On 7/17/2019 6:44 AM, Alessandro Ghedini wrote: > On Tue, Jul 09, 2019 at 10:25:15PM -0400, Ben Schwartz wrote: >> Thanks for writing this up. Your recommendation makes sense to me, and I >> think it will be useful in practice. >> >> One thought: instead of rejecting unsafe 0-RTT data with FormErr, could we >> tell servers to reject the early data at the TLS layer to force a >> retransmission? That seems like it might be simpler to implement on both >> sides, and just as safe.
Servers could also be programmed to not advertise support for early data in the TLS 1.3 session resumption tickets. This will automatically prevent the client from even trying 0-RTT. > The problem is that the decision of whether you accept or reject early data > happens before the application had a chance of actually reading it, so you > don't > know whether a specific DNS query can be allowed before deciding to reject all > of the early data. Also, there could potentially be multiple queries in the > early data. That's a real problem when the TLS layer has to support multiple application,such as for a DoH service hosted over a general purpose HTTP server. It is much less of a problem for DoT. > > HTTP solved this by defining a special HTTP status code that instructs the > client to retry only the affected request(s), so the server could, after > accepting early data at the TLS layer, execute some of the early data requests > but not all of them. Maybe we could do something similar with extended DNS > errors (draft-ietf-dnsop-extended-error)? Though I don't know how useful this > would be in practice. The threat model here is an attacker that can observe the traffic flowing from the resolver to the authoritative servers. I suppose that the attack does not work if the response comes from cached data. But generally, yes, if clients are concerned with privacy they should not attempt to use 0-RTT. Note that this is not just an issue of replay by attackers. You also have to be concerned with the "session resumption ticket" acting as a super cookie, and allowing the server to link the resumed session with the previous one, thus exposing more of the client's "history". -- Christian Huitema
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
