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

[Viktor Dukhovni <[e-mail]>]

On Wed, Jun 04, 2014 at 10:22:33AM -0400, Paul Wouters wrote:

> >(skip oob when somewhat likely to fail and the client implements use of PKIX certs).
> 
> It's not "likely to fail" when there is an exising "3 1 x" TLSA record
> published!

Sure it is, those record might match only a future or past server
key when other RR parameter combinations are also present.  Unless
we define such transitions as invalid, and publish server-operator
guidelines that place the burden on the server to avoid such states.

Is that the WG's preference?  I can strengthen the key rotation
guidelines in the OPs draft (looks like it is about to morph into
a standards track 6698 update) to require server operators to avoid
transition states in which any of the published C/U/M combinations
match only future or only past keys.  This requires some attention
to detail when updating TLSA RRs, and a tricky process when
switching from "311" to "201":

    1. 311 old self-signed leaf

    2. 311 old leaf + 311 new DANE-TA issued leaf  (wait for 1 to age out
       then deploy new cert chain).

    3. 201 new DANE-TA issued chain (previously published as 311 in step 2).

at each stage there are now C/U/M combinations that don't match
any "active" key.

> Leaves me puzzled even more about what you _are_ trying to convey as
> the requirement for not mixing "3 1 x" and other types.

Consider the above transition from a 311 self-signed cert to a
DANE-TA(2) issued cert, in which the server operator is in a hurry,
and we've not yet mandated the above process:

    1. 311 old self-signed leaf

    2. 311 old (still active) leaf + 201 planned TA

	(wait for 1 to age out, then activate new chain).

    3.  Drop 311 leaving only 201.

This this, "oob" clients lose at step 2 when the new chain is
activated, but the RRset has "311" only for obsolete keys and a
"201" for the active keys.  Note, this is not a "misconfiguration"
in any sense with respect to 6698, and is not a problem prior to
the introduction of "oob" negotiation.

-- 
	Viktor.