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

Howdy folks!
This WGLC ended up being a bit more of a long discussion than I
anticipated... I think since this WGLC there have been 2 document updates
to catch comments/concerns/etc and I think deal with them properly.

I don't see anymore chatter for this document after 9/2/2016, so I think we
should move this document forward to IESG.. I'll be sending along a pub
request today.

-chris

On Tue, Jul 19, 2016 at 10:00 AM, Stephen Kent <kent@bbn.com> wrote:

> 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 of  resources 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
>
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr
>
>