Re: [dane] Extending TLSA RFC to operate with TLS's new raw public keys

[Viktor Dukhovni <[e-mail]>]

On Fri, Jun 06, 2014 at 11:35:04AM -0400, Paul Wouters wrote:

> Okay, I understand this example now and your desire to not mixup TLSA
> types. However, the operations document could simply advise not to
> combine a key rollover with a usage/type/selector rollover at once,
> which seems more appropriate than banning all other valid scenario's
> that mixup type such as:
> 
>  	IN TLSA 2 0 1 {current TA}
>  	IN TLSA 3 1 1 {current leaf}

I am not suggesting to ban mixed TLSA RRs. Rather, I was suggesting
that clients encountering mixed TLSA RRs might want to avoid RPK, but
we'll handle that question in the other thread.

To your point about transitions and changing one thing at a time,
yes that's the right high-level description of the BCP TLSA RRset
change strategy.  Keep all other things fixed and apply one of:

    * Add future keys presented with the same U/S/M combinations as
      existing keys.

    * Remove all U/S/M combinations for legacy keys leaving only
      current keys.

    * Add new U/S/M combinations that match the same keys as existing
      U/S/M combinations.

    * Remove all records with a given U/S/M combination.

    * Or combine the two previous and replace one U/S/M combination with
      another, while still matching the same set of keys.

The required invariant is that at all times each currently published,
or not yet expired from DNS caches, U/S/M combination comtains at
least one record that matches the current server keys.

Whether or not client RPK behaviour includes any work-arounds for
"mixed" TLSA RRsets, the above should be a BCP for server TLSA RRset
management.

-- 
	Viktor.