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

Larry Zhu <larry.zhu@microsoft.com> Thu, 05 November 2009 00:03 UTC

Return-Path: <larry.zhu@microsoft.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE6CF3A67BD; Wed, 4 Nov 2009 16:03:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9gnlcYCWjela; Wed, 4 Nov 2009 16:03:21 -0800 (PST)
Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 086C73A679F; Wed, 4 Nov 2009 16:03:20 -0800 (PST)
Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 4 Nov 2009 16:03:42 -0800
Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) with Microsoft SMTP Server id 14.0.639.20; Wed, 4 Nov 2009 16:03:42 -0800
Received: from TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.181]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi; Wed, 4 Nov 2009 16:03:43 -0800
From: Larry Zhu <larry.zhu@microsoft.com>
To: Nicolas Williams <Nicolas.Williams@sun.com>
Thread-Topic: [TLS] New Problem (Was: Last Call: draft-altman-tls-channel-bindings)
Thread-Index: AQHKXaJ3/jMkb6C1dEyRuhhf/zDndZEmmUig
Date: Thu, 5 Nov 2009 00:03:41 +0000
Message-ID: <D3DC9D45B39CFC4CB312B2DD279B354C29BBA4A1@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com>
References: <20091005162704.8C1B43A6873@core3.amsl.com> <D3DC9D45B39CFC4CB312B2DD279B354C29BADFF7@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com> <20091030223647.GO1105@Sun.COM> <D3DC9D45B39CFC4CB312B2DD279B354C29BBA0B3@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com> <20091104224741.GM1105@Sun.COM>
In-Reply-To: <20091104224741.GM1105@Sun.COM>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "channel-binding@ietf.org" <channel-binding@ietf.org>, "tls@ietf.org" <tls@ietf.org>, "sasl@ietf.org" <sasl@ietf.org>
Subject: Re: [TLS] New Problem (Was: Last Call: draft-altman-tls-channel-bindings)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Nov 2009 00:03:22 -0000

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