IETF Logo Mail Archive

Re: [TLS] [CHANNEL-BINDING] [sasl] Updates to

Larry Zhu <larry.zhu@microsoft.com> Tue, 23 March 2010 23:41 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 DB97C3A6938; Tue, 23 Mar 2010 16:41:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.221
X-Spam-Level:
X-Spam-Status: No, score=-9.221 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 8sCPUXZi1TZa; Tue, 23 Mar 2010 16:41:53 -0700 (PDT)
Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id ED07E3A68AF; Tue, 23 Mar 2010 16:41:52 -0700 (PDT)
Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 23 Mar 2010 16:42:12 -0700
Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) with Microsoft SMTP Server (TLS) id 14.0.639.21; Tue, 23 Mar 2010 16:42:12 -0700
Received: from TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.141]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi; Tue, 23 Mar 2010 16:42:11 -0700
From: Larry Zhu <larry.zhu@microsoft.com>
To: "<mrex@sap.com>" <mrex@sap.com>
Thread-Topic: [TLS] [CHANNEL-BINDING] [sasl] Updates to
Thread-Index: AQHKyt6YVbfsrek0G0SgZPtlzjfE8pIApHsA
Date: Tue, 23 Mar 2010 23:42:02 +0000
Message-ID: <390DE3D1-279D-4E90-BFDF-43C9D73954A3@microsoft.com>
References: <201003232314.o2NNEX6n002849@fs4113.wdf.sap.corp>
In-Reply-To: <201003232314.o2NNEX6n002849@fs4113.wdf.sap.corp>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: text/plain; charset="us-ascii"
Content-ID: <5b2e89c7-bdbb-4d64-9779-5852ff169478>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Mark Novak <Mark.Novak@microsoft.com>, "channel-binding@ietf.org" <channel-binding@ietf.org>, "Nicolas.Williams@sun.com" <Nicolas.Williams@sun.com>, "pasi.eronen@nokia.com" <pasi.eronen@nokia.com>, "tls@ietf.org" <tls@ietf.org>, "sasl@ietf.org" <sasl@ietf.org>
Subject: Re: [TLS] [CHANNEL-BINDING] [sasl] Updates to
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: Tue, 23 Mar 2010 23:41:55 -0000

More precisely we allow you treat the renegotiated channel the same in  
tls- endpiont, or differentally in tls-unique. Thus the flexiblity  
remains yours.

Sent from my phone

On Mar 23, 2010, at 4:16 PM, "Martin Rex" <mrex@sap.com> wrote:

> Larry Zhu wrote:
>>
>> It is amusing that if you actually suggest that it is more complex
>> to leave the behavior as undefined.
>
> The part that is a little funny (or weird) is something else.
>
> When we realized that the original TLS renegotiation resulted,
> in fact, in a completely different and unrelated channel than
> its predecessor, and that all apps that blindly assumed it
> would be still the same channel, we decided to fix TLS and
> provide that assurance to the app.
>
> _After_ fixing TLS renegotiation, it sounds strange to
> define TLS channel bindings that clearly indicate that the
> channel before TLS renegotiation and after TLS renegotiation
> is _NOT_ the same channel (because it uses different channel
> bindings and will make authentications fail that mix them up).
>
> That is IMHO a little weird.
>
>
> -Martin
>
>

v2.23.0 | Report a Bug | By Email