Thank you for your comments! > 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 > We can distinguish the HTTP versions of the DoH measurements in our dataset: We see around 96% measurements over HTTP/2 and 4% over HTTP/1.1. However, we do not differentiate between them in our analysis since we do not observe significant differences between the HTTP versions (also, the sample size of HTTP/1.1 is quite low). Thanks for the hint on DoH3, we’ll take a look!
> 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? We made sure that the subsequent query is sent from the same src ip and port a few seconds after the initial query was finished and closed. During early measurements, we observed that not only the change in client IP address lead to a server denying the token (which was expected), but also that a change in src port may lead to a token rejection (which was unexpected). Our best guess for this is load balancing: the subsequent query hits another endpoint, which does not know about the token since tokens are not shared between the servers. > 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? Sorry for not being clear on that in the paper: we are not using TLS session resumption, but we will consider this in the future. Let me briefly elaborate on the measurement process: The first query warms the DNS cache, where we receive a RETRY packet - hence, the Handshake is extended by 1-RTT. Following the Handshake, we get a token in a NEW_TOKEN frame, which we use in our subsequent session a few seconds later (send from the same src ip and port). 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) if 3x the amount of client-send data is reached. The client has to send an ACK before the server resumes sending data - hence, the Handshake is extended by 1-RTT > 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? In fact, around 97% of first connections experience a RETRY. We agree that the combination of both address validation and the enforcement of the amplification limit is unnecessary, and that the RETRY looks more like a deployment choice. How is it handled on your implementation @Christian? Maybe other implementors can also pitch in. We are happy to share some exemplary tcpdumps on the observed behaviour. We also collected the qlogs of the subsequent queries, which we used to ensure that the anti-amplification limit (as observed in the exemplary tcpdumps) is actually the problem in all subsequent measurements - the qlog data is available on Github [1]. Best, Mike [1] https://github.com/kosekmi/2022-pam-dns-over-quic <https://github.com/kosekmi/2022-pam-dns-over-quic> > On 8. Feb 2022, at 19:03, Christian Huitema <[email protected]> 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/ >> >>> 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 steadil >> 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
