Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: text/plain; charset=windows-1252
From: Tim Bruijnzeels <tim@ripe.net>
In-Reply-To: <8E32FD39-FD20-455C-8BEC-5752DE9C8531@tislabs.com>
Date: Sun, 17 Jul 2016 11:47:39 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <DC08C8ED-E611-4D95-A557-3EE74633F9A4@ripe.net>
References: <8E32FD39-FD20-455C-8BEC-5752DE9C8531@tislabs.com>
To: Sandra Murphy <sandy@tislabs.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/BtKc3xJtMuWUwcPUsxLwgIyyzr4>
Cc: sidr <sidr@ietf.org>
Subject: Re: [sidr] wglc for draft-ietf-sidr-adverse-actions-00
Precedence: list

Hi,

I have a number of late comments (unfortunately no time to read this in =
detail earlier)

First of all, I believe that the structure of the document, where =
analysis is done without going into details of solutions, is useful.

That said I have some substantial comments. I think the order of the =
analysis of the various objects in section 2 is not logical. This may =
sound like a trivial thing, but actually I think a re-ordering will help =
to think about the context and different vectors for each.

Comments on each case:

- CA certificates (section 2.5)

I suggest that section 2 should start with this. CA certificates are =
issued by parent CAs. So the sections on modification, revocation and =
injections make more sense to me here - they are all done by the parent =
of the CA that is affected by these actions.

@A-5.4.1: A shrink may be seen as adverse by the INR holder, but there =
may be reasons (e.g. transfers, temporary assignments, closure) why an =
RIR may have to reclaim certain resources. In our case these practices =
are based on community consensus in our address policy working group. =
So.. a specific INR holder may not be happy to see resources removed, =
but in some cases this is a feature, not a bug.

@A-5.4.2: I think this is being addressed by validation-reconsidered

@A-5.4.5: It may be hard to detect this case because of normal key =
rolls.

- Manifests (section 2.2) and CRLs (section 2.4)

These objects are part of the 'boilerplate' objects that a CA uses. To =
me they seem related. At least in our RP software we typically find the =
'current' MFT and CRL for a validated CA certificate and then we use =
this to find and validate all other objects issued by this CA. So it =
would make sense to me to look at these next (as 2.2 and 2.3 after CA =
certificates)

In any case I don't think that the analysis of modification, revocation =
and injections are very useful here. For these to work an adverse agent =
needs to have access to the CA certificate's private key *and* =
repository. Bets are then just off.

I understand that you don't want to go in solution space here, but.. I =
believe that with RRDP we can now actually get multiple objects as a =
single delta. That means that a CA can publish a new MFT and CRL, and =
all its objects together.

This in turn means that an RP can find a MFT and CRL, check the =
thisUpdate/nextUpdate time to detect a withhold. And it can find all the =
objects enumerated on the MFT by hash. So it can detect withhold, replay =
or modification of other objects.

Ultimately the adverse actions by a repository (deletion, suppression, =
corruption) cannot be prevented, but they can be *detected*. And I =
believe this is relevant to the analysis of those adverse actions.


- Ghostbusters

No comment

- ROAs

Similarly to manifests I don't think that the analysis of modification, =
revocation and injections are very useful here. Bets are off if an =
adversary has the key and the repo.

I think it would be more useful to analyse what the general problem is =
w.r.t. outsourcing CA functions - as is done later in the doc. People do =
it because it's convenient, but obviously this means that you have to =
*trust* that the organisation you outsource to will do any of those =
M/R/I type adverse actions.

- Router Certs

Same concerns as ROAs

=20












> On 30 Jun 2016, at 23:11, Sandra Murphy <sandy@tislabs.com> wrote:
>=20
> The authors of draft-ietf-sidr-adverse-actions-00, "Adverse Actions by =
a Certification Authority (CA) or Repository Manager in the Resource =
Public Key Infrastructure (RPKI)=94,  believe that the document is ready =
for a working group last call.
>=20
> This starts a two week wglc which will end on 14 July 2016.
>=20
> Please review the draft and send comments and your opinion of whether =
it is worthy of publication to the list.  Remember that support for =
publication is needed, and comments can improve quality, so lack of =
comments is not sufficient.
>=20
> You can reach the document at =
https://tools.ietf.org/html/draft-ietf-sidr-adverse-actions-00 and =
https://datatracker.ietf.org/doc/draft-ietf-sidr-adverse-actions.
>=20
> =97Sandy, speaking as one of the wg co-chairs.
>=20
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr