On Wed, Sep 30, 2015 at 02:24:49PM -0400, Warren Kumari wrote: > > > I'd love to be able to publish these two documents, declare success > and shut this WG down... but I'm assuming that the WG simply hasn't > finished reviewing these, so, pretty please, review and provide > feedback...
Some random comments from quick reading (might be quite off-base): Both: 1) I think that (D)TLS profiling, authentication and privacy profiling should be harmonized between the documents. It seems that the problem is (almost) identical, yet the solutions described look different. After all, TLS and DTLS are very similar crypto capability-wise (I think the only difference is that RC4 does not work in DTLS). DNS-over-TLS (-00): 1) Section 3.2: Is the section about authentication just examples or is it missing stuff like pinning RPK of the server? Also, DNS servers are usually designated by IP, but certificates work by domain name... 2) Section 3.3: I presume each request or reply SHOULD also be inside just one TLS record (but multiple queries/responses can be combined into a single one)? DNS-over-DTLS (-01): 1) Section 2: Obsolete reference, should be upgraded to WG DNS-over-TLS draft? 2) Section 3.1: Also some kinds of NAT could interact badly with DTLS on UDP port 53 (specifically, those applying special lifetime rules on that port). 3) Section 3.2: The SPKI fingerprint example could use explicit specification of the hash function (seems to be SHA1 in the example). 4) Section 6: That is from before decision to switch to dedicated port? I would imagine multiplexing on port 53 would cause problems with: - All sorts of DNS proxies (these are infamous for various creative "interpretations" of DNS). - Some NATs that might apply special rules on UDP/53 - Some anti-reflection firewall rules (DTLS handshake looks like answer, which are only allowed in, not out). - All sorts of strange middleboxes. I think the dedicated port is both TCP and UDP, and this would get the UDP one. 5) Section 7: Plain public keys reference should be RFC 7250? DTLS heartbeat is infamous. Additionally, it isn't very well-suited for MTU determination. 6) Section 10: How would replying with DTLS alert be implemented? IIRC (but this might be wrong), with connection in SHOWTIME, alerts from server to client are encrypted, but the server doesn't have the keys to construct the message. One possible way would be to mirror SRTP mux. DTLS packet first octet is record type, which is always 20-63 for DTLS. SRTP mux sends non DTLS packets using first octets outside that range. Also, this smae mechanism probably goes for dealing with client address change (sometimes that changes rather frequently). 7) Multiple sections: Multiple places seem to refer to some sort of shim layer that does not seem to be defined anywhere. -Ilari _______________________________________________ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
