Thanks for the references. I haven't been keeping up with this WG, so apologies for coming to them both anew.
I don't have any violent feedback, but I'd be disappointed to see a system port allocated for these proposals right now. System ports are scarce and precious and it would be better to be responsible and to have some real-world deployments and traction before allocating one. I have a now-defunct non-system UDP and TCP port (4166) assigned to me, which people are welcome to re-use for experimentation. (I've never figured out how to return that port, maybe this is an out). Some of my reasoning: * The documents describe using a dedicated port and re-using port 53. If re-using port 53 turns out to be more popular, the dedicated port seems like a waste. * I wonder if the goals of DNS privacy are actually enhanced by encouraging as much "overloading" of port 53 as possible. By having different traffic types share that port, it may discourage or penalize, fingerprinting more generally. * I've implemented TLS and DNS a few times each, and without meaning to be inflammatory; they don't seem like a good match for each other to me. I'm pretty skeptical about adoption. * That aside, both documents are poorly specified. Why the note about disabling compression, but no consideration of regular size-based side-channel leaks? why is one kind of compression ok, but not the other? how should TLS authentication be handled? is it intended to use PKI? or PSK or some alternative? if it's PKI, how are the circular dependencies on DNS resolved? what happens when a query crosses the boundary between two or more TLS sessions and auth contexts? for the SPKI scheme, what happens when you need to change the signature format or algorithm? for the DTLS cases - how do you reason about replay attacks and DNS server behavior; for example, if I as a MITM replay a DTLS DNS query can I observe the rotation of a multi-RR RRSET to derive what the q-tuple was? I probably can, right? Which seems like a privacy leak. The docs say that a single DTLS session can be used for multiple queries, do we rely purely on queryid + q-tuple to disambiguate them or do we also look at the DTLS record numbers? are there MITM attacks where the extremely small query-id space can be abused to derive the plaintext? e.g. if I replay responses from elsewhere in the stream, with 2^16 responses then I can produce arbitrary matches - could that leak data or allow me to poison caches? should there therefore be a limit on the number of responses per PRF stream? can an attacker do interesting things if they can engineer a DNS response to be split across DTLS records at interesting boundaries? On Mon, Aug 10, 2015 at 5:32 PM, Paul Hoffman <[email protected]> wrote: > On 10 Aug 2015, at 16:35, Colm MacCárthaigh wrote: > > > Quick question: What document is "the document"? > > Two: draft-ietf-dprive-dnsodtls and draft-ietf-dprive-start-tls-for-dns. > > --Paul Hoffman > -- Colm
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
