Subject: Re: [sidr] Last Call: <draft-ietf-sidr-rpsl-sig-10.txt> (Securing RPSL Objects with RPKI Signatures) to Proposed Standard

From: Brian Haberman <[email-masked]>
Date: Wed, 11 May 2016 09:08:43 -0400

Hi Tom,
     Thanks for the in-depth review and your efforts in creating another
implementation of this draft. Responses to your comments are below...

On 4/28/16 6:54 PM, Tom Harrison wrote:
> Section 5 requires that an EE certificate be used for the signing of
> the RPSL object.  An EE certificate must contain an SIA extension that
> points to an RPKI signed object (RFC 6487 [4.8.8.2]).  The draft does
> not define a profile for a new type of object, or specify an existing
> one that may be used instead.  There are a number of ways to deal with
> this: for example, by defining a new profile and changing the
> signature URL to suit, or by amending RFC 6487 such that object
> pointers in EE certificates are optional.

I would propose adding some text to this draft (probably as a
sub-section in section 2) that says that the SIA defined in RFC 6487 is
omitted when a certificate is used to sign RPSL objects. Given the
single-use nature of the key-pair (section 3.2, point #1), omitting the
SIA is straightforward.

> 
> Section 4 specifies sets of attributes that must be signed.  'org' is
> included as one of these attributes for the as-block, inet[6]num, and
> route[6] object types.  However, 'org' is not defined in either of the
> principal RPSL RFCs (2622 and 4012), and there are current
> implementations (e.g. APNIC's) that do not support it.  I think the
> references to 'org' should be omitted.

Agreed. I will remove 'org' from the listed objects.

> 
> Section 4 specifies 'signature' as an attribute that must be signed.
> 'signature' can appear multiple times in a single object, where e.g.
> two different resource holders sign a route[6] object.  Given that the
> text doesn't explicitly state that only the newest 'signature' must be
> signed, it would appear to require that any extant 'signature'
> attributes be signed as well.  That in turn would prevent previous
> signers from re-signing the object independently of the subsequent
> signers.  I think the text should be changed so that only the new
> signature attribute need be signed.

Agreed. I will update the text to explicitly refer to the signature
currently under construction.

> 
> Section 2.4 requires that "the Internet number resources present in
> [RFC3779] extensions of the certificate referred to in the "c" field
> of the signature must cover the resources in the primary key of the
> object".  This means that it's not possible to sign a route[6] object
> for a route where one resource holder has the ASN and another the
> prefix.  In revision 8 (and earlier), the possibility of there being
> multiple signatures, each with a certificate covering a subset of the
> primary key resources, was explicitly permitted.  I think that the
> previous text here should be restored.

I agree that the original text allowing multiple signatures supports the
case where the components of the primary key of the object (i.e.,
prefix+ASN) come from different resource holders. I will restore that text.

> 
> (The above points were the product of much discussion of this draft
> with Tim and Oleg from RIPE, not that I'm speaking for them.  We were
> able to write interoperable prototype signer/validator
> implementations, so the document is in pretty good shape on the
> whole.)

Thanks! Glad to hear this.

Regards,
Brian

---

From: Randy Bush <[email-masked]>
Date: Wed, 11 May 2016 18:42:25 +0200

> omitted when a certificate is used to sign RPSL objects.

perhaps you might also include your reasoning for this seemingly odd
choice.

> I agree that the original text allowing multiple signatures supports
> the case where the components of the primary key of the object (i.e.,

this is gonna be really simple; no complications at all i am sure.

btw, was this a consensus of the wg?

randy

---

From: Brian Haberman <[email-masked]>
Date: Wed, 11 May 2016 12:56:53 -0400

Hi Randy,

> perhaps you might also include your reasoning for this seemingly odd

The SIA in 6487 mandates an rsync URI that points to the object that is
signed with the certificate. I am not aware of any RPSL servers that
support referencing an RPSL object via rsync.

> btw, was this a consensus of the wg?

The original draft supported multiple signature attributes. During WG
review (WGLC?, don't recall), several people suggested simplifying the
approach by only allowing one signature attribute. Given the route[6]
example, we need multiple signatures modulo the proposed text to clarify
the handling/generation of those signatures.

Regards,
Brian

---

From: Sandra Murphy <[email-masked]>
Date: Wed, 11 May 2016 15:04:58 -0400

Speaking as regular ol’ wg member

(I took the ietf off the cc list  - I intended this as a sidr discussion, not an ietf discussion.)

> single-use nature of the key-pair (section 3.2, point #1), omitting the

wrt Tom’s comment:

It is certainly the case that currently existing EE certificates in the RPKI appear in RPKI Signed Objects (i.e. instances of RFC6488) - manifests, ghostbuster records, ROAs.  But these aren’t the only possible use of EE certificates - the architecture RFC6480 mentions that there might be other uses of EE certificates.

And it is certainly the case that there’s been no intent in this work to put signed RPSL objects into the RPKI repositories.

wrt Brian’s suggestion:

A similar example:  The router certificates draft also omits the SIA field for router EE certificates - probably for similar reasons.

> support referencing an RPSL object via rsync.

“A small matter of programming” - an RPSL database operator could find a way to format an rsync URL so that it could be translated on receipt to a database object retrieval. ( :-)  ?  )

A new type of EE cert does sound cleaner.  It puts the burden on the RPKI implementer rather than the RPSL database operators, of course.  I am not an implementer nor operator.

—Sandy, speaking as regular ol’ working group member

---

From: Sandra Murphy <[email-masked]>
Date: Wed, 11 May 2016 15:09:50 -0400

speaking as one of the wg co-chairs

> single-use nature of the key-pair (section 3.2, point #1), omitting the

Speaking as one of the wg co chairs:

You are suggesting much the same as draft-ietf-sidr-bgpsec-pki-profiles - defining a new EE cert profile.

This draft would have to say that it is updating RFC6485(bis).

Which means making clear what the additions/modification/deletions are.

So that implementations know how to interpret these new certs when they find them in some repository, it must be possible to distinguish these new EE certs from other EE certs.

Etc.

And the wg would have to agree on the changes.

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

---

From: Randy Bush <[email-masked]>
Date: Thu, 12 May 2016 13:22:45 +0200

> the handling/generation of those signatures.

i.e. it was not wg consensus but you think you should do it anyway?

randy

---

From: Tim Bruijnzeels <[email-masked]>
Date: Thu, 12 May 2016 13:29:37 +0200

> On 12 May 2016, at 13:22, Randy Bush <[email-masked]> wrote:
> 

First off: I am sorry for arriving late to this party with my comments.

But regardless of process. For this to be useful for route objects we need two signatures in cases where the AS and prefix are held by different parties.

If the current text can't be modified, my guess is that a bis could be another option.

On another note: I think RPSL signatures on route objects add relatively little value - I would advise people to use ROAs instead. But the ability to sign over import/export in aut-num objects, or contact information/remarks etc in inetnum object to name two examples is useful, and only requires one signature.

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

---

From: Randy Bush <[email-masked]>
Date: Thu, 12 May 2016 13:33:57 +0200

> But regardless of process. For this to be useful for route objects we
> need two signatures in cases where the AS and prefix are held by
> different parties.

then we have misplaced this whole discussion.  it is really about using
rpki keys to sign rpsl data willy-nilly, as opposed to using the rpki
infrastructure.

the rpki-based origin validation and bgpsec models specifically do not
authenticate the authority of an AS.  the AS does that by announcing.

i happen to be in the building having post lunch coffee.  wanna chat
face to face?  bring clue bat.

randy

---

From: Rob Austein <[email-masked]>
Date: Thu, 12 May 2016 08:11:29 -0400

At Wed, 11 May 2016 15:04:58 -0400, Sandra Murphy wrote:
...
> A new type of EE cert does sound cleaner.  It puts the burden on the
RPKI implementer rather than the RPSL database operators, of course.

We already have precedent and mechanism for adding
application-specific EE certificates: assign a new EKU OID, write a
profile, make sure that the profile requires the new EKU and specifies
all deviations from the base certificate profile.  This is what we did
with router certificates.

As with router certificates, this means that RP code that doesn't know
about the new flavor of EE certificates won't allow them.  This is by
design: we don't accept RPKI objects with unknown semantics.

---

From: Sandra Murphy <[email-masked]>
Date: Fri, 13 May 2016 06:02:11 -0400

I’ve made an error in reference.  Going back through to correct.

> This draft would have to say that it is updating RFC6485(bis).

RFC6485 -> RFC6487.

RFC6485 is about algorithms.  RFC6487 is the document about RPKI certificates.

Sorry for the confusion.

—Sandy