The results are indeed interesting. And also surprising. It would be
nice to tease out what is inherent to the specification, what is caused
by choices or bugs in the early implementation, and what may be caused
by the testing process.
The paper points out the effect of amplification attack prevention.
Amplification prevention is of course a good thing. Even Do53
implementations should do a version of it, using DNS Cookies. But
clearly, it can impede performance. I checked my implementation of QUIC,
and it does not enforce amplification prevention if the initial packet
carried a valid new token -- but it would if the source IP address of
the initial packet did not match the IP address to which the new token
was sent. We would not want a botnet to use a valid new token! Could you
verify that the IP source address used in your measurements remains
constant?
You trace amplification prevention kicking in to the large size of TLS
certificates sent by servers. I checked in my implementation of QUIC and
found that when a session is resumed, the server response does not
include a CERT extension. There is no need to send the certificate
again, it was already verified by the client in the session being
removed. In resumption traces, the Initial packets and the Handshake
packet sent by the server are both a few hundred bytes, and fit in a
single UDP packet. Are the early server implementations are buggy? Or
does the test client wait too long before resuming the connection, so
the server finds that the ticket has expires and goes through a full
connection setup?
The paper mentions that most first connections experience a "retry".
That seems like a deployment choice at the server. The amplification
protections in theory make this process unnecessary. It would be
interesting to know why servers chose to do that for all connections.
Are they under constant DOS attacks?
So many questions...
-- Christian Huitema
On 2/8/2022 3:05 AM, James wrote:
Thanks for paper, and your results are very interesting.
One area that would be interesting to focus on is HTTP versions, I would expect
the performance characteristics between them to be notably different, and it
appears your client supports HTTP/2, but I can't see if you distinguish the
version in your dataset or if you are only sending the HTTP/2 ALPN. More
importantly for future work would be comparing DoH3 with DoQ - this is
something folk have been thinking about[0] and there are very few resolvers
that I'm aware that offer it but may answer questions around the real-world
impact of HTTP overheads.
- J
0: https://mailarchive.ietf.org/arch/msg/quic/roPNRcYwKpHBaYjOuHxzqGTEWp0/
On 8 Feb 2022, at 11:14, Mike Kosek <[email protected]> wrote:
Dear dprive WG,
Over the past 6 months, we measured the adoption of DNS over QUIC (and the
different drafts) on resolvers worldwide, and evaluated their performance in
comparison to DoUDP, DoTCP, DoT as well as DoH. The paper recently got accepted
at PAM 2022, and might be of interest to the WG:
One to Rule them All? A First Look at DNS over QUIC
https://arxiv.org/abs/2202.02987
Please find the abstract below this email. We also published the raw data of
our measurements on github:
https://github.com/kosekmi/2022-pam-dns-over-quic
While we plan to build up on this work in future studies, we are happy to get
feedback of what might be of interest to the WG - please get back to us with
any feedback or suggestions!
Best,
Mike, Viet, Malte, Vaibhav
TUM Technical University of Munich
---- Abstract ----
The DNS is one of the most crucial parts of the Internet. Since the original
DNS specifications defined UDP and TCP as the underlying transport protocols,
DNS queries are inherently unencrypted, making them vulnerable to eavesdropping
and on-path manipulations. Consequently, concerns about DNS privacy have gained
attention in recent years, which resulted in the introduction of the encrypted
protocols DNS over TLS (DoT) and DNS over HTTPS (DoH). Although these protocols
address the key issues of adding privacy to the DNS, they are inherently
restrained by their underlying transport protocols, which are at strife with,
e.g., IP fragmentation or multi-RTT handshakes - challenges which are addressed
by QUIC. As such, the recent addition of DNS over QUIC (DoQ) promises to
improve upon the established DNS protocols. However, no studies focusing on
DoQ, its adoption, or its response times exist to this date - a gap we close
with our study. Our active measurements show a slowly but steadi
l
y increasing adoption of DoQ and reveal a high week-over-week fluctuation,
which reflects the ongoing development process: As DoQ is still in
standardization, implementations and services undergo rapid changes. Analyzing
the response times of DoQ, we find that roughly 40% of measurements show
considerably higher handshake times than expected, which traces back to the
enforcement of the traffic amplification limit despite successful validation of
the client's address. However, DoQ already outperforms DoT as well as DoH,
which makes it the best choice for encrypted DNS to date.
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
