Subject: [perpass] Hasty PRISM proofing considered harmful

From: Paul Hoffman <[email-masked]>
Date: Tue, 22 Oct 2013 08:26:57 -0700

This was posted last night by Viktor Dukhovni on the cryptography mailing
list, but is certainly applicable here. Forwarded with Viktor's permission.

====================

There have been many recent efforts to harden the cryptographic
security of various systems.  I would like to urge anyone considering
taking steps in that direction to exercise due caution.

Multiple recent attempts at improvement backfire in various ways:

   - RedHat has been under pressure for some time to enable EC support
     in their OpenSSL RPM package.

    * They finally relented and added EC support ~1 week ago.  However,
      they quickly decided to play it safe and enable just the Suite-B
      curves: secp256r1, secp384r1 and no others.

    * They neglected to consider that the new libraries now
      happily negotiate EECDH key exchange TLS cipher-suites with
      servers that typically don't know of (or can't act on) the
      client's limitations.

    * At the same time newly hardened SMTP servers at gmx.de
      and other sites have "stronger" security by switching to
      secp521r1.

      # Result: SMTP TLS handshakes break, and more mail goes out in
        the clear!

      # With TLS, no EC is better than crippled EC.

   - GnuTLS sets aggressive client-side EDH prime-size lower bound.

    * Exim encounters interoperability problems and works-around
      the setting by allowing 1024-bit EDH in SMTP clients while
      using 2048-bit EDH in the server (which generally works for
      SMTP).

    * Debian decides to improve security in Exim and raises this
      to 2048-bits, breaking interoperability again.

       # Result:  Since SMTP TLS is generally opportunistic, when
         TLS handshakes break, more mail is transmitted in the clear!

   - Some email administrators disable RC4 (enable only the OpenSSL "HIGH"
     ciphers) in opportunistic TLS.  Many extant Microsoft Exchange servers
     support only RC4-SHA1, RC4-MD5 and 3DES (whose implementation is
     breaks post handshake in data transfer).

       # Result: TLS handshakes fail, and mail is sent in the clear.

   - There's lots of press about CRIME, BEAST, ... and some SMTP
     administrators configure their systems to prefer RC4 and
     avoid CBC ciphersuites.

    # The attacks in question are primarily HTTPS attacks,
    cryptanalysis of RC4 may well be the greater threat to SMTP.

There are I expect similar examples of good intentions, but poor
outcomes outside the world of SMTP.  Raising the bar on Internet
security will take considerable time and effort.  Updated standards
will have to be developed, toolkits extended to support them and
applications updated.  Rolling improved security out to end-users
will likely take on the order of a decade.

In the mean-time, users should make an effort to configure their
systems to employ current best-practice security, trying to go
beyond that into uncharted territory may well be counter-productive.

Endpoint security and misuse of data at rest are still IMHO the
bigger issues.  I am much more concerned about the proliferation
of miniature programmable computers inside our computers (CPUs and
programmable firmware in disk controllers, battery controllers,
BMC controllers, with opaque binary firmware update blobs, and
complex supply chains) that about secp256r1 vs secp521r1.

We thought embedded devices were for physical infrastructure
engineers to worry about, but now they are proliferating inside
our general purpose computers.  The next Stuxnet will run on one
of the invisible computers inside your computer.

With concerted effort we can improve the crypto protocols, but will
it matter if the architecture on top of which the crypto runs has
an ever growing attack surface.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 22 Oct 2013 17:46:58 +0100

Yep, that's a useful post - we shouldn't rush too much,
but we do want to get things done so that developers
and deployers have something to use.

I wonder what's the best way to proceed with this kind
of stuff. I guess we want a BCP of some sort, but the
question is how to handle the various different cases
of foo-with-tls.

- Yaron did a generic TLS BCP draft. [1]
- PSA did an XMPP TLS BCP draft [2]
- This sounds like we might want an SMTP TLS BCP draft
  or perhaps to add text to [3], but that's aiming for
  experimental and is just about using DANE.

So at present we're heading towards a bunch of foo-with-tls
BCPs. Could those usefully be merged or are they better
kept separate?

Thoughts?

S.

[1] https://tools.ietf.org/html/draft-sheffer-tls-bcp
[2] https://tools.ietf.org/html/draft-saintandre-xmpp-tls
[3] https://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane

On 10/22/2013 04:26 PM, Paul Hoffman wrote:
> _______________________________________________
> perpass mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/perpass
>

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 22 Oct 2013 11:53:29 -0700

I could certainly do a rfc3207bis document, or participate in a
foo-over-tls omnibus. But, as Viktor points out, it's probably going to be
a bit less self-congratulatory than we might have expected.

---

From: John-Mark Gurney <[email-masked]>
Date: Tue, 22 Oct 2013 14:49:47 -0700

> list, but is certainly applicable here. Forwarded with Viktor's permission.

Is anyone working on an interop spread sheet?  Like limitations and
others...  I was looking at sendmail's TLS and realized it did 1024
DH (server) and 512 DH (client), but increasing DH beyond 1024 is a
problem since Java can't handle 1024 bit DH...

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 23 Oct 2013 12:52:02 +0100

Hi Stephen,

>    experimental and is just about using DANE.
I think some generic fallback rules can be protocol independent. But 
needs of different protocols might be different. For example backward 
compatibility with deployed TLS ciphers might be different for XMPP and 
SMTP.

I think SMTP TLS BCP would be a good idea. I think it should be 
independent of DANE, because of the status of the DANE document. I would 
be happy to work on it (and would be happy to collaborate with PSA to 
discuss similarities and differences).

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 23 Oct 2013 13:02:33 +0100

> compatibility with deployed TLS ciphers might be different for XMPP and

Sounds reasonable. I guess even if they have the same libraries
the update cycles might differ. (Anyone know?)

> discuss similarities and differences).

Great. Let's talk in YVR about how to get that done so
its a real BCP that gets followed in the wild. If someone
else is up for helping I guess contact Alexey.

Cheers,
S.

---

From: Harry Halpin <[email-masked]>
Date: Wed, 23 Oct 2013 14:02:46 +0200

On 10/22/2013 05:26 PM, Paul Hoffman wrote:
> This was posted last night by Viktor Dukhovni on the cryptography 
> mailing list, but is certainly applicable here. Forwarded with 
> Viktor's permission.
>

Very good post - although the main problem seems to be fallback to 
cleartext in SMTP due to lack of co-ordination, not attempting better 
support of crypto.  Although this has historically not been the case, 
perhaps users may start wanting draconian error-handling as regards 
encrypted email between the client and server as a default. IMHO that is 
the only factor that could force co-ordination of better support of 
larger keys in the client and ECC curves. Obviously, this option already 
exists in most mail clients - yet users are typically unaware of the 
distinction (and the confusing terminological history re enforcement of 
TLS and StarTLS upgrading). While perhaps more draconian error-handling 
would help in standards rather than assuming cleartext fallback, it 
seems the real failure here is a usability issue with many mail clients 
where users are unaware their mail is being sent in the clear.

Right now, at least on Linux, Mozilla has effectively it seems stopped 
development on Thunderbird (truly a shame) so there's virtually no 
usable email clients.  Are folks aware of any that make "forcing TLS 
encryption" both the default and offer severe warnings if it fails?

> <http://gmx.de>

---

From: Paul Wouters <[email-masked]>
Date: Wed, 23 Oct 2013 10:47:52 -0400 (EDT)

On Tue, 22 Oct 2013, Paul Hoffman wrote:

[ With my Red Hat on but using personal email to prevent moderation queues ]

>       curves: secp256r1, secp384r1 and no others.

Note that "quickly decided" is a little judgemental and unfair. Enabling
ECC has been at least a year in the making. It predates Snowden.

>       servers that typically don't know of (or can't act on) the

The elliptic_curves extension informs a server which curves the client
supports, and openssl uses that extension. So that should not be a
problem. However, Hubert Kario found out that we advertise support for
curves that are not actually supported. We are addressing that bug now:

https://bugzilla.redhat.com/show_bug.cgi?id=1022468
Openssl advertises support for curves it doesn't actually support in Client Hello (edit)

Remember, bugs are resolved faster if reported properly. Please feel
free to contact me regarding any security/crypto bugs in RHEL/Fedora
and I'll ensure proper bugs are filed and tracked.

>       and other sites have "stronger" security by switching to

With the above bug addressed, it should select a non-ECC cipher suite.

> Rolling improved security out to end-users will likely take on the order of a decade.

Wow, that's rather pessimistic :P

> beyond that into uncharted territory may well be counter-productive.

Users should not do so. Vendors should do it for them. Users who tweak
crypto parameters manually are not users - they are developers.

Paul

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 24 Oct 2013 12:03:43 -0600

On 10/23/13 6:02 AM, Stephen Farrell wrote:
>>> Yep, that's a useful post - we shouldn't rush too much, but we
>>> do want to get things done so that developers and deployers
>>> have something to use.
>>> 
>>> I wonder what's the best way to proceed with this kind of
>>> stuff. I guess we want a BCP of some sort, but the question is
>>> how to handle the various different cases of foo-with-tls.
>>> 
>>> - Yaron did a generic TLS BCP draft. [1] - PSA did an XMPP TLS
>>> BCP draft [2] - This sounds like we might want an SMTP TLS BCP
>>> draft or perhaps to add text to [3], but that's aiming for 
>> I think some generic fallback rules can be protocol independent.
>> But needs of different protocols might be different. For example
>> backward compatibility with deployed TLS ciphers might be
>> different for XMPP and SMTP.
> 
> Sounds reasonable. I guess even if they have the same libraries the
> update cycles might differ. (Anyone know?)

I expect that the update cycles are indeed different.

I don't particularly *want* to have different BCPs for different
protocols, and personally I'd like to see as much commonality as
possible (with everyone pointing to Yaron's generic document).
However, there are some application-level differences (e.g., with
regard to session resumption) and each community (email, IM, web,
etc.) has had a different experience with the use of TLS, including
varying release schedules or willingness to release more often, use of
STARTTLS vs. separate ports, bigger or smaller networks, more or less
diverse developer community (e.g., with no one dominant implementation
or small set of implementations), client-to-server only communications
vs. also server-to-server federation, varying user expectations, etc.

>> independent of DANE, because of the status of the DANE document.
>> I would be happy to work on it (and would be happy to collaborate
>> with PSA to discuss similarities and differences).
> 
> Great. Let's talk in YVR about how to get that done so its a real
> BCP that gets followed in the wild. If someone else is up for
> helping I guess contact Alexey.

Before this thread emerged, I suggested the idea of having a chat
about this topic during the AppsArea session on Monday morning (and
BTW there are no SEC area sessions opposite). That might be a good
place to start.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: Ted Hardie <[email-masked]>
Date: Thu, 24 Oct 2013 12:43:31 -0700

> BTW there are no SEC area sessions opposite). That might be a good
Are you thinking of this in terms of MSAs in the RFC 6409 sense, as well as
MTAs?   Though SMTP is used for both, the usefulness of things like DANE is
likely to be different in the different contexts.

That hints, unfortunately, that there is a strong possibility that the best
current practice may be best specified in relation to a specific use of a
protocol rather than generally to the protocol.

regards,

Ted

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 24 Oct 2013 14:01:16 -0600

On 10/24/13 1:43 PM, Ted Hardie wrote:
> On Thu, Oct 24, 2013 at 11:03 AM, Peter Saint-Andre
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
>>> I think SMTP TLS BCP would be a good idea. I think it should
>>> be independent of DANE, because of the status of the DANE
>>> document. I would be happy to work on it (and would be happy to
>>> collaborate with PSA to discuss similarities and differences).
>> 
>> Great. Let's talk in YVR about how to get that done so its a
>> real BCP that gets followed in the wild. If someone else is up
>> for helping I guess contact Alexey.
> 
> about this topic during the AppsArea session on Monday morning
> (and BTW there are no SEC area sessions opposite). That might be a
> good place to start.
> 
> 
> Are you thinking of this in terms of MSAs in the RFC 6409 sense, as
> well as MTAs?

I'm thinking about what Keith Moore posted in draft-moore-email-tls.
So yes, MSAs in the RFC 6409 sense (but also covering IMAP and POP).

> Though SMTP is used for both, the usefulness of things like DANE is
> That hints, unfortunately, that there is a strong possibility that
> the best current practice may be best specified in relation to a
> specific use of a protocol rather than generally to the protocol.

So it seems.

We all need to up our game, but each of us might need to do so in
different ways.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: [email-masked]
Date: Thu, 24 Oct 2013 19:15:00 -0700 (PDT)

> likely to be different in the different contexts.

Quite right. SUBMIT is best thought of as a separate protocol that happens to
share a lot of syntax and semantics with SMTP. And I'd say the utility is
certain to be different. (I hope we don't have to go through the same
discussion we've just had regarding IMAP for SUBMIT.)

> protocol rather than generally to the protocol.

Agreed.

				Ned

---

From: Yaron Sheffer <[email-masked]>
Date: Sat, 26 Oct 2013 15:06:18 +0300

Hi Peter,

I understand the need for multiple BCPs, I just want to minimize 
conflicts between them, and we will need a lot of communication to do that.

There's a bunch of process questions that we'll need to discuss over 
time (Informational vs. PS etc.), but let's postpone this stuff.

Lastly, my view of the TLS BCP document is as an interim measure, until 
TLS 1.3 comes around and until the industry adopts it. Yes, this could 
be 2-3 years or possibly more. App-level BCPs should IMHO anticipate 
this migration from TLS 1.2 augmented by the BCP (essentially a profile) 
into TLS 1.3.

Thanks,
     Yaron

On 2013-10-24 21:03, Peter Saint-Andre wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBAgAGBQJSaWD/AAoJEOoGpJErxa2p9/0P/1BVxsw8CBDfzv+hlT4Gg8vo
> Jh3lPmEDuLnolqulFFUnFWos83egKabC/aGZ02i4YoAOzKhA48OIgKgjxaqA99H1
> qzt/84s/C0m2z4iXG/AUCxI6TuLh2VoZkjJTVG//wFHVkde0Ooa8kv09g6yeOsmO
> DD6iPEft4tSrvZM6F9dQTZuciBza/nFpq5pJ8EZHwnMKQgmPp2W9gtd7+ua/BDwL
> w2CbxeJ8pGiDVXu9wjLenYVrapHs0Ul5zCNfmX0fK3qSijdlz4iUAC9+vrZF+Jnv
> ufvvGhNZwMlmmMLguQnyFoFAmf7uleHiufuIyAVn27Aa9tUWUQtNNS2CBx3NFxs2
> iozYIyYOdjRC8D3fXNe+kmauVhTZtYx6yjKIvZdWpFLtBYo2MzWBUyJ/zzx+7dx4
> 5Y2oqphKedZzSkW2dRlqCqCJ52Wiv2mCwDtuUfx3XEeVxDezcSMLtrLc7sTvQ8wK
> 22YoU42+maHk0V7Ggzdb0avrK9/SSRQ7rJnvVANUWzMlYYLZSMgHsUXEwhetYYyO
> vAIwLvEkdckMLaLLN672rHHzY7WyJWhQUmDxb16FEWeLayAOOjAAWNcdGu86ehpF
> /T/WXIIrD4msirRCJEvpVe0lihIWoQHAX6ZyJcsjGGU5rrrM5JwdPJS+PpkxvG00
> 8EU5HwKYOSngShp+vzu3
> =4/i5
> -----END PGP SIGNATURE-----
>