[TLS] Comments on the TLS 1.3 draft

"Scott Fluhrer (sfluhrer)" <sfluhrer@cisco.com> Thu, 06 August 2015 20:35 UTC

Return-Path: <sfluhrer@cisco.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 162D31A0334 for <tls@ietfa.amsl.com>; Thu, 6 Aug 2015 13:35:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id qinsbsfxlBlM for <tls@ietfa.amsl.com>; Thu, 6 Aug 2015 13:35:11 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 000751A00D0 for <tls@ietf.org>; Thu, 6 Aug 2015 13:35:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10532; q=dns/txt; s=iport; t=1438893310; x=1440102910; h=from:to:subject:date:message-id:mime-version; bh=AsCH/r5fS4MWNv+TrEpKj4kukQEI5JBJ0JxhLxFlbF4=; b=dtq3oTR8UZwvJBq8FJN3YKb0OyMWljBNfNc79CuLZcxWdXUatT81kJWI e9UanwiTuou8KxJPGQIl8O4oDjB+/c6NFcmRdOckrg8bYcK2NbmQWnl4/ M+aPOQoacmIZ7N+P8rLB7NYi3k25fIOqkP4ElOHF30qAc4UpKCnvJKY82 g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos; i="5.15,624,1432598400"; d="scan'208,217"; a="16526440"
Received: from rcdn-core-3.cisco.com ([]) by rcdn-iport-7.cisco.com with ESMTP; 06 Aug 2015 20:35:04 +0000
Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com []) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t76KZ40r017767 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for <tls@ietf.org>; Thu, 6 Aug 2015 20:35:04 GMT
Received: from xch-aln-001.cisco.com ( by XCH-ALN-001.cisco.com ( with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 6 Aug 2015 15:35:03 -0500
Received: from xhc-rcd-x11.cisco.com ( by xch-aln-001.cisco.com ( with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Thu, 6 Aug 2015 15:35:03 -0500
Received: from xmb-rcd-x04.cisco.com ([]) by xhc-rcd-x11.cisco.com ([]) with mapi id 14.03.0248.002; Thu, 6 Aug 2015 15:35:03 -0500
From: "Scott Fluhrer (sfluhrer)" <sfluhrer@cisco.com>
To: "tls@ietf.org" <tls@ietf.org>
Thread-Topic: Comments on the TLS 1.3 draft
Thread-Index: AdDQh1sDmNL//7S4RNq25TsEbTcNdQ==
Date: Thu, 06 Aug 2015 20:35:03 +0000
Message-ID: <A113ACFD9DF8B04F96395BDEACB340420D164FC1@xmb-rcd-x04.cisco.com>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_A113ACFD9DF8B04F96395BDEACB340420D164FC1xmbrcdx04ciscoc_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/E7NdvVBl-GrSMpi029xRY8YYXIM>
Subject: [TLS] Comments on the TLS 1.3 draft
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: Thu, 06 Aug 2015 20:35:14 -0000

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.

-          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"

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.