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.
2. Some subset of those clients with use DANE authentication to
authenticate whichever of X.509 or RPK is negotiated.
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.
4. Somebody (client, server or both) should do something to avoid
unnecessary application failure under the above conditions.
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.
--
Viktor.
Footnote:
Client retries will typically be futile, because a DANE authentication
failure with RPK for past/future keys cannot be distinguished from
other reasons for the server keys not matching. Clients that retry
will often fail to authenticate even after negotiating the use of
X.509 keys.
Retries are also difficult to hide in client libraries, because
often connection management is done by the application, while
the TLS protocol engine is handled by a suitable library. Thus
applications will have to be willing to retry, and somehow know
to tell the library to avoid RPK the second time around.
Connection setup can be expensive, and reconnection difficult.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
