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

On Thu, Jul 24, 2014 at 9:10 PM, Peter Gutmann
<pgut001@cs.auckland.ac.nz> wrote:
> Andrey Jivsov <crypto@brainhub.org> writes:
>
>>Cons:
>>* It adds only one bit of security
>>* an implementation that shares code between IKE and TLS will need to store
>>an additional hardcoded prime.
>
> * The IKE values have been around since before IKE (in the form of Oakley),
> nearly twenty years.  These new values have been around since last Wednesday.
> This could mean a difference in anything from 0 to 1024, 2048, or whatever
> bits of security (0 bits if they're no better or worse, the full bitsize if
> they turn out to have some issue that the existing, well-proven ones don't).

What makes you think I sit around all day, looking at a particular
prime, dreaming of ways to break that prime, and not
others?  The analogy to symmetric cryptanalysis is wrong: there is
nothing "well-proven" about the Oakley primes.
>
>>Most people will not have strong preferences here, I assume.
>
> Well I do, the RFC 3526 values are already used in SSH (alongside IKE), and
> I've been using them in TLS as well.  I really don't want to have to implement
> a whole new set of gratuitously incompatible parameters.

I would love to know how your implementation manages to optimize
arithmetic modulo a really nasty
prime. The best strategy I can think of is Montgomery reduction, which
requires a single per-prime table,
so the logic is similar no matter what prime is used. (I don't care
much one way or the other: IKE values
would be fine).

>
> All we need in order to deal with this is a signalling mechanism for which set
> of parameters to use.  The RFC should provide this, and reference a standard
> set of parameters, i.e. the IKE/SSH/whatever ones.  Alongside this there could
> be a second RFC, "Additional parameters for xxx", which contains the new
> parameters, although I can't see why anyone would want them.
>
> (OK, there's always the "as a spare in case the existing ones fail", it's a
> pretty thin argument but I can accept it.  Just make the standard RFC 3526
> ones the default and have any new ones as a backup).

The backup is ECC. The NFS is steadily improving, and harms all primes
almost equally. Add that to the CPU consumption
that keeps people from the higher bitlengths, and the days of prime
group DH are numbered. Backups are only good if people
use them: see the trouble with turning RC4 off.

Sincerely,
Watson Ladd

>
> Peter.
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin