Re: [TLS] Fixing TLS

Peter Bowen <pzbowen@gmail.com> Tue, 12 January 2016 17:51 UTC

Return-Path: <pzbowen@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 7DB9D1A0167 for <tls@ietfa.amsl.com>; Tue, 12 Jan 2016 09:51:31 -0800 (PST)
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 ahrjzI8k1cEf for <tls@ietfa.amsl.com>; Tue, 12 Jan 2016 09:51:30 -0800 (PST)
Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C5101A0158 for <tls@ietf.org>; Tue, 12 Jan 2016 09:51:29 -0800 (PST)
Received: by mail-pf0-x22f.google.com with SMTP id n128so66259671pfn.3 for <tls@ietf.org>; Tue, 12 Jan 2016 09:51:29 -0800 (PST)
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=ku2T6n4XXs7Hf97fENqGdbtukG+0mOV4lQk2xmEBRl0=; b=Esu8Bq9C+DNaTq7rjgiOV4GSw9V7HtL/OH09x2lcBtCoNNGD/ZycrTNyaARXriC2FK ZCmZo+TMhR3mWAaasZEGSbEBLPSyGsO+XgR0K9EXQ6N29Ub3pFYHW+JkdMHuSu33jgkH DiezW2ReKpW9MhyoBjb5ag2pjGHCUaEz6SXBJYQ6GobPxcbhsgPZq6T5UTh53CAkzCDw N1GO1HyoYwRHZ5nXMW1dtdQrDOxuRsGzWojFPCMN/kpAkWHDQzzu/qgpjmgFPOHJssvI hbdJsmPX2JmpnVCpVZ6g+JYfi9qLO4pfn8GbP+mY6nshT8KMBrsl53rFurO7R//KpFVx ikvw==
MIME-Version: 1.0
X-Received: by 10.98.9.147 with SMTP id 19mr30766425pfj.163.1452621088852; Tue, 12 Jan 2016 09:51:28 -0800 (PST)
Received: by 10.66.142.193 with HTTP; Tue, 12 Jan 2016 09:51:28 -0800 (PST)
In-Reply-To: <CAK6vND9x-QOsvfA4bmz-GbbF8kEx8kv22mDPbCm=mEqXe_XvAg@mail.gmail.com>
References: <9A043F3CF02CD34C8E74AC1594475C73F4BC6849@uxcn10-5.UoA.auckland.ac.nz> <201601121202.26624.davemgarrett@gmail.com> <CAK6vND9x-QOsvfA4bmz-GbbF8kEx8kv22mDPbCm=mEqXe_XvAg@mail.gmail.com>
Date: Tue, 12 Jan 2016 09:51:28 -0800
Message-ID: <CAK6vND_SbHY_mY4VXH+C4E6d6k_6ChLT7trTfz3PfQytnN=Khg@mail.gmail.com>
From: Peter Bowen <pzbowen@gmail.com>
To: Dave Garrett <davemgarrett@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/IIQbevhKp2oafc6u-IaVcom7LrQ>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Fixing TLS
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: <https://mailarchive.ietf.org/arch/browse/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, 12 Jan 2016 17:51:31 -0000

On Tue, Jan 12, 2016 at 9:27 AM, Peter Bowen <pzbowen@gmail.com>; wrote:
> On Tue, Jan 12, 2016 at 9:02 AM, Dave Garrett <davemgarrett@gmail.com>; wrote:
>> On Tuesday, January 12, 2016 09:03:53 am Peter Gutmann wrote:
>>> Martin's comment reminded me of the following that I've been meaning to
>>> post...
>>>
>>> In a recent discussion among some crypto folks, the topic of what TLS 1.3
>>> could be came up.  Now by TLS 1.3 I mean TLS 1.3 as a simple upgrade path from
>>> TLS 1.2, not the TLS 2.0-called-TLS 1.3 that it currently is.  The discussion
>>> centered around the fact that we already have lots of analysis done for TLS
>>> 1.x, and it's not too hard to create a TLS 1.3 that fixes the TLS < 1.3
>>> problems while being as compatible as possible with existing infrastructure.
>>> So what this would do is take existing security analysis applied to TLS,
>> [...]
>>
>> Welcome to the TLS 1.2.1 proposal club. Unfortunately, we don't have snacks.
>>
>> I'll be the bearer of bad news and tell you that your proposal has come up in multiple forms. I suggested a similar thing a while back and far before me others have as well. The chairs have, however, long declared consensus that we want to focus on a single new version not leaving out other more complex changes, namely latency improvements.
>
> Rather than talking about this as TLS 1.2.1 (or 1.3), is the smarter
> way to go to document a profile of TLS 1.2 that covers almost all of
> this.  From a quick read, existing RFCs and I-Ds cover most of this:
> - RFC 5246 (TLS 1.2 & TLS_DHE_RSA_WITH_AES_128_CBC_SHA256)
> - RFC 5487 (TLS_DHE_PSK_WITH_AES_128_CBC_SHA256)
> - RFC 5289 (TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256)
> - RFC 7366 (EtM)
> - RFC 7627 (extended master secret)
> - RF 4055 (RSA-PSS)
>
> The gaps seem to be:
> - No TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 cipher suite allocated
> (BoringSSL has an implementation using cipher suite 0xca,0xfe)

Correction: draft-mattsson-tls-ecdhe-psk-aead-03 defines this suite.
Still no cipher suite allocated, but there is an active draft.

> - DH parameters -- the alternative would be using FFDH named groups
> (draft-ietf-tls-negotiated-ff-dhe-10), right?
>
> This would only leave "Get rid of the IPsec cargo-cult MAC truncation", right?
>
> Thanks,
> Peter