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

[Benjamin Kaduk <[e-mail]>]

Picking a message somewhat at random to reply to with some more-general
observations...

On 10/24/2016 05:48 PM, Victor Vasiliev wrote:
> 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
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__cdn.example.com&d=DQMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=QlZQH8Ib1casHq6YFMriiZIPnTMzCHTxbPVrN_kDElI&s=t1O12kmBzZmXqHTSFe7DFW0i20d2hmZAgQxx-K8C4z4&e=>,
> 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.
>

I think it is useful to distinguish between this case, where
[cdn.]example.com is the owner of all the content involved, from other
co-tenanted names that have different content owners, such as from a
shared hosting service.  The wildcard cert is pretty clearly in the
"same content owner" case, but even subjectAltNames in a single cert do
not necessarily provide the same indication -- I understand that some
CDNs offer a lower-cost TLS option by means of being a SAN on a cert
that shares names with many different CDN customers.

So, even the server's configuration settings may change as a result of
SNI (e.g., a hosting provider may let customers configure settings
differently even when served from the same TLS server).

> 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.
>

I would argue that changing SNI value on resumption or 0RTT only has a
hope of making sense in the "same content owner" case ... but the client
may not have an easy way of knowing, in the absence of an explicit
server signal as you propose.

> 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.
>
>

Things are getting messy enough that I'm starting to lean towards just
not doing it at all (perhaps with the carve-out for future behavior that
Chrstian wants, if we can satisfy ourselves that it won't ossify).

-Ben

> On Thu, Oct 20, 2016 at 8:33 PM, Eric Rescorla <[e-mail]
> <mailto:[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
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_tlswg_tls13-2Dspec_issues_720&d=DQMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=QlZQH8Ib1casHq6YFMriiZIPnTMzCHTxbPVrN_kDElI&s=7Q2af7DaRnOwrSNMWkMfnKs9xHDrMn9HifdhztZCIks&e=>
>     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
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_rfcmarkup-3Fdoc-3D6066-23section-2D3&d=DQMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=QlZQH8Ib1casHq6YFMriiZIPnTMzCHTxbPVrN_kDElI&s=5EJDx9XlpTf2PkCnuN3iIVKBz8uwMCOQJpwV8fg9xK8&e=>
>     [1] https://github.com/tlswg/tls13-spec/commit/b26093b5e9143fb61f5b619d1da78c4ba54b2121
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_tlswg_tls13-2Dspec_commit_b26093b5e9143fb61f5b619d1da78c4ba54b2121&d=DQMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=QlZQH8Ib1casHq6YFMriiZIPnTMzCHTxbPVrN_kDElI&s=ev2q8--tzpBkxa4aASjneoQ6WrW11JINJquDdDrhtos&e=>
>     [2] http://antoine.delignat-lavaud.fr/doc/www15.pdf
>     <https://urldefense.proofpoint.com/v2/url?u=http-3A__antoine.delignat-2Dlavaud.fr_doc_www15.pdf&d=DQMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=QlZQH8Ib1casHq6YFMriiZIPnTMzCHTxbPVrN_kDElI&s=bjOJibThsgQKY_v0SofUEncVF1EQMrI28rKnNqLupb8&e=>
>
>
>     _______________________________________________
>     TLS mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/tls
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=DQMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=QlZQH8Ib1casHq6YFMriiZIPnTMzCHTxbPVrN_kDElI&s=I84l3Svs9XuDxebbvINR2b6XsvrDNJuv8tVrtr0Dw54&e=>
>
>
>
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls