Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-02.txt

[Henrick Hellström <[e-mail]>]

On 2014-10-11 06:55, Daniel Kahn Gillmor wrote:
> I'd appreciate any comments or suggestions, and particularly review
> related to the IANA considerations would be great.

It seems to me the the recommended Client Behavior and Server Behavior 
has to be simplified and strengthened, in order for the standard to meet 
the security objectives.

All relevant attacks here https://secure-resumption.com/ seem to involve 
a MITM server that chooses bad ServerDHParams for the server key 
exchange message.

   * Clearly, a MITM server might simply act as if it doesn't support 
the "elliptic_curves" extension. The server does not include a reply to 
the "elliptic_curves" extension in server_hello, so the client will not 
receive any indication of lack of support, until it receives 
server_key_exchange. At this point, the client might decide to terminate 
the handshake if the ServerDHParams aren't acceptable. Checking an 
arbitrary group by means of a binary compare, is only marginally harder 
than checking a named group.
   * Conversely, a MITM that connects to a legitimate server, will be 
perfectly able to carry out the secure resumption attacks, even if the 
MITM and the legitimate server negotiate using a fixed FFDHE group. (It 
is only the ServerDHParams used in the handshake between the legitimate 
client and the MITM that have to be doctored.)
   * Also, there doesn't seem to be any obvious harm in requiring that a 
compatible server always picks a ServerDHParams group with an estimated 
security equal to the minimum of the server certificate public key and 
the bulk encryption cipher, regardless of the presence or absence of an 
"elliptic_curves" extension in client_hello. If this group is encoded as 
an arbitrary group in ServerDHParams, there is no divergence from 
current standards at the protocol level.

Hence, in order to introduce as little complexity as possible into the 
client behavior and server behavior, as well as actually strengthening 
security by implementing this mechanism, I suggest something along these 
lines:

Client Behavior

Conforming clients MIGHT require that a FFDHE group with appropriate 
security bounds is presented by a specific server. If the use of such 
groups are required by the client, the client SHOULD NOT offer cipher 
suites that might force a compatible server to pick a group the client 
does not implement.

A client that requires the use of FFDHE groups MUST perform a binary 
compare of the ServerDHParams against the FFDHE group with the 
corresponding modulus size, and MUST end the handshake with an 
insufficient_security alert if the parameters do not match.

In order to avoid ambiguities if FFDHE groups are added, replaced or 
deprecated in future revisions of this standard, a compatible client 
SHOULD send an "elliptic_curves" extension in client_hello, to indicate 
support of specific groups.

Server Behavior

When a DHE cipher suite is negotiated, a compatible server SHOULD always 
pick a FFDHE group for ServerDHParams, with a security bound greater 
than the minimum of the server certificate public key and the bulk 
encryption cipher of the negotiated cipher suite. The server SHOULD NOT 
negotiate a DHE cipher suite, unless it implements at least one FFDHE 
group with at least the corresponding security bound.

If an "elliptic_curve" extension is included in client_hello, the server 
MUST NOT negotiate a DHE cipher suite that would require the server to 
pick a FFDHE group not included in the "elliptic_curve" extension sent 
by the client. NOTE: Since FFDHE groups might be replaced or added in 
future revisions of this standard, this check MUST be performed 
regardless if the "elliptic_curve" extension does not include any 
identifiers the server recognizes as FFDHE identifiers.