Subject: [Sidrops] I-D Action: draft-ietf-sidrops-signed-tal-01.txt

From: [email-masked]
Date: Fri, 08 Jun 2018 06:30:41 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the SIDR Operations WG of the IETF.

        Title           : RPKI signed object for TAL
        Authors         : Tim Bruijnzeels
                          Carlos Martinez
	Filename        : draft-ietf-sidrops-signed-tal-01.txt
	Pages           : 12
	Date            : 2018-06-08

Abstract:
   Trust Anchor Locators (TALs) [I-D.ietf-sidrops-https-tal] are used by
   Relying Parties in the RPKI to locate and validate Trust Anchor
   certificates used in RPKI validation.  This document defines an RPKI
   signed object [RFC6488] for a Trust Anchor Locator (TAL) that can be
   used by Trust Anchors to perform a planned migration to a new key,
   allowing Relying Parties to discover the new key up to one year after
   the migration occurred.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-sidrops-signed-tal/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-sidrops-signed-tal-01
https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-signed-tal-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-signed-tal-01

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: Tim Bruijnzeels <[email-masked]>
Date: Fri, 8 Jun 2018 15:37:40 +0200

Dear WG,

This a new version of the “Signed TAL” document that I presented on at IETF101.

The main changes in this version are:
- Now supporting planned rolls only!
- MAJOR change here:
 — No staging time!
 — BUT: Added steps for the TA to be sure that things work BEFORE publishing the new Signed TAL (I think this is better).
- Included deployment considerations - essentially: once RPs support, roll often!
- Do changes in URIs as planned rolls.. - included consideration section on this
- No unplanned rolls, they are too complex and introduce a new key that can be compromised (now you have two problems) - included consideration section on this
- Changed the structure of the object to have a version (definitely needed) and use ASN.1 structure rather than plain text or XML - inline with other RPKI Signed Objects
- I included a “activationTime” element in the object to allow for future planned rolls, but I am not convinced that it’s really needed given the proposed procedure to set up the new key and test it first, and only then publish the Signed TAL - But, I don’t object strongly either.

As I said in London. I don’t think that we are close to the final word on this.. so I really would like to invite all of you to give this a good read and speak your mind.

I do want to keep the ball rolling. I think the experience with 5011 has shown that this should be addressed before there are too many implementations. So, I see urgency to address this.

Kind regards,

Tim

> On 8 Jun 2018, at 15:30, [email-masked] wrote:
> 
> 
> _______________________________________________
> Sidrops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidrops
>

---

From: Di Ma <[email-masked]>
Date: Sun, 10 Jun 2018 15:52:07 +0800

Tim,

I think you might as well leave ‘activationTime’ as OPTIONAL element since it is sorta an operational strategy in this document intended to be a BCP. If so, the first MUST in the following text should be change to MAY.

The Signed TAL MUST have an "activationTime" that reflects when	
 	      Relying Parties MUST use use this new TAL in place of any	
 	      previously known TAL for this Trust Anchor.

Besides, it is lovely to see ‘deployment considerations’  included in this version and I am in favor of what is stated in it.

Di

P.S.

I found a nit in Section 6.1 that The sentence ‘The Trust Anchors MUST a new key pair and generate a new TA Certificate. ‘ just missed a verb ‘generate’.

> 在 2018年6月8日，21:37，Tim Bruijnzeels <[email-masked]> 写道：
> 
> Dear WG,
>

---

From: Tim Bruijnzeels <[email-masked]>
Date: Wed, 13 Jun 2018 10:51:51 +0200

Hi Di,

I prefer to have “activationTime” either be mandatory, in which case it’s fairly trivial to set it to ‘now’ or ‘2 minutes ago’ even when one publishes, or not have it all and say that ‘activation’ is implicit because the Signed TAL is published.

This really depends on whether there is a good case for future dating.

Personally I don’t see this use case from the RP side. I would rather that I can just find whatever the TA thinks is the current TAL variables to use and switch to it immediately if they are different from mine.

From the TA side I think that if a TA does its testing and set up as described in section 6, before publishing the Signed TAL, then there is also no need for future dating.

The other issue I have with future dating is that I believe it makes things easy to reason about if there MAY be one, but only one, Signed TAL that describes the current TAL variables (URIs and Subject Public Key Info) to use. Having a future dated object, but no current, is confusing. Having two is more work and a bit confusing.

But if someone else does see a good case for future dating I would be happy to learn it.

Tim

> On 10 Jun 2018, at 09:52, Di Ma <[email-masked]> wrote:
> 
> Tim,
>

---

From: Di Ma <[email-masked]>
Date: Wed, 13 Jun 2018 20:55:49 +0800

Tim,

> 在 2018年6月13日，16:51，Tim Bruijnzeels <[email-masked]> 写道：
> 
> Hi Di,
> 

Yes indeed.  The use case matters here.

> Personally I don’t see this use case from the RP side. I would rather that I can just find whatever the TA thinks is the current TAL variables to use and switch to it immediately if they are differ…

I think it’s important for an RP to determine whether it is ready to use the new TA in case of a planned roll. 

I can’t help but see the parallels when the dnsop item ‘A Root Key Trust Anchor Sentinel for DNSSEC’ occurs to me.

> The other issue I have with future dating is that I believe it makes things easy to reason about if there MAY be one, but only one, Signed TAL that describes the current TAL variables (URIs and Sub…

Agreed.

> But if someone else does see a good case for future dating I would be happy to learn it.

Let’s expect good case:-)

Di