Re: [TLS] Summarizing identity change discussion so far

[Martin Rex <[e-mail]>]

Marsh Ray wrote:
> 
> 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.

It is very relevant.  Consenting communication peers can very
well pass around TLS endpoints without the third communication party
realizing that.

Wait a minute -- the finished messages are _NOT_ secrets for the
communication peers, and they are _NOT_ keying material.
The MitM attacker knows perfectly well which Finished messages
would be necessary to make a secure renegotiation work -- but
he can not coerce unsuspecting TLS peers to uses these finished
messages in the fashion that would be required to make a successful
TLS handshake and deceive the third communication peer.

The finished messages are "secure and unique session identifiers",
and something that Nico wants to get his hands on for channel bindings.


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

You do not know where that TLS endpoint is.  What you do know is
that with the secure TLS renegotiation, the TLS endpoint may no
longer be transfered to unsuspecting communication peers.


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

You mean for the old TLS renegotiation when using client certificates?

Yes, I believe so.


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

This comment was _not_ about TLS renegotiation.

I was refering to concepts such as the HTTP-Negotiate authentication,
which abuses GSS-API as a plaintext OTP-authentication scheme.


-Martin