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/blob/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
