Re: [TLS] I-D Action: draft-ietf-tls-ecdhe-psk-aead-00.txt
Daniel Migault <daniel.migault@ericsson.com> Mon, 17 October 2016 17:16 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 97103129437 for <tls@ietfa.amsl.com>; Mon, 17 Oct 2016 10:16:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.597
X-Spam-Level:
X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, 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 M464-96bkvkU for <tls@ietfa.amsl.com>; Mon, 17 Oct 2016 10:16:28 -0700 (PDT)
Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (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 3549F129524 for <tls@ietf.org>; Mon, 17 Oct 2016 10:16:28 -0700 (PDT)
Received: by mail-it0-x236.google.com with SMTP id 139so49489394itm.1 for <tls@ietf.org>; Mon, 17 Oct 2016 10:16:28 -0700 (PDT)
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=rN+5y5ggt+DBVNg/0jtaksF7FlAAe7p2ahkwMgyJGqE=; b=GsJV7QneMPcat9HC2ywINmBp0dLX9/zVvdGy/is/jc27/ki32iZdZfWGSO4YnOo4s5 10STPp6/b3yt/5nNvOe72MqLrkuEPDCddc4DiaCojPjhfOc+TX6rYNiz22vPzWmwWzJO BsRzWR1RBu0nFqSklRzTfdAPN/toSRivWzA5rV8VYHlj3SmXnJuDENrqIY/eh+eWUGa7 4huPePZLFqFrsk2dSqmetyF7m2K0DdYAw1UldZ/omV6oEWz/Y5NV3he4myQUr5otI1EC zuPEEg3EycHSdTPGbFZ6xqONF43RyPcjqR1LAhBYMys8A3pt0tPcnZaniQxzNShiw8wF YDFA==
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=rN+5y5ggt+DBVNg/0jtaksF7FlAAe7p2ahkwMgyJGqE=; b=GO7Plsv/x233jwRJMILTaL9VSzjqD6fnHPnE6XXzxhOT9z0h6bgtAXOlecdFDnnups LKhQuL0ZLUZEt9HXSen1V6cNqQ1cu8KG6GOHbSidltsHb4iiPvIKYFUF5K0iYizCSUF8 c/xI2zLGmKDX8YrKnJzuYZ3odRs8JbrplRIB3/1ziO4BOH4xrp203IGCwE/5py2eowc+ geBlmcn+Uvo37GtUHG9aJwPxn/yzyrNB/8bEFXUT+OOZSK5fEJd20DFsOfNi1AdbAxsN z0BZ7b2GmraBvEI6ptvEhfPA5brYRXoCWNmEx2JVwEwUAHu4+WCd4O2Zeqz2KQf+ksoe BzkQ==
X-Gm-Message-State: AA6/9RkF68dy8Quf7NT3xSS7g9aUftUmi7F33tBll6OtPurDOf5q/vrOlMB7OvqGBZsd0kqqBGf6eGp/T/0Epg==
X-Received: by 10.36.90.202 with SMTP id v193mr9630565ita.120.1476724587543; Mon, 17 Oct 2016 10:16:27 -0700 (PDT)
MIME-Version: 1.0
Sender: mglt.ietf@gmail.com
Received: by 10.107.188.4 with HTTP; Mon, 17 Oct 2016 10:16:27 -0700 (PDT)
In-Reply-To: <D41FA5C6.52E9B%john.mattsson@ericsson.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>
From: Daniel Migault <daniel.migault@ericsson.com>
Date: Mon, 17 Oct 2016 13:16:27 -0400
X-Google-Sender-Auth: LX2RTcVBuCvLvqFGISi0qI3Hhk4
Message-ID: <CADZyTkkJv2yyd5p7CR8p5gHCE+gjWQNu-+39N4RW-26gh+NzSA@mail.gmail.com>
To: John Mattsson <john.mattsson@ericsson.com>
Content-Type: multipart/alternative; boundary="001a1145c51c78c2ad053f12bc72"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/ONYU-yH8qXEft44AzjXIgPQqpIE>
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: Mon, 17 Oct 2016 17:16:30 -0000
Hi, I am not very clear on how to update the text of the draft. The problem seems to me that code point restriction are hard to implement. As a result, the session is aborted with - insufficient_security(71) or equivalent - when the code point does not match the security strength. I am encline to think that we should also provide some profiles that achieve 128/256 bit security. These profiles may be described in this document or in another document more related to cryptographic recommendation. What would be the most appropriated way to move forward ? BR, Daniel On Sun, Oct 9, 2016 at 2:59 AM, John Mattsson <john.mattsson@ericsson.com> wrote: > Hi Dan, Sean, Nikos, > > First, let me state that I think requiring 128-bit key management for > AES-128 is quite reasonable. > > HTTP/2 [RFC7540] also has some related text in Section 9.2.1 that applies > when TLS is used for HTTP/2. "Endpoints MAY treat negotiation of key sizes > smaller than the lower limits as a connection error (Section 5.4.1 > <https://tools.ietf.org/html/rfc7540#section-5.4.1>) of type > INADEQUATE_SECURITY." > > > I think this is a question for TLS in general, > draft-ietf-tls-ecdhe-psk-aead should just follow what the TLS WG decides > as the general way forward. Wether that is MAY/SHOULD/SHALL treat groups > with insufficient security as an error. > > I think the real problem here are TLS libraries supporting 1024 MODP and > 160 ECC at all, support for these should have been removed before 2010. > Nikos [0] recommends a RCF forbidding weak elliptic curves from TLS 1.2 > (i.e. WeakDH DieDieDie!!!). I think this is a great idea and much better > than bundling it into a code-point assignment RFC. (My current plans for > the next update of 3GPP’s TLS and DTLS profiles is simply to forbid > support of anything weaker than 2048 MODP and 255-bit ECC). > > [0]. https://mailarchive.ietf.org/arch/msg/tls/4PZsc_Dy-aT299BYrlBKvZs0BOQ > > > > Cheers, > John > > > On 11/07/16 22:26, "TLS on behalf of Dan Harkins" <tls-bounces@ietf.org on > behalf of dharkins@lounge.org> wrote: > > > > > I'm glad I have to opportunity to make you happy Sean :-) > > > >On Mon, July 11, 2016 7:40 am, Sean Turner wrote: > >> I think I can take this bit: > >> > >> On Jul 10, 2016, at 06:51, Peter Dettman > >><peter.dettman@bouncycastle.org> > >> wrote: > >>> > >>> I'm also curious whether there is a precedent in other RFCs for an > >>> explicit minimum curve bits, or perhaps a de facto implementer's rule? > >> > >> I'd be happy to be wrong here. but to my knowledge no there's not been > >> an explicit minimum for curve bits. There have however been similar (at > >> least in my non-cryptographer mind) for RSA key sizes so if we wanted to > >> define an explicit minimum curve bits then we could. > > > > draft-ietf-tls-pwd-07 includes a RECOMMENDED practice of ensuring > >the curves used provide commensurate strength with the ciphersuite > >negotiated. Section 10, "Implementation Considerations", says: > > > > It is RECOMMENDED that implementations take note of the strength > > estimates of particular groups and to select a ciphersuite providing > > commensurate security with its hash and encryption algorithms. A > > ciphersuite whose encryption algorithm has a keylength less than the > > strength estimate, or whose hash algorithm has a blocksize that is > > less than twice the strength estimate SHOULD NOT be used. > > > > And I would like to take this opportunity to remind everyone that > >the only difference between TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 > >and TLS_ECCPWD_WITH_AES_128_GCM_SHA256 is that the latter is resistant > >to dictionary attack and the former is not. > > > > regards, > > > > Dan. > > > > > > > >_______________________________________________ > >TLS mailing list > >TLS@ietf.org > >https://www.ietf.org/mailman/listinfo/tls > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
- Re: [TLS] I-D Action: draft-ietf-tls-ecdhe-psk-ae… Sean Turner
- Re: [TLS] I-D Action: draft-ietf-tls-ecdhe-psk-ae… Sean Turner
- Re: [TLS] I-D Action: draft-ietf-tls-ecdhe-psk-ae… g_e_montenegro
- Re: [TLS] I-D Action: draft-ietf-tls-ecdhe-psk-ae… g_e_montenegro
- Re: [TLS] I-D Action: draft-ietf-tls-ecdhe-psk-ae… Dan Harkins
- [TLS] I-D Action: draft-ietf-tls-ecdhe-psk-aead-0… internet-drafts
- Re: [TLS] I-D Action: draft-ietf-tls-ecdhe-psk-ae… Peter Dettman
- Re: [TLS] I-D Action: draft-ietf-tls-ecdhe-psk-ae… John Mattsson
- Re: [TLS] I-D Action: draft-ietf-tls-ecdhe-psk-ae… John Mattsson
- Re: [TLS] I-D Action: draft-ietf-tls-ecdhe-psk-ae… Daniel Migault
- Re: [TLS] I-D Action: draft-ietf-tls-ecdhe-psk-ae… Daniel Migault
- Re: [TLS] I-D Action: draft-ietf-tls-ecdhe-psk-ae… Daniel Migault
- Re: [TLS] I-D Action: draft-ietf-tls-ecdhe-psk-ae… Martin Thomson
- Re: [TLS] I-D Action: draft-ietf-tls-ecdhe-psk-ae… Nikos Mavrogiannopoulos
- Re: [TLS] I-D Action: draft-ietf-tls-ecdhe-psk-ae… Daniel Migault
- Re: [TLS] I-D Action: draft-ietf-tls-ecdhe-psk-ae… Nikos Mavrogiannopoulos
- Re: [TLS] I-D Action: draft-ietf-tls-ecdhe-psk-ae… Daniel Migault
- Re: [TLS] I-D Action: draft-ietf-tls-ecdhe-psk-ae… Martin Thomson
- Re: [TLS] I-D Action: draft-ietf-tls-ecdhe-psk-ae… Daniel Migault