>>>>> "VD" == Viktor Dukhovni <[email protected]> writes:
VD> 3. Some subset of servers will have TLSA RRsets during transition VD> states, not currently defined as "misconfigured", such that VD> X.509 DANE TLSA authentication works, but RPK DANE TLSA VD> authentication fails, because the RPK-compatible TLSA RRs VD> match only past or future keys. Now I see why/where we disagree. In the case where the server's current key cannot be verified by a RPK- compatible TLSA, and where the server publishes TLSA at all, it is a mis-configuration to permit the server to negotiate RPK. Just because a client sends the RPK extension does not mean that the server must or will agree. If the admin knows that no published RPK-compatible TLSA will verify the key which the server currently would send to an RPK client, said admin SHOULD configure the server to refuse the RPK extension. Servers which expect their RPK clients to authenticate the SPKI via LDAP or pre-shared knowledge SHOULD NOT publish TLSA which cannot verify the current SPKI without also publishing TLSA which can do so. (This is why the last paragraph is only a SHOULD rather than a MUST.) Servers which expect their RPK clients to authenticate the SPKI via TLSA MUST publish at least one TLSA which can verify the current SPKI. It seems extremely unlikely to me that, as RPK support is added to the various TLS libraries, that it will be enabled by default. It is vastly more likely that explicit configuration will be required by any server software to enable support for RPK. Perhaps even requiring that the SPKI to be sent to RPK clients be in a file outside of any 509 container, rather than auto-extracted as needed. The likelyhood, therefore, of servers suddenly negotiating RPK unbeknownst to their admins is negligible. Admins who want to enable RPK and want to support DANE verification of the bare SPKIs should be expected always to include a suitable record in their TLSA set. -JimC -- James Cloos <[email protected]> OpenPGP: 0x997A9F17ED7DAEA6 _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
