Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18
John Mattsson <john.mattsson@ericsson.com> Sun, 20 November 2016 13:10 UTC
Return-Path: <john.mattsson@ericsson.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 5106B129653 for <tls@ietfa.amsl.com>; Sun, 20 Nov 2016 05:10:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J0h_WJ2qU06n for <tls@ietfa.amsl.com>; Sun, 20 Nov 2016 05:10:52 -0800 (PST)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 560D8129501 for <TLS@ietf.org>; Sun, 20 Nov 2016 05:10:52 -0800 (PST)
X-AuditID: c1b4fb25-aefff70000007ee2-f1-5831a0d87f5f
Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by (Symantec Mail Security) with SMTP id 7F.44.32482.8D0A1385; Sun, 20 Nov 2016 14:10:50 +0100 (CET)
Received: from ESESSMB307.ericsson.se ([169.254.7.62]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0319.002; Sun, 20 Nov 2016 14:10:48 +0100
From: John Mattsson <john.mattsson@ericsson.com>
To: "TLS@ietf.org" <TLS@ietf.org>
Thread-Topic: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18
Thread-Index: AQHSL/2+2v4l5+5kKUiyJ4qNLpCCr6DXocKAgAAe1ICAALIggIAI7NsAgAElk4A=
Date: Sun, 20 Nov 2016 13:10:48 +0000
Message-ID: <D4576CA5.55787%john.mattsson@ericsson.com>
References: <CAOgPGoChDnFf-4Vxm1S021MXHhGGpTjniD6+124B7off2RzO6w@mail.gmail.com> <13C3DBCF-2609-4560-A194-1FA422BE7EEE@akamai.com> <CABcZeBMB570XtAsZbARk9gztSaX==QCz=Ky2iRH4LRfzmfqpsA@mail.gmail.com> <C20768B0-54D7-4EBE-BE7A-863900668C4E@akamai.com> <D456D4A0.55721%john.mattsson@ericsson.com>
In-Reply-To: <D456D4A0.55721%john.mattsson@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.6.9.160926
x-originating-ip: [153.88.183.149]
Content-Type: text/plain; charset="utf-8"
Content-ID: <7CCF42A1DA94AC419E574924B2AC3FDA@ericsson.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpnkeLIzCtJLcpLzFFi42KZGbFdVPfWAsMIgzlPlC0+ne9idGD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxqb1x9kL9mVXHHkd28B4J6OLkZNDQsBEYtK5JtYuRi4OIYF1 jBIrtuxkgXAWM0o8PviQHaSKTcBAYu6eBrYuRg4OEQFFiU+fs0HCwgJuEltXLGADsUUE3CX2 n93ICmH7SZy4MZsZxGYRUJW4OH0OI4jNK2Au0bdwFTPE/LVMEhM3N4MlOAUsJFZtnQnWzCgg JvH91BomEJtZQFzi1pP5TBCXCkgs2XOeGcIWlXj5+B8ryD2iAnoSa+6HQYSVJNYe3s4CEmYW 0JRYv0sfYoq1xL+TDawQtqLElG6Ir3gFBCVOznzCMoFRbBaSZbMQumch6Z6FpHsWku4FjKyr GEWLU4uTctONjPVSizKTi4vz8/TyUks2MQKj5+CW36o7GC+/cTzEKMDBqMTDW3DTIEKINbGs uDL3EKMEB7OSCO/T+YYRQrwpiZVVqUX58UWlOanFhxilOViUxHnNVt4PFxJITyxJzU5NLUgt gskycXBKNTD2zJ2cvCmgI9M3SKvg4ufqzV/5yzfrJp7z3Zn9PlTmyO9TXmuvfFx7sjT3Rp/S TuOle4S4r06WPv2/NPtDwqKer6ZbXPdc3VQcvkNhyrTz107e9fr00Y3R8evd5UmiNjcn78h8 mewS3O427YL7jPDQt7pNq7bG9n5aLL/hZuNv1czDGm9jtU6WK7EUZyQaajEXFScCAD2KpeOa AgAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/F7at20ldJATodg3flEXP4qcQjwY>
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18
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: Sun, 20 Nov 2016 13:10:55 -0000
(This is the same comments as yesterday, just resending them as my mail client turned my text into an unreadable mess, hopefully this is better). Hi, 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 (D)TLS. Cheers, John - 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 allow 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 inputstream. 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 added: - SHALL support an exporter API - SHALL support an API allowing application to get information regarding the negotiated connection. - SHOULD support an API allowing application to influence the connection to be negotiated. - 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 certificates. I suggest removing "how to interpret the authentication certificates exchanged" - Figure 1, 4: "pre_shared_key_modes" -> "psk_key_exchange_modes" - Figure 1. "Server Params" not horizontally aligned with "Key Exch" and "Auth" (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 before 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 to TLS 1.3 I suggest the following OLD "When PSKs are provisioned out of band, the PSK identity and the KDF to be used with the PSK MUST also be provisioned." NEW "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. - 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 something. - Section 3.8: Same thing here. The variable 'n' is used for two different purposes. - 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 HelloRetryRequest." 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 ClientHello.random. - 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 non-DHE PSK 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" NEW "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 specifications 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 CTR 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 frequently. - 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 occurrences 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 (SHOULD) I suggest changing "MTI" to "Requirements" - Section 8.1 The title is "cipher suites", but the scope is broader (signatures and key exchange). I suggest 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 negative. - Section 11.2: [RFC4279] is an informative reference but never referred to. - Section A.4 "TLS 1.2 and lower cipher suites cannot be used with TLS 1.3." I cannot find any text in the draft statinn that you can negotiate TLS 1.2 cipher suites 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" NEW "weaker than 2048-bit RSA, 224-bit ECDSA, or 128-bit PSK are not appropriate" - Section D.2 "The reader should refer to the following references for analysis of the TLS record layer." No references given. ------------------------------------------------------------------ JOHN MATTSSON MSc Engineering Physics, MSc Business Administration and Economics Ericsson IETF Security Coordinator Senior Researcher, Security
- [TLS] Working Group Last Call for draft-ietf-tls-… Joseph Salowey
- Re: [TLS] Working Group Last Call for draft-ietf-… Salz, Rich
- Re: [TLS] Working Group Last Call for draft-ietf-… Martin Rex
- Re: [TLS] Working Group Last Call for draft-ietf-… Ilari Liusvaara
- Re: [TLS] Working Group Last Call for draft-ietf-… Eric Rescorla
- Re: [TLS] Working Group Last Call for draft-ietf-… Martin Rex
- Re: [TLS] Working Group Last Call for draft-ietf-… Eric Rescorla
- Re: [TLS] Working Group Last Call for draft-ietf-… Martin Rex
- Re: [TLS] Working Group Last Call for draft-ietf-… Ilari Liusvaara
- Re: [TLS] Working Group Last Call for draft-ietf-… Sean Turner
- Re: [TLS] Working Group Last Call for draft-ietf-… Yoav Nir
- Re: [TLS] Working Group Last Call for draft-ietf-… Martin Rex
- Re: [TLS] Working Group Last Call for draft-ietf-… Salz, Rich
- Re: [TLS] Working Group Last Call for draft-ietf-… Watson Ladd
- Re: [TLS] Working Group Last Call for draft-ietf-… Yoav Nir
- Re: [TLS] Working Group Last Call for draft-ietf-… Martin Rex
- Re: [TLS] Working Group Last Call for draft-ietf-… Martin Rex
- Re: [TLS] Working Group Last Call for draft-ietf-… Benjamin Kaduk
- Re: [TLS] Working Group Last Call for draft-ietf-… Yoav Nir
- Re: [TLS] Working Group Last Call for draft-ietf-… Ilari Liusvaara
- Re: [TLS] Working Group Last Call for draft-ietf-… Martin Rex
- Re: [TLS] Working Group Last Call for draft-ietf-… Salz, Rich
- Re: [TLS] Working Group Last Call for draft-ietf-… Martin Rex
- Re: [TLS] Working Group Last Call for draft-ietf-… Eric Rescorla
- Re: [TLS] Working Group Last Call for draft-ietf-… Daniel Kahn Gillmor
- Re: [TLS] Working Group Last Call for draft-ietf-… Martin Rex
- Re: [TLS] Working Group Last Call for draft-ietf-… Watson Ladd
- Re: [TLS] Working Group Last Call for draft-ietf-… Martin Rex
- Re: [TLS] Working Group Last Call for draft-ietf-… Adam Langley
- Re: [TLS] Working Group Last Call for draft-ietf-… Watson Ladd
- Re: [TLS] Working Group Last Call for draft-ietf-… Benjamin Kaduk
- Re: [TLS] Working Group Last Call for draft-ietf-… Martin Rex
- Re: [TLS] Working Group Last Call for draft-ietf-… Benjamin Kaduk
- Re: [TLS] Working Group Last Call for draft-ietf-… Martin Rex
- Re: [TLS] Working Group Last Call for draft-ietf-… Benjamin Kaduk
- Re: [TLS] Working Group Last Call for draft-ietf-… Salz, Rich
- Re: [TLS] Working Group Last Call for draft-ietf-… Martin Rex
- Re: [TLS] Working Group Last Call for draft-ietf-… Peter Gutmann
- Re: [TLS] Working Group Last Call for draft-ietf-… Kaduk, Ben
- Re: [TLS] Working Group Last Call for draft-ietf-… Eric Rescorla
- Re: [TLS] Working Group Last Call for draft-ietf-… Kaduk, Ben
- Re: [TLS] Working Group Last Call for draft-ietf-… John Mattsson
- Re: [TLS] Working Group Last Call for draft-ietf-… John Mattsson
- Re: [TLS] Working Group Last Call for draft-ietf-… Yuhong Bao
- Re: [TLS] Working Group Last Call for draft-ietf-… Eric Rescorla
- Re: [TLS] Working Group Last Call for draft-ietf-… Martin Thomson