IETF Logo Mail Archive

Re: [TLS] tls 1.3: renegotiation

Martin Thomson <martin.thomson@gmail.com> Mon, 28 July 2014 23:20 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 [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 311C41A038D for <tls@ietfa.amsl.com>; Mon, 28 Jul 2014 16:20:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JkEh8Qy60BJC for <tls@ietfa.amsl.com>; Mon, 28 Jul 2014 16:20:16 -0700 (PDT)
Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C69681A0386 for <tls@ietf.org>; Mon, 28 Jul 2014 16:20:15 -0700 (PDT)
Received: by mail-wi0-f178.google.com with SMTP id hi2so90543wib.5 for <tls@ietf.org>; Mon, 28 Jul 2014 16:20:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=wBq9glM3L51EMaDcQfkRQsgATVpSvAs2jDz7XTJJFwA=; b=SsRF2MnUxuvBv3vq6kzeqxtt+ZzdhpGKIpPG0u5tj3wSRJp37gBCqJq/tY1O6m2S2+ GxRw6taJcsmuZAqML5k5fozYU+1dqfjkpr5YAKpBi0tR+Zr9WZTB+lAa6eF2EyDcb8w3 LtfZjgViR0Uf6yi+gh6v1TedUbYkt2SCm3aKylByXF2lUEHrXRRqTSrNSOiqxA5q1z5W syZaXdKvuWc4oxJSVzT+UOjC67pKClqQ/tg42fZAJ2nXGW2h4mYHhy5feW/w2mX2nLes 9yhp9ySotUw7SaWzAG4GeN25aLspcpS2k1wk1QqZGs1F4bWKk0n5l/G1DFer3t4Y6LnZ TEXA==
MIME-Version: 1.0
X-Received: by 10.180.103.74 with SMTP id fu10mr443930wib.47.1406589614412; Mon, 28 Jul 2014 16:20:14 -0700 (PDT)
Received: by 10.194.110.6 with HTTP; Mon, 28 Jul 2014 16:20:14 -0700 (PDT)
In-Reply-To: <CABqy+spuvWmrxgznzA2dZB-4PD0QffdtaGihD-D6CNTM2ruH5g@mail.gmail.com>
References: <7C3D5CF9-2B17-4953-A13D-C5E7226D13E7@ieca.com> <CABqy+so=yV9Gp8aCp3cJ8wQRmd6JC-J9raEzgw1c1UDdFT2=JQ@mail.gmail.com> <CABkgnnX4zU8kxKK=4HTyFyX-uxpujEkNcXfcDmt0CHwfF+q-BA@mail.gmail.com> <CABqy+spuvWmrxgznzA2dZB-4PD0QffdtaGihD-D6CNTM2ruH5g@mail.gmail.com>
Date: Mon, 28 Jul 2014 16:20:14 -0700
Message-ID: <CABkgnnWrwqKFfxSbbv95wK1hveTFzKwO7wUJnGJ4usvrFmuN7g@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Robert Ransom <rransom.8774@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/PPmbwBAX1s-gXl0kLV5_E8kNofE
Cc: "TLS@ietf.org (tls@ietf.org)" <tls@ietf.org>
Subject: Re: [TLS] tls 1.3: 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: Mon, 28 Jul 2014 23:20:17 -0000

On 28 July 2014 15:03, Robert Ransom <rransom.8774@gmail.com> wrote:
> So you don't even have a consensus on what “rekeying” will mean.

That's step 2.  Do you think that this has a material impact on the
outcome of this call?  (I'm guessing not.)

> I gave a list of four use cases that can be (and are currently)
> addressed by renegotiation a while back.

I can't find these.

> Renegotiation is a particularly elegant solution to several problems.
> It requires little extra code beyond what is already used to perform
> the initial handshake, and adding a (correctly designed) channel
> binding as input to the renegotiation process will add the security
> properties that some API and application developers had previously
> expected renegotiation to provide.

It might be conceptually elegant, but it's certainly not free.  Even
within NSS, the number of "if we are renegotiating" branches is pretty
large.

And fixing NSS is relatively easy.  It's the externalities
renegotiation creates that are the larger problem.  Because API and
application developers don't look for particular properties, the
problem is with the assumptions, once of which is generally
immutability of various properties.

v2.23.0 | Report a Bug | By Email