Subject: [dns-privacy] Study on the adoption and performance of DNS over QUIC

From: Mike Kosek <[email-masked]>
Date: Tue, 8 Feb 2022 11:14:56 +0100

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 steadily 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.

---

From: James <[email-masked]>
Date: Tue, 8 Feb 2022 12:05:33 +0100

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-masked]> wrote:
> 
> Dear dprive WG,
> 
> https://arxiv.org/abs/2202.02987
> 
> https://github.com/kosekmi/2022-pam-dns-over-quic
> 
> _______________________________________________
> dns-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy

---

From: Christian Huitema <[email-masked]>
Date: Tue, 8 Feb 2022 10:03:56 -0800

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:
>> 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.

---

From: Mike Kosek <[email-masked]>
Date: Wed, 9 Feb 2022 16:46:03 +0100

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…
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-masked]> 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
>

---

From: Vladimír Čunát <[email-masked]>
Date: Wed, 9 Feb 2022 17:16:43 +0100

On 09/02/2022 16.46, Mike Kosek wrote:
> we do not observe significant differences between the HTTP versions

HTTP 1.1 would surely have performance issues in practical use due to 
head of line blocking, especially if some answers take long to resolve.  
Sure you can work around that by opening multiple connections, but 
that's ugly and probably also not practical because of handshake latency.

--Vladimir | knot-resolver.cz

---

From: Mike Kosek <[email-masked]>
Date: Wed, 9 Feb 2022 18:02:43 +0100

> HTTP 1.1 would surely have performance issues in practical use due to head of line blocking, especially if some answers take long to resolve.  Sure you can work around that by opening multiple connections, but that's ugly and probably also not practical because of handshake latency.
Thanks for your comment - I agree. However, we are issuing single queries in our study on newly established connections - hence, we have no issues with HoLB, and thus do not see significant differences between the HTTP versions.

> On 9. Feb 2022, at 17:16, Vladimír Čunát <[email-masked]> wrote:
> 
> HTTP 1.1 would surely have performance issues in practical use due to head of line blocking, especially if some answers take long to resolve.  Sure you can work around that by opening multiple connections, but that's ugly and probably also not practical because of handshake latency.
>

---

From: Vladimír Čunát <[email-masked]>
Date: Wed, 9 Feb 2022 18:22:13 +0100

> Thanks for your comment - I agree. However, we are issuing single queries in our study on newly established connections - hence, we have no issues with HoLB, and thus do not see significant differe…

Yes, I knew.  That might actually be a meaningful future improvement of 
your test-bed.  Even other protocols (except plain UDP, I guess) do not 
really imply that HoLB is avoided in the particular implementation, 
though I'd assume that mostly it's OK: 
https://dnsprivacy.org/implementation_status/#servers  (OOOR line)

---

From: Christian Huitema <[email-masked]>
Date: Wed, 9 Feb 2022 12:35:24 -0800

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). 
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 
establishedsessions for subsequent queries, as well asTLS 1.3 0-RTT 
between sessions in afuture 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:
> 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.
>
> 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?
>
> certificates sent by servers. I checked in my implementation of QUIC 
> and found that when a session is resumed, the server response does not 
>> 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/
>>
>>> 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:
>>>
>>> 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,
>>> 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.

---

From: Mike Kosek <[email-masked]>
Date: Thu, 10 Feb 2022 16:54:54 +0100

> 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-masked]> 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
> 
>>> 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-masked]> <mailto:[email-masked]> wrote: 
>>>> 
>>>> Dear dprive WG, 
>>>> 
>>>> [email-masked] <mailto:[email-masked]> 
>>>> https://www.ietf.org/mailman/listinfo/dns-privacy <https://www.ietf.org/mailman/listinfo/dns-privacy> 
>>> [email-masked] <mailto:[email-masked]> 
>>> https://www.ietf.org/mailman/listinfo/dns-privacy <https://www.ietf.org/mailman/listinfo/dns-privacy> 
>> [email-masked] <mailto:[email-masked]> 
>> https://www.ietf.org/mailman/listinfo/dns-privacy <https://www.ietf.org/mailman/listinfo/dns-privacy>

---

From: "libor.peltan" <[email-masked]>
Date: Thu, 10 Feb 2022 17:07:46 +0100

Anyway, do you think that the "typical" recursive-to-authoritative query 
in DoQ era will be a session resumption, or a clean new connection 
without any chance of 0-RTT or counter-amplification-limit-token? I 
agree that both cases could be explored, but the latter one is still a 
good start.

/Libor

Dne 09. 02. 22 v 21:35 Christian Huitema napsal(a):
> resumption." 
> (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, 
> 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 establishedsessions for subsequent 
> queries, as well asTLS 1.3 0-RTT between sessions in afuture study". 
> Please do that!
>
> 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
>
>> caused by choices or bugs in the early implementation, and what may 
>> be caused by the testing process.
>>
>> 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?
>>
>>>> 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:
>>>>
>>>> these protocols address the key issues of adding privacy to the 
>>>> DNS, they are inherently restrained by their underlying transport 
>>>> 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

---

From: Christian Huitema <[email-masked]>
Date: Thu, 10 Feb 2022 11:22:33 -0800

I am not sure. There is a fair bit of concentration in the 
"authoritative server" market. I see measurements 
(https://ithi.research.icann.org/graph-m9.html) showing that Go Daddy, 
Cloudflare and AWS have a fairly big share of this market. Add Akamai, 
Dyn and Google to the mix, and probably a couple of others, and you get 
40% of names served by a small number of servers. For that set, I would 
expect that the typical DoQ query will be a session resumption. For 
smaller servers, maybe not. And yes, there is an aspect of concentration 
there. As if more encryption encouraged more concentration.

-- Christian Huitema

On 2/10/2022 8:07 AM, libor.peltan wrote:
> Anyway, do you think that the "typical" recursive-to-authoritative 
> query in DoQ era will be a session resumption, or a clean new 
> connection without any chance of 0-RTT or 
> counter-amplification-limit-token? I agree that both cases could be 
> explored, but the latter one is still a good start.
>
> /Libor
>
>> (https://twitter.com/MikeKosek/status/1491351241695592454). This are 
>> a very serious limitations of the test client. The performance of DNS 
>> are mentioned in the conclusion, in which the authors "plan to 
>> further evaluate DoQ by using previously establishedsessions for 
>> subsequent queries, as well asTLS 1.3 0-RTT between sessions in 
>> afuture study". Please do that!
>>
>> 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
>>
>>> 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?
>>>
>>> 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?
>>>
>>> interesting to know why servers chose to do that for all 
>>> connections. Are they under constant DOS attacks?
>>>
>>> So many questions...
>>>
>>> -- Christian Huitema
>>>
>>>> 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: 
>>>>> 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
>>>> 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.

---

From: James Cloos <[email-masked]>
Date: Thu, 10 Feb 2022 15:34:42 -0500

>>>>> "CH" == Christian Huitema <[email-masked]> writes:

CH> and you get 40% of names served by a small number of servers. For that set,
CH> I would expect that the typical DoQ query will be a session  resumption.

does quic session resumption correctly work in the face of any-cast servers?

IU that tls s-r often fails in such cases, yes?

-JimC
-- 
James Cloos <[email-masked]>         OpenPGP: 0x997A9F17ED7DAEA6

---

From: Christian Huitema <[email-masked]>
Date: Thu, 10 Feb 2022 16:47:13 -0800

On 2/10/2022 12:34 PM, James Cloos wrote:

>>>>>> "CH" == Christian Huitema<[email-masked]>  writes:

It depends. If anycast routing points back to the same server, life is 
good. If it goes to a different location, that depends on the 
deployment, and the way the server farms manage their session tickets.

There is also a QUIC option for quickly migrating a connection from 
anycast to unicast, the "preferred address" parameter. If the server 
uses that option, the client migrates to the preferred address as soon 
as the handshake completes, keeping the same encryption context, etc. 
The goal was to make sure that long QUIC connection remain stable, even 
if anycast routing changes. I imagine that if a client receives session 
tickets and new tokens from the preferred address, it could attempt 
session resumption directly at that address. We may want to clarify that 
in the QUIC WG.

-- Christian Huitema