[TLS] renegotiation draft needs clarification !!

Nelson B Bolyard <nelson@bolyard.me> Thu, 12 November 2009 01:27 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 32E5A3A6AC8 for <tls@core3.amsl.com>; Wed, 11 Nov 2009 17:27:02 -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 j9KFhSkF2yUh for <tls@core3.amsl.com>; Wed, 11 Nov 2009 17:27:01 -0800 (PST)
Received: from smtpauth13.prod.mesa1.secureserver.net (smtpauth13.prod.mesa1.secureserver.net [64.202.165.37]) by core3.amsl.com (Postfix) with SMTP id 566303A63C9 for <tls@ietf.org>; Wed, 11 Nov 2009 17:27:01 -0800 (PST)
Received: (qmail 6348 invoked from network); 12 Nov 2009 01:27:26 -0000
Received: from unknown (24.5.142.42) by smtpauth13.prod.mesa1.secureserver.net (64.202.165.37) with ESMTP; 12 Nov 2009 01:27:25 -0000
Message-ID: <4AFB64FA.1060505@bolyard.me>
Date: Wed, 11 Nov 2009 17:29:30 -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: Eric Rescorla <ekr@rtfm.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Cc: tls@ietf.org
Subject: [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 01:27:02 -0000

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.

/Nelson