Re: [TLS] Call for Consensus on removal of renegotiation

Martin Thomson <martin.thomson@gmail.com> Fri, 27 June 2014 16:30 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 6AE361B2B3C for <tls@ietfa.amsl.com>; Fri, 27 Jun 2014 09:30:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Level:
X-Spam-Status: No, score=-1.4 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, J_CHICKENPOX_38=0.6, 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 D6hICGpkgZtP for <tls@ietfa.amsl.com>; Fri, 27 Jun 2014 09:30:46 -0700 (PDT)
Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EBD21B2960 for <tls@ietf.org>; Fri, 27 Jun 2014 09:30:45 -0700 (PDT)
Received: by mail-wi0-f177.google.com with SMTP id r20so3125740wiv.10 for <tls@ietf.org>; Fri, 27 Jun 2014 09:30:44 -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; bh=ZUu1AziC2RLDi5snMjjb3irYmc/NneCMh9xDQgx0+1U=; b=lVGbX5ruHaPMTsvzA1AkjDjGFciRmohvGBuexulfx9HBprhUPr1ZVYsjvmRBjEt4Qq IzH0oh2PyAjcUIbCqm6lgi7qe3GgP2fgjegVJJTicZBsn+4NcUpXR9IitNBFjHQku3fj Eq7fIIGtwlPr8Z9y7JO2HjFs0Z8FHAUd1NMQU70ZcibGeGk0RCF38ql7DMMZq+pc8Be9 zVJv2RZk3UzumIX3G8ndMMtrvXT+5RXWLHSpkJAu56/QO0P0eLfBt/F2RUbPDSJp9NrE phdHVKVYM4fzvWwE/czLNeNVkS+gie5JBYIB1WsttB5C3ooR+MXYe9V3uR6u7Lvvfb7y Umow==
MIME-Version: 1.0
X-Received: by 10.194.238.6 with SMTP id vg6mr24356295wjc.24.1403886644190; Fri, 27 Jun 2014 09:30:44 -0700 (PDT)
Received: by 10.194.51.134 with HTTP; Fri, 27 Jun 2014 09:30:44 -0700 (PDT)
In-Reply-To: <m3k3825tk3.fsf@carbon.jhcloos.org>
References: <44DA5A30-015D-40F3-90CA-F15076891BBC@cisco.com> <53AB192F.2040001@fifthhorseman.net> <CAAF6GDdkkuB=Eko55vqaPS9Krc0XmiQk0vo2c_q5n6kydpkYuQ@mail.gmail.com> <B18B3440-8CBF-4B04-B792-F81FBF0CE8AC@gmail.com> <CAAF6GDdsHo1178Hfs8RzERLPDni9SMHB6+nPg0aWBSkxFv_53w@mail.gmail.com> <A19581EC-A67A-4CEC-83D1-542F09429A93@gmail.com> <CAAF6GDdk26=CDLsjwhkOKWewWwGgTGZpX1mh6=pDN_DycU7w4Q@mail.gmail.com> <m3k3825tk3.fsf@carbon.jhcloos.org>
Date: Fri, 27 Jun 2014 09:30:44 -0700
Message-ID: <CABkgnnVAW5boy3o2Wgqs6HtMEA+B6BRw1cK4v+p1jpKmFGNspQ@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: James Cloos <cloos@jhcloos.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/P3b4FCFfF3caCy0PLZKJV437pw4
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Call for Consensus on removal of 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: Fri, 27 Jun 2014 16:30:47 -0000

On 27 June 2014 07:13, James Cloos <cloos@jhcloos.com> wrote:
> If tls1.3 drops rekeying established sockets, then one reasonably can
> predict that its adoption will be limited enough that any security
> benefits it has over 1.2 will be, mostly, for naught.
>
> Whether rekeying requires renegotiation should be the question.

We're all running the same sort of questions over.

I've been looking at TCP crypt and their informal requirements
document says this:


           [...]  Use of a single key over a long connection is a
           known security problem, so it would be preferable to either
           limit the length of a connection or require in-band keying
           support.

           Unfortunately, not all applications are easy to restart.
           BGP, for which this option is intended, is being augmented
           for graceful restart [RFC4724] [RFC4781], but this extension
           is under recent scrutiny.  TCP itself has no limit on the
           length of a connection, and it would be preferable to avoid
           modifying this semantic.

I think that this last sentence answered the rekeying question for me.
TLS is considered widely as TCP+security (as much as that abstraction
occasionally leaks, c.f., packet length).