Ben Campbell has entered the following ballot position for draft-ietf-dprive-dns-over-tls-07: Yes
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dprive-dns-over-tls/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 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? _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
