Re: [Cfrg] MAY use specified curves

[Daniel Kahn Gillmor <[e-mail]>]

On 09/09/2014 03:38 PM, Dan Brown wrote:

> I vaguely recall some TLS WG list emails agreeing to move towards named DHE 
> parameters, and perhaps dropping DHE parameters.  Perhaps the TLS WG plans on 
> doing the same for ECDHE?  If so, then my proposal is for CFRG to ask to 
> retain the option of specified curves.

Yes, TLS is moving toward supporting a known set of named finite-field
DHE groups (though i don't think anyone has proposed eliminating custom
DHE groups for the full handshake yet).

  https://tools.ietf.org/html/draft-ietf-tls-negotiated-ff-dhe

No TLS implementation supports custom ECC curves that i've seen.

The advantage of using named groups/curves is that the groups/curves can
be evaluated in detail (for both cryptographic strength and
implementation optimization) by the community once, and then used
everywhere without any additional per-connection cost.

Custom groups/curves are far more expensive to use in practice.

With custom groups/curves, the recipient of the group/curve has a
difficult challenge -- they need to review the group/curve offered and
determine whether it meets their intended security level.  for finite
field DHE, evaluating a group for security requires at least (a)
checking the length of the modulus p, (b) testing the p for primality,
(c) testing q=(p-1)/2 for primality (to ensure a safe prime), and (d)
verify the order of the generator g and peer's share X (for safe primes,
this is an easy check, since group sizes are either 1, 2, p-1, or q, and
we know where the generators of order 2 are).  Very few implementations
actually do all these tests, and some common implementations do not even
verify (a), which is relatively cheap.

You can point your preferred TLS client at https://demo.cmrg.net/, which
uses finite-field DHE with the 16-bit "safe" prime 0x8C7B.  OpenSSL
currently connects to this server without complaint :/ [0]  What
advantage there might be in offering custom groups seems outweighed by
the implausibility of effective endpoint verification.

I can see a private organization deciding to all use a novel curve/group
in their internal communication because they don't like the existing
named groups/curves.  One option for them that wouldn't would be to all
agree to use a specific custom group/curve and then just verify that the
offered group/curve matches that one (and reject otherwise).  But for
this use case, a declared experimental code point (or private OID,
depending on where the group/curve is in use) would be sufficient, and
cheaper in terms of bandwidth.

Consider how long it has taken this group of very clever people to
decide whether any given curve is reasonable to use.  Do we expect a TLS
implementation confronted with a novel curve or group to be able to make
any sane representation to the user of the security level represented by
the offered curve?

i'd say that custom groups or curves are at best a SHOULD NOT, unless
there are some very clear guidelines on how to evaluate them at
connection time to determine what approximate security level they provide.

	--dkg

[0] https://rt.openssl.org/Ticket/Display.html?id=3120