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

Daniel Migault <> Fri, 19 May 2017 16:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 27D681294EC; Fri, 19 May 2017 09:07: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 PCfPhlC85vcB; Fri, 19 May 2017 09:07:39 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4010:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0CB561294A4; Fri, 19 May 2017 09:07:39 -0700 (PDT)
Received: by with SMTP id h4so3511215lfj.3; Fri, 19 May 2017 09:07:38 -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=uwHBmfuU4afjEOllwHYg5B3VzGqkeebVf6XvE+EY0gg=; b=PO7WgfJRI5Y2h5a5x+4Z48haRK7enlYhKEX82+icO7n1mXyV5LjnAMlkEKk8fxjSWz 0+jvf7sEfKtlfVuiiTLACjUsvyfQkiXTmfyx9+i+qErhswNaQ3CSyeA1YdCJvI4GU0Zn wasg2WwNIH6Mzx+NFCyywmA/GqQYfgeTmyxyt6E0l+zTHS8W3l+5XXEVLqvL4c535EOJ roVDEwTB/rrT+TjPv6DhSKU5JPNlvdHzK2GHmBa/MLwo7q43n2rQSEf5Ld4TT2Lw5TOt uLsg9L4mTEyeKkZVHW3xCYLxhNToAHy6IsuRNcDProQyaqvlaPHfbyHCzR70vDCTJ4gi C/QA==
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=uwHBmfuU4afjEOllwHYg5B3VzGqkeebVf6XvE+EY0gg=; b=jcE9OllRpEQvmDUK1qHMHPaF4cRWxb6b7K8a6D7knpGDQoYa4hb9bSn7PP2qkPKZhy kPmeVXUU6/krEFWdSXaKRe8AoDZim750iPbRXHyViaesNYSbAHn2rlAYxwQOmdWfGzaN +/KAliemmMBtDD2ZlUu5mJMu0BZM5o8OAejs73kzwic248aUAOGJiBSC5e4mq/JHaLjX UsUM3xy0Vz+3g54RSqIsUy+NobKhahCr9U9CkDo7FFjVzVRxhxs9w9fK8tNwXVwONqCw /Ak15+sViJxy7TzRfa1jNKytQ2mq2fyBMHQXKotof7YHkAlGw4bFGOB8YgxFeifX8tZh CqGQ==
X-Gm-Message-State: AODbwcAQaJZNqMAwWyonSD+mhrlgw3B0A/VEGis8np0z/FzsIfn/ut7C LZhl8xdQk0a+isiKe/At5gS06a1JVw==
X-Received: by with SMTP id r139mr1531754lff.111.1495210057237; Fri, 19 May 2017 09:07:37 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 19 May 2017 09:07:36 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
From: Daniel Migault <>
Date: Fri, 19 May 2017 12:07:36 -0400
X-Google-Sender-Auth: 9qEQEUqd_BBy51at4x7pj0L4Fqc
Message-ID: <>
To: Benjamin Kaduk <>
Cc: Dave Garrett <>, tls <>, The IESG <>, Benjamin Kaduk <>,, "" <>,
Content-Type: multipart/alternative; boundary="94eb2c1a0878538d39054fe2b8a6"
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 16:07:41 -0000

Hi Benjamin and Dave,

Thanks for the clarification. Considering also Roman' s and Ben' s comments
the section is built as follow. 1) Limit cipher suites to TLS1.2, 2)
explain how TLS1.3 and higher version negotiate them 3) bring all
explanation foe the previous versions.


The text is as follows:

<t> The cipher suites defined in this document MUST NOT be negotiated
for any version of (D)TLS other than TLS1.2.</t>

<t> TLS version 1.3 and later negotiate these features in a different
manner. Unlike TLS1.2, TLS1.3 separates authentication and cipher suite
negotiation <xref target="I-D.ietf-tls-tls13"/> Section 1.2. TLS1.3
supports PSK with ECDHE key exchange and the cipher suites
TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_AES_128_CCM_8_SHA256
and  TLS_AES_128_CCM_SHA256 are part of the specification. As a result,
TLS 1.3 and higher versions, negotiate and support these cipher suites
in a different way. </t>

<t>The cipher suites defined in this document make use of the
authenticated encryption with additional data (AEAD) defined in TLS 1.2
<xref target="RFC5246"/> and DTLS 1.2 <xref target="RFC6347" />.
Earlier versions of TLS do not have support for AEAD and consequently,
the cipher suites defined in this document MUST NOT be negotiated in TLS
versions prior to 1.2.  In addition, it is worth noting that TLS1.0
<xref target="RFC2246"/> and TL1.2 <xref target="RFC4346"/> splits teh
pre-master 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.  Clients MUST NOT offer these
cipher suites defined in this document if they do not offer TLS 1.2 or
later. Servers that select an earlier version of TLS MUST NOT select one
of these cipher suites. A client MUST treat the selection of these
cipher suites in combination with a version of TLS that does not support
AEAD (i.e., TLS 1.1 or earlier) as an error and generate a fatal
'illegal_parameter' TLS alert.</t>

On Fri, May 19, 2017 at 10:39 AM, Benjamin Kaduk <> wrote:

> On 05/19/2017 02:16 AM, Dave Garrett wrote:
> On Friday, May 19, 2017 12:38:27 am Benjamin Kaduk wrote:
> 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.
> Probably should be: "the cipher suites defined in this document
> MUST NOT be negotiated for any version of TLS other than 1.2."
> The sentence mentioning TLS 1.3+ could be moved up to right after
> and just say: "TLS version 1.3 and later negotiate these features in
> a different manner."
> That's probably best, yes.  The interaction between this document and TLS
> 1.3 is a little weird, and it's not entirely clear to me that this one
> needs to say much of anything about TLS 1.3, given that TLS 1.3 changes all
> the relevant messages and key hierarchy and such.
> -Ben
> _______________________________________________
> TLS mailing list