Re: [TLS] Fixing TLS

Watson Ladd <> Tue, 12 January 2016 17:29 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E471C1A00FD for <>; Tue, 12 Jan 2016 09:29:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Ausx0hpcbxua for <>; Tue, 12 Jan 2016 09:29:17 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4002:c07::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D16571A00FF for <>; Tue, 12 Jan 2016 09:29:16 -0800 (PST)
Received: by with SMTP id x67so460047917ykd.2 for <>; Tue, 12 Jan 2016 09:29:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=e/qjhHCm5sfv6S/eYBe0JcjgJC4zWjfT8C960oOquLU=; b=sHEfekkNF+6Qc4RZBMEsCKnVwsrmi7ybqIPlSTkRYXjdSRztAJZVVI6fXbOtkCQ7lN clakYkjv+3g2jfy+3Oj6D2KQPhUBlTyz+ZP97hTgVhbEH4fBGcYn2fIcOd6Cclc3v6LJ qQO5aXaj+X+VgDsTeWNRQqXz7mJcrarA3rw4/CM3CE390NpcneEYGKmFPl+/5wFpQAJF o4suxsvV7lTQM9ZuFrQI1wnmyJ7u/WfSULVBKZBoKeV3S2dWMZkir9LtJNr9Ac3XwUav Dz5SfYj2828jdEw5gTPhcD7jPlrW/EZqr9LLyyaCF8W8ErgoV2MnRYjvsaAfLeLiHcr4 OzOA==
MIME-Version: 1.0
X-Received: by with SMTP id x206mr99978757ywd.97.1452619756173; Tue, 12 Jan 2016 09:29:16 -0800 (PST)
Received: by with HTTP; Tue, 12 Jan 2016 09:29:16 -0800 (PST)
In-Reply-To: <>
References: <> <>
Date: Tue, 12 Jan 2016 09:29:16 -0800
Message-ID: <>
From: Watson Ladd <>
To: Yoav Nir <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Cc: "<>" <>
Subject: Re: [TLS] Fixing TLS
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 12 Jan 2016 17:29:24 -0000

On Tue, Jan 12, 2016 at 9:13 AM, Yoav Nir <> wrote:
> Hi, Peter
> Ignoring for a moment the merits of this proposal vs the TLS 1.3 (or 2.0) that this WG is working on right now, why?
> Other groups are not working on HTTP/1.2 or IKEv1.1 or any other $protocolv$(major-1).$(minor+1).
> Any TLS library that exists now doesn’t have an implementation of either “your” TLS 1.3 or “our” TLS 1.3. To get either, you’ll need to get an upgraded version of your favorite library. So the upgrade path is no smoother for either protocol.   If this had been brought up before the work on the current draft started, maybe we would be convinced. As it is, I don’t see the point.

Not if TLS 1.2.1 is a subset of TLS 1.2, similar to the UTA profile.
In fact, that's what happened the last time this idea was raised: it
got kicked over to UTA.

> Yoav
>> On 12 Jan 2016, at 4:03 PM, 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,
>> namely:
>> Bhargavan et al, "Proving the TLS handshake secure (as is)".
>> Brzuska et al, "Less is more: relaxed yet compatible security notions for key
>> exchange".
>> Dowling et al, "Modelling ciphersuite and version negotiation in the TLS
>> protocol".
>> Firing, "Analysis of the Transport Layer Security protocol".
>> Gajek et al, "Universally Composable Security Analysis of TLS".
>> Giesen et al, "On the security of TLS renegotiation".
>> Jager et al, "On the security of TLS-DHE in the standard model".
>> Krawczyk et al, "On the security of the TLS protocol".
>> (and probably several more) and use them to simplify TLS 1.2 to create an
>> improved TLS that leverages about 15 years of analysis, rather than creating
>> what's almost a new protocol based on bleeding-edge/experimental ideas,
>> mechanisms, and algorithms.
>> The discussion started out somewhat informally so by the time it got really
>> interesting it was too late to take notes, but I thought I'd try and recreate
>> the design points...
>> - Drop 99% of all cipher suites, leaving one traditional one (DHE + AES-CBC +
>> HMAC-SHA2 + RSA-SHA2/PSK for auth) and one ECC one (ECDHE + AES-GCM + HMAC-
>> SHA2 + ECDSA-SHA2/PSK for auth) as must's (with a strong preference for OCB
>> instead of GCM as the AEAD if it were freely available).
>> - For the non-AEAD cipher, use EtM not MtE (so effectively making it AEAD as
>> well).
>> - Get rid of the IPsec cargo-cult MAC truncation.
>> - For DHE, send the full set of parameters (X9.42), not p+g only (PKCS #3) to
>> allow verification (for those who don't have a copy of X9.42, it requires
>> the same verification steps as FIPS 186 does).  Also, mix the hash of the
>> DHE values into the computed premaster secret to protect against use of
>> manipulated curves.
>> - RSA-PSS, not PKCS #1 (with a subset arguing for PKCS #1 with the sig-check
>> done as encode-then-compare, which fixes all known padding-manipulation
>> issues).
>> - No compression or rehandshake.
>> - Replace the PRF with HKDF?  (No pressing need for this, but it would be part
>> of the general cleanup).
>> Longer discussion points:
>> - The DHE/ECDHE parameters were a bit contentious.  For DHE the choice is
>> between server-specified ephemeral parameters and IETF-blessed fixed ones.
>> Arguments can be made either way, we had de facto IETF-blessed fixed DHE
>> params in the form of the RFC 2409 ones, but that wasn't such a good idea.
>> OTOH with ephemeral DHE params many implementations didn't check them, but
>> then the spec never required any checking (or much of anything at all in
>> regard to DHE use, which no doubt contributed to some of the dubious
>> practices that have been found in the wild).  The situation wasn't helped by
>> the use of the PKCS #3 representation, which the requirement to use the
>> X9.42 form alongside the accompanying checks attempts to address.
>> - Similarly, for ECDHE the choice is between NIST and CFRG ones.  The CFRG
>> ones are obviously better (for various values of better, see endless debates
>> elsewhere), but some people will insist on only using something that's come
>> from NIST (I'll reserve my opinion on that one, and wouldn't dream of
>> stooping to phrases like "cargo cult protocol design"...).
>> Peter.
>> _______________________________________________
>> TLS mailing list
> _______________________________________________
> TLS mailing list

"Man is born free, but everywhere he is in chains".