Subject: [TLS] Adam Roach's No Objection on draft-ietf-tls-ecdhe-psk-aead-04: (with COMMENT)

From: Adam Roach <[email-masked]>
Date: Tue, 23 May 2017 12:21:48 -0700

Adam Roach has entered the following ballot position for
draft-ietf-tls-ecdhe-psk-aead-04: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-psk-aead/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I agree with EKR's discuss -- specifying semantics for these ciphersuites
with TLS 1.0 and 1.1 is a material change, and the proposed mechanism (in
which servers are encouraged to infer 1.2 support even in the absence of
explicit indication) is a bit baffling.

Given the scope this document covers, I recommend adding "1.2" to the
title of the document. (e.g.: "ECDHE_PSK with AES-GCM and AES-CCM Cipher
Suites for Transport Layer Security Version 1.2 (TLS 1.2)")

---

From: [email-masked] (Martin Rex)
Date: Tue, 23 May 2017 21:34:53 +0200 (CEST)

> draft-ietf-tls-ecdhe-psk-aead-04: No Objection

It encourages (but does not require) servers to infer 1.2 support
from _very_explicit_ information: the offering of TLSv1.2-only TLS
ciphersuites is the very same TLS ClientHello handshake message.

We know since rfc5746 that the most reliable scheme to indicate support
for certain TLS protocol features is a cipher suite value.  It is far
from rocket science to infer support for 1.2 from 1.2-only cipher
suite codepoints in ClientHello.cipher_suites.

I just realized that I suggested removal of a description of client
behaviour that can, and should remain in the document (I'm sorry):

                    A client MUST treat the selection of these cipher
  suites in combination with a version of TLS that does not support
  AEAD (i.e., TLS 1.1 or earlier) as an error and generate a fatal
  'illegal_parameter' TLS alert.

-Martin

---

From: Daniel Migault <[email-masked]>
Date: Tue, 23 May 2017 18:04:15 -0400

Hi,

So I have propose a fall back to the latest version. However, if we agree
this is a better approach, I am fine adding it to the document.

Yours,
Daniel

---

From: Martin Thomson <[email-masked]>
Date: Wed, 24 May 2017 10:10:58 +1000

> this is a better approach, I am fine adding it to the document.

Not sure what you mean by this.  If you mean removing the offending
paragraph, that seems best.

It's OK for these suites to be 1.2 only.

---

From: Daniel Migault <[email-masked]>
Date: Tue, 23 May 2017 21:33:23 -0500

Hi Martin,

The current version does not consider that proposing the cipher suites of
the document implicitly assumes the client supports TLS1.2. However, if
people think there is an advantage of adding this I am fine this being
discussed and  added in the next versions.

Yours,
Daniel

---

From: Adam Roach <[email-masked]>
Date: Tue, 23 May 2017 21:48:09 -0500

On 5/23/17 9:33 PM, Daniel Migault wrote:
> The current version does not consider that proposing the cipher suites 
> of the document implicitly assumes the client supports TLS1.2.

Really? Can you clarify the meaning of the following passage? Because I 
can't read it in any way other than to contradict your assertion above:

    A server receiving a ClientHello and a client_version indicating
    (3,1) "TLS 1.0" or (3,2) "TLS 1.1" and any of the cipher suites from
    this document in ClientHello.cipher_suites can safely assume that the
    client supports TLS 1.2 and is willing to use it.

/a

---

From: Daniel Migault <[email-masked]>
Date: Wed, 24 May 2017 08:39:07 -0400

Hi Adam,

The text you mention is from version 04. Version 05 has been submitted, but
is somewhere in the datatracker. For some reason I am not able to confirm
the submission, so I have attached it to my response to Eric. The text of
the current version 05 is:

Yours,
Daniel
"""
4.     Applicable TLS Versions

   The cipher suites defined in this document MUST NOT be negotiated for
   any version of (D)TLS other than TLS 1.2.  Clients MUST NOT offer one
   of these cipher suites with a (D)TLS version that differs from TLS
   1.2.  Servers MUST NOT select one of these cipher suites with a TLS
   version that differs from TLS 1.2.  A client MUST treat the selection
   of these cipher suites in combination with a version of TLS as an
   error and generate a fatal 'illegal_parameter' TLS alert.

Mattsson & Migault      Expires November 24, 2017               [Page 3]
^L
Internet-Draft               ECDHE_PSK_AEAD                     May 2017

   TLS version 1.3 and later negotiate these features in a different
   manner.  Unlike TLS 1.2, TLS 1.3 separates authentication and cipher
   suite negotiation [I-D.ietf-tls-tls13] Section 1.2.  TLS 1.3 supports
   PSK with ECDHE key exchange and the cipher suites
   TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384,
   TLS_AES_128_CCM_8_SHA256 and TLS_AES_128_CCM_SHA256 are part of the
   specification.  As a result, TLS 1.3 and higher versions, negotiate
   and support these cipher suites in a different way.

   The cipher suites defined in this document make use of the
   authenticated encryption with additional data (AEAD) defined in TLS
   1.2 [RFC5246] and DTLS 1.2 [RFC6347].  Earlier versions of TLS do not
   have support for AEAD and consequently, the cipher suites defined in
   this document MUST NOT be negotiated in TLS versions prior to 1.2.
   In addition, it is worth noting that TLS 1.0 [RFC2246] and TLS 1.2
   [RFC4346] split the pre-master into two parts.  The PRF results from
   mixing the two pseudorandom streams with distinct hash functions (MD5
   and SHA-1) by exclusive-ORing them together.  In the case of
   ECDHE_PSK authentication, the PSK and ECDHE shared secret are treated
   by distinct hash function with distinct properties.  This may
   introduce vulnerabilities over the expected security provided by the
   constructed pre-master.  As such, all ECDHE_PSK ciphers, including
   those defined in this document, SHOULD NOT be negotiated in TLS
   versions prior to 1.2.
"""

On Tue, May 23, 2017 at 10:48 PM, Adam Roach <[email-masked]> wrote:

>> the document implicitly assumes the client supports TLS1.2.
>>
>