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

[Tom Harrison <[e-mail]>]

On Sun, Mar 06, 2022 at 06:02:25PM -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 Trust Anchor Key
>         Authors         : Carlos Martinez
>                           George G. Michaelson
>                           Tom Harrison
>                           Tim Bruijnzeels
>                           Rob Austein
> 	Filename        : draft-ietf-sidrops-signed-tal-09.txt
> 	Pages           : 18
> 	Date            : 2022-03-06
> 
> 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 planned key rolls without
>    impacting RPKI validation.

To summarise the changes in -09:

 - acceptance timers (similar to those in RFC 5011) for transition to
   new keys have been added;
 - the term 'revoked' is avoided, so that there is no confusion around
   semantics; and
 - the predecessor key is included in the TAK object, as an additional
   check that things are set up correctly.

Feedback on this updated model would be appreciated.

The changes in more detail: in the feedback on -07, there were various
pointers to alternative approaches to TA rollover, and suggestions
that we look into that topic more generally.  Notes on this feedback:

 - RFC 4210: Certificate Management Protocol (CMP)
    - The process in RFC 4210 is that the root CA operator signs the
      old key with the new key, and the new key with the old key,
      which the clients can then fetch from the CA operator.  That
      means that clients who trust the old key can validate
      certificates signed with the new key, and clients who trust the
      new key can validate certificates signed with the old key.
    - It's not clear that this work translates to RPKI, though.  The
      mechanism in RFC 4210 appears to be designed to account for
      out-of-band TA distribution, as well as clients receiving
      certificates from other sources.  Since the aim with signed TAL
      is to have TA distribution be in-band, and also considering that
      all certificates are stored in a repository, it doesn't appear
      that this work will help here.

 - RFC 8649: Hash Of Root Key Certificate Extension
    - This document defines a process where the TA can include the
      hash of the next TA key in their current TA certificate, and
      then clients can transition on seeing that new certificate.
    - Tim commented on this on the list: a couple of issues are that
      some RPs might not ignore the extension (compare the situation
      with a new signed object, which would definitely be ignored),
      and it also limits the ability to transition once the
      certificate has been replaced (i.e. once the new TA certificate
      is published, the old TAL data can no longer be used).
    - Another consideration is that RPKI supports arbitrary reissuance
      of the TA certificate, so there would need to be additional
      guidance around what the RP should do when the extension is
      removed, or when a new hash is seen, and how long the hash
      should be in place before a new TA using the associated key will
      be accepted, and so on.

 - Web PKI generally
    - It doesn't appear that key rollover happens in this context.  It
      looks like root CA operators simply issue new root CA
      certificates as required, and then rely on cross-certification
      for clients that aren't configured to trust the new root CA.

 - RFC 5011: Automated updates of DNSSEC TAs
    - The acceptance timer behaviour from this document seems like a
      useful way to guard against the problems raised around key
      compromise, and has been added to the document.  With a timer,
      an attacker who gains access to the TA key and publication point
      is no longer able to immediately transition all clients to a key
      and publication point controlled solely by the attacker, which
      is helpful.
    - Including this delay also deals in part with some of the support
      for a "sign in advance"-type model.

As far as literature/reference material on TA rollover more generally
is concerned, we couldn't find any.  Any pointers would be
appreciated.

The other main piece of feedback from last time was to do with using
the term 'revoked' to describe TA keys that aren't current, because
those 'revoked' keys will still be trusted by clients configured with
the corresponding TAL, and an attacker who gains access to that key
and publication point will still be able to cause trouble for any
client configured with that TAL data who hasn't transitioned to the
new key.  This was addressed by avoiding the use of the term 'revoked'
in the TAK object and the document, so as to avoid any confusion
around semantics, and also by advising TAs to reuse TA certificate
URLs for new keys, once they stop maintaining the previous keys hosted
as those points.  That will inhibit the use of the previous key by an
attacker, since the URL will be in use for a different current key.

The only other substantive change to the document since -07 is the
inclusion of the predecessor key in the TAK object.  This allows a
relying party to confirm that the successor intends to operate as the
successor for this specific key.  This is just an extra check to make
sure that things are set up correctly.

Separately, there was a suggestion that we look into the versions of
validators that are in use, to see how long it takes people to upgrade
to current versions.  The graph of this data for September 2021
through February 2022 is attached to this mail.  The data is taken
from APNIC's RRDP service, as at the last day of each month.  The
Y-axis is in terms of client ASNs, where individual IP addresses were
mapped to ASNs by looking at data from BGP.  Each ASN was only counted
for the most up-to-date validator that was seen running from it.

Only validators that provide version information in the user agent
string were taking into account: Routinator, FORT, the RIPE validator,
OctoRPKI, and rpki-prover.  Version information for each validator was
taken from the tags in the corresponding Github repository.  Requests
directly from browsers were discounted, while all other requests were
placed in the 'Unknown' category.

The key points from this data are that 30-50% of the known validators
are running code that is more than one year behind the current version
of that validator, and there are a large number of unknown clients
hitting RRDP services (probably a substantial portion of these clients
are rpki-client, though).  To rely on signed TAL as the principal
transition mechanism for TA rollover, it's likely that a concerted
effort would need to be made on getting clients to upgrade once the
associated RP code is in place, as well as getting a better
understanding of the clients in the 'Unknown' category.

-Tom