Re: [dns-privacy] draft-ghedini-dprive-early-data

[Alessandro Ghedini <[e-mail]>]

Hello!

On Wed, Aug 21, 2019 at 03:06:30PM +1000, Martin Thomson wrote:
> I only just noticed this (don't know why).  I don't know the status of discussion either, so apologies if this isn't appropriate.  The draft is expired, but I felt motivated to comment since I seem to understand the problem a little bit.

Thanks for the review. The draft is still very much alive (also, the -01 version
expires in January next year AFAICT, so not expired either :). I presented it in
Montreal (though due to conflicts between dprive and httpbis/cfrg sessions a few
interested parties probably missed it).

> TLS early data could be useful for DNS, even if it is less useful given that the cost of connection establishment is amortized quite well in most cases [1].  That assessment might differ depending on your views of the relative merits of endpoints doing their own recursion.
> 
> 1. This draft could lean more heavily on RFC 8470 and 8446 for detail on TLS early data works and its effects.  The bulk of the intro and even the main section are just reiterations of stuff from there.  Not that that text is bad or wrong, just that it isn't really DNS-specific.  For instance, the ALPN piece probably doesn't need to be repeated.

So, looking at RFC8470 specifically, it doesn't seem like HTTP-independent
pieces (e.g. the ALPN wording you mentioned) can be easily referenced on their
own. E.g. if I just reference "RFC8470, Section 2" wouldn't it be too confusing
that that section also has a bunch of HTTP-specific content?

But good point about referencing RFC8446 more closely, I'll see what I can do.

> 2. The draft needs to more clearly identify what might be safe to send.  All the draft concretely does is forbid a few things.  If this were just queries, with everything else not allowed unless stated, that might be enough.

Indeed, this was also the feedback from previous review. Currently tracked at
https://github.com/ghedo/draft-ghedini-dprive-early-data/issues/2

> 3. How does this advice differ for recursive vs. authoritative?  I think that the advice is probably going to be largely applicable to both, but the zone transfer thing seems to be one clear example of a difference worth highlighting.  So you should say "everything except" or - by scoping - concentrate on a use case where there are no differences.  And say that there are no differences.

I guess the main difference between recursive and authoritative from the early
data POV comes down to what queries might be accepted. So the solution for the
previous point somewhat generalizes this (i.e. instead of framing in terms of
"authoritative servers should disallow zone transfers" it becomes "if server
would normally accept query X, it should/should not allow it over early data"),
unless I misunderstood what you saying.

But the security considerations might need to be more specific.

> 4. The advice about stateful rotation in 4.1 needs to condition the recommendation on accepting early data.  I'm sure that stateful rotation is fine absent a replay risk.

ACK.

> 5. Along the lines of the design in 8470... Is there any signal that might be generated by a recursive resolver toward an authoritative if the recursive is forwarding a query that might have been replayed?  Is there a need for a response indicating that the request should be tried again outside of early data?  I can't see DNS servers holding queries until the handshake completes, so that's unlikely to be a solid recommendation.  Of course, a recursive cannot ensure that the authoritative understands an optional signal in the same way we require reverse proxies to check with origin servers, and a non-optional signal is just going to fail the "can I deploy this" sniff test.  All that to say just that I don't know what the answer is myself, but it sure would be nice if someone could tell me.

I thought about this, but as you say it would probably be difficult to deploy
safely. There also doesn't seem to be as much of a need for this in the DNS
case, as whether a specific query is safe or not over ealy data is pretty clear
cut, and it seems unlikely that servers would have much need to disallow a
subset of the ones that are safe (as opposed to HTTP, where e.g. the server
might want to disallow some GETs dependning on how they are handled).

Cheers