Subject: [TLS] Call for consensus to remove anonymous DH

From: Joseph Salowey <[email-masked]>
Date: Tue, 15 Sep 2015 18:00:39 -0700

There has been some discussion to remove anonymous DH as described in
https://www.ietf.org/mail-archive/web/tls/current/msg17481.html.  I think
ekr's message sums up the pros and cons well.  I don't think we have
consensus on this issue yet.  Please respond on this message by Monday,
September 21, if you have an opinion.

Thanks,

J&S

---

From: Tony Arcieri <[email-masked]>
Date: Tue, 15 Sep 2015 18:42:59 -0700

+1 for removing anonymous DH

On Tue, Sep 15, 2015 at 6:00 PM, Joseph Salowey <[email-masked]> wrote:

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

-- 
Tony Arcieri

---

From: Tom Ritter <[email-masked]>
Date: Tue, 15 Sep 2015 21:10:14 -0500

> +1 for removing anonymous DH

+1.

Even for the anonymous use cases I like having a long-term key around
for people to optionally remember. (I realize we're not requiring
that.)

-tom

---

From: Dave Garrett <[email-masked]>
Date: Tue, 15 Sep 2015 23:24:11 -0400

On Tuesday, September 15, 2015 09:00:39 pm Joseph Salowey wrote:
> remove anonymous DH

+1 for replacing anon DH with raw public keys

If it simplifies the protocol in a meaningful way, the switch is worth it. It also makes it easy to allow ECC here without having to define a new pile of anon ECDH suites.

Dave

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Wed, 16 Sep 2015 10:37:48 +0200

On Tue, 2015-09-15 at 18:00 -0700, Joseph Salowey wrote:
> There has been some discussion to remove anonymous DH as described inhttps://www.ietf.org/mail-archive/web/tls/current/msg17481.html. ; I think ekr's message sums up the pros and cons well.  I don't think we have consensus on this issue yet.  Please respond on this message by Monday, September 21, if you have an opinion.  

If that implies that anonymous ECDH ciphersuites are removed too, I'm
all for it.

regards,
Nikos

---

From: Aaron Zauner <[email-masked]>
Date: Wed, 16 Sep 2015 11:24:35 +0200

+1.

Aaron

---

From: Martin Thomson <[email-masked]>
Date: Wed, 16 Sep 2015 10:40:28 -0700

> remove anonymous DH

+1

It's not like we're making the use case impossible, just that the
solution will look different.

---

From: Russ Housley <[email-masked]>
Date: Wed, 16 Sep 2015 13:46:52 -0400

> There has been some discussion to remove anonymous DH as described in https://www.ietf.org/mail-archive/web/tls/current/msg17481.html.  I think ekr's message sums up the pros and cons well.  I don't think we have consensus on this issue yet.  Please respond on this message by Monday, September 21, if you have an opinion.

I see no reason to keep it.

Russ

---

From: Andrei Popov <[email-masked]>
Date: Wed, 16 Sep 2015 18:35:29 +0000

To clarify, the proposal includes removing ECDH_anon, right? If it does, I support it.

Cheers,

Andrei

From: TLS [mailto:[email-masked]] On Behalf Of Joseph Salowey
Sent: Tuesday, September 15, 2015 6:01 PM
To: [email-masked]
Subject: [TLS] Call for consensus to remove anonymous DH

Thanks,

J&S

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 16 Sep 2015 12:05:36 -0700

On Wed, Sep 16, 2015 at 11:35 AM, Andrei Popov <[email-masked]>
wrote:

> To clarify, the proposal includes removing ECDH_anon, right?
>

Yes.

> If it does, I support it.
>
>
>
> Cheers,
>
>
>
> Andrei
>
>
>
> *From:* TLS [mailto:[email-masked]] *On Behalf Of *Joseph Salowey
> *Sent:* Tuesday, September 15, 2015 6:01 PM
> *To:* [email-masked]
> *Subject:* [TLS] Call for consensus to remove anonymous DH
>
>
>

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 16 Sep 2015 19:10:34 +0000

Remove it.

--
Senior Architect, Akamai Technologies
IM: [email-masked] Twitter: RichSalz

---

From: Nico Williams <[email-masked]>
Date: Wed, 16 Sep 2015 14:57:32 -0500

> solution will look different.

And will be more costly.

I'm neutral on this, as I don't think the extra cost will lead to, say,
MTAs forgoing TLS for SMTP.

Nico
--

---

From: Brian Smith <[email-masked]>
Date: Wed, 16 Sep 2015 13:20:37 -0700

> September 21, if you have an opinion.

I think it is a good idea to remove DH_anon_* and similar ECDH_anon_*
cipher suites.

This isn't an endorsement of the raw public key modes.

Cheers,
Brian

---

From: Nico Williams <[email-masked]>
Date: Wed, 16 Sep 2015 16:01:14 -0500

> This isn't an endorsement of the raw public key modes.

Sure, one can always use self-signed certs (at an even higher cost to do
anonymity).  If we're going to raise the cost of anonymity for the sake
of simplicity in TLS 1.3, do let's try to keep that cost from
escalating.  Raw public keys are not a large additional complexity cost.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 16 Sep 2015 14:05:53 -0700

In addition, they are already part of TLS, so the question would be if we
have
consensus to remove them....

-Ekr

---

From: Tony Arcieri <[email-masked]>
Date: Wed, 16 Sep 2015 14:12:07 -0700

> consensus to remove them....

I see a bunch of +1s and zero -1s. Just saying...

-- 
Tony Arcieri

---

From: Nico Williams <[email-masked]>
Date: Wed, 16 Sep 2015 16:24:21 -0500

> I see a bunch of +1s and zero -1s. Just saying...

I think Eric meant raw public keys.

---

From: Brian Smith <[email-masked]>
Date: Wed, 16 Sep 2015 14:25:52 -0700

> consensus to remove them....

This thread  is about the removal of DH_anon_*, not about raw public keys.

Cheers,
Brian

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 16 Sep 2015 14:38:05 -0700

> This thread  is about the removal of DH_anon_*, not about raw public keys.

Yes, I'm aware of that.

The point I was making was that presently we have:

- Certificates
- Raw keys
- Anon

This proposal is to remove Anon, thus making things strictly simpler, since
Raw keys can replace Anon but not the other way around. One might imagine
a proposal to remove Raw keys, but that's not the question here and even if
that failed (as I expect it would) things will still be simpler if we
remove Anon.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 16 Sep 2015 14:39:35 -0700

> I think Eric meant raw public keys.

Yes. I'm in favor of removing Anon, which is why I proposed it a few weeks
ago.

-Ekr

---

From: Nico Williams <[email-masked]>
Date: Wed, 16 Sep 2015 17:55:02 -0500

> This thread  is about the removal of DH_anon_*, not about raw public keys.

Yes, but you implied that you might not support keeping raw public keys.

I'm not in favor of removing the anon cipher suites if we also remove
raw public key support.  This is important.  I don't want the cost of
doing anon with TLS to escalate piecemeal.  All cards on the table
please.

Nico
--

---

From: Dave Garrett <[email-masked]>
Date: Wed, 16 Sep 2015 19:07:31 -0400

On Wednesday, September 16, 2015 06:55:02 pm Nico Williams wrote:
> > > have consensus to remove them....
> > 

This appears to just be a miscommunication.

> that failed (as I expect it would) things will still be simpler if we

The current poll is to remove anon ciphers in favor of raw public keys. We're not considering removing raw public keys, as far as I know, and I think most of us would be against that.

Dave

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 16 Sep 2015 16:10:19 -0700

On Wed, Sep 16, 2015 at 4:07 PM, Dave Garrett <[email-masked]>
wrote:

> The current poll is to remove anon ciphers in favor of raw public keys.
> We're not considering removing raw public keys, as far as I know, and I
> think most of us would be against that.

Isn't this what I said?

-Ekr

---

From: Nico Williams <[email-masked]>
Date: Wed, 16 Sep 2015 18:23:34 -0500

> This appears to just be a miscommunication.

It is not.

> The current poll is to remove anon ciphers in favor of raw public
> keys. We're not considering removing raw public keys, as far as I
> know, and I think most of us would be against that.

Once more, with feeling.  I would oppose the current proposal if there
was to be a follow-on proposal to remove raw public keys, which I
wouldn't have even though plausible but for Brian's intimating that he'd
be fine with removing raw public keys.  Otherwise I would be neutral as
to removing anon ciphersuites.

I would also be neutral as to removing raw public keys if anon
ciphersuites are to remain.

Whichever one is removed, I shall oppose the removal of the other.

I.e., these two features are interrelated.  It is difficult to consider
the removal of one without considering the possible removal of the
other.

I leave it at that.

Nico
--

---

From: Dave Garrett <[email-masked]>
Date: Wed, 16 Sep 2015 19:48:25 -0400

> the removal of one without considering the possible removal of the

Yes, I agree with this, and I'm saying that I think that we're all on the same page here. Brian made a point to explicitly not endorse raw keys, but looking back through the messages today, I don't see anyone actually propose removing them. Thus, I said this is likely to be a miscommunication. That's all.

Dave

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 17 Sep 2015 00:21:11 +0000

> that failed (as I expect it would) things will still be simpler if we

The difference between raw public keys (RFC7250 RPK) and anon is:

    - PRO: Dropping anon simplifies the implementation and reduces
      cipher count.

    - PRO: Raw keys may facilitate TOFU pinning.

    - CON: Raw keys are not yet implemented in any toolkits I've seen
      (a temporary setback perhaps).

    - CON: Raw keys send more traffic (public key in certificate
      message, plus signature of key agreement).  Byte counts can
      matter in some environments.

    - CON: Raw keys consume more CPU (signing the key agreement).

    - CON: Servers lose a simple signal that the client is not
      bothering with authentication.

The costs are likely noticeable for 4096-bit RSA keys.  In the end
though, if dropping anon_(EC)DH increases the chance that RPK gets
widely implemented, I can live with the cons.

-- 
	Viktor.

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 16 Sep 2015 20:31:41 -0400

> September 21, if you have an opinion.

I support removing anonymous DH for the server side[0] of TLS.  TLS
servers that want to effectively do "anonymous" DH can craft a raw
public key or certificate and forge a signed_params to match.  They can
do this per-session if they do not want to present a persistent
identity.

For those worried about computational cost: the raw public key or
certificate themselves do not have to be valid mathematical objects if
the peer is not inclined to check them.  The signed_params itself could
also be all 0xff or anything you like as long as the peer isn't
checking.  For those concerned about bandwidth, these objects do not
have to be large.

This simplifies the expected messages and transitions in a TLS
handshake.  I think that's a good thing, given the errors we've seen
already in state machine implementations.

         --dkg
         
[0] I do not think that clients engaged in a DH key exchange should be
    uniformly required to claim an identity at the TLS layer :)

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 17 Sep 2015 00:42:07 +0000

On Wed, Sep 16, 2015 at 08:31:41PM -0400, Daniel Kahn Gillmor wrote:

> the peer is not inclined to check them.

That's not generally possible.  Many servers support a mixture of
clients, some of which authenticate, and others not.  If a server
agrees to a cipher that requires signatures, it needs to sign.

> The signed_params itself could
> checking.  

Without "anon_(EC)DH" ciphers in the client HELLO, there's no "I'm
not checking" signal.

> For those concerned about bandwidth, these objects do not
> have to be large.

Absent a client signal, this is generally not viable.

-- 
	Viktor.

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 16 Sep 2015 20:42:04 -0400

>       bothering with authentication.

and:

      - PRO: passive attackers on the network lose a simple signal tha
        tthe client is not bothering with authentication.

> The costs are likely noticeable for 4096-bit RSA keys.

A server concerned about CPU or bandwidth costs who would have preferred
anon_DH suites would be silly to select 4096-bit RSA, whether RPK or
cert.  They should choose some small ECC key.

A client concerned about CPU who would have been fine with anon_DH will
simply not verify the signature at all.

So that leaves clients concerned about bandwidth, who pretty much have
no choice but to eat the handshake message that the server sends them
anyway :/

   --dkg

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 16 Sep 2015 17:52:23 -0700

>     uniformly required to claim an identity at the TLS layer :)

I agree with this and that's not the intention.

-Ekr

---

From: Bill Frantz <[email-masked]>
Date: Wed, 16 Sep 2015 18:40:47 -0700

>widely implemented, I can live with the cons.

I agree with both Nico and Viktor. For me the big win of RPK 
over anon_(EC)DH is it allows TOFU. If TOFU isn't needed, short 
public keys should ease many of Viktor's cons. I also like the 
idea of simpler implementations.

For the question that started this thread, I am neutral.

Cheers - Bill

--------------------------------------------------------------
Bill Frantz        | There are now so many exceptions to the
408-356-8506       | Fourth Amendment that it operates only by
www.pwpconsult.com | accident.  -  William Hugh Murray

---

From: Nico Williams <[email-masked]>
Date: Thu, 17 Sep 2015 14:07:23 -0500

On Wed, Sep 16, 2015 at 06:40:47PM -0700, Bill Frantz wrote:
> I agree with both Nico and Viktor. For me the big win of RPK over
> anon_(EC)DH is it allows TOFU. If TOFU isn't needed, short public
> keys should ease many of Viktor's cons. I also like the idea of
> simpler implementations.

Eh, certs also allow TOFU.  That's what key pinning is, in a way.  :)