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

[Andrei Popov <[e-mail]>]

Using anonymous cipher suites for opportunistic connections allows the server operator to explicitly enable anonymous connections, and it saves bytes on the wire.

The downside is of course that the attacker can easily distinguish opportunistic clients from server-authenticating ones. Is this a concern for the opportunistic TLS community?

-----Original Message-----
From: TLS [mailto:[e-mail]] On Behalf Of Viktor Dukhovni
Sent: Tuesday, July 14, 2015 12:16 PM
To: [e-mail]
Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek)

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.

_______________________________________________
TLS mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tls