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:tls-boun...@ietf.org] On Behalf Of Viktor Dukhovni Sent: Tuesday, July 14, 2015 12:16 PM To: tls@ietf.org 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 TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
