Re: [dane] RPK use-case high level problem statement

[Viktor Dukhovni <[e-mail]>]

On Thu, Jun 05, 2014 at 07:13:24PM -0700, John Gilmore wrote:

> >     3. Some subset of servers will have TLSA RRsets during transition
> >        states, not currently defined as "misconfigured", such that
> >        X.509 DANE TLSA authentication works, but RPK DANE TLSA
> >        authentication fails, because the RPK-compatible TLSA RRs
> >        match only past or future keys.
> 
> I do not agree with this and am still awaiting a communication from
> you about why you think this will occur.  Normally, key transitions
> are done by moving from publishing "current" keys, to "current/future"
> keys by adding the future keys.  Those then become "past/current" keys
> when the server's key itself changes, and then are moved to "current"
> keys by dropping the past keys.

Done under separate cover.  Some key rotation scenarios involve
changes from TA issued keys to self-issued keys or the converse.

Or sometimes even simply a change from "3 0 1" with old keys to
a deliberate "3 1 1" with new keys (to make them RPK compatible).


> At no point do the TLSA records in a key rollover include only
> "past/future" keys.  TLS would fail if they did so.

The total set of TLSA RRs indeed always contains present keys when
the server is not misconfigured.  But there is (today) no guarantee
that the "3 1 X" subset of the TLSA RRset contains any present
keys.  I am proposing to document this issue.  We've not yet agreed
on who's responsible for the work-around (client, server, both).

-- 
	Viktor.