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

[Tim Bruijnzeels <[e-mail]>]

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 <[e-mail]> 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 <[e-mail] <mailto:[e-mail]>> wrote:
> Hi Tom,
> 
> Thanks for testing and the feedback. Comments below.
> 
> > On 17 Jul 2018, at 12:58, Tom Harrison <[e-mail] <mailto:[e-mail]>> wrote:
> > 
> > On Fri, Jun 08, 2018 at 06:30:41AM -0700, [e-mail] <mailto:[e-mail]> 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).
> 
> Fixed in my edit buffer.
> 
> > 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.
> 
> Yes, you are right. The intention was duration. Fixed in the edit buffer.
> 
> > 
> > The SubjectPublicKeyInfo in the TAL structure has the type IA5String.
> > Is there some reason not to use the 'raw' SubjectPublicKeyInfo type
> > from RFC 5280?
> 
> This is an oversight. It should just be the raw DER structure.
> 
> > 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.
> 
> 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
> > [e-mail] <mailto:[e-mail]>
> > https://www.ietf.org/mailman/listinfo/sidrops <https://www.ietf.org/mailman/listinfo/sidrops>
> 
> _______________________________________________
> Sidrops mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/sidrops <https://www.ietf.org/mailman/listinfo/sidrops>