It seems that this issue has not been so far successfully resolved, and to
the
best of my knowledge it has not been discussed during the meeting in Seoul.
I
still believe that this is a valuable feature, and our experience with 0-RTT
handshake deployment in QUIC has indicated that it's basically required to
make
0-RTT work for YouTube videos.
So far, we have considered three options in this thread:
(1) Retain RFC 6066 restriction on SNI,
(2) Allow resumption for different SNI provided it was negotiated in the
ticket,
(3) Always allow resumption for different SNI.
In both (2) and (3), the certificate for the original ticket issuer would
have
to be valid for the new server name, of course.
I believe that (2) will result in a higher resumption success rate than (3),
since for the servers that do not support shared resumption key, (3) would
result in losing session tickets to unsuccessful resumption.
For concreteness, I wrote a pull request that describes (2):
<https://github.com/tlswg/tls13-spec/pull/777>
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
