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

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7244D129625 for <>; Tue, 8 Nov 2016 02:08:11 -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 222RKjnawOLx for <>; Tue, 8 Nov 2016 02:08:09 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c0b::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C33CF129495 for <>; Tue, 8 Nov 2016 02:08:09 -0800 (PST)
Received: by with SMTP id u205so196261211itc.0 for <>; Tue, 08 Nov 2016 02:08:09 -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=0+WWSTOlAhS31MoP0NbK5cgAKGQEBPyeAsIPYPysYsw=; b=TIaGKDzMfDRrcnp460V9hqagHVL55ELhY4Jas37m54bzJbkzElR1SZM6OhLlVniB9W DlmOLTOuLLk8GTWLZ7kMZJhDpQxjyzuf1Qj31+mZs4EUzUHrcWLBeWT/oeo4UBgLExwC tIYtQf7o8t/isAVFO3YtHh5S8niM5Wxl+b9nRNf0ShI4STm3mwtnyvO3+lwywBpoHrCr oNMCizo4RX7rAUtGHF/2mFcCln4O2aCEMplmKmvkuyBE5h8AO4J7Hc8ArCVKlVEYZT9Z Px83x8jYiaV+l8j1SNW2k+/u0Kkiu3Gaf+q8OR4Wci2FzTmuJM6D6C6DzF3QRrPBYfkf UGIA==
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=0+WWSTOlAhS31MoP0NbK5cgAKGQEBPyeAsIPYPysYsw=; b=Sa0RGeqvaqIuuv62mABqm17a3aGJta0NSoN8h7s/afGks7zTtKINYoux0ThBTNZDin x8/K/VIrOZPXllQS4vFPfZ3kdg8sStVT4ZyjGYtT08cPG4JdYkVV2qQILLp0HRgTxkHu 1p5AxH8DYyHkQ6cbKPQB+2NndWWsJT1PKr6vYUqFIzeIrSlZ2f0Ej6o0SdQ2HiJGGB4X T442+WmrD5QIivUzTXnN3O+COouCCUMNCLJboao1kpKFqHPfYulZZhsgqwvGpJsZmd/c eP+YmCuO2AZ72pMgC1zLxweBpqfneXqltGD75MGuaTnJPr2YLGscsFLfhHowK48QMbAs W5Iw==
X-Gm-Message-State: ABUngvcI8ddcAzu3MhervMalKEyWzU+/toDwwsa2ThAPRdAbdgpcoP2jfBEuoSpGe2ZaIKY/n0zGLiK+nlxJAQ==
X-Received: by with SMTP id f3mr8433904ita.101.1478599688975; Tue, 08 Nov 2016 02:08:08 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Tue, 8 Nov 2016 02:08:08 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <>
From: Daniel Migault <>
Date: Tue, 08 Nov 2016 05:08:08 -0500
X-Google-Sender-Auth: Adtwqn4ktfQade-sopyWDbViNPE
Message-ID: <>
To: Nikos Mavrogiannopoulos <>
Content-Type: multipart/alternative; boundary="001a1146f0b239f9b80540c75159"
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 10:08:11 -0000

If I understand correctly, you recommend something that is of the flavor in
the security recommendation section:

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.

If that is correct I will propose some better text explaining why we can
hardly provide some better text, including the one provided by HTTP2.


On Tue, Nov 8, 2016 at 4:49 AM, Nikos Mavrogiannopoulos <>

> On Tue, 2016-11-08 at 03:50 -0500, Daniel Migault wrote:
> > 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.
> That's a valid concern, but TLS doesn't have the notion of a security
> level, and I am not sure that you can easily introduce it with a
> ciphersuite point assignment rfc. With TLS you can easily use AES-256
> with DHE-RSA with DH parameters of 4096-bits, signed with an RSA
> certificate of 32-bits. One can use your draft with a 8-bit PSK, and
> still be insecure despite the fact that you force a 256-bit curve or
> better. When trying to ensure a consistent level you may likely need to
> adjust the finished message size as well.
> Nevertheless, I think to cover your goal, a security considerations
> addition that makes apparent that in addition to the ciphersuite
> parameters, the TLS protocol finished message size, the elliptic curves
> used, and the size of the selected key define the security level of the
> session.
> regards,
> Nikos
> _______________________________________________
> TLS mailing list