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

[Carrick Bartle]

I've submitted a PR that addresses this issue: 
https://github.com/vasilvv/tls-cross-sni-resumption/pull/3 


In general though, I support publication of this draft.


> On Aug 11, 2021, at 3:50 PM, Carrick Bartle 
>  wrote:
> 
> Okay, in that case, I wouldn't use the word "re-validated," since to me that 
> sounds like the certificate is to be completely validated again (e.g. 
> checking expiration). Instead I would say something like "attempt resumption 
> only if the certificate is valid for the new SNI," ideally with a reference 
> to the current best practice of how to do that.
> 
> 
> 
>> On Aug 11, 2021, at 3:25 PM, David Benjamin > > wrote:
>> 
>> On Wed, Aug 11, 2021 at 5:49 PM Carrick Bartle > > wrote:
>>> - Ticket-based PSKs carry over the server certificate from the previous 
>>> connection
>> 
>> What does "carry over" mean here? That the client literally holds on to the 
>> certificate and re-evaluates it before resumption? Or just that the trust 
>> from evaluating the certificate during the initial handshake also applies to 
>> the PSK? Because, AFAICT, the literal ticket isn't required to contain the 
>> server certificate.
>> 
>> I meant the latter. Though every TLS stack I've seen does actually retain 
>> the peer certificate. It's not in the literal ticket (that wouldn't work 
>> since it's issued by the server), but in the session state the client stores 
>> alongside the ticket, just like the PSK and other state. This is because TLS 
>> APIs typically have some kind of function to get the peer certificate, and 
>> applications typically expect that function to work consistently for all 
>> connections. That stuff is mostly not in the RFCs because it's local state 
>> and TLS doesn't define an API.
>> 
>> Anyway, as with any other use of resumption, in order to offer a ticket, you 
>> need to have retained enough information locally to know that the trust from 
>> the initial handshake is also good for this connection. This could be 
>> remembering application context (perhaps by way of separate session caches). 
>> This could be remembering the whole certificate. This could be remembering 
>> smaller amounts of information from the certificate. The exact details here 
>> I don't think TLS should specify, only the conditions on when using a 
>> session is okay.
>> 
>> David
>>  
>>> On Aug 11, 2021, at 2:13 PM, David Benjamin >> > wrote:
>>> 
>>> On Wed, Aug 11, 2021 at 5:00 PM Carrick Bartle 
>>> >> > wrote:
>>> >  Notably, it still relies on the server certificate being re-validated 
>>> > against the new SNI at the
>>> >  session resumption time.
>>> 
>>> Where is this specified? I can't find it in RFC 8446. (Sorry if I missed 
>>> it.)
>>> 
>>> Does RFC 8446 actually say this? I haven't looked carefully, but I suspect, 
>>> if it says anything useful, it's implicit in how resumption works:
>>> 
>>> - If the client offers a PSK, it must be okay with the server 
>>> authenticating as that PSK for this connection
>>> - Ticket-based PSKs carry over the server certificate from the previous 
>>> connection
>>> - Therefore, in order to offer a ticket in a connection, the client must be 
>>> okay with that previous server certificate in the context of that 
>>> connection. Server name, trust anchors, and all.
>>> 
>>> This is another one of those cases where cross-SNI resumption is just a 
>>> more obvious example of a general principle that needs to be written down 
>>> somewhere in TLS proper. (Even with the same SNI, suppose two different 
>>> parts of my application use different trust stores. My session resumption 
>>> decisions must be consistent with that.)
>>>  
>>> >  However, in the absence of additional signals, it discourages using a 
>>> > session ticket when the SNI value > does not match ([RFC8446], Section 
>>> > 4.6.1), as there is normally no reason to assume that all servers
>>> > sharing the same certificate would also share the same session keys.
>>> 
>>> It'd be helpful to describe under what circumstances there is reason to 
>>> assume that servers that share the same certificate also share the same 
>>> session keys (and are able to take advantage of cross-SNI resumption).
>>> 
>>> 
>>> > On Jul 30, 2021, at 6:57 PM, Christopher Wood >> > > wrote:
>>> > 
>>> > 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:
>>> >> 
>>> >>https://datatracker.ietf.org/doc/draft-ietf-tls-cross-sni-resumption/ 
>>> >> 

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

[Eric Rescorla]

This document seems generally fine. I agree with MT that the security
considerations could be beefed up.

On Wed, Aug 11, 2021 at 3:53 PM Carrick Bartle  wrote:

> Okay, in that case, I wouldn't use the word "re-validated," since to me
> that sounds like the certificate is to be completely validated again (e.g.
> checking expiration). Instead I would say something like "attempt
> resumption only if the certificate is valid for the new SNI," ideally with
> a reference to the current best practice of how to do that.
>
>
>
> On Aug 11, 2021, at 3:25 PM, David Benjamin  wrote:
>
> On Wed, Aug 11, 2021 at 5:49 PM Carrick Bartle 
> wrote:
>
>> - Ticket-based PSKs carry over the server certificate from the previous
>> connection
>>
>>
>> What does "carry over" mean here? That the client literally holds on to
>> the certificate and re-evaluates it before resumption? Or just that the
>> trust from evaluating the certificate during the initial handshake also
>> applies to the PSK? Because, AFAICT, the literal ticket isn't required to
>> contain the server certificate.
>>
>
> I meant the latter. Though every TLS stack I've seen does actually retain
> the peer certificate. It's not in the literal ticket (that wouldn't work
> since it's issued by the server), but in the session state the client
> stores alongside the ticket, just like the PSK and other state. This is
> because TLS APIs typically have some kind of function to get the peer
> certificate, and applications typically expect that function to work
> consistently for all connections. That stuff is mostly not in the RFCs
> because it's local state and TLS doesn't define an API.
>
> Anyway, as with any other use of resumption, in order to offer a ticket,
> you need to have retained enough information locally to know that the trust
> from the initial handshake is also good for this connection. This could be
> remembering application context (perhaps by way of separate session
> caches). This could be remembering the whole certificate. This could be
> remembering smaller amounts of information from the certificate. The exact
> details here I don't think TLS should specify, only the conditions on when
> using a session is okay.
>
> David
>
>
>> On Aug 11, 2021, at 2:13 PM, David Benjamin 
>> wrote:
>>
>> On Wed, Aug 11, 2021 at 5:00 PM Carrick Bartle > 40icloud@dmarc.ietf.org> wrote:
>>
>>> >  Notably, it still relies on the server certificate being re-validated
>>> against the new SNI at the
>>> >  session resumption time.
>>>
>>> Where is this specified? I can't find it in RFC 8446. (Sorry if I missed
>>> it.)
>>>
>>
>> Does RFC 8446 actually say this? I haven't looked carefully, but I
>> suspect, if it says anything useful, it's implicit in how resumption works:
>>
>> - If the client offers a PSK, it must be okay with the server
>> authenticating as that PSK for this connection
>> - Ticket-based PSKs carry over the server certificate from the previous
>> connection
>> - Therefore, in order to offer a ticket in a connection, the client must
>> be okay with that previous server certificate in the context of that
>> connection. Server name, trust anchors, and all.
>>
>> This is another one of those cases where cross-SNI resumption is just a
>> more obvious example of a general principle that needs to be written down
>> somewhere in TLS proper. (Even with the same SNI, suppose two different
>> parts of my application use different trust stores. My session resumption
>> decisions must be consistent with that.)
>>
>>
>>> >  However, in the absence of additional signals, it discourages using a
>>> session ticket when the SNI value > does not match ([RFC8446], Section
>>> 4.6.1), as there is normally no reason to assume that all servers
>>> > sharing the same certificate would also share the same session keys.
>>>
>>> It'd be helpful to describe under what circumstances there is reason to
>>> assume that servers that share the same certificate also share the same
>>> session keys (and are able to take advantage of cross-SNI resumption).
>>>
>>>
>>> > On Jul 30, 2021, at 6:57 PM, Christopher Wood 
>>> wrote:
>>> >
>>> > 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:
>>> >>
>>> >>
>>> 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
>>> >>
>>> >> ___
>>> >> TLS mailing list

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

[Carrick Bartle]

Okay, in that case, I wouldn't use the word "re-validated," since to me that 
sounds like the certificate is to be completely validated again (e.g. checking 
expiration). Instead I would say something like "attempt resumption only if the 
certificate is valid for the new SNI," ideally with a reference to the current 
best practice of how to do that.



> On Aug 11, 2021, at 3:25 PM, David Benjamin  wrote:
> 
> On Wed, Aug 11, 2021 at 5:49 PM Carrick Bartle  > wrote:
>> - Ticket-based PSKs carry over the server certificate from the previous 
>> connection
> 
> What does "carry over" mean here? That the client literally holds on to the 
> certificate and re-evaluates it before resumption? Or just that the trust 
> from evaluating the certificate during the initial handshake also applies to 
> the PSK? Because, AFAICT, the literal ticket isn't required to contain the 
> server certificate.
> 
> I meant the latter. Though every TLS stack I've seen does actually retain the 
> peer certificate. It's not in the literal ticket (that wouldn't work since 
> it's issued by the server), but in the session state the client stores 
> alongside the ticket, just like the PSK and other state. This is because TLS 
> APIs typically have some kind of function to get the peer certificate, and 
> applications typically expect that function to work consistently for all 
> connections. That stuff is mostly not in the RFCs because it's local state 
> and TLS doesn't define an API.
> 
> Anyway, as with any other use of resumption, in order to offer a ticket, you 
> need to have retained enough information locally to know that the trust from 
> the initial handshake is also good for this connection. This could be 
> remembering application context (perhaps by way of separate session caches). 
> This could be remembering the whole certificate. This could be remembering 
> smaller amounts of information from the certificate. The exact details here I 
> don't think TLS should specify, only the conditions on when using a session 
> is okay.
> 
> David
>  
>> On Aug 11, 2021, at 2:13 PM, David Benjamin > > wrote:
>> 
>> On Wed, Aug 11, 2021 at 5:00 PM Carrick Bartle 
>> > > wrote:
>> >  Notably, it still relies on the server certificate being re-validated 
>> > against the new SNI at the
>> >  session resumption time.
>> 
>> Where is this specified? I can't find it in RFC 8446. (Sorry if I missed it.)
>> 
>> Does RFC 8446 actually say this? I haven't looked carefully, but I suspect, 
>> if it says anything useful, it's implicit in how resumption works:
>> 
>> - If the client offers a PSK, it must be okay with the server authenticating 
>> as that PSK for this connection
>> - Ticket-based PSKs carry over the server certificate from the previous 
>> connection
>> - Therefore, in order to offer a ticket in a connection, the client must be 
>> okay with that previous server certificate in the context of that 
>> connection. Server name, trust anchors, and all.
>> 
>> This is another one of those cases where cross-SNI resumption is just a more 
>> obvious example of a general principle that needs to be written down 
>> somewhere in TLS proper. (Even with the same SNI, suppose two different 
>> parts of my application use different trust stores. My session resumption 
>> decisions must be consistent with that.)
>>  
>> >  However, in the absence of additional signals, it discourages using a 
>> > session ticket when the SNI value > does not match ([RFC8446], Section 
>> > 4.6.1), as there is normally no reason to assume that all servers
>> > sharing the same certificate would also share the same session keys.
>> 
>> It'd be helpful to describe under what circumstances there is reason to 
>> assume that servers that share the same certificate also share the same 
>> session keys (and are able to take advantage of cross-SNI resumption).
>> 
>> 
>> > On Jul 30, 2021, at 6:57 PM, Christopher Wood > > > wrote:
>> > 
>> > 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:
>> >> 
>> >>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
>> >> 
>> >> 

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

[David Benjamin]

On Wed, Aug 11, 2021 at 5:49 PM Carrick Bartle 
wrote:

> - Ticket-based PSKs carry over the server certificate from the previous
> connection
>
>
> What does "carry over" mean here? That the client literally holds on to
> the certificate and re-evaluates it before resumption? Or just that the
> trust from evaluating the certificate during the initial handshake also
> applies to the PSK? Because, AFAICT, the literal ticket isn't required to
> contain the server certificate.
>

I meant the latter. Though every TLS stack I've seen does actually retain
the peer certificate. It's not in the literal ticket (that wouldn't work
since it's issued by the server), but in the session state the client
stores alongside the ticket, just like the PSK and other state. This is
because TLS APIs typically have some kind of function to get the peer
certificate, and applications typically expect that function to work
consistently for all connections. That stuff is mostly not in the RFCs
because it's local state and TLS doesn't define an API.

Anyway, as with any other use of resumption, in order to offer a ticket,
you need to have retained enough information locally to know that the trust
from the initial handshake is also good for this connection. This could be
remembering application context (perhaps by way of separate session
caches). This could be remembering the whole certificate. This could be
remembering smaller amounts of information from the certificate. The exact
details here I don't think TLS should specify, only the conditions on when
using a session is okay.

David


> On Aug 11, 2021, at 2:13 PM, David Benjamin  wrote:
>
> On Wed, Aug 11, 2021 at 5:00 PM Carrick Bartle  40icloud@dmarc.ietf.org> wrote:
>
>> >  Notably, it still relies on the server certificate being re-validated
>> against the new SNI at the
>> >  session resumption time.
>>
>> Where is this specified? I can't find it in RFC 8446. (Sorry if I missed
>> it.)
>>
>
> Does RFC 8446 actually say this? I haven't looked carefully, but I
> suspect, if it says anything useful, it's implicit in how resumption works:
>
> - If the client offers a PSK, it must be okay with the server
> authenticating as that PSK for this connection
> - Ticket-based PSKs carry over the server certificate from the previous
> connection
> - Therefore, in order to offer a ticket in a connection, the client must
> be okay with that previous server certificate in the context of that
> connection. Server name, trust anchors, and all.
>
> This is another one of those cases where cross-SNI resumption is just a
> more obvious example of a general principle that needs to be written down
> somewhere in TLS proper. (Even with the same SNI, suppose two different
> parts of my application use different trust stores. My session resumption
> decisions must be consistent with that.)
>
>
>> >  However, in the absence of additional signals, it discourages using a
>> session ticket when the SNI value > does not match ([RFC8446], Section
>> 4.6.1), as there is normally no reason to assume that all servers
>> > sharing the same certificate would also share the same session keys.
>>
>> It'd be helpful to describe under what circumstances there is reason to
>> assume that servers that share the same certificate also share the same
>> session keys (and are able to take advantage of cross-SNI resumption).
>>
>>
>> > On Jul 30, 2021, at 6:57 PM, Christopher Wood 
>> wrote:
>> >
>> > 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:
>> >>
>> >>
>> 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
>> >>
>> >> ___
>> >> 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
>>
>> ___
>> 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

[Carrick Bartle]

> - Ticket-based PSKs carry over the server certificate from the previous 
> connection

What does "carry over" mean here? That the client literally holds on to the 
certificate and re-evaluates it before resumption? Or just that the trust from 
evaluating the certificate during the initial handshake also applies to the 
PSK? Because, AFAICT, the literal ticket isn't required to contain the server 
certificate.


> On Aug 11, 2021, at 2:13 PM, David Benjamin  wrote:
> 
> On Wed, Aug 11, 2021 at 5:00 PM Carrick Bartle 
> mailto:40icloud@dmarc.ietf.org>> 
> wrote:
> >  Notably, it still relies on the server certificate being re-validated 
> > against the new SNI at the
> >  session resumption time.
> 
> Where is this specified? I can't find it in RFC 8446. (Sorry if I missed it.)
> 
> Does RFC 8446 actually say this? I haven't looked carefully, but I suspect, 
> if it says anything useful, it's implicit in how resumption works:
> 
> - If the client offers a PSK, it must be okay with the server authenticating 
> as that PSK for this connection
> - Ticket-based PSKs carry over the server certificate from the previous 
> connection
> - Therefore, in order to offer a ticket in a connection, the client must be 
> okay with that previous server certificate in the context of that connection. 
> Server name, trust anchors, and all.
> 
> This is another one of those cases where cross-SNI resumption is just a more 
> obvious example of a general principle that needs to be written down 
> somewhere in TLS proper. (Even with the same SNI, suppose two different parts 
> of my application use different trust stores. My session resumption decisions 
> must be consistent with that.)
>  
> >  However, in the absence of additional signals, it discourages using a 
> > session ticket when the SNI value > does not match ([RFC8446], Section 
> > 4.6.1), as there is normally no reason to assume that all servers
> > sharing the same certificate would also share the same session keys.
> 
> It'd be helpful to describe under what circumstances there is reason to 
> assume that servers that share the same certificate also share the same 
> session keys (and are able to take advantage of cross-SNI resumption).
> 
> 
> > On Jul 30, 2021, at 6:57 PM, Christopher Wood  > > wrote:
> > 
> > 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:
> >> 
> >>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
> >> 
> >> ___
> >> 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 
> > 
> 
> ___
> 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

[David Benjamin]

On Wed, Aug 11, 2021 at 5:00 PM Carrick Bartle  wrote:

> >  Notably, it still relies on the server certificate being re-validated
> against the new SNI at the
> >  session resumption time.
>
> Where is this specified? I can't find it in RFC 8446. (Sorry if I missed
> it.)
>

Does RFC 8446 actually say this? I haven't looked carefully, but I suspect,
if it says anything useful, it's implicit in how resumption works:

- If the client offers a PSK, it must be okay with the server
authenticating as that PSK for this connection
- Ticket-based PSKs carry over the server certificate from the previous
connection
- Therefore, in order to offer a ticket in a connection, the client must be
okay with that previous server certificate in the context of that
connection. Server name, trust anchors, and all.

This is another one of those cases where cross-SNI resumption is just a
more obvious example of a general principle that needs to be written down
somewhere in TLS proper. (Even with the same SNI, suppose two different
parts of my application use different trust stores. My session resumption
decisions must be consistent with that.)


> >  However, in the absence of additional signals, it discourages using a
> session ticket when the SNI value > does not match ([RFC8446], Section
> 4.6.1), as there is normally no reason to assume that all servers
> > sharing the same certificate would also share the same session keys.
>
> It'd be helpful to describe under what circumstances there is reason to
> assume that servers that share the same certificate also share the same
> session keys (and are able to take advantage of cross-SNI resumption).
>
>
> > On Jul 30, 2021, at 6:57 PM, Christopher Wood 
> wrote:
> >
> > 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:
> >>
> >>
> 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
> >>
> >> ___
> >> 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
>
> ___
> 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

[Carrick Bartle]

>  Notably, it still relies on the server certificate being re-validated 
> against the new SNI at the
>  session resumption time.

Where is this specified? I can't find it in RFC 8446. (Sorry if I missed it.)

>  However, in the absence of additional signals, it discourages using a 
> session ticket when the SNI value > does not match ([RFC8446], Section 
> 4.6.1), as there is normally no reason to assume that all servers
> sharing the same certificate would also share the same session keys.

It'd be helpful to describe under what circumstances there is reason to assume 
that servers that share the same certificate also share the same session keys 
(and are able to take advantage of cross-SNI resumption).


> On Jul 30, 2021, at 6:57 PM, Christopher Wood  wrote:
> 
> 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:
>> 
>>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
>> 
>> ___
>> 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

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

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

[Martin Thomson]

This document is mostly fine.

The text on use of client certificates isn't particularly clear.  The key piece 
of information that a reader is going to need is that a resumed connection will 
include any (and potentially all) client authentication.

I found the meat of the flag definition hard to follow.  There is a lot of 2119 
language, but very little of it relates to the operation of this extension.  
Some is just restatement of RFC 8446, which comes with real risks and should be 
avoided.  I think that what this needs to say is:

1. What the protocol mechanism is: (a flag in NST)
2. What sending that signal means.  For example, "The flag is an assertion from 
the server that all servers that answer to the names in the certificate are 
able to use this ticket."
3. What the client might do with that.  For example, "If a client would accept 
the certificate for a new connection, it can/MAY attempt resumption even if the 
server name differs from the server name of the original connection." <- that 
might be the only 2119 language you need in the entire document, though I'm not 
sure you even need that.

Then talk about consequences (this is currently in Security Considerations and 
is mostly good, though not all of this belongs in a section with that title):

1. What if the server is wrong in its assertion.   For example, "A server that 
wrongly advertises this flag could cause clients to waste tickets on connection 
attempts where resumption will not be successful."
2. Why the server might choose not to do this: need to coordinate across a 
deployment, it could be wrong, certificate bloat, key compromise scope, etc... 
(the existing text on this is fine)
3. What the client needs to consider before exercising this option (tracking -> 
partitioning, client authn)

On Sat, Jul 17, 2021, at 09:55, Christopher Wood wrote:
> 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
> 
> ___
> 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

[Christopher Wood]

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:
> 
> 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
> 
> ___
> 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

[Stephen Farrell]

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

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

[David Benjamin]

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

[Stephen Farrell]

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

[David Benjamin]

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

[Stephen Farrell]

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

[David Benjamin]

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] WGLC for draft-ietf-tls-cross-sni-resumption

[Stephen Farrell]

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

[David Benjamin]

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

[Stephen Farrell]

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

[David Benjamin]

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

[Stephen Farrell]

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

[Ryan Sleevi]

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

[Michael StJohns]

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

[Stephen Farrell]

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

[Salz, Rich]

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

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

[Christopher Wood]

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

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