On Sep 11, 2020, at 20:13, Paul Hoffman <[email protected]> wrote:
> Primarily because that is only of value to resolvers that are validating, and > that's the small minority of resolvers. Which of large resolver operators is not validating ? Which of the stock opensource resolvers is not validating with a default configuration ? Arguably the only ones left not validating are phones and we are busy giving them DoH and DoT to servers that do that for them. I think your argument does not hold. > Secondarily because "just stuff" leads to errors that will lead to resolvers > failing to get answers. That’s not different from web servers. It’s 2020, if you still require an unencrypted or in authenticated protocol, you are doing it wrong. Surely, we should not be designing for it. The only reason to do opportunistic encryption is when authentication or identity management is hard. This is simply not true for authoritative DNS servers. > >> This is not rocket science. We already do TLSA for email at large scale >> now. > > You somehow missed the word "opportunistic" in that sentence. SMTP was largely opportunistic due to fear and complexity of getting certificates working. Since ACME that is no longer the case and it is as easy to setup postfix with acme as it is using selfsigned certs. At this point I would also argue against opportunistic for SMTP, although the case for SMTP is stronger due to mail relays within networks that cannot gets a public cert because they are not public. > Opportunistic encryption to authoritative servers is just too silly. > > Many people disagree. > >> I am strongly opposed to doing this work. > > You continue to say that without writing up your use case for review in this > WG (or anywhere, as far as I can tell). The best way to support your use case > it to write it down, not just snipe at those who have written theirs down. How do I write up a use case of “don’t overengineer for complex crypto that might accidentally skip authentication of your encryption and cause security vulnerabilities to support people who can only create selfsigned certificates for their DNS server” ? Paul _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
