On Sep 12, 2020, at 6:19 AM, James <[email protected]> wrote: > > 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.
There is nothing in the current proposal that specifies the protocol that the two sides use. Additional protocol discovery methods can be added; we just didn't have any other desired protocols at this time. > Is there any reason besides simplicity you didn't consider using the ALPN as > identifier? Simplicity counts. :-) However, if you want to use an ALPN method, this document certainly does nothing to prevent that. > 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. There is no value in opportunistic encryption to use DANE or any other way of authenticating the TLS server. Paul Wouters has said that he does not support encrypting more DNS traffic using opportunistic encryption, but so far has not written up his use case for regular (authenticated) encryption where some DNS lookups would be blocked due to inability to authenticate. Maybe you could write up such a use case and send it to this WG so they can compare use cases? --Paul Hoffman
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
