Subject: [TLS] The risk of misconfiguration

From: Watson Ladd <[email-masked]>
Date: Tue, 6 May 2014 11:48:26 -0700

Dear all,

Do you know what your TLS configurations mean? If you use OpenSSL,
probably not: apparently "HIGH" enables ADH ciphersuites. It does so
before permitting AES128 with an authenticated ECDHE exchange. Sorting
by strength puts DES ahead of AES128: I've got no idea how that
happened. (Yes, DES: 3DES is indicated differently. Maybe it is really
3DES, but even so...). I haven't found the email yet, but someone
indicated they saw this in the wild on the list, actually leading to
ADH happening due to an interaction between this and another borked
configuration.

I've sort of singled out OpenSSL here. PolarSSL uses compile-time
configuration, which in some circumstances doesn't work, but it at
least provides a somewhat sensible configuration depending on how you
build it.I've not looked at GnuTLS yet, or cryptlib.

Actually configuring OpenSSL to do something reasonable requires
writing something like
EECDH+AES128:RSA+AES128:EECDH+AES256:RSA+AES256:EECDH+3DES:RSA+3DES:EECDH+RC4:RSA+RC4:!MD5.
Good luck coming up with that when you are overly busy, don't realize
that asking for high security doesn't actually do what you want, and
don't know anything about crypto.

Part of the issue is that we've enabled dangerous options like NULL
ciphers and anonymous DH, which very, very few people should ever use.
The other part of the issue is software quality. But a third part of
the issue is the lack of guidance, which UTA was supposedly going to
address.

So how do we fix this? Well, one thing we can do is ensure that the
least secure options are reasonably secure, so if they are enabled it
isn't a disaster. Authentication-only ciphersuites fail that test. I
appreciate the performance issue, and yes, sometimes you don't need
encryption. But I think the number of people who accidentally enabled
ADH is an order of magnitude more than those who actually wanted it.

Sincerely,
Watson Ladd

---

From: Alyssa Rowan <[email-masked]>
Date: Tue, 06 May 2014 19:53:54 +0100

On 06/05/2014 19:48, Watson Ladd wrote:

> I think the number of people who accidentally enabled ADH is an
> order of magnitude more than those who actually wanted it.

+1. I never saw anyone enable ADH, NULL or EXPORT cipher suites
actually on purpose. I have definitely seen people do it by accident.

The mere presence of NULL ciphersuites is dangerous: someone might
actually use them, and that's basically never a good idea.

Take them out; keep them out; don't put them back in.

- -- 
/akr

---

From: James Cloos <[email-masked]>
Date: Tue, 06 May 2014 15:30:34 -0400

>>>>> "WL" == Watson Ladd <[email-masked]> writes:

WL> Do you know what your TLS configurations mean? If you use OpenSSL,
WL> probably not: apparently "HIGH" enables ADH ciphersuites. It does so
WL> before permitting AES128 with an authenticated ECDHE exchange. Sorting
WL> by strength puts DES ahead of AES128: I've got no idea how that
WL> happened. (Yes, DES: 3DES is indicated differently. Maybe it is really
WL> 3DES, but even so...).

With openssl-1.1g, I see no DES from HIGH, only 3DES.

But you have to look carefully to realise that.  The SRP and PSK suites
which match the regex /DES/ use CBC3 to specify triple des; all other
openssl suites which match /DES/ use 3DES to specify triple des.

Gnutls, OTOH, always uses 3DES_EDE_CBC for the suites, and 3DES-CBC for
the cipher.

NSS’s tstclnt uses single-letter flags rather than names, but documents
the triple des options with EDE3 for the ssl2 suite and 3DES for the ssl3
suites it supports.

-JimC
--
James Cloos <[email-masked]>         OpenPGP: 0x997A9F17ED7DAEA6

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 6 May 2014 22:13:44 +0000

> actually on purpose. I have definitely seen people do it by accident.

The SMTP server that hosts your email runs Postfix:

    $ posttls-finger -lmay -c akr.io
    posttls-finger: Connected to entima.net[78.129.143.175]:25
    posttls-finger: Anonymous TLS connection established to entima.net[78.129.143.175]:25: TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)
    posttls-finger: Server is anonymous

When remote Postfix systems employ unauthenticated opportunistic
TLS to send you email (smtp_tls_security_level = may), they and
your server will preferrentially use ADH and AECDH cipher-suites.

Because any encryption at all is better than sending cleartext
email, both your server and the remote SMTP clients typically leave
both EXPORT and LOW cipher-grades enabled.  This may change in
Postfix 2.12 as I've seen no recent evidence of any systems that
only support export-grade crypto.  So I am inclined to disable
EXPORT and LOW by default starting with 2.12 in 2015.

Postfix also supports the use of NULL ciphers for client-certificate
authenticated delivery to LMTP over the loopback interface, though
this is not on by default (lmtp_tls_mandatory_ciphers = null).

By the way, though it is nice to see your server publishing TLSA
records for SMTP, the DANE WG draft for SMTP specifies that only
certificate usages DANE-TA(2) and DANE-EE(3) are to be used with
SMTP.  You're publishing PKIX-EE(1).

    $ posttls-finger akr.io
    posttls-finger: using DANE RR: _25._tcp.entima.net IN TLSA 1 1 1 53:5B:F2:89:B0:04:2F:20:92:E7:90:2C:DF:91:DD:F9:F8:B9:62:66:81:C7:94:34:04:A4:22:78:FF:72:AF:46
    posttls-finger: Connected to entima.net[78.129.143.175]:25
    posttls-finger: entima.net[78.129.143.175]:25: depth=0 matched end entity public-key sha256 digest=53:5B:F2:89:B0:04:2F:20:92:E7:90:2C:DF:91:DD:F9:F8:B9:62:66:81:C7:94:34:04:A4:22:78:FF:72:AF:46
    posttls-finger: Verified TLS connection established to entima.net[78.129.143.175]:25: TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)

The reason posttls-finger verified this, is that Postfix implicitly
maps PKIX-EE(1) to DANE-EE(3), because that's better than simply
treating the TLSA RR as unusable.

> Take them out; keep them out; don't put them back in.

Authenticated loopback IPC is a perfectly fine use-case for NULL
cipher-suites.  Don't confuse perfectly fine protocol capabilities
with fragile user interfaces.

The OpenSSL cipherlist is not an end-user interface, it is a
configuration interface for developers.  Applications need to expose
higher-level application-specific configuration interfaces, and
the better designed ones do.

I, for one, am not surprised by HIGH including ADH cipher-suites.
It is a good idea to read the documentation before cargo-cult
cut/paste of cipherlist strings.  HIGH refers only to the symmetric
algorithm bit strength.  It would not be a useful building-block
if it did not represent an elementary property.

The DEFAULT cipherlist in OpenSSL excludes aNULL and eNULL.  Safe
strictly stronger cipherlists that want to elicit server certificates
need to start with "DEFAULT" and subtract:

	# High-grade authenticated ciphersuites only
	DEFAULT+HIGH

	# High-grade, sans MD5, DSS certs and RSA key exchange.
	DEFAULT:!LOW:!EXPORT:!MEDIUM:!MD5:!aDSS:!kRSA

By the way mere use of a cipher suite that elicits certificates
does not magically make authentication happen, there still needs
to be some code for that too...

-- 
	Viktor.

---

From: Nico Williams <[email-masked]>
Date: Tue, 6 May 2014 17:23:23 -0500

Banning anon ciphersuites is NOT a good idea.  We have at least two
uses for them (more assuming we retain renego):

 - channel binding with tls-unique CB

 - opportunistic security (as in the SAAG list thread on OS, and, of
course, what some SMTP MTAs do)

Nico
--

---

From: Andrei Popov <[email-masked]>
Date: Tue, 6 May 2014 22:48:46 +0000

Here are a couple scenarios I'm aware of that require NULL ciphers:
1. Protocols that implement their own encryption, but run within TLS channels (to get through middle boxes). Double encryption is wasteful, therefore NULL ciphers can be negotiated in this case.
2. Various cases where confidentiality is not required, or is not achievable by means of encryption (e.g. constrained devices sending out periodic pings).

However, it seems reasonable to disable NULL ciphers in the default configuration.

I have nothing to say in support of the EXPORT ciphers:)

Cheers,

Andrei

-----Original Message-----
From: TLS [mailto:[email-masked]] On Behalf Of Alyssa Rowan
Sent: Tuesday, May 6, 2014 11:54 AM
To: [email-masked]
Subject: Re: [TLS] The risk of misconfiguration

On 06/05/2014 19:48, Watson Ladd wrote:

> I think the number of people who accidentally enabled ADH is an order 
> of magnitude more than those who actually wanted it.

The mere presence of NULL ciphersuites is dangerous: someone might actually use them, and that's basically never a good idea.

- --
/akr

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

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 6 May 2014 23:30:05 +0000

> I have nothing to say in support of the EXPORT ciphers:)

Yes, and throw in LOW as well:

    EDH-RSA-DES-CBC-SHA     SSLv3 Kx=DH       Au=RSA  Enc=DES(56)   Mac=SHA1
    EDH-DSS-DES-CBC-SHA     SSLv3 Kx=DH       Au=DSS  Enc=DES(56)   Mac=SHA1
    ADH-DES-CBC-SHA         SSLv3 Kx=DH       Au=None Enc=DES(56)   Mac=SHA1
    DES-CBC-SHA             SSLv3 Kx=RSA      Au=RSA  Enc=DES(56)   Mac=SHA1

These (EXPORT and LOW) fortunately seem to have some time ago
outlived their useful life.  They can I think be disabled, rather
than offered at the bottom of the client cipherlist, without
degrading even opportunistic security where handshake-failure leads
to cleartext fallback.

This would leave OpenSSL with eNULL, MEDIUM and HIGH.  HIGH includes
3DES, presumably in part because this is a historical MUST implement
for interoperability cipher-suite.  In practice that role was and
to some extent still is actually played by RC4.

-- 
	Viktor.

---

From: Alyssa Rowan <[email-masked]>
Date: Wed, 07 May 2014 01:01:39 +0100

On 06/05/2014 23:13, Viktor Dukhovni wrote:

>>> I think the number of people who accidentally enabled ADH is
>>> an order of magnitude more than those who actually wanted it.
>> I never saw anyone enable ADH, NULL or EXPORT cipher suites 

Touché! I take your point there. SMTP's a particularly painful
usecase, one with OE being particularly valuable, and one I overlooked.

As I've previously pointed out, I prefer scenarios where Mallory can't
passively tell if we're negotiating opportunistically, so he can't
selectively MITM without risk of detection. Using anon ciphersuites
for OE may make Mallory's life a little easier than if we just don't
hard-fail on self-signed/expired certificates and the like when
negotiating OE. But I can see that also complicates things in its own
way (as OE then looks like just not implementing it right, and Bob
can't tell either).

As far as Nico points out with channel binding/tls-unique and anon,
that's kind of a bigger problem with the triple-handshake issue and
all. Maybe there's a better solution for that altogether that doesn't
need or use A(EC)DH?

> ...I've seen no recent evidence of any systems that only support 
> export-grade crypto.  So I am inclined to disable EXPORT and LOW
> by default starting with 2.12 in 2015.

I think that seems eminently sensible.

> Postfix also supports the use of NULL ciphers for
> client-certificate authenticated delivery to LMTP over the loopback
> interface, though this is not on by default
> (lmtp_tls_mandatory_ciphers = null).

Others have also pointed out some use cases for NULL:
client-certificate authenticated loopback APIs; constrained devices
pinging; and those using TLS merely as a framing protocol to get
through middle-boxes.

Those all leave me scratching my head wondering why they're using TLS
anyway:

• One's running locally (and authenticating with slow cert
  signatures, and it's the bulk cipher that bugs them?);
• One's too small to (but not too small to do x.509/ASN.1, RSA, etc?
  and not sending anything identifiable?); and,
• One's apparently only pretending to use TLS (which makes NULL an
  intriguing choice to reveal to that untrusted middle-box; why not
  masq a more fun protocol? What about if it sees NULL and measures
  encrypted/compressed data and freaks out? Why not - gasp - *lie*?).

Of course, it wouldn't be the first time people made odd decisions.

> The OpenSSL cipherlist is

...um. The word I'd use would be: hairy.

In practice, unfortunately way too hairy for the average developer;
whence passing the buck to the average end-user; whence the average
end-user taking the cipherlist as copypasta from the first Google
result they found that actually worked.

We've all seen the end results.

- -- 
/akr

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 7 May 2014 00:24:52 +0000

> We've all seen the end results.

We must not confuse implementation user-interface issues with
protocol issues.  The protocol supports many different use-cases.
Interfaces for cipher selection in implementations are not protocol
issues.  The OpenSSL cipherlist interface is beginning to get some
attention.  That issue belongs on [email-masked], not
[email-masked].

-- 
	Viktor.

---

From: Ralph Holz <[email-masked]>
Date: Wed, 07 May 2014 02:39:18 +0200

Hi,

> Take them out; keep them out; don't put them back in.

While I concur for the general use cases of Web/mail etc., I have seen
the NULL ciphers put to successful use for large-scale data transfer
between high-performance computing clusters. The use was indeed
intentional.

R

-- 
Ralph Holz
I8 - Network Architectures and Services
Technische Universität München
http://www.net.in.tum.de/de/mitarbeiter/holz/
Phone +49.89.289.18043
PGP: A805 D19C E23E 6BBB E0C4  86DC 520E 0C83 69B0 03EF

---

From: Watson Ladd <[email-masked]>
Date: Tue, 6 May 2014 18:08:52 -0700

> attention.  That issue belongs on [email-masked], not

Agreed, but it's an example of the hazard that insecure modes present.
OpenSSL is not an outlier: with 100+ possible ciphersuites, with
strange omissions and inclusions, and completely lacking information
about which curve to use, designing a good configuration system to
pick TLS ciphersuites is hard. PolarSSL takes the exact opposite tack,
forcing users to subset a single preference order. It is entirely
possible that legitimately desired ciphersuites cannot be chosen in
PolarSSL: I know they cannot be reordered.

No matter how the choice is presented to end-users or application
developers, so long as it is possible to misconfigure TLS, it will be
misconfigured. You can blame the end user or the programmer or the
library writer all you want, but unless a library is willing to forgo
supporting null ciphers, they will be used inadvertently. Why include
something that should virtually never be used, when using it has bad
consequences?

We've recognized the need for guidance on how to use TLS, hence
formation of UTA. We're punting on implementation, although I recently
got an email about the C standards body wanting to standardize APIs
for networks, which, if they included TLS with a sane API would be
wonderful. But the complexity that OpenSSL reveals is real: there is
no way to support all possible combinations of ciphersuites without
something this nasty to pick between them.

Sincerely,
Watson Ladd

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 7 May 2014 02:00:23 +0000

> misconfigured.

In Postfix the user chooses a "cipher-grade" that sets the floor
on the set of enabled cipher-suites.  The levels are monotone.
This is a simple interface that is rather difficult to mess up.

The underlying definitions of these grades is also configurable,
but I strongly discourage users from attempting to touch these
without expert advice.

This has worked well for nearly a decade with no evidence of
significant user confusion or misguided misconfiguration.

User interfaces need to make the simple things easy and the
complicated things possible.

> You can blame the end user or the programmer or the

The above is just a rhetorical rant.  Risk cannot be banned out of
existence, but systems can be designed with greater safety in mind.

> something this nasty to pick between them.

The above is plainly false.  Good systems offer many layers of
controls, some for naive users some for experts.  They have high
and low level APIs, with the latter offering more fine-grained
control when needed.  OpenSSL should be improved not neutered.

Software that only dumbs everything down is not progress, we need
software that is both usable and flexible.

-- 
	Viktor.

---

From: Watson Ladd <[email-masked]>
Date: Tue, 6 May 2014 20:32:43 -0700

> This is a simple interface that is rather difficult to mess up.

Actually, it makes the same mistake as OpenSSL does:enabling anonymous
ciphers even when configured to send a server certificate and use 128
bit encryption, without an additional option set. (Source:
http://www.postfix.org/TLS_README.html, search for the Server-Side
Cipher Controls section)

At least the documentation notes that this happens, and tells you the
option you really need. Of course, the sad state of TLS for email
prevents this from being a problem in practice. Postfix is one of the
better-written applications out there, with a team that gets it. That
does not apply to all applications. It doesn't even apply to mobile
banking applications.

> software that is both usable and flexible.

I'm a Hobbsean: our role is to assure the safety of encrypted traffic,
even if people can't do what they want as a result. How many
ciphersuites do you really need? Not 314, soon to increase with the
addition of ChaCha20+Poly1305. (Which surprisingly we do need: very
few of the block ciphers are side channel resistant) This number is
actually an underestimate: ECDH and ECDHE indicate curve support
separately from ciphersuite. In TLS 1.3 we've decided to take a vast
number to the woodshed: the question now is to reenable null
encryption.

Maybe it's possible to make a configuration system that enables a
considerable number of these ciphersuites without letting people blow
their leg off accidentally. Experimental evidence largely indicates
otherwise.

Sincerely,
Watson Ladd

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 7 May 2014 03:59:57 +0000

> http://www.postfix.org/TLS_README.html, search for the Server-Side

What you say is mistake in Postfix is actually a mistake in your
problem analysis.

http://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-09#section-8.2

use of anonymous ciphers in Postfix is not an accident, it is rather
deliberate.

> Of course, the sad state of TLS for email prevents this from being a
> problem in practice.

Actually TLS for email is not in such sorry shape as you might
think.  I bet a larger share of SMTP traffic is encrypted than with
HTTP.  Opportunistic TLS has a simpler deployment model.

> ciphersuites do you really need?

There are different sets of "you".  No single set of "you" needs
all the ciphersuites, but collectively many are required in a
general-purpose protocol.  This is the price of success.

    - Some folks want ADH and AECDH
    - Some folks want NULL ciphers
    - Some folks want Suite-B
    - Japan wants CAMELLIA
    - Russia wants GOST
    - Korea wants SEED

> In TLS 1.3 we've decided to take a vast

The Postfix "null" cipher grade offers ONLY NULL ciphers, and the
other grades offer no NULL ciphers.  Servers by default offer no
NULL ciphers.  It is rather difficult to enable NULL ciphers by
accident and not notice.  Both sides need to only offer NULL ciphers
or else the handshake fails.

> their leg off accidentally. Experimental evidence largely indicates

Experimental evidence based on an underfunded dominant toolkit.
Which provides mostly just the low-level interfaces.  This is
starting to change.  Breaking the protocol because OpenSSL is
difficult to use right is not the right answer.  Solve the
right problem, work to improve OpenSSL.

The Postfix to OpenSSL glue makes up for lack of higher level
interfaces with ~10,000 lines of commented code:

$ wc src/tls/*.[ch]  | sort -k3nr
   10594   40319  313491 total
    2231    8228   62695 src/tls/tls_dane.c
    1060    4717   36667 src/tls/tls_client.c
    1209    4125   35031 src/tls/tls_misc.c
     903    3873   31929 src/tls/tls_server.c
     606    2393   19700 src/tls/tls.h
     507    2119   16252 src/tls/tls_verify.c
     593    2189   16242 src/tls/tls_scache.c
     471    1466   12447 src/tls/tls_mgr.c
     363    1632   11703 src/tls/tls_fprint.c
     289    1276    8509 src/tls/tls_bio_ops.c
     278    1135    7974 src/tls/tls_dh.c
     245     858    7078 src/tls/tls_proxy_clnt.c
     176     647    4885 src/tls/tls_certkey.c
     160     648    4704 src/tls/tls_stream.c
     169     573    4462 src/tls/tls_session.c
     166     583    4119 src/tls/tls_prng_egd.c
     142     516    3776 src/tls/tls_prng_exch.c
     155     530    3732 src/tls/tls_prng_file.c
     155     513    3681 src/tls/tls_prng_dev.c
      94     294    2795 src/tls/tls_proxy_scan.c
     119     410    2709 src/tls/tls_rsa.c
      73     268    2139 src/tls/tls_scache.h
      86     225    2133 src/tls/tls_proxy_print.c
      81     311    2023 src/tls/tls_level.c
      88     261    1814 src/tls/tls_seed.c
      71     223    1808 src/tls/tls_mgr.h
      50     154    1295 src/tls/tls_prng.h
      54     152    1189 src/tls/tls_proxy.h

One day when OpenSSL offers a much more complete high level interface,
this code footpring might shrink.  (Long from now, when we're ready
to deprecate less capable OpenSSL versions).

-- 
	Viktor.

---

From: Watson Ladd <[email-masked]>
Date: Tue, 6 May 2014 22:32:54 -0700

> HTTP.  Opportunistic TLS has a simpler deployment model.

Go walk outside. Ask someone "When you send email to someone, who can
read it?". Compare their answer to the reality. So long as there is a
difference between those two, you have a problem. At least with the
web, we have a (somewhat) functioning PKI, and it's the protocol and
implementations that are the real problem.

(Interestingly DKIM ensures all email is signed, even without DANE,
yet we've not been able to turn that into encrypting the connections
between mail servers in 9 years of work. XMPP has a flag day in 13
days in which encryption will be on. Most servers will be using
certificates.)

Furthermore, in TLS 1.3 we've made changes to the protocol that have
the side effect of removing everything but AES and Camellia. Yes, if
you want to saturate a gigabit Ethernet cable using a 1.3 GHz
processor, you may have a problem with encryption slowing things down.
Is that worth the hazard null encryption presents? I'm not sure: I
agree that (some) of the misconfiguration hazards are a result of the
deplorable state of a major implementation, that is going to get
massively changed, and so maybe we shouldn't worry too much. On the
other hand people have turned them on by accident.

Sincerely,
Watson Ladd

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 7 May 2014 05:58:35 +0000

On Tue, May 06, 2014 at 10:32:54PM -0700, Watson Ladd wrote:

> Go walk outside.

Some humility in areas in which you're not the domain expert may
at times be appropriate.  You say TLS for SMTP is in sorry state,
this is not the case.  It is simply opportunistic TLS, with which
folks whose mental model of TLS is based on HTTPS are not sufficiently
familiar:

http://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-09#section-1.3

> Ask someone "When you send email to someone, who can
> read it?".

We're talking about TLS in SMTP not who can or can't read stored
email.  Whether the man in the street knows it or not, a substantial
fraction (estimated 20% and growing) of email traffic is encrypted
in transit, just because both ends can simply turn on STARTTLS.
I bet this fraction is larger than the fraction of HTTP traffic
that is protected inside HTTPS.

Yes, email is often stored by providers subject to a NSL.  The same
may well be true of your bank statement.  Intelligence services
are interesting in money movements, not just email.  One might hope
banks are not as cooperative with warrantless "metadata" as the
telcos.

> Compare their answer to the reality. So long as there is a

It only covers the sites that pay the PKI tax and the URLs that
they bother to encrypt for clients willing to trust a few hundred
CAs.  This is NOT the majority of the traffic.  Strong protection
for some, no protection for most.  Opportunistic TLS can scale to
"some protection for most", largely by bypassing the PKI in question.

> processor, you may have a problem with encryption slowing things down.

TLS 1.3 is not a done deal yet.

> massively changed, and so maybe we shouldn't worry too much.

Now we get to focus on solving the right problem.

-- 
	Viktor.

---

From: Fedor Brunner <[email-masked]>
Date: Wed, 07 May 2014 09:13:37 +0200

On 07.05.2014 00:13, Viktor Dukhovni wrote:
> $ posttls-finger -lmay -c akr.io posttls-finger: Connected to
> entima.net[78.129.143.175]:25 posttls-finger: Anonymous TLS
> connection established to entima.net[78.129.143.175]:25: TLSv1.1
> with cipher AECDH-AES256-SHA (256/256 bits) posttls-finger: Server
> is anonymous
> 
> email, both your server and the remote SMTP clients typically
> leave both EXPORT and LOW cipher-grades enabled.  This may change
> in Postfix 2.12 as I've seen no recent evidence of any systems
> that only support export-grade crypto.  So I am inclined to
> disable EXPORT and LOW by default starting with 2.12 in 2015.
> 
> $ posttls-finger akr.io posttls-finger: using DANE RR:
> _25._tcp.entima.net IN TLSA 1 1 1
> 53:5B:F2:89:B0:04:2F:20:92:E7:90:2C:DF:91:DD:F9:F8:B9:62:66:81:C7:94:34:04:A4:22:78:FF:72:AF:46
>
> 
> posttls-finger: entima.net[78.129.143.175]:25: depth=0 matched end
> entity public-key sha256
> digest=53:5B:F2:89:B0:04:2F:20:92:E7:90:2C:DF:91:DD:F9:F8:B9:62:66:81:C7:94:34:04:A4:22:78:FF:72:AF:46
>
> 
posttls-finger: Verified TLS connection established to
entima.net[78.129.143.175]:25: TLSv1.1 with cipher ECDHE-RSA-AES256-SHA
(256/256 bits)
> 
> The reason posttls-finger verified this, is that Postfix
> implicitly maps PKIX-EE(1) to DANE-EE(3), because that's better
> than simply treating the TLSA RR as unusable.
> 
>> The mere presence of NULL ciphersuites is dangerous: someone
>> might actually use them, and that's basically never a good idea.
>> 
> configuration interface for developers.  Applications need to
> expose higher-level application-specific configuration interfaces,
> and the better designed ones do.
> 
> cut/paste of cipherlist strings.  HIGH refers only to the
> symmetric algorithm bit strength.  It would not be a useful
> building-block if it did not represent an elementary property.
> 
> strictly stronger cipherlists that want to elicit server
> certificates need to start with "DEFAULT" and subtract:
> 
> # High-grade authenticated ciphersuites only DEFAULT+HIGH
> 
> does not magically make authentication happen, there still needs to
> be some code for that too...
> 

Your example
 	# High-grade authenticated ciphersuites only
 	DEFAULT+HIGH
is incorrect because it selects also very weak ciphers
EXP-DES-CBC-SHA, EXP-RC2-CBC-MD5, DES-CBC-SHA

Try to run OpenSSL ciphers command:

openssl ciphers 'DEFAULT+HIGH'

DHE-RSA-SEED-SHA:DHE-DSS-SEED-SHA:SEED-SHA:ECDHE-RSA-RC4-SHA:ECDHE-ECDSA-RC4-SHA:ECDH-RSA-RC4-SHA:ECDH-ECDSA-RC4-SHA:RC4-SHA:RC4-MD5:PSK-RC4-SHA:EDH-RSA-DES-CBC-SHA:EDH-DSS-DES-CBC-SHA:DES-CBC-SHA:EXP-EDH-RSA-DES-CBC-SHA:EXP-EDH-DSS-DES-CBC-SHA:EXP-DES-CBC-SHA:EXP-RC2-CBC-MD5:EXP-RC4-MD5:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:SRP-DSS-AES-256-CBC-SHA:SRP-RSA-AES-256-CBC-SHA:DHE-DSS-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA256:DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:DHE-RSA-CAMELLIA256-SHA:DHE-DSS-CAMELLIA256-SHA:ECDH-RSA-AES256-GCM-SHA384:ECDH-ECDSA-AES256-GCM-SHA384:ECDH-RSA-AES256-SHA384:ECDH-ECDSA-AES256-SHA384:ECDH-RSA-AES256-SHA:ECDH-ECDSA-AES256-SHA:AES256-GCM-SHA384:AES256-SHA256:AES256-SHA:CAMELLIA256-SHA:PSK-AES256-CBC-SHA:ECDHE-RSA-DES-CBC3-SHA:ECDHE-ECDSA-DES-CBC3-SHA:SRP-DSS-3DES-EDE-CBC-SHA:SRP-RSA-3DES-EDE-CBC-SHA:EDH-R
 S
A-DES-CBC3-SHA:EDH-DSS-DES-CBC3-SHA:ECDH-RSA-DES-CBC3-SHA:ECDH-ECDSA-DES-CBC3-SHA:DES-CBC3-SHA:PSK-3DES-EDE-CBC-SHA:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:SRP-DSS-AES-128-CBC-SHA:SRP-RSA-AES-128-CBC-SHA:DHE-DSS-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-SHA256:DHE-DSS-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA:DHE-RSA-CAMELLIA128-SHA:DHE-DSS-CAMELLIA128-SHA:ECDH-RSA-AES128-GCM-SHA256:ECDH-ECDSA-AES128-GCM-SHA256:ECDH-RSA-AES128-SHA256:ECDH-ECDSA-AES128-SHA256:ECDH-RSA-AES128-SHA:ECDH-ECDSA-AES128-SHA:AES128-GCM-SHA256:AES128-SHA256:AES128-SHA:CAMELLIA128-SHA:PSK-AES128-CBC-SHA

The correct selection is HIGH:!aNULL

Always check your OpenSSL cipher configuration using the ciphers
command. The command "openssl ciphers -v' will also display the
properties of ciphers.

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Wed, 07 May 2014 08:40:04 +0200

> build it.I've not looked at GnuTLS yet, or cryptlib.
[...]
> don't know anything about crypto.

Just because you saw a red car you cannot infer that all cars are red.
As you describe it this clearly looks like an openssl problem and you
need to report to the openssl developers, not this list.

regards,
Nikos

---

From: Warren Kumari <[email-masked]>
Date: Wed, 7 May 2014 10:22:29 -0400

On Tue, May 6, 2014 at 2:53 PM, Alyssa Rowan <[email-masked]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>

I've seen someone do it on purpose -- kinda....

Many years ago I was working for a large registrar -- we had an F5
load balancer that directed HTTP to one set of hosts, and HTTPS to
another set. One day one of the sysadmins noticed that the HTTPS
servers ran *much* hotter than the HTTP ones (for the same QPS). He
came and asked me what to do about this, and I suggested that he go
investigate and figure out why - I thought it would be a useful
learning experience...

Anyway, a month or two later we have some really weird network issue,
so  I fire up a sniffer -- and in one of the packets I see something
that is fairly clearly a name and credit card number. Much panic
ensues -- and then I discover how he has "solved" the issue -- yup, he
has managed to disable everything, and then enable only NULL. He had
no idea why, but he;d poked at things, and now the CPU on the HTTPS
servers was much closer to the HTTP ones. Win!

W

> -----BEGIN PGP SIGNATURE-----
>
> iQIcBAEBCgAGBQJTaS/CAAoJEOyEjtkWi2t6q34P/j5QX4BBRJLusLx3cevVdxmM
> JXHnhPDY+ovbHSs1XkASJAS4x/k40IN2maj+8E47Me/ZsTriJd8659vq9jxQeTT4
> f04TBYGphcBQupZg136CVcsA1WSFiWo1UfXffW8oRAQfU2CpVdeKb/0IFLgQ64sa
> G37UAxFtKTnFVtrec1Q5tdwfSdc6nEP2zbzpaAVB96vqJuel/bNtOFQM44CriPQ3
> LbtIX3MMh0qfBAxwmTwe9+YahzGuCxIAStHwJl4JD3ReTJHlo/lxlDNIVt46nkzv
> HYB3moJ1tDlzpFn0xWNQHrKcN5GtotktsV12Uyq91DvAd6U/CHQD13h9cO5OmCDT
> Sb+S+0OmHeXah6A0zBe7DSJS+yf4pqjQazFaQyP6z0SLdh4krhvKP2hGiuDvTMyf
> b2WVOmd1ThitIqoFYfS8VhpbEOFrUDl4y6LYAEJgqCET20BK5Qal0doENrsTE260
> 57oFR7wygJpc4Y5yGZ4sWfOqRuowbJm7ZSdYguMv2VuS84M3BdhFHaitYyrEbZRR
> 9r6uuZR7d+VIR9nhLYXTFK9I4B2DDr6joLaVTzDB4W2tf6xHL2RsIRXnwCj3UdAQ
> XOHKtnQ+RCsHCUUetKsOx8Arc7IQb5R4f/qPF3bvhWWc4Q7dJevXcViz7eWaJ9MZ
> BK5q7JpBLXskyfIpToPR
> =DOKC
> -----END PGP SIGNATURE-----
>

---

From: Nico Williams <[email-masked]>
Date: Wed, 7 May 2014 10:57:50 -0500

Watson,

How would you prevent PKI trust anchor set misconfiguration?  Or the
dreaded "give your money away to the bad guy?" pop-up?

One can always get anon ciphersuites by just taking a peer's cert with
no validation.  There's no way to prove to them that you did validate
their cert.  Of course, that's a rather expensive way to get anon
ciphersuites.

Nico
--

---

From: Michael D'Errico <[email-masked]>
Date: Wed, 07 May 2014 10:05:29 -0700

> their cert.  Of course, that's a rather expensive way to get anon

Yes, but it's riskier for a MitM to hope that a certificate isn't being
checked.  When they see "DH_anon" they know they can't be caught in the
act.

Mike

---

From: Nico Williams <[email-masked]>
Date: Wed, 7 May 2014 12:09:56 -0500

> checked.  When they see "DH_anon" they know they can't be caught in the

You're not listening.  Some of us have uses for anon ciphersuites.

Nico
--

---

From: Michael D'Errico <[email-masked]>
Date: Wed, 07 May 2014 10:20:27 -0700

> You're not listening.  Some of us have uses for anon ciphersuites.

I'm not against them.  Was just pointing out that you can make it
more difficult to MitM by appearing to do certificate validation.

Mike

---

From: Nico Williams <[email-masked]>
Date: Wed, 7 May 2014 12:28:23 -0500

> more difficult to MitM by appearing to do certificate validation.

Without anon ciphersuites we'll end up with more self-signed cert
usage.  Then what?  Ban those?  OK, then we'll end up with some other
arbitrary and equivalent convention.

Can we stop now?

---

From: Alyssa Rowan <[email-masked]>
Date: Wed, 07 May 2014 18:38:20 +0100

On 07/05/2014 18:09, Nico Williams wrote:

>> Yes, but it's riskier for a MitM to hope that a certificate isn't
>> being checked.  When they see "DH_anon" they know they can't be
>> caught in the act.

With the greatest respect, I'm simply not clear on why those uses are
best addressed that way.

For opportunistic encryption, at least with self-signed cert usage we
can then softly migrate from opportunistic to DANE-EE pinning - and
indeed that is the route SMTP has already taken, as Viktor's helpfully
highlighted.

Meanwhile aDH denies us that option, and broadcasts our MITM
susceptibility to Mallory.

tls-unique c/b may already need a big change anyway, thanks to
triple-handshake, I gather?

So, what use of anon_DH ciphersuites aren't addressed better by this
method, especially given the very clear additional perpass risk of
keeping them in TLS v1.3 that we've outlined here? How can we do better?

- -- 
/akr

---

From: Nico Williams <[email-masked]>
Date: Wed, 7 May 2014 12:57:48 -0500

> susceptibility to Mallory.

Don't negotiate anon ciphersuites if they are of no use to you.

Removing them because of misconfiguration fears is silly: there will
always be possible misconfigurations.  Please first address that
argument.  And the argument that I shouldn't have to pay for the
additional CPU cycles needed to do pointless (in these use cases) PK.

Nico
--

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 7 May 2014 18:16:51 +0000

> susceptibility to Mallory.

A Postfix SMTP server, whether it has TLSA RRs or not, almost always
has a certificate (for interoperability reasons), often self-signed.

Even though the server has a certificate, it still enables ADH and
AECDH cipher-suites.  Clients that don't authenticate the server
negotiate ADH or AECDH cipher-suites.  If the server happens to
publish TLSA RRs, some *clients* will omit ADH and AECDH from their
cipherlist because they are going to authenticate the server's
certificate.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 7 May 2014 18:47:48 +0000

On Wed, May 07, 2014 at 07:25:50PM +0100, Alyssa Rowan wrote:

> > publish TLSA RRs, some *clients* will omit ADH and AECDH from
> > their cipherlist because they are going to authenticate the
> > server's certificate.
> 
> ...and my point is, Mallory can trivially spot the difference and
> knows it can MITM those clients with impunity. That's more dangerous
> for perpass: specifically, ubiquitous surveillance of mail text and
> metadata via GCHQ's project TEMPORA.

This is not a compelling reason to remove protocol capabilities.
I am against banning power tools.  Build them as safely as possible
at reasonable cost.

Both NULL and ADH/AECDH ciphersuites have real use-cases.

  - NULL ciphers should never be offered in combination with non-NULL
    ciphers.

  - ADH/AECDH ciphers are building blocks for using TLS with channel-
    binding to implement non-X.509 authentication systems.  They
    also reduce server work-factor and handshake bloat when
    opportunistic clients don't check certificates.  Cipher-suite
    signalling is just one of many ways that Mallory can determine
    which clients she can attack undetected.

-- 
	Viktor.

---

From: Alyssa Rowan <[email-masked]>
Date: Wed, 07 May 2014 20:04:02 +0100

> This is not a compelling reason to remove protocol capabilities.

I think that they are insecure _is_ a compelling reason: we seem
simply to disagree on that point.

More interestingly:

> Cipher-suite signalling is just one of many ways that Mallory can
> determine which clients she can attack undetected.

I wonder, what other ways are there; and how can we stop them, too?

- -- 
/akr

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 7 May 2014 15:10:11 -0400

> I think that they are insecure _is_ a compelling reason: we seem simply to disagree on that point.

No, I think there is disagreement as to whether or not they are insecure. Counter-examples include a server-initiated challenge-response (such as good old S/Key), PGP encrypted mail over SMTP, and so on. 

	/r$

--  
Principal Security Engineer
Akamai Technologies, Cambridge, MA
IM: [email-masked]; Twitter: RichSalz

---

From: Alyssa Rowan <[email-masked]>
Date: Wed, 07 May 2014 20:22:44 +0100

On 07/05/2014 20:10, Salz, Rich wrote:
> No, I think there is disagreement as to whether or not they are
> insecure.

Because the application layer provides all its own security?

Then why would it need TLS; decoration for middleboxes¹?

> PGP encrypted mail over SMTP

Perhaps a poor example: payload protected end-to-end by OpenPGP, but
interesting cleartext metadata protected hop-by-hop by TLS.

___
1. In all fairness, that _is_ a perfectly valid, if somewhat hacky,
   reason. I may have answered my own question here.

- -- 
/akr

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 7 May 2014 19:24:28 +0000

> simply to disagree on that point.

There is no such thing as "secure" or "insecure" without context.
Opportunistic TLS offers protection against passive attacks that
cleartext does not.  It makes no promises about active attacks.

> I wonder, what other ways are there; and how can we stop them, too?

You can't, these attacks are above the TLS layer.  It is not
difficult for active attackers to downgrade opportunistic TLS to
cleartext.

What we can do, is promote the adoption of approaches like
opportunistic DANE TLS, which adds peer-by-peer MiTM protection to
an opportunistic security model.  If widely implemented, this may
lead to broad MiTM protection by default, but we're very early in
the adoption curve.  I know of only 25 domains with DANE TLSA
records for SMTP.

-- 
	Viktor.

---

From: Nico Williams <[email-masked]>
Date: Wed, 7 May 2014 15:24:08 -0500

> Because the application layer provides all its own security?

It provides its own authentication, but not its own security layer.

> Then why would it need TLS; decoration for middleboxes¹?

Because it's simpler this way.

SASL used to provide a "security layer".  It's now deprecated because
it only led to problems:

a) double encryption in some cases (since SASL apps generally also use TLS)
b) extra code in the application and the SASL mechanism, all variously
duplicating TLS functionality, not always well done.

With channel binding both of those go away.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Wed, 7 May 2014 17:07:46 -0500

> simply to disagree on that point.

I disagree with your characterization.

>> determine which clients she can attack undetected.

No.  Mallory can only see that anon ciphersuites where offered.
Mallory cannot conclude from this that anon ciphersuites will be
accepted (the peer might disconnect if an anon ciphersuite is
negotiated) nor can Mallory conclude that channel binding (or renengo)
won't be used in that session.  It's always a risk for Mallory to
attempt an MITM attack.

Nico
--

---

From: Watson Ladd <[email-masked]>
Date: Wed, 7 May 2014 15:33:56 -0700

> With channel binding both of those go away.

But you get a new issue: channel binding doesn't work with all
ciphersuites because of the DHE validation issue. I think SASL is
important enough to support anonymous ECDH, and maybe anonymous DH if
we can fix it. However, using it without authenticating endpoints
isn't getting anything.

Sincerely,
Watson Ladd

---

From: Nico Williams <[email-masked]>
Date: Wed, 7 May 2014 17:42:07 -0500

> ciphersuites because of the DHE validation issue. I think SASL is

Can you be more specific?  What DHE validation issue?

> we can fix it. However, using it without authenticating endpoints

Please explain in detail.  Channel binding involves authentication of
entities at the application layer -- authentication is done there, so
why must it be done by TLS?

Nico
--

---

From: Watson Ladd <[email-masked]>
Date: Wed, 7 May 2014 16:10:11 -0700

> Can you be more specific?  What DHE validation issue?

Currently DHE groups aren't validated. As a result it is possible for
the server to force the premaster secret to be just about anything.
This breaks the tls-unique channel binding after resumption.

> why must it be done by TLS?

Sorry, "it" was referring to anonymous DH.

Sincerely,
Watson Ladd

---

From: Watson Ladd <[email-masked]>
Date: Wed, 7 May 2014 16:12:40 -0700

> won't be used in that session.  It's always a risk for Mallory to

So they do the MITM, see that SASL is being used, the connection
breaks, and then what?

Or they do the MITM, the peer disconnects because they didn't really
mean it anyway, and then what?

Sincerely,
Watson Ladd

---

From: Nico Williams <[email-masked]>
Date: Wed, 7 May 2014 18:14:01 -0500

> This breaks the tls-unique channel binding after resumption.

It would have been easier if you're referred to this as the resumption bug.

I'm assuming this will get fixed.  Are you assuming it won't?  Please explain.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Wed, 7 May 2014 18:15:58 -0500

> So they do the MITM, see that SASL is being used, the connection

And then the user only observes the re-connect or the failure.  Either
way the user did not fall to an MITM attack.

> mean it anyway, and then what?

The user doesn't get MITMed.

Alternative the client was trying to get opportunistic security, and
speaking to an MITM is better than sending cleartext (which would have
been the alternative).

Nico
--

---

From: Watson Ladd <[email-masked]>
Date: Wed, 7 May 2014 16:39:53 -0700

> I'm assuming this will get fixed.  Are you assuming it won't?  Please explain.

If it gets fixed anonymous DH will work just fine for channel binding:
the premaster secret will always be unique.

Sincerely,
Watson Ladd

---

From: Nico Williams <[email-masked]>
Date: Wed, 7 May 2014 18:42:19 -0500

> the premaster secret will always be unique.

Clearly.  No one disagrees with that.  You're making statements that
implicitly assume it's not fixed, so I want to know if you're assuming
it won't be fixed.

Also, really, this is an ancillary issue being dealt with in a
separate thread.  It's NOT germane to your proposal to remove features
that the rest of us don't want removed.  Please address the arguments
against removal.

Nico
--

---

From: Watson Ladd <[email-masked]>
Date: Wed, 7 May 2014 16:48:02 -0700

> that the rest of us don't want removed.  Please address the arguments

I changed my mind about anonymous DH: it's useful enough in SASL to
keep. You replied to a message that had this sentence in it.

I think the null encryption cipher should definitely stay out: the
only use I've heard of is extremely niche, namely large datasets with
slow CPUs on both ends.

SIncerely,
Watson Ladd

---

From: Nico Williams <[email-masked]>
Date: Wed, 7 May 2014 19:01:00 -0500

> I changed my mind about anonymous DH: it's useful enough in SASL to

Good.  That's a relief.  You and I both can change our minds about such things.

> keep. You replied to a message that had this sentence in it.

"If it gets fixed anonymous DH will work just fine for channel
binding: ..."  -- I didn't take that to mean that you'd changed your
mind, only that you were explaining something [that I already knew].

> only use I've heard of is extremely niche, namely large datasets with

I have no opinion yet as to null encryption ciphersuites.  In general
I think they are best left out, but I should hear more about their
uses before agreeing to remove them.

Nico
--

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 8 May 2014 00:15:32 +0000

> only use I've heard of is extremely niche, namely large datasets with

Any bulk transfer application that wants to work at wire rates to
move already encrypted data with authentication of the endpoints.

The solution to avoid accidental use of NULL ciphers is in the
client API, no client HELLO should ever include a mixture of NULL
and non-NULL ciphers-suites.

The "let's remove everything that I personally don't use" crusade
seems rather heavy-handed.  Successful general-purpose protocols
have more knobs than niche protocols.  That's the cost of success.

-- 
	Viktor.

---

From: Watson Ladd <[email-masked]>
Date: Wed, 7 May 2014 17:58:43 -0700

> and non-NULL ciphers-suites.

Why not make that a MUST in the RFC, and the same for anonymous DH? I
think this solves most of the configuration issues without making any
uses impossible.

To those who haven't been following along that means the following:
1: Your ciphersuite list can have either authenticated or
unauthenticated ciphers, but cannot have both.
2: It can have null encryption or use encryption, but not both.
3: If you try to break the above rules, the remote side (assuming it
is compliant) bails out.

I can live with that: it makes accidental misconfiguration cause
everything to stop working, thus preventing a quiet misconfiguration
incident.
> have more knobs than niche protocols.  That's the cost of success.

Maybe if TLS wasn't "successful" we wouldn't have had the terrible
track record on security, because it would be simple enough to
understand and see the problems. That's vastly preferable to having
problems that will continue to bite us for years because broken
versions of the protocol were widely deployed.

Sincerely,
Watson Ladd

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 7 May 2014 21:06:51 -0400

>> The solution to avoid accidental use of NULL ciphers is in the client 
>> API, no client HELLO should ever include a mixture of NULL and 
>> non-NULL ciphers-suites.

> Why not make that a MUST in the RFC, and the same for anonymous DH?
> I think this solves most of the configuration issues without making any uses impossible.

I think this is worth serious consideration.

	/r$

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 8 May 2014 01:23:18 +0000

On Wed, May 07, 2014 at 05:58:43PM -0700, Watson Ladd wrote:

> Why not make that a MUST in the RFC

No objection there, the use of NULL ciphers is typically by mutual
agreement between cooperating peers.  They are disabled by default,
and both ends have to enable them, with the client enabling *only*
NULL ciphers where applicable.

> And the same for anonymous DH?

Sadly this does not work.  Clients often don't know whether the
server supports any ADH cipher-suites or not.  Sending only ADH is
going to result in handshake failure.

> I think this solves most of the configuration issues without making any

Yes, for NULL ciphers.

> unauthenticated ciphers, but cannot have both.

No on this one.  That makes ADH/AECDH unusable.

> 2: It can have null encryption or use encryption, but not both.

This is what I am proposing as an implementation feature in the
client API.  It need not be a protocol feature.

> 3: If you try to break the above rules, the remote side (assuming it

Just rule "2", not rule "1".

If you absolutely must remove something, I don't know of any
plausible use-case for the following cipher-suite:

    $ openssl ciphers -v aNULL+eNULL
    AECDH-NULL-SHA          SSLv3 Kx=ECDH     Au=None Enc=None      Mac=SHA1

This just MACs each message post an authenticated key exchage.  So
you get all or nothing message integrity.

When Postfix enables eNULL it always disables aNULL, so this
cipher-suite is never turned on.  I don't think there is either a
good reason to continue to to support this, or a real benefit to
"banning" it.

-- 
	Viktor.

---

From: Yoav Nir <[email-masked]>
Date: Thu, 8 May 2014 09:40:57 +0300

> I think this is worth serious consideration.

I agree that it’s worth consideration, but we have to be clear on what we’re making a MUST here.

We can mandate that clients don’t mix NULL and non-NULL ciphersuites in the ClientHello. In that case, if some client does send a mixture of NULL and non-NULL, we can point to the implementers and say “your client is not compliant with the RFC”. And they could reply that it’s possible to configure their client to comply. I don’t know how much that helps security, but it seems like a strange way to force something that is basically a  UI/API issue. BTW: does 40-bit export level DES go with the NULL or the non-NULL? Don’t answer that. That’s just me being facetious.

The other thing we could mandate is that servers validate the ClientHello, to make sure that it doesn’t contain ciphersuites of both kinds. That would actually help, because it would drive misconfigured clients off the Internet rather than into potentially insecure modes, but that’s one reason server makers would resist having this change.

Regarding ADH I’m not sure. It makes sense that clients that don’t require server identity should not be blocked just because the server insists on authenticating itself. OTOH you could make the same argument for clients that don’t require confidentiality. So I don’t know where I stand on this.

Yoav

---

From: Manuel Pégourié-Gonnard <[email-masked]>
Date: Thu, 08 May 2014 10:28:14 +0200

> keeping them in TLS v1.3 that we've outlined here? How can we do better?
Side note: it seems to me that perpass is short for pervasive passive
(surveillance). Would you say the MitM risk you're describing here qualifies as
passive? (It might still be cheap enough to be implemented at a large scale by
some organisations doing pervasive surveillance, which is a serious problem indeed.)

Anyway, I'm not sure an adversary needs aDH as a marker to rather efficiently
guess which clients are going perform some kind of server authentication: for
example, if the server's cert is self-signed, and the client doesn't perform a
TLSA lookup, and the client and the server don't belong to the same
organisation, it's quite likely that the client isn't validating. I don't think
an adversary needs to be 100% sure here. They can probably also just try to MitM
clients and remember for which ones it worked.

Manuel.

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 8 May 2014 09:47:15 -0400

Yes, perhaps a new alert, e_wtf, MUST/SHOULD be sent if a client offers a nonsensical combination.

Less flippantly a new AlertDescription, unsupported_policy, that can be used during a handshake to indicate that a combination of ciphers, extensions, etc., is not acceptable.  We could say a server MUST send it if a client in the null/non-null case. But this lets us add other policy concerns in a compatible  way.

	/r$

---

From: [email-masked] (Martin Rex)
Date: Thu, 8 May 2014 16:44:14 +0200 (CEST)

> additional CPU cycles needed to do pointless (in these use cases) PK.

The latter argument is extremely bogus.

CPU cycle-wise, the by-far cheapest option for the client is to
offer only static RSA cipher suites and entirely skip the validation
of the server's certificate, because that is a single public-key RSA
operation for the client.

We _already_ have a strong warning against DH_anon cipher suites in
the TLS v1.2 spec:

  https://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.)

The problem with unsolicited DH_anon cipher suites being available to
an unsuspecting application is that it may easily allow bypassing of
the check of the server certificate depending on the API architecture
of the SSL stack and how it is used by the application.

Configurability of cipher suites (such as HIGH) for administrators
MUST NOT allow enabling of DH_anon cipher suites, because this is
a request _by_the_administrator_, and not _by_the_application_.
DH_anon cipher suites should only be made available, if at all,
when the application *CODE* explicitly calls a non-standard
API call that signals to the TLS stack, that the application code
knows about the resulting semantics and can properly deal with
the resulting behaviour.

I also believe that the current behaviour of OpenSSL, to enable DH_anon
cipher suites when the cipher suite configuration string "HIGH" is
used, is extremely unsafe.

DH_anon have two more serious drawbacks compared to ignoring an untrusted
server certificate:  the client can not even "pin" the server's certificate
for future connections to the same server (i.e. only an initial leap-of-faith),
and it completely precludes the use of a client certificate to authenticate
the client to the server.

My very personal opinion is that DH_anon cipher suites are pure bloat
without value.  We do not even implement them in our TLS implementation.
But I'm OK with what rfc5246 says about them in the paragraph quoted above.
Implementors can just leave them away from their implementations, and
the consumers will be *MUCH* better of with the result. 

I do not see the value in making this availble for an extremely small
group of experts like Niko who could devise niche usage scenarios where
_they_ could operate them safely with hand-selected and manually hardened
application software, compared to the inherent danger to the large
unwashed masses (of consumers and app-software).

-Martin

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 8 May 2014 16:05:39 +0000

> of the SSL stack and how it is used by the application.

We're back to implementation issues, which should be addressed by
implementations.  In OpenSSL for example the "DEFAULT" cipher-suite
omits anonymous cipher-suites.  Non-default cipher-suites are
configured by the application.

The Postfix SMTP client, for example, automatically appends ":!aNULL"
to the application-administrator configured cipher-suite when it
wants to elicit a certificate from the remote SMTP server.  The
Postfix SMTP server automatically appends ":!aNULL" when it wants
to solicit a client certificate from the remote SMTP client.

This is not rocket science.  If you want to add similar safety
measures in new high-level APIs, that's fine.  I still see no reason
to neuter the protocol.

> a request _by_the_administrator_, and not _by_the_application_.

The OpenSSL domain-specific-language for specifying cipher-lists
provides a set of elementary properties that can be use to construct
cipher lists by combining atoms with "+" (AND) and combining those
with ":" (OR), with special semantics for leading "-" and "!".

It is somewhat unfortunate that some think of "HIGH" as a way of
specifying high security, all it does is select symmetric algorithms
with long keys.  This is a user-interface issue.

There is new code in master that provides security levels, rather
than cipher-suite list building blocks.

> knows about the resulting semantics and can properly deal with

Still not a reason to remove these from the protocol.

> used, is extremely unsafe.

I doubt you don't understand "HIGH", so you're likely alluding to
the fact that many others might not.  That's fine, OpenSSL ciphersuite
configuration is too difficult for most users, that's an API issue
and an application design issue (when applications simply pass the
buck to the user).

> the client to the server.

Not much use if the application has no code for pinning and no
mechanisms to interact with a "user" when pins fail.

> without value.  We do not even implement them in our TLS implementation.

Right more "I don't use it, so out it goes".  The protocol and many of its
implementations are general purpose and serve many use-cases.  Custom
implementations that make different trade-offs are fine, but are not
a valid rationale for neutering the protocol or all implementations.

> the consumers will be *MUCH* better of with the result. 

This is certainly true in application-specific products, less so
in general-purpose libraries.

> group of experts like Nico who could devise niche usage scenarios where

Well, GSSAPI with channel-binding and without certs is not so
exotic.  Nor is opportunistic TLS in MTAs.  I think it is quite
clear that removing ADH and AECDH is an overzealous reaction
to heartbleed.

If there are concerns about interface safety in particular
implementations, they need to be addressed in the right place.
(Sometimes in applications rather than in libraries, in which
case the library documentation may need to provide better
application guidance).

-- 
	Viktor.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 8 May 2014 09:31:43 -0700

> Yes, perhaps a new alert, e_wtf, MUST/SHOULD be sent if a client offers a nonsensical combination.

I think that is actually necessary.  If you intend to prohibit
behaviour, it's best if that's enforced.  That way the chances of
non-conformant behaviour is less likely to propagate.  e_wtf sounds
like a good name.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 08 May 2014 18:03:21 +0100

On 08/05/14 09:28, Manuel Pégourié-Gonnard wrote:
> (surveillance).

I wouldn't sweat about that term. Its just the imperfect name
I made up for a mailing list back last summer. It does get used
sometimes as a shorthand when we probably would be better saying
something longer that uses the term pervasive monitoring, (which
is not just passive as you point out) but that's ok for list
discussion.

S.

---

From: "Blumenthal, Uri - 0558 - MITLL" <[email-masked]>
Date: Thu, 8 May 2014 17:09:14 +0000

Hmm... Monitoring by definition *is* passive.

MITM implies the *ability* to tamper with the traffic, which goes beyond
the mere listening capability.

---

From: Manuel Pégourié-Gonnard <[email-masked]>
Date: Thu, 08 May 2014 20:12:21 +0200

> is not just passive as you point out) but that's ok for list
Ok, thanks for this precision.

Manuel.

---

From: Russ Housley <[email-masked]>
Date: Sat, 10 May 2014 19:53:37 -0400

> I think this solves most of the configuration issues without making any uses impossible.

This seems like a good way forward.

Russ

---

From: Bill Frantz <[email-masked]>
Date: Sun, 11 May 2014 18:43:33 -0700

>ADH is an order of magnitude more than those who actually wanted it.

There are times where encrypting information to obscure its 
meaning is illegal. One place it is illegal is in amateur radio 
communications. The FCC recently reaffirmed its ban on 
encryption for message obfuscation, so this situation is not 
likely to change soon.

The problem comes when amateur radio is used as a fall back for 
emergency communications. There are times when emergency 
management agencies communications facilities are either 
overloaded or fail completely and they turn to amateurs for help.

Currently most of the help they get is via classical message 
passing via voice, morse code, or digital radio -- which can be 
done in the clear. But things are moving from handing a person a 
message to be sent to wanting to send data -- spreadsheets etc. 
A number of amateur radio emergency groups are experimenting 
with mesh networks, which us IP as their underlying protocol. 
The NULL cypher suites are ideal because they provide 
authentication, and replay prevention.

Now I recognize that there is a significant footgun in having 
NULL cypher suites in a mix of protocols offered by a client. 
One way to reduce the risk is to say, "The server MUST reject 
any connection attempt where the offered cypher suites include 
both suites providing encryption and those which have NULL 
encryption. I notice from Viktor's email that postfix already 
separates its suites this way.

Cheers - Bill

-----------------------------------------------------------------------
Bill Frantz        |Security, like correctness, is| Periwinkle
(408)356-8506      |not an add-on feature. - Attr-| 16345 
Englewood Ave
www.pwpconsult.com |ibuted to Andrew Tanenbaum    | Los Gatos, 
CA 95032

---

From: Michael D'Errico <[email-masked]>
Date: Sun, 11 May 2014 20:04:03 -0700

Bill Frantz wrote:
> 
> Now I recognize that there is a significant footgun in having NULL 
> cypher suites in a mix of protocols offered by a client. One way to 
> reduce the risk is to say, "The server MUST reject any connection 
> attempt where the offered cypher suites include both suites providing 
> encryption and those which have NULL encryption.

Why not have the server choose a non-NULL cipher suite if both types
are offered instead of rejecting the connection?

Mike

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 12 May 2014 03:16:54 +0000

On Sun, May 11, 2014 at 08:04:03PM -0700, Michael D'Errico wrote:

> Bill Frantz wrote:
> >
> >Now I recognize that there is a significant footgun in having NULL cypher
> >suites in a mix of protocols offered by a client. One way to reduce the
> >risk is to say, "The server MUST reject any connection attempt where the
> >offered cypher suites include both suites providing encryption and those
> >which have NULL encryption.
> 

I am not convined that any special action should be taken on the
server side.  My original suggestion was that client implementations
could by default attempt to catch some configuration errors (user
interface improvement).  Server-side enforcement (effectively a
protocol change) is likely unnecessary complexity.

There may even be use-cases in which the client prefers authenticated
NULL ciphers, but if the choice is between a handshake failure or
being forced to encrypt, is willing to encrypt.  I expect this to
be quite rare, but there is no compelling reason to rule this out.

Clients that offer NULL ciphers to servers not a-priori known to
support them will almost always find their offer declined.

So on balance I don't think it would be appropriate to *require*
any particular server behaviour here, however implementations MAY
implement optional features that enforce sensible policies at either
end.

-- 
	Viktor.

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Tue, 13 May 2014 12:41:05 -0400

> indeed that is the route SMTP has already taken, as Viktor's helpfully

this soft migration can happen by moving from anonymous key exchanges to
non-anonymous key exchanges when they publish their DANE-EE pin, though.

> susceptibility to Mallory.

I think this is more an argument that the ciphersuite negotiation
shouldn't be in the clear than it is an argument to reject an aDHE key
exchange scheme.

I recognize that there are chicken-and-egg issues here, but it seems
possible to protect the handshake itself with a non-negotiable
mandatory-to-implement scheme that protects at least against passive
monitoring, and then allow the rest of the communication the flexibility
for algorithm agility.

With proper traffic padding, this would avoid broadcasting any
MITM-susceptibility to Mallory without Mallory actively making a
(potentially detectable) MITM attack herself.

	--dkg

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 14 May 2014 02:22:22 +0000

> that is protected inside HTTPS.

Right on queue:

    https://www.facebook.com/notes/protect-the-graph/the-current-state-of-smtp-starttls-deployment/1453015901605223

I was fairly sure my number of 20% was conservative, now Facebook
measures it at 58%:

    We found that 76% of unique MX hostnames that receive our emails
    support STARTTLS. As a result, 58% of notification emails are
    successfully encrypted. Additionally, certificate validation
    passes for about half of the encrypted email, and the other
    half is opportunistically encrypted. 74% of hosts that support
    STARTTLS also provide Perfect Forward Secrecy.

It is perhaps time to retire the belief that TLS for email is in
a "sad state".  Of course it would be nice to also have authentication,
but for that we need DNSSEC deployment and publication of TLSA RRs.

An ISP (posteo.de) deployed the first email transport authentication
"fax-machine" this week:

    http://www.heise.de/newsticker/meldung/Verschluesselter-Mail-Transport-Posteo-setzt-als-erster-Provider-DANE-ein-2187144.html

they can now deliver email securely to debian.org, and any day now
ietf.org, plus a smattering of smaller domains operated by individual
DANE early adopters (welcome to the club Alyssa).

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 14 May 2014 02:49:13 +0000

> Right on queue:

    s/queue/cue/

Too much time spent hacking email, fingers automatically type "queue".

-- 
	Viktor.

---

From: Watson Ladd <[email-masked]>
Date: Tue, 13 May 2014 20:06:08 -0700

> but for that we need DNSSEC deployment and publication of TLSA RRs.

So 0% of the email is actually protected from being read by anyone on
the network. (well, modulo PGP). In another 20 years we might have a
solution deployed.

And for this you want to run the risk of using aDH?

Sincerely,
Watson Ladd

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 14 May 2014 11:01:35 +0100

Good stuff. And thanks to FB for measuring and making this
public, be great if they wanted to do this now and then to
see how what trends emerge and/or if others did similarly.

S.

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 16 May 2014 12:33:39 +0000

> the network. (well, modulo PGP). In another 20 years we might have a

You have an odd definition of "protected".  Protection of content
from passive monitoring is not an insignificant benefit.

In the mean-time a second German email provider has enabled DANE
(two this week), so now all posteo.de deliveries to mailbox.org
are authenticated.  While that may be "0%" overall, it is not
0% for posteo.de.

> And for this you want to run the risk of using aDH?

Deja vu all over again.  (No the reasons is to not destroy TLS as
a transport for channel-binding + application-level authentication,
the fact that Postfix offers and accepts aDH in opportunistic mode
is rather secondary, and we've already had this discussion...).

-- 
	Viktor.