[Cfrg] UTA: Request for advice on ciphersuite recommendations
Alyssa Rowan <akr@akr.io> Mon, 06 January 2014 21:50 UTC
Return-Path: <akr@akr.io>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16AB51AE276 for <cfrg@ietfa.amsl.com>; Mon, 6 Jan 2014 13:50:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 i_cL7TgGF7Di for <cfrg@ietfa.amsl.com>; Mon, 6 Jan 2014 13:50:12 -0800 (PST)
Received: from entima.net (entima.net [78.129.143.175]) by ietfa.amsl.com (Postfix) with ESMTP id 4B7B61AE259 for <cfrg@irtf.org>; Mon, 6 Jan 2014 13:50:12 -0800 (PST)
Received: from [10.10.42.10] (cpc5-derb12-2-0-cust796.8-3.cable.virginm.net [82.31.91.29]) by entima.net (Postfix) with ESMTPSA id 123F6602C5; Mon, 6 Jan 2014 21:50:03 +0000 (GMT)
Message-ID: <52CB2512.8060301@akr.io>
Date: Mon, 06 Jan 2014 21:50:10 +0000
From: Alyssa Rowan <akr@akr.io>
MIME-Version: 1.0
To: cfrg@irtf.org, uta@ietf.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Subject: [Cfrg] UTA: Request for advice on ciphersuite recommendations
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 Jan 2014 21:50:15 -0000
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 In light of the events of last year, and weaknesses in common configurations of TLS, the new UTA¹ Working Group is currently considering draft Best Current Practice recommendations for practical, secure configurations of TLS clients and servers. In practice, this is a careful balancing act, particularly in the ciphersuite and version recommendations, between security and interoperability (particularly given known and suspected application of cryptanalytic advances, protocol-related and trust-model attacks, and the complex behaviour of legacy clients, servers and intermediaries). I would like to raise the following questions for comment, in the hope that this might assist the process: 1. Where AES-128 and AES-256 are both candidates for the block cipher in use: which is preferable, and to what actual degree? The current top preference is TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256. Do you have any comments as to preference, given their relative performance and security, and given the relative strength of other common TLS elements (key sizes/formats, block cipher mode, etc)? 2. For continued interoperability with legacy SSLv3 clients/servers, some implementers and configurations may still want a 'fallback' for unfortunate situations where even TLS_RSA_WITH_AES_128_CBC_SHA is not mutually-available. The few remaining options available are, unfortunately, both awful: • TLS_RSA_WITH_3DES_EDE_CBC_SHA • TLS_RSA_WITH_RC4_128_SHA Advice is sought on which is the least awful out of these two, given the known and speculated attacks (particularly the potential for active 'BEAST', etc attacks, versus passive pervasive surveillance). (Current opinion² is that RC4 should be entirely prohibited if it is at all practical to do so, as it has a number of known flaws now. Unfortunately, due to legacy advice favouring avoidance of the BEAST attack, keeping RC4 around may cause legacy configurations to choose RC4 even when AES is available.) 3. We may need to provide specific advice in the BCP about the actual risks of choosing to allow any such 'fallback', given that an active adversary could, at present, force a protocol/ciphersuite downgrade. (The TLS WG is drafting a potential remedy to this, but that of course awaits deployment.) How bad are the 'fallback' ciphersuites above thought to be, versus TLS_RSA_WITH_AES_128_CBC_SHA? 4. ECDHE suites are being considered as first preference for providing forward security (and for potential ECDSA certificate support, although this appears extremely rarely in the wild at present). The common subset of curves which are very widely-implemented is small, and currently appears to be two of the NIST/SEC curves: • secp256r1 (aka prime256v1); and, • secp384r1. Does anyone have any comments regarding these? Are both thought to be suitable for this use, as widely implemented, for the time being, given current knowledge, or are either thought to be unsuitable? Similarly, are there any comments regarding brainpoolp256r1? 6. For certificates, the current draft recommends 2048-bit RSA with SHA-256 signatures³, and, similarly, 2048-bit Diffie-Hellman key exchange where practical and where ECDHE is not available. Are there any comments on these recommendations? Both qualitative and quantitative advice is welcomed, based on the current known state-of-the-art, known or speculated nation state adversary capabilities, and being as forward-looking as it is possible to be - although, of course, I appreciate no-one has a crystal ball! Your input would be warmly appreciated. ___ 1. Using TLS in Applications <https://datatracker.ietf.org/wg/uta/charter/> 2. <https://tools.ietf.org/html/draft-popov-tls-prohibiting-rc4-01> 3. As in CAB-Baseline <https://www.cabforum.org/documents.html> - -- /akr -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJSyyUSAAoJEOyEjtkWi2t6bYYP/A/SIFzHFXcTRMtOXY0WVEDq Tvnj5QHIYf7EyEQLku5kEzQOiwPYEGIM6/qfwedbGx6HcJ7CdGzCpM1DuurYmzuI 5+C06r5qSZW1b6GksZWblu7y8bmydOcr5uiEvxbqt/lENAAmymp6/OVrqXCWWCqH a7c0OgAWX1U8GG4cdHzfX05rYKUZu/mhap6brQIHpyIafvVplUiKGw+fvxU+6+Ie I7cAQm4qktLJYN3KASIq/DntTlFo58xzmB6rVuRvl+IaSD17b9GFU2opfIRAErah PSd3+6/Jp7Nun334AhUT/N0sNspmlcHW6xbSiJX5IUS7boB639hrpay4JQPWzgLr wBYMcRBf1rGEBsTYFruhncwpUHCg0HrJIjIVrdTUs57M1wLdvYq/y67G64sE3KxI ioAvCdlBnIPPqWnw4ICbpflnF/PM4wzbjuo1ymHyipeTWsv5NfzmhWMt46pGWn8o 659hQ0epzrrupHjutabwJzTUED7INUPeYrAeiwhbLVAeXQ5PXelgwM5faigzo5on iLB8WJFHIx3Z2RgM3Jzpzdan3tBPVQw4WUWKVGdSwJgYSGIeuG/bKUpU3fpA/BQ6 9nD6SwQVO7b0YITauPLaA8cb9oB+9+I/4P1IOGZf5bWFib0zxxGnHRvVhNipK492 0HyIuyQt29oeCAfezeAc =syDT -----END PGP SIGNATURE-----
- [Cfrg] UTA: Request for advice on ciphersuite rec… Alyssa Rowan