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

> On 29 Jul 2021, at 19:17, Randy Bush <randy@psg.com> wrote:
> 
>>> is there something useful which can be said about dealing with
>>> compromise?  e.g. the classic sign new with old far in advance
>>> comes to mind.  i yield the floor to russ.
>> 
>> I like the mechanism described in RFC 8649.
>> 
>> This requires the trust anchor to generate the next key in advance,
>> and store the hash of it in the current self-signed certificate.  This
>> allows the relying party to recognize the successor TA when it gets
>> published.
> 
> wfm

RPKI RPs do not ship with TA (CA) certificates. They get the latest certificate for each validation run based on the TAL (RFC 8630).

Including an optional non-critical extension like this for a new key in that certificate could be done, but I am not sure that all RPs will ignore the extension if they don't understand it. This would have to be tested.

Furthermore, what is then the next step? If we would simply replace that TA certificate with one for the new key, then this could work for RPs which support the extension and have seen the hash of the new key. They would find a certificate that does not match the TAL, but they could accept it because they had learned the key. But it would not work for RPs that do not support this, or fresh installations (without prior state) using an old TAL (with the fingerprint of the previous key).

Please correct me, but I guess it implies a process like:
- generate the new key
- include the hash in the old key certificate

When the time comes to use the new key:
- operate both keys in parallel
- distribute a TAL for the new key, ask for it to packaged with new RPs

When the time comes to remove the old key:
- perhaps start publishing the new key's CA certificate on the old key's TAL location
- RPs which learned the new key hash earlier could accept it
- Accept that out-of-date RPs, or RPs which do not support the extension, will be left behind at this point

The main advantage that I can see is that we would not need a new signed-tal object type. But the drawback is that we can not leave way pointers for outdated RPs. The proposal as written suggests to keep these around as pointers for outdated RPs. The security assumption / caveat is that the old key is not compromised, preferably was kept in an HSM, and is destroyed when it is no longer used. And that an attacker cannot derive the old private key (brute force?) and has access to the old key's CA certificate publication point.

So, with signed-tal if the old key is compromised then old RPs with old TALs can be fooled. But I think the same can be said if we used the hash approach - RPs with outdated TALs could then be misled as well.

To be clear: I am not opposed to better ideas than the signed-TAL approach described now, but I want to understand how and why they are better, and what the consequences and trade-offs are.

Tim

> 
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops