I've submitted a PR that addresses this issue: https://github.com/vasilvv/tls-cross-sni-resumption/pull/3 <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 > <cbartle891=40icloud....@dmarc.ietf.org> 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 <david...@chromium.org >> <mailto:david...@chromium.org>> wrote: >> >> On Wed, Aug 11, 2021 at 5:49 PM Carrick Bartle <cbartle...@icloud.com >> <mailto:cbartle...@icloud.com>> 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 <david...@chromium.org >>> <mailto:david...@chromium.org>> wrote: >>> >>> On Wed, Aug 11, 2021 at 5:00 PM Carrick Bartle >>> <cbartle891=40icloud....@dmarc.ietf.org >>> <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 <c...@heapingbits.net >>> > <mailto:c...@heapingbits.net>> 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/ >>> >> <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 >>> >> <https://github.com/vasilvv/tls-cross-sni-resumption> >>> >> >>> >> Thanks, >>> >> Chris, on behalf of the chairs >>> >> >>> >> _______________________________________________ >>> >> TLS mailing list >>> >> TLS@ietf.org <mailto:TLS@ietf.org> >>> >> https://www.ietf.org/mailman/listinfo/tls >>> >> <https://www.ietf.org/mailman/listinfo/tls> >>> >> >>> > >>> > _______________________________________________ >>> > TLS mailing list >>> > TLS@ietf.org <mailto:TLS@ietf.org> >>> > https://www.ietf.org/mailman/listinfo/tls >>> > <https://www.ietf.org/mailman/listinfo/tls> >>> >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org <mailto:TLS@ietf.org> >>> https://www.ietf.org/mailman/listinfo/tls >>> <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
