[address-policy-wg] 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) going to Last Call

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I am afraid I don't believe this policy should be adopted at this time.

My reason is that I think it creates a legal and political risk that is
substantial and as yet uninvestigated in the PDP, but which may in the
long term reduce the overall robustness of Internet infrastructure to an
extent that greatly outweigh the security benefits of the policy.

This is not a minor, administrative policy. It is (even if not intended
as such) the first step in a process the end result of which would be a
major change to the Internet architecture. I am afraid that the ultimate
outcome could be that the Internet becomes more fragile as a
consequence. True, it's only the first step. But if it's a step in the
wrong direction, let's not do it.

I don't think we should approve this policy until we are certain that
this approach is necessary, worth the risk, that no acceptable
alternative solutions (or partial solutions) to the problem exist, and
that we've also established all appropriate measures to mitigate the
foreseeable risks.

The complete argument about why I fear a bad outcome will be too long
and complex for a first post on this subject, so let me try to give the
briefest summary I can manage instead:

I believe that if this policy is adopted, and if it is taken up
significantly be operators, it will encourage a dramatic increase in the
number of demands from law enforcement and private litigants to the RIPE
NCC to revoke both allocation of resources and their certificates,
without the consent of the person to whom the resource is delegated.

Once legislators realise that the NCC has a more effective power to
revoke allocations than previously existed, and has become more capable
of making networks appear to "go offline" than it currently is able,
legislators will likely respond by creating new powers for law
enforcement to oblige the NCC to revoke resource allocations as a tool
to address undesired behaviour by network users.

In short, in a world where reachability is significantly affected by the
ability to produce a valid certificate under this policy, the RIPE NCC
will be seen as a "one-stop-shop" for knocking networks offline, to
control illicit content and online activity.

     (Perhaps reachability will not be affected because network
     operators will ignore these certificates, but if we believe that
     then isn't this policy a waste of time and effort? And operators
     may not have a free choice: new legal powers were created by the
     EU last year that could easily be used to compel adoption).

Thus, the RIPE NCC would be gradually transformed into a much more
political body; indeed, I think at least as political as ICANN currently is.

My concerns are not merely academic, they are immediate and practical.
We know that many countries, including the EU, have adopted or are
actively considering adopting legal requirements for network operators
to block packet transit to/from network addresses outside their network
in order to inhibit illicit content or activity (e.g. copyright
infringement). LEAs already attend RIPE meetings (Co-operation WG) to
ask the community to develop policies to transfer allocations of network
blocks to the LEA following an allegation by the LEA that the netblock
is being used for illicit purposes, the idea being to seize control of
routing. Earlier this year the RIPE NCC attended at least one meeting
that I know of to discuss this with EU officials. So far the NCC has
fended off such requests, I understand, on the grounds that it doesn't
have control over routing. If this policy proceeds, is adopted and
successful, that argument will be greatly weakened.

Would making RIPE NCC such an attractive single point of failure really
make the Internet more secure and robust?

I believe that before this policy is adopted the community should
consider in depth:

i) whether these concerns are at least potentially valid (I am convinced
they are);

ii) If so, whether the problem that this policy addresses is
sufficiently serious to warrant accepting these new risks [1]; and

iii) Even if the problem is serious enough, whether alternative means to
address it could be found that would mitigate these risks [2]. (For
example, if the problem could be 80% solved using a model that does not
give RIRs a power to revoke and expire certificates "needed" for
routing, is the residual 20% of the problem really serious enough to
warrant creating the risks I describe).

iv) Even if the problem still justifies adopting the approach taken in
this policy proposal, what other steps should be taken simultaineously
to mitigate these risks.

For myself, I am convinced about (i). I have serious doubts about (ii)
and (iii) myself, and perhaps more importantly can see no evidence on
the list archive that the community has actively assessed whether (ii)
is true, and no evidence that other potential architectures or system
designs have been considered as a possible alternative that might better
mitigate the risks I describe. Nor has there been any visible discussion
of (iv).

Even if I've missed something, do we really think the community has
considered these issues in depth? Or have they been shunted off as a
problem to be looked at later, or elsewhere?

The presentation at yesterdays RIPE meeting plenary by Randy Bush and
the discussion that followed convinced me that there is much more for
the community to discuss.

I have raised this issue at previous RIPE meetings but only recently
become aware that to affect the PDP it was necessary to post on this
list, for which my apologies. However I now see such objections are the
explicit purpose of the Last Call, so I hope you'll consider this
objection carefully.

There is much more I could say, but for a first post on the subject I'll
leave it at that; I don't want to create a bigger "wall of text" than
absolutely necessary.

I would be grateful if those who agree with me that this discussion
warrants delaying adoption of the proposal would say so now, so that the
WG Chair can see whether there is a "serious objection" that prevents a
rough consensus being declared at this time.

My apologies to those who have worked so long and hard on this, with
only the best of motives, on the assumption that there was general
support for this approach. But I'm afraid this issue is too important to
let this pass without raising my concerns, and asking the community to
stand with me.

Malcolm.

[1] Yes, route hijacking does happen, sometimes by mistake and sometimes
by malice. But how often? Are current responses sufficient to deal with
it proportionately? Could they be made more effective without any kind
of certification scheme? Would something new, that's not a certification
scheme suffice?

[2] For example, could we creates "webs of trust" rather than a single
hierarchy? Would that be "good enough" or is a hierarchy essential?
Could a PKI for address allocations work sufficiently well without
investing the hierarchy with authority to revoke certificates? Should we
consider an architecture with a distributed issuer/revoker, spread
across multiple jurisdictions? What other models exist?

- -- 
            Malcolm Hutty | tel: +44 20 7645 3523
   Head of Public Affairs | Read the LINX Public Affairs blog
 London Internet Exchange | http://publicaffairs.linx.net/

                 London Internet Exchange Ltd
  Maya House, 134-138 Borough High Street, London SE1 1LB

         Company Registered in England No. 3137929
       Trinity Court, Trinity Street, Peterborough PE1 1DA
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk2/56YACgkQJiK3ugcyKhTdwgCgp02ZpOj7XhT1TlN5xk7vOF9l
ZdAAoIe+LF1Dt70q9Gonk2/CsoLG6N2O
=z7io
-----END PGP SIGNATURE-----