Subject: [TLS] Deprecate DH_anon in favor of raw public keys?

From: Eric Rescorla <[email-masked]>
Date: Fri, 28 Aug 2015 10:35:11 -0700

https://github.com/tlswg/tls13-spec/issues/233

Folks,

We presently have some support for DH_anon cipher suites. I agree that this
is a useful use case, but it's yet another mode.

I would like to suggest that we instead deprecate it and instead always use
Raw Public Key mode (https://tools.ietf.org/html/rfc7250). The idea is that
the client would simply indicate support for a raw public key and the
server could then either (a) spin a new key for this use or (b) use a
long-term
one. To my mind this has three advantages:

1. Complexity: It means that we have one less operational mode. And all the
public key
modes would look cryptographically similar.

2. It resolves the question of how you bind to the server's identity in
0-RTT mode
(https://github.com/tlswg/tls13-spec/issues/219), namely the raw public key
that goes in the Certificate message.

3. It makes it easier to do an SSH-style leap-of-faith mode since the
server can
use the same signing key for a long time while maintaining PFS.

It seems to me that the two major counterarguments are:

1. Extra computational cost from the signature. I'm not worried too much
about that since generally the anonymous contexts don't do a lot of
connections
and we don't really want to encourage pure anonymous (i.e., non-TOFU) modes
anyway.

2. It's less explicit that this is unverified. Arguably this is a feature
rather than
a bug.

Thoughts?
-Ekr

---

From: Dave Garrett <[email-masked]>
Date: Fri, 28 Aug 2015 13:51:26 -0400

I actually had this in my old a la carte proposal. Here's the relevant section posted separately, unedited, except for keeping the current list of RFCs with anon that weren't in that proposal:

https://github.com/tlswg/tls13-spec/compare/master...davegarrett:unauthenticated

Dave

---

From: Martin Thomson <[email-masked]>
Date: Fri, 28 Aug 2015 11:07:02 -0700

This seems fine to me, though I'll note that 7250 only really saves
you space when it comes down to it.  You can wrap your raw public key
in a certificate, just like we do in WebRTC, and then you don't need
7250 support in your library.  Noting you can only do any of these
variations in a context where there is some preexisting understand
that what you choose to use is acceptable to the other side.

Regarding the explicit nature of having an explicit DH_anon signal, I
tend to think that (on balance) removing this signal does more good
than harm.  I expect certain others to disagree, of course, but we can
talk about why a vigorous defense of the cipher suite signal isn't a
good use of their energy later.

On 28 August 2015 at 10:35, Eric Rescorla <[email-masked]> wrote:
> 3. It makes it easier to do an SSH-style leap-of-faith mode since the server
> can
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 28 Aug 2015 11:10:05 -0700

On Fri, Aug 28, 2015 at 11:07 AM, Martin Thomson <[email-masked]>
wrote:

> 7250 support in your library.

It also removes the need to parse the cert.

> Noting you can only do any of these

SG.

> server

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 28 Aug 2015 18:33:17 +0000

> that what you choose to use is acceptable to the other side.

Indeed that's effectively what you get with DANE TLSA "3 1 1", when
the client, the server or at present typically both don't support
RFC 7250.

> good use of their energy later.

The signal has pros and cons.  Absent channel-binding at the next
layer up, it makes it clear to adversaries that active attacks are
"safe".  On the other hand, it allows servers to detect that a
client is not planning to authenticate the server, which has forensic
value, and can be used to grant appropriately restricted access.

Furthermore, anon-DH has strong privacy properties, the server
sends no identity information, not even a public key.  Any
channel-binding at the next layer is privacy protected.

The proposal to use raw public keys sends a similar signal to
servers that don't publish DANE-EE(3)/SPKI(1) TLSA records.  X.509
clients can no longer to PKIX authentication.  A server that does
publish DANE-EE(3)/SPKI(1) records on the other hand can no longer
conclude that authentication is not done.  And of course clients
may be doing public key pinning, be it TOFU, or via some out-of-band
means.

Clearly getting along without anon_DH is possible, since many
servers or clients don't enable anon_DH ciphers and yet interoperate
just fine with those that do.  

My view is that anon_DH should either be supported properly (be
defined for the same symmetric cipher combinations as ciphersuites
with certs or public keys) or as proposed not supported at all.

Replacement by public keys is not semantically equivalent, it just
saves a bit of network and code space relative to self-signed X.509.
So I'm not yet convinced that the proposal is progress, we lose
some and gain some.

-- 
	Viktor.

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 28 Aug 2015 11:36:35 -0700

> channel-binding at the next layer is privacy protected.

How does anon-DH have different privacy properties than doing
RFC 7250 with a fresh signing key for each connection?

-Ekr

---

From: Martin Thomson <[email-masked]>
Date: Fri, 28 Aug 2015 11:44:22 -0700

> RFC 7250 with a fresh signing key for each connection?

Or what we do in WebRTC, which uses a certificate that has no good
information in it?

---

From: Martin Thomson <[email-masked]>
Date: Fri, 28 Aug 2015 11:47:05 -0700

On 28 August 2015 at 11:33, Viktor Dukhovni <[email-masked]> wrote:
> On the other hand, it allows servers to detect that a

I think that these are potentially useful properties, but I don't
think that we need to use the cipher suite signaling to get that
information.  What if you could (for example) include a signal at the
application layer "oh, by the way, I didn't authenticate you".  Or you
could have an extension that said up front that you don't intend to
check.  Those are superior in the sense that it allows for all the
benefits of ekr's proposal, without losing the properties you care
about.

---

From: Ronald del Rosario <[email-masked]>
Date: Fri, 28 Aug 2015 19:21:12 +0000

"Or what we do in WebRTC, which uses a certificate that has no good
information in it?”

+1. Anxiously waiting for response on this, as I am currently helping non-profit groups build a private and secure P2P Messaging System using WebRTC, which of course utilizes encrypted P2P connection between two browsers (A centralized signaling server must be at the middle as a broker for the sessions)

The DTLS handshake performed between two WebRTC clients re-lies on self-signed certificates. As a result, the certificates themselves cannot be used to authenticate the peer, as there is no explicit chain of trust to verify.

Ron

From: TLS <[email-masked]<mailto:[email-masked]>> on behalf of Martin Thomson <[email-masked]<mailto:[email-masked]>>
Date: Friday, August 28, 2015 at 11:44 AM
To: Eric Rescorla <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [TLS] Deprecate DH_anon in favor of raw public keys?

________________________________

CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain confidential information of Five9 and/or its affiliated entities. Access by the intended recipient only is authorized. Any liability arising from any party acting, or refraining from acting, on any information contained in this e-mail is hereby excluded. If you are not the intended recipient, please notify the sender immediately, destroy the original transmission and its attachments and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Copyright in this e-mail and any attachments belongs to Five9 and/or its affiliated entities.

---

From: Nico Williams <[email-masked]>
Date: Mon, 31 Aug 2015 11:13:30 -0500

> channel-binding at the next layer is privacy protected.

Using raw public signature keys doesn't change that.  It just requires
generating a signature key every time.

For devices/protocols where DH_anon is common (perhaps because they do
channel binding) the proposal at hand is annoying and CPU-wasting, but
hardly fatal.

I'm not sure how I feel about this.  The idea that we always do a DH key
exchange and always have a server signature means we can greatly reduce
the number of ciphersuites, so that's quite helpful.  We'd have to apply
this to PSK too to make it really worthwhile.

> with certs or public keys) or as proposed not supported at all.

Yes, DH_anon should be first-class.

Nico
--

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 31 Aug 2015 09:18:34 -0700

> this to PSK too to make it really worthwhile.

Certainly it would be nice to get rid of PSK too but just getting rid of
DH_anon makes a non-trivial difference.

-Ekr

---

From: Nico Williams <[email-masked]>
Date: Mon, 31 Aug 2015 11:45:31 -0500

> DH_anon makes a non-trivial difference.

How would we get rid of PSK [without DH]?  What would the impact be on
IoT devices?  Could we have a fake-DH-and-signature PSK scheme to make
it easy on IoTs?

Nico
--

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 31 Aug 2015 09:48:10 -0700

> IoT devices?  Could we have a fake-DH-and-signature PSK scheme to make

I guess I wasn't clear: I'm not in favor of getting rid of PSK. I'm saying
that
even if we still have PSK, removing DH_anon as an explicit mode makes
things simpler.

-Ekr

---

From: Nico Williams <[email-masked]>
Date: Mon, 31 Aug 2015 12:41:41 -0500

On Mon, Aug 31, 2015 at 09:48:10AM -0700, Eric Rescorla wrote:
> I guess I wasn't clear: I'm not in favor of getting rid of PSK. I'm
> saying that even if we still have PSK, removing DH_anon as an explicit
> mode makes things simpler.

I wasn't either.  I was asking about requiring the use of DH [and a
server signature] when using PSK.

Let's get back to removing DH_anon for a minute.

What would the impact be on TCPINC proposals using TLS as their basis?
They really need anonymity, leaving it to the application to do channel
binding.  (The application might be using TLS itself, oddly enough.)  Do
we really want to force servers to generate an unnecessary signing key,
compute an unnecessary signature, and to then force clients to verify
said unnecessary signature (if they don't then there's a subliminal
channel)??

I think "no", unless the signature algorithm used is cheap [and weak],
which probably adds other complications.

Back to PSK:  How is PSK with PFS going to work?  How is PSK w/o PFS
going to work?

Anyways, my current take is that we should not get rid of the DH_anon
ciphersuites.  I grant that the existing applications (ignoring TPCINC?)
could take the performance hit, but in the longer term it seems likely
to be more problematic than helpful.

Nico
--