Re: Quic: the elephant in the room

[Ben Laurie <[e-mail]>]

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

>
> On 4/10/21 2:29 AM, Ben Laurie wrote:
>
>
>
> 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.
>
>
> DNS is the natural trust anchor for the internet. And I don't know what
> "considerably less secure" means. If you mean that DNSSec is broken, then
> you should say that. If you mean that DNSsec deployment is thin, that is
> quite another thing, and that is all about the incentives to deploy. I
> don't consider a plethora of CA's of varying security responsibility to be
> a feature and in fact is a bug.
>
What I mean is that the authorities for DNS get compromised far more often
than CAs do. Also, DNS has the same plethora of authorities with varying
security responsibility.


>
> Mike
>
>