Re: [TLS] Last call comments and WG Chair review of draft-ietf-tls-ecdhe-psk-aead

Joseph Salowey <joe@salowey.net> Fri, 28 April 2017 22:44 UTC

Return-Path: <joe@salowey.net>
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 9AAAA12941A for <tls@ietfa.amsl.com>; Fri, 28 Apr 2017 15:44:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=salowey-net.20150623.gappssmtp.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 OPax64oWBoFe for <tls@ietfa.amsl.com>; Fri, 28 Apr 2017 15:44:54 -0700 (PDT)
Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::22b]) (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 4489F1293FD for <tls@ietf.org>; Fri, 28 Apr 2017 15:42:04 -0700 (PDT)
Received: by mail-pf0-x22b.google.com with SMTP id e64so17040504pfd.1 for <tls@ietf.org>; Fri, 28 Apr 2017 15:42:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xy6mZIqOBY8NBl2tUJVqCwmTMsoRvfjEAszg8vYMrnE=; b=IyBXzL6eH5VZQOHQ0sz0jO+nSvImTt5WbntlUugElE3vX5+20QOiX811CLcYj40Y5g z4mUZZJNR8l2hDc2mbP7TH4syLAKFMDHTr3jZ0NYbqIB39qtxX5eTqs2UJ9ubFg27EG9 2PrjkXZ0eHyAe00wd47ZOMhUZ3JWpY2THsKQJtoYH6VzGvefJarE2ynx+izi233Rmj/b gK9bcW3866G2Jj9afdbBOtg0f8pPeS7zrd0iPidWxhx7dcIw9xiAzrYWs2d/9y6jQEDo n6ItYYKPtT8imTCGNOO8OVHyVzbm2jVJs19U6U6IiL65JulWRZ62XuVuwXstHq8ag3+z yn2Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xy6mZIqOBY8NBl2tUJVqCwmTMsoRvfjEAszg8vYMrnE=; b=lErKYrfFXf0670GSKDsf5uldDOexexBB8tikgGo5z1JrbRuC+hOeq4Iv/d2Uf/NKzx YFRXm8fSGoaiUShp8XDXG5cKnmXj9ytpMUb4G7jurLXGEK6sqQT+g/VQgHix1GQ/M6tL VeG9uTC7MiafGzP2MHBEWoGTBJ7VQOnpgqzb0vbW8wrOv/1xkvBWj7NtghGtkYbk8iKx TXjIWpHwgsrLfAH7X8TdaIGRCo04xk71uK7K5PU77UZ7AJ82xTbg4HGydAit2WtMnxv5 81tp4cUdvCub7H9ytVZwuzrFuEQuAKkLj7x3hkwGgyT0VukDaSC0jx7Ch9vLGx3xcBdm 6sUQ==
X-Gm-Message-State: AN3rC/4HC0C4iVCuCH6Jz1cg3KB/TgVCvfpmyeX0nMCLCfpt5TAYq7DO JQ5J7r7yks9OEyQgKd+vtpmYeA3wFA==
X-Received: by 10.98.194.69 with SMTP id l66mr14742810pfg.55.1493419323687; Fri, 28 Apr 2017 15:42:03 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.140.201 with HTTP; Fri, 28 Apr 2017 15:41:43 -0700 (PDT)
In-Reply-To: <CAOgPGoCoiVjpMgyBkW7HqFgW+aEDK5PyMWC+02eTpuX8ikSBkA@mail.gmail.com>
References: <CAOgPGoA0tTmwkcC3CPdgUd=6QNTpTxRT8pkXLD-Yezzh05b+KA@mail.gmail.com> <CADZyTkm4YnrTFwLJcf3Zw2XxKBO0wBuyqQ0c_MqWZVjPE-zUdw@mail.gmail.com> <CAOgPGoCoiVjpMgyBkW7HqFgW+aEDK5PyMWC+02eTpuX8ikSBkA@mail.gmail.com>
From: Joseph Salowey <joe@salowey.net>
Date: Fri, 28 Apr 2017 15:41:43 -0700
Message-ID: <CAOgPGoD7Q+o73FDZ7FTUad-jJ8q8bn=i2v9QfL=1H0ceRgLSLg@mail.gmail.com>
To: "tls@ietf.org" <tls@ietf.org>
Cc: draft-ietf-tls-ecdhe-psk-aead@tools.ietf.org
Content-Type: multipart/alternative; boundary=94eb2c0a43504a1afa054e41c8ff
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/AI3trhMnAnCTV6bhHGFCZmcktxg>
Subject: Re: [TLS] Last call comments and WG Chair review of draft-ietf-tls-ecdhe-psk-aead
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
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: Fri, 28 Apr 2017 22:44:58 -0000

The chairs are forwarding this document to our AD to progress towards
publication.

Cheers,

Joe

On Tue, Apr 11, 2017 at 8:21 AM, Joseph Salowey <joe@salowey.net> wrote:

> Hi Daniel,
>
> Please submit a revised draft with the changes below.
>
> Thanks,
>
> Joe
>
>
> On Tue, Mar 21, 2017 at 11:08 AM, Daniel Migault <
> daniel.migault@ericsson.com> wrote:
>
>> Hi,
>>
>> Thank you for the review and comments received. Given the discussion our
>> understanding was that the consensus was to remove CCM-256 so that suites
>> defined by the document apply both for TLS1.2 as well as for TLS1.3. The
>> draft available on github [1
>> <https://github.com/mglt/draft-ietf-tls-ecdhe-psk-aead/blob/master/draft-ietf-tls-ecdhe-psk-aead>]
>> has been updated as follows:
>>
>>
>> 1.  Why does TLS_ECDHE_PSK_WITH_AES_256_CCM_8_SHA256 use SHA256 instead
>> of SHA384 like the other 256 bit cipher suites? (From Russ Housley)
>>
>> MGLT: This was a mistake in the IANA section. The cypher suite was
>> correct in the remaining text. However, the current version does not
>> consider anymore CCM-256* which also solves this issue.
>>
>> 2.  Since the security considerations mention passwords (human chosen
>> secrets) it should mention dictionary attacks. (From Russ Housley)
>>
>> MGLT: The issue of human chosen passwords and dictionary attacks has been
>> mentioned in the security consideration with the following text:
>>
>> """
>>    Use of Pre-Shared Keys of limited entropy may allow an active
>>    attacker attempts to connect to the server and tries different keys.
>>    For example, limited entropy may be provided by using short PSK in
>>    which case an attacker may perform a brute-force attack.  Other
>>    example includes the use of a PSK chosen by a human and thus may be
>>    exposed to dictionary attacks.
>> """
>>
>>
>> 3.  Section 2 and 3 of the document contains more detail about TLS 1.3
>> than necessary.
>>
>> Section 2: This document only defines cipher suites for TLS 1.2, not TLS
>> 1.2 or later.  A subset of equivalent cipher suites is defined in the TLS
>> 1.3 specification.
>>
>> MGLT: CCM-256 has been removed from the specification so that suites can
>> be defined for TLS 1.2 as well as TLS1.3. The following text is considered.
>>
>> """
>>    This document defines new cipher suites that provide Pre-Shared Key
>>    (PSK) authentication, Perfect Forward Secrecy (PFS), and
>>    Authenticated Encryption with Associated Data (AEAD).  The cipher
>>    suites are defined for version 1.2 of the Transport Layer Security
>>    (TLS) [RFC5246] protocol, version 1.2 of the Datagram Transport Layer
>>    Security (DTLS) protocol [RFC6347], as well as version 1.3 of TLS
>>    [I-D.ietf-tls-tls13].
>> """
>>
>> Section 3 and 4: Maybe replace the last 2 paragraphs with an addition to
>> section 4 that states:
>>
>> "TLS 1.3 and above name, negotiate and support a subset of these cipher
>> suites in a different way."  (TLS 1.3 does not support
>> TLS_ECDHE_PSK_WITH_AES_256_CCM_SHA384 and TLS_ECDHE_PSK_WITH_AES_256_CCM
>> _8_SHA256)
>>
>> MGLT: As CCM-256 has been removed, we do not have to deal with the
>> situation where TLS1.3 only considers a subset of the suites defined for
>> TLS1.2.
>>
>> The following sentence in section 3 clarifies that codes points are only
>> defined for TLS1.2: “””The assigned code points can only be used for TLS
>> 1.2.”””. The description of the TLS1.3 negotiation has been limited in
>> section 4 to the following sentence: “””TLS 1.3 and above version,
>> negotiate and support these cipher suites in a different way.”””
>>
>> 4. Section 3 should contain a bit more detail about relationship to 4492
>> bis and RFC 4279:
>>
>> Something like the following may be enough.
>>
>> "This messages and pre-master secret construction in this document are
>> based on [RFC4279].  The elliptic curve parameters used in in the
>> Diffie-Hellman parameters are negotiated using extensions defined in
>> [4492-bis]."
>>
>> MGLT: The sentence mentioned above has been added with [4492-bis]
>> mentioned as normative.
>> “””
>>     Messages and pre-master secret construction in this document are
>>    based on [RFC4279].  The elliptic curve parameters used in in the
>>    Diffie-Hellman parameters are negotiated using extensions defined in
>>    [I-D.ietf-tls-rfc4492bis].
>> “””
>>
>> [1] https://github.com/mglt/draft-ietf-tls-ecdhe-psk-aead/blob/m
>> aster/draft-ietf-tls-ecdhe-psk-aead
>>
>> Yours,
>> Daniel and John
>>
>>
>> On Tue, Feb 21, 2017 at 1:22 PM, Joseph Salowey <joe@salowey.net> wrote:
>>
>>> Here are the open issues for draft-ietf-tls-ecdhe-psk-aead
>>>
>>> 1.  Why does TLS_ECDHE_PSK_WITH_AES_256_CCM_8_SHA256 use SHA256 instead
>>> of SHA384 like the other 256 bit cipher suites? (From Russ Housley)
>>>
>>> 2.  Since the security considerations mention passwords (human chosen
>>> secrets) it should mention dictionary attacks. (From Russ Housley)
>>>
>>> 3.  Section 2 and 3 of the document contains more detail about TLS 1.3
>>> than necessary.
>>>
>>> Section 2: This document only defines cipher suites for TLS 1.2, not TLS
>>> 1.2 or later.  A subset of equivalent cipher suites is defined in the TLS
>>> 1.3 specification.
>>>
>>> Section 3 and 4: Maybe replace the last 2 paragraphs with an addition to
>>> section 4 that states:
>>>
>>> "TLS 1.3 and above name, negotiate and support a subset of these cipher
>>> suites in a different way."  (TLS 1.3 does not support
>>> TLS_ECDHE_PSK_WITH_AES_256_CCM_SHA384 and TLS_ECDHE_PSK_WITH_AES_256
>>> _CCM_8_SHA256)
>>>
>>> 4. Section 3 should contain a bit more detail about relationship to 4492
>>> bis and RFC 4279:
>>>
>>> Something like the following may be enough.
>>>
>>> "This messages and pre-master secret construction in this document are
>>> based on [RFC4279].  The elliptic curve parameters used in in the
>>> Diffie-Hellman parameters are negotiated using extensions defined in
>>> [4492-bis]."
>>>
>>> Thanks,
>>>
>>> Joe
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> TLS mailing list
>>> TLS@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tls
>>>
>>>
>>
>