Subject: [TLS] Still missing: TLS_ECDH_anon_WITH_AES_xxx_GCM_SHAxxx

From: Nico Williams <[email-masked]>
Date: Tue, 11 Mar 2014 17:49:00 -0500

This is a big problem for anything that wants to do opportunistic TLS
(e.g., MTAs, like Postfix).

Shall I submit an I-D?  With what handle?  draft-williams-... or draft-tls-...?

Nico
--

---

From: Manuel Pégourié-Gonnard <[email-masked]>
Date: Wed, 12 Mar 2014 10:12:15 +0100

Hi,

> (e.g., MTAs, like Postfix).
Sorry if I'm missing something obvious, but why would ECDH_anon be a requirement
for opportunistic TLS? Can't we just use certificates and not validate them?

Or are you rather interested in the performance gain of ECDH_anon over
authenticated and forward-secure key exchanges?

Manuel.

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 12 Mar 2014 08:59:43 -0400

> for opportunistic TLS? Can't we just use certificates and not validate them?

using certificates and expecting the peer to not validate them has a
couple downsides:

 0) either the software or the admin must manually provision the
certificate for the server; this means making decisions about questions
that don't necessarily have any good answers, which is not a situation
you want your users to be in.  Servers operating in a pool now need to
have some sort of secret key distribution mechanism, for example.

 1) as peers start using TOFU-like mechanisms (which cannot be
controlled or even necessarily observed by the server itself, the
choices made in (0) become relevant -- want to rotate your key?  want to
deploy a "real" certificate?  want to deploy a certificate issued by
your private CA? all of a sudden your server's identity has changed from
one explicit identity to another.

In the anon case, you can have simple, automatic, configuration-less
deployment that makes no claims of identity at all.

> authenticated and forward-secure key exchanges?

the performance difference on the server side is one RSA or ECDSA
signature per connection; i don't think this is likely to be a large
factor, though i guess it depends on the key size.

	--dkg

---

From: Alyssa Rowan <[email-masked]>
Date: Wed, 12 Mar 2014 13:22:32 +0000

On 12 March 2014 12:59:43 GMT+00:00, Daniel Kahn Gillmor <[email-masked]> wrote:
> 0) [certificate provisioning]
> 1) [TOFU complications]
And an upside: An attacker in a position to MITM in TLSv1.2 would be in a position to see *_anon suites offered: and therefore heuristically guess what the peers will choose and whether an active MITM attack would likely be detected or not.

That would be bad: I think we'll want to conceal that data if possible so that an attacker can't easily distinguish between opportunistic connections they'd succeed silently on (and restrict their MITM to that case, silently decrypting without tripping any warnings and staying under the radar), and authenticated connections in which MITM shenanigans would raise very loud alarm bells. Let's try to keep the "lasers" invisible to third parties, if we can?

Of course if we keep this in mind for TLSv1.3 and the Hellos are encrypted in that version, problem hopefully solved, although the size of the Hello exchange might provide a side channel revealing whether certs were exchanged. Thoughts?

- --
/akr

---

From: Alexandre Anzala-Yamajako <[email-masked]>
Date: Wed, 12 Mar 2014 14:34:34 +0100

Just out of curisoity, is anyone aware of scenarios where people chose
*_anon suites to save on the bandwidth of sending certificates ?

-- 
Alexandre Anzala-Yamajako

---

From: Yoav Nir <[email-masked]>
Date: Wed, 12 Mar 2014 23:02:51 +0200

Anonymous cipher suites save not only bandwidth, they also save calculation. 

ECDHE_RSA requires a private RSA operation on the server as well as the ECDH calculation
ECDHE alone requires only the ECDH calculation. 

In many servers the cost of the handshake is a more significant part of the sizing than the application or the encryption. So that would save a lot - the same server will be able to handle more clients.

However, anonymous cipher suites are very rarely used in practice. Browsers don’t implement them at all, and they’re not the default for any library.

Yoav

On Mar 12, 2014, at 3:34 PM, Alexandre Anzala-Yamajako <[email-masked]> wrote:

> Just out of curisoity, is anyone aware of scenarios where people chose *_anon suites to save on the bandwidth of sending certificates ?
> 
> 
> -- 
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Nico Williams <[email-masked]>
Date: Thu, 13 Mar 2014 00:02:18 -0500

> authenticated and forward-secure key exchanges?

Just because a client and server negotiated an anon ciphersuite does
NOT mean that they won't authenticate each other.

For example:

 - the client might initiate renegotiation to send an SNI and get an
appropriate server certificate,

 - or the client might use application-layer authentication with
channel binding.

Or maybe not authenticating each other is fine and then -yes- ECDH
performance will be appealing.

In the SMTP case when there's no TLSA RRs in the DNS for the server
and the server has no certificates, the client may prefer to use anon
DH/ECDH.  Considering that e-mail has historically had very poor
privacy protection, that would be a huge step up.  But today an SMTP
client can't get high-performance ECDH and AEAD ciphers :(

Nico
--

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 13 Mar 2014 20:36:33 +0200

Hi Nico,

this is about much more than anon-DH cipher suites. The proposal that if 
the client doesn't see a DANE certificate, it can initiate a TLS 
connection with (only) anon-DH means that even if the server does have a 
PKIX certificate (maybe it's old and has not heard of TLSA yet:-), the 
client will not be able to get an authenticated connection with it. So 
we will probably need these cipher suites combined with additional TLS 
signaling, as well as certificate pinning, to allow clients to juggle 
securely between authenticated and anonymous TLS.

Thanks,
	Yaron

On 03/13/2014 07:02 AM, Nico Williams wrote:
[...]

---

From: Nico Williams <[email-masked]>
Date: Thu, 13 Mar 2014 14:08:16 -0500

On Thu, Mar 13, 2014 at 1:36 PM, Yaron Sheffer <[email-masked]> wrote:
> this is about much more than anon-DH cipher suites. [...]

Other anon ciphersuites exist.  We should register these missing ones.
 What rationale is there for not doing so?

As to how to use them, that's a general and _orthogonal_ issue.

Nico
--

---

From: [email-masked] (Martin Rex)
Date: Thu, 13 Mar 2014 20:23:45 +0100 (CET)

I strongly frown upon the idea of resurrecting DH_anon cipher suites
from their cold grave, let alone adding new cruft.

Generate Server Keys on the fly just like SSH does.  Resurrecting
DH_anon turns an initial-leap-of-faith into eternal-leaps-of-faith.

-Martin

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 13 Mar 2014 21:25:28 +0200

I fully agree. I was just saying that deploying them in real-life 
scenarios would require a more complete solution.

	Yaron

---

From: Nico Williams <[email-masked]>
Date: Thu, 13 Mar 2014 14:29:58 -0500

> from their cold grave, let alone adding new cruft.

OK, but do you oppose it, and if so, on what grounds?  Frowning is not
really part of the consensus process :)

> DH_anon turns an initial-leap-of-faith into eternal-leaps-of-faith.

And if I want to renegotiate inside the tunnel?  Why must I pay for
extra crypto just because you frown?

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Thu, 13 Mar 2014 14:31:11 -0500

On Thu, Mar 13, 2014 at 2:25 PM, Yaron Sheffer <[email-masked]> wrote:
> I fully agree. I was just saying that deploying them in real-life scenarios
> would require a more complete solution.

Sure, but since you fully agree I gather you also fully agree that
this is orthogonal to registering the missing ciphersuites.  OK, so
let's start a separate thread (new subject) to discuss the uses of
anon ciphersuites.

Nico
--

---

From: Kurt Roeckx <[email-masked]>
Date: Thu, 13 Mar 2014 21:00:49 +0100

> DH_anon turns an initial-leap-of-faith into eternal-leaps-of-faith.

You can't do authenticated encryption with SMTP in most of the
cases.  DANE is currently about the best way to move to
authenticated encrypted SMTP, however there are very few sites
that bother to set up DNSSEC and DANE.

Since it's SMTP is now not authenticated it makes perfect sense to
use anonymous DH.  The best option for that is currently
TLS_DH_anon_WITH_AES_XXX-GCM-SHAXXX, and this would add the ECDH
version.

I would agree that moving to authenticated encryption would be the
best, but since we can't do authenticated encryption we should go
for the best thing we can do without authentication, and that
would be this proposal.

I'm not sure what you mean with your comment about SSH, but I do
hope that you actually check the fingerprint of the host you're
connecting to.

Kurt