Re: Quic: the elephant in the room

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

 




On 4/10/21 2:29 AM, Ben Laurie 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.


It occurs to me that it would be possible to return the DANE RR's as additional RR's in the address query so that it is always the case that it is in cache for the sake of the handshake. Or it could possibly be the other way around: you query for the DANE RR and get back A/AAAA records as well. I don't know how this might work in real life, but it seems theoretically possible. That would satisfy the no "side channel" rule.

Mike


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

  Powered by Linux