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

From: Tom Harrison <[email-masked]>
Date: Tue, 17 Jul 2018 12:58:27 -0400

On Fri, Jun 08, 2018 at 06:30:41AM -0700, [email-masked] wrote:
> 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

I've updated our proof-of-concept to match the new draft.  Some
questions and minor suggestions:

In section 3, there is:

   The ASN.1 syntax for the Signed TAL eContent defined in
   Section 3.2.  (This is the payload that specifies the AS being
   authorized to originate routes as well as the prefixes to which
   the AS may originate routes.)

The text in parentheses looks to be a cut-and-paste from the ROA
profile document (RFC 6482).

In section 4, there is "[t]his EE certificate MUST have a 'notAfter'
time that reflects the intended time that this Signed TAL will be
published", which on its face implies that the 'notAfter' should be
set to the time when the object is first published.  Changing it to
"reflects the intended time [or duration] for which this signed TAL
will be published" should make things clearer.

The SubjectPublicKeyInfo in the TAL structure has the type IA5String.
Is there some reason not to use the 'raw' SubjectPublicKeyInfo type
from RFC 5280?

Since activationTime is not needed for an in-protocol reason at the
moment, it would be good to add a note to the draft that it's there to
prompt discussion/feedback about future dating.

On future dating more generally, I think it's a good idea, since it
allows for in-band signalling about the rollover and would (hopefully)
encourage a wider set of users to test the new tree before it becomes
the 'official' tree.

-Tom

---

From: Tim Bruijnzeels <[email-masked]>
Date: Tue, 17 Jul 2018 17:52:32 -0400

Hi Tom,

Thanks for testing and the feedback. Comments below.

> On 17 Jul 2018, at 12:58, Tom Harrison <[email-masked]> wrote:
> 

Fixed in my edit buffer.

> will be published" should make things clearer.

Yes, you are right. The intention was duration. Fixed in the edit buffer.

> Is there some reason not to use the 'raw' SubjectPublicKeyInfo type

This is an oversight. It should just be the raw DER structure.

> encourage a wider set of users to test the new tree before it becomes

The current draft assumes that the TA tests things before publishing the new signed TAL object, and then I think it would be okay for RPs to follow this new TAL as soon as it’s available.

But.. there may be good reasons for future dating / having a backup key.

In that case I would suggest that we have a structure where the ‘current’ TA key and URIs are always listed explicitly, pretty much like the document says now, but there is an optional similar structure with the intended ‘activationTime’ (informational only) for the new key.

That way the roll can be prepared in advance. RPs could theoretically verify independently that things are okay - but I would like to avoid putting this burden on all RPs. Once things are okay to roll, the TA can update it’s signed TAL then to make the new key ‘current’ and RPs can follow.

As I said at the mic HSMs can be used to protect against key theft. But keys (or card sets) can still be lost. If access to the new key is lost, then the TA can just choose not complete the roll - remove it, replace it with a new target key. If access to the current key is lost, then things get more difficult. Then the new key would have to be allowed to take over, e.g. automatically once the activation time is past?

Explicit revocation of the old key is also possible, but would require that RPs constantly check these candidate keys. I am afraid this adds a lot of overhead.

Comments and ideas are most welcome!

Tim

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

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 26 Jul 2018 02:02:54 -0400

It occurs to me that ... we should have closed out the wglc for this
document prior to IETF week.
If this set of comments/edits is all done then we can send a new version of
the draft and forward things up the mgmt chain.

thoughts?

-chris

On Tue, Jul 17, 2018 at 5:52 PM Tim Bruijnzeels <[email-masked]> wrote:

> The current draft assumes that the TA tests things before publishing the
> new signed TAL object, and then I think it would be okay for RPs to follow
> this new TAL as soon as it’s available.
>
> In that case I would suggest that we have a structure where the ‘current’
> TA key and URIs are always listed explicitly, pretty much like the document
> says now, but there is an optional similar structure with the intended
> ‘activationTime’ (informational only) for the new key.
>
> That way the roll can be prepared in advance. RPs could theoretically
> verify independently that things are okay - but I would like to avoid
> putting this burden on all RPs. Once things are okay to roll, the TA can
> update it’s signed TAL then to make the new key ‘current’ and RPs can
> follow.
>
> As I said at the mic HSMs can be used to protect against key theft. But
> keys (or card sets) can still be lost. If access to the new key is lost,
> then the TA can just choose not complete the roll - remove it, replace it
> with a new target key. If access to the current key is lost, then things
> get more difficult. Then the new key would have to be allowed to take over,
> e.g. automatically once the activation time is past?
>
> Explicit revocation of the old key is also possible, but would require
> that RPs constantly check these candidate keys. I am afraid this adds a lot
> of overhead.
>

---

From: Tim Bruijnzeels <[email-masked]>
Date: Thu, 26 Jul 2018 09:34:16 +0200

Hi Chris,

The last call was on 'draft-ietf-sidrops-https-tal-03’, see:
https://www.ietf.org/mail-archive/web/sidrops/current/msg00440.html <https://www.ietf.org/mail-archive/web/sidrops/current/msg00440.html>

There was a nit and a suggestion for clarification by Job Snijders that I would be happy to include in an update.

The signed-tal document needs more work. I received useful feedback on list from Tom Harrison and Di Ma, and a good in-depth discussion with Rob Austein. I plan to upload a new version for further discussion in the coming weeks.

Tim

> On 26 Jul 2018, at 08:02, Christopher Morrow <[email-masked]> wrote:
> 
> It occurs to me that ... we should have closed out the wglc for this document prior to IETF week.
> If this set of comments/edits is all done then we can send a new version of the draft and forward things up the mgmt chain.
> 
> thoughts?
> 
> -chris
> 
> On Tue, Jul 17, 2018 at 5:52 PM Tim Bruijnzeels <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Tom,
> 
> > On 17 Jul 2018, at 12:58, Tom Harrison <[email-masked] <mailto:[email-masked]>> wrote:
> > 
> > On Fri, Jun 08, 2018 at 06:30:41AM -0700, [email-masked] <mailto:[email-masked]> wrote:
> > [email-masked] <mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/sidrops <https://www.ietf.org/mailman/listinfo/sidrops>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/sidrops <https://www.ietf.org/mailman/listinfo/sidrops>

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 26 Jul 2018 10:02:34 -0400

On Thu, Jul 26, 2018 at 3:34 AM Tim Bruijnzeels <[email-masked]> wrote:

> https://www.ietf.org/mail-archive/web/sidrops/current/msg00440.html
>
> The signed-tal document needs more work. I received useful feedback on
> list from Tom Harrison and Di Ma, and a good in-depth discussion with Rob
> Austein. I plan to upload a new version for further discussion in the
> coming weeks.
>
>
ok, great, you intend to ask to move it back through wglc when you get
settled then? (which is fine for me)

> If this set of comments/edits is all done then we can send a new version
> of the draft and forward things up the mgmt chain.
>
> thoughts?
>
> -chris
>

---

From: Tim Bruijnzeels <[email-masked]>
Date: Thu, 26 Jul 2018 16:24:03 +0200

Hi,

> On 26 Jul 2018, at 16:02, Christopher Morrow <[email-masked]> wrote:
> ok, great, you intend to ask to move it back through wglc when you get settled then? (which is fine for me)

I just uploaded https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-https-tal-04 <https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-https-tal-04> with the nits included. I want to ask you if you can conclude what the outcome is of the WG-LC for this, but I hope it can progress to publication.

Signed-tal should just stay a WG document. I plan to have an -02 before Bangkok, and based on how that is received we can then ask for WG-LC on this one, or keep discussing and fixing things for a bit longer.

Tim