New "TLS Forward Secrecy" document

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

New "TLS Forward Secrecy" document

Wietse Venema
Postfix has supported forward secrecy for TLS since version 2.2
when the TLS patch was adopted into Postfix. Things have changed a
lot since then, both in TLS and in the real world.

Viktor wrote up a FORWARD_SECRECY_README that summarizes the Postfix
side of things all in one place.

Available now:
http://www.porcupine.org/postfix-mirror/FORWARD_SECRECY_README.html

In the next 24 hours:
http://www.postfix.org/FORWARD_SECRECY_README.html

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: New "TLS Forward Secrecy" document

Titanus Eramius
On Wed, 18 Dec 2013 15:15:34 -0500 (EST)
[hidden email] (Wietse Venema) wrote:

> Postfix has supported forward secrecy for TLS since version 2.2
> when the TLS patch was adopted into Postfix. Things have changed a
> lot since then, both in TLS and in the real world.
>
> Viktor wrote up a FORWARD_SECRECY_README that summarizes the Postfix
> side of things all in one place.
>
> Available now:
> http://www.porcupine.org/postfix-mirror/FORWARD_SECRECY_README.html
>
> In the next 24 hours:
> http://www.postfix.org/FORWARD_SECRECY_README.html
>
> Wietse

Wietse, Viktor
Thanks for this, it's a great help.

Cheers
Reply | Threaded
Open this post in threaded view
|

Re: New "TLS Forward Secrecy" document

Micah Anderson-2
In reply to this post by Wietse Venema
Wietse Venema <[hidden email]> writes:

> Postfix has supported forward secrecy for TLS since version 2.2
> when the TLS patch was adopted into Postfix. Things have changed a
> lot since then, both in TLS and in the real world.
>
> Viktor wrote up a FORWARD_SECRECY_README that summarizes the Postfix
> side of things all in one place.
>
> Available now:
> http://www.porcupine.org/postfix-mirror/FORWARD_SECRECY_README.html
>
> In the next 24 hours:
> http://www.postfix.org/FORWARD_SECRECY_README.html
Thank you for writing this up.

I notice that you are using OpenSSL's private terminology (EDH and
EECDH) instead of the standard terminology (DHE and ECDHE).

I realize that postfix is using openssl, and so it may seem natural to
use those names, but when we are struggling with protocols where
interoperability with other tools is critical, eliminating confusion
wherever possible is a worthy goal.

I don't know why openssl did that, it really introduces confusion all
around[0]. Whatever the reason, it is being fixed to remove the
confusion entirely[1], and Postfix should adopt the standard names as
soon as possible.

My suggestion for dealing with this in this FORWARD_SECRECY_README is to
change to using the standard terminology and just include a footnote
about the non-standard names until those fade from our collective
nightmare.

Micah

0. especially since https://tools.ietf.org/html/rfc4492 was clearly
publicly announced -- they just chose EECDH by analogy with their
EDH. Even the (admittedly-retrospective) SSL 3.0 RFC calls it DHE, not
EDH: https://tools.ietf.org/html/rfc6101#appendix-A.6... It probably was
a result of some pre-TLS ssleay struggle to work with mosaic or
something.

1. http://thread.gmane.org/gmane.comp.encryption.openssl.devel/23577/focus=23579

attachment0 (947 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: New "TLS Forward Secrecy" document

Viktor Dukhovni
On Thu, Jan 02, 2014 at 06:03:40PM -0500, micah wrote:

> I notice that you are using OpenSSL's private terminology (EDH and
> EECDH) instead of the standard terminology (DHE and ECDHE).

Given cipherlist class names:

        kEECDH - cipher suites that support Ephemeral ECDH key exchange
        kEDH - cipher suites that support Ephemeral DH key exchange

it makes sense to have matching Postfix names in parameters and
documentation.

The best I can offer is to also mention ECDHE in the second bullet under

    http://www.postfix.org/FORWARD_SECRECY_README.html#tls_fs

where we say that EDH also DHE, but don't say that EECDH is also ECDHE.

Dare I mention the fact that there are also kECDHe and kECDHr key
exchange cipher suite class names in OpenSSL and the first of these
has nothing to do EECDH/ECDHE?  I think not. :-)

> My suggestion for dealing with this in this FORWARD_SECRECY_README is to
> change to using the standard terminology and just include a footnote
> about the non-standard names until those fade from our collective
> nightmare.

May all your 2014 nightmares be so tame, happy new year!

--
        Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: New "TLS Forward Secrecy" document

Micah Anderson-2

Hi Viktor,

Thanks for the reply.

Viktor Dukhovni <[hidden email]> writes:

> On Thu, Jan 02, 2014 at 06:03:40PM -0500, micah wrote:
>
>> I notice that you are using OpenSSL's private terminology (EDH and
>> EECDH) instead of the standard terminology (DHE and ECDHE).
>
> Given cipherlist class names:
>
> kEECDH - cipher suites that support Ephemeral ECDH key exchange
> kEDH - cipher suites that support Ephemeral DH key exchange

I'm sorry, but I have no idea what "cipherlist class names" are, would
you mind clarifying what that is, I tried to search the web for those
names, but was not able to uncover anything.

Thanks,
micah
Reply | Threaded
Open this post in threaded view
|

Re: New "TLS Forward Secrecy" document

Viktor Dukhovni
On Sun, Jan 05, 2014 at 06:31:46PM -0500, micah wrote:

> > Given cipherlist class names:
> >
> > kEECDH - cipher suites that support Ephemeral ECDH key exchange
> > kEDH - cipher suites that support Ephemeral DH key exchange
>
> I'm sorry, but I have no idea what "cipherlist class names" are, would
> you mind clarifying what that is, I tried to search the web for those
> names, but was not able to uncover anything.

There's nothing to research.  I meant to say "cipher suite class names",
and these are not surprisingly names of classes of cipher suites.  That
is names you can use in an OpenSSL cipherlist that match multiple cipher
suites.

  aNULL - anonymous cipher suites
  aRSA - cipher suites with RSA certificate authentication.
  eNULL - cipher suites with no encryption
  kEECDH - cipher suites with EECDH (ECDHE) key exchange.
  AES - cipher suites that use AES payload encryption.
  ...

each of which matches a set of ciphers suites whose elements have
names that correspond to a single combination of algorithms, such as:

  RC4-SHA
  AES128-SHA
  ECDHE-ECDSA-AES256-SHA384 (OpenSSL 1.0.2 or later)

  $ openssl ciphers -v 'ECDHE-ECDSA-AES256-SHA384:AES128-SHA:RC4-SHA'
  ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AES(256) Mac=SHA384
  AES128-SHA              SSLv3 Kx=RSA      Au=RSA  Enc=AES(128)  Mac=SHA1
  RC4-SHA                 SSLv3 Kx=RSA      Au=RSA  Enc=RC4(128)  Mac=SHA1

--
        Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: New "TLS Forward Secrecy" document

Micah Anderson-2
Viktor Dukhovni <[hidden email]> writes:

> On Sun, Jan 05, 2014 at 06:31:46PM -0500, micah wrote:
>
>> > Given cipherlist class names:
>> >
>> > kEECDH - cipher suites that support Ephemeral ECDH key exchange
>> > kEDH - cipher suites that support Ephemeral DH key exchange
>>
>> I'm sorry, but I have no idea what "cipherlist class names" are, would
>> you mind clarifying what that is, I tried to search the web for those
>> names, but was not able to uncover anything.
>
> There's nothing to research.  I meant to say "cipher suite class names",
> and these are not surprisingly names of classes of cipher suites.  That
> is names you can use in an OpenSSL cipherlist that match multiple cipher
> suites.
Ok, thank you for clarifying.

>
>   aNULL - anonymous cipher suites
>   aRSA - cipher suites with RSA certificate authentication.
>   eNULL - cipher suites with no encryption
>   kEECDH - cipher suites with EECDH (ECDHE) key exchange.
>   AES - cipher suites that use AES payload encryption.
>   ...
>
> each of which matches a set of ciphers suites whose elements have
> names that correspond to a single combination of algorithms, such as:
Yes, I understand this, now that I know what you are referring to. It is
true that right now, "kEECDH" is a string you can currently pass to
openssl ciphers.

However, as the [1] footnote in my original message details, along with
the series of patches to openssl: the Openssl input, API and output are
being changed so *every* occurrence of EDH and EECDH will be changed to
use the standard names DHE and ECDHE.

>  it makes sense to have matching Postfix names in parameters and
>  documentation.

I completely agree, however it seems we do not agree with the matching
names should be. That is precisely why I write this message. The postfix
parameter names and documentation should adopt the standardized names
that openssl is changing to. As it is written now, the postfix TLS
Forward Secrecy Document currently uses the non-standard, proprietary
names that are being replaced in Openssl.

Changing these names, before postfix is released with these older names,
seems like the most prudent thing to do to eliminate confusion.

>  The best I can offer is to also mention ECDHE in the second bullet under
>
>      http://www.postfix.org/FORWARD_SECRECY_README.html#tls_fs
>
>  where we say that EDH also DHE, but don't say that EECDH is also ECDHE.

I understand the desire to transition the old, non-standard names to the
new ones, but I think the better thing to do is to replace *all*
instances of EDH and EECDH with the standardized names (DHE and EECDH)
and simply note the non-standard, proprietary names as an acceptable
alternative, but one that is deprecated.

micah

attachment0 (947 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: New "TLS Forward Secrecy" document

Wietse Venema
micah:
> I completely agree, however it seems we do not agree with the matching
> names should be. That is precisely why I write this message. The postfix
> parameter names and documentation should adopt the standardized names
> that openssl is changing to. As it is written now, the postfix TLS

We'll adapt *after* OpenSSL is updated.

        Wietse