Subject: Quic: the Elephant in the Room

From: Michael Thomas <[email-masked]>
Date: Mon, 19 Apr 2021 11:34:00 -0700

Hi all,

I wrote a blog post called Quic: the Elephant in the Room and posted it 
to the ietf list which generated a lot of comments, so maybe it's 
worthwhile for this list to consider as well. The jist is getting the 
Quic startup exchange back down to a 3 way handshake and very analogous 
to the original TCP handshake. It can be implemented using a DANE-like 
approach, or could be TLS could be extended to allow clients to cache 
server certificates.

My main purpose for writing it is because a Google-like company could 
actually implement it just like they did with Quic itself to see how it 
behaves in real life.

https://rip-van-webble.blogspot.com/2021/04/quic-elephant-in-room.html

Mike

---

From: Matt Joras <[email-masked]>
Date: Mon, 19 Apr 2021 13:45:48 -0700

Hi,

Note that there is a TLS feature which reduces the crypto (TLS) data
needed to be sent during the handshake considerably, resumption. The
vast majority of QUIC connections in our deployment (and TCP + TLS for
that matter) are resumed. In a typical resumed connection the total
crypto data transferred is around 500 bytes in both directions.
Resumption is also less CPU intensive on the server than a fresh
handshake.

There is always an opportunity for using DNS features in a clever way
to improve things. I would say though that the complexity, especially
since it introduces out-of-band dependencies, makes it a hard sell for
someone to implement and explore without a really compelling reason
(i.e. data showing that there is a huge opportunity). Resumption makes
this particular concern a non-issue for most real world connections
and has other positive benefits.

Matt Joras

---

From: Michael Thomas <[email-masked]>
Date: Mon, 19 Apr 2021 14:02:26 -0700

> and has other positive benefits.
Well, the overall point of my post was that it would be interesting to 
run an experiment and that Google, MS and Apple would be in a good 
position to do that. Out of  all of this I found out that Google doesn't 
DNS sign their zone which is a little shocking. But it's sort of hard to 
call DNS "out of band" since it's needed for A/AAAA records and as my 
flow showed the TLSA record could be requested at the same time as the 
A/AAAA lookup which would on average not stall the handshake (and of 
course, RR's are cached). If you wanted to be really clever, the TLSA RR 
could be stapled to the name lookup too.

When I was looking this over with Wireshark it sure seemed like it was 
mostly doing a 5 message handshake, but it was hard to make a lot of 
sense because... encrypted.

Mike, i'll check out TLS resume though

---

From: Paul Vixie <[email-masked]>
Date: Mon, 19 Apr 2021 21:13:44 +0000

hello. can you explain how you get from:

On Mon, Apr 19, 2021 at 01:45:48PM -0700, Matt Joras wrote:
> ... The
> that matter) are resumed.

to:

> ... Resumption makes

that is, how is your deployment known to represent most real world use?

i love resumption -- that's why RFC 6013 had it. but i also love DANE, which
is having strong success in the SMTPS market but has been eschewed by the
HTTPS market. thus my question as to how the QUIC team is prioritizing use
cases. "big tech" is shiny but not nec'ily representative of the whole web.

-- 
Paul Vixie

---

From: Matt Joras <[email-masked]>
Date: Mon, 19 Apr 2021 14:32:12 -0700

Hi Paul,

> that is, how is your deployment known to represent most real world use?

There was implied context to those statements. In Mike's blog post and
subsequent emails it is clear he's talking about typical Internet
browser-like use cases, which is why he suggests someone "Google-like"
might benefit from this sort of system to reduce the amount of data
transferred during the handshake. I am referring to the same class of
usage when I say "most real world connections". Perhaps I should have
qualified more but I figured that was implicit.

> cases. "big tech" is shiny but not nec'ily representative of the whole web.

Again, Mike's blog post is specifically suggesting that this might be
worthwhile for a "big tech" company to explore. I am simply giving a
couple reasons why this may not be the case from my perspective.

Matt Joras

---

From: Roberto Peon <[email-masked]>
Date: Mon, 19 Apr 2021 21:35:03 +0000

Connecting to the wrong place costs more than slightly longer handshake, and I suspect often happens because our name mapping solution is a host mapping solution, whereas for many use-cases today we need object mapping, since it is impractical to host every object in every place the service exists.
 
The object mapping problem is one of the reasons why I'd originally hoped to get something like DoH into HTTP2 (server push of a DoH-equivalent record plus a redirect allows for good object-> address mapping).
That combination didn't happen, but the problem that made it interesting to think about still persists-- getting the mapping right matters more than a little bit more data being sent in the handshake.

Ideally, such an object mapping would be targetable, redistributable, and dynamic.
We've been using this internally for storage-related things (i.e. not just the read() part, but the write() and associated other calls as well), and it has helped quite a bit. I imagine it'd help for the web/HTTP as well. 

-=R

On 4/19/21, 2:14 PM, "QUIC on behalf of Paul Vixie" <[email-masked] on behalf of [email-masked]> wrote:

    -- 
    Paul Vixie

---

From: Michael Thomas <[email-masked]>
Date: Mon, 19 Apr 2021 14:46:08 -0700

> qualified more but I figured that was implicit.
To put a fine point on it, I'm saying a Google-like company is in the 
position to run an *experiment* just like they did for Quic. Apparently 
Chrome at one point supported DANE but Google didn't do the obvious and 
support it server side so they could find out whether it could make a 
difference or not. They took it out when predictably nobody supported it.

Mike

---

From: Michael Thomas <[email-masked]>
Date: Mon, 19 Apr 2021 15:18:15 -0700

> Resumption is also less CPU intensive on the server than a fresh
Ok, I just looked up TLS Restore and it has the problem that it needs to 
keep fairly hard state in the typical case where there are a lot of 
servers listening. A Cloudflare blog post said that they use memcached 
which implies that they have to do a out of band lookup for the 
session-id. To my mind, it sort of begs the question of why you'd ever 
kill the transport session in the first place, but that's the browser's 
choice to make.

That's in contrast to the DANE or client cert caching solutions which 
cache on the client side and would be fairly rarely be waiting for the 
TLSA RR, and no state of any kind is required at all in the backend. So 
I don't think this is exactly a slam dunk. That Cloudflare even wrote a 
blog post about it shows that Restore introduces operational complexity 
at the very least.

Mike

---

From: Lucas Pardue <[email-masked]>
Date: Mon, 19 Apr 2021 23:33:05 +0100

I'm struggling to see what the problem statement that is unique to the QUIC
protocol is.

That certificates can be large is not new information, it was a prime
motivator for RFC 7924 [1] and RFC 8879 [2].

Operators can, of course, experiment with new optimal ways of doing things.
The broader IETF community is likely interested in the outcome of such
experiments. Since QUIC version 1 uses TLS, any changes that stand to
improve a QUIC handshake would likely be applicable to TLS too. So the
concept of replacing current TLS mechanisms with the DNS doesn't seem to be
something the QUIC WG should be leading. Should such work identify QUIC
protocol design evolution or extension, then it could be suitable for WG
consideration.

Cheers,
Lucas

[1] https://datatracker.ietf.org/doc/rfc7924/
[2] https://datatracker.ietf.org/doc/rfc8879/

---

From: Michael Thomas <[email-masked]>
Date: Mon, 19 Apr 2021 15:39:09 -0700

On 4/19/21 3:33 PM, Lucas Pardue wrote:
> I'm struggling to see what the problem statement that is unique to the 
> QUIC protocol is.
>
> Operators can, of course, experiment with new optimal ways of doing 
> things. The broader IETF community is likely interested in the outcome 
> of such experiments. Since QUIC version 1 uses TLS, any changes that 
> stand to improve a QUIC handshake would likely be applicable to TLS 
> too. So the concept of replacing current TLS mechanisms with the DNS 
> doesn't seem to be something the QUIC WG should be leading. Should 
> such work identify QUIC protocol design evolution or extension, then 
> it could be suitable for WG consideration.
>
I'm not asking this working group to do anything. Just socializing 
something that generated a lot of discussion on the IETF list that might 
be of interest to the Quic community.

Mike

---

From: David Schinazi <[email-masked]>
Date: Tue, 20 Apr 2021 10:07:03 -0700

Hi Mike,

I read your blog post, and I failed to find what problem you're trying to
solve.
The fact that some handshakes spend a couple packets on certificates?
We can actually quantify the user-visible impact of the handshake size, and
from everything I've seen this particular topic isn't impactful enough to
solve,
apart from ensuring support for RFC 8879. It's even less realistic if the
solution involves the minor task of switching PKIs and roots of trust.
Speaking as one of the QUIC tech leads at a "Google-like company", I can
ensure you that we don't spend time on experiments that don't benefit users.
It seems that you have a solution in search of a problem here.

David

---

From: Michael Thomas <[email-masked]>
Date: Tue, 20 Apr 2021 10:15:23 -0700

On 4/20/21 10:07 AM, David Schinazi wrote:
> Hi Mike,
>
> I read your blog post, and I failed to find what problem you're trying 
> to solve.
> from everything I've seen this particular topic isn't impactful enough 
> to solve,

I thought the entire point of QUIC (aside from HoL blocking) was to cut 
down the number of packets needed to start a connection. From what I can 
tell, it takes it from an 8 packet exchange to a 5 packet exchange. If 
you were to use a DANE-like solution that would be a 3 packet exchange 
most of the time. Why is a 5 packet exchange good but a 3 packet 
exchange not?

Mike

>
> David
>
> On Mon, Apr 19, 2021 at 3:39 PM Michael Thomas <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>

---

From: David Schinazi <[email-masked]>
Date: Tue, 20 Apr 2021 10:20:22 -0700

Cutting down the number of packets was never a goal for QUIC.
The goal was to save round trips in connection establishment,
as that significantly impacts user-visible latency. The number of
packets only slightly increases the probability of loss during the
handshake which can be correlated to user-visible latency, but
much less.

I'm not saying that a 3-packet handshake would be bad, I'm saying
that it's not worth boiling the ocean to remove 2 packets. I'll also
note that your proposal doesn't fully reduce the number of packets
because you still need a DNS TLSA request and response, and loss
of those is much worse as DNS retransmissions are less optimized.

David

On Tue, Apr 20, 2021 at 10:15 AM Michael Thomas <[email-masked]> wrote:

> tell, it takes it from an 8 packet exchange to a 5 packet exchange. If you
> were to use a DANE-like solution that would be a 3 packet exchange most of
> the time. Why is a 5 packet exchange good but a 3 packet exchange not?
>
> Mike
>
>
>
> David
>

---

From: Michael Thomas <[email-masked]>
Date: Tue, 20 Apr 2021 10:31:18 -0700

> of those is much worse as DNS retransmissions are less optimized.

Signing your DNS zone is considered "ocean boiling" now? Really? And I 
didn't claim that it would "fully" reduce the number of packet, though 
that could be accomplished if TLSA records were stapled to the A/AAAA 
lookup. Half of this has already been done by Google when they 
implemented DANE for Chrome. All it would take is for them to dust off 
that code and sign their zone. Is Google really incapable of deploying a 
20 year old standard?

Mike

>
> David
>
> On Tue, Apr 20, 2021 at 10:15 AM Michael Thomas <[email-masked] 
>>     I read your blog post, and I failed to find what problem you're
>>     trying to solve.
>>     from everything I've seen this particular topic isn't impactful
>>     enough to solve,
>     I thought the entire point of QUIC (aside from HoL blocking) was
>     to cut down the number of packets needed to start a connection.
>     From what I can tell, it takes it from an 8 packet exchange to a 5
>     packet exchange. If you were to use a DANE-like solution that
>     would be a 3 packet exchange most of the time. Why is a 5 packet
>     exchange good but a 3 packet exchange not?
>
>     Mike
>
>
>>
>>     David
>>

---

From: Lucas Pardue <[email-masked]>
Date: Tue, 20 Apr 2021 18:57:10 +0100

Hi,

Chair hat on.

This thread is not discussing a QUIC-specific issue. There are more
appropriate venues to discuss the merits of TLS, DANE and PKIs. Please take
it there.

Regards,
Lucas
QUIC WG Co-chair

---

From: Michael Thomas <[email-masked]>
Date: Tue, 20 Apr 2021 11:02:14 -0700

On 4/20/21 10:57 AM, Lucas Pardue wrote:
> appropriate venues to discuss the merits of TLS, DANE and PKIs. Please 
> take it there.

Typical, and predictable. This also confirms exactly why people don't 
want to participate in IETF, as is currently being discussed on the IETF 
list.

Bye!

Mike

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 20 Apr 2021 13:17:43 -0700

To follow up on what David Schinazi says, the primary determinant of
handshake latency for a protocol like TLS or QUIC is not the total number
of packets but rather the number of round trips. Of course these are not
unconnected because you don't have infinite congestion control window. This
is especially true for QUIC because the server is limited to 3x the
client's initial flight as an anti-amplification defense [0]. However, in
practice, most server certificate chains will fit within a single QUIC
flight, as documented in this post by Patrick McManus from Fastly [1]. And
if you use RFC 8879 certificate compression you should capture almost all
of the rest. For this reason, it seems unlikely that the TLSA approach you
propose would significantly decrease setup latency.

This is not to say that there is no room for improving latency via keying
material in the DNS, but the purpose of that would be to allow the client
to send data in its first flight (aka "zero-RTT priming"), not to reduce
the size of the server's first flight.

-Ekr

P.S.  Mike writes "TLS could be extended to allow clients to cache server
certificates." This already exists (https://tools.ietf.org/html/rfc7924)
but in terms of applicability it has a lot of overlap with resumption.
[0] By contrast for TLS over TCP, the server has already confirmed the
client's IP and so it can use a larger initial window.
[1]
https://www.fastly.com/blog/quic-handshake-tls-compression-certificates-extension-study

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 20 Apr 2021 20:43:11 -0400

On Tue, Apr 20, 2021 at 4:18 PM Eric Rescorla <[email-masked]> wrote:

> the size of the server's first flight
>

If you win at Pinball, you get to play again.

I decided not to engage in QUIC fairly early on. Not because I didn't have
any relevant ideas but because the scope was already large and my ideas
would tend to make it larger when was needed was to make it narrower.

As the work continued, I realized that QUIC is very different from TLS and
TCP: We don't have to try to make one size fits all. We can have separate
transports optimized for Browsing, RTC and transactional services.

There are now several people who have various prototypes of non-QUIC UDP
transports. Rather than discuss them here in QUIC, it would make more sense
to discuss them elsewhere, such as in an IRTF group. Some parts of QUIC are
probably re-usable, I plan to reuse the recovery scheme albeit with changes
to allow for my rather different approach to encryption.

Changing the PKI to save a few packets seems like the wrong move to me. We
should be bolder. If paying $30/yr for a certificate was an unacceptable
outrage, we should treat $10/yr for a domain name in like manner. $0.10
with no renewal fee ever seems fairer to me. If you build out a naming
scheme and a PKI at the same time, you don't need validation.

---

From: Michael Thomas <[email-masked]>
Date: Tue, 20 Apr 2021 18:10:14 -0700

On 4/20/21 5:43 PM, Phillip Hallam-Baker wrote:
> On Tue, Apr 20, 2021 at 4:18 PM Eric Rescorla <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     To follow up on what David Schinazi says, the primary determinant
>     of handshake latency for a protocol like TLS or QUIC is not the
>     total number of packets but rather the number of round trips. Of
>     course these are not unconnected because you don't have infinite
>     congestion control window. This is especially true for QUIC
>     because the server is limited to 3x the client's initial flight as
>     an anti-amplification defense [0]. However, in practice, most
>     server certificate chains will fit within a single QUIC flight, as
>     documented in this post by Patrick McManus from Fastly [1]. And if
>     you use RFC 8879 certificate compression you should capture almost
>     all of the rest. For this reason, it seems unlikely that the TLSA
>     approach you propose would significantly decrease setup latency.
>
>     This is not to say that there is no room for improving latency via
>     keying material in the DNS, but the purpose of that would be to
>     allow the client to send data in its first flight (aka "zero-RTT
>     priming"), not to reduce the size of the server's first flight
>
>
> I decided not to engage in QUIC fairly early on. Not because I didn't 
> have any relevant ideas but because the scope was already large and my 
> ideas would tend to make it larger when was needed was to make it 
> narrower.
>
> As the work continued, I realized that QUIC is very different from TLS 
> and TCP: We don't have to try to make one size fits all. We can have 
> separate transports optimized for Browsing, RTC and transactional 
> services.

This is a picture perfect example of the power hungry working group 
chairs executing the infidels that have been the subject of many recent 
talks on the IETF list. this is exactly why nobody wants to work with 
the IETF. I predicated this on the IETF list with Keith Moore and turned 
out exactly as I expected. And it took less than 24 hours. Thanks for 
making my point Lucas Purdue. You are part of the problem, not part of 
the solution.

Mike

---

From: Michael Thomas <[email-masked]>
Date: Tue, 20 Apr 2021 18:19:33 -0700

[]

if anybody is baffled by this, you should read the thread on the ietf 
list about "snarling". the wg chairs are a classic example. their 
fiefdom was challenged. it was utterly predictable, and I called it 
before hand.

Mike

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 20 Apr 2021 18:27:39 -0700

On Tue, Apr 20, 2021 at 6:10 PM Michael Thomas <[email-masked]> wrote:

> This is a picture perfect example of the power hungry working group chairs
> executing the infidels that have been the subject of many recent talks on
> the IETF list. this is exactly why nobody wants to work with the IETF.
>
There is a certain irony that you are saying this on the mailing list for a
protocol whose github repo has somewhere over 100 separate contributors
(i.e., people who actually submitted PRs and had them accepted). This seems
to me like a good example of a case where quite a few people wanted to work
with IETF.

> I predicated this on the IETF list with Keith Moore and turned out exactly
> as I expected. And it took less than 24 hours. Thanks for making my point
> Lucas Purdue. You are part of the problem, not part of the solution.
>
Having read the thread, I think the chairs handled this appropriately. You
made a suggestion, several people, most notably David Schinazi told you why
they didn't think that it was an improvement, and you responded by
complaining that David didn't want to run an experiment that he didn't see
value in. Lucas politely asked you to take it elsewhere. With that said, if
you in fact think that Lucas behaved inappropriately, I encourage you to
take it up with the ADs.

-Ekr

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 21 Apr 2021 02:31:27 +0100

Michael,

> fiefdom was challenged. it was utterly predictable, and I called it

You are making noise on this list. Please stop it.

If you want to branch or direct your thread of discussion towards things
that are related to the QUIC protocol, that is entirely of the purview of
this group and is welcomed.

If you want to talk about extending TLS, DANE, PKI, or the topics of other
mailing lists that are unrelated to the interests of this WG, the QUIC
mailing list is not the appropriate venue.

Regards
Lucas Pardue
QUIC WG Co-chair

---

From: Michael Thomas <[email-masked]>
Date: Tue, 20 Apr 2021 18:35:45 -0700

On 4/20/21 6:31 PM, Lucas Pardue wrote:
> Michael,
>
> On Wed, 21 Apr 2021, 02:19 Michael Thomas, <[email-masked] 
> If you want to branch or direct your thread of discussion towards 
> things that are related to the QUIC protocol, that is entirely of the 
> purview of this group and is welcomed.
>
> If you want to talk about extending TLS, DANE, PKI, or the topics of 
> other mailing lists that are unrelated to the interests of this WG, 
> the QUIC mailing list is not the appropriate venue.
>
I will not. You are a posterchild for what is wrong with IETF. Please 
get some clue.

Mike

---

From: Michael Thomas <[email-masked]>
Date: Tue, 20 Apr 2021 18:38:49 -0700

On 4/20/21 6:27 PM, Eric Rescorla wrote:
> Having read the thread, I think the chairs handled this appropriately. 
> You made a suggestion, several people, most notably David Schinazi 
> told you why they didn't think that it was an improvement, and you 
> responded by complaining that David didn't want to run an experiment 
> that he didn't see value in. Lucas politely asked you to take it 
> elsewhere. With that said, if you in fact think that Lucas behaved 
> inappropriately, I encourage you to take it up with the ADs.
>
This was predictable from the IETF list. It has acted out exactly as 
expected. IETF fiefdoms are a real problem.

Mike

PSL STIR is the worst standard i've ever seen.

---

From: Michael Thomas <[email-masked]>
Date: Wed, 21 Apr 2021 06:57:56 -0700

> inappropriately, I encourage you to take it up with the ADs.
I responded that I was incredulous that signing a DNS zone was 
tantamount to "boiling the ocean". In what world is that true? And that 
was apparently enough to cause the chairs to go ballistic. It was not 
polite whatsoever. It was a first class snarl.

Mike

---

From: Lars Eggert <[email-masked]>
Date: Wed, 21 Apr 2021 17:16:52 +0300

Hi,

On 2021-4-21, at 16:57, Michael Thomas <[email-masked]> wrote:
> And that was apparently enough to cause the chairs to go ballistic. It       was not polite whatsoever. It was a first class snarl.

the message that was sent said: "This thread is not discussing a QUIC-specific issue. There are more appropriate venues to discuss the merits of TLS, DANE and PKIs. Please take it there."

I'm struggling to interpret those three sentences as "going ballistic", or being a "first class snarl". With all due respect, I think you are overreacting.

Thanks,
Lars (also one of the chairs)

---

From: Michael Thomas <[email-masked]>
Date: Wed, 21 Apr 2021 09:11:17 -0700

> I'm struggling to interpret those three sentences as "going ballistic", or being a "first class snarl". With all due respect, I think you are overreacting.
I am a newcomer. I came here against my better judgement as I stated on 
the IETF list. I immediately had my head chopped off and told to go away 
by a working group chair in less than 24 hours. If the number of packets 
exchanged in the initial handshake of a transport protocol is off topic, 
I am speechless. My better judgement wasn't that it was off topic, it 
was that this outcome is the ordinary behavior of insular IETF working 
groups.

I also got told that signing a zone is tantamount to "boiling the 
ocean". As IETF chair, do you agree with that? Because if it's true then 
there are serious issues with DNSSec and we should do something about 
it. I think it's nonsense, fwiw.

Mike, and what exactly are those venues? tia.

---

From: Lars Eggert <[email-masked]>
Date: Wed, 21 Apr 2021 19:46:57 +0300

Hi,

On 2021-4-21, at 19:11, Michael Thomas <[email-masked]> wrote:
> I am a newcomer. I came here against my better judgement as I stated on the IETF list.

I have emails from you in my IETF mail archive at least as far back as 2006. But I assume you mean that you are a newcomer to the QUIC WG.

> I immediately had my head chopped off and told to go away by a working group chair in less than 24 hours.

I don't think you're helping your case by using dramatic phrases.

To recap: You brought a proposal that had been discussed elsewhere to the QUIC WG list. You got feedback from a number of different participants on your proposal. The discussion veered away from QUIC to other protocols that this WG is not working on. A chair suggested you continue the discussion on a mailing list better suited to your topic.

> If the number of packets exchanged in the initial handshake of a transport protocol is off topic, I am speechless. My better judgement wasn't that it was off topic, it was that this outcome is the ordinary behavior of insular IETF working groups.

A number of participants have commented on this already, for example, pointing out that the number of round trips matter much more than the number of packets, and that in their opinion your suggestion would not lead to further substantial enough gains. You then moved the topic of the discussion to why Google (and I assume other companies) are not signing their zones and offered theories as to why that is, which is not a topic of relevance to this WG. Hence the request to discuss it elsewhere.

> I also got told that signing a zone is tantamount to "boiling the ocean".

You're misquoting David. He said:

On 2021-4-20, at 20:20, David Schinazi <[email-masked]> wrote:
> that it's not worth boiling the ocean to remove 2 packets.

Nowhere in that sentence or the rest of David's email do I see any mention of signing zones.

> As IETF chair, do you agree with that? Because if it's true then there are serious issues with DNSSec and we should do something about it. I think it's nonsense, fwiw.

Again, not a topic for *this* mailing list.

> Mike, and what exactly are those venues? tia.

I'd start at DNSOP and ask if there is a more appropriate list.

Thanks,
Lars

---

From: Michael Thomas <[email-masked]>
Date: Wed, 21 Apr 2021 09:56:27 -0700

> Again, not a topic for *this* mailing list.

Chrome has already implemented DANE once upon a time. The only thing 
left is for Google to DNSSec sign their zone. That's it. If there is 
something else, I'm all ears.

And I am asking in your capacity as IETF chair if signing your zone is 
tantamount to "boiling the ocean". Taken at face value, that is a 
stunning indictment.

Mike

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 21 Apr 2021 13:03:41 -0400

> something else, I'm all ears.

It is very rare that I make an assertion on a public mailing list and refer
to reasons I am not prepared to discuss in public but I am going to do that
on this occasion.

There are very good reasons why Google and other large international
network service providers should not sign their DNSSEC zones. Securing the
Internet is about rather more than securing the Internet.