(resending this to the list, apologies Paul) Thank you for writing this draft. Just two observations:
1. The absence of protocol agility bothers me - whilst I do not think the use case described in this document lends to DoH in particular being suitable, DoQUIC and not-yet-existent protocols could also be applicable. Is there any reason besides simplicity you didn't consider using the ALPN as identifier? 2. I disagree on the points around authentication and section 2 could be updated to better encourage adopters to implement matching TLSA records for the certificate they present during the TLS handshake - with a clear statement that recursives are not required to query this record type before TLS negotiation, nor explicitly fail if it mismatches. - J On Fri, 11 Sep 2020 at 22:39, Paul Hoffman <[email protected]> wrote: > Greetings. The discussion of encrypting the recursive to authoritative > traffic keeps getting bogged down due to lack of use cases. Puneet and I > would like to propose a specific use case (the desire to encrypt much more > traffic, even if there could be an active attacker in the middle). With > that in mind, we wrote up < > https://tools.ietf.org/html/draft-pp-recursive-authoritative-opportunistic>. > The abstract says: > This document describes a method for a DNS recursive resolver to use > opportunistic encryption when communicating with authoritative > servers. The method here is optional for both the recursive resolver > and the authoritative server. A 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. Nothing in this > method prevents use cases that require better encryption. > > We would like DPRIVE to adopt this, and we are open to suggestions on how > to improve the protocol. > > --Paul Hoffman_______________________________________________ > dns-privacy mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dns-privacy >
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
