Re: [TLS] Proposed text for removing renegotiation

mrex@sap.com (Martin Rex) Wed, 28 May 2014 00:44 UTC

Return-Path: <mrex@sap.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C12371A0834 for <tls@ietfa.amsl.com>; Tue, 27 May 2014 17:44:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.552
X-Spam-Level:
X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fhv6Pv2zpcqU for <tls@ietfa.amsl.com>; Tue, 27 May 2014 17:44:15 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 463BB1A0827 for <tls@ietf.org>; Tue, 27 May 2014 17:44:15 -0700 (PDT)
Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id s4S0i8kf014131 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 28 May 2014 02:44:09 +0200 (MEST)
In-Reply-To: <CABkgnnXaLKmxXL01hQEdxHSNGt3nZQQNBLDD5H2LqBzTo3vK4g@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Date: Wed, 28 May 2014 02:44:08 +0200
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20140528004408.D184F1AD1D@ld9781.wdf.sap.corp>
From: mrex@sap.com
X-SAP: out
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Vly_BIJsX-MOIdJrJzNvmj7-Maw
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Proposed text for removing renegotiation
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: mrex@sap.com
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/options/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, 28 May 2014 00:44:21 -0000

Martin Thomson wrote:
> 
> Here I'm proposing changes that remove renegotiation.
>
> It's not possible to just remove renegotiation.
> After removing HelloRequest and no_renegotiation, there are some
> things that need to be fixed.  The current and pending states for
> both read and write direction are integral parts of the spec.

I haven't looked at the details, but this sound terrible.

The beauty of the original TLS renegotiation is that it doesn't
really exist.  For the state machine, it is a regular full TLS
handshake, for the record layer, it is just a replacement of
the current state with the next state upon CCS.

The only problem with TLS renogitation, if there ever was one,
is with the flawed assumptions of the application about what
characteristics it provides (i.e that another successful TLS
handshake could be abused to provide an OTP-style authentication
of all data previously received over that TLS channel.


Renegotiation could be combined with an abbreviated TLS handshake
to provide fast rekeying of the traffic protection keys (not creating
a new entry in the TLS session cache), and renegotiation could be
combined with a full TLS handshake, creating a new, self-contained
entry in the TLS session cache that can be resumed on different
connections with an abbreviated TLS handshake.


Conceptually, the TLS session cache is readonly after an entry
is created, and that is GOOD, i.e. full TLS handshakes create new,
distict session cache entries, and abbreviated TLS handshakes resume
existing session cache entries and *NEVER* modify them.


The original architecture allows for a very simple and robust
TLS protocol state machine for the TLS handshake (allows!=implies,
you can implement arbitrarily complicated TLS state machines if you
so desire, just look at some of the OpenSource implementations).



> 
> The proposal generates a new master secret from the previous using the
> same formula that is used to generate the master from the pre-master
> secret.  Obviously, if we change that formula (and it seems likely
> that we will) then this should be changed too.

It sounds like quite a lot more stuff will have to be carried over
from the previous session state to the next.  Now what does this mean
for the abbreviated TLS handshake?  When, where and how do you issue
a new session ID, or how does this change affect abbreviated
TLS handshakes happening on independent parallel connections? 


-Martin