Re: [TLS] TLS renegotiation issue

Bodo Moeller <bmoeller@acm.org> Thu, 12 November 2009 06:15 UTC

Return-Path: <bmoeller@acm.org>
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 C899128C139 for <tls@core3.amsl.com>; Wed, 11 Nov 2009 22:15:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.249
X-Spam-Level:
X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100]
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 Jpmh49gsJh3u for <tls@core3.amsl.com>; Wed, 11 Nov 2009 22:15:29 -0800 (PST)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by core3.amsl.com (Postfix) with ESMTP id 4CA7B3A6A20 for <tls@ietf.org>; Wed, 11 Nov 2009 22:15:21 -0800 (PST)
Received: from [172.19.233.94] ([216.239.45.130]) by mrelayeu.kundenserver.de (node=mreu1) with ESMTP (Nemesis) id 0MHci0-1N7MVG2Z2K-003mwq; Thu, 12 Nov 2009 07:15:44 +0100
From: Bodo Moeller <bmoeller@acm.org>
To: Eric Rescorla <ekr@rtfm.com>
In-Reply-To: <d3aa5d00911051016p7a0cc508q2090b86de30a50d5@mail.gmail.com>
References: <73843DF9-EFCB-4B8D-913E-FE2235E5BDD3@rtfm.com> <d3aa5d00911051016p7a0cc508q2090b86de30a50d5@mail.gmail.com>
Message-Id: <FE388C21-9AF4-4FCF-81DA-6E30B04722B6@acm.org>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Wed, 11 Nov 2009 22:15:39 -0800
X-Mailer: Apple Mail (2.936)
X-Provags-ID: V01U2FsdGVkX18y8pmtzVTHhK/ICZ7NTljYBTpcfG0fg/8OObB rOal2H4TN9Tfi7hs4TqTervqPACo4VughXcvMj+m7vy7jNrvLf zPq97KDaebZiYBctWTl1w==
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] TLS renegotiation issue
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:54 -0000

On Nov 5, 2009, at 10:16 AM, Eric Rescorla wrote:

> I now have a draft extension up at:
>
> https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-renegotiate.txt
> https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-renegotiate.xml

[= http://www.ietf.org/id/draft-rescorla-tls-renegotiation-00.txt]


There's pointless overhead in the following extract: Sending the  
client's verify_data to the server for verification makes sense;  
sending the server's verify_data to the client for verification makes  
less sense, but still sense; sending another copy of the client's  
verify_data to the client, however, doesn't make sense.  Using  
symmetric 12-byte values, where each party sends its own previous  
verify_data, achieves the same with fewer bytes.

Bodo


             struct {
                opaque renegotiated_connection<0..255>;
              } Renegotiation_Info;

    All TLS implementations SHOULD support this extension.  TLS clients
    SHOULD generate it with every handshake and TLS servers SHOULD
    generate it in response to any client which offers it.

    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.
    o  For ClientHellos which are renegotiating, this field contains the
       verify_data from the Finished message sent by the client on the
       immediately previous handshake.  For current versions of TLS,  
this
       will be a 12-byte value.  Note that this value is the "tls- 
unique"
       channel binding from [I-D.altman-tls-channel-bindings]
    o  For ServerHellos which are renegotiating, this field contains the
       concatenation of the verify_data values sent by the client and  
the
       server (in that order) on the immediately previous handshake.   
For
       current versions of TLS, this will be a 24-byte value.