Subject: Re: [sidr] Terry Manderson's Discuss on draft-ietf-sidr-rfc6485bis-04: (with DISCUSS)

From: Sandra Murphy <[email-masked]>
Date: Sat, 5 Dec 2015 00:29:29 -0500

The AD, the chairs and the authors have discussed the draft change suggested below.

To summarize:  The language Terry’s DISCUSS objects to is SHOULD recommendations of how to handle algorithm transitions, and being SHOULD only, leads to potential differences in implementation and operation choice.  RFC6916 made much more stringent descriptions of algorithm transition and mandates certain actions.  RFC6916 was published a year after RFC6485 and rfc6485bis attempts to meld the two by pointing to it, but leaves the SHOULD language in place.

The decision of AD, chairs and authors is that the wg consensus for rfc6485bis was focussed on the OID problem, so it could not be said that this section was carefully considered by the wg.

So the draft draft-ietf-sidr-rfc6485bis-04 is being returned to the wg to address this problem and then to do a wglc (and IETF Last Call) before it is returned to the IESG.

—Sandy, speaking as one of the co-chairs

On Nov 19, 2015, at 10:59 PM, Terry Manderson <[email-masked]> wrote:

> Hi Sandy,
> 
> 
> On 20/11/2015 4:27 am, "Sandra Murphy" <[email-masked]> wrote:
> 
>> A bit of history here.
>> 
>> After RFC6485 was published, it was discovered that it incorrectly used
>> the same OID for all RPKI crypto uses, which conflicts with CMS specs and
>> is inconsistent with known implementations.
> 
> I am aware of that.
> 
>> 
>> The wg decided to create RFC6485bis, to correct the OID problem and the
>> OID problem only, with emphasis on the ³only².
> 
> Timeline leap is not your friend here. 6485 pre-dates 6916. 6485 is
> minimalist (and from a point of view, wrong) about algorithm changes.
> 
>> 
>> The ³SHOULD² language in section 5 is inherited from RFC6485, except for:
>> 
>>  The recommended
>>  procedures to implement such a transition of key sizes and algorithms
>>  is specified in [RFC6916]
>> 
>> RFC6916, which was published a year after RFC6485, is "Algorithm Agility
>> Procedure for the Resource Public Key Infrastructure (RPKI)².  It
>> describes the procedure to follow in transitioning from one algorithm/key
>> size to another.
> 
> Correct. It was this text that drew me to the section. And since the text
> pre-dates 6916, which takes a more encompassing view of an
> algorithm/profile change with a security section that adequately warns of
> invalidity due to a RP not supporting the new certificate profile, I view
> 6916 as more 'with the times' (YMMV).
> 
> 
>> 
>> Does RFC6916 satisfy your concerns about a change of algorithm?
> 
> It does a better job that allowing a CA or RP to opt out and fracture the
> RPKI.
> 
>> 
>> Would you prefer that RFC6485bis remove the inherited ³SHOULD² language
>> and point only to RFC6916?
> 
> Yes, That is certainly one way to address this. And I would be OK with
> that.
> 
> 
> Cheers
> Terry
> 
>> 
>> ‹Sandy
>> 
>> On Nov 17, 2015, at 9:09 PM, Terry Manderson <[email-masked]>
>> wrote:
>> 
>>> Terry Manderson has entered the following ballot position for
>>> draft-ietf-sidr-rfc6485bis-04: Discuss
>>> 
>>> When responding, please keep the subject line intact and reply to all
>>> email addresses included in the To and CC lines. (Feel free to cut this
>>> introductory paragraph, however.)
>>> 
>>> 
>>> Please refer to
>>> https://www.ietf.org/iesg/statement/discuss-criteria.html
>>> for more information about IESG DISCUSS and COMMENT positions.
>>> 
>>> 
>>> The document, along with other ballot positions, can be found here:
>>> https://datatracker.ietf.org/doc/draft-ietf-sidr-rfc6485bis/
>>> 
>>> 
>>> 
>>> ----------------------------------------------------------------------
>>> DISCUSS:
>>> ----------------------------------------------------------------------
>>> 
>>> I'm not so sure that this will be an easy DISCUSS to work through as I
>>> view this in light of future sustainability/deployability of RPKI and
>>> any
>>> protocol wedded to it (eg BGPSEC).
>>> 
>>> Section 5 "Additional Requirements" suggests that both CAs and RPs
>>> "SHOULD" be capable of supporting a transition and thus able to support
>>> multiple RPKI alg. and key profiles. To me this "SHOULD" seems like it
>>> invites fragility in any such transition. An immediate example would be
>>> the root DNSSEC ksk rollover. An rather large amount of work is underway
>>> to ascertain the impact. By leaving the SHOULDs in place is this walking
>>> the same path?
>>> 
>>> Let me ask another way. Under what situations is it actually appropriate
>>> for a CA or RP to be able to ignore the requirement of being able to
>>> support a phased introduction/deprecation of new/different RPKI
>>> algorithm
>>> and key profiles? And if they ignore such a recommendation does this
>>> make
>>> the entire RPKI infrastructure a fractured PKI by algorithm?
>>> 
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> sidr mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/sidr
>> 
> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr

---

From: Sandra Murphy <[email-masked]>
Date: Fri, 11 Dec 2015 12:41:42 -0500

> —Sandy, speaking as one of the co-chairs

speaking as document shepherd.

This message is intended to spark discussion.

Terry agreed that his preference is to remove the SHOULD language.  He did not insist that this was the only way to go.

>> Yes, That is certainly one way to address this. And I would be OK with

If we did do that, it could look like:

OLD

   It is anticipated that the RPKI will require the adoption of updated
   key sizes and a different set of signature and hash algorithms over
   time, in order to maintain an acceptable level of cryptographic
   security to protect the integrity of signed products in the RPKI.
   This profile should be replaced to specify such future requirements,
   as and when appropriate.

   Certification Authorities (CAs) and RPs SHOULD be capable of
   supporting a transition to allow for the phased introduction of
   additional encryption algorithms and key specifications, and also
   accommodate the orderly deprecation of previously specified
   algorithms and keys.  Accordingly, CAs and RPs SHOULD be capable of
   supporting multiple RPKI algorithm and key profiles simultaneously
   within the scope of such anticipated transitions.  The recommended
   procedures to implement such a transition of key sizes and algorithms
   is specified in [RFC6916]

NEW

   It is anticipated that the RPKI will require the adoption of updated
   key sizes and a different set of signature and hash algorithms over
   time, in order to maintain an acceptable level of cryptographic
   security to protect the integrity of signed products in the RPKI.
   This profile should be replaced to specify such future requirements,
   as and when appropriate.

   The mandated procedures to implement a transition of key sizes and
   algorithms are specified in [RFC6916].

Comments?

—Sandy, speaking as document shepherd and regular ol’ member

---

From: Sandra Murphy <[email-masked]>
Date: Fri, 11 Dec 2015 12:46:08 -0500

speaking as wg co-chair:

> So the draft draft-ietf-sidr-rfc6485bis-04 is being returned to the wg to address this problem and then to do a wglc (and IETF Last Call) before it is returned to the IESG.

Previous discussions on  draft-ietf-sidr-rfc6485bis were restricted to the OID problem.  The current discussion and eventual wglc are not restricted to the OID problem or to Terry’s Discuss.

—Sandy, speaking as wg co-chair