Martin Thomson wrote: > On 21 July 2016 at 18:41, Martin Rex <m...@sap.com> wrote: >> A server that implements this extension MUST NOT accept the request >> to resume the session if the server_name extension contains a >> different name. Instead, it proceeds with a full handshake to >> establish a new session. > > If that's the only barrier to doing this, I'd be surprised. The > prospect of having to overcome this is not at all daunting.
No, that is only the tip of an iceberg, and you're going Titanic here. Really, this is about TLS session cache management (which is something very close to TLS) vs. Endpoint identification, i.e. interpreting end-entity certificates -- which is something that is explicitly outside of the scope of TLS (e.g. rfc2818 and rfc6125). Could you please describe the approach to session cache management that you're conceiving here? In the original TLS architecture (up to TLSv1.2) TLS sessions are read-only after creation, and identities (certificates) are locked down. Forgetting to cryptographically bind the communication identities into the session properties allowed the triple-handshake-attack. If you want to change any session properties (including certificates), you MUST perform a new full handshake, which creates a new session with new properties and a new session ID / session cache entry. Session resumption (and session resumption proposal) should operate based on requested properties (is there an existing session with the requested properties?) and this is conceptually independent from the app-level endpoint identification (such as rfc2818/rfc6125). The wording in rfc6066 is not optimal. It should have better said: whenever a full handshake would result in selection of a different server certificate, then the server MUST perform a full handshake, in order to produce predictable/deterministic behaviour that is not side-effected by session cache management / session cache lifetime effects. The principle of least surprise. -Martin _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
