[TLS] secdir review of draft-ietf-tls-ecdhe-psk-aead-03

Benjamin Kaduk <kaduk@mit.edu> Fri, 19 May 2017 04:43 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70A81129C6E; Thu, 18 May 2017 21:43:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.303
X-Spam-Level:
X-Spam-Status: No, score=-2.303 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 TdrSVNrUSx8o; Thu, 18 May 2017 21:43:21 -0700 (PDT)
Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBABA129C13; Thu, 18 May 2017 21:38:35 -0700 (PDT)
X-AuditID: 1209190f-db7ff70000005284-13-591e76c97452
Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 4E.26.21124.9C67E195; Fri, 19 May 2017 00:38:34 -0400 (EDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id v4J4cWgl014307; Fri, 19 May 2017 00:38:33 -0400
Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v4J4cRQa011042 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 19 May 2017 00:38:31 -0400
Date: Thu, 18 May 2017 23:38:27 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: iesg@ietf.org, secdir@ietf.org, draft-ietf-tls-ecdhe-psk-aead.all@ietf.org
Cc: tls@ietf.org, ietf@ietf.org
Message-ID: <20170519043827.GL39245@kduck.kaduk.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.7.1 (2016-10-04)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrDIsWRmVeSWpSXmKPExsUixG6nrnuqTC7SYP57GYs3yzYxWcz4M5HZ 4tnG+SwWHxY+ZLH4dL6L0YHVY8mSn0wBjFFcNimpOZllqUX6dglcGT0P9rAWfJapWPr7P2MD 41bxLkYODgkBE4lLb1y7GLk4hAQWM0mc3vWUHcLZyCjx4m4rK4RzlUniZNdJIIeTg0VAVWLV 4WvsIDabgIpEQ/dlZhBbRMBPYt2P90wgNrOAvMSidzfBaoQFrCR+bvwDFucF2vZpRRcbhC0o cXLmExaIei2JG/9eMoFcxCwgLbH8HwdIWFRAWeLv4XssExj5ZiHpmIWkYxZCxwJG5lWMsim5 Vbq5iZk5xanJusXJiXl5qUW6Jnq5mSV6qSmlmxhBgcgpyb+DcU6D9yFGAQ5GJR7eBytkI4VY E8uKK3MPMUpyMCmJ8s4IkIsU4kvKT6nMSCzOiC8qzUktPsQowcGsJMIrLgaU401JrKxKLcqH SUlzsCiJ84prNEYICaQnlqRmp6YWpBbBZGU4OJQkeJeVAjUKFqWmp1akZeaUIKSZODhBhvMA Dc8HqeEtLkjMLc5Mh8ifYlSUEue1KAFKCIAkMkrz4HpBiUIie3/NK0ZxoFeEeb1B2nmASQau +xXQYCagwc0PpEEGlyQipKQaGB1b8nfVilR23Fh8536vG9fSB1ev3/FOM/Tvi/9bf+exkMXs F+6TV/FeWuVulP3j4d830Ys3hhuu2/tobdPl2PPSLp0KSs8v2+/6KnBPZHvHlaU3wto23q0K WXRz6pLyd7xn3K5ML5dMWLJpQqx1HZPjA3fu3yx2S5b5mQUm/hNaN43xy+nF254qsRRnJBpq MRcVJwIA6NGlB+8CAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/RE5HJl8mnReBZ3Yb3WlIQQogJMA>
Subject: [TLS] secdir review of draft-ietf-tls-ecdhe-psk-aead-03
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
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: Fri, 19 May 2017 04:43:23 -0000

Hi all,

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should
treat these comments just like any other last call comments.

This document is ready with nits.

Essentially, we are filling in a gap in the TLS (< 1.3) ciphersuite
space, thought of as a cross product of key exchange and
cipher+mac/AEAD -- we have some of the combinations (PSK with ECDHE
but no AES-[GC]CM, PSK with AES-GCM but only non-EC DH, etc.) but
not quite this one.

That said, it seems a little silly to only partially fill the gap
(by omitting the AES_256_CCM* cipher suites), even though there is
not currently demand for them.

This document is just assembling pieces that were already specified
elsewhere, so it need not contain much detail itself, which is fine.
That said, I think section 3 should probably state explicitly which
pieces it uses, instead of a vague reference of being "based on RFC
4279".  So, "The ServerKeyExchange and ClientKeyExchange messages
from RFC 5489 for ECDHE_PSK are used, and the premaster secret is
computed in the same manner as for ECDHE_PSK key exchange in RFC
5489."  (I am not sure why RFC 4279 is cited in the current text; it
does not cover ECDHE_PSK.)

The premaster_secret structure so used basically ends up putting the
ECDH output first followed by the static PSK; with the pre-TLS 1.2
PRF, that would give the ECDH shared secret to md5 and the PSK to
sha1, which is perhaps another reason to not use these with pre-1.2
worth mentioning (in addition to the AEAD availability).

The security considerations largely refer to those of the other
documents providing the pieces that are combined together here;
those referenced security considerations sections are more than
adequate here, as this document itself does not really do anything
particularly novel.  That said, if we are going to reiterate the
entropy requirement for PSKs inline, we probably ought to also
reiterate the nonce-reuse considerations for GCM and CCM.  The
relevant constructions help, but there are still ways to mess up and
reuse a nonce when doing crypto in parallel, if I remember the
GCM/TLS document's security considerations correctly.


Some other editorial nits follow.

I see we're already discussing "perfect forward secrecy" vs.
"forward secrecy"; my preference is for just "forward secrecy" (and
I may have been one of the more active voices in causing TLS 1.3 to
switch), but in the grand scheme of things it doesn't really matter.

In section 2, the RFC 7525 reference that "AEAD algorithms [...] are
strongly recommended" is scoped to just (D)TLS, so the text here
should probably also list that qualification.

In section 4, "... make use of the authenticated encryption with
additional data (AEAD) defined in TLS 1.2" seems to make AEAD into
something of a unique object, as opposed to a class of things with
multiple possible instantiations.  I would consider something like
"... (AEAD) concept".

In section 4, "these cipher suites MUST NOT be negotiated in TLS
versions prior to 1.2" should probably clarify that "these" cipher
suites are the new ones specified by this document.

s/Servers,\nwhich/Servers\nthat/

Does the last paragraph of section 5 want a note "RFC Editor please
remove this paragraph"?

Section 6, third paragraph, s/by using short PSK/by using a short
PSK/.  Also, s/by a human and thus/by a human which thus/, maybe?

Last paragraph page 4, comma after "i.e.".


-Ben