Subject: Re: [TLS] SNI and Resumption/0-RTT

From: Victor Vasiliev <[email-masked]>
Date: Wed, 23 Nov 2016 17:46:19 -0500

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>

---

From: Martin Thomson <[email-masked]>
Date: Thu, 24 Nov 2016 10:10:06 +1100

>     <https://github.com/tlswg/tls13-spec/pull/777>

At this point, I think that it would be more sensible to write a
separate extension draft.  There are a bunch of additional
considerations that would be easier to write down in a dedicated
document.