[Cfrg] UTA: Request for advice on ciphersuite recommendations

[Alyssa Rowan <[e-mail]>]

-----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-----