Re: [TLS] Summarizing identity change discussion so far

[Marsh Ray <[e-mail]>]

Martin Rex wrote:
> 
> The secure TLS renegotiation _ONLY_  assures that the TLS endpoint
> can not be tranferred among different peers without their _consent_
> during renegotiation.  An MitM attacker is someone acting without consent.

"Consent" isn't relevant, unless you're suggesting there are systems
intentionally handing out secret key material.

> As long as switching of the identity is permitted during renegotiation
> (which it currently is), there is only a vague concept of
> "party" at the other end.

The remote party may be a physically hardened and tamper-resistant
crypto module, or it may be some set of shared processes operating
across a "cloud". In that sense it is nebulous, but that is outside the
scope of the protocol.

After this fix, the TLS concept of "remote party identity" becomes
maximally "the identity established by the union of all valid and
correct credentials validated during the establishment of a connection
state on this connection, and transitively to all connections sharing at
least one master_secret".

For example, given the basic assumptions about the remote endpoint (it
isn't pwned), you can believe all those credentials came from the same
web browser.

An application protocol is free to require its clients and servers to
apply credentials more conservatively, of course.

I suspect you would prefer application protocols to use a more minimal
sense interpretation of identity, such as "the credentials validated
during the establishment of just this one connection state". But this
isn't sufficient for some uses of https and it is ambiguous for
application data interleaved with handshake messages, so the maximal
interpretation is actually better defined than yours.

>>> If we make any recommendations for TLS libraries it should be to
>>> not do renegotiation unless the application asks for it by
>>> registering a callback.
> 
> Clients usually do _not_ want renegotiation, but they have no say

Some clients prefer renegotiation because they believe it lends
confidentiality to the "public" client certificate.

> in the TLS handshake.  It is the Server which decides whether to
> ask for a certificate on the initial handshake or whether the
> server wants to make up his mind only after having seen the clients
> request.

Really it should be defined as part of any application protocol using TLS.

> The issue is often usability / user-experience.  If you ask a Browser
> for a certificate on the initial connect, it will result in a popup
> windows to the user, even if that user has no certificate.  It
> is possible to configure the browser to suppress this popup,
> but often the browser has only a single configuration option
> that says "select automatically", and that does actually two
> different things, i.e. use a client certificate when the request
> from the server matches exactly one client cert -- an the latter
> is something one might want _not_ to happen automatically--in
> contrast to automatic reply that no client cert is available.

A. Yes, that's how browsers work.

B. The number of applications which are "browsers" pop-up "choose a
client cert" dialogs is small, I can think of four or five (actively
maintained). This has got to be a tiny fraction of TLS client
applications, even if it is the most visible and familiar for most people.

> The get-style API is _the_only_ API that I provide to our applications.
> Besides, I'm coming from the GSS-API world, and there never was
> a callback API.
> 
> If you think that get-style API is dangerous, then you seem to be
> quite unaware about the risks involved with some of the callback APIs
> (besides being difficult to use in distributed architectures).

Then you can call the TLS library in a loop to invert the call.

> TLS peers should check the peer's ID before they start sending
> or receiving any data over the newly established TLS session.

For current (pre-fix) https servers, the client's Finished message can
be the most important thing it sends.

> Apps protocols that infer from a successful TLS handshake that
> previously received plaintext data is authenticated suffer from
> a serious apps-level design flaw.
>
> Abusing GSS-API or TLS as an OTP plaintext authentication scheme
> is IMHO a severe APPS design flaw.  The ability to complete a
> TLS handshake (or to establish a gssapi security context)
> does not, by itself, convey any kind of intent.

It's up to the app layer to define 'intent' the events exposed by the
API, based on the stated and implied guarantees of the protocol spec.

> Apps that infer intent from this, should really rethink their
> flawed architecture.

No, the design flaw was in SSLv3. It regressed on a fundamental security
guarantee of SSLv2 and no one (including the spec writers) realized it
at the time.

- Marsh