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

Watson Ladd <watsonbladd@gmail.com> Sat, 28 June 2014 05:33 UTC

Return-Path: <watsonbladd@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 0622B1A02B2 for <tls@ietfa.amsl.com>; Fri, 27 Jun 2014 22:33:37 -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 IQ-a3CNGCt2C for <tls@ietfa.amsl.com>; Fri, 27 Jun 2014 22:33:35 -0700 (PDT)
Received: from mail-yk0-x234.google.com (mail-yk0-x234.google.com [IPv6:2607:f8b0:4002:c07::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47AD11A02B0 for <tls@ietf.org>; Fri, 27 Jun 2014 22:33:35 -0700 (PDT)
Received: by mail-yk0-f180.google.com with SMTP id 131so3447664ykp.11 for <tls@ietf.org>; Fri, 27 Jun 2014 22:33:34 -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=UHlXAgXq67r7RDXpFWUXBm5yeYhPJxw3k7X3jECFo9w=; b=vzf4DLbt8mA2kjZgUkbb3uC8CxuS/Tuz+22jhWQJAohzERvIH6ITQ110gQnaU4dTbO A4PK2IVbveWNfvFJ4oCCS2uLzm+u30Vx1q+uqGVdaVd77WT3cTKyMXRKhwIZrSQKsbHB mkOwtehNTu8EaJZHZJUt/FHYcYXtQFIi8irLgy6m8p4xOfSbsy1uxXVst2tKnvehua5q zyOVSOieBp7kskCoFfofFleMDUBHdZulDAhYrM/i6ndGmlsteQd1qtweLZQzksJOBi6j zgZTt6VG88RwJCRsXycB7kCt6nVPgU8n6BnBpeRmtaQADlnDtuGX38kTGBAFD/7kLF8U DFRA==
MIME-Version: 1.0
X-Received: by 10.236.81.243 with SMTP id m79mr37963267yhe.36.1403933614605; Fri, 27 Jun 2014 22:33:34 -0700 (PDT)
Received: by 10.170.39.136 with HTTP; Fri, 27 Jun 2014 22:33:34 -0700 (PDT)
In-Reply-To: <20140628050924.86D2F1AD6F@ld9781.wdf.sap.corp>
References: <9A043F3CF02CD34C8E74AC1594475C738DED010B@uxcn10-tdc06.UoA.auckland.ac.nz> <20140628050924.86D2F1AD6F@ld9781.wdf.sap.corp>
Date: Fri, 27 Jun 2014 22:33:34 -0700
Message-ID: <CACsn0c=G0vqOSuxm-8xakUgcDn2UAvXVz5De0R-EqS-VKuYH+w@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: "mrex@sap.com" <mrex@sap.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/s16MAK8AGPcxaDfDrK0GfMotaw0
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: Sat, 28 Jun 2014 05:33:37 -0000

On Fri, Jun 27, 2014 at 10:09 PM, Martin Rex <mrex@sap.com> wrote:
> Peter Gutmann wrote:
>> James Cloos <cloos@jhcloos.com> writes:
>>>
>>>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.
>
> I think that TLSv1.3 will be largely ignored for many other reasons
> (except maybe by a few (heart)bleeding edge implementations that spend
>  their scarce resources to implement every TLS kitchen sink rather than
>  for quality of the stuff that is important).

Hard to say: removing one round trip doesn't need to be especially
complicated: False Start demonstrated that.

For the web this latency really matters, so browsers are very
motivated to support TLS 1.3

Of course, only four implementations matter: one for the server, the
one in Chrome,
the one in Mozilla, and the one in Microsoft Windows.

>
>
>>
>> That's pretty speculative.  My speculation is instead:
>>
>>   If tls1.3 drops rekeying established sockets, then one reasonably can
>>   predict that people won't rekey established sockets any more.
>>
>> I'd say that's far more likely.
>
> For the purpose of rekeying, I still think that renegotiation is
> a pretty good solution.

Only if we tolerate the delays it introduces, and mandate significant
restrictions on what can change.
Interestingly some browsers seem to have already done this to fix
Triple Handshake.

>
>
> Bottom line:  if renegotiation is dropped from TLSv1.3, then long-lived
> connections with either not rekey, i.e. kiss forward secrecy good-bye,
> or long-lived connections will kiss TLSv1.3 good-bye.
>
> The latter of these two options is less work and immediately available...

Why are these the two options? TLS 1.3 could provide a transparent
rekeying option, that unlike renegotiation
doesn't require excessive round trips.

Sincerely,
Watson Ladd

>
>
>
> -Martin
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls



-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin