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

Hi all,

> On 29 Jul 2021, at 00:44, Russ Housley <housley@vigilsec.com> wrote:
> 
> 
> 
>> On 29 Jul 2021, at 7:42 am, Ben Maddison <benm=40workonline.africa@dmarc.ietf.org> wrote:
>> 
>> 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?
> 
> I think we need to consider graceful transition from one trust anchor key to another separately from recovery from key compromise.

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 and new-with-old provide bounds on the transition time period.

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

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