Return-Path: 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 54F75129490 for ; Mon, 7 Nov 2016 19:09:46 -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 gSh7VUSdiNo8 for ; Mon, 7 Nov 2016 19:09:42 -0800 (PST) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::22f]) (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 781051294F2 for ; Mon, 7 Nov 2016 19:09:41 -0800 (PST) Received: by mail-it0-x22f.google.com with SMTP id u205so175860630itc.0 for ; Mon, 07 Nov 2016 19:09:41 -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=2f/v0lhV2DJbb/cHiaszABfNwvDmMkywCAYeFcHeHPM=; b=WqQ61kKmKZ4OE9z/Efi8yR52tz3meta8D8cn5hAO2UBo2rmim7gTcOGcaDMxq8co5O f4NSxGeT5bVsIgNAx20UQkQnS+9qWHWaT2VI0MtwLyCCGvlBDkLAxUmguej5iAEyvl/h +eeG70dAXXdGpZVCl6jcMY5M13Dg+6NwDTnOWNIvVX3kbRHLx/JU+gdQojPbIHrtR2aA z5kGlf2J0SVUvczC6rmjbQmXC631ACCGBAzX7YSUvi7Eg1Fsrt+xsY2BQpAq9i5K56oE P0c77/YDvbkIVS6UoSHt9JRrmUJRY+FIA2BZMs9hBjC6j44SVeHhIo5smYvvgkJA/B+Q 8rFw== 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=2f/v0lhV2DJbb/cHiaszABfNwvDmMkywCAYeFcHeHPM=; b=a6+pZvdi/gWLhji4Z96YvYIf60jwYycw0aAp0Qsr4q2/YqPDb1Swe6SRHw3yaTA9RT KnADziDvIxJDgOayw8NcSjYAmbxtCSDk/KJkCFuBbXf0g5LuDyA8o2D7OSbelYd6YlaB Uoc1vPvQ7Vln7RHwVHacfnvA03KJ7jAsawLS9yPRE/gUZOR6ayxpwFNPM5A/3YzC7siP aTdBbp+3kqMbgHaoy53tK2hHe3fZsS4/lI4aCT/4KL9EC1NU6V8xY2q94jqQKhNoF92O dD11tO3VutT2U0pnG7iXvu7dI2t84Dyc7rhvanehhlcUcgBbRVmoEvbgIm88HULvGskY gfKw== X-Gm-Message-State: ABUngvfHseHup2sDW+pBa1qzYAeiRmdOjlREo3tDXGdfuja5hchGMX7UoalcYeCpBZkyUXDs63WR3hkiPn/UgQ== X-Received: by 10.107.18.39 with SMTP id a39mr10100590ioj.45.1478574580752; Mon, 07 Nov 2016 19:09:40 -0800 (PST) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.107.188.4 with HTTP; Mon, 7 Nov 2016 19:09:40 -0800 (PST) In-Reply-To: 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> From: Daniel Migault Date: Mon, 7 Nov 2016 22:09:40 -0500 X-Google-Sender-Auth: uBcZjmXqhl0FtHIHnUYLOFN3CTk Message-ID: To: John Mattsson Content-Type: multipart/alternative; boundary=001a113ff17ca8e80b0540c17810 Archived-At: Cc: "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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2016 03:09:46 -0000 --001a113ff17ca8e80b0540c17810 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Please find the text I propose. Let me know if you have any comment regarding the proposed text. Unless I receive comment on it, the text will be publish as soon as draft submission is possible. Yours, Daniel The cipher suites defined in this document are based on the AES-GCM and AES-CCM Authenticated Encryption with Associated Data (AEAD) algorithms AEAD_AES_128_GCM, AEAD_AES_256_GCM, AEAD_AES_128_CCM, and AEAD_AES_256_CCM defined in [RFC5116], AEAD_AES_128_CCM_8 and AEAD_AES_256_CCM_8 defined in [RFC6655]. For the AES-128 cipher suites, the TLS Pseudorandom Function (PRF) with SHA-256 as the hash function SHALL be used and Clients and Servers MUST NOT negotiate curves of less than 255 bits. For the AES-256 cipher suites, the TLS PRF with SHA-384 as the hash function SHALL be used and Clients and Servers MUST NOT negotiate curves of less than 384 bits. 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 TLS1.2 and TLS1.3. On Mon, Oct 24, 2016 at 11:22 AM, Daniel Migault < daniel.migault@ericsson.com> wrote: > Hi, > > My understanding is that the updated version should not introduce any > profile. Am I correct ? > > BR, > Daniel > > On Mon, Oct 17, 2016 at 1:16 PM, Daniel Migault < > daniel.migault@ericsson.com> wrote: > >> 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 resu= lt, >> the session is aborted with - insufficient_security(71) or equivalent - >> when the code point does not match the security strength. I am encline t= o >> 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 > > 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 appli= es >>> 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 >>> ) 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 decide= s >>> as the general way forward. Wether that is MAY/SHOULD/SHALL treat group= s >>> with insufficient security as an error. >>> >>> I think the real problem here are TLS libraries supporting 1024 MODP an= d >>> 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 bette= r >>> than bundling it into a code-point assignment RFC. (My current plans fo= r >>> the next update of 3GPP=E2=80=99s TLS and DTLS profiles is simply to fo= rbid >>> support of anything weaker than 2048 MODP and 255-bit ECC). >>> >>> [0]. https://mailarchive.ietf.org/arch/msg/tls/4PZsc_Dy-aT299BYrl >>> BKvZs0BOQ >>> >>> >>> >>> Cheers, >>> John >>> >>> >>> On 11/07/16 22:26, "TLS on behalf of Dan Harkins" >> 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 >>> >> >>> >> 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 be= en >>> >> 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 wante= d >>> 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 providin= g >>> > commensurate security with its hash and encryption algorithms. A >>> > ciphersuite whose encryption algorithm has a keylength less than th= e >>> > 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 >>> >> >> > --001a113ff17ca8e80b0540c17810 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Please find the text I pr= opose. Let me know if you have any comment regarding the proposed text. Unl= ess I receive comment on it, the text will be publish as soon as draft subm= ission is possible.

Yours,
Daniel

= =C2=A0=C2=A0 The cipher suites defined in this document are based on the AE= S-GCM
=C2=A0=C2=A0 and AES-CCM Authenticated Encryption with Associated = Data (AEAD)
=C2=A0=C2=A0 algorithms AEAD_AES_128_GCM, AEAD_AES_256_GCM, = AEAD_AES_128_CCM, and
=C2=A0=C2=A0 AEAD_AES_256_CCM defined in [RFC5116]= , AEAD_AES_128_CCM_8 and
=C2=A0=C2=A0 AEAD_AES_256_CCM_8 defined in [RFC= 6655].

=C2=A0=C2=A0 For the AES-128 cipher suites, the TLS Pseudoran= dom Function (PRF)
=C2=A0=C2=A0 with SHA-256 as the hash function SHALL = be used and Clients and
=C2=A0=C2=A0 Servers MUST NOT negotiate curves o= f less than 255 bits.

=C2=A0=C2=A0 For the AES-256 cipher suites, th= e TLS PRF with SHA-384 as the hash
=C2=A0=C2=A0 function SHALL be used a= nd Clients and Servers MUST NOT negotiate
=C2=A0=C2=A0 curves of less th= an 384 bits.

=C2=A0=C2=A0 TLS enable curve negotiation but not for c= ode point.=C2=A0 This makes
=C2=A0=C2=A0 restrictions on code points har= d to implement.=C2=A0 As a result Endpoints
=C2=A0=C2=A0 MAY treat negot= iation of key sizes smaller than the lower limits as a
=C2=A0=C2=A0 conn= ection error of type insufficient_security(71) for TLS1.2 and
=C2=A0=C2= =A0 TLS1.3.





On Mon, Oct 24, 2016 at 11:22 AM, Daniel Mi= gault <daniel.migault@ericsson.com> wrote:
Hi,

My understanding is that the updated version should not introd= uce any profile. Am I correct ?

BR,
Daniel

On Mon, Oct 17, 2016 at 1:16 PM, Daniel Migault <daniel.migault@ericsson.com> wrote:
Hi,

I am no= t very clear on how to update the text of the draft. The problem seems to m= e that code point restriction are hard to implement. As a result, the sessi= on is aborted with - insufficient_security(71) or equivalent - when the cod= e 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 rel= ated to cryptographic recommendation. What would be the most appropriated w= ay to move forward ?

BR,
Daniel


On Sun, Oct 9, 2016 at 2:59 AM, John Mattsson &l= t;john.matt= sson@ericsson.com> wrote:
H= i 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 s= izes
smaller than the lower limits as a connection error (Section 5.4.1
<https://tools.ietf.org/html/rfc7540#sectio= n-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=E2=80=99s TLS and DTLS profiles is simply to forbid=
support of anything weaker than 2048 MODP and 255-bit ECC).

[0]. https://mailarchive.ietf.o= rg/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<= br>
behalf of dharkins@lounge.org> wrote:=

>
>=C2=A0 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 RFC= s 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= 9;s not been
>> an explicit minimum for curve bits.=C2=A0 There have however been = similar (at
>> least in my non-cryptographer mind) for RSA key sizes so if we wan= ted to
>> define an explicit minimum curve bits then we could.
>
>=C2=A0 draft-ietf-tls-pwd-07 includes a RECOMMENDED practice of ensurin= g
>the curves used provide commensurate strength with the ciphersuite
>negotiated. Section 10, "Implementation Considerations", says= :
>
>=C2=A0 =C2=A0It is RECOMMENDED that implementations take note of the st= rength
>=C2=A0 =C2=A0estimates of particular groups and to select a ciphersuite= providing
>=C2=A0 =C2=A0commensurate security with its hash and encryption algorit= hms.=C2=A0 A
>=C2=A0 =C2=A0ciphersuite whose encryption algorithm has a keylength les= s than the
>=C2=A0 =C2=A0strength estimate, or whose hash algorithm has a blocksize= that is
>=C2=A0 =C2=A0less than twice the strength estimate SHOULD NOT be used.<= br> >
>=C2=A0 And I would like to take this opportunity to remind everyone tha= t
>the only difference between TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256<= br> >and TLS_ECCPWD_WITH_AES_128_GCM_SHA256 is that the latter is resis= tant
>to dictionary attack and the former is not.
>
>=C2=A0 regards,
>
>=C2=A0 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



--001a113ff17ca8e80b0540c17810--