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

From: Nico Williams <[email-masked]>
Date: Wed, 20 Mar 2013 19:52:32 -0500

Note that anon cipher suites are useful for:

 - SMTP
 - apps that want to use tls-unique channel bindings

This is bad because ECDH is faster, has smaller public keys, but lacking
these cipher suites we're stuck with using either TLS_ECDH_anon w/ SHA-1
suites or TLS_DH_anon suites.

Please fix :)

Nico
--

---

From: [email-masked] (Martin Rex)
Date: Thu, 21 Mar 2013 02:06:31 +0100 (CET)

> suites or TLS_DH_anon suites.

   http://tools.ietf.org/html/rfc5246#appendix-D.3

                                          A proper implementation will
   probably not support many cipher suites.  For instance, anonymous
   Diffie-Hellman is strongly discouraged because it cannot prevent man-
   in-the-middle attacks.  

Our TLS implementation does not contain anonymous cipher suites,
and I stronly doubt that anyone could provide a convincing rationale
to change that.

For SMTP(STARTTLS), I consider the lack of authentication in the original
SMTP infrastructure as well as most of the STARTTLS installed base to
part of the _problem_space_.  And while I'm not particularly enthusiastic
about misleading DANE band-aids to SMTP-STARTTLS, I consider that approach
preferable to anonymous TLS cipher suites by a huge margin.

-Martin

---

From: Nico Williams <[email-masked]>
Date: Thu, 21 Mar 2013 13:44:21 -0500

>    Diffie-Hellman is strongly discouraged because it cannot prevent man-

That's not relevant.  I'm not asking why your implementation is missing
some cipher suite: I'm asking why some cipher suites are missing from the
registry.

> preferable to anonymous TLS cipher suites by a huge margin.

TLS has anon cipher suites.  I have a need for anon cipher suites with a)
decent confidentiality and integrity protection algorithms, b) fast
ephemeral-ephemeral + small public key key agreement.  That is, I need
*modern* anon cipher suites.  Your value judgement is noted, and rejected:
it does not change my need, a need that is acknowledged by TLS given that
it provides anon cipher suites at all.

If nothing else we should have consistency, and we should define
all modern cipher suites that make sense (e.g., we'd not define suites for
stream ciphers w/ block cipher modes).  We might leave some out (e.g., why
bother with old non-AEAD modes for new block ciphers?), but we should not
leave out modern suites providing important functionality that TLS has
generally offered before (again, anon cipher suites with modern
algorithms).  Please argue (or accept) this, not that anon suites are a bad
idea.

[Yes, this means we're stuck having lots of cipher suites registrations,
but we already have lots, and the commitment to having lots was made long
ago.  I'd propose, once more, that we begin to aim for a la carte
negotiation, but that's really a separate thread (and please change the
Subject: if you want to take this chance to discuss that idea).]

Also, +1 to Peter G.'s response.  You might hate anon cipher suites, but I
can always get the same effect by ignoring cert validation failures (or
even not attempting to validate them in the first place).

Nico
--

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Fri, 22 Mar 2013 18:27:46 +0100

> some cipher suite: I'm asking why some cipher suites are missing from the

Indeed, but as a comment I'd say that the anon ciphersuites have a big
disadvantage comparing to using the certificate based ones for anonymous
authentication, and that is they cannot support key continuity.

With the certificate based ciphersuites you may use the certificates
only as container to send the public key of each party (or even use the
raw key proposed extension of TLS), and store the party's key for future
sessions. That way you limit the anon authentication only on the first
session and subsequent sessions are properly authenticated (you are
assured it is the same party you talked before).

With the anon ciphersuites unfortunately you cannot not do that, meaning
you are always going to have anonymous authentication, even if you have
seen that party before.

regards,
Nikos

---

From: [email-masked] (Martin Rex)
Date: Fri, 22 Mar 2013 20:51:48 +0100 (CET)

Nico Williams wrote:
> Martin Rex wrote:

I believe you're too fast in dismissing the security problems
associated with anon cipher suites.

  http://tools.ietf.org/html/rfc5246#page-76

     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.  Using this mode therefore is of limited use: These
*>   cipher suites MUST NOT be used by TLS 1.2 implementations unless the
*>   application layer has specifically requested to allow anonymous key
     exchange.  (Anonymous key exchange may sometimes be acceptable, for
     example, to support opportunistic encryption when no set-up for
     authentication is in place, or when TLS is used as part of more
     complex security protocols that have other means to ensure
     authentication.)

        CipherSuite TLS_DH_anon_WITH_RC4_128_MD5          = { 0x00,0x18 };
        CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA     = { 0x00,0x1B };
        CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA      = { 0x00,0x34 };
        CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA      = { 0x00,0x3A };
        CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA256   = { 0x00,0x6C };
        CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA256   = { 0x00,0x6D };

     Note that using non-anonymous key exchange without actually verifying
     the key exchange is essentially equivalent to anonymous key exchange,
     and the same precautions apply.  While non-anonymous key exchange
     will generally involve a higher computational and communicational
     cost than anonymous key exchange, it may be in the interest of
     interoperability not to disable non-anonymous key exchange when the
     application layer is allowing anonymous key exchange.

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.

The other problem is, that when a Server certificate is required,
at least a self-signed one for local/test scenarios, that the
relevant interfaces and configuration options will be available
in the application caller code.  If anonymous ciphersuites were
available by default, you start finding application callers
that either "forgot" to offer a configuration option for certs,
or where that option is only theoretically available but doesn't
work, because it was never tested (by the developer).

Using a regular TLS cipher suite, and ignoring the server certificate
chain is always a possibility for an application caller that desires
to skip authentication consciously.

> ago.

Now you're confusing two things.  While its true that there are lots
of cipher suites _registrations_, that doesn't mean that there are
lots of cipher suites to choose from.

And performance seems to not be a concern for everybody, because
there are some TLS implementations that put RSA-AES256-SHA1 before
RSA-AES128-SHA1 in their preference order, rather than the more
reasonable RSA-AES128-SHA1 before RSA-AES256-SHA1 default ordering.

-Martin

---

From: Nico Williams <[email-masked]>
Date: Fri, 22 Mar 2013 15:07:51 -0500

> authentication, and that is they cannot support key continuity.

An interesting argument... that fails to address the use cases I gave.
 Also, it's not responsive to the issue at hand... unless you want to argue
for removal of the existing anon cipher suites, and even then it'd not be
responsive.  I might not mind having a debate about the utility of anon
cipher suites -in a separate thread- but I kinda need to know what to do
about the missing cipher suites.

I want to know a) why these cipher suites are missing (presumably from
RFC5289) and b) what I should do to get them added (submit an individual
submission I-D?  ask the chairs to adopt a new WG work item for adding
these?).  The registry has Specification Required allocation a range but
merely submitting an I-D is still not enough, and if there's some reason
for these cipher suites being missing other than "oversight", well, why get
myself blindsided by it?  Better ask is what I thought.  If no one answers
by Monday I'll assume this was an oversight and submit an I-D.

Nico
--

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Fri, 22 Mar 2013 21:37:01 +0100

> about the missing cipher suites.

No I didn't say that to challenge the utility of the anon ciphersuites
in your use case. Since they are defined, it is good to have all
possible variants, as you suggest.

> The registry has Specification Required allocation a range but
> myself blindsided by it?  Better ask is what I thought.

What if submitting an independent informational rfc? Wouldn't that count
as a specification?

regards,
Nikos

---

From: [email-masked] (Martin Rex)
Date: Fri, 22 Mar 2013 22:25:43 +0100 (CET)

> What if submitting an independent informational rfc? Wouldn't that count

To meet "Specification Required" an Informational RFC is OK.
But it is actually a lesser Requirement than "RFC Required",
so having it permanently documented elsewhere (outside of the IETF),
would also be OK.

An I-D typically needs to have at least been approved by the IESG to meet
the "documented in a permanent and readily available specification",
since I-Ds are officially "temporary, work in progress", carrying the
explicit "warning" label:

         It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress".

For the exact definition, see:

  http://tools.ietf.org/html/rfc5226#page-10

      Specification Required - Values and their meanings must be
            documented in a permanent and readily available public
            specification, in sufficient detail so that interoperability
            between independent implementations is possible.  When used,
            Specification Required also implies use of a Designated
            Expert, who will review the public specification and
            evaluate whether it is sufficiently clear to allow
            interoperable implementations.  The intention behind
            "permanent and readily available" is that a document can
            reasonably be expected to be findable and retrievable long
            after IANA assignment of the requested value.  Publication
            of an RFC is an ideal means of achieving this requirement,
            but Specification Required is intended to also cover the
            case of a document published outside of the RFC path.  For
            RFC publication, the normal RFC review process is expected
            to provide the necessary review for interoperability, though
            the Designated Expert may be a particularly well-qualified
            person to perform such a review.

            Examples: Diffserv-aware TE Bandwidth Constraints Model
            Identifiers [RFC4124], TLS ClientCertificateType Identifiers
            [RFC4346], ROHC Profile Identifiers [RFC4995].

-Martin