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

From: Ben Maddison <[email-masked]>
Date: Wed, 28 Jul 2021 23:42:16 +0200

Hi all,

Re-iterating the comment that I made during the meeting, as requested...

Including the "revoked" flag *only* in the TAK object published by the
"revoked" TA effectively gives anyone with access to that TA's private
the key the ability to resurrect it and/or point RPs to a malicious
successor TA.

Given that a prime motivation for a performing a key roll is a suspected
key compromise, it is troubling that the key roll can be reversed by the
compromised key!

Perhaps I am overlooking something?

Cheers,

Ben

On 06/17, [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 Trust Anchor Key
>         Authors         : Carlos Martinez
>                           George G. Michaelson
>                           Tom Harrison
>                           Tim Bruijnzeels
>                           Rob Austein
> 	Filename        : draft-ietf-sidrops-signed-tal-07.txt
> 	Pages           : 18
> 	Date            : 2021-06-17
> 
> Abstract:
>    A Trust Anchor Locator (TAL) is used by Relying Parties (RPs) in the
>    Resource Public Key Infrastructure (RPKI) to locate and validate a
>    Trust Anchor (TA) Certification Authority (CA) certificate used in
>    RPKI validation.  This document defines an RPKI signed object for a
>    Trust Anchor Key (TAK), that can be used by a TA to signal the
>    location(s) of the accompanying CA certificate for the current key to
>    RPs, as well as the successor key and the location(s) of its CA
>    certificate.  This object helps to support both planned and unplanned
>    key rolls without impacting RPKI validation.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-sidrops-signed-tal/
> 
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-ietf-sidrops-signed-tal-07.html
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-signed-tal-07
> 
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> 
> _______________________________________________
> Sidrops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidrops

---

From: Geoff Huston <[email-masked]>
Date: Thu, 29 Jul 2021 08:15:12 +1000

> On 29 Jul 2021, at 7:42 am, Ben Maddison <benm=[email-masked]> wrote:
> 
> Hi all,
> 

A compromised key being used as a TA is a disaster in many ways, and there
are many scenarios that are possible in addition to the one you describe here.

Perhaps its useful to raise the meta-question: given that its not feasible 
to recover from as compromised key being used as a Trust Anchor, short of
manually “resetting” the trust state of all Relying Parties, what is the purpose
of a key roll in any case?

If all this is merely a box-ticking exercise of ‘required' PKI functionality then
let's admit that and move on. If this is intended to address risks of compromise
through extended use of the same key then what is the nature of such use that
creates the risk profile? Is it the use of the key to sign many diverse objects
and the more things that are signed then the higher the risks of compromise? Is 
the physical aspect of use where the more times the seals of the HSM are cracked
open to use the key, then the greater the risk of compromise? Is it that the more 
relying parties use the key to validate signed objects then the greater the risk
of compromise?

It seems to me that this is a o pretty standard form of “old signs new”, but 
without many of the ancillary measures that we’ve used elsewhere - such as hold-down
timers in RFC 5011. I have not headed into the literature of the analysis of
old-signs-new approaches, but I’m pretty confident that such analyses exist
and would be helpful here. Has anyone delved into such mechanisms for
other PKIs and the measures that have been used in such PKIs to make the
key roll process more robust?

Geoff

---

From: Russ Housley <[email-masked]>
Date: Wed, 28 Jul 2021 18:44:24 -0400

> Perhaps I am overlooking something?

I think we need to consider graceful transition from one trust anchor key to another separately from recovery from key compromise.

RFC 4210 has a discussion on graceful transition that uses old-in-new and new-in-old so that not all relying parties need to transition at the same time.  The validity period in the old-with-new and new-with-old provide bounds on the transition time period.

Russ

---

From: Tim Bruijnzeels <[email-masked]>
Date: Thu, 29 Jul 2021 10:58:54 +0200

Hi all,

> On 29 Jul 2021, at 00:44, Russ Housley <[email-masked]> wrote:
> 
> 
> 

Indeed recovering from a key compromise (theft) is a different ball game altogether.

The primary motivation for starting this (when I was still at RIPE NCC and operating a TA) was to deal with the migration from one HSM vendor to another. So the intent is not to be able to deal with a *compromised* TA key (which hopefully would have been kept in an HSM) - but to allow that key A in HSM A can sign the transition to key B in HSM B and then be destroyed.

I believe this is addressed in the security considerations section. Pasting for convenience:

9.  Security Considerations

   Because a TA key can mark itself as revoked and require clients to
   start using a new key, an adversary that gains access to a TA's
   current key and its associated publication servers can essentially
   take over the TA.

   This risk can be mitigated by the use of Hardware Security Modules
   (HSMs) by TAs, which will guard against theft of a private key, as
   well as operational processes to guard against (accidental) misuse of
   the keys in an HSM by operators.

   An example where planned rolls are useful is when a TA is using an
   HSM from vendor X, and they want to migrate to an HSM from vendor Y.

   Alternate models of TAL update exist and can be complementary to this
   mechanism.  For example, TAs can liaise directly with validation
   software developers to include updated and reissued TAL files in new
   code releases, and use existing code update mechanisms in the RP
   community to distribute the changes.

> RFC 4210 has a discussion on graceful transition that uses old-in-new and new-in-old so that not all relying parties need to transition at the same time.  The validity period in the old-with-new an…

I should probably put RFC 4210 on my reading list. Still, this document (signed-tal) as written is trying to define graceful transitions from A to B where relying parties do not need to migrate at the same time. Did you find any specific issues with the proposal in this regard?

Sections 6 and 7 talk about maintaining multiple TA keys in parallel and performing key rolls. The TAK object is introduced to automate this transition for RPs which support this. The document also talks about distributing TAL files for RPs which do not support TAK files. See section 7.3:

   The TA must also release a new TAL file for key 'B', as the intended
   key to be used by RP software.  As described above, it SHOULD use a
   different set of URIs in the TAL compared to the TAK file, so that
   the TA can learn the proportion of RPs that can successfully validate
   and use the updated TAK objects.

   To support RPs that do not take account of TAK objects, the TA should
   continue operating key 'A' for a period of time after it has been
   marked as revoked.  The length of that period of time is a local
   policy matter for that TA: it might operate the key until no clients
   are attempting to validate using it, for example.

(Rereading this I believe that it would be best to s/must/MUST/ in the first sentence above.)

I guess that what I am trying to say here is that I believe this document already includes a mechanism for doing a graceful transition for RPs which do NOT support this. I.e. even if the working group were to conclude that automated transitions using TAK files are not desired, then sections 6 and 7 are imo still relevant.

Tim

---

From: Ben Maddison <[email-masked]>
Date: Thu, 29 Jul 2021 15:06:59 +0200

Hi Tim,

> The primary motivation for starting this (when I was still at RIPE NCC and operating a TA) was to deal with the migration from one HSM vendor to another. So the intent is not to be able to deal wit…
Ack.
Re-reading with the benefit of your's and George's comments, the procedure
makes far more sense to me.

I think this needs spelling out far more explicitly throughout the
draft. It should not take email correspondence with the authors to
discern the intended use-case.

On reflection, I think that actually recommending that this
mechanism *not* be used in response to (suspected) key theft is
appropriate: better the TA goes away altogether for some period of time,
than risk an undetectable takeover.

Related to this, I also think "revoked" is a poor choice of word to
describe the status of the "old" TA.
For me, revoked means "no longer trustworthy", whereas in this procedure
the trust in the old key must be maintained for (at least) the purpose
of validating the TAK/MFT/CRL.
Perhaps "decommissioned" is a better choice, indicating that it will no
longer be used to issue new objects, and should be used only build a
chain to a successor.

Cheers,

Ben

---

From: Randy Bush <[email-masked]>
Date: Thu, 29 Jul 2021 09:42:36 -0700

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.

randy

---

From: Russ Housley <[email-masked]>
Date: Thu, 29 Jul 2021 12:47:09 -0400

Randy:

If old is compromised, the old-with-new lets the attacker's bugus stuff validate back to the new trust anchor, so please do not do that.

Russ

> On Jul 29, 2021, at 12:42 PM, Randy Bush <[email-masked]> wrote:
>

---

From: Russ Housley <[email-masked]>
Date: Thu, 29 Jul 2021 13:16:24 -0400

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

Russ

---

From: Randy Bush <[email-masked]>
Date: Thu, 29 Jul 2021 10:17:51 -0700

> 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

---

From: Tim Bruijnzeels <[email-masked]>
Date: Fri, 30 Jul 2021 17:53:55 +0200

> On 29 Jul 2021, at 19:17, Randy Bush <[email-masked]> wrote:
> 

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