Re: [CHANNEL-BINDING] [TLS] New Problem (Was: Last Call: draft-altman-tls-channel-bindings)

I think this is good as is. The mentioned issue is in the TLS itself at which layer it knows every well what a TLS connection is so we do not have any confusions related to I mentioned.

Now some comments on the alternative proposals, I would prefer a stable identifier for the channel. If the name of the channel constantly changes when TLS renegotiates, it is a bad taste in the mouth for me.

-----Original Message-----
From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of Nicolas Williams
Sent: Wednesday, November 04, 2009 2:48 PM
To: Larry Zhu
Cc: channel-binding@ietf.org; tls@ietf.org; sasl@ietf.org
Subject: [TLS] New Problem (Was: Last Call: draft-altman-tls-channel-bindings)

On Wed, Nov 04, 2009 at 10:13:46PM +0000, Larry Zhu wrote:
> The proposed looks fine. Thanks,

Thanks.

HOWEVER, Martin's post to the TLS WG list about MITM attacks in
re-negotiations is relevant.

Re-negotiations have no real binding between inner and outer
connections.  Clients can enforce that the server end-point is the same
(has the same certificate, whatever) for both connections: inner and
outer.  Servers can also force the inner connection to change cipher
specs.  But suppose that the outer connection used an TLS_DH_anon_*
cipher suite!  Then there is no binding whatsoever between the inner and
outer connection.  And then we have a real problem for tls-unique.

We need at least a security considerations note about this.  But we
should also consider changing tls-unique to be the client's Finished
message for the _inner-most_ TLS connection, not outer-most.
(Outer-most is OK IFF there's a binding between each channel.)

Comments?

Nico
-- 
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls