Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek)

[Viktor Dukhovni <[e-mail]>]

On Tue, Jul 14, 2015 at 03:46:12PM +0200, Martin Rex wrote:

[ There's no need to belabour the obvious, yes unauthenticated TLS
  does not protect against active attacks, absent authenticated
  channel binding post handshake.  This does not mean that the are
  no appropriate use-cases for anon_DH and anon_ECDH. ]

>    https://tools.ietf.org/html/rfc2246#page-55
> 
>    The following cipher suites are used for completely anonymous
>    Diffie-Hellman communications in which neither party is
>    authenticated. Note that this mode is vulnerable to man-in-the-middle
>    attacks and is therefore deprecated.
> 
>     CipherSuite TLS_DH_anon_EXPORT_WITH_RC4_40_MD5     = { 0x00,0x17 };
>     CipherSuite TLS_DH_anon_WITH_RC4_128_MD5           = { 0x00,0x18 };
>     CipherSuite TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA  = { 0x00,0x19 };
>     CipherSuite TLS_DH_anon_WITH_DES_CBC_SHA           = { 0x00,0x1A };
>     CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA      = { 0x00,0x1B };

Which still leaves us with (sorry about the OpenSSL-specific names):

    AECDH-AES256-SHA        SSLv3 Kx=ECDH     Au=None Enc=AES(256)  Mac=SHA1
    ADH-AES256-GCM-SHA384   TLSv1.2 Kx=DH     Au=None Enc=AESGCM(256) Mac=AEAD
    ADH-AES256-SHA256       TLSv1.2 Kx=DH     Au=None Enc=AES(256)  Mac=SHA256
    ADH-AES256-SHA          SSLv3 Kx=DH       Au=None Enc=AES(256)  Mac=SHA1
    ADH-CAMELLIA256-SHA     SSLv3 Kx=DH       Au=None Enc=Camellia(256) Mac=SHA1
    AECDH-AES128-SHA        SSLv3 Kx=ECDH     Au=None Enc=AES(128)  Mac=SHA1
    ADH-AES128-GCM-SHA256   TLSv1.2 Kx=DH     Au=None Enc=AESGCM(128) Mac=AEAD
    ADH-AES128-SHA256       TLSv1.2 Kx=DH     Au=None Enc=AES(128)  Mac=SHA256
    ADH-AES128-SHA          SSLv3 Kx=DH       Au=None Enc=AES(128)  Mac=SHA1
    ADH-CAMELLIA128-SHA     SSLv3 Kx=DH       Au=None Enc=Camellia(128) Mac=SHA1
    AECDH-RC4-SHA           SSLv3 Kx=ECDH     Au=None Enc=RC4(128)  Mac=SHA1

As for "ADH" and "AECDH" being "insecure", that rather depends on
the threat model, and presumption of lack of channel binding.

For opportunistic TLS in SMTP, the threat model does not include
active attacks.  Active attackers can in any case suppress "STARTTLS",
use some random certificate (the client performs no authentication
anyway), ... Denying the client anon TLS is pointless, and loses
audit information on the server side.

    https://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-19#section-1.3
    https://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-19#section-8.2

If the recently proposed changes to cipher suite negotiation bear
fruit, perhaps there'll some day again be a reasonably complete/current
set of anon_ECDH ciphers to work with.

-- 
	Viktor.