Greetings again. Based on the request of the WG during last week's meeting, I have updated my draft to flesh out some of the ideas we discussed. As noted in the abstract and in the body of the draft, this version only proposes using pot-checking for discovery, even though that is not likely to be the final proposal.
For those of you interested in the use case described in the document, please review and discuss how this might be improved. For those of you not interested in the use case described in the document, there was a few pleas during the WG meeting for fleshed-out drafts on fully authenticated encryption for DNS. --Paul Hoffman A new version of I-D, draft-pp-recursive-authoritative-opportunistic-03.txt has been successfully submitted by Paul Hoffman and posted to the IETF repository. Name: draft-pp-recursive-authoritative-opportunistic Revision: 03 Title: Recursive to Authoritative DNS with Opportunistic Encryption Document date: 2020-11-25 Group: Individual Submission Pages: 9 URL: https://www.ietf.org/archive/id/draft-pp-recursive-authoritative-opportunistic-03.txt Status: https://datatracker.ietf.org/doc/draft-pp-recursive-authoritative-opportunistic/ Htmlized: https://datatracker.ietf.org/doc/html/draft-pp-recursive-authoritative-opportunistic Htmlized: https://tools.ietf.org/html/draft-pp-recursive-authoritative-opportunistic-03 Diff: https://www.ietf.org/rfcdiff?url2=draft-pp-recursive-authoritative-opportunistic-03 Abstract: This document describes a use case and a method for a DNS recursive resolver to use opportunistic encryption (that is, encryption with optional authentication) when communicating with authoritative servers. The motivating use case for this method is that more encryption on the Internet is better, and opportunistic encryption is better than no encryption at all. The method here is optional for both the recursive resolver and the authoritative server. Nothing in this method prevents use cases and methods that require authenticated encryption. IMPORTANT NOTE: This version of the document describes discovery whether an authoritative server supports encryption using port- checking. This restriction is based on the request of the DPRIVE WG during its meeting at IETF 109. It is quite likely that the final protocol will include a better set of methods for such discovery.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
