On Sun, Feb 28, 2021 at 7:09 PM Paul Wouters <[email protected]> wrote: > On Thu, 25 Feb 2021, Eric Rescorla wrote: > > > There are (at least) three reasons: > > 1. Semantically, TLSA does not mean "I support TLS", but rather "if you > are to do TLS, do it this way. SVCB means something > > different. > > We tried hard to make it mean "You should only use TLS", but the webpki > people freaked out and blocked the DANE WG until this compromise was > reached. In my opinion, any client that publishes TLSA records for a > service means that you should reach it over TLS and hard-fail. No > one really means "you may do TLS but if insecure cleartext is your cup > of tea, that's fine with me too". >
ISTM that these are the precise common semantics of the Web. I.e., it's quite common for hosts to be reachable over both HTTP and HTTPS, with the method of connection being defined by the referring URL. Indeed, they're different origins and sometimes the servers serve different content depending on the access method. This is one of the things that makes it somewhat difficult to build systems like HTTPS Everywhere. HSTS allows the host to override this, but the basic semantic of "I offer TLS" is not "you must reach me over TLS" > > No, because there are existing deployments, so we can't just retcon the > meaning. > > That would be the retcon of "If you can do TLS, please prefer TLS over > insecure cleartext" instead of the original meaning "This is my TLS. It > is secure but you are welcome to use this completely insecure > version instead - I claim no preference" > I'm not quite sure what you mean by "original" meaning, but the relevant meaning is what's encoded in the specifications. I don't necessarily object to having this be TLSA, but given that we are standardizing a record whose precise purpose is to signal what services are available at a given location, it seems to me natural to use that. -Ekr
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
