Re: [TLS] Merkle Tree Certificates

[Hubert Kario <[e-mail]>]

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 <[e-mail]> 
> Sent: Wednesday, March 22, 2023 8:46 AM
> To: David Benjamin <[e-mail]>
> Cc: Kampanakis, Panos <[e-mail]>; <[e-mail]> 
> <[e-mail]>; Devon O'Brien <[e-mail]>
> 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 <[e-mail]> 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