Re: [sidr] wglc for draft-ietf-sidr-adverse-actions-00

[Stephen Kent <[e-mail]>]

Tim,

Thanks for taking the time to read and comment on the document.

I will change CA certificate analysis to be section 2.1, and make the 
CRL section b 2.3, as per your request. The Manifest section will remain 
2.2, ROAs will become 2.4, GB will become 2.5, and Router Certificates 
will remain 2.6. This will require a lot of changes to the pointers 
within and between sections, but we aim to please :-).

A-5.4.1: I agree that reducing the set ofresources in a CA certificate 
may be done for legitimate reasons, even if the INR holder does not 
agree with the reduction. Nonetheless, this is an adverse action from 
the perspective of the INR holder. It’s important to note that there are 
cases when this reduction is the result of an attack against or an error 
by the parent CA. Thus I believe it is important to retain this action 
in the list.

A-5.4.2: I’ll delete this action.

A-5.4.5: I agree that this may be hard to distinguish from a legitimate 
key rollover, except that a key rollover would have both old and new CA 
keys present simultaneously. I’ll add a note to this effect.

I disagree with your suggestion that we remove the modification, 
revocation, and injection actions for Manifests, ROAs, and Router 
Certificates. First, remember that adverse actions include errors by 
CAs, and transient attacks against CAs. In the former case the private 
key is clearly available and the CA may also control the repository. In 
the latter case note that an attacker need not need learn the private 
key’s value; he/she needs only the ability to cause an HSM to use the 
key. Also, an attacker need not control the repository to effect these 
actions; an RP might be misdirected to a different set of files via a 
routing system attack (ironic?) or a DNS attack.

Recall that the goal of this document is to document, as best we can, a 
wide range of actions that are adverse, irrespective of whether we can 
prevent or detect such actions. Your message noted that RRDP may make it 
easier for RPs to detect some of these actions; I suggest you add 
references to the relevant sections of this document as further 
motivation for transitioning to RRDP.

Finally, when we revised an earlier version of the document we decided 
to include every action in the same order in each section (except for GB 
records, where it would be trivial), to make it easier for a reader to 
see that we were addressing the same issues for each object.

Steve