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