3 ms·

I suppose it also depends on your position on DoH as well, as a I know some folks don’t like the idea of clients avoiding local DNS resolvers when using it. Th

I suppose it also depends on your position on DoH as well, as a I know some folks don’t like the idea of clients avoiding local DNS resolvers when using it. The simple answer is that DoQ, and Quic, are more efficient at connection establishment when setting up a TLS connection it reduces the total round trips for TLS from 6 to 3, which is pretty assume for reducing latency. While Google developed it, I don’t think there is anything inherent to it that makes using it any different that using TCP and/or TLS like people do today.

toast0 3y ago
Isn't TCP + TLS, with false start or TLS 1.3 also three round trips? C: SYN -> S S: SYN + ACK -> C C: ACK -> S C: Client hello -> S (no need for two separate packets, but almost everyone sends the no data ack) S: Server hello, certificate, server hello done -> C C: client key exchange, change cipher spec, finished, application data -> S S: change cipher spec, finished, application data -> C In theory, you could use tcp fast open to shave a round trip, and you can use TLS 1.3 early data to get to application data on the second round trip where there's a session to resume, if the client sent data is OK to replay.
- bluejekyll 3y ago
  Yes I think you’re correct with pre established connections, etc, TLS 1.3, there are definitely efficiencies there.
WarOnPrivacy 3y ago
That helps; is appreciated. I have small biz Unbound resolvers out there. For whatever reason I hadn't run into DoQ. Or QUIC for that matter. Not sure if that merits any chagrin. I think Google products vary from helpful to harmful. Good for me is that HN folks often know how beneficial (or not) some G tech might be.
WarOnPrivacy 3y ago
> I suppose it also depends on your position on DoH as well, I'm good with it. It was a tiny bit annoying at first but I strongly support the intent behind it. Mozilla's override (at the resolver) is trivial to enact so I've nothing to complain about.

toast0 3y ago

Isn't TCP + TLS, with false start or TLS 1.3 also three round trips? C: SYN -> S S: SYN + ACK -> C C: ACK -> S C: Client hello -> S (no need for two separate packets, but almost everyone sends the no data ack) S: Server hello, certificate, server hello done -> C C: client key exchange, change cipher spec, finished, application data -> S S: change cipher spec, finished, application data -> C In theory, you could use tcp fast open to shave a round trip, and you can use TLS 1.3 early data to get to application data on the second round trip where there's a session to resume, if the client sent data is OK to replay.

bluejekyll 3y ago
Yes I think you’re correct with pre established connections, etc, TLS 1.3, there are definitely efficiencies there.

WarOnPrivacy 3y ago

That helps; is appreciated. I have small biz Unbound resolvers out there. For whatever reason I hadn't run into DoQ. Or QUIC for that matter. Not sure if that merits any chagrin. I think Google products vary from helpful to harmful. Good for me is that HN folks often know how beneficial (or not) some G tech might be.

WarOnPrivacy 3y ago

> I suppose it also depends on your position on DoH as well, I'm good with it. It was a tiny bit annoying at first but I strongly support the intent behind it. Mozilla's override (at the resolver) is trivial to enact so I've nothing to complain about.