On Thursday, 23 March 2023 03:00:53 CET, Kampanakis, Panos wrote:
Hi Hubert,
I totally agree on your points about time-to-first-byte vs
time-to-last-byte. We (some of my previous work too) have been
focusing on time-to-first byte which makes some of these
handshakes look bad for the tails of the 80-95th percentiles.
But in reality, the time-to-last-byte or
time-to-some-byte-that-makes-the-user-think-there-is-progress
would be the more accurate measurement to assess these
connections.
Neither cached data nor Merkle tree certificates reduce round-trips
Why is that? Assuming Dilithium WebPKI and excluding CDNs, QUIC
sees 2 extra round-trips (amplification, initcwnd) and TLS sees
1 (initcwnd). Trimming down the "auth data" will at least get
rid of the initcwnd extra round-trip. I think the Merkle tree
cert approach fits in the default QUIC amplification window too
so it would get rid of that round-trip in QUIC as well.
I meant it on TLS level. Sure, on TCP level the less data you need to send
the less problem you have with congestion window. But even there, I don't
see
insurmountable problems with it; even with 3 Dilithium certs, with 2 SCTs
each, we're talking about 22kB of data; that's half of what cloudflare
found to be an inflection point for extra data:
https://blog.cloudflare.com/sizing-up-post-quantum-signatures/
So I'm very unconvinced that for good general web browsing experience
Merkle Tree Certs will be qualitatively better than cached info.
-----Original Message-----
From: Hubert Kario <hka...@redhat.com>
Sent: Wednesday, March 22, 2023 8:46 AM
To: David Benjamin <david...@chromium.org>
Cc: Kampanakis, Panos <kpa...@amazon.com>; <tls@ietf.org>
<tls@ietf.org>; Devon O'Brien <asymmet...@google.com>
Subject: RE: [EXTERNAL][TLS] Merkle Tree Certificates
CAUTION: This email originated from outside of the
organization. Do not click links or open attachments unless you
can confirm the sender and know the content is safe.
On Tuesday, 21 March 2023 17:06:54 CET, David Benjamin wrote:
On Tue, Mar 21, 2023 at 8:01 AM Hubert Kario <hka...@redhat.com> wrote:
On Monday, 20 March 2023 19:54:24 CET, David Benjamin wrote: ...
I'm not seeing where this quote comes from. I said it had analogous
properties to resumption, not that it was a privacy problem in
the absolute.
I meant it as a summary not as a quote.
The privacy properties of resumption and cached info on the situation. If
you were okay correlating the two connections, both are okay in this
regard. If not, then no. rfc8446bis discusses this:
https://tlswg.org/tls13-spec/draft-ietf-tls-rfc8446bis.html#appendix-C.4
In browsers, the correlation boundaries (across *all* state, not just TLS)
were once browsing-profile-wide, but they're shifting to this notion of
"site". I won't bore the list with the web's security model, but roughly
the domain part of the top-level (not the same as destination!) URL. See
the links above for details.
That equally impacts resumption and any hypothetical deployment of cached
info. So, yes, within those same bounds, a browser could deploy cached
info. Whether it's useful depends on whether there are many cases where
resumption wouldn't work, but cached info would. (E.g. because resumption
has different security properties than cached info.)
The big difference is that tickets generally should be valid only for
a day or two, while cached info, just like cookies, can be valid for many
months if not years.
Now, a privacy focused user may decide to clear the cookies and cached
info daily, while others may prefer the slightly improved performance
on first visit after a week or month break.
It also completely ignores the encrypted client hello
ECH helps with outside observers correlating your connections, but it
doesn't do anything about the server correlating connections. In the
context of correlation boundaries within a web browser, we care about the
latter too.
How's that different from cookies? Which don't correlate, but
cryptographically
prove previous visit?
...
I don't think that's quite the right dichotomy. There are
plenty of reasons
to optimize for the first connection, time to first bytes, etc. Indeed,
this WG did just that with False Start and TLS 1.3 itself.
(Prior to those,
TLS 1.2 was 2-RTT for the first connection and 1-RTT for resumption.) ...
In my opinion time to first byte is a metric that's popular because it's
easy
to measure, not because it's representative. Feel free to point me to
double blind studies with representative sample sizes showing otherwise.
Yes, reducing round-trips is important as latency of connection is not
correlated with bandwidth available. But when a simple page is a megabyte
of
data, and anything non trivial is multiple megabytes, looking at when the
first
byte arrives it is completely missing the bigger picture.
Especially when users are trained to not interact with the page until it
fully
loads (2018 Hawaii missile alert joke explanation):
https://gfycat.com/queasygrandiriomotecat
Neither cached data nor Merkle tree certificates reduce round-trips
I suspect a caching for a few hours would not justify cached info because
you may as well use resumption at that point.
In comparison, this design doesn't depend on this sort of ...
True, we could preload cached info for a global list of common
certificates. I'm personally much more interested in mechanisms that
benefit popular and unpopular pages alike.
Unpopular pages are much more likely to deploy a solution that doesn't
require
a parallel CA infrastructure and a cryptographer on staff.
--
Regards,
Hubert Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
--
Regards,
Hubert Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
