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

John Mattsson <john.mattsson@ericsson.com> Sun, 09 October 2016 06:59 UTC

Return-Path: <john.mattsson@ericsson.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 057C61294B2 for <tls@ietfa.amsl.com>; Sat, 8 Oct 2016 23:59:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level:
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 hBEvW7QMeeht for <tls@ietfa.amsl.com>; Sat, 8 Oct 2016 23:59:25 -0700 (PDT)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E94811294AD for <tls@ietf.org>; Sat, 8 Oct 2016 23:59:24 -0700 (PDT)
X-AuditID: c1b4fb30-b87ff70000000cb2-6c-57f9eaca608a
Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by (Symantec Mail Security) with SMTP id 1C.87.03250.ACAE9F75; Sun, 9 Oct 2016 08:59:23 +0200 (CEST)
Received: from ESESSMB307.ericsson.se ([169.254.7.51]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0319.002; Sun, 9 Oct 2016 08:59:21 +0200
From: John Mattsson <john.mattsson@ericsson.com>
To: Dan Harkins <dharkins@lounge.org>, Sean Turner <sean@sn3rd.com>, "Nikos Mavrogiannopoulos" <nmav@redhat.com>
Thread-Topic: [TLS] I-D Action: draft-ietf-tls-ecdhe-psk-aead-00.txt
Thread-Index: AQHR2pj1k3z3BfHf+k6el32lv2/tSKATLaCAgABguQCAjLIjAA==
Date: Sun, 9 Oct 2016 06:59:20 +0000
Message-ID: <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>
In-Reply-To: <80bc8ae67e0ba0e2355b26bdbb34d1b6.squirrel@www.trepanning.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.6.7.160722
x-originating-ip: [153.88.183.149]
Content-Type: text/plain; charset="utf-8"
Content-ID: <940A3AB94A7B794FBEC72B8013998788@ericsson.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrAIsWRmVeSWpSXmKPExsUyM2K7q+7pVz/DDe5OErdY+u8Li8WPo1tZ LK6samS2+HS+i9GBxWPJkp9MHs92v2TxeL/vKpvHwYOMASxRXDYpqTmZZalF+nYJXBlTXj1n KbiiWHFo+W72BsYnCl2MnBwSAiYStzbfYQWxhQTWM0q83+bfxcgFZC9ilLh67RAbSIJNwEBi 7p4GMFtEoEji+sYdLCA2s4CixPtL88BsYQFniRmnbrN3MbID1bhI3BWGqHaSmPP1Cth4FgEV id3bJ4NN4RUwl7jw4hUTxKr3jBKNNxczgyQ4Bbwllh3cyQhiMwqISXw/tYYJYpW4xK0n85kg bhaQWLLnPDOELSrx8vE/sAWiAnoSzz4/Z4eIK0msPbwd6DQOoF5NifW79CHGWEtsf3iPDeb6 Kd0P2SHuEZQ4OfMJywRG8VlIts1C6J6FpHsWku5ZSLoXMLKuYhQtTi1Oyk03MtJLLcpMLi7O z9PLSy3ZxAiMx4NbfhvsYHz53PEQowAHoxIPb0LOz3Ah1sSy4srcQ4wSHMxKIrwTnwGFeFMS K6tSi/Lji0pzUosPMUpzsCiJ85qtvB8uJJCeWJKanZpakFoEk2Xi4JRqYIxMVfC98fZCelF9 aGtGkFqBZUHCT8tOLoZdNzJzd2x8Xu/4+f0E4WWadybdff/xNcfu6xJXq/+kXfPlfTbzPduP 6GeWBZM62+olDpZ9eb9VfWpNwpKm0onGqn6LX3s3rLqSHz3z3o0TiTf2sC739Z3y2aVTMyr2 rL7rzffrnjb8uqUcEnvj5W0lluKMREMt5qLiRAC9Sc7uwwIAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/PZZmcu38AIx2Bm7lUlSdKdAFUts>
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: Sun, 09 Oct 2016 06:59:27 -0000

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