Re: [TLS] HTTP, Certificates, and TLS

[Ilari Liusvaara <[e-mail]>]

On Thu, Jul 21, 2016 at 07:08:04PM +0200, Martin Rex wrote:
> 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? 

Well, I guess it would be reasonable to remember the server identites
on client side, but clear client identities on server side.

Especially the client identies are highly important: If the server
thinks any identity is valid that client thinks is invalid, that will
lead to attacks.

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

No, THS was caused by failing to bind the exchange keys (I consider the
abstract of EMS RFC to be quite misleading).

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

And thanks to all sorts of crypto restrictions, exchange keys have
nothing to do with certificates of any kind (all modes where they
have anything to do are banned), and that the exchange keys are properly
bound.

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

Within context of HTTP, the server authentication is about what
authorities the server is allowed to assert. And in responses, the
server always needs to pick the authority it asserts.

As long as one takes care that no authorities get lost, or that lost
authorities can be recovered if needed (and authroized), then the
behaviour will remain deterministic (modulo possibly few extra RTTs
to recover the lost authroties).


Now, client authentication is entierely different beast. The client
won't inherently assert its authority in HTTP, so the server view
of client authority damn better be subset of what client intended,
or you WILL get privilege escalation attacks.

>From that it follows that the client needs per-request control of
authorities it holds (if to assert them or to disclaim them).



-Ilari