Re: Quic: the elephant in the room

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On Sat, Apr 10, 2021 at 5:29 AM Ben Laurie <benl@xxxxxxxxxx> wrote:


On Sat, 10 Apr 2021 at 00:35, Michael Thomas <mike@xxxxxxxx> 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.

That is not the approach I am planning to take.

DNSSEC will always be an afterthought and Domain Validation in the WebPKI will always be weak because the role of the CA is to recover information thrown away in the DNS registration scheme.

Build out the name registry and the PKI in parallel and the need for Domain Validation goes away entirely.

My current proposal is focused on the never solved problem of credentialing people rather than organizations and employees in organizations. But it could also be used for organizations:


This is not built on Certificate Transparency but it does apply many of the same ideas. 

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux