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

Daniel Migault <daniel.migault@ericsson.com> Tue, 21 March 2017 18:08 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 68767129C71 for <tls@ietfa.amsl.com>; Tue, 21 Mar 2017 11:08:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.4
X-Spam-Level:
X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 E-U67I5DeV9v for <tls@ietfa.amsl.com>; Tue, 21 Mar 2017 11:08:22 -0700 (PDT)
Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::231]) (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 60CDE129C58 for <tls@ietf.org>; Tue, 21 Mar 2017 11:08:22 -0700 (PDT)
Received: by mail-it0-x231.google.com with SMTP id y18so13116607itc.0 for <tls@ietf.org>; Tue, 21 Mar 2017 11:08:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=Nc4Bg5qMUSy9kB6CphGIFhJySIFq1SxKclhO60/Jq+Q=; b=ENwxrTmstzREDemVvEbEaA0bzr6M8oyqiBxZeHTOp6o/8j6bVpn7nGISC1OwBo6nzY QV2bQFsWipyemJyYQzJTW6ytI5LbtKMx1yU+33PYHHY3YEzGm+4tWPJYyMAEcG18bUsy fcmT0FizsidxDxoDrJTrZ0qXHbxi6VLdrr3iZr8c9sEEBcxnsLBSrCMgABY1HSOVWS92 FiXyKBGq/yM6qKXN5Gz7G7IJ4MTRQ7vWSs4DDClVaHidezYyw4ASL3WWrAGtuzJOAZUg L+jjlywsUM99CF7S/lBDp2Gc5MKhXU6sDW5RPF4C0s2wHEFUQyqEkdhjs6qsS2yK4c7R B4XQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=Nc4Bg5qMUSy9kB6CphGIFhJySIFq1SxKclhO60/Jq+Q=; b=mf8XqbgSXqjEDOx9+M1ZhzUMVOrF0QjygHNMfeE2oGyP7IcL8WluNbIoqfPhgTSe2K H3RC9Paf2V057PfdJX5UY1hZne3sFDFVoctKnbhBN6ymg5o7O4dk4yvjsbgAbdrbjbEs xQZLZiONAIn+0CFdgWBDune+DIY3CESyU36MVRxrsBxVwPTkNik117v9mPGyWgyKyRUd uSVjt0f+CLEwSew7U/9AJPtbjQ/d3ZcHcNl//8PmnyQbtpX53804zgnwxq/BgEhGqnlz 4W9RkQTUWHSllZ6ZDeITVokwb9IGuacDrk4CYm8XMz+p/1d0sTBLa6aW7f/gnGCNy/pc ysfA==
X-Gm-Message-State: AFeK/H1m702e2/xrcL6D5AeGIdWE49XgGIyyLVsvDyNowfOJSou3vE8LpzYIZcMyYrCJlgdgRZnGLfSSsyFaVw==
X-Received: by 10.36.215.194 with SMTP id y185mr4080407itg.101.1490119701683; Tue, 21 Mar 2017 11:08:21 -0700 (PDT)
MIME-Version: 1.0
Sender: mglt.ietf@gmail.com
Received: by 10.107.35.213 with HTTP; Tue, 21 Mar 2017 11:08:20 -0700 (PDT)
In-Reply-To: <CAOgPGoA0tTmwkcC3CPdgUd=6QNTpTxRT8pkXLD-Yezzh05b+KA@mail.gmail.com>
References: <CAOgPGoA0tTmwkcC3CPdgUd=6QNTpTxRT8pkXLD-Yezzh05b+KA@mail.gmail.com>
From: Daniel Migault <daniel.migault@ericsson.com>
Date: Tue, 21 Mar 2017 14:08:20 -0400
X-Google-Sender-Auth: G69CWd6dJIulTg6TwwNJfVxeKbE
Message-ID: <CADZyTkm4YnrTFwLJcf3Zw2XxKBO0wBuyqQ0c_MqWZVjPE-zUdw@mail.gmail.com>
To: Joseph Salowey <joe@salowey.net>
Cc: "tls@ietf.org" <tls@ietf.org>, draft-ietf-tls-ecdhe-psk-aead@tools.ietf.org
Content-Type: multipart/alternative; boundary=94eb2c0afc5c7de536054b418767
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/bARidzoj_TK9cKjslQ-mZpM9tYk>
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: Tue, 21 Mar 2017 18:08:25 -0000

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/master/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
>
>