On 4/11/21 7:34 AM, Ben Laurie wrote:
On Sat, 10 Apr 2021 at 18:04, Michael Thomas <mike@xxxxxxxx> wrote:
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. 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.
Huh? Source?
On Sun, 11 Apr 2021 at 16:42, Michael Thomas <mike@xxxxxxxx> wrote:
I'm afraid my source is my own experience (Google has a *lot* of domains).
