IETF Logo Mail Archive

Re: [TLS] Next steps for draft-ietf-tls-renegotiation

<Pasi.Eronen@nokia.com> Mon, 07 December 2009 12:33 UTC

Return-Path: <Pasi.Eronen@nokia.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 2FE463A680C for <tls@core3.amsl.com>; Mon, 7 Dec 2009 04:33:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.525
X-Spam-Level:
X-Spam-Status: No, score=-6.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 VH3ns1Nh9Vt6 for <tls@core3.amsl.com>; Mon, 7 Dec 2009 04:33:21 -0800 (PST)
Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 00E203A683D for <tls@ietf.org>; Mon, 7 Dec 2009 04:33:20 -0800 (PST)
Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id nB7CX3b2031128; Mon, 7 Dec 2009 14:33:08 +0200
Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Dec 2009 14:33:03 +0200
Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Dec 2009 14:33:03 +0200
Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Dec 2009 14:32:58 +0200
Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Mon, 7 Dec 2009 13:32:57 +0100
From: Pasi.Eronen@nokia.com
To: mrex@sap.com, tls@ietf.org
Date: Mon, 07 Dec 2009 13:32:56 +0100
Thread-Topic: [TLS] Next steps for draft-ietf-tls-renegotiation
Thread-Index: Acp06x81UTfrhZTWRI2oX6rBqAQ2hgCTRGSA
Message-ID: <808FD6E27AD4884E94820BC333B2DB774F31A4F4BA@NOK-EUMSG-01.mgdnok.nokia.com>
References: <808FD6E27AD4884E94820BC333B2DB774F3128928A@NOK-EUMSG-01.mgdnok.nokia.com> from "Pasi.Eronen@nokia.com" at Dec 4, 9 02:29:50 pm <200912041407.nB4E76dQ011303@fs4113.wdf.sap.corp>
In-Reply-To: <200912041407.nB4E76dQ011303@fs4113.wdf.sap.corp>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 07 Dec 2009 12:32:58.0769 (UTC) FILETIME=[68BF5010:01CA7739]
X-Nokia-AV: Clean
Subject: Re: [TLS] Next steps for draft-ietf-tls-renegotiation
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: Mon, 07 Dec 2009 12:33:22 -0000

Martin Rex wrote:
> Think about the following scenario:
> 
> Updated TLS client establishes session with _old_ server.  The old
> server requests renegotiation and were still early in the transition
> period, so the user really wants his client to allow that.
> 
> What should the TLS client send on the renegotiation ClientHello to
> that old server?  What if the client used an extension-less ClientHello
> for the initial handshake?  what if that old server is actually
> extensions-intolerant?
> 
> So: what should that client send on the renegotiation handshake with
> that server?  Does the answer differ based on which kind of old
> server that is?
> 
> The answer for my proposal is obvious, described in my document
> and fully interoperable with the entire installed base.
> 
> The answer for TLS extension RI is not in that document, non-obvious
> and will either be insecure or break interop for some scenarios.

I agree that the answer is not in the document, and it's non-obvious,
so something needs to be changed in the document.

Best regards,
Pasi

v2.23.0 | Report a Bug | By Email