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

[Eric Rescorla <[e-mail]>]

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 <cbartle891=
[e-mail]> 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 <[e-mail]> wrote:
>
> On Wed, Aug 11, 2021 at 5:49 PM Carrick Bartle <[e-mail]>
> 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 <[e-mail]>
>> wrote:
>>
>> On Wed, Aug 11, 2021 at 5:00 PM Carrick Bartle <cbartle891=
>> [e-mail]> 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 <[e-mail]>
>>> 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
>>> >> [e-mail]
>>> >> https://www.ietf.org/mailman/listinfo/tls
>>> >>
>>> >
>>> > _______________________________________________
>>> > TLS mailing list
>>> > [e-mail]
>>> > https://www.ietf.org/mailman/listinfo/tls
>>>
>>> _______________________________________________
>>> TLS mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/tls
>>>
>>
>>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>