Re: [dns-privacy] Early port allocation request for dns-over-TLS

[Colm MacCárthaigh <[e-mail]>]

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 <[e-mail]> 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