Subject: [TLS] WGLC for draft-ietf-tls-cross-sni-resumption

From: "Christopher Wood" <[email-masked]>
Date: Fri, 16 Jul 2021 16:55:52 -0700

This is the working group last call for the "Transport Layer Security (TLS) Resumption across Server Names" draft, available here:

    https://datatracker.ietf.org/doc/draft-ietf-tls-cross-sni-resumption/

Please review this document and send your comments to the list by July 30, 2021. The GitHub repository for this draft is available here:

    https://github.com/vasilvv/tls-cross-sni-resumption

Thanks,
Chris, on behalf of the chairs

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 19 Jul 2021 14:16:21 +0000

I support publication.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 19 Jul 2021 16:01:20 +0100

> I support publication.

I don't, though I may be in the rough.

We did discuss this a bit earlier but from my POV this
adds a new vector for cross-domain tracking and we ought
be removing those, not adding them.

I don't find the reference to [FETCH] explains how that
problem can be mitigated by browsers. (IIRC, adding that
was the result of earlier discussion of this point?)

I have no idea if anything similar might protect mail user
agents when processing mailbug URLs, not other applications
using TLS.

To give a small sense of scale, in scans I did a few
years back [1], one wild-card certificate [2] was visible
at almost 2000 addresses in a range of different countries.
That appeared to be part of some multi-product marketing
campaign. (The names seen associated with the wildcard cert
were of the form "<product>.campaign.<marketing-company>"
and the wildcard was for "*.campaign.<marketing-company>".)
Another certificate (sorry had a quick look but didn't find
the specific ref) for parked domains had 1500 SANs.
I think both of those are indicators that this mechanism
could be used at scale for tracking.

Cheers,
S.

[1] https://eprint.iacr.org/2018/299
[2] https://crt.sh/?id=242683192

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Michael StJohns <[email-masked]>
Date: Mon, 19 Jul 2021 11:04:51 -0400

>> https://datatracker.ietf.org/doc/draft-ietf-tls-cross-sni-resumption/

Nit - which also applies to draft-ietf-tls-flags:  In the IANA 
considerations section, the Value field is expressed as 0x8 - a hex 
value - rather than 8 a decimal value.  Given that the registry uses 
decimal bit number positions, and that a hex value might be confused 
with a mask (e.g. 0x8 might be confused with bit 5), I'd suggest 
dropping the "0x".   Or, to keep this more in keeping with normal 
practice, specify Value as "TBD" and have the IANA do the actual 
assignment consistent with policy - it's a good way to ensure the WG and 
the IANA are on the same page.  If that change is made, add a "to be 
removed before publication" note to the IANA indicating that you want 
the assignment to be made out of the 8-31 range.  Section 3 would also 
need to change to remove "(8)";

Nit: Section 4 - it's not clear that "Section 4.6.1" refers to RFC8846 
(at least in the text version) as opposed to a mis-numbered section - 
instead I suggest: "Section 4.6.1 of that document"

Mike

---

From: Ryan Sleevi <[email-masked]>
Date: Mon, 19 Jul 2021 11:21:43 -0400

> was the result of earlier discussion of this point?)

I'm not sure I'm parsing this correctly.

Are you saying that you don't believe network isolation keys are
sufficient? That is, this is the current language from the draft:

> For example, the Web use case uses network partition keys to separate
cache lookups [FETCH].

And the term there ("network partition keys") is a defined term in the
FETCH spec that forms the basis of cross-domain tracking prevention:
https://fetch.spec.whatwg.org/#network-partition-key

It's unclear whether you're saying that the spec should diverge from FETCH
and impose additional requirements, or whether you're saying you don't
believe the current FETCH spec is robust enough there.

It's unclear that there's any benefit to having the Cross-SNI spec impose
additional requirements: you have to consider the Web application in its
entire context, which is precisely what network partition keys do.
Similarly, if the concern is that FETCH isn't sufficient for your concerns,
is that a concern with this spec, or with FETCH, and can/should they be
articulated there (and the related issue mentioned)

<snip>

> could be used at scale for tracking.

You opened by talking about MTAs, but it's unclear if this is meant to be a
general statement or specific to mail. In the context of the Web, then we
have to consider the holistic platform, and ask whether this hooks into the
same appropriate points - it does, as the partition keys are based on the
same cross-origin tracking protection mechanisms (e.g. the determination of
"first party" vs "third party" contexts is implicitly handled here). If
this is for mail, then isn't the point that this remains an
application-/protocol-specific consideration?

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 19 Jul 2021 16:59:54 +0100

Hiya,

On 19/07/2021 16:21, Ryan Sleevi wrote:
> sufficient? 

I'm saying I don't know. I'm not a browser implementer.
Nor are a bunch of other people who use TLS and who won't
be familiar with fetch.

> That is, this is the current language from the draft:
> 

The spec doesn't say how to mitigate the problem for any
other application using TLS, nor does it explain how to
mitigate the issue for a browser, other than via that one
sentence referring to a document that can change (though
that last isn't my problem with this spec).

I don't myself know how well that mechanism mitigates the
issue for browser users, nor how feasible it might be to do
something similar in a non-browser. (If the mechanism works
ok for browsers, that's fine for them of course.)

> You opened by talking about MTAs,

It's very common to see web servers and MTAs on the same IP
address, and also common to see the same certificate used
for both. (My scans were of hosts listening on mail ports
but I also scanned 443.)

> but it's unclear if this is meant to be a
> general statement or specific to mail. 

The scale issue is general I think. I agree that trackers
today overwhelmingly enjoy the web as their preferred tool.

But again, my fundamental issue with this is that we ought
not be added new cross-domain tracking threats.

S.

> In the context of the Web, then we

---

From: David Benjamin <[email-masked]>
Date: Mon, 19 Jul 2021 12:17:16 -0400

I'll add that, in the context of cross-domain tracking on the web, this
draft is a red herring. Remember that web pages have subresources. That
means looking at the destination domain isn't useful because two different
pages can embed a common destination domain. So the same concerns exist
with RFC8446 (TLS resumption), RFC7540 (connection-reuse, same- and
cross-domain), and RFC7230 (connection reuse). That's why we need a
holistic answer like network partition keys from [FETCH], that apply to
*all* network state. That answer applies equally to plain resumption and
this draft.

Of course, [FETCH] doesn't apply to other applications, just the web. But I
think the above should demonstrate that correlation boundaries are
necessarily a whole-application question. That's why the [FETCH] citation
is only an example. The general guidance is this:

> Client applications should partition the session cache between
connections that are meant to be uncorrelated.

This applies to all application protocols. Do you believe your correlation
boundary is an individual email? Well, you shouldn't reuse any state across
those and probably will end up not doing any resumption at all. Do you have
multiple contexts in your application, like different profiles, that are
meant to be separate? Well, you shouldn't reuse state across those
profiles. Does your application not have correlation boundaries? Well, then
you can resume whatever. Are you a non-web application where partitioning
by just the destination domain is meaningful? Well, then you should
partition your session cache accordingly, which no-ops this extension and
parts of RFC7540.

Indeed, since this is a general problem with TLS resumption, we're really
talking about an omission in RFC8446 itself. For rfc8446bis, I landed this
PR, which corrects the omission.
https://github.com/tlswg/tls13-spec/pull/1205
Were publication orders different, there would be no need to include the
same text in draft-ietf-tls-cross-sni-resumption, but so it goes.

On Mon, Jul 19, 2021 at 11:22 AM Ryan Sleevi <[email-masked]>
wrote:

>
>
> On Mon, Jul 19, 2021 at 11:02 AM Stephen Farrell <
> [email-masked]> wrote:
>
> You opened by talking about MTAs, but it's unclear if this is meant to be
> a general statement or specific to mail. In the context of the Web, then we

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 19 Jul 2021 17:26:55 +0100

Hiya,

> *all*  network state. That answer applies equally to plain resumption and

That's true but isn't that also the old "adding this
one new way to track doesn't make it worse because it's
already horrible"?

My preference is to not add new mechanisms that can
enable cross-domain tracking as this one does.

Cheers,
S.

---

From: David Benjamin <[email-masked]>
Date: Mon, 19 Jul 2021 12:35:17 -0400

> enable cross-domain tracking as this one does.

No, that's not what I'm saying at all. Read the last sentence again.

We need to *both* not add new tracking vectors *and* mitigate the existing
ones. Doing either one on its own is not useful. That means if the existing
mitigation for the existing vector applies just as well to this new
feature, we have not added a new vector. Indeed it applies so well that we
were able to add the same text to both this draft and rfc8446bis.

David

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 19 Jul 2021 17:38:29 +0100

Hiya,

On 19/07/2021 17:35, David Benjamin wrote:
> We need to*both*  not add new tracking vectors*and*  mitigate the existing
> feature, we have not added a new vector.

I think that clarifies where we disagree, thanks - i'm
not convinced that our existing mitigations for tracking
via the web, or otherwise, are anywhere near sufficient.

S.

---

From: David Benjamin <[email-masked]>
Date: Mon, 19 Jul 2021 12:50:37 -0400

> via the web, or otherwise, are anywhere near sufficient.

I think you're still misunderstanding me. Let me try to phrase this better.
By "existing" I mean "already written down in Fetch", and just talking
about the TLS resumption component. I certainly don't mean to suggest the
problem is done. Tracking via the web overall is a complex, evolving topic,
with lots of folks working on it across the stack. Most of it is not
relevant to low-level TLS state, except in recognizing that, because
correlation is transitive, you can only solve it looking at the application
as a whole.

To bring this back to resumption, there is really only a single question to
answer here: do you offer a session, negotiated in context A, over this new
connection being established in context B? If you say yes, you potentially
get a performance improvement, but you also allow contexts A and B to be
correlated. Whether you are okay with that depends on the application, and
is not something TLS can answer.

What TLS needs to do is translate this TLS-level notion into things the
application is worrying about. In this case, the deciding question is: do
you mean for those two contexts to be correlated? If not, don't offer
resumption. That is what this draft says, and it is what rfc8446 needed to
say, but omitted. That omission has been corrected in rfc8446bis.

Do you have other text in mind? There doesn't seem to be any other possible
answer here, since there is only one decision to make in resumption. It's
also one that clearly will continue working as we evolve and strengthen
applications' privacy goals, including that of the web, since everything
boils down to what contexts can and cannot be correlated.

David

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 19 Jul 2021 21:20:49 +0100

Hiya,

On 19/07/2021 17:50, David Benjamin wrote:
> answer here, since there is only one decision to make in resumption.

There is a 3rd option: don't standardise the flag. That'd be
my preference, but as I said maybe I'm in the rough in not
preferring more optimisation at the cost of the additional
privacy concern.

Other than that I don't have better wording to offer at the
moment that I think would really help sorry. Maybe if others
chime in something'll become more apparent.

Cheers,
S.

---

From: David Benjamin <[email-masked]>
Date: Mon, 19 Jul 2021 17:13:57 -0400

> chime in something'll become more apparent.

I don't think that's an accurate characterization of what's going on. I at
least care about both optimization and privacy. 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. 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.

David

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 19 Jul 2021 22:32:03 +0100

Hiya,

On 19/07/2021 22:13, David Benjamin wrote:
> least care about both optimization and privacy. 

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

> We should apply
> Even ignoring this document, rfc8446*already*  fails this test. By
>>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
> means we can both avoid a privacy issue*and*  make things faster. Even

---

From: David Benjamin <[email-masked]>
Date: Mon, 19 Jul 2021 17:43:13 -0400

> ought not progress until 8446bis is done?

No. I'm saying there is a need for text around resumption and privacy,
whether or not we publish this draft. There is a copy of the text to
address it in both documents. The text applies equally well to both, thus I
am satisfied with how this draft addresses the concerns.

It sounds like you disagree with this reasoning because you are unhappy
with that text. Thus: what do you think are the privacy rules for TLS
resumption? An alternate suggestion of "don't publish the draft" does not
work, because having resumption in form means we need to consider this.

David

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 19 Jul 2021 22:49:32 +0100

Hiya,

> am satisfied with how this draft addresses the concerns.

Ack.

> with that text. 

I've not considered the text in 8446bis.

I'm against this draft entirely, as it adds to our problems
(IMO, but not yours).

> Thus: what do you think are the privacy rules for TLS

Of course that suggestion "works." It'd mean that this new
potential tracking vector doesn't turn into an actual one.

(We may still likely need more text in 8446bis about
resumption but that's different - were it precisely same
there'd be no need for this draft at all.)

Cheers,
S.

---

From: "Christopher Wood" <[email-masked]>
Date: Fri, 30 Jul 2021 18:57:53 -0700

Given the few responses received thus far, we're going to extend this WGLC for another two weeks. It will now conclude on August 13.

Best,
Chris, for the chairs

On Fri, Jul 16, 2021, at 4:55 PM, Christopher Wood wrote:
> This is the working group last call for the "Transport Layer Security 
> (TLS) Resumption across Server Names" draft, available here:
> 
> Please review this document and send your comments to the list by July 
> 30, 2021. The GitHub repository for this draft is available here:
>