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