Re: [TLS] Call for adoption of draft-vvv-tls-cross-sni-resumption

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.com@dmarc.ietf.org>
wrote:

> I support the draft and will review.
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>