Specification for DNS over Transport Layer Security (TLS)
RFC 7858
Yes
No Objection
Note: This ballot was opened for revision 06 and is now closed.
Alvaro Retana No Objection
(Alissa Cooper; former steering group member) Yes
(Barry Leiba; former steering group member) Yes
-- Section 3.1 -- A DNS server that supports DNS-over-TLS MUST listen for and accept TCP connections on port 853. By mutual agreement with its clients, the server MAY, instead, use a port other than 853 for DNS-over-TLS. Is it really "instead" (in which case the previous sentence isn't unqualified "MUST"), or is it "in addition? That is, which of these is correct?: NEW-1 A DNS server that supports DNS-over-TLS MUST listen for and accept TCP connections on port 853. By mutual agreement with its clients, the server MAY, in addition, use a port other than 853 for DNS-over-TLS. END NEW-2 A DNS server that supports DNS-over-TLS MUST listen for and accept TCP connections on port 853, unless it has mutual agreement with its clients to use a port other than 853 for DNS-over-TLS. END (And similarly for the client side in the following paragraph.)
(Ben Campbell; former steering group member) Yes
I'm balloting yes, but I do have a few comments/questions: - 3.1, third paragraph: This seems to put normative requirements on clients and servers that do not implement this draft. If that is really needed, then perhaps this needs to update the appropriate base spec(s)? - 3.2, last paragraph: That's a bit of an odd use of SHOULD. I suggest s/SHOULD/can - 3.3: This section seems more about DNS over TCP in general. Is it specific to TLS? Are the 2119 keywords in this section new requirements, or do they describe existing requirements from 5966/7766? (If the latter, please consider stating them with descriptive language rather than normative language.) - 4 and subsections: There seems to be a notable absence of a profile that requires server authentication but does not require pinning. I assume there's a good reason for that which is obvious to people with stronger TLS and/or DNS backgrounds than mine. But it might be helpful to say why. Do (or should) the profiles have anything to say about clear-text fallback if a client cannot connect to the server's DNS-over-TLS port, or the TLS handshake fails? I infer that such fallback should not occur with the pinned profile, but what about the opportunistic profile?
(Brian Haberman; former steering group member) Yes
I am a definite Yes on this work, but just have a couple of comments... * Section 3.1 says "By mutual agreement with its server, the client MAY, instead, use a port other than port 853 for DNS-over-TLS. Such an other port MUST NOT be port 53..." It would be useful to *briefly* explain the MUST NOT. If it is by mutual agreement, what's the harm? * Section 3.2 uses the SPKI acronym before it is expanded in section 4.2. * I do not understand the last sentence of section 3.2, especially the "SHOULD".
(Spencer Dawkins; former steering group member) Yes
(Stephen Farrell; former steering group member) (was Discuss) Yes
Many thanks for doing this work. I look forward to using DNS in this way. I had a discuss but the changes indicated at [1] are plenty good. [1] https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-dprive-dns-over-tls-07.txt&url2=https://raw.githubusercontent.com/paulehoffman/draft-hzhwm-dprive-start-tls-for-dns/master/draft-ietf-dprive-dns-over-tls.txt
(Terry Manderson; former steering group member) Yes
(Alia Atlas; former steering group member) No Objection
(Benoît Claise; former steering group member) No Objection
(Deborah Brungard; former steering group member) No Objection
(Jari Arkko; former steering group member) No Objection
(Joel Jaeggli; former steering group member) No Objection
(Martin Stiemerling; former steering group member) No Objection