Yes, this is worth doing. Agree with comments that it has to be
compatible with non-opportunistic encryption.
R's,
John
PS: RFC 7435.
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
Regards,
John Levine, [email protected], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
