Hi all-- Thanks for the start-tls-for-dns draft! i'm happy to see it. I have a few pieces of feedback below...
------ A structural nit: the draft has no Table of Contents -- can you update whatever drafting toolchain you're using to include one? they're helpful for people trying to navigate the document. ------ The third bullet point in section 2.2 of https://tools.ietf.org/html/draft-ietf-dprive-start-tls-for-dns-00 says: o The DNS client sends a TO=1 query and receives a TO=1 response, but the middlebox does not understand the TLS negotiation and does not allow those packets to pass through. "those packets" is confusing here -- my first reading of it took me a couple tries to see that it wasn't talking about the query and response in the first sentence. It should probably say "does not allow the TLS handshake packets to pass". ------ section 3.1 says: Opportunistic privacy can be used by any current client, but it only provides privacy when there are no on-path attackers. It should probably say "no on-path active attackers", since it still provides privacy against on-path passive eavesdroppers. ------ section 3.2 says: With pre-deployed privacy, a client retains a copy of the TLS certificate and IP address of each provider. The client will only use one of those DNS providers. Because it has a pre-deployed TLS certificate, it may detect person-in-the-middle and downgrade attacks. I'm not sure that "certificate" is the relevant thing that a client wants to cache here. For example, a client could instead use one of the following options: * a long-term public key (and the certificate itself could be re-issued as long as it retains the same key, or could be sent as a raw public key (RFC 7250), or a TLSA record, etc) * the equivalent of an HPKP pinset (a digest of two or more public keys that should be present somewhere in the certificate chain) plus a name of the peer * a PSK, for use with one of the TLS PSK modes * the name of the peer and a X.509 trust anchor list Or maybe some combination of the above. I'm not sure that this draft is the place to specify all of these options, of course, but limiting it to "the TLS certificate of each provider" seems unnecssesarily constrained. (This is partly addressed in item 4 of the security considerations section, but seems to be in conflict) ------ DNSSEC-trigger is mentioned but has no reference. perhaps a pointer to https://www.nlnetlabs.nl/projects/dnssec-trigger/ or somewhere else would be worth including? ------ The Security Considerations section does not mention traffic analysis at all. The sizes of DNS packets and their timing may turn out to be significant, and this draft should at least mention these concerns. ------ There is no Privacy Considerations section, but there probably should be. RFC 6973 is a good resource here. ------ The draft mentions TCP Fast Open; it may also want to mention the TLS False Start protocol optimization: https://tools.ietf.org/html/draft-ietf-tls-falsestart-00 ------ hope these comments are helpful, --dkg
signature.asc
Description: PGP signature
_______________________________________________ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
