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

From: "Terry Manderson" <[email-masked]>
Date: Tue, 17 Nov 2015 18:09:07 -0800

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?

---

From: Sandra Murphy <[email-masked]>
Date: Thu, 19 Nov 2015 13:27:31 -0500

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.

The wg decided to create RFC6485bis, to correct the OID problem and the OID problem only, with emphasis on the “only”.

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.

Does RFC6916 satisfy your concerns about a change of algorithm?

Would you prefer that RFC6485bis remove the inherited “SHOULD” language and point only to RFC6916?

—Sandy

On Nov 17, 2015, at 9:09 PM, Terry Manderson <[email-masked]> wrote:

> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr

---

From: Terry Manderson <[email-masked]>
Date: Fri, 20 Nov 2015 03:59:56 +0000

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
>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
>> Please refer to 
>>https://www.ietf.org/iesg/statement/discuss-criteria.html