Re: [TLS] WGLC for draft-ietf-tls-rfc4492bis

John Mattsson <john.mattsson@ericsson.com> Wed, 23 November 2016 10:15 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 1B105129BE8 for <tls@ietfa.amsl.com>; Wed, 23 Nov 2016 02:15:12 -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 JB_KLCBRdz_r for <tls@ietfa.amsl.com>; Wed, 23 Nov 2016 02:15:10 -0800 (PST)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 21519129BE3 for <tls@ietf.org>; Wed, 23 Nov 2016 02:15:09 -0800 (PST)
X-AuditID: c1b4fb3a-d644398000007918-f0-58356c2c190e
Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by (Symantec Mail Security) with SMTP id 4B.5A.31000.C2C65385; Wed, 23 Nov 2016 11:15:08 +0100 (CET)
Received: from ESESSMB307.ericsson.se ([169.254.7.62]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0319.002; Wed, 23 Nov 2016 11:15:06 +0100
From: John Mattsson <john.mattsson@ericsson.com>
To: Sean Turner <sean@sn3rd.com>, "<tls@ietf.org>" <tls@ietf.org>
Thread-Topic: [TLS] WGLC for draft-ietf-tls-rfc4492bis
Thread-Index: AQHSQh6ZBtLjySIXQkGGsA9kkiXhRqDmYMOA
Date: Wed, 23 Nov 2016 10:15:06 +0000
Message-ID: <D45B2A10.55949%john.mattsson@ericsson.com>
References: <62B88142-2DBE-439F-AD4A-309053925794@sn3rd.com>
In-Reply-To: <62B88142-2DBE-439F-AD4A-309053925794@sn3rd.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.20]
Content-Type: text/plain; charset="utf-8"
Content-ID: <875A82C46116B044A948F35966232B4F@ericsson.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnkeLIzCtJLcpLzFFi42KZGbFdV1cnxzTC4OcBIYsrqxqZLT6d72J0 YPJYsuQnk8fBg4wBTFFcNimpOZllqUX6dglcGX/udDEVzFOv2PmPpYFxjloXIyeHhICJxLRV L1m7GLk4hATWMUosX7mFHcJZzCgx5fFeRpAqNgEDibl7GthAbBEBR4ljtyeA2cICphKfXvWx QsTNJDZtnQvUzAFkG0ls22oDEmYRUJX4d303O4jNK2Au8W72VbCRQgI2Ep27loDFOQVsJSav P8cEYjMKiEl8P7UGzGYWEJe49WQ+E8ShAhJL9pxnhrBFJV4+/scKskpUQE9izf0wiLCixNXp y5lAwswCmhLrd+lDTLGW2Pb2IguErSgxpfsh1DWCEidnPmGZwCg2C8myWQjds5B0z0LSPQtJ 9wJG1lWMosWpxcW56UZGeqlFmcnFxfl5enmpJZsYgdF0cMtvqx2MB587HmIU4GBU4uEtiDWJ EGJNLCuuzD3EKMHBrCTC65htGiHEm5JYWZValB9fVJqTWnyIUZqDRUmc12zl/XAhgfTEktTs 1NSC1CKYLBMHp1QDY0RqV2iv7IRPu1dzKUUe9bU2bp72jE3kaMXMk0/5mjMzhZ5vfSHGeUNh ybrzmyWm34tnXxVv53opnn3bMoXrHpMPzrPXnjbhsn/l/g2PZn5/W7ixbl/H5DvRXZL/Uqe0 f+puerlk4oevP+KyolbeeGN3iNUySZXJoXrVb3aTeQcKtjjP9r4Ut1CJpTgj0VCLuag4EQBt WWPEogIAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/odTdEusa6OiDNL_Ti-nzU9bOwMs>
Subject: Re: [TLS] WGLC for draft-ietf-tls-rfc4492bis
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: Wed, 23 Nov 2016 10:15:12 -0000

I have not read the processing parts in detail. Here are comments on the
first and last sections of the document.

Cheers,
John

- Somewhere
I suggest adding the following sentence from TLS 1.3:
"Applications SHOULD also enforce minimum and maximum key sizes.  For
example, certification paths containing keys or signatures weaker than
2048-bit RSA or 224-bit ECC are not appropriate for secure applications."

This is as true for TLS 1.0, 1.1, and 1.2 as for TLS 1.3

- Section 1
"Compared to currently prevalent cryptosystems such as RSA, ECC offers"

I think this should be updated, ECDHE is already very well-spread.

- Section 1
"This is illustrated in the following table, based on [Lenstra_Verheul],
which gives approximate comparable key sizes for symmetric- and
asymmetric-key cryptosystems based on the best-known algorithms for
attacking them."

The key sizes for DH/DSA/RSA does not seem to be based on the
Lenstra-Verheuls equations which gives much higher key sizes for
DH/DSA/RSA.

The DH/DSA/RSA key sizes seem to be based on NIST recommendations. I
suggest either:

A) Fully based the table on NIST recommendation, which means keeping
DH/DSA/RSA as is but simplifying ECC to 2 * Symmetric.
B) Update the DH/DSA/RSA key sizes based on state-of-the-art. But then I
would say that this is not [Lenstra_Verheul], but rather [RFC3766],
[Lenstra 2004], [ECRYPT 2012]. I think these three all use the same
equation.
C) Just remove DH/DSA/RSA as the draft is about ECC.

- Section 2
"However, the computational cost incurred by a server is higher for
ECDHE_RSA than for the traditional RSA key exchange, which does not
provide forward secrecy."

True, but I think it gives the wrong impression. I think the additional
cost is negligible. I don't have any TLS benchmarks but for i5-6600,
bench.cr.yp.to gives:

ronald3072 decrypt  8776864 cycles

ronald3072 sign     8781842 cycles
curve25519 keygen    163200 cycles
curve25519 compute   165816 cycles

That's only 3.8% overhead for crypto, and much less if calculated for the
whole handshake. I suggest removing the sentence, or writing that the
additional server cost for forward secrecy is negligible and well worth it.

- Section 6
"TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256"

Should this be "TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256"?
I don't think the document should recommend support of cipher suites
without forward secrecy.

- Section 7
"documemts" -> "documents"

- Section 7
"NEED TO ADD A PARAGRAPH HERE ABOUT WHY X25519/X448 ARE PREFERRABLE TO
NIST CURVES."

I suggest using the excellent explanation in RFC7748 as a basis.
Suggestion:

"Modern curves such X25519 and X448 [RFC7748] are preferable as they lend
themselves to constant-time implementation and an exception-free scalar
multiplication that is resistant to a wide range of side-channel attacks,
including timing and cache attacks. For more information see [SafeCurves]."

[SafeCurves]  https://safecurves.cr.yp.to/

- Section 7
"Substantial additional information on elliptic curve choice can be found
in [IEEE.P1363.1998], [ANSI.X9-62.2005], and [FIPS.186-4]".

I think it is better to refer people to [SafeCurves].

- Section 7
The paragraph about structure gives the impression that "F_p with p
random" is the optimal choice. I think this should be expanded with more
information explaining why we do not recommend random curves.

1) That random curves are hard to protect against side-channel attacks.
2) Non-random curves are significantly faster, so that for a fixed number
of operations, p can be much larger for non-random curves.