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

Daniel Migault <daniel.migault@ericsson.com> Tue, 08 November 2016 10:08 UTC

Return-Path: <mglt.ietf@gmail.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 7244D129625 for <tls@ietfa.amsl.com>; Tue, 8 Nov 2016 02:08:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 222RKjnawOLx for <tls@ietfa.amsl.com>; Tue, 8 Nov 2016 02:08:09 -0800 (PST)
Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C33CF129495 for <tls@ietf.org>; Tue, 8 Nov 2016 02:08:09 -0800 (PST)
Received: by mail-it0-x231.google.com with SMTP id u205so196261211itc.0 for <tls@ietf.org>; Tue, 08 Nov 2016 02:08:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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; d=1e100.net; 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 10.36.36.3 with SMTP id f3mr8433904ita.101.1478599688975; Tue, 08 Nov 2016 02:08:08 -0800 (PST)
MIME-Version: 1.0
Sender: mglt.ietf@gmail.com
Received: by 10.107.188.4 with HTTP; Tue, 8 Nov 2016 02:08:08 -0800 (PST)
In-Reply-To: <1478598547.2532.57.camel@redhat.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> <1478598547.2532.57.camel@redhat.com>
From: Daniel Migault <daniel.migault@ericsson.com>
Date: Tue, 8 Nov 2016 05:08:08 -0500
X-Google-Sender-Auth: Adtwqn4ktfQade-sopyWDbViNPE
Message-ID: <CADZyTk=Z8VV3LRsSbvL5Vg3PdHeMwcnm538M8CZkdZMF0TEHYQ@mail.gmail.com>
To: Nikos Mavrogiannopoulos <nmav@redhat.com>
Content-Type: multipart/alternative; boundary=001a1146f0b239f9b80540c75159
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/oQQNzF7aKPqrtwjAds_ZXMD15p0>
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 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.

Yours,
Daniel


On Tue, Nov 8, 2016 at 4:49 AM, Nikos Mavrogiannopoulos <nmav@redhat.com>
wrote:

> 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
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>