Re: [TLS] Comments on the TLS 1.3 draft

Eric Rescorla <> Thu, 06 August 2015 20:41 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 3ABFF1A6F2D for <>; Thu, 6 Aug 2015 13:41:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5K0TMqGsUzqf for <>; Thu, 6 Aug 2015 13:41:03 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1021D1A1DBC for <>; Thu, 6 Aug 2015 13:41:03 -0700 (PDT)
Received: by wicgj17 with SMTP id gj17so37284045wic.1 for <>; Thu, 06 Aug 2015 13:41:01 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=1P9/c3NXUNKDzrcJUAFcc0Xzle84iCEX9HF3IWxgbCc=; b=Fbw4hcAD5WSm65o4gmGJt7zO0u2aifwKZt6nqLK9H8XJBAf4rSlVS/Ttk6imJCRfGP RuAefW79TQzfO1t0afHzK4t79Rx1xjvwSnsh2ptmsS9wqC006iKJSvDmET7WYzCcoFfq pQ67r1kL71z2EZmw20OkplHVPEWaUe3im1B3kpHxygxP+75bqrc4KWCpCrBc8gk2UkFD XvHweJgDb1mhCZ9uj+o/YxHKb/UI+RMa95YOwoOW2HmvyZ5sQ9jK2arcIgiS8oRMSH0S oW85NhpfUDF03WbxHS/IwH4jK7qd6Y56WJNaYGPSTGerDb2XJFn0zXRGoSzYaTUcs6yq Bf+g==
X-Gm-Message-State: ALoCoQlzZfcfyKfMD7qefyP6w90msceitlNvGz0IMBTarpRV+J8OyUyQDfflFt/GmdCRJ6BfYlvk
X-Received: by with SMTP id pa9mr7042499wjb.148.1438893661785; Thu, 06 Aug 2015 13:41:01 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Thu, 6 Aug 2015 13:40:22 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Eric Rescorla <>
Date: Thu, 06 Aug 2015 13:40:22 -0700
Message-ID: <>
To: "Scott Fluhrer (sfluhrer)" <>
Content-Type: multipart/alternative; boundary="089e011771a994a51e051caa8971"
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] Comments on the TLS 1.3 draft
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: Thu, 06 Aug 2015 20:41:05 -0000

On Thu, Aug 6, 2015 at 1:35 PM, Scott Fluhrer (sfluhrer) <
> wrote:

> I recently reviewed the most recent TLS 1.3 draft, and I must say that I
> am impressed; the protocol appears to be a significant improvement.  In
> particular, you simplify the protocol significantly, and as we all know,
> complexity is the enemy of security.  You also drop many of the weak
> options, such as RC4 and the export ciphers; that sounds like an excellent
> idea.
> That said, I do see a few things that puzzle me:
> -          When dealing with ECDSA signatures, the default hash algorithm
> is SHA1, and any other hash function needs to be specified explicitly.
> Might I ask why that is?  No one has demonstrated a SHA1 collision yet;
> however people are creeping closer.  If you ask me (which you didn’t, but
> I’ll give my opinion anyways), the default should be (at least) SHA-256;
> you should allow SHA-1 as a downgrade option only if someone makes a strong
> case that they can implement ECDSA and the rest of TLS 1.3, but
> implementing SHA-256 is just too hard.  Otherwise, it should be discarded
> just like the other known weak cryptographical primitives (such as RC4).
> -          You also allow the provision of someone using MD5 as the hash
> algorithm.  Take the above comments about how SHA-1 is not a good idea, and
> multiply it by a factor of about 10.  I see no justification for allowing
> someone to use a known broken hash algorithm.

This is just a transient state. We have patches in progress to remove both
of these.

-          Given the general theme of simplification, I was a bit puzzled
> by something; you appear to provide two different solutions to “how do I
> quickly reestablish a TLS tunnel”; you have both 0-RTT and session
> resumption.  While both appear to have minor advantages over the other, I
> don’t immediately see any real justification for including the complexity
> of both.  Now, it might be that I’m catching a draft in the middle, and
> that you fully intend to combine them.  Alternatively, there might be
> strong reasons to have both (and it just doesn’t occur to me). In either of
> those two cases, “never mind”

Each of these has some benefit, though I agree that it would be nice to
combine them.
The big issue is:

- For security reasons it's much easier to work with 0-RTT DH exchanges.
- For performance reasons it's nice to have resumption.


> However, despite these minor nits, I would end with saying that the
> working group has done good work on this draft; I look forward to the end
> product.
> Thanks!
> _______________________________________________
> TLS mailing list