Re: [TLS] tls 1.3: renegotiation

Robert Ransom <rransom.8774@gmail.com> Mon, 28 July 2014 22:03 UTC

Return-Path: <rransom.8774@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 F2EFB1A008E for <tls@ietfa.amsl.com>; Mon, 28 Jul 2014 15:03:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.75
X-Spam-Level:
X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
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 JkQFUjzkCm_t for <tls@ietfa.amsl.com>; Mon, 28 Jul 2014 15:03:42 -0700 (PDT)
Received: from mail-qa0-x22e.google.com (mail-qa0-x22e.google.com [IPv6:2607:f8b0:400d:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 483941A0080 for <tls@ietf.org>; Mon, 28 Jul 2014 15:03:42 -0700 (PDT)
Received: by mail-qa0-f46.google.com with SMTP id v10so8588138qac.33 for <tls@ietf.org>; Mon, 28 Jul 2014 15:03:36 -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=t/8RFc8mEyg+a6pJaoWEkENHp80aNLhSJUf1LrwTJeE=; b=El/CwRXqEzRu7qvvuHOwQdJTRGjKuK7HD4H46KXde64ahwj2Pm5qf3Lk+IQTYaCCRc fKv2xhcgajAJTlZtiYfUKhs4FSKdt0AutnVXo4XJJLKbqKUpVGMDyurUFjQyW3MTdfP/ iL42A/aS6u6kh2qntB93dPowGSTHxExwn97lEu8JadLN/xFCxOK0q/d10Jd+CHQgzKeI AmUQQ7hChiBWNQnL9djfuASX+UttK5Z9p3fMNcg0IZCcY7Wh9FtYO5lDIJt7JRXagxGy yYY+PkZbvApAtGKDMl2YHna2vlLxyp22kGMekTYjMgJd+oWiy4fsEjATiGZlKz91TeDQ c6yg==
MIME-Version: 1.0
X-Received: by 10.224.135.2 with SMTP id l2mr64460177qat.37.1406585016854; Mon, 28 Jul 2014 15:03:36 -0700 (PDT)
Received: by 10.140.86.135 with HTTP; Mon, 28 Jul 2014 15:03:36 -0700 (PDT)
In-Reply-To: <CABkgnnX4zU8kxKK=4HTyFyX-uxpujEkNcXfcDmt0CHwfF+q-BA@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>
Date: Mon, 28 Jul 2014 15:03:36 -0700
Message-ID: <CABqy+spuvWmrxgznzA2dZB-4PD0QffdtaGihD-D6CNTM2ruH5g@mail.gmail.com>
From: Robert Ransom <rransom.8774@gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/NcQ3hjAyI3Qog0YoZyqDraT_Q5s
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 22:03:44 -0000

On 7/28/14, Martin Thomson <martin.thomson@gmail.com> wrote:
> On 25 July 2014 12:27, Robert Ransom <rransom.8774@gmail.com> wrote:
>> In addition, I believe that it is not possible for the WG to make an
>> informed decision as to whether renegotiation should be removed at
>> this time:
>>
>> * The rekeying feature and client-initiated client authentication
>>   feature have not been specified yet, even to the point of stating
>>   the requirements which each feature will meet.  It is not possible
>>   for the WG to determine whether the features intended to replace
>>   these two uses of renegotiation will be fit for their intended
>>   purposes at this time.
>
> We had a good discussion about these in Toronto.  On rekeying, there
> are concerns about how much we might want to make changeable; offline
> discussions about the complexity/value trade-off space between simple
> rekeying (as I have proposed) and something more complete like a full
> DH exchange was quite enlightening.

I see.  So you don't even have a consensus on what “rekeying” will mean.


> We've talked quite a bit about spontaneous client authentication
> (though we might talk about client-initiated authentication, that
> implies a solution and so I think that is the wrong focus for the
> discussion).
>
> The problem as always is that the defense of renegotiation is largely
> based on its existence alone.  That defense would be stronger if there
> it were based on use cases.  I don't find arguments from inertia ("it
> exists", or "it's easy") to be at all persuasive.  Saying "it can be
> fixed" is actively detrimental to the case.
>
> Arguments in the form "I need to do X and in order to do X I need
> renegotiation" are far better.  They are testable.  Andrei's concerns
> are a good example of this.  We might disagree on the subjective
> elements, but that's a good starting point.

I gave a list of four use cases that can be (and are currently)
addressed by renegotiation a while back.  The responses can be summed
up as “But we can add a separate ad-hoc feature to address each of
those use cases!”.  I agree that each use of renegotiation can be
replaced with a new protocol feature, which will require new protocol
design effort, new implementation code, new testing, new API design
effort, new application code, and new risk of introducing security
bugs at each of those steps.  I do not agree with your argument that
such a replacement is desirable for every use of renegotiation -- or
for *any* use of renegotiation at all.

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.

I don't find arguments based on the prospect that new features might
be added to TLS to be at all persuasive.  Saying
“TLS-without-renegotiation can be fixed to support long-lived
connections if we decide to add some sort of rekeying mechanism.” or
“We added a Heartbeat record type; now let's add a ClientAuthenticate
record type too!” are actively detrimental to the case.


Robert Ransom