> Mike Kosec mentioned on Twitter that "We do not use TLS session resumption." > (https://twitter.com/MikeKosek/status/1491351241695592454 > <https://twitter.com/MikeKosek/status/1491351241695592454>). This are a very > serious limitations of the test client. The performance of DNS over QUIC > depend a lot on the support of 0-RTT and, failing that, session resumption. > The test client performs two queries at short intervals: a first one to > "prime the cache", and a second one a few seconds later. If the client > supported 0RTT, the second query would execute in a single round-trip. Not > supporting 0RTT implies that the second query will require at least two > round-trips. Also not supporting session resumption implies that the server > first flight will require a couple of kilobytes of overhead, instead of a few > hundred bytes. These limitations are not mentioned in the "methodology" > section of the paper, and I think they should be. They are mentioned in the > conclusion, in which the authors "plan to further evaluate DoQ by using > previously established sessions for subsequent queries, as well as TLS 1.3 > 0-RTT between sessions in a future study". Please do that! >
Fair point, thanks for starting the discussion on that. We are currently working on support for TLS session resumption and 0-RTT, which will make its way into our tooling. > Mike also wrote on Twitter that "We get no RETRY packet in the second > session, so the token is accepted by the server. However, we are still bound > by the anti-amplification limit, as the server stops sending data (the server > cert)." Both issues, the retry and the amplification limit, can be traced to > deployment choices and software issues in some of the early implementations > of DNS over QUIC. Servers do not always need to issue a Retry packet on every > first connection from a new IP address -- the amplification limits are > designed to make that optional. Servers definitely don't need to enforce the > amplification limits if they receive a valid token in the initial packets, > that looks very much like a bug. > Thanks for conforming our assumptions. It will be interesting to see if, and how fast, the upcoming standardisation will lead to people updating their implementations and deployments, hopefully addressing these issues. > But then, buggy servers are a fact of life, and measurement studies like > those described in the paper are a good way to find out the what deployed > servers do: how many enforces Retry on the first connection, how many support > 0-RTT or Session Resumption, how many enforce amplification limits despite a > valid new token? It would be great if the second version of this measurement > paper reported on that! > We'll do! > On 9. Feb 2022, at 21:35, Christian Huitema <[email protected]> wrote: > > The paper is titled "A first look at DNS over QUIC", and I very much would > like to see the second look. The first look contains very interesting > reporting on the usage of DNS over QUIC, serious efforts made to find out > which servers already support a version of DoQ. That part is great, but the > actual measurements are very much affected by limitations of the test client > and bugs in early implementations. > > Mike Kosec mentioned on Twitter that "We do not use TLS session resumption." > (https://twitter.com/MikeKosek/status/1491351241695592454 > <https://twitter.com/MikeKosek/status/1491351241695592454>). This are a very > serious limitations of the test client. The performance of DNS over QUIC > depend a lot on the support of 0-RTT and, failing that, session resumption. > The test client performs two queries at short intervals: a first one to > "prime the cache", and a second one a few seconds later. If the client > supported 0RTT, the second query would execute in a single round-trip. Not > supporting 0RTT implies that the second query will require at least two > round-trips. Also not supporting session resumption implies that the server > first flight will require a couple of kilobytes of overhead, instead of a few > hundred bytes. These limitations are not mentioned in the "methodology" > section of the paper, and I think they should be. They are mentioned in the > conclusion, in which the authors "plan to further evaluate DoQ by using > previously established sessions for subsequent queries, as well as TLS 1.3 > 0-RTT between sessions in a future study". Please do that! > > Mike also wrote on Twitter that "We get no RETRY packet in the second > session, so the token is accepted by the server. However, we are still bound > by the anti-amplification limit, as the server stops sending data (the server > cert)." Both issues, the retry and the amplification limit, can be traced to > deployment choices and software issues in some of the early implementations > of DNS over QUIC. Servers do not always need to issue a Retry packet on every > first connection from a new IP address -- the amplification limits are > designed to make that optional. Servers definitely don't need to enforce the > amplification limits if they receive a valid token in the initial packets, > that looks very much like a bug. But then, buggy servers are a fact of life, > and measurement studies like those described in the paper are a good way to > find out the what deployed servers do: how many enforces Retry on the first > connection, how many support 0-RTT or Session Resumption, how many enforce > amplification limits despite a valid new token? It would be great if the > second version of this measurement paper reported on that! > > -- Christian Huitema > > On 2/8/2022 10:03 AM, Christian Huitema wrote: >> 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/ >>> <https://mailarchive.ietf.org/arch/msg/quic/roPNRcYwKpHBaYjOuHxzqGTEWp0/> >>> >>>> On 8 Feb 2022, at 11:14, Mike Kosek <[email protected]> >>>> <mailto:[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 <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 >>>> <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] <mailto:[email protected]> >>>> https://www.ietf.org/mailman/listinfo/dns-privacy >>>> <https://www.ietf.org/mailman/listinfo/dns-privacy> >>> _______________________________________________ >>> dns-privacy mailing list >>> [email protected] <mailto:[email protected]> >>> https://www.ietf.org/mailman/listinfo/dns-privacy >>> <https://www.ietf.org/mailman/listinfo/dns-privacy> >> _______________________________________________ >> dns-privacy mailing list >> [email protected] <mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/dns-privacy >> <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
