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

Daniel Migault <> Fri, 19 May 2017 15:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 97E901294D8; Fri, 19 May 2017 08:55:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IePb0rm2HD51; Fri, 19 May 2017 08:55:38 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4010:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 17B04129484; Fri, 19 May 2017 08:55:38 -0700 (PDT)
Received: by with SMTP id 99so3338356lfu.1; Fri, 19 May 2017 08:55:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=L+plUwKnFmIyg/bdkHFdC9zg9l6zsBn2dNJEtQP4xVY=; b=OSQ+ZqGcE/2bL57NRRhDieKYYUeBNWBBg2E6S6DFYfz88tYyXZEkHZNLBHMdqQ8Jc7 WbZiL65bMIesBTDfh+32SZxazGx3l6THtgI3uNT0GQGpttynE4cfwgpVC5j18jU3Vtxh Yrhz5Z6Umq4h0kNkWr3Rtooxjt7e8bjqlEMDlNEfCZY0QjzW0jGySVCR4ykay0ugoLbX yTj8GaHSJFPnwkuS3XwIWL8plxj3i8JFJSi+sSO1KhfiddfFJhPzZezqrrDtypW70aOh Gmg1SDciTUvf2ld2LAbollaPRQpsm9qDJ/lYnIh48fnSvOeC9tAqMrohd/K2aP5eZJTZ y7Qw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=L+plUwKnFmIyg/bdkHFdC9zg9l6zsBn2dNJEtQP4xVY=; b=HQ1nVYAOhArZTa/jmK0GNCKJvCNmOnAseIYcnZAggUSjC4txGl13VOhuqgejQx3i08 PKQ2qZHtKpRfotI+LjeSbvY6YNDicBYm/dapVR8C6uhGWbV/ZkTQUd1rpd0iJRh4xVO6 ftq07ULtpgPPVu4b9Hsmy3Dej6R3br0g/PMlLMHCcVEpYjtDz1WWGKayiq7RKPf1HyG/ vcFM0AHs7vA+qLxE41q30GWUUhgnagMiuQlvdEZ5qdAIi5sDXBGM0Nez/2tDWxCgxtS6 vpUO5CMfZOFIzhHS9ifsEuDj7oevfJZRpjX/cpPwvbQ6vEZNmcD5fAfy2RB6/CxC7KVq be8g==
X-Gm-Message-State: AODbwcCVtqG8TQp6ZCQqObtWF6Meu7zePAcPQd6ysO6TZ4mVRw8uSK+6 7xBGmHTguF4X/SLdnJtv6d7b7JzVW872
X-Received: by with SMTP id x66mr2272178lfi.145.1495209336235; Fri, 19 May 2017 08:55:36 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 19 May 2017 08:55:35 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Daniel Migault <>
Date: Fri, 19 May 2017 11:55:35 -0400
X-Google-Sender-Auth: mkl0vhJtSKd0EsKUTBHbL0a9Xck
Message-ID: <>
To: Benjamin Kaduk <>
Cc: The IESG <>,,, tls <>, "" <>
Content-Type: multipart/alternative; boundary="94eb2c0e7d8859eec0054fe28dcd"
Archived-At: <>
Subject: Re: [TLS] secdir review of draft-ietf-tls-ecdhe-psk-aead-03
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 19 May 2017 15:55:42 -0000

Hi Benjamin,

Thank you for the review. Please find my comments inline and let me know if
you agree with the proposed text. I believe the only point not addressed
concerns the addition of CCM-256 which has been remove after discussion
during the WGLC.

Thanks you for the review,


On Fri, May 19, 2017 at 12:38 AM, Benjamin Kaduk <> wrote:

> 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.
TLS_ECDHE_PSK_WITH_AES_256_CCM_SHA384  were mentioned in the 01 and removed
after  the WGLC. [0] The issue was whether or not introducing new ciphers
not supported by TLS1.3. In 01, we though of adding the code point for
TLS1.2 and then specify that TLS1.3 was only implementing a **subset** of
the cipher suites proposed.In case of needs these could still be supported
later by TLS1.3. The consensus seems to not introduce ciphers that would
not be handled by TLS1.3. If the WG decides otherwise, these could still be


> 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.)

MGLT: I agree we coudl be more explicit, here are the changes I propose. I
believe it address your purpose.


Messages and pre-master secret construction in this
document are based on [RFC4279 <>].


Messages and pre-master secret construction in this
document are defined in [RFC5489]. The ServerKeyExchange
and ClientKeyExchange messages and premaster secret is
computed as for  the ECDHE_PSK key exchange.

> 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).

MGLT: I believe the following text address your concern, however I am
wondering if we are not going beyond the scope of expected considerations.

In addition, it is worth noting that TLS1.0 <xref target="RFC2246"/> and
TL1.2 <xref target="RFC4346"/> splits the premaster in two parts. The PRF
results of mixing the two pseudorandom streams with distinct hash functions
(MD5 and SHA-1) by exclusive-ORing them together. In the case of ECDHE_PSK
authentication, the PSK and pre-master are treated by distinct hash
function with distinct properties. This may introduce vulnerabilities over
the expected security provided by the constructed pre-master. As such
TLS1.0 and TLS1.1 SHOULD NOT be used with ECDHE_PSK.

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

MGLT: I believe the following text address your comments.

 <t>GCM or CCM encryption - even of different clear text - re-using a
nonce with a same key undermines the security of GCM and CCM. As a
result, GCM and CCM MUST only be used with system guaranteeing nonce
uniqueness <xref target="RFC5116"/>.</t>

> 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.
> MGLT: perfect forward secrecy has been removed and replaced by forward

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

MGLT: I believe the following text address your concern:

OLD text:
<t>AEAD algorithms that combine encryption and integrity protection are
strongly recommended for <xref target="RFC7525" /> and non-AEAD algorithms
are forbidden to use in TLS 1.3 <xref target="I-D.ietf-tls-tls13"/>.

NEW text:
<t>AEAD algorithms that combine encryption and integrity protection are
strongly recommended for (D)TLS <xref target="RFC7525" /> and non-AEAD
are forbidden to use in TLS 1.3 <xref target="I-D.ietf-tls-tls13"/>.

> 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.
> MGLT: I believe the following text address your comment:

these cipher suites MUST NOT be negotiated in TLS  versions prior to 1.2.

the cipher suites defined in this document MUST NOT be negotiated in TLS
versions prior to 1.2.

Clients MUST NOT offer these cipher suites

Clients MUST NOT offer these cipher suites defined in this document

> s/Servers,\nwhich/Servers\nthat/
MGLT: Done

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

> 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?
> MGLT: Probably ;-) done. thanks.

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

MGLT: Added

> -Ben
> _______________________________________________
> TLS mailing list