> There are also timing subtleties, are TLSA records located before
> the TLSA handshake or during the handshake once the server provides
> key material. If the latter (which I don't recommend...
It is my belief that the reason we have no web browsers that support
DANE is because it would likely reduce the latency of web transactions
that involve https. Browser vendors compete on how quickly they can
go from the user typing "eff.org" to showing the EFF home page. They
use all kinds of tricks (like doing DNS lookups on the part before the
first slash, while the user is still typing the rest of the URL; or
matching on the URLs of previous visits from this browser), to reduce
that latency.
If clients that support DANE and RPK require that a full DNSSEC TLSA
lookup begins and ends before the client can start any TLS negotiation
-- even to sites that are not using raw public keys -- then this
latency will increase. Which means even less chance of practical
adoption of DANE (and less chance of practical adoption of RPK) in the
real world web browsers.
That's why I am trying to avoid such a requirement. DANE is a good
idea, but to the extent that we require them to be slower than the
currently widespread TLS implementations, DANE may never be adopted in
realtime clients that have a user watching them run.
John
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
