Subject: [TLS] CPU cost of 1RTT handshake

From: Watson Ladd <[email-masked]>
Date: Sun, 10 Aug 2014 13:35:13 -0700

Dear all,

Right now, instead of the server defining the group to be used and
sending a key in the group, the client computes multiple keys, and the
server selects one. This is very bad for embedded devices with
constrained CPU, especially if they are connecting to a server over
high-latency, low-bandwidth links.

The justification for the current behavior is similarity to 0-RTT. But
I'm not convinced that this actually makes the protocol or
implementations any simpler, and it has real costs for many devices
that will otherwise not adopt TLS or try to invent their own encrypted
protocols.

Sincerely,
Watson Ladd

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 11 Aug 2014 00:11:13 +0300

> high-latency, low-bandwidth links.

Have the constrained client support just 1 group (most probably the
cheapest one to compute, hopefully it is something secure)?

Constrained clients hopefully don't go connecting to random servers.

Supporting additional groups would mean additional code too, and ROM
space is scarce in constrained devices (50-250kB _total_ might be
typical).

-Ilari

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 10 Aug 2014 21:09:38 -0700

> that will otherwise not adopt TLS or try to invent their own encrypted

I'm not sure I would phrase the protocol behavior exactly as you have
above. Rather, the client sends a list of the groups it supports  (as in
TLS 1.2). It can also send any number of (EC)DHE shares that match
those groups. If the server selects a group that matches one of those
shares, the handshake proceeds. Otherwise, the server tells the
client which group it has selected and the client then adds a share
from that group to the list.

In other words:

1. The server does get to select the group as  it can reject all the
client's shares (thougb of course it cannot force the client to use
a group it does not accept or know about)..

2. The client is not forced to send any shares. It can simply send
an empty ClientKeyExchange (See S 7.4.2) and then wait for the
server to select a group. In other words, it can act as you suggest
above, but at the cost of a round trip. It's a explicit computation/
latency tradeoff.

-Ekr

---

From: Watson Ladd <[email-masked]>
Date: Sun, 10 Aug 2014 21:28:30 -0700

> above, but at the cost of a round trip. It's a explicit computation/

It's a completely unnecessary one: the server can send its share, then
the client goes, which is followed by the remaining messages. Why are
we making 1-RTT unnecessarily expensive?

Sincerely,
Watson Ladd

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 10 Aug 2014 21:36:47 -0700

On Sun, Aug 10, 2014 at 9:28 PM, Watson Ladd <[email-masked]> wrote:
> the client goes, which is followed by the remaining messages.

Yes, one could do that, but it has different properties:

1. It doesn't allow the server to encrypt its handshake data on
the first flight and therefore does not conceal it from passive
observers [0]

2. It doesn't allow the server to send data to the client on its first
flight (if it doesn't care about the client's identity).

-Ekr

[0] Or active observers in cases like WebRTC where the server
doesn't respond to any client.