IETF Logo Mail Archive

Re: [TLS] Quest for Unified Solution to TLS Renegotiation

Eric Rescorla <ekr@networkresonance.com> Wed, 25 November 2009 22:53 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 D7EA23A67AA for <tls@core3.amsl.com>; Wed, 25 Nov 2009 14:53:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.225
X-Spam-Level:
X-Spam-Status: No, score=0.225 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, 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 xmH5X04D7yfj for <tls@core3.amsl.com>; Wed, 25 Nov 2009 14:53:38 -0800 (PST)
Received: from kilo.networkresonance.com (74-95-2-169-SFBA.hfc.comcastbusiness.net [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id 079853A6B78 for <tls@ietf.org>; Wed, 25 Nov 2009 14:53:38 -0800 (PST)
Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 42FB96C3288; Wed, 25 Nov 2009 14:54:08 -0800 (PST)
Date: Wed, 25 Nov 2009 14:54:08 -0800
From: Eric Rescorla <ekr@networkresonance.com>
To: Michael D'Errico <mike-list@pobox.com>
In-Reply-To: <4B0D9B94.9080205@pobox.com>
References: <4B0D9B94.9080205@pobox.com>
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: <20091125225408.42FB96C3288@kilo.networkresonance.com>
Cc: TLS Working Group <tls@ietf.org>
Subject: Re: [TLS] Quest for Unified Solution to TLS Renegotiation
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: Wed, 25 Nov 2009 22:53:38 -0000

At Wed, 25 Nov 2009 13:03:16 -0800,
Michael D'Errico wrote:
> 
> I think that it would be good to find a unified solution that
> everybody is happy with, and believe that this may be it:

This was actually suggested by Bodo Moeller last week.


>    1) Client-to-Server signalling can be done in either of
>       two ways:
> 
>       A) an empty Secure_Renegotiation (SR) extension, or
>       B) a "magic" cipher suite
> 
>    2) Server-to-Client signal is always an empty SR extension

I just sent a message suggesting 1 and almost 2.



>    3) Incorporate previous verify_data into Finished calc.

I'm not happy with this, actually.

This requires breaking the current clean definition of handshake
hashes as the hash of all the handshake messages and simply adding
some synthetic message in the middle. I don't think this is anywhere
near as clean, as evidenced by the ongoing debate about whether to put
it the synthetic data in the front, the back, incorporate it into the
PRF, or chain the pre-existing handshake messages. [FWIW, I think I
prefer the last of these implicit versions.]

By contrast, RI allows that part of the system (which is well
understood) to remain the same and in fact when RI is offered on the
first handshake, there is no change to the TLS core at all. It's all
just hashed into Finished as part of the ordinary TLS procedures,
and everything is in fact compliant TLS, which I think is desirable.

I appreciate that this is to some extent a matter of tradeoffs,
but I don't find the arguments in favor of the implicit version
very compelling when weighed against the above.

-Ekr

v2.23.0 | Report a Bug | By Email