Document: draft-vvv-tls-cross-sni-resumption-00.txt I think we should adopt this draft. Some review comments below.
S 1. Section 4.2.11). 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. The extension defined in this document allows the server to provide such a signal in-band. "session keys" is a weird term here. Perhaps "same session cache"? S 3. The server MAY send the extension if it reasonably believes that any server for any identity presented in its certificate would be capable of accepting that ticket. The server SHOULD NOT send the extension otherwise, since, if the client follows the single-use ticket policy recommended by [RFC8446], sending the ticket results in it being no longer usable regardless of whether resumption has succeeded. Would a MUST be cleaner here? "Reasonably believes" is already pretty weak. I think we should say you can't use this with 1.2, even though it's kind of obvious. S 4. It seems like a cite to https://www.mitls.org/downloads/vhost_confusion.pdf and an explanation of any impact this mechanism has would be in order here. If a client certificate has been associated with the session, the client MUST use the same policy on whether to present said certificate to the server as if it were a new TLS session. For instance, if the client would show a certificate choice prompt for every individual domain it connects to, it MUST show that prompt for the new host when performing cross-domain resumption. This seems like it only applies with post-handshake auth, right, given that you can't do resumption + client auth. -Ekr On Tue, Dec 1, 2020 at 5:49 AM Salz, Rich <rsalz=40akamai....@dmarc.ietf.org> wrote: > I support the draft and will review. > > > _______________________________________________ > 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
