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

Nikos Mavrogiannopoulos <nmav@redhat.com> Tue, 08 November 2016 09:49 UTC

Return-Path: <nmav@redhat.com>
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 D64321295DA for <tls@ietfa.amsl.com>; Tue, 8 Nov 2016 01:49:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.419
X-Spam-Level:
X-Spam-Status: No, score=-8.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-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 MkuxBOIFDpJG for <tls@ietfa.amsl.com>; Tue, 8 Nov 2016 01:49:10 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2793F1295D7 for <tls@ietf.org>; Tue, 8 Nov 2016 01:49:10 -0800 (PST)
Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id DAC478F275; Tue, 8 Nov 2016 09:49:09 +0000 (UTC)
Received: from dhcp-10-40-1-102.brq.redhat.com ([10.40.3.171]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id uA89n7JG023446 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 8 Nov 2016 04:49:09 -0500
Message-ID: <1478598547.2532.57.camel@redhat.com>
From: Nikos Mavrogiannopoulos <nmav@redhat.com>
To: Daniel Migault <daniel.migault@ericsson.com>
Date: Tue, 08 Nov 2016 10:49:07 +0100
In-Reply-To: <CADZyTknYBNHCucPxZODCLrjvA-UvPuFojkTfUXhh0n-y_eekVA@mail.gmail.com>
References: <20160527171935.11166.82258.idtracker@ietfa.amsl.com> <7a3597ae-92b8-23c8-b2c3-357f6fdb6792@bouncycastle.org> <6CE18F17-F8E0-4F4A-95A4-BE9B3A8250A2@sn3rd.com> <80bc8ae67e0ba0e2355b26bdbb34d1b6.squirrel@www.trepanning.net> <D41FA5C6.52E9B%john.mattsson@ericsson.com> <CADZyTkkJv2yyd5p7CR8p5gHCE+gjWQNu-+39N4RW-26gh+NzSA@mail.gmail.com> <CADZyTkmHwL=2MVQOUKwDkMur_gMiT_00Q6EY-h=zOUbfeddAOA@mail.gmail.com> <CADZyTkm05WD_DSHFUJMtPughDQKuS2-ZwRVwuHPFdLh=tAthzA@mail.gmail.com> <1478593476.2532.29.camel@redhat.com> <CADZyTknYBNHCucPxZODCLrjvA-UvPuFojkTfUXhh0n-y_eekVA@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Tue, 08 Nov 2016 09:49:09 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/Ej2CGxw8mtd4o4tjtvsEGlukRIM>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] I-D Action: draft-ietf-tls-ecdhe-psk-aead-00.txt
X-BeenThere: tls@ietf.org
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." <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: Tue, 08 Nov 2016 09:49:11 -0000

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