On 9/26/2018 4:15 AM, Tony Finch wrote:
> Christian Huitema <[email protected]> wrote:
>> The basic QUIC handshake will be 1-RTT before sending the first query,
>> with two exceptions:
> Thanks for those details!
>
>> Using 0-RTT is a trade-off between security and performance, because
>> 0-RTT packets can be subject to replay attacks. That's true for 0-RTT in
>> QUIC and also 0-RTT in TLS. If you are really concerned about privacy,
>> the prudent decision is to not use 0-RTT.
> Correct me if I'm wrong, but my understanding is that the 0RTT replay
> attack is not a privacy problem, but is a problem if the payload has
> undesirable side-effects. The 0RTT privacy problem is the same as for TLS
> session resumption: the session details can be used to track clients.
An attacker could replay the 0-RTT packet, and observe whether it
creates a particular side effect at the server end. For example, replay
the traffic from client to recursive, and observe whether the resolver
issues a query to particular DNS server. I think DKG did the analysis in
details. He should probably elaborate.
> For privacy-conscious clients, I think it makes sense to use session
> resumption for the lifetime of a particular layer 2/3 network connection,
> and drop session tokens when roaming to a different connection. So you
> benefit from the improved performance while the server has other ways to
> track you, but it's harder for the server to track clients from place to
> place.
>
> (this is more of a stub -> recursive concern rather than recursive ->
> authoritative)
There is indeed that other issue with 0-RTT and session resumption. It
provides the server with a tracking cookie.
>
>> If 0-RTT is enabled, QUIC performs better than either UDP or TCP in all
>> scenarios; if it is not, QUIC still performs slightly better than TCP or
>> TLS, because it does not suffer from head of line blocking.
> QUIC is something nice to look forward to :-)
Yes...
-- Christian Huitema
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
