Hiya,

On 19/07/2021 22:13, David Benjamin wrote:
I don't think that's an accurate characterization of what's going on. I at
least care about both optimization and privacy.

Sure. We just disagree, I've no doubt you care about those.

We should apply
optimizations only where they do not result in a privacy issue, and we
should not apply optimizations that result in a privacy issue. That means
taking the time to understand a system's privacy goals and how mechanisms
interact with them.

Even ignoring this document, rfc8446*already*  fails this test. By
omission, it implies applications needn't match up their privacy goals with
TLS resumption. This is false and indeed that results in a tracking vector
on the Web, and any other application where multiple contexts talk to the
same domain. That means this 3rd option does not replace the need for text.
We need to either find wording we're happy with, or remove resumption
entirely.

I've proposed some text for rfc8446bis. I think it captures the right
criteria: you may only resume if you were okay correlating the first and
second connections. If you think something is missing, I think that is
useful feedback. Given how widespread resumption is, it's important that we
fully understand the implications.
https://github.com/tlswg/tls13-spec/pull/1205

From there, we can look at this document.

Now it's me that's confused. Are you arguing that this draft
ought not progress until 8446bis is done?

Ta,
S.

Observe that the rule applies
equally well here. Moreover, on the Web, even after you apply the rule,
there is still a space where the optimization is useful. This is great. It
means we can both avoid a privacy issue*and*  make things faster. Even
better, the optimizations apply to XSS privsep schemes (subdomains within a
site), so there is an indirect security benefit. Other applications may
look different (no subresource-like construct, different correlation
boundaries), such that the optimization is not useful, but that's still
fine. The overall rule simply turns the flag into a no-op.

Attachment: OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature
Description: OpenPGP digital signature

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Reply via email to