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

[Victor Vasiliev <[e-mail]>]

I believe that an ability to resume across different server_name values
specified in the subjectAltName of a certificate will have a positive
performance impact on the websites which due to various reasons have to
fetch
resources from different servers.  A particular use case I have in mind is
when
a website maintains a pool of servers, say, *.cdn.example.com, and supplies
a
specific server directly in a resource URL.  In that case, all the servers
already share a wildcard certificate with a secret, so they can share a
ticket
key too, meaning it makes sense for them to accept the ticket issued by
another
server in the pool.

There are potential confusion issues associated with using a ticket for a
different server name, both with the server becoming confused and the client
becoming confused.  On the server side, this requires implementations to
know
how to handle SNI value change.  I suggest that the servers should
explicitly
indicate to the client that a newly issued ticket may be used for all the
subjectAltName values present in the server's certificate.

Clients must also account for any per-host differences before offering a
ticket.  For instance, web browsers typically require users to pick a
certificate for each domain they authenticate to, so resumption across
different SNI values should obviously not happen here.  One can also
imagine,
say, a client which uses different cipher configuration or a different set
of
trust anchors for each host.  In all of those cases, it is on the client to
not
cross-resume, but a lot of those concerns are application-specific in
nature,
so I am not sure how much guidance can the TLS specification provide on this
matter.


On Thu, Oct 20, 2016 at 8:33 PM, Eric Rescorla <[e-mail]> wrote:

> We used to explicitly say that you had to check SNI for 0-RTT (but
> didn't say anything about resumption). On the principle that 0-RTT and
> resumption should be the same I removed that, but it turns out that
> the document doesn't actually have any rule at all other than the one
> we've inherited from RFC 6066, which clearly says that you can't
> resume with a different SNI [0].
>
> Following the discussion in
> https://github.com/tlswg/tls13-spec/issues/720 I've added a statement
> to the draft clarifying that the RFC 6066 rule still applies [1]
>
> With that said, it does seem like there might be situations where it
> would be useful to allow resumption/0-RTT with different SNIs. My
> intuition (partly informed by [2]) is that this is something we should
> be pretty careful about and have the server opt-in explicitly (if at
> all) but I'm willing to be wrong about that.
>
> Comments?
> -Ekr
>
>
> [0] https://tools.ietf.org/rfcmarkup?doc=6066#section-3
> [1] https://github.com/tlswg/tls13-spec/commit/
> b26093b5e9143fb61f5b619d1da78c4ba54b2121
> [2] http://antoine.delignat-lavaud.fr/doc/www15.pdf
>
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>
>