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 > On 30 Jun 2016, at 23:11, Sandra Murphy <[email protected]> wrote: > > 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)”, believe that the document is ready for a working > group last call. > > This starts a two week wglc which will end on 14 July 2016. > > 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. > > 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. > > —Sandy, speaking as one of the wg co-chairs. > > _______________________________________________ > sidr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/sidr _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
