> Perhaps we can at least agree on the high-level problem statement:
>
> 1. Some clients will support both X.509 and RPK TLS handshakes,
> and will opportunistically negotiate RPK as an optimization.
Agreed.
> 2. Some subset of those clients with use DANE authentication to
> authenticate whichever of X.509 or RPK is negotiated.
Agreed (s/with/will/).
> 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.
At no point do the TLSA records in a key rollover include only
"past/future" keys. TLS would fail if they did so.
> 4. Somebody (client, server or both) should do something to avoid
> unnecessary application failure under the above conditions.
Disagree, based on not seeing why 3 is anything but a mistake made
by naive or unskilled administrators.
> 5. We should probably write-up the potential problem cases,
> and spell out client and server responsibilities and strategies
> to avoid the problem cases. Either client is conservative
> and avoids opportunistic RPK, or server avoids publishing
> potentially problematic RRsets or both. We should probably
> not recommend "retries" see [Footnote], but for some clients
> retries might be a viable strategy.
I thought we had already done that by explaining in detail how to do
key rollovers. See Appendix A.4 of RFC 6698. If you try to change
keys and you do it wrong, your service will become inaccessible. The
cure is to do it right, not to contort the protocol.
PS- you do the same rollover process when changing the "A" record of
your server. This is not specific to TLSA, DANE, DNSSEC, or RPK.
Would you argue that the protocol should somehow accommodate
administrators who, while trying to change their A record from 1.2.3.4
to 5.6.7.8, somehow foolishly publish 1.2.3.4 and 9.10.11.12? Of
course when the server at 1.2.3.4 goes down, all attempts to connect
will be broken. The server at 5.6.7.8 will be sitting there ready,
but nobody will connect to it. There is no recovery until the "A"
records are corrected. The TLSA situation is directly analogous.
John
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
