Subject: [sidr] Stephen Farrell's Discuss on draft-ietf-sidr-bgpsec-pki-profiles-19: (with DISCUSS and COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Wed, 04 Jan 2017 05:51:20 -0800

Stephen Farrell has entered the following ballot position for
draft-ietf-sidr-bgpsec-pki-profiles-19: 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-bgpsec-pki-profiles/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I have a few probably quick things I'd like to discuss for
this one:

(1) 3.1.1: Why MUST a CA ensure that the CA name and
Subject name combination is unique? I don't see what'd
break in BGPsec if that rule is omitted, but maybe I'm
missing something. 

(2) 3.1.1: Similarly, I'm not clear why only common name
and serial number are allowed in Subject.  Why is that
needed for interop? (I can see that you want to say that
code MUST support those but not why you want to prevent
other things.)

(3) Where's certificate status checking covered? What's
expected for BGPsec router certs? If BGPsec speakers are
intended to inherit the CRL checking from 6487 then being
explicit about that would probably be worthwhile.  And I'd
wonder if router cert revocation will be more common than
for other resource certs, in which case an OCSP-like
system could be needed - did the WG consider that?

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

- section 2: I think this is a bit badly written: "The use
of BGPsec Router Certificates in no way affects RPKI RPs
that process Manifests and ROAs because the public key
found in the BGPsec Router Certificate is used only to
verify the signature on the BGPsec certificate request
(only CAs process these) and the signature on a BGPsec
Update Message [ID.sidr-bgpsec-protocol] (only BGPsec
routers process these)." Do you mean that there's no way
that an entity can confuse a Manifest, ROA, CSR or BGPsec
update so there's no issue with which public keys are used
to verify the signatures on those data structures?

- section 3: As noted in my comments on the BGPsec
protocol, it'd be better to call out the SKI here if you
don't add the direct ref to 6487 to the BGPsec protocol
draft.

---

From: Rob Austein <[email-masked]>
Date: Wed, 04 Jan 2017 15:04:13 -0500

[Not the author, but...]

At Wed, 04 Jan 2017 05:51:20 -0800, Stephen Farrell wrote:
...
> code MUST support those but not why you want to prevent

This draft is a profile of RFC 6487, which is itself a profile of RFC
5280.  All of the above is pretty much verbatim from RFC 6487.

> explicit about that would probably be worthwhile.

Yes, I think this too is inherited from RFC 6487.

> And I'd wonder if router cert revocation will be more common than
> for other resource certs, in which case an OCSP-like system could be
> needed - did the WG consider that?

Not as such.  Fair question, but the architecture kind of assumes that
the RPKI RP process is separable from the BGPSEC implementation per
se, BGPSEC just consumes the output of that process.

Most likely implementation technique does all the RPKI stuff per se on
a separate box and just stuffs the resulting raw keys into the router
using the rpki-rtr protocol, so the router itself probably would not
have the information needed to play OCSP even if it wanted to do so,
which it probably doesn't.  Requiring the routers to speak OCSP seems
like a potentially dangerous layering violation.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 4 Jan 2017 20:57:24 +0000

Hi Rob,

> [Not the author, but...]

No matter - a good answer is a good answer:-)

> 5280.  All of the above is pretty much verbatim from RFC 6487.

Hmm. I wonder if that's the best plan, especially if there's
no interop justification for some of it. I note that 6487
says "In the RPKI, the subject name is determined by the
issuer, not proposed by the subject" but that seems a bit
weird for routers, where I would guess there'll be more
diversity in terms of key/CSR generation code. (Correct me
if I'm wrong but I'm not sure if it's possible to conform
to these requirements with e.g. openssl, or is it?)

> se, BGPSEC just consumes the output of that process.

I'd wonder if that means some revocation request protocol will be
needed later. But it's fine to not try define that now.

More to the point is whether or not the WG have thought about the
revocation support in the RPKI and whether or not that seems also
ok for BGPsec. (I'm unsure myself, but mostly due to the number of
moving parts in the RPKI.)

> which it probably doesn't.  

So if that's a widely shared view of WG participants then it'd be
good to see it described somewhere to help implementers. (It may
be in the -overview document which I've yet to read.)

> Requiring the routers to speak OCSP seems

Not sure about a layering violation but I can see it'd likely be
problematic;-)

Cheers,
S.

---

From: Rob Austein <[email-masked]>
Date: Wed, 04 Jan 2017 17:15:57 -0500

...
> no interop justification for some of it.

The theory, such as it is, goes:

* RPKI is a tightly constrained profile of X.509v3, with almost
  everything either required or forbidden, to reduce the number of
  grey areas.

* The BGPSEC profile is a minimal set of changes and extensions to the
  RPKI profile: same overall goal, slightly different constraints.

> I note that 6487 says "In the RPKI, the subject name is determined
> by the issuer, not proposed by the subject" but that seems a bit
> weird for routers, where I would guess there'll be more diversity in
> terms of key/CSR generation code.

Well, strictly speaking the subject name is always selected by the
issuer in X.509, but I know what you mean.

RFC 6487 is weird about this because various parties were extremely
concerned to avoid anything that could be construed as certification
of real-world identity, ie, they did not want to find themselves in
the mainstream PKI business.  So RPKI uses meaningless names and has
the ability to enforce that, hence the text you note in RFC 6487.

RFC 6487 6.1.1 does in fact allow the subject to include a subject
name in the PKCS #10 request, but the text is loaded with weasel
words.  Speaking as someone who has implemented all of this, I find
the RFC 6487 constraints on subject name in PKCS #10 requests a bit
excessive, but that's not the document currently under discussion.

> (Correct me if I'm wrong but I'm not sure if it's possible to
> conform to these requirements with e.g. openssl, or is it?)

The OpenSSL command line tool would probably fight hard against either
omitting the subject field from the PKCS #10 request or allowing it to
be NULL.  The former (field absent) is not even syntactically legal
X.509.  The latter (present but NULL) is legal but kind of unusual:
RFC 5280 4.1.2.6 allows it in certificates if a critical, non-empty
subjectAltName extension is present, RFC 2986 is silent on the subject
and is only informational in any case.

I'm pretty sure that the OpenSSL library would allow the
present-but-NULL form, but haven't tested it (recently? ever? don't
recall...).

In practice, I don't think any of the RKI CA implementations reject
PKCS #10 requests for having a non-NULL subject, they just ignore it.

All of this is still a problem with RFC 6487, which we should have
caught five years ago.  Oops.  Not sure what the best approach is when
trying to sub-profile a profile with a known wart like this.

> needed later. But it's fine to not try define that now.

Fair point.

> moving parts in the RPKI.)

Has been discussed, somewhat noisily.  Ask a SIDR WG chair if you want
an opinion on WG consensus.  My own take is that router keys probably
get whacked on roughly the same kind of timescale as other RPKI keys,
so if the revocation mechanism is good enough for everything else,
it's probably good enough for router keys.  YMMV.

> be in the -overview document which I've yet to read.)

It's sort of in RFC 6810 (rpki-rtr).  The update to RFC 6810 is
stalled because I dropped the ball last year.

> Not sure about a layering violation but I can see it'd likely be

I had front-row tickets to the "let's stuff routing policy data into
the DNS!" show back in the '90s.  My main take-away from that mess was
a fear of real-time circular dependencies.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 4 Jan 2017 23:11:48 +0000

Hiya,

> the ability to enforce that, hence the text you note in RFC 6487.

I'd say any concerns that the web PKI CAs might have had ought
now be ameliorated (or OBE, give letsencrypt), so not trodding
on mainstream CA business is probably not as much as concern
as was the case at the start of the RPKI work.

> excessive, but that's not the document currently under discussion.

Well, except that this draft does re-iterate some of those now
clearly weird MUSTs.

Fair point.

So assuming there isn't a chorus of WG participants asking to
remove the weird constraints then I'd say the right thing must
be to not re-iterate any weirdness from 6487 but to only inherit
that by reference. That way, if/when we modify 6487, we won't
have to do the same with this, and maybe also hit problems
with these constraints being enforced by code in two places.

I think the only such text I saw (that re-iterates 6487) was
in 3.1.1 but there might I guess be more.

> it's probably good enough for router keys.  YMMV.

Fair enough. Again, assuming that there's no chorus wanting
change, I'll clear this point as well.

Cheers,
S.

---

From: Sean Turner <[email-masked]>
Date: Wed, 4 Jan 2017 18:56:54 -0500

Jumping here

> On Jan 4, 2017, at 18:11, Stephen Farrell <[email-masked]> wrote:
> 
> Hiya,
> 

> break in BGPsec if that rule is omitted, but maybe I'm

This might OBE based on the hack/burn of this section, but are you talking about the last sentence?

>>  RPKI profile: same overall goal, slightly different constraints.

Yep that’s it: constraining the constrained.

>> trying to sub-profile a profile with a known wart like this.

The only thing I want to what Rob has mentioned is that this constraint to use common name and serial number has been around since mid-2011.  In contrast to many other groups I’ve worked with there was no desire to support everything and the kitchen sink only to find out later that there were a whole lot of implementation pitfalls to be had with T61String, BMPString, or how IDNA2008 vs IDNA2003 might affect comparisons.  I remember trying to get people to provide input to tell me that more was needed, I gave up at some point because all I got in response was crickets.  Now that might have been for a lot of reasons, but I/we certainly asked.

> in 3.1.1 but there might I guess be more.

That text has basically been unchanged since the -01 of the individual draft circa 2011.  I can have a look at 3.1.1 and scrub out what’s repeated from 6487, but then I’ll get a chorus of “but there’s no context, I can’t understand it.” But, to get through this hurdle, what I think we’re talking about is deleting the first sentence and everything after “note”, i.e., 

   Common name encoding options that are supported are
   printableString and UTF8String.  For BGPsec Router Certificates, it
   is RECOMMENDED that the common name attribute contain the literal
   string "ROUTER-" followed by the 32-bit AS Number [RFC3779] encoded
   as eight hexadecimal digits and that the serial number attribute
   contain the 32-bit BGP Identifier [RFC4271] (i.e., the router ID)
   encoded as eight hexadecimal digits.  If there is more than one AS
   number, the choice of which to include in the common name is at the
   discretion of the Issuer. If the same certificate is issued to more
   than one router (hence the private key is shared among these
   routers), the choice of the router ID used in this name is at the
   discretion of the Issuer.

> change, I'll clear this point as well.

Again, definitely no chorus or even drunk carolers :)

spt

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 5 Jan 2017 00:19:45 +0000

Hiya,

Yep, I guess the text below is good enough.

Thanks,
S.

---

From: Sean Turner <[email-masked]>
Date: Wed, 4 Jan 2017 19:34:48 -0500

Gahhhh … so that’s a little tortured; it’s a continuation of the whole “these certs don’t really affect the rest of the RPKI".  How about:

BGPsec Router Certificates are used only to verify the signature on the BGPsec certificate request (only CAs process these) and the signature on a BGPsec Update Message [ID.sidr-bgpsec-protocol] (only BGPsec routers process these); BGPsec Router Certificates are not used to process Manifests and ROAs or verify signatures on Certificates or CRLs.

> don't add the direct ref to 6487 to the BGPsec protocol

Wait, I thought I wasn’t supposed to duplicate any of the crazy stuff from 6487 :)

spt

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 5 Jan 2017 00:39:25 +0000

Hiya,

>> of BGPsec Router Certificates in no way affects RPKI RPs that
>> process Manifests and ROAs because the public key found in the
>> BGPsec Router Certificate is used only to verify the signature on
>> the BGPsec certificate request (only CAs process these) and the
>> signature on a BGPsec Update Message [ID.sidr-bgpsec-protocol]
>> (only BGPsec routers process these)." Do you mean that there's no
>> way that an entity can confuse a Manifest, ROA, CSR or BGPsec 
>> update so there's no issue with which public keys are used to
>> verify the signatures on those data structures?
> 
> Gahhhh … so that’s a little tortured; it’s a continuation of the
> whole “these certs don’t really affect the rest of the RPKI".  How
> about:
> 
> BGPsec Router Certificates are used only to verify the signature on
> the BGPsec certificate request (only CAs process these) and the
> signature on a BGPsec Update Message [ID.sidr-bgpsec-protocol] (only
> BGPsec routers process these); BGPsec Router Certificates are not
> used to process Manifests and ROAs or verify signatures on
> Certificates or CRLs.

Yep, better.

> 
>> - section 3: As noted in my comments on the BGPsec protocol, it'd
>> be better to call out the SKI here if you don't add the direct ref
>> to 6487 to the BGPsec protocol draft.
> 

Well, this is describing a different PDU though:-) But yeah, better
if the protocol spec points direct to 6487 direct.

Cheers,
S.

---

From: Sean Turner <[email-masked]>
Date: Wed, 4 Jan 2017 19:40:15 -0500

> On Jan 4, 2017, at 19:39, Stephen Farrell <[email-masked]> wrote:
> 
> 
> Hiya,
> 

Incorporated in my editor’s copy.

spt

---

From: Sean Turner <[email-masked]>
Date: Wed, 4 Jan 2017 19:40:34 -0500

In my editor’s copy.

spt

> On Jan 4, 2017, at 19:19, Stephen Farrell <[email-masked]> wrote:
> 
> 
> Hiya,
>

---

From: Randy Bush <[email-masked]>
Date: Thu, 05 Jan 2017 15:57:02 +0900

> Wait, I thought I wasn’t supposed to duplicate any of the crazy stuff

duplication opens to errors in copying and makes later changes messier

randy