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 <[email protected] > <mailto:[email protected]>> 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 > [email protected] <mailto:[email protected]> > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/tls
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
