Re: Quic: the elephant in the room

[Ben Laurie <[e-mail]>]

On Sat, 10 Apr 2021 at 00:35, Michael Thomas <[e-mail]> wrote:

>
> On 4/9/21 4:26 PM, Phillip Hallam-Baker wrote:
>
> It is only a 'three packet handshake' if you ignore the off path
> interactions with the DNS service. The timeout on DNS tens to be rather
> smaller than that most would be comfortable with for crypto.
>
> I don't see why it can't be long lived, but even normal TTL's would get
> amortized over a lot of connections. Right now with certs it is a 5 message
> affair which cannot get better. But that is why one of $BROWSERVENDORS
> doing an experiment would be helpful.
>

When I was designing Certificate Transparency, Chrome ruled out any side
channel communications requirement during handshake. Given that DNS is
required anyway, perhaps this would be different. However, the other
problem is introducing DNS as a trust root - the DNS hierarchy is
considerably less secure than CAs were even before CT but now it's really a
very poor option in comparison.

Could be fixed with DNS Transparency, of course.



> Mike
>
>
>
> On Fri, Apr 9, 2021 at 7:17 PM Michael Thomas <[e-mail]> wrote:
>
>>
>> I wrote a blog post about how something like DANE could be used instead
>> of certificates for the TLS handshake to get it back to the original 3
>> packet handshake. I know that isn't news to a lot of people, but the
>> interesting part is that a Google could perform an experiment to see how
>> well it works in real life just like they did with Quic and Spdy. Since
>> Quic is all about making setup time faster, it seems like a pretty
>> reasonable experiment since it would cut out 2 packets generally
>> speaking since DNS can be cached.
>>
>> https://rip-van-webble.blogspot.com/2021/04/quic-elephant-in-room.html
>>
>> Mike
>>
>>