Subject: [sidr] working group adoption poll for draft-huston-sidr-rfc6490-bis

From: "Murphy, Sandra" <[email-masked]>
Date: Fri, 7 Feb 2014 19:47:46 +0000

The authors of "draft-ietf-sidr-multiple-publication-points" proposed a new direction for that draft that included:

- A "6490-bis" document that obsoletes RFC 6490 with the addition of multiple operators in section 3 of the current document.

The wg having consented to that approach, the authors of RFC6490 produced a new draft draft-huston-sidr-rfc6490-bis that would serve as the 6490-bis.

The authors of draft-huston-sidr-rfc6490-bis have requested that the wg adopt this draft as a working group work item.

See http://tools.ietf.org/html/draft-huston-sidr-rfc6490-bis-00, "Resource Certificate PKI (RPKI) Trust Anchor Locator".

Please do respond to the list as to whether you support the wg adopting this as a work item.  Note that you do not need to comment on the content of this draft at this time.  You are asked to indicate if you think that this is work that the wg should be doing and whether this draft is an acceptable starting point.  Adding whether you can/will review or not is useful.

This adoption poll will end on Friday, 21 February, 2014.

--Sandy, speaking as wg co-chair

---

From: Randy Bush <[email-masked]>
Date: Sat, 08 Feb 2014 13:21:06 +0900

i think this is a worthwhile effort and this document is a good place to
start.

--

presuming there is consensus to adopt, i have some some nits we can
discuss when it is a wg item.

  o i thought folk wanted a blank line between the URI(s) and the key

  o last para of 2.2 says

       Where the TAL contains two or more rsync URIs, then the same
       self-signed CA certificate MUST be found at each referenced
       location.

    maybe should say what happens when one or more do not have the same
    cert?  does the whole TAL get ignored?

  o same last para of 2.2

       it is RECOMMENDED that the domain name parts of each of these
       URIs resolve to distinct IP addresses that are used by a diverse
       set of repository publication points, and these IP addresses be
       included in distinct Route Origination Authorizations (ROAs)
       objects signed by different CAs.

    as this is ops guidance, and really the core of the proposed change,
    perhaps the rationale for this should be given

  o 3.1 

       Retrieve the object referenced by (one of) the URI(s) contained
       in the TAL.

    you may want to give some guidance as to which one.  pseudo-random?
    first?  think load balancing, proximity, ..., a la dns

and then there are the questions folk have been raising about
consistency, etc., which i will leave to them.

randy

---

From: Tim Bruijnzeels <[email-masked]>
Date: Sat, 8 Feb 2014 14:14:12 +0100

> i think this is a worthwhile effort and this document is a good place to

+1

Some initial comments in-line.

I am not sure that I care too much about this as long as it's well defined.

But if the format is open to change, then I would feel more for a key=value style, or dare I say even json.. this is parsed by the machines after all. And using something like json makes it much more flexible regarding ordering of elements, or extending should that ever be necessary.

>    cert?  does the whole TAL get ignored?

I agree, but on top of that having multiple publication points by definition implies that there will be differences, albeit short lived.

I would like to see wording along these lines.
= TA MUST increment serial number whenever they re-issue the CA cert
= TA SHOULD* publish the CA cert in all locations 'asap', within 1 hour?
= TA SHOULD* remove the cert from unmaintained locations
  *: They may not be able to if this is hosted at a third party

To handle all this more elegantly I think there should be a mechanism for TAs to publish replacement TALs. To add, or remove URIs, or even to do planned key rolls (for example: TA wants change HSM vendor). What if the TA could optionally publish one (1) signed object containing an updated TAL? And possibly some dates: do-not-use-this-before, and do-not-use-other-after?

This would allow RPs to use existing TALs to discover updates and process automatically (it is signed by the key that I trust). It could stop re-trying retired URIs, and start using the new ones. And even planned key rolls could be as simple as this on this level (provided the TA re-issues and publishes all the products before the change date, under the new key and in its own repositories).

>    first?  think load balancing, proximity, ..., a la fns

I like to see some guidance, but ultimately I think the RP should be allowed to choose a strategy.

I would probably prefer to check all URIs regularly, and go with the certificate with the highest serial number (provided the key matches of course).

Tim

---

From: Geoff Huston <[email-masked]>
Date: Mon, 10 Feb 2014 09:05:39 +1100

Hi,

I took the text n draft-ietf-sidr-multiple-publication-points as it related to TAs and placed it into the RFC6490bis draft without change.

The syntax of the TAL is not something I care a lot about either - I suppose that one could get worried about rogue TA:s that try to place 1 million  URIs into the TAL, and get into the whole JSON / plain ascii thing - I thought that the draft-ietf-sidr-multiple-publication-points document already had a certain level of WG buy-in behind it - I guess that was not a very good assumption on my part. I'll happily add what the WG wants here.

The issue about multiple CA certs that are different was something the earlier draft was silent about. They simply said that they MUST be the same and left it at that. I'm not sure how critical an issue this is, and whet forms of additional mechanism are necessary to allow RPs to retrieve all the referenced CA certs and define an algorithm for them to follow to select the "best". My simplistic thinking about the original intent in draft-ietf-sidr-multiple-publication-points was that an RP would pick oine URI, and if that was unresponsive after some local threshold it wuould try another, and so on. The discussion so far has been based on an assumption that an RP would retrieve the CA cert from 2 or more URI's and then worry about the case where the URIs differ. I am not sure what to add here to the draft - the WG will need to provide further guidance on this. I worry about a proposal for RPs to check all URIs - it seems to me to be adding to the total load and I'm then not sure where the benefit of multiple URIs in TAs comes from in such a scenario.

Finally, the issue obout URI diversity was again taken from teh original text and I had assumed that the WG had already considered this. 

regards,

   Geoff

On 9 Feb 2014, at 12:14 am, Tim Bruijnzeels <[email-masked]> wrote:

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

---

From: Randy Bush <[email-masked]>
Date: Mon, 10 Feb 2014 11:22:05 +0900

[ this discussion is not to be taken as questioning if the draft should
  be adopted by the wg.  i have already advocated for adoption.  we're
  now in the post-adoption discussion :) ]

> But if the format is open to change, then I would feel more for a
> key=value style, or dare I say even json.. this is parsed by the
> machines after all.

the assumption that json is a universally, or even widely, implemented
format is not well founded.  let's not get carried away into lala land.
we're just trying to allow multiple uris in a tal.

> I agree, but on top of that having multiple publication points by
> definition implies that there will be differences, albeit short lived.

huh?  a difference in the cert's key between the tal and the repository
is a major error.  the question i asked was if we should/could give some
guidance on how to deal with it.

>   *: They may not be able to if this is hosted at a third party'

i suspect many of those "TA"s are "CA"s.

operationally, how do you remove something from an unmaintained
location irrespective of who does not maintain it.  maybe you mean
remove the uri from the tal?

as it is the key, not the cert, which must match, i am not sure how
critical this all is.  and if the key changes, you have entered the
world of key roll, and i suspect we don't want to go there this week.

> To handle all this more elegantly I think there should be a mechanism
> for TAs to publish replacement TALs. To add, or remove URIs, or even
> to do planned key rolls (for example: TA wants change HSM vendor).
> What if the TA could optionally publish one (1) signed object
> containing an updated TAL? And possibly some dates:
> do-not-use-this-before, and do-not-use-other-after?

major expand-a-project.  not if you want this draft finished in 2014.

> allowed to choose a strategy.

that is one approach

> I would probably prefer to check all URIs regularly, and go with the
> certificate with the highest serial number (provided the key matches
> of course).

so the rp is to chase them all?  how often.  when three uris have the
same serial, which do you choose?  and perhaps we should recommend going
with the uri which points to a cert with a serial which matches that in
the tal?

but mainly, i think it would be good to give some guidance.

randy

---

From: "Roque Gagliano (rogaglia)" <[email-masked]>
Date: Mon, 10 Feb 2014 16:06:42 +0000

Sandy,

I support the addition of multiple publication points as working group item and hope to go quickly through the process.

Roque

--------------------
Initial Comments:

Section 2.1
(Roque) We received the request from the WG to add a blank line break between the URI section and the public key. You can see the example on section 3. of the draft-ietf-sidr-multiple-publication-points-00 document.

Section 2.2:
(Roque) I find this paragraph confusing:
   The trust anchor MUST be published at a stable URI.  When the trust
   anchor is re-issued for any reason, the replacement CA certificate
   MUST be accessible using the same URI.
I am not sure the meaning of "stable URI" in this context. Would it be "stable URI section"? or "stable rsync URI(s)"?

(Roque) s/Becuase/Because

---

From: "Roque Gagliano (rogaglia)" <[email-masked]>
Date: Mon, 10 Feb 2014 16:23:40 +0000

Hi Goeff,

On Feb 9, 2014, at 11:05 PM, Geoff Huston <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

The document went through the adoption process and was open to discussions for almost 2 years. We never went through WGLC, which is when most people pays a closer attention. The only formal comment that we received on the format was about the blank line Randy mentioned and that was incorporated.

The issue about multiple CA certs that are different was something the earlier draft was silent about. They simply said that they MUST be the same and left it at that. I'm not sure how critical an issue this is, and whet forms of additional mechanism are necessary to allow RPs to retrieve all the referenced CA certs and define an algorithm for them to follow to select the "best". My simplistic thinking about the original intent in draft-ietf-sidr-multiple-publication-points was that an RP would pick oine URI, and if that was unresponsive after some local threshold it wuould try another, and so on. The discussion so far has been based on an assumption that an RP would retrieve the CA cert from 2 or more URI's and then worry about the case where the URIs differ. I am not sure what to add here to the draft - the WG will need to provide further guidance on this. I worry about a proposal for RPs to check all URIs - it seems to me to be adding to the total load and I'm then not sure where
the benefit of multiple URIs in TAs comes from in such a scenario.

I believe you should use Section 3.2 of draft-ietf-sidr-multiple-publication-points  as a starting point. As you can see the recommended behaviour is to select a rule to fetch the TA certificate and stop when you fetch one that matches the TAL public key.

3.2<http://tools.ietf.org/html/draft-ietf-sidr-multiple-publication-points-00#section-3.2>.  Rules for Relying Parties (RP)

   A RP can use different rules to select the URI from where fetch the
   Trust Anchor certificate.  Some examples are:

   o  Using the order provided in the TAL file

   o  Selecting the URI randomly from the available list

   o  Creating a prioritized list of URIs based on RP specific
      parameters such as connection establishment delay

   If the connection to the preferred URI fails or the fetched
   certificate public key does not match the TAL public key, the RP
   SHOULD fetch the TA certificate from the next URI of preference.

Roque

  Geoff

On 9 Feb 2014, at 12:14 am, Tim Bruijnzeels <[email-masked]<mailto:[email-masked]>> wrote:

On Feb 8, 2014, at 5:21 AM, Randy Bush <[email-masked]<mailto:[email-masked]>> wrote:

+1

--

o last para of 2.2 says

o same last para of 2.2

o 3.1

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

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

---

From: Geoff Huston <[email-masked]>
Date: Tue, 11 Feb 2014 03:43:12 +1100

On 11 Feb 2014, at 3:23 am, Roque Gagliano (rogaglia) <[email-masked]> wrote:

> Hi Goeff,
> 
> On Feb 9, 2014, at 11:05 PM, Geoff Huston <[email-masked]> wrote:
> 
>> Hi,
>> 

no criticism was intended here Roque about the previous process. I was trying to explain my assumptions when incorporating this text into 6490bis. I agree that in general it takes a Last Call to elicit readers and comments, although there are always exceptions and this call for adoption is one of them.

> 3.2.  Rules for Relying Parties (RP)
> 
> 
> 

I can (and will) certainly add that text to section 3 of the bis document.

However, the question raised by Randy and commented on by Tim still remains - what should a RP do if it chooses to retrieve the material from 2 or more URIs and finds that the CA certificates that are retrieved in this manner differ? And from Tim, some further contemplation about that the TA publisher could do to provide hints to the RP in such a situation.

regards,

   Geoff

---

From: "Roque Gagliano (rogaglia)" <[email-masked]>
Date: Mon, 10 Feb 2014 17:28:13 +0000

Geoff,

> no criticism was intended here Roque about the previous process. I was trying to explain my assumptions when incorporating this text into 6490bis. I agree that in general it takes a Last Call to el…

(Roque) No problem and thank you for taking over the work.

> However, the question raised by Randy and commented on by Tim still remains - what should a RP do if it chooses to retrieve the material from 2 or more URIs and finds that the CA certificates that…

(Roque)  Two different problems:
	1) Fetching two different TA certificates that match the public key but do not have the same content: This problem can happen today as even if you have one URI, you can have two different "real" rsync servers behind, we are just making it evident. I personally believe we should stay only what is the expected behaviour rather than enumerating all the alternatives.

	2) Tim proposal to expand the TAL verbosity: I am sympathetic to the idea of using key=value style. However, as we only have two "keys", I see little incremental value on the changes from one version to the next one. On the other side, I am skeptical to add more verbosity to the TAL with information that we cannot cryptographically verify (the TAL is a plain text not signed document.)  I remember Carlos proposed the idea of having a special TAL signed object only available at the TA's publication point that would add information referring to the TAL lifecycle (maybe including a new TAL file to be replacing the existing one.) This seams to be a more appropriate way to solve the problem of replacing the TA key and keep the compatibility with the old install base (and as long as it is not been compromised :-) ).

Regards,
Roque

---

From: Tim Bruijnzeels <[email-masked]>
Date: Mon, 10 Feb 2014 20:14:30 +0100

Hi Roque, all,

First of all, the short version:
= Yes, I support adoption
= No, I don't see big issues / show stoppers, have some comments
= Yes, I do see potential for other improvements (but I understand we may want to leave it for now)

> (Roque) No problem and thank you for taking over the work.

As I tried to say in my previous mail. This is not show stopper for me, and I am aware that changing this would be new work.

So, if this proves too timely and difficult now, or there is simply no wg consensus on this, then I really don't mind deferring this.

> 	1) Fetching two different TA certificates that match the public key but do not have the same content: This problem can happen today as even if you have one URI, you can have two different "real" r…

For this I think we can assume that the keys match. If the certificate is for another key, it will simply not validate according to the known TAL and be dismissed.

But even with the same key other important bits may have changed. Most importantly the resources, but possibly also the publication point. I think the general semantics should be that:
 = The TAL is just a hints file really, the URIs are there to help the RP find a certificate matching the key they chose to trust
 = If the RP finds multiple certificates matching the TAL, then (to me) it would make sense to go with the most recent one..

That's where I was driving with the whole Trust Anchor must increase the serial number whenever it re-issues a self signed TA certificate. Then the RP can just go with the one with the highest serial. If we find this a little scary (though I don't see a clear attack here), then I would also be fine with saying that the TA should set the signing-time, and the RP can go with the most recent (non future dated) certificate it knows.

I think it's up to the RP to decide how many URIs it will try and how often. You could try to limit that here, but I don't think you can make them..

> 	2) Tim proposal to expand the TAL verbosity: I am sympathetic to the idea of using key=value style. However, as we only have two "keys", I see little incremental value on the changes from one version to the next one. On the other side, I am skeptical to add more verbosity to the TAL with information that we cannot cryptographically verify (the TAL is a plain text not signed document.)

As said above.. not a show stopper, my feeling of the room is that people are not keen, but..

We are actually using a key value pair based tal format in our validator today. We wanted additional info in there, like a human friendly name, and a list of pre-fetch URIs to aid in validating non-hierarchical TA repos. None of this is actually used for validation, it's just hints that make it a bit smoother. If the standard said something like:
  - must contain one value for the 'subjectPublicKeyInfo'
  - must contain one or more values for the 'URI'
  - may contain additional elements
  - and RP: just ignore what you don't care about

Then it would be a little easier to be back-ward compatible. And we could publish our extended TAL and other validators would still understand.

And finally on this, I do think json is a better format. Especially when dealing with arrays. Randy you may want to check RFC4627 and the list of links to libraries for 50 odd languages at json.org. It's actually pretty well defined, and widely used.

>  I remember Carlos proposed the idea of having a special TAL signed object only available at the TA's publication point that would add information referring to the TAL lifecycle (maybe including a new TAL file to be replacing the existing one.) This seams to be a more appropriate way to solve the problem of replacing the TA key and keep the compatibility with the old install base (and as long as it is not been compromised :-) ).

Ah cool. I forgot that, or I missed it, or it lingered in my subconsciousness . In any case it's exactly what I was referring to in my previous mail.

I was triggered by this text in section 2.2:

   If an entity wishes to withdraw a self-signed CA certificate as a
   putative Trust Anchor, for any reason, including key rollover, the
   entity MUST remove the object from the location referenced in the
   TAL.

I think a signed TAL would really help here.. 

If the entity wishes to remove a self-signed CA certificate they SHOULD first publish a new signed TAL where this URI is no longer present and then proceed to remove the object. If the entity wishes to add a self-signed CA certificate publication point they SHOULD first publish the object at the new location and then publish a new signed TAL where this URI has been included.

And maybe even the planned key roll..

If the entity wishes to perform a key roll of the self-signed CA certificate they MUST first re-issue all the signed objects signed by the old key under the new key under a new location. Then they MUST publish a new TAL with an subjectPublicKeyInfo matching the new key, one or more URIs, and a date by which the old key will be retired*.

I am not saying this is finished.. or even that it must be included now, but I really think this would be useful, and it does not have to get much more complicated than this.

*: Note.. on second thought I figured that the not-before-date I mentioned earlier doesn't make sense here: just publish when ready, not before.

Cheers
Tim

---

From: Andy Newton <[email-masked]>
Date: Mon, 10 Feb 2014 19:15:52 +0000

>we're just trying to allow multiple uris in a tal.

I agree with Randy that we don¹t need to get carried away (though JSON is
widely implemented). The current format works for me.

And I support the adoption of this work item.

-andy

---

From: Geoff Huston <[email-masked]>
Date: Tue, 11 Feb 2014 10:01:54 +1100

>    SHOULD fetch the TA certificate from the next URI of preference.

I'll add the following to the text in section 3, and re-submit this as a -01 draft. (I hope that the wg adoption
process does not get confused by this change - is this ok WG chairs?)

   In the case where a TAL contains multiple URIs, RP may use a locally
   defined preference rule to select the URI from where fetch the Trust
   Anchor certificate.  Some examples are:
   o  Using the order provided in the TAL
   o  Selecting the URI randomly from the available list
   o  Creating a prioritized list of URIs based on RP specific
      parameters, such as connection establishment delay

   If the connection to the preferred URI fails, or the fetched CA
   certificate public key does not match the TAL public key, the RP
   SHOULD fetch the CA certificate from the next URI, according to the
   local preference ranking.

Geoff

---

From: Randy Bush <[email-masked]>
Date: Tue, 11 Feb 2014 16:16:28 +0900

>    local preference ranking.

in the case of a key mismatch, there would be significant benefit of
reporting it.  but to whom and how?  

randy

---

From: Stephen Kent <[email-masked]>
Date: Tue, 11 Feb 2014 13:12:11 -0500

Tim,
> But if the format is open to change, then I would feel more for a key=value style, or dare I say even json.. this is parsed by the machines after all. And using something like json makes it much mo…
I'm not a fan of switching to JSON at this point.
>    *: They may not be able to if this is hosted at a third party
I agree with Randy that the references to "TA" above should just be "CA"

I'm puzzled by the references to a "third party" above. Why would an 
entity acting as
a TA not want to control all of the locations where it's TAL identifies 
as places from
which to acquire the cert?
> To handle all this more elegantly I think there should be a mechanism for TAs to publish replacement TALs. To add, or remove URIs, or even to do planned key rolls (for example: TA wants change HSM…
These are desirable, additional features, but I agree with Randy that 
they merit a new work item.
The change to allow a TAL to contain pointers to multiple locations for 
cert retrieval seems to
be an easy change that we can agree upon.
> This would allow RPs to use existing TALs to discover updates and process automatically (it is signed by the key that I trust). It could stop re-trying retired URIs, and start using the new ones. A…
As I noted above, this seems like a good, new work item.

Steve

---

From: Tim Bruijnzeels <[email-masked]>
Date: Tue, 11 Feb 2014 21:37:17 +0100

Hi Steve

> I'm not a fan of switching to JSON at this point.

I noticed I stand alone in the matter. No worries. Note the 'if' and let's move on..

> I agree with Randy that the references to "TA" above should just be "CA"

Sure. I used to TA rather broadly here, including the CA operated by the Trust Anchor entity.

> I'm puzzled by the references to a "third party" above. Why would an entity acting as
> a TA not want to control all of the locations where it's TAL identifies as places from
> which to acquire the vert?

Actually I think this could be a feature. Call me paranoid, but publishing the cert in places where even your own disgruntled operators can't reach it, and remove it or replace it with an old one, seems to me like an idea to entertain. Such access generally does not require any HSM, card quorum etc. But doing this of course introduces the risk of these third party points going rogue. Hence the "no control" remark. But see below..

> These are desirable, additional features, but I agree with Randy that they merit a new work item.
> The change to allow a TAL to contain pointers to multiple locations for cert retrieval seems to

Fair enough. I did not want to bring this up as a show stopper for going forward with the bis, but it seemed relevant to talk about this now.

The rogue third party risk could be mitigated by signed TALs. A signed (presumably controlled by an HSM and N out of M cards) statement could remove such a publication point from the list. On top of this RPs could regularly re-check certificates in multiple locations to find the most recent. They could also cache the most recent one they have found and refuse older ones. This re-checking should not be needed every few minutes, but once every 24 hours or something seems quite reasonable to me.

But since I don't think it's feasible to get the signed TAL idea worked out for the bis, it's probably best for now to say that the entity acting as a TA should only publish the CA certificate in locations it has full control over. This would also make zealous re-checking by RPs less relevant at this stage.

Tim

---

From: Randy Bush <[email-masked]>
Date: Wed, 12 Feb 2014 08:06:26 +0900

> entity acting as a TA not want to control all of the locations where
> it's TAL identifies as places from which to acquire the cert?

outsourcing.  think of it as rendition.

randy

---

From: Stephen Kent <[email-masked]>
Date: Wed, 12 Feb 2014 10:17:44 -0500

Tim,

>>> ...
I don't see the tradeoff as being a positive one, but at least I now 
understand the motivation for your statement.
>> ...
sure.
> The rogue third party risk could be mitigated by signed TALs. A signed (presumably controlled by an HSM and N out of M cards) statement could remove such a publication point from the list. On top o…
a once per day retrieval seems quite reasonable to me too.
> But since I don't think it's feasible to get the signed TAL idea worked out for the bis, it's probably best for now to say that the entity acting as a TA should only publish the CA certificate in l…
agreed.

I'm happy to work with you on a new doc that explores added security 
functions for TALs.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 12 Feb 2014 10:33:01 -0500

Randy,
> outsourcing.  think of it as rendition.
Ah, so a TA kidnaps a cert, blindfolds it, pours water over its 
signature, and forces
the cert to disclose the private key used to sign it.

Got it.

No problem.

Steve

---

From: Tim Bruijnzeels <[email-masked]>
Date: Mon, 17 Feb 2014 09:43:46 +0100

Hi Steve,

On Feb 12, 2014, at 4:17 PM, Stephen Kent <[email-masked]> wrote:

> I'm happy to work with you on a new doc that explores added security functions for TALs.

Let's have a chat in London. Carlos may also be interested.

Tim

---

From: "Murphy, Sandra" <[email-masked]>
Date: Wed, 26 Feb 2014 17:16:24 +0000

There was sufficient support and no objections raised (as well as some energetic activity) to judge the working group as having consensus to adopt this work as a working group work item.

The authors should submit a new draft with a working group file name as soon as as possible.

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

________________________________________
From: sidr [[email-masked]] on behalf of Murphy, Sandra [[email-masked]]
Sent: Friday, February 07, 2014 2:47 PM
To: [email-masked]
Subject: [sidr] working group adoption poll for draft-huston-sidr-rfc6490-bis