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

From: Tom Harrison <[email-masked]>
Date: Mon, 19 Feb 2018 09:01:33 +1000

Hi Tim,

On Wed, Dec 06, 2017 at 02:59:51PM +0100, Tim Bruijnzeels wrote:
> 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>
>       ...
>    </subjectPublicKeyInfo>
> </tal>
> 
> A structure like this will make it easier to add tags or attributes
> to communicate other things.

This approach looks good.  Would this structure be specific to the
signed TAL, with the 'standard' TAL remaining as-is?

> 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>

Agreed, this approach makes more sense. 

>> 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>
    ...
> </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.

What's the motivation for explicitly listing the previous keys in the
signed TAL?  If each deprecated TA publishes a long-lived signed TAL
that points to the TA that superseded it, then anybody who is using a
deprecated TA will be able to find the current TA, and I can't think
of other instances where knowing the previous keys would be useful.

>> 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.

OK, sounds good.

> And as a final thought.. it would be good if the planned and
> unplanned key roll processes are similar.

One option here is for planned rollover to be handled by having the
'staging' key details include an additional 'transition date' field,
indicating that the TA operator expects to be using the staging key as
its TA key by that date.  That would allow the 'staging period' from
6.2 to remain as-is, while also providing for more advance notice to
be given by way of the 'transition date' field.

-Tom

---

From: Tim Bruijnzeels <[email-masked]>
Date: Tue, 20 Feb 2018 11:38:15 +0100

Hi Tom,

> On 19 Feb 2018, at 00:01, Tom Harrison <[email-masked]> wrote:
> 
> Hi Tim,
> 

In the past I have argued for a more structure TAL. But.. I don’t think there is a strict need. There are working implementations that can parse the current format. Allowing HTTPS (other thread) is fairly trivial as well.

So, in short I would leave the standard TAL as-is, until it’s found that other information is needed there.

> of other instances where knowing the previous keys would be useful.

I was thinking of pre-staging a backup key for an unplanned key roll. If access to the current key is lost the backup key can then revoke the old key. Having a full list was for completeness, but may be overkill, just the one previous key should be enough. RPs would then always check the back-up key, but as long as it didn’t revoke the current key no further action would be needed.

For planned rolls a simpler model with only forward signing (old key says “now use new key”) would be fine.

But.. if we do want to support unplanned rolls then it makes sense to me that we should use the same algorithm in both cases.

> be given by way of the 'transition date' field.

For a planned rollover we can do this. Unless we find that access is lost to the new key before the roll takes place. In that case it will have to be withdrawn, and likely replaced with a new key.

For unplanned rolls it would be needed that keys can be used ahead of this date. One might use a back-up key with the intention of using it 3 months from now, but if access to the current key is lost one week from now, one would still do a quick uplanned roll then.

So, in short, if unplanned rolls need to be supported, then this date should be taken as an intent only. But RPs should keep checking for an unplanned roll.

I hope this makes sense. Would be happy to discuss in person.

Tim

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