Re: [TLS] WGLC: draft-ietf-tls-negotiated-ff-dhe-05

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

On Fri 2015-01-23 14:30:42 -0500, Sean Turner wrote:
> This is the WGLC (working group last call) for draft-ietf-tls-negotiated-ff-dhe-05:
> http://datatracker.ietf.org/doc/draft-ietf-tls-negotiated-ff-dhe-05/
> Please send comments on this draft to the TLS list before February 16, 2015.

Off-list, i've recieved a handful of requests for changes in the last
couple weeks that i've been remiss in processing.  I list them below,
From least controversial to most controversial in my estimation.

My biggest fear is that the last two points on the list of 5 below
threaten to be a repeat of the current CFRG curve selection morass.  I
really do not want to see that happen.


Adding back ffdhe6144
---------------------
  
I had ffdhe6144 in the earlier draft, and had removed it to reduce the
number of groups to minimize fingerprintability of the handshake, but
have no strong feelings here.

The argument was that the cost increase jumping from a 4kib group to an
8kib group could be seen as prohibitive, and if we ever need to
encourage people to move up from the 4kib group due to a cryptanalytic
advance that puts that range in question, we'd like to offer something
with less of a cost increase.
    
I'm not convinced i buy the argument: anything that makes folks think
4kib groups are seriously dangerous seems like it could also cause worry
at the 6kib level, but i can also imagine a DLOG work-factor reduction
of modest size that makes this argument seem plausible.  I don't
particularly mind putting 6144 back in unless there are objections.


Increasing the size of the short exponent recommendation
--------------------------------------------------------

The estimates of the group strength come from ECRYPT, and the short
exponent sizes are recommended based on this group strength.  But some
other strength estimates suggest groups of this size are slightly
stronger.  If ECRYPT is wrong, and we base our short exponent length on
its estimates, then we might weaken the system below the actual strength
of the group.  Also, attacking the DLOG problem requires different
resources and precomputation from attacking the stream ciphers.

So the proposal is to leave the estimates based on ECRYPT estimates, but
to increase the size of the recommended short exponents per group.

This only slightly reduces the extra efficiency provided by the short
expoenents, and seems like the right choice to make.


Designating private-use pre-agreed ffdhe groups
-----------------------------------------------

A request was made to set aside one (or a few) codepoint(s) for TLS
endpoints that have pre-agreed on a group together.  It's not clear to
me exactly how many "private use" codepoints would be needed.  But two
would allow a large deployment to implement a smooth transition between
two different private groups, which seems like a reasonable goal.

I'll probably designate 510 and 511 ( 0x01fe and 0x01ff ) as these
private-use codepoints for deployments that want this capability.

If anyone has objections, or wants more or less than 2 private-use
codepoints, please speak up.


Using a keyed PRF instead of e
------------------------------

Two objections were made about the use of e --

(a) because of its definition as the base of the natural log, e has some
    sort of special internal structure that might make FFDH groups
    derived from it more vulnerable to analysis.

(b) that starting from e and counting up biases the randomized prime
    selection by only fiddling certain bits in the prime while counting.

I've spoken with several cryptographers about (a) who dismissed it as
totally implausible.  I haven't gotten much feedback about (b).

The proposed change is to select the "random" bits by using a keyed PRF,
or KDF, with the seed or additional input incrementing until a safe
prime is found.

I confess this sounds better than using e to me, simply because the
construction avoids any claims about (a) and (b).

One approach would be to use [HKDF] with SHA-512, with the initial key
material ("IKM") and info parameter both set to "TLS-ffdheNNNN" (where
ffdheNNNN is the ASCII name of the group), and a salt that we increment
until a safe prime is found at the right length.

  [HKDF] https://tools.ietf.org/html/rfc5869


Avoiding the high-64 and low-64 bits set to 1
---------------------------------------------

The high 64 bits and the low 64 bits of these primes are set to 1
specifically to facilitate Montgomery and Barrett reduction.  This is
similar to the choices made in the MODP FFDHE groups.

The objection to this is that the special structure may make these
groups more vulnerable to attacks that we don't know about, potentially
making them equivalent to groups the size of the inner bits or
something.

I'd like to think that if any advances had been made against the DLOG
problem for groups with this special form, they would be published
already, since the first Oakley group is 768 bits, with the top and
bottom 64 bits all set to 0xff, so this should be in-range and
high-profile for anyone who wants to take a crack at it:

  https://tools.ietf.org/html/rfc2409#section-6.1

But i'm not a cryptographer, i know of no such attack, and i have no
idea how to judge the likelihood of something like this existing.

I also don't know how widespread or desirable Barrett and Montgomery
reductions are: if these reduction methods are unlikely to be actually
used in the field, or offer only insignificant efficiency incentives for
adoption, then we might not need to maintain them.

Another argument here is that if efficiency is paramount, most people
will choose ECDHE instead of FFDHE.  So if we're proposing FFDHE groups
as a bulwark against some future failure of ECDHE, we might as well
accept that performance efficiency isn't the highest priority.



These last two points are what Andrei is referring to when he says
"avoid special-form primes", fwiw.


Thoughts, feedback?

          --dkg