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. -----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 don't think flattening is the right way to look at it. See my >>> other reply for a discussion about flattening, and how this does a >>> bit more than that. (It also handles SCTs.) >>> >>> As for RFC 7924, in this context you should think of it as a funny >>> kind of TLS resumption. In clients that talk to many ... >> https://github.com/MattMenke2/Explainer---Partition-Network-State/blo >> b/main/README.md >>> and https://github.com/privacycg/storage-partitioning. >> >> Sorry, but as long as the browsers are willing to perform session >> resumption I'm not buying the "cached info is a privacy problem". >> > > 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? >> Browser doesn't have to cache the certs since the beginning of time to be >> of benefit, a few hours or even just current boot would be enough: >> >> 1. if it's a page visited once then all the tracking cookies >> and javascript >> will be an order of magnitude larger download anyway >> 2. if it's a page visited many times, then optimising for the subsequent >> connections is of higher benefit anyway >> > > 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 >>> per-destination state and can apply to the first time you talk >>> to a server. >> >> it does depend on complex code instead, that effectively duplicates the >> functionality of existing code >> >>> David >>> >>> [0] If you're a client that only talks to one or two servers, >>> you could imagine getting this cached information pushed >>> out-of-band, similar to how this document pushes some valid tree >>> heads out-of-band. But that doesn't apply to most clients, ... >> >> web browser could get a list of most commonly accessed pages/cert pairs, >> randomised to some degree by addition of not commonly accessed pages to >> hide if >> the connection is new or not, and make inference about previous visits >> worthless >> > > 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 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
