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

[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]

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

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

[TLS] FYI: discussion on TLS 1.2 SignatureAlgorithm IANA allocation

[Benjamin Kaduk]

Hi all,

I recently did an RFC 5742 conflict review of a document that is
allocating new cipher suites for TLS 1.2 and also needs new signature
algorithms.  The document currently requests two allocations from the old TLS
1.2 SignatureAlgorithm registry that TLS 1.3 replaced with the two-octet
SignatureScheme registry.  (Actually, the registrations have been live for
2.5 years but the document is just getting ready for publication as an RFC
now.)

I tried to summarize the history and WG intent at the time of RFCs
8446/8447 in a note to tls-reg-review
(https://mailarchive.ietf.org/arch/msg/tls-reg-review/1RJOKg9Cnt1PHS-iOC5sOOt5aeE/)
and wanted to send a heads-up here in case I'm misrepresenting history
and/or WG intent.

Please send any follow-ups to me directly; I will collate and report back
if it turns out that I did get things wrong.

-Ben

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