Re: [TLS] I-D Action: draft-ietf-tls-ecdhe-psk-aead-00.txt

Daniel Migault <> Tue, 08 November 2016 08:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 019C3129C4C for <>; Tue, 8 Nov 2016 00:50:55 -0800 (PST)
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 KkxEkJunv8sE for <>; Tue, 8 Nov 2016 00:50:52 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c0b::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C3A55129C4B for <>; Tue, 8 Nov 2016 00:50:52 -0800 (PST)
Received: by with SMTP id q124so191489521itd.1 for <>; Tue, 08 Nov 2016 00:50:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=vUWHaKfR61LLcaftO1r68zmGuFEb7M52MzUngaAtSpo=; b=p5eYjlaA1y6QS205dElbKnKQktEQ4aYwO3izTOseadmJOueDvdXiLbhUbNnMqKzK+9 Z4gbddNv0HQTMj3VK/S8KBCarqQpbAs4m6JKZA3EiZhTO1mfhUaZZmSrNSTDdt3Hyamf cvp9M7MWXnWSr73Tn/aEyOVDTgq3fF2evyQApgZBBsC99UhCYkJxtPFmWMea5LDLN9Z/ Gc72PrxqadVdXpyknbb/NjjBeeJ328ox7L/0KcneNwLcWNn/HdTqI6qv3QpiHrhyWIYf LQ+4kMR1sS66CqtOmURJyFSDJ0IYemV+xTBDdEvWcIqWVyKzjLltuni4a+G1LWMlW6Jb eufg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=vUWHaKfR61LLcaftO1r68zmGuFEb7M52MzUngaAtSpo=; b=dPDbECj+D9ImLnh1QLAHRt5aoe7+Z7ByRdvM2uNGVkX1+WYO22rSXos8UWRDvnB2xH C5DY7Y+ZwdBYM81kdpGzeluIFWbbKcmn1imLLJuwbP2YVQ6a3Y/i7ECAPKDGbj4Fm+r7 SSf5FEPBBUja2hMbefzMbtSkdS+yBxCVw1pNQO+n83tzVMAiFS6wLPOAZu5856baMyh3 Tw3wJgJ484Jtjnmete/7UXgSFaNE37aqfllR3BDaJ5fqf7DZ8dhVK5hFB1cv8GUBxX26 XiuGguFCwAYbj8dNYy45/8hEPgReWn//c0UMQVBEOpath2cPVtQldhR0MXtUA6hB8VLO ZrQw==
X-Gm-Message-State: ABUngvfmDk02bd+ICM7Z01A8otyA9EH6NvLngzlCPwCodcuDcN/MORIndd/unUAwRzcO95v3Weq7eOqBUQil4A==
X-Received: by with SMTP id q203mr9386175itd.120.1478595051625; Tue, 08 Nov 2016 00:50:51 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Tue, 8 Nov 2016 00:50:51 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <>
From: Daniel Migault <>
Date: Tue, 08 Nov 2016 03:50:51 -0500
X-Google-Sender-Auth: hdfEgyCGXgxpYsWh5CiaeadCqlg
Message-ID: <>
To: Nikos Mavrogiannopoulos <>
Content-Type: multipart/alternative; boundary="94eb2c08b238d1a3320540c63cf9"
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] I-D Action: draft-ietf-tls-ecdhe-psk-aead-00.txt
X-Mailman-Version: 2.1.17
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: Tue, 08 Nov 2016 08:50:55 -0000

Hi Martin, Niko,

Thanks for the comment. Regarding Martin comment, I agree the text should
not comment the SHAX as these are defined by the cipher suites. What is not
clear to me is how the reference to DH should be handled. I also did not
feel that the provided text provides different recommendations for the
AES-128 / AES-256.

This is the text I would propose then. Please let me know if it catches
your comments and feel free to comment on it.

Regarding Niko, my understanding is that the WG preferred not to have the
definition of profiles in this document. I am not sure you wanted the text
to be removed as MUST NOT was to normative or if you would like no
recommendation at all. The reason I would rather advocate for
recommendation is that ECDHE does not specify an algorithm with a specific
security. As a result, I would rather provide some guide lines to avoid
weak authentication being used with high long AES keys.

-- Text --
When choosing AES-128 cipher suites, servers SHOULD select a key exchange
that is at least 224 bits for cipher suites that use ephemeral elliptic
curve Diffie-Hellman (ECDHE)[RFC4492].

When choosing AES-256 cipher suites, servers SHOULD select a key exchange
that is at least 384 bits for cipher suites that use ephemeral elliptic
curve Diffie-Hellman (ECDHE)[RFC4492].

TLS enable curve negotiation but not for code point.  This makes
restrictions on code points hard to implement.  As a result Endpoints MAY
treat negotiation of key sizes smaller than the lower limits as a
connection error of type insufficient_security(71) for TLS 1.2 and TLS 1.3.

On Tue, Nov 8, 2016 at 3:24 AM, Nikos Mavrogiannopoulos <>

> On Mon, 2016-11-07 at 22:09 -0500, Daniel Migault wrote:
> > Hi,
> >
> > Please find the text I propose. Let me know if you have any comment
> > regarding the proposed text. Unless I receive comment on it, the text
> > will be publish as soon as draft submission is possible.
> >
> > Yours,
> > Daniel
> >
> >    The cipher suites defined in this document are based on the AES-
> > GCM
> >    and AES-CCM Authenticated Encryption with Associated Data (AEAD)
> >    algorithms AEAD_AES_128_GCM, AEAD_AES_256_GCM, AEAD_AES_128_CCM,
> > and
> >    AEAD_AES_256_CCM defined in [RFC5116], AEAD_AES_128_CCM_8 and
> >    AEAD_AES_256_CCM_8 defined in [RFC6655].
> >
> >    For the AES-128 cipher suites, the TLS Pseudorandom Function (PRF)
> >    with SHA-256 as the hash function SHALL be used and Clients and
> >    Servers MUST NOT negotiate curves of less than 255 bits.
> Sorry for not getting back into previous discussions. My comment as
> before would be to remove the text "Clients and Servers MUST NOT
> negotiate curves of less than 255 bits."
> I find that unrelated to the purpose of the text which is define code
> points for certain ciphersuites, and no other code points for TLS set
> such restrictions (DH bits, or curves). Alternatively if with this
> document you want to create a profile of TLS (e.g, like SuiteB rfc
> does), which sets options which are more than just ciphersuites then
> just be clear about it.
> That is, say this document creates a profile of TLS named XXX which if
> used, the clients and servers which conform to it must negotiate the
> ciphersuites defined above and must not negotiate curves of less than
> 255 bits.
> regards,
> Nikos
> _______________________________________________
> TLS mailing list