Subject: Re: [TLS] Missing cipher: anon ephemeral ECDH w/ SHA-2 nor AEAD modes

From: Peter Gutmann <[email-masked]>
Date: Mon, 25 Mar 2013 04:59:00 +0000

Martin Rex <[email-masked]> writes:

>One of the problem is, that with some SSL Stacks, authentication of the
>server is performed in an event-based callback fashion on receipt of the
>Server Certfiicate handshake message.
>
>Myself, I haven't used any such implementation, but I would not be surprised
>if, when an anon cipher suite is enabled and used, there simply wouldn't be
>any callback performed, and the application caller typically wouldn't care,
>and the user would silently assume that authentication happend, because he
>was not shown an error.

There's a (reasonably) widely-deployed implementation that reports successful
cert verification if an anon or NULL suite is used (!!).  Both are enabled by
default, this was discovered by chance by some implementers who carefully
checked that the cert the other side presented had verified, for some reason
the other enabled use of a NULL suite and the implementation happily completed
the handshake with a NULL suite while reporting that everything was OK and the
certificate had verified.

Having said that:

>Myself, I haven't used any such implementation, but I would not be surprised
>if, when an anon cipher suite is enabled and used, there simply wouldn't be
>any callback performed

... as opposed to implementation where a callback does happen and the
developers hardcode it to 'return true' because certificate verification is
hard (too many cases of this to enumerate, see the CCS'12 papers on cert-
verification problems in apps for some examples).

Peter.

---

From: Nico Williams <[email-masked]>
Date: Mon, 25 Mar 2013 11:46:43 -0500

One of the applications where use of anon DH suites is useful is
Postfix, and, really, all MTAs.  *Eventually* we'll have a world where
DANE has been widely (and properly) deployed, and then we can use that
an no anon DH suites.  In the meantime, the ability to negotiate an
anon DH cipher suite obtains a) protection from passive attackers
(which, well, whatever, in this day and age of NSLs and such), and b)
decent integrity protection relative to plain transmission errors.

In the world of e-mail hop-by-hop authentication has much lower
priority than delivery, and if you want end-to-end authentication then
you'll layer that on top (either PGP or S/MIME, or settle for DKIM).
But we should still want to be able to upgrade to stronger hop-by-hop
security some day, and starting with being able to do TLS in *all*
MTA<->MTA connections helps us get there.

I will submit an I-D shortly.  I will assume that the missing
ciphersuites are missing due to oversight.

Nico
--