Re: [TLS] renegotiation draft needs clarification !!
Nelson B Bolyard <nelson@bolyard.me> Thu, 12 November 2009 02:24 UTC
Return-Path: <nelson@bolyard.me>
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 E31E03A67F2 for <tls@core3.amsl.com>; Wed, 11 Nov 2009 18:24:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 U4bbrloS+p8N for <tls@core3.amsl.com>; Wed, 11 Nov 2009 18:24:50 -0800 (PST)
Received: from smtpauth23.prod.mesa1.secureserver.net (smtpauth23.prod.mesa1.secureserver.net [64.202.165.47]) by core3.amsl.com (Postfix) with SMTP id 22D973A6828 for <tls@ietf.org>; Wed, 11 Nov 2009 18:24:50 -0800 (PST)
Received: (qmail 11514 invoked from network); 12 Nov 2009 02:25:18 -0000
Received: from unknown (24.5.142.42) by smtpauth23.prod.mesa1.secureserver.net (64.202.165.47) with ESMTP; 12 Nov 2009 02:25:18 -0000
Message-ID: <4AFB728C.9050102@bolyard.me>
Date: Wed, 11 Nov 2009 18:27:24 -0800
From: Nelson B Bolyard <nelson@bolyard.me>
Organization: Network Security Services
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.9.1b1pre) Gecko/20081004 NOT Firefox/2.0 SeaMonkey/2.0a2pre
MIME-Version: 1.0
To: tls@ietf.org
References: <4AFB64FA.1060505@bolyard.me> <e8c553a60911111748m44921264s44cfc8fcc34c21fd@mail.gmail.com>
In-Reply-To: <e8c553a60911111748m44921264s44cfc8fcc34c21fd@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Subject: Re: [TLS] renegotiation draft needs clarification !!
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, 12 Nov 2009 02:24:51 -0000
On 2009-11-11 17:48 PDT, Wan-Teh Chang wrote: > On Wed, Nov 11, 2009 at 5:29 PM, Nelson B Bolyard <nelson@bolyard.me> wrote: >> At least Two implementers have read the draft differently and implemented >> non-interoperable implementations. The draft needs clarification. >> >> First the draft says: >> >> The "extension data" field of this extension contains a >> "Renegotiation_Info" structure: >> >> struct { >> opaque renegotiated_connection<0..255>; >> } Renegotiation_Info; >> >> Then it says: >> >> The contents of this extension are specified as follows. >> >> o If this is the initial handshake for a connection, then this field >> is of zero length in both the ClientHello and the ServerHello. >> >> One implementer interprets this to mean that the extension data field >> is of zero length. Another interprets it to mean that the >> "renegotiated_connection" field inside the Renegotiation_Info is to >> have zero length. This leads to two different encodings, which are: >> >> FF 01 00 00 >> >> FF 01 00 01 00 >> >> I suggest replacing "the contents of this extension" with either >> "The contents of the renegotiated_connection", or >> "the contents of the extension data field", to make this sufficiently >> explicit. > > This kind of ambiguity was also in the original RFC 4507 for > the TLS session ticket extension, and had to be addressed in > a new RFC 5077. See RFC 5077 section 1 and appendix A. Thanks for the tip, Wan-Teh. So, summarizing that appendix, it says that clients have two different interpretations of an empty session ticket extension, so servers should accept either one and should return an empty extension in the same format as that sent by the client. Fellow TLS WG members, Let's not repeat that for this extension. This extension hasn't been published in an RFC yet, so let's nip this in the bud, and make it completely unambiguous before that happens. /Nelson
- [TLS] renegotiation draft needs clarification !! Nelson B Bolyard
- Re: [TLS] renegotiation draft needs clarification… Wan-Teh Chang
- Re: [TLS] renegotiation draft needs clarification… Nelson B Bolyard
- Re: [TLS] renegotiation draft needs clarification… Michael D'Errico
- Re: [TLS] renegotiation draft needs clarification… David-Sarah Hopwood
- Re: [TLS] renegotiation draft needs clarification… Michael D'Errico
- Re: [TLS] renegotiation draft needs clarification… Eric Rescorla
- Re: [TLS] renegotiation draft needs clarification… Nasko Oskov
- Re: [TLS] renegotiation draft needs clarification… Michael Gray