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

[Tim Bruijnzeels <[e-mail]>]

Dear WG,

Allow me to kick this thread again. The London IETF is happening soon, and if possible I would like to have some discussion before then, so that we may be able to update the document before then.

TL;DR on the below:
- I agree with Tom about a double encoding issue
- I am thinking out loud whether to have:
    - An explicit XML based structure for the content, rather than a simple TAL, as it will allow for some additional information that is useful here
    - A mechanism for unplanned rolls: a stand-by key can can revoke the current key if it would be lost
    - And if adopted, use the same mechanism for planned rolls (keep things consistent).

I would like to hear your thoughts on this. If it is desired I am happy to present on this in London and/or discuss in person.

Tim


> On 6 Dec 2017, at 14:59, Tim Bruijnzeels <[e-mail]> wrote:
> 
> Hi Tom,
> 
> Thank you for your reply. I have been side-tracked for a bit, but let me comment :)
> 
>> On 16 Nov 2017, at 11:34, Tom Harrison <[e-mail]> wrote:
>> 
>> On Mon, Nov 13, 2017 at 11:20:18PM -0800, [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-00.txt
>>> 	Pages           : 10
>>> 	Date            : 2017-11-13
>> 
>> We've done a fairly basic proof-of-concept implementation of this as
>> an extension to our RPKI system.  The core of it looks good and
>> functions as expected.  Some questions and minor suggestions (all
>> IMHO):
>> 
>> Having explicit structure in the SignedTalContent definition would
>> make implementation a little easier.  It would also remove any
>> possible confusion about whether the public key need be base64-encoded
>> again (the current text appears to require that).
> 
> I agree that the double encoding is probably not needed. I hoped to avoid any chance of having character in the ‘eContent’ part that could cause issue. But.. just shooting for encoding again for good measure was a bit of lazy thinking here.. we don’t need this for the XML messages in RFC6492 (provisioning) and RFC8181 (publication) either, so I think we should be safe.
> 
> There is no structure at the moment because we wanted to use the TAL format as-is.
> 
> That said, I think that there may be merit in an explicit json, or XML (to be consistent with 6492 and 8181) format, e.g.:
> 
> <tal>
>   <uris>
>     <uri>https://rpki.example.org/rpki/hedgehog/root.cer</uri>
>     <uri>rsync://rpki.example.org/rpki/hedgehog/root.cer</uri>
>   </uris>
>   <subjectPublicKeyInfo>
>      MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAovWQL2lh6knDx
>      GUG5hbtCXvvh4AOzjhDkSHlj22gn/1oiM9IeDATIwP44vhQ6L/xvuk7W6
>      Kfa5ygmqQ+xOZOwTWPcrUbqaQyPNxokuivzyvqVZVDecOEqs78q58mSp9
>      nbtxmLRW7B67SJCBSzfa5XpVyXYEgYAjkk3fpmefU+AcxtxvvHB5OVPIa
>      BfPcs80ICMgHQX+fphvute9XLxjfJKJWkhZqZ0v7pZm2uhkcPx1PMGcrG
>      ee0WSDC3fr3erLueagpiLsFjwwpX6F+Ms8vqz45H+DKmYKvPSstZjCCq9
>      aJ0qANT9OtnfSDOS+aLRPjZryCNyvvBHxZXqj5YCGKtwIDAQAB
>   </subjectPublicKeyInfo>
> </tal>
> 
> A structure like this will make it easier to add tags or attributes to communicate other things. See below.
> 
>> Section 3.3 has "[i]f the above procedure indicates that the manifest
>> is invalid".  It looks like it should be "...that the Signed TAL is
>> invalid".
>> 
>> Section 4 has "[t]his EE certificate MUST have a "notBefore" time that
>> is before the moment that the Signed TAL will be published".  Why is
>> this a MUST?  I can imagine somebody prepublishing the new TAL, but
>> not wanting RPs to switch over until the notBefore time had been
>> reached, though I guess that would also lead to validation errors for
>> RPs in the interim due to the object not being in-date.
> 
> It’s a MUST because otherwise the object is invalid.
> 
> If we need an explicit staging time, rather than require this implicitly by publishing it, then I think we are better off with a valid object and an XML structure like above with an additional tag like:
> 
> <notBefore>2019-01-01T00:00:00.000Z</notBefore>
> 
>> Regarding signed TAL EE certificate validity periods generally, I
>> think it would be good to add some text about how the new TAL becomes
>> 'effective' as soon as it is published, and that neither revocation
>> nor expiry of the associated EE certificate has any implications in
>> that respect (even though this is implicit from the document as a
>> whole).
> 
> True. Whether it’s done implicitly by publishing the signed TAL (as the document says now), or some explicit <notBefore/> tag is introduced: there is a point of no return by which RPs will have moved over.
> 
> And thinking about this a bit more I believe that there should also be text that forbids a Trust Anchor from pointing RPs back to a previous key. We should only roll forward.
> 
>> Section 6.3 has "[t]he TA SHOULD preserve a Signed TAL for the old key
>> after the staging period as a hint for RPs that missed the key roll".
>> Although (I think) the only sensible way to read this is that the
>> signed TAL to which this is referring is that pointing to the new TA,
>> "for the old key" might make people think the signed TAL should be for
>> the deprecated key instead.  Something like "[t]he TA SHOULD preserve
>> the Signed TAL pointing to the new TA after the staging period..."
>> could work.
> 
> So, here there is a lot of implicit stuff again.
> 
> We could also think of this differently.. maybe extending the structure to something like this could help:
> 
> <ta>
>  <oldKeys>
>     <subjectPublicKeyInfo>MIIBIjANBgk…</subjectPublicKeyInfo>
>     <subjectPublicKeyInfo>MIIBIjdfkhjfd…</subjectPublicKeyInfo>
>  </oldKeys>
>  <current>
>  <tal>
>   <uris>
>     <uri>https://rpki.example.org/rpki/hedgehog/root.cer</uri>
>     <uri>rsync://rpki.example.org/rpki/hedgehog/root.cer</uri>
>   </uris>
>   <subjectPublicKeyInfo>
>      MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAovWQL2lh6knDx
>      GUG5hbtCXvvh4AOzjhDkSHlj22gn/1oiM9IeDATIwP44vhQ6L/xvuk7W6
>      Kfa5ygmqQ+xOZOwTWPcrUbqaQyPNxokuivzyvqVZVDecOEqs78q58mSp9
>      nbtxmLRW7B67SJCBSzfa5XpVyXYEgYAjkk3fpmefU+AcxtxvvHB5OVPIa
>      BfPcs80ICMgHQX+fphvute9XLxjfJKJWkhZqZ0v7pZm2uhkcPx1PMGcrG
>      ee0WSDC3fr3erLueagpiLsFjwwpX6F+Ms8vqz45H+DKmYKvPSstZjCCq9
>      aJ0qANT9OtnfSDOS+aLRPjZryCNyvvBHxZXqj5YCGKtwIDAQAB
>   </subjectPublicKeyInfo>
> </tal>
>  </current>
> </ta>
> 
> This way we can communicate explicitly which previous keys have been expired. And what the current key is at the time of publishing this.
> 
> If this is published by old keys in the form of long-lived objects and CRLs, then RPs could still find their way to the current key. An argument can also be made that RPs should not care about staleness of MFT/CRL or expired MFT/TAL EE certificates in this case.
> 
>> I think 24 hours for the staging period is too short, mainly because
>> people who don't update their validators to support this may not take
>> action on the new validation error (something like "unknown type of
>> object: {name}.tal") within that short a time period.
> 
> Okay, it’s not clear to me that this is related to the staging period.
> 
> But, before any of this could be deployed we do need to be sure that RP software can be upgraded to support it, or at least not choke on it. If people do not upgrade their RP software they can still find out that a new TAL should be used through other means (e.g. mailing lists). And let me be devil’s advocate here.. if people never, ever upgrade their RP software, then breaking it and forcing them to upgrade could be considered a feature by some. Of course, after a reasonable time..
> 
>> There are also
>> other instances like this where manual action might be required, e.g.
>> where operations staff insist that the validator not have write access
>> to its configuration and that all updates happen manually.  A week or
>> a month as a mandatory period would be better.
> 
> I believe that we should insist that key rolls like this are fully automated and not done manually. I also believe that it would be prudent that if && when we agree on a mechanism for this, it is done regularly - at least in some environments to ensure that this works. In short: I think a planned key roll, signed by a trusted TA, should be a normal thing. If we leave this as paperware then there will be no guarantee that it works when we need it.
> 
> 
> One more thing I wanted to bring up is unplanned key rolls. There may be merit in having a <staging> tag in the structure, like this:
> 
> <ta>
>  <oldKeys>
>     <subjectPublicKeyInfo>MIIBIjANBgk…</subjectPublicKeyInfo>
>     <subjectPublicKeyInfo>MIIBIjdfkhjfd…</subjectPublicKeyInfo>
>  </oldKeys>
>  <current>… this key.. </current>
> 
>  <staging>
>  <type>standby</type>
>  <tal>
>   <uris>
>     <uri>https://rpki.example.org/rpki/hedgehog/root.cer</uri>
>     <uri>rsync://rpki.example.org/rpki/hedgehog/root.cer</uri>
>   </uris>
>   <subjectPublicKeyInfo>
>      MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAovWQL2lh6knDx
>      GUG5hbtCXvvh4AOzjhDkSHlj22gn/1oiM9IeDATIwP44vhQ6L/xvuk7W6
>      Kfa5ygmqQ+xOZOwTWPcrUbqaQyPNxokuivzyvqVZVDecOEqs78q58mSp9
>      nbtxmLRW7B67SJCBSzfa5XpVyXYEgYAjkk3fpmefU+AcxtxvvHB5OVPIa
>      BfPcs80ICMgHQX+fphvute9XLxjfJKJWkhZqZ0v7pZm2uhkcPx1PMGcrG
>      ee0WSDC3fr3erLueagpiLsFjwwpX6F+Ms8vqz45H+DKmYKvPSstZjCCq9
>      aJ0qANT9OtnfSDOS+aLRPjZryCNyvvBHxZXqj5YCGKtwIDAQAB
>   </subjectPublicKeyInfo>
>  </tal>
>  </staging>
> 
> </ta>
> 
> This could alert RPs that a new key exists. It in turn can publish the same signed TAL structure - confirming that this staging key is not in use yet. If and when the old key needs to be replaced and the TA operator lost access to its key, then the staging key can publish a structure where the old key appears in the <oldKeys> list instead.. in other words it’s empowered to revoke the “current” key. If access to the “staging" key is lost, then the “current” key can just remove the <staging> section, or replace it with another staging key.
> 
> The risk here is that if the new key goes rogue it can revoke the current key. I don’t think that this is a bigger risk than the current key going rogue. The advantage is that there is a back-up key and in a TA can recover if they lose access to either the current, or the staging key. If Hardware Security Modules (HSMs) are used, the risk of key theft can be mitigated to a very large degree - typically keys are protected by an N out of M card set where a quorum of people are needed to use the key, or migrate it into new hardware. But, losing keys, broken cards, and sadly loosing people, are real threats that can lead to situations where a TA no longer has a quorum.
> 
> Obviously the above is not worked out in full detail, but I would welcome discussion on the direction. And as a final thought.. it would be good if the planned and unplanned key roll processes are similar.
> 
> 
> Thanks
> 
> Tim
> 
> 
>> 
>> -Tom
>> 
>> _______________________________________________
>> Sidrops mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/sidrops
>> 
> 
> _______________________________________________
> Sidrops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sidrops