Subject: [sidr] I-D Action: draft-ietf-sidr-bgpsec-algs-07.txt

From: [email-masked]
Date: Wed, 02 Jul 2014 08:34:55 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF.

        Title           : BGP Algorithms, Key Formats, & Signature Formats
        Author          : Sean Turner
	Filename        : draft-ietf-sidr-bgpsec-algs-07.txt
	Pages           : 7
	Date            : 2014-07-02

Abstract:
   This document specifies the algorithms, algorithms' parameters,
   asymmetric key formats, asymmetric key size and signature format used
   in BGPSEC (Border Gateway Protocol Security).  This document updates
   the Profile for Algorithms and Key Sizes for use in the Resource
   Public Key Infrastructure (RFC 6485).

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-algs/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-algs-07

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-bgpsec-algs-07

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Sean Turner <[email-masked]>
Date: Wed, 2 Jul 2014 11:36:45 -0400

A minor update to move some references that were in the wrong place as well as to correctly identify where the OID goes that indicates the algorithm used in the CRMF (thanks Sandy for pointing these out).  Oh and I updated the dates.

spt

On Jul 02, 2014, at 11:34, [email-masked] wrote:

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

---

From: Sean Turner <[email-masked]>
Date: Wed, 2 Jul 2014 11:39:42 -0400

And then I just noticed the section #ing is not sequential :(  Stay tuned for another version.

spt

---

From: Geoff Huston <[email-masked]>
Date: Tue, 8 Jul 2014 06:19:17 +1000

Hi Sean,

Whats the relationship between this draft and draft-ietf-sidr-rfc6485bis?

g

---

From: Geoff Huston <[email-masked]>
Date: Tue, 8 Jul 2014 06:28:49 +1000

Hi Sean,

g

---

From: Matthew Lepinski <[email-masked]>
Date: Mon, 7 Jul 2014 17:04:39 -0400

Yes, there seems to be an issue here:

I believe the question is what types of keys can appear as the subject
public key in an RPKI certificate.

--  RFC 6485 says "See 6487" (and thus 6487bis when it is published)
to find out what is allowed as a subject public key

-- draft-ietf-sidr-bgpsec-pki-profiles updates RFC 6485 and says "For
Router Certs (end-entity certificates use by BGPSEC) see
draft-ietf-sidr-bgpsec-algs

Ideally, this shouldn't be a problem. RFC 6487 governs subject public
keys for all certificates in the RPKI except BGPSEC router
certificates and draft-sidr-bgpsec-algs covers that case.

That being said, we currently have two working group documents that
update RFC 6485 and I am not sure that it is sufficiently clear in the
text of those documents how the two updates interact.

---

From: Geoff Huston <[email-masked]>
Date: Tue, 8 Jul 2014 08:29:49 +1000

yes confusion all round

> to find out what is allowed as a subject public key

RFC 6487 says "See RFC6485" and (thus 6485bis when it is published) to find out what is allowed as a subject public key

i.e. I think I understand what you are saying here, but you seem to have 6485 and 6487 swapped - right?

g

---

From: Matthew Lepinski <[email-masked]>
Date: Mon, 7 Jul 2014 18:37:44 -0400

Yes, let me try re-sending my original message -- this time with
correct RFC numbers:

--  RFC 6487 says "See 6485" (and thus 6485bis when it is published)
to find out what is allowed as a subject public key

-- draft-ietf-sidr-bgpsec-pki-profiles updates RFC 6487 and says "For
Router Certs (end-entity certificates use by BGPSEC) see
draft-ietf-sidr-bgpsec-algs

That being said, we currently have two working group documents that
update existing documents and I am not sure that the text of those
documents (taken together) is sufficiently clear on what can and
cannot appear as a subject public key in an RPKI certificate.

In particular, 6485bis seems to say "only RSA with SHA256" and I think
what sidr-bgpsec-pki-profiles wants to say (but I don't know if it is
sufficiently clear) that b485bis applies to all RPKI certificates
except end-enty router certificates and that those certificates should
look at bgpsec-algs to figure out what an acceptable subject public
key is

---

From: Geoff Huston <[email-masked]>
Date: Tue, 8 Jul 2014 09:00:35 +1000

> draft-ietf-sidr-bgpsec-algs

but...

the header of draft-ietf-sidr-bgpsec-algs-08 says:
    "Updates: 6485 (if approved) "

so I'm still confused about the two 6485 update drafts.

> certificates and draft-sidr-bgpsec-algs covers that case.

errr - do you mean 6487 or 6485?

> cannot appear as a subject public key in an RPKI certificate.

I can agree wholeheartedly on this observation of a lack of clarity here!

Geoff

---

From: Sandra Murphy <[email-masked]>
Date: Mon, 7 Jul 2014 19:42:51 -0400

> Whats the relationship between this draft and draft-ietf-sidr-rfc6485bis?

So you want to know if bgpsec-algs is updating the original RFC6485 or updating rfc6485bis?

--Sandy, speaking as regular ol' member

---

From: Sean Turner <[email-masked]>
Date: Mon, 7 Jul 2014 21:11:28 -0400

> So you want to know if bgpsec-algs is updating the original RFC6485 or updating rfc6485bis?

draft-ietf-sidr-bgpsec-algs adds support for EC public keys & signature formats to RFC 6485 for BGPsec.  If 6485bis is going to be updated to include these changes then draft-ietf-sidr-bgpsec-algs can go away but I didn’t think that was the plan.  Assuming EC algs aren’t incorporated in 6485bis then draft-ietf-sidr-bgpsec-algs needs to update RFC 6485 or any document that obsoletes it.  I’m happy to change the updates header info to “Updates: draft-ietf-sidr-rfc6485bis (once approved)" though if that makes things crystal clear.

spt

---

From: Geoff Huston <[email-masked]>
Date: Tue, 8 Jul 2014 14:49:30 +1000

well I would like to understand why there appears to be two parallel efforts
to update RFC6485, and it was I suppose a question that is correctly passed
to the chairs, given that the chairs wanted rfc6485bis produced, and
I assume that the chairs similarly approved the WG adoption of bgpsec-algs.

The original desire was to isolate the structure and framework from the crypto,
which is why RFC6485 was produced in the first place, but now it appears that we
are fragmenting this and producing multiple crypto profiles.

Geoff

(I was told recently that the DNS specs now span a few hundred RFCs. For a widely deployed
active protocol I can kinda see that, but I'm not sure that there is merit in SIDR at this
point in time to take this same quantity of RFCs as an objective! :-) )

---

From: Matthew Lepinski <[email-masked]>
Date: Tue, 8 Jul 2014 01:02:13 -0400

So I have no preference with regards to one document or two. (That is, if
the working group wants to merge the BGPSec algs document with 6485bis, I
see nothing wrong with fewer documents.)

However, I believe that there is a good reason to have a distinct set of
algorithms for creating BGPSEC signatures and for signing RPKI
certificates. In particular, the devices that we envision producing BGPSEC
signatures are different than the devices that are currently signing RPKI
certificates. Additionally, signature length seems to be a non issue today
with regards to signing RPKI certificates, but signature length is a more
important consideration for BGPSEC signatures. That is, the trade offs in
what makes a good signature algorithm are somewhat different when it comes
to BGPSEC and I don't think we want to artificially force the two signature
algorithms (for RPKI certs and for BGPSEC) to be the same. That is the
original reason for producing the bgpsec-algs document (of course, this
document was first written before it became clear that we needed to do a
bis for 6485, and so perhaps it we should revisit whether we want one
document or two).

- Matt Lepinski

---

From: Geoff Huston <[email-masked]>
Date: Tue, 8 Jul 2014 15:07:23 +1000

Personal opinion:

I think SIDR is already densely littered with a LOT of specification documents, and 
we are now at a stage where maintaing internal consistency across these specs is a 
real challenge. Indeed even now there is a need for a SIDR Roadmap to explain the
set of documents we have and their inter-relationship.

I would prefer to see fewer documents, not more, and I think the two update
efforts in 6485 should be merged.

Geoff

---

From: Geoff Huston <[email-masked]>
Date: Tue, 8 Jul 2014 15:13:19 +1000

On 8 Jul 2014, at 3:02 pm, Matthew Lepinski <[email-masked]> wrote:

> So I have no preference with regards to one document or two. (That is, if the working group wants to merge the BGPSec algs document with 6485bis, I see nothing wrong with fewer documents.)
> 
> However, I believe that there is a good reason to have a distinct set of algorithms for creating BGPSEC signatures and for signing RPKI certificates.

I can understand that perspective, and it makes sense to me, But that does not necessarily imply two RFCs. I think we need to keep an eye on the entire framework, and as we add pieces to the RPKI we should clearly understand where and how they interlock. For that reason,  I would like to see a single RPKI algorithms and key length spec that encompasses the entire RPKI use domain. If there is a need to split this document to make the distinction between use in the certificate and authority domain and use within the router-to-router domain then thats fine, but that split would (in my opinion) be within a single specification document, rather than more documents.

Geoff

> In particular, the devices that we envision producing BGPSEC signatures are different than the devices that are currently signing RPKI certificates. Additionally, signature length seems to be a non issue today with regards to signing RPKI certificates, but signature length is a more important consideration for BGPSEC signatures. That is, the trade offs in what makes a good signature algorithm are somewhat different when it comes to BGPSEC and I don't think we want to artificially force the two signature algorithms (for RPKI certs and for BGPSEC) to be the same. That is the original reason for producing the bgpsec-algs document (of course, this document was first written before it became clear that we needed to do a bis for 6485, and so perhaps it we should revisit whether we want one document or two).
> 
> - Matt Lepinski
>

---

From: Sandra Murphy <[email-masked]>
Date: Tue, 8 Jul 2014 15:02:02 -0400

> draft-ietf-sidr-bgpsec-algs adds support for EC public keys & signature formats to RFC 6485 for BGPsec.  If 6485bis is going to be updated to include these changes then draft-ietf-sidr-bgpsec-algs…

The rfc6485bis draft is intended to clean up errors in RFC6485.  That should progress.  Implementations already comply with the corrected text.

The bgpsec-algs draft is adding new algorithms to be used in new RPKI objects and in the bgpsec protocol.  The bgpsec-algs draft should be updating the rfc6485bis document.  As there's still work in progress here, there should be no problem with the order of publication.  I can see that there are several references to RFC6485 in bgpsec-algs that will have to take the final publication of rfc6485bis draft into account, in order to clear up the relationships.

--Sandy, speaking for the wg co-chairs

---

From: Geoff Huston <[email-masked]>
Date: Wed, 9 Jul 2014 06:23:34 +1000

> The bgpsec-algs draft is adding new algorithms to be used in new RPKI objects and in the bgpsec protocol.  The bgpsec-algs draft should be updating the rfc6485bis document.  As there's still work i…

this seems to me to be a deliberate decision to proliferate more documents.

- we are updating rfc6485 to clean up an error

- we are updating rfc6485 to add crypto profiles for BGPSEC router use

And out of this the chair is saying "lets have TWO documents", RFC6485bis and RFC6485bisupdate

If this is what you are saying, then as a WG member I strongly disagree with this edict from the chair. We should consider the poor consumer of our various efforts and try to consolidate our work, and not proliferate the madness across many documents in such a profligate manner! (0.5 :-))

Geoff

---

From: Sandra Murphy <[email-masked]>
Date: Tue, 8 Jul 2014 16:57:05 -0400

> If this is what you are saying, then as a WG member I strongly disagree with this edict from the chair. We should consider the poor consumer of our various efforts and try to consolidate our work,…

The RFC6485bis draft corrects errors, where the error corrections are known. 

The bgpsec-algs document is new stuff and not yet completely worked out and not yet implemented or in use.

I see those as two different separable issues and do not want to see the error correction wait for, confused with,  the bgpsec-algs completion.

RFC6485 is in use and deployment in the RPKI origin validation, as will the eventual RFC6485bis.  The additional algorithms in bgpsec-algs will be used in path validation in the bgpsec protocol, not in origin validation.  The uses are separable.  

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