Re: [TLS] CPU cost of 1RTT handshake

[Eric Rescorla <[e-mail]>]

On Sun, Aug 10, 2014 at 1:35 PM, Watson Ladd <[e-mail]> wrote:

> 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.
>

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