Re: [TLS] renegotiation draft needs clarification !!

Eric Rescorla <ekr@networkresonance.com> Thu, 12 November 2009 06:15 UTC

Return-Path: <ekr@networkresonance.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 C40563A6A4D for <tls@core3.amsl.com>; Wed, 11 Nov 2009 22:15:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.012
X-Spam-Level:
X-Spam-Status: No, score=0.012 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1]
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 SvUMUBeu6ulF for <tls@core3.amsl.com>; Wed, 11 Nov 2009 22:15:18 -0800 (PST)
Received: from genesis-hsia.quadriga-www.com (2.26.235.80.sta.estpak.ee [80.235.26.2]) by core3.amsl.com (Postfix) with ESMTP id 3A7663A67A3 for <tls@ietf.org>; Wed, 11 Nov 2009 22:15:15 -0800 (PST)
Received: from [192.168.12.187] (helo=kilo.networkresonance.com) by genesis-hsia.quadriga-www.com with esmtp (Exim 3.34 #1) id 1N8Sy5-0002nz-00 for tls@ietf.org; Thu, 12 Nov 2009 08:15:41 +0200
Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id DFC7169EF22; Thu, 12 Nov 2009 08:16:36 +0200 (EET)
Date: Thu, 12 Nov 2009 08:16:36 +0200
From: Eric Rescorla <ekr@networkresonance.com>
To: Nelson B Bolyard <nelson@bolyard.me>
In-Reply-To: <4AFB728C.9050102@bolyard.me>
References: <4AFB64FA.1060505@bolyard.me> <e8c553a60911111748m44921264s44cfc8fcc34c21fd@mail.gmail.com> <4AFB728C.9050102@bolyard.me>
User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Message-Id: <20091112061636.DFC7169EF22@kilo.networkresonance.com>
Cc: tls@ietf.org
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 06:15:29 -0000

At Wed, 11 Nov 2009 18:27:24 -0800,
Nelson B Bolyard wrote:
> 
> 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.

I agree. I'll put it on my TODO list to fix this.

IMHO, the better interpretation is an empty vector (i.e. 00) for
the data field with an extension containing only that. I.e.

ff 01 00 01 00

-Ekr