Re: Quic: the elephant in the room

[Michael Thomas <[e-mail]>]

On 4/11/21 7:56 AM, Phillip Hallam-Baker wrote:
>
>
> On Sun, Apr 11, 2021 at 12:36 AM Viktor Dukhovni 
> <[e-mail] <mailto:[e-mail]>> wrote:
>
>     On Sun, Apr 11, 2021 at 12:20:28AM -0400, Phillip Hallam-Baker wrote:
>
>     > Only VERIFYING digital signatures provides security. And nobody
>     knows what
>     > to do when DNSSEC validation fails so nobody really does it
>
>     This is false both in premise and conclusion.  I was tempted to ignore
>     the rest of the post, but ...
>
>
> If nobody is ever going to check the sigs, they could simply be random 
> bytes.
>
> I had a PGP sig on some of my USENET posts for a while. Nobody ever 
> checked
> it and nobody ever noticed it was a static sig that never changed.

If Google implemented DANE in Chrome, that's who checks. It's really 
that simple.


> To justify the deployment of a new infrastructure, I do have to show that
> backporting is infeasible. I have paid particular attention to the 
> reason for
> the failure of DNSSEC and DANE precisely because I want to understand what
> the criteria are for success.

My take is that the reason for lack of uptake is that they are viewed as 
essentially superfluous. The same thing happened to SCTP as it was 
painful to get kernel adoption and firing up multiple TCP streams was a 
good enough bandaid. Then Quic came around with the goal of greatly 
reducing the setup time and finally fixing HoL blocking, and also 
learning that external dependencies is a good route to /dev/null. Google 
and others are completely at liberty to finish the job with Quic by 
adopting DANE and finally get back to a 3 way handshake (on average or 
possibly always). And they don't need to ask your, my, or anybody else's 
opinion on the matter which is a Good Thing.

Mike