Re: [TLS] HTTP, Certificates, and TLS

[[e-mail] (Martin Rex)]

Martin Thomson wrote:
> On 21 July 2016 at 18:41, Martin Rex <[e-mail]> 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