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