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

Daniel Migault <daniel.migault@ericsson.com> Tue, 08 November 2016 03:09 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 54F75129490 for <tls@ietfa.amsl.com>; 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 <tls@ietfa.amsl.com>; 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 <tls@ietf.org>; Mon, 7 Nov 2016 19:09:41 -0800 (PST)
Received: by mail-it0-x22f.google.com with SMTP id u205so175860630itc.0 for <tls@ietf.org>; 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: <CADZyTkmHwL=2MVQOUKwDkMur_gMiT_00Q6EY-h=zOUbfeddAOA@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>
From: Daniel Migault <daniel.migault@ericsson.com>
Date: Mon, 7 Nov 2016 22:09:40 -0500
X-Google-Sender-Auth: uBcZjmXqhl0FtHIHnUYLOFN3CTk
Message-ID: <CADZyTkm05WD_DSHFUJMtPughDQKuS2-ZwRVwuHPFdLh=tAthzA@mail.gmail.com>
To: John Mattsson <john.mattsson@ericsson.com>
Content-Type: multipart/alternative; boundary=001a113ff17ca8e80b0540c17810
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/vJEr0J94egWlcwGTA_-YJp1pWtw>
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 03:09:46 -0000

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 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-aT299BYrl
>>> BKvZs0BOQ
>>>
>>>
>>>
>>> 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
>>>
>>
>>
>