Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

John Mattsson <> Sat, 19 November 2016 19:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5F51B1295CF for <>; Sat, 19 Nov 2016 11:40:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id L0BbCM8zvl5t for <>; Sat, 19 Nov 2016 11:40:20 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4AB3E129577 for <>; Sat, 19 Nov 2016 11:40:20 -0800 (PST)
X-AuditID: c1b4fb30-96c1b98000001942-33-5830aaa2347d
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 9C.E7.06466.2AAA0385; Sat, 19 Nov 2016 20:40:18 +0100 (CET)
Received: from ([]) by ([]) with mapi id 14.03.0319.002; Sat, 19 Nov 2016 20:40:06 +0100
From: John Mattsson <>
To: "" <>
Thread-Topic: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18
Thread-Index: AQHSL/2+2v4l5+5kKUiyJ4qNLpCCr6DXocKAgAAe1ICAALIggIAI7NsA
Date: Sat, 19 Nov 2016 19:40:05 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplkeLIzCtJLcpLzFFi42KZGbFdVHfRKoMIg58btS0+ne9idGD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxr13nAVvsip+Lt3C1sDYk9HFyMkhIWAicXH5b+YuRi4OIYF1 jBLNu+4wQjiLGSWufF7GCFLFJmAgMXdPA1sXIweHiICixKfP2SBhYQE3ia0rFrCB2CIC7hL7 z25khbDdJGZN+QLWyiKgKnH06hewGl4Bc4n2fc+g5v9nlDjQv5kZJMEpYCfR8OMmWBGjgJjE 91NrmEBsZgFxiVtP5jNBXCogsWTPeWYIW1Ti5eN/rCD3iAroSay5HwYRVpJYdPszE0iYWUBT Yv0ufQjTWuLxGWGIgYoSU7ofskNcIyhxcuYTlgmMYrOQ7JqF0DwLoXkWkuZZSJoXMLKuYhQt Ti1Oyk03MtJLLcpMLi7Oz9PLSy3ZxAiMnINbfhvsYHz53PEQowAHoxIPb4G4foQQa2JZcWXu IUYJDmYlEd4zCw0ihHhTEiurUovy44tKc1KLDzFKc7AoifOarbwfLiSQnliSmp2aWpBaBJNl 4uCUamCUyfg/45qhSJz3Pwan5k170iorpU9uenuRpUrr593MIpUT8judZ0cETzKN6V0nt+A8 h2FY95UI39cVWQdnuG4zmGsTV6Dm96sjifvjtG/Znx7/vzF5Qcrj8zzFMuZnf+R36CW9FK+Q mVhUV5GYZu/LdmZawhVGUW37AxuEp76uMg5OWv765C0lluKMREMt5qLiRAAFtO4OmAIAAA==
Archived-At: <>
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18
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: Sat, 19 Nov 2016 19:40:23 -0000

WGLC comments on draft-ietf-tls-tls13-18


Very well written draft and an excellent protocol. The things I have found
is mostly
editorial. I think it’s ready. I will try to make sure that 3GPP already
next year
mandates support of both TLS 1.3 and DTLS 1.3 in all the places they use


- I cannot find any text describing the requirements TLS 1.3 put on the
lower layers. In
  fact the only text I can find is "which might be hidden by TCP". I don't
  know if the draft should mandate TCP or not, but otherwise it should be
stated that
  reliable, in-order transport is required, and that the lower layers must
  identification TLS messages in the same session (e.g. the 5-tuple when
TCP is used).

- I cannot find any text describing that TLS 1.3 outputs a stream
identical to the input
  stream. The current text only states that the input on the sender side
is application
  messages. Should state that the TLS is reliable and in-order.

- The are no requirements on the TLS API. I think the following should be
  - SHALL support an exporter API
  - SHALL support an API allowing an application to get information
regarding the negotiated
  - SHOULD support an API allowing an application to influence the
connection to be

- TLS 1.3 also updates RFC5246, but I don't know if you can both update
and obsolete.
  If you have to choose, obsolete is better.

- Section 1: This is the only place channel is used in the meaning
connection. I suggest
  "channel" -> "connection"
  as connection is used in the rest of the document.

- Section 1: "The TLS standard, however, does not specify ... how to
interpret the
  authentication certificates"

  I don't this is really true any more, the draft has significant text on
  I suggest removing "how to interpret the authentication certificates

- Figure 1, 4: "pre_shared_key_modes" -> "psk_key_exchange_modes"

- Figure 1. "Server Params" not horizontally aligned with "Key Exch" and
  (not sure if this is a feature or a bug).

- Section 2: 
- "CertificateVerify:  a signature over the entire handshake "
  "Finished :  a MAC over the entire handshake "

  Not really true. Maybe add something like "to this point"

- Section 2: The text below Figure 1 should mention
psk_key_exchange_modes. It talks
  about all other messages and extensions.

- Section 2.2: OLD "PSKs can be used with (EC)DHE exchange"
               NEW "PSKs SHOULD be used with (EC)DHE exchange"

- Section 2.3: 
  "When PSKs are provisioned out of band, the PSK identity and the KDF to
be used with
   the PSK MUST also be provisioned."
   OLD "and the KDF to be used"
   NEW "and the Hash algorithm to be used"
   I think this is a little problematic as current PSK provisioning
mechanisms do
   not provision a hash algorithm. This means that they need to be updated
   TLS 1.3 can be used. Otherwise the risk is that one endpoint uses
SHA-256 and
   the other SHA-384. To enable PSK systems to directly and easily upgrade
   TLS 1.3 I suggest the following
   "When PSKs are provisioned out of band, the PSK identity and the KDF to
be used with
   the PSK MUST also be provisioned."

   "When PSKs are provisioned out of band, the PSK identity MUST also be
provisioned and
   the Hash algorithm to be used SHOULD be provisioned. If no hash
algorithm has been
   provisioned, then SHA-256 SHALL be used."
   This would also affect 4.2.6.

- Section 2.3: "the following additional information MUST be provisioned
to both parties:

   -  The Application-Layer Protocol Negotiation (ALPN) protocol, if any
      is to be used

   -  The Server Name Indication (SNI), if any is to be used"

  I think these two bullets apply to ALL uses of TLS. Or? I suggest moving
to a general

- Section 2.3: "1.  This data is not forward secret, as it is encrypted
solely under keys
  derived using the offered PSK."

  This is true for all uses of PSK without (EC)DHE and not only Zero-RTT.
I suggest
  moving this text to another more general section. Maybe in Section 2
when the three
  basic key exchange modes are discussed.

- Section 2.3: Zero-RTT with PSK obtained out-of-band is a special case of
  Zero-RTT, with its own requirements and warnings. I think it should be
moved to its
  own subsubsection (2.3.1).

- Section 3.5: "enum { e1(v1), e2(v2), ... , en(vn) [[, (n)]] } Te;"
  The variable 'n' is used for two different purposes. Use n, m or

- Section 3.8: Same thing here. The variable 'n' is used for two different

- Section 4.0 The cases in Handshake definition in some random order.
Should keep the same
  order as the HandshakeType definition.

- Section 4.1.2 "Including a "cookie" extension if one was provided in the
  Could state that this is the HelloRetryRequest cookie echoed back.
- Section 4.1.3 I don't think ServerHello.extensions can be 0 length, but
maybe there is
  no well defined minimum length...

- Section 4.1.3
  Should state that Server.random shall be (psuedo-)random, I don't think
this is stated
  (except that the name kind of indicates it)
  OLD: "random  This structure is generated by the server and MUST be
        generated independently of the ClientHello.random.
  NEW: "random  32 bytes generated by the server. The first 24 bytes are
generated by a
       secure random number and MUST be generated independently of the

- Section 4.1.3
  OLD "as long as ephemeral ciphers are used"
  NEW "as long as ephemeral key exchange are used"

  As the ephemeral part is not part of the cipher suites anymore.

- Section 4.1.3 "It does not provide downgrade protection when static RSA
is used."
  I don't know the details of ServerKeyExchange, but it this not true for
  as well?

- Section 4.2.4
  I do not really understand why the private_use divided and resticted?
  I.e. ffdhe_private_use and ecdhe_private_use. I think it would be
preferable to just
  have "private_use" without specifying the exact use. Where do I e.g. put
my private use
  SIDH, and Lattice-based key exchange information. Feels like this is the
natural place,
  or is the intention that a new extension is required for PQC?

- Section 4.2.8
  OLD "the server MUST have accepted a PSK cipher suite"
  OLD "the server MUST have accepted a PSK key exchange mode"

- Section 5.5 "up to 2^24.5 full-size records"

  It is not well-defined on how to do with non-full-size records. I suggest
  OLD "up to 2^24.5 full-size records"
  NEW “up to 2^24.5 records"

- Section 5.5
  Limits are needed also for AES-CCM. It should also be stated that new
  defining new TLS ciphers SHALL provide lmits on the number of records
that can be
  protected with a given key.
  As far as I understand the confidentiality limits for AES-CCM (and CRT
and CBC) would
  be the same as for AES-GCM. I suggest
  OLD "For AES-GCM, up to 2^24.5 full-size records"
  NEW "For AES-GCM and AES-CCM, up to 2^24.5 records"
  These limits are quite hard, but I think that is fine as it should not
be a problem
  to rekey frequantly.
- Section 5.5 "for Authenticated Encryption (AE) security."
  I think it is better to state that this is confidentiality (in constrast
to integrity
  or key recovery). Suggestion
  OLD "for Authenticated Encryption (AE) security."
  NEW "for an confidentiality attack"

- Section 8
  The sentences "In the absence of an application profile standard
specifying otherwise"
  only apply to some parts of Section 8. E.g. it applies to cipher suites
but not to the
  diffie-hellman groups. Feels like this should apply to the whole
section. I suggest
  removing the current occurences of ""In the absence of an application
profile standard
  specifying otherwise" and add (at the start of Section 8.)

  "In the absence of an application profile standard specifying otherwise,
the following
  requirements apply".

- Section 8.1 and 8.2
  The heading says "MTI" but the text also contains non-mandatory things

  I suggest changing "MTI" to "Requirements"

- Section 8.1
  The title is "cipher suites", but the scope is broader (signatures and
  exchange). I sugegst changing the heading to
  "Requirements for cipher suites, signatures, and groups"

- Section 8.2 This section seems to forget psk_key_exchange_modes. If
pre_shared_key is
  mandatory then psk_key_exchange_modes should be to.

- Section 9: Should mention that an attacker at any point can terminate
the session by
  sending a single malformed packet. This termination feature is both
positive and

- Section 11.2: [RFC4279] is an informative reference but never referred

- Section A.4 "TLS 1.2 and lower cipher suites cannot be used with TLS
  I cannot find any text in the draft statinn that you can negotiate TLS
1.2 ciphersuites
  in TLS 1.3, I think this should be stated.
  OLD: "TLS 1.2 and lower cipher suites cannot be used with TLS 1.3."
  NEW: "TLS 1.2 and lower cipher suites cannot be used with TLS 1.3, but
can be
        negotiated in a TLS 1.3 Client Hello."

- Section D.2
  OLD "weaker than 2048-bit RSA or 224-bit ECDSA are not appropriate"
  OLD "weaker than 2048-bit RSA, 224-bit ECDSA, or 128-bit PSK are not

- Section D.2 "The reader should refer to the following references for
analysis of
  the TLS record layer."
  No references given.

MSc Engineering Physics, MSc Business Administration and Economics
Ericsson IETF Security Coordinator
Senior Researcher, Security