Re: [TLS] Possible TLS 1.3 erratum
Ilari Liusvaara writes:
>Actually, I think this is quite messy issue:
It certainly is.
>Signature schemes 0x0403, 0x0503 and 0x0603 alias signature algoritm 3 hash
>4, 5 and 6. However, those two things are not the same, because the former
>have curve restriction, but the latter do not.
That and the 25519/448 values are definitely the weirdest of the lot. In
particular the value 0x03 means P256 when used with SHA256, P384 when used
with SHA384, and P521 when used with SHA512.
>So one algorithm one could use is:
>
>- Handle anything with signature 0-3/224-255 and hash 0-6/224-255 as
> signature/hash pair.
>- Display schemes 0x0840 and 0x0841 specially.
>- Handle anything else as signature scheme.
I think an easier, meaning with less special cases, way to handle it is for a
TLS 1.2 implementation to treat the values defined in 5246 as { hash,
signature } pairs and for TLS 1.3 and newer implementations to treat all
values as 16-bit cipher suites, combined with a reworking of the definitions,
e.g. to define the "ed25519" suite in terms of the curve and hash algorithm,
not just "Ed25519 and you're supposed to know the rest".
>The reason is that some TLS implementations have very hard time supporting
>RSA-PSS certificates.
But why should the TLS layer care about what OID is used to represent an RSA
key in a certificate? The signature at the TLS level is either a PSS
signature or it isn't, it doesn't matter which OID is used in the certificate
that carries the key.
More to the point, the TLS layer may have no way to determine which OID is
used in the certificate, it's either an RSA key or not, not "it's an RSA key
with OID A" or "it's an RSA key with OID B".
So I think for bis the text should rename rsa_pss_rsae_xxx to just rsa_pss_xxx
and drop rsa_pss_pss_xxx, which I assume has never been used anyway because I
don't know of any public CA that'll issue a certificate with a PSS OID.
Peter.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Possible TLS 1.3 erratum
On Monday, 19 July 2021 14:06:41 CEST, Peter Gutmann wrote:
Ilari Liusvaara writes:
Actually, I think this is quite messy issue:
It certainly is.
Signature schemes 0x0403, 0x0503 and 0x0603 alias signature
algoritm 3 hash
4, 5 and 6. However, those two things are not the same, because the former
have curve restriction, but the latter do not.
That and the 25519/448 values are definitely the weirdest of the lot. In
particular the value 0x03 means P256 when used with SHA256, P384 when used
with SHA384, and P521 when used with SHA512.
So one algorithm one could use is:
- Handle anything with signature 0-3/224-255 and hash 0-6/224-255 as
signature/hash pair.
- Display schemes 0x0840 and 0x0841 specially.
- Handle anything else as signature scheme.
I think an easier, meaning with less special cases, way to
handle it is for a
TLS 1.2 implementation to treat the values defined in 5246 as { hash,
signature } pairs and for TLS 1.3 and newer implementations to treat all
values as 16-bit cipher suites, combined with a reworking of
the definitions,
e.g. to define the "ed25519" suite in terms of the curve and hash algorithm,
not just "Ed25519 and you're supposed to know the rest".
The reason is that some TLS implementations have very hard time supporting
RSA-PSS certificates.
But why should the TLS layer care about what OID is used to represent an RSA
key in a certificate? The signature at the TLS level is either a PSS
signature or it isn't, it doesn't matter which OID is used in
the certificate
that carries the key.
It only doesn't matter if you don't want to verify the certificate...
It's one thing to be able to be able to verify an RSA-PSS signature on
TLS level, it's entirely another to be able to properly handle all the
different RSA-PSS limitations when using it in SPKI in X.509.
More to the point, the TLS layer may have no way to determine which OID is
used in the certificate, it's either an RSA key or not, not "it's an RSA key
with OID A" or "it's an RSA key with OID B".
So I think for bis the text should rename rsa_pss_rsae_xxx to
just rsa_pss_xxx
and drop rsa_pss_pss_xxx, which I assume has never been used
anyway because I
don't know of any public CA that'll issue a certificate with a PSS OID.
That's because browsers don't have the code to handle RSA-PSS certificates.
But that doesn't mean that there is no code that can do that.
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security 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
Re: [TLS] Possible TLS 1.3 erratum
On Mon, Jul 19, 2021, at 23:25, Hubert Kario wrote: > That's because browsers don't have the code to handle RSA-PSS certificates. Not ALL the code, but we only have one small piece left in Firefox. And we have plans to address the final small piece. So maybe soon. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] WGLC for draft-ietf-tls-cross-sni-resumption
I support publication. > https://datatracker.ietf.org/doc/draft-ietf-tls-cross-sni-resumption/ ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] WGLC for draft-ietf-tls-cross-sni-resumption
On 19/07/2021 15:16, Salz, Rich wrote: 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 ".campaign." and the wildcard was for "*.campaign.".) 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 https://datatracker.ietf.org/doc/draft-ietf-tls-cross-sni-resumption/ ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls OpenPGP_0x5AB2FAF17B172BEA.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] WGLC for draft-ietf-tls-cross-sni-resumption
On 7/19/2021 10:16 AM, Salz, Rich wrote: I support publication. https://datatracker.ietf.org/doc/draft-ietf-tls-cross-sni-resumption/ ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls 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 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] WGLC for draft-ietf-tls-cross-sni-resumption
On Mon, Jul 19, 2021 at 11:02 AM Stephen Farrell
wrote:
> 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'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)
> I think both of those are indicators that this mechanism
> 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?
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] WGLC for draft-ietf-tls-cross-sni-resumption
Hiya,
On 19/07/2021 16:21, Ryan Sleevi wrote:
On Mon, Jul 19, 2021 at 11:02 AM Stephen Farrell
wrote:
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'm not sure I'm parsing this correctly.
Are you saying that you don't believe network isolation keys are
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:
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.
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.)
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)
I think both of those are indicators that this mechanism
could be used at scale for tracking.
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
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?
OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] WGLC for draft-ietf-tls-cross-sni-resumption
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
wrote:
>
>
> On Mon, Jul 19, 2021 at 11:02 AM Stephen Farrell <
> stephen.farr...@cs.tcd.ie> wrote:
>
>> 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'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)
>
>
>
>> I think both of those are indicators that this mechanism
>> 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?
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] WGLC for draft-ietf-tls-cross-sni-resumption
Hiya, On 19/07/2021 17:17, David Benjamin wrote: 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. 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. OpenPGP_0x5AB2FAF17B172BEA.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] WGLC for draft-ietf-tls-cross-sni-resumption
On Mon, Jul 19, 2021 at 12:27 PM Stephen Farrell wrote: > > Hiya, > > On 19/07/2021 17:17, David Benjamin wrote: > > 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. > > 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. > 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 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] WGLC for draft-ietf-tls-cross-sni-resumption
Hiya, On 19/07/2021 17:35, David Benjamin wrote: 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. 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. OpenPGP_0x5AB2FAF17B172BEA.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] WGLC for draft-ietf-tls-cross-sni-resumption
On Mon, Jul 19, 2021 at 12:38 PM Stephen Farrell wrote: > > Hiya, > > On 19/07/2021 17:35, David Benjamin wrote: > > 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. > > 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. > 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 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Possible TLS 1.3 erratum
Hubert Kario writes: >It only doesn't matter if you don't want to verify the certificate... > >It's one thing to be able to be able to verify an RSA-PSS signature on TLS >level, it's entirely another to be able to properly handle all the different >RSA-PSS limitations when using it in SPKI in X.509. Is there anything that's jumped through all the hoops to implement the complex mess that is PSS but then not added the few lines of code you need do verify it in certificates? And if so, why? In any case it's still encoding a minor implementation artefact of the certificate library being used into the TLS protocol, where it has absolutely no place. You either do PSS or you don't, and the TLS layer doesn't need to know what magic number you use to identify it in certificates. More to the point, for a number of certificate libraries there's no way for the TLS layer to know what magic number is used because it's a minor implementation detail that isn't exposed in the API. Peter. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] WGLC for draft-ietf-tls-cross-sni-resumption
Hiya, On 19/07/2021 17:50, David Benjamin wrote: 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. 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. OpenPGP_0x5AB2FAF17B172BEA.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] WGLC for draft-ietf-tls-cross-sni-resumption
On Mon, Jul 19, 2021 at 4:20 PM Stephen Farrell wrote: > > Hiya, > > On 19/07/2021 17:50, David Benjamin wrote: > > 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. > > 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. > 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 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] WGLC for draft-ietf-tls-cross-sni-resumption
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. OpenPGP_0x5AB2FAF17B172BEA.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] WGLC for draft-ietf-tls-cross-sni-resumption
On Mon, Jul 19, 2021 at 5:32 PM Stephen Farrell wrote: > > 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? > 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 > 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. > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] WGLC for draft-ietf-tls-cross-sni-resumption
Hiya, On 19/07/2021 22:43, David Benjamin wrote: 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. Ack. It sounds like you disagree with this reasoning because you are unhappy 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 resumption? An alternate suggestion of "don't publish the draft" does not work, because having resumption in form means we need to consider this. 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. OpenPGP_0x5AB2FAF17B172BEA.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
