[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 []) 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-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 ([]) by localhost (ietfa.amsl.com []) (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 []) by ietfa.amsl.com (Postfix) with ESMTP id 4B7B61AE259 for <cfrg@irtf.org>; Mon, 6 Jan 2014 13:50:12 -0800 (PST)
Received: from [] (cpc5-derb12-2-0-cust796.8-3.cable.virginm.net []) 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

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:


   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

2. <https://tools.ietf.org/html/draft-popov-tls-prohibiting-rc4-01>

3. As in CAB-Baseline <https://www.cabforum.org/documents.html>

- --