I think opportunistic or unauthenticated encryption is worth pursuing. However, your quote also says "use authentication when possible", and I agree. I would like to avoid selecting an opportunistic encryption design that doesn't match well with our authenticated encryption design, so I think that means we need to develop them together.
On Thu, Aug 6, 2020 at 10:59 AM Paul Hoffman <[email protected]> wrote: > Greetings again. The following is a short text-based version of my slides > from last week's WG meeting. I'd like to find out if this is one of the use > cases that the WG would be interested in dealing with. > > Use case: Opportunistic encryption for recursive to authoritative > > In this use case, a resolver operator says “I’m happy to use encryption > with the authoritative servers if it doesn’t slow down getting answers by > much”, and an authoritative server says “I’m happy to use encryption with > the recursive resolvers if it doesn’t cost me much”. > > Opportunistic encryption is defined in RFC 7535. From the abstract: > "Protocol designs based on Opportunistic Security use encryption even when > authentication is not available, and use authentication when possible, > thereby removing barriers to the widespread use of encryption on the > Internet." > > The assumptions behind the use case are: > • More encryption is good for the Internet > • Resolver vendors are smart and motivated > • Most resolvers don’t validate with DNSSEC and may never want to > • Authoritative operators don’t care much about encryption, but some would > turn it on because more encryption is good for the Internet > • Other use cases for authentication stronger than opportunistic may > appear and would co-exist with this one > > The other slides had thoughts about possible solutions that implement this > use case, but before we go there, I wanted to find out if more than a > handful of people here are interested in this use case. If so, I could turn > the above into a draft with some possible solutions for us to bang on. > > --Paul Hoffman > > _______________________________________________ > dns-privacy mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dns-privacy >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
