Subject: [sidr] Terry Manderson's Discuss on draft-ietf-sidr-rpsl-sig-11: (with DISCUSS and COMMENT)

From: "Terry Manderson" <[email-masked]>
Date: Tue, 17 May 2016 20:37:54 -0700

Terry Manderson has entered the following ballot position for
draft-ietf-sidr-rpsl-sig-11: 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-rpsl-sig/

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

Thank you for putting substantial effort into this document.

I have a few discusses. I hope they can be resolved quickly.

In Section 2.1. The reference to the aligned certificate  which has the
same private key that signed the RPSL object is mandatory, and defined by
a RSYNC URL or a HTTP(S) URL. My question surrounds the "or". The
architecture of RPKI (IIRC) is centered around RSYNC, and thus SIA/AIA
values MUST have a RSYNC URL, and MAY have other types. By this are you
leaving it to the issuing party to control the RPKI Distribution
mechanisms of the Replying Party? I am quite comfortable with "or"
personally, however this facet of fetching the RPSL Certificate to
validate the private key usage is seemingly orthogonal to the RPKI
architecture of RSYNC preferred and should be called out if 'or' is the
clear intention. Or, has the consensus of the WG moved on from being
wedded to RSYNC?

If it is truely "or", my observation is that the use of the RPKI
repository is one of  convenience, and that should be called out, in fact
it does appear that any valid certificate bearing RFC3779 extensions
could be used to validate the digital signature associated with the RPSL
object provided the relying party has trust anchor material that leads to
the corresponding EE certificate and therefore private key. Is this
observation correct?

The Signature expiration time field ("x") currently has no time
constraints, and I'm very surprised that it is optional with the text in
s2.5, given that the expiration time, by my reading, could not be beyond
the 'not after' time of the corresponding certificate. Can you please
instruct me as to what the consensus position on this was? A criticism of
many IRRs is that data becomes stale. have the signature expiration time
field could aide in data freshness models and reduce load on automated
import and validation of these RPSL signatures.

And lastly, IRRs tend to run over the (legacy?) whois port 43 that
doesn't provide channel layer security. This means that while signature
provide a means of detecting modification it may not stop a a MiTM event
where the entire object is omitted. Do you agree? if so that might be
appropriate for the Security Considerations section.

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

one nit:

"MUST reject the signature and threat the object as a regular" I think
you mean `s/threat/treat`

Misc comments:

* Thank you for the very clear canonicalisation requirements!

* For route6 objects, where two resource holder's signatures considered
such that it might address the inability to properly sign the RPSL when
one holder possesses the ASN and another possesses the prefix? (just a
comment, nothing more)

---

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

Hi Terry,

> https://datatracker.ietf.org/doc/draft-ietf-sidr-rpsl-sig/

I am not aware of the WG moving away from their rsync leanings...

> the corresponding EE certificate and therefore private key. Is this

You are correct that the use of the RPKI repository is one of
convenience. My original implementation of this approach used non-RPKI
certificates. I would be fine with putting a statement in the
Introduction along the lines of:

"While the approach outlined in this document mandates the use of the
RPKI for certificate distribution, it is not dependent upon the RPKI for
correct functionality. Equivalent functionality can be achieved with a
more traditional certificate authority, RFC 3779 extensions within the
certificates, and the appropriate trust anchor material to verify the
digital signature."

> import and validation of these RPSL signatures.

The validity of the signature is driven by the notAfter field of the
certificate described in 6487. My implementation does the validation
based on notAfter regardless of what is included in the "x" field. I
view "x" as a simple way for RPSL object signers to indicate the
lifetime, but not the authoritative way.

> appropriate for the Security Considerations section.

I agree with the potential MiTM attack described, but view that as
orthogonal to digital signatures providing integrity protection. This
type of attack could easily occur regardless of whether objects are
signed or not.

Fixed in my pending edit buffer.

> one holder possesses the ASN and another possesses the prefix? (just a

Not sure I can parse the above unless s/where/were/... If so, that was
originally in the document prior to -09, but the consensus of the WG was
to remove multiple signature support.

Regards,
Brian

---

From: Tim Bruijnzeels <[email-masked]>
Date: Wed, 18 May 2016 16:32:42 +0200

Hi,

> On 18 May 2016, at 15:08, Brian Haberman <[email-masked]> wrote:
> 
> Hi Terry,
> 

My take on this: for the moment I would stick to rsync as it's required and EE certificates appearing in the rsync repository, and leave out http(s).

Work is being done on RRDP. In time this may replace rsync altogether. This is speculation at this time, but.. one way to look at this could be to have AKI and a reference to a TA or an RRDP publication point (notification file) where the signing EE certificate is supposed to be found. Just shooting from the hip here, bottom line: this is a discussion and decision for a later time, and is probably best addressed in a -bis.

Tim

---

From: Brian Haberman <[email-masked]>
Date: Wed, 18 May 2016 11:02:55 -0400

Hi Tim,

On 5/18/16 10:32 AM, Tim Bruijnzeels wrote:
>>> 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-rpsl-sig/
>>> 
>>> 
>>> 
>>> In Section 2.1. The reference to the aligned certificate  which
>>> has the same private key that signed the RPSL object is
>>> mandatory, and defined by a RSYNC URL or a HTTP(S) URL. My
>>> question surrounds the "or". The architecture of RPKI (IIRC) is
>>> centered around RSYNC, and thus SIA/AIA values MUST have a RSYNC
>>> URL, and MAY have other types. By this are you leaving it to the
>>> issuing party to control the RPKI Distribution mechanisms of the
>>> Replying Party? I am quite comfortable with "or" personally,
>>> however this facet of fetching the RPSL Certificate to validate
>>> the private key usage is seemingly orthogonal to the RPKI 
>>> architecture of RSYNC preferred and should be called out if 'or'
>>> is the clear intention. Or, has the consensus of the WG moved on
>>> from being wedded to RSYNC?
>> 
> My take on this: for the moment I would stick to rsync as it's
> required and EE certificates appearing in the rsync repository, and
> leave out http(s).
> 

If the consensus is to remove mention of an http(s) URI, I can live with
that. The current state of affairs within the SIDR documentation is such
that only an rsync URI will be feasible in the near future. I don't
believe that the mention of an http(s) URI in this context affects that
one way or the other.

Regards,
Brian

---

From: George Michaelson <[email-masked]>
Date: Thu, 19 May 2016 08:39:09 +1000

I would rather the sigs were signed by ee certs which were in the
blob, than have to make an external reference and I would rather we
varied the compliance needs to remove a pointless external ref.

If there has to be a ref, I think making it mandated to a specific
scheme is over specifying, especially in a context where we might
begin to understand *where you get cryptographic materials from is
less important than proving who said them*.

Rsync is a bad fit. for the actual signing cert, Inline is better. It
can refer to whatever chain it likes.

-G

On Thu, May 19, 2016 at 1:02 AM, Brian Haberman
<[email-masked]> wrote:
> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr
>

---

From: Terry Manderson <[email-masked]>
Date: Thu, 19 May 2016 04:07:07 +0000

Hi Brian,

>certificates, and the appropriate trust anchor material to verify the

That is a fine snippet to include. Thank you.

>lifetime, but not the authoritative way.

Understood. I was considering a more operational triage of the signed
objects prior to validation.
But in reflection that can introduce an unintentional error situation. Put
aside this item.

>type of attack could easily occur regardless of whether objects are

Correct. I raise the point so that people who implement and/or use
rpsl-sig do not accidentally assume that by adding a signature some form
of magic happens that unreservedly protects the object - you can take this
now as 'comment' fodder.

>Fixed in my pending edit buffer.

Thanks

>to remove multiple signature support.

Yes, I typo'd. 

Thanks for the info on the WG consensus for multiple signature support.

I'll clear my discuss shortly.

Cheers
Terry

---

From: Tim Bruijnzeels <[email-masked]>
Date: Thu, 19 May 2016 09:43:27 +0200

Hi all,

Actually, yes, I agree with George on in-line.

In-line would have my preference. Include the entire EE certificate in the signature field. This way it does not need to be fetched separately, and it does not need to appear in a repository or a manifest. Mandate that the EE certificate is signed by CA certificate in the RPKI (i.e. no longer chain possible). The EE certificate should have an AIA and AKI that can then be easily referenced against known CA certificates that a validator found.

So in short: a validator can do its normal top-down validation for a TA. And to perform bottom-up validation of a signed RPSL object the process of validating the EE cert would be fairly simple -> find a CA cert with SKI matching the AKI of the EE, verify the signature of the EE (proof of possession), verify the CRL. Omitting the other checks here - would be good to specify this explicitly in the document, but for the discussion here seems excessive.

I think there was some discussion around this earlier and back then the thought was that we wouldn't want to make the RPSL objects bigger. However, I don't know if that should be a concern. The way I see it looking at our own whois implementation I imagine that this field could actually only be shown to RPs when they supply an additional flag, if size is a concern. And in our web UI (ad-hoc queries by humans) we would not show the signature field as is, but process it and highlight signed fields somehow.

Tim

> On 19 May 2016, at 00:39, George Michaelson <[email-masked]> wrote:
>

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 19 May 2016 10:31:01 +0100

On 19/05/16 08:43, Tim Bruijnzeels wrote:
> In-line would have my preference. Include the entire EE certificate
> in the signature field. This way it does not need to be fetched
> separately, and it does not need to appear in a repository or a
> manifest. Mandate that the EE certificate is signed by CA certificate
> in the RPKI (i.e. no longer chain possible). The EE certificate
> should have an AIA and AKI that can then be easily referenced against
> known CA certificates that a validator found.

Were I designing that I'd have a separate new attribute that
could contain one or more certs and I'd say that if the c=
field/URI in the signature attribute is empty (or has some
specified value such as "inband") then that means "look
at the cert-bucket attribute in this file."

The cert-bucket would then be expected to contain a base64
encoded cert chain. Consumers of that attribute would have
to ensure that nothing in it affects the local trust point
store but can otherwise throw the lot into their cert path
processing engine.

Assuming that the signatures on these files aren't very
long-lived you can probably input the cert-bucket attribute
into the signature. If signatures commonly need to be ok
to verify even after certificate expiry (e.g. if a new
cert was issued for the same key pair in an update operation)
then you'd not want the cert-bucket in the signature maybe.

There're various non-compelling but goodish reasons to do it
that way. Maybe the best ones are around making it easy to
use existing tooling (openssl etc) for the verifier.

I'm not sure what benefit ensues from insisting that the EE
cert very strictly adhere to all ithe RPKI rules, but I
reckon you do want to be able to use the same PKI for sure.
So were it me, I'd try craft text saying "you're very likely
to want to use an RPKI CA for issuing the cert used to
verify the signature attribute so your code MUST support
doing that, but there can be other equally standard PKI
options too that are useful to support."

> 
> So in short: a validator can do its normal top-down validation for a
> TA. And to perform bottom-up validation of a signed RPSL object the
> process of validating the EE cert would be fairly simple -> find a CA
> cert with SKI matching the AKI of the EE, verify the signature of the
> EE (proof of possession), verify the CRL. Omitting the other checks
> here - would be good to specify this explicitly in the document, but
> for the discussion here seems excessive.

Yep.

Cheers,
S.

> 
> I think there was some discussion around this earlier and back then
> the thought was that we wouldn't want to make the RPSL objects
> bigger. However, I don't know if that should be a concern. The way I
> see it looking at our own whois implementation I imagine that this
> field could actually only be shown to RPs when they supply an
> additional flag, if size is a concern. And in our web UI (ad-hoc
> queries by humans) we would not show the signature field as is, but
> process it and highlight signed fields somehow.
> 
> Tim
> 
> 
>> blob, than have to make an external reference and I would rather
>> we varied the compliance needs to remove a pointless external ref.
>> 
>> Rsync is a bad fit. for the actual signing cert, Inline is better.
>> It can refer to whatever chain it likes.
>> 
>> -G
>> 
>>>>>> Terry Manderson has entered the following ballot position
>>>>>> for draft-ietf-sidr-rpsl-sig-11: 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
>>>>>> In Section 2.1. The reference to the aligned certificate
>>>>>> which has the same private key that signed the RPSL object
>>>>>> is mandatory, and defined by a RSYNC URL or a HTTP(S) URL.
>>>>>> My question surrounds the "or". The architecture of RPKI
>>>>>> (IIRC) is centered around RSYNC, and thus SIA/AIA values
>>>>>> MUST have a RSYNC URL, and MAY have other types. By this
>>>>>> are you leaving it to the issuing party to control the RPKI
>>>>>> Distribution mechanisms of the Replying Party? I am quite
>>>>>> comfortable with "or" personally, however this facet of
>>>>>> fetching the RPSL Certificate to validate the private key
>>>>>> usage is seemingly orthogonal to the RPKI architecture of
>>>>>> RSYNC preferred and should be called out if 'or' is the
>>>>>> clear intention. Or, has the consensus of the WG moved on 
>>>> required and EE certificates appearing in the rsync repository,
>>>> and leave out http(s).
>>>> 
>>> 
>>> If the consensus is to remove mention of an http(s) URI, I can
>>> live with that. The current state of affairs within the SIDR
>>> documentation is such that only an rsync URI will be feasible in
>>> the near future. I don't believe that the mention of an http(s)
>>> URI in this context affects that one way or the other.
>>> 
>>> Regards, Brian
>>> 
>>> 
>>> 
>>> _______________________________________________ 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: Robert Kisteleki <[email-masked]>
Date: Fri, 20 May 2016 13:32:39 +0200

Chiming it late...

> can refer to whatever chain it likes.

In the good ol' days a reference was put in because while the signature
itself is relatively small, including the full EE cert would bloat the whole
RPSL object to potentially multiple times its original size -- and for those
who don't care about signatures this is a huge overhead. Furthermore, if one
would reuse EE certs in multiple signatures (I don't see why that would be
prohibited -- for example if I want to sign multiple objects at the same
time), then this method makes even more sense.

Then the whole back-and-forth started about whether it should be rsync or
http(s) and now perhaps it's neither. It feels like we're going around in
circles here :)

Robert

---

From: Stephen Kent <[email-masked]>
Date: Fri, 20 May 2016 08:53:14 -0400

George,

I agree that it's more convenient to have the EE cert close to the
RPSL data being verified. Just so long as RPs use the RPKI to acquire
the cert path info, revocation status info, etc.

Steve

---

From: Tim Bruijnzeels <[email-masked]>
Date: Fri, 20 May 2016 16:18:19 +0200

Hi Robert, all,

> On 20 May 2016, at 13:32, Robert Kisteleki <[email-masked]> wrote:
> 
> Chiming it late...
> 

Let me attempt a different angle. I think a more fundamental question is whether we would expect this EE certificate a) to appear in the normal RPKI repository as one of the signed products of a CA, and appear on the manifest - or b) to be an embedded certificate, or c) that it can be a detached EE certificate that lives elsewhere, but is validated against a signing CA cert and CRL that do live in the 'normal' RPKI repository.

Currently looking at the document it's not clear to me whether 'a' or 'c' is intended. My preference however is 'b'.

if a) in the normal RPKI

Then I think we should stick to rsync as it's currently required for all RPKI certificates. Even if using RRDP, we still have the rsync URIs as a hint in the XML so we can find the certificate.

If this is the way, then there are some amendments needed to profile and repository standards - as discussed in the thread - let me not repeat here. Currently deployed RPs *will* choke on this. So this option does not have my preference.

if b) embedded

I prefer this approach because it makes it easier to specify the certificate and define validation in the RPSL-SIG document, and it has no impact on RPKI deployment. If you like I can suggest text..

And if you want to multi-use and fate-share (indeed I think this is generally an easy way to shoot in one's own foot, and don't see optimisation by doing this), you can just embed the same certificate. As I stated in my response to George I am not convinced that the size is problematic. I think we can filter this if we must.

In response to Stephen's suggestion to use another attribute for the certificate: I prefer not to. The reason is that we would have to introduce two new optional attributes that need to appear in conjunction, and I believe this makes it unnecessarily difficult to implement RPSL object validation and attribute filtering. The value of the 'signature' attribute is well-defined and needs to be parsed anyway, so adding an element to contain the certificate does not seem problematic to me.

if c) third location

I believe this is the worst option. Having random third locations to retrieve the EE certificates over http(s) or rsync, different from the RPKI repository itself and from where the RPSL objects are retrieved introduces a lot of overhead for both RPs and publishers, and introduces a potential for failure to retrieve.

> http(s) and now perhaps it's neither. It feels like we're going around in

Yep, you have my sympathy and I am sorry for not engaging more actively earlier.

We found this and the concerns raised by Tom when we worked on an inter-operating proof of concept implementation recently. On a positive note, as a general concept we found this works. It's really about where to find EE cert, and how to relate it to a CA certificate and CRL in the existing RPKI.