[TLS] Proposed text for removing renegotiation

Martin Thomson <martin.thomson@gmail.com> Tue, 27 May 2014 21:39 UTC

Return-Path: <martin.thomson@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id CD1321A027D for <tls@ietfa.amsl.com>; Tue, 27 May 2014 14:39:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id xOGnfcdYZGxO for <tls@ietfa.amsl.com>; Tue, 27 May 2014 14:39:34 -0700 (PDT)
Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CC751A027A for <tls@ietf.org>; Tue, 27 May 2014 14:39:34 -0700 (PDT)
Received: by mail-we0-f169.google.com with SMTP id u56so10422355wes.0 for <tls@ietf.org>; Tue, 27 May 2014 14:39:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=cwnz0t2EeUk646jwXpl1ZTFF1E54FUzv+CvgPwVwrs0=; b=Y3DViQ+WAdsORioFegO+B/pd2iIQqY3AWGd+w9tTGja7X8OAguP3ao2TkZiQMRM1Kn eiWnGOgFrD+QuYQjux9y21m/cp3DRbLatGL2XX4hBNs53Af9PDKNBt4a0QWy+vo2TkI2 mySP1HEJRt4tXifLNEwd1yAMa8BCzUnXvQaQvMBgoaAaQ4wSbQHX6CSxdif6A6wWFCP8 wPz2jHAR0dZ4VSBPOFBZYeq1LqQlzI0j/GPgdOgZZpTPEs6KEYNHu6IpyrEbdhQGXPdr w5Rkohe5wdAt2VguqXLGviDSvGPVarxOZAorrFHJgJd7Y9ubNTSOXxZoMEOuUUNRc9as T00Q==
MIME-Version: 1.0
X-Received: by with SMTP id v8mr44981735wja.53.1401226769687; Tue, 27 May 2014 14:39:29 -0700 (PDT)
Received: by with HTTP; Tue, 27 May 2014 14:39:29 -0700 (PDT)
Date: Tue, 27 May 2014 14:39:29 -0700
Message-ID: <CABkgnnXaLKmxXL01hQEdxHSNGt3nZQQNBLDD5H2LqBzTo3vK4g@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/O3SxjrBc_PJD2GWOhwFgIuMQn4k
Subject: [TLS] Proposed text for removing renegotiation
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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/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: Tue, 27 May 2014 21:39:36 -0000

I was incapable of doing much real work on a plane last week, so I did this:


Here I'm proposing changes that remove renegotiation.  There are some
pieces that are probably separable, and other pieces that might be
controversial, so I'll try to highlight those and then we can discuss
the merits of various approaches.  You know, the regular process.

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've proposed a simple mechanism for key refresh.  Basically, either
side sends a ChangeCipherSpec, which triggers the creation of a new
master secret for that direction.  Since CCS was otherwise unused
after removing renegotiation, it can be used to explicitly
indicate/request key refresh.

The proposal mandates a reciprocal CCS to keep the master secret
approximately in sync.  That is, if you receive a CCS, and you haven't
already sent a matching CCS, then you are required to send one.  This
means that an old master secret can be discarded in a bounded amount
of time.

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.

This overloads ChangeCipherSpec, which some might find distasteful,
but I think that it is consistent with it's current use and purpose.

Does this sound like a reasonable approach?