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

From: Peter Gutmann <[email-masked]>
Date: Tue, 29 Jul 2014 13:10:28 +0000

Daniel Kahn Gillmor <[email-masked]> writes:

>There's a possibility that a very expensive (e.g. precomputation) attack
>exists that can be mounted against any given group.  If we reuse the same
>group used by other mechanisms (e.g. ipsec) then the value for mounting such
>an expensive attack goes up.
>
>Selecting a different group forces an attacker to choose which group to
>attack.

Yeah, I can see that, but it's a bit of a hypothetical attack, we have no way
to quantify the risk.  For something like "don't use the same key to encrypt
and MAC" there's a clear, well-known threat, but for "don't use the same key
(DH group) for IPsec and TLS" it's really just speculation.  Once you start
down this path, where do you stop?

>This was based on the 112-bit symmetric equivalence published by ECRYPT II.
>The ECRYPT document is referenced in the draft.

Is there really any good reason to want to match group size to algorithm key
sizes, and (I'm assuming for a 112-bit key) one for an obsolete (if still
widely-used) block cipher?  I'd just pick some standard group sizes (1K, 2K,
3K, 4K) and go with those as general-purpose solutions rather than selecting
oddball sizes to match some particular other algorithm.

(Where did the fashion of specifically choosing the hat to match the shoes
come from in crypto?  AFAIK it's NSA-originated from things like the original
DSA's hardcoding of the SHA-1 blocksize into the algorithm, and KEA and
Skipjack key sizes.  I've never been able to understand why something like a
particular cipher block size needs an entire range of fashion accessories to
go with it, if an n-bit prime is good enough for a 256-bit symmetric algorithm
then it should also be good enough for 128 bits, 192 bits, and 77 1/2 bits).

>by q i think you mean (p-1)/2 -- i'm happy to document those values
>explicitly in the draft if you think that would be useful.

Yes, thanks.

Peter.

---

From: Fedor Brunner <[email-masked]>
Date: Tue, 29 Jul 2014 14:08:43 +0000

> down this path, where do you stop?

If we assume an attack exists for fixed DH group then not fixed  DH
groups generated for each server (as is current option in TLS) would
make the attack much more expensive.

In RFC 4253 (The Secure Shell (SSH) Transport Layer Protocol) 1024-bit
MODP Group, 2048-bit MODP Group are used. But the newer RFC 4419 allows
to use arbitrary safe primes.

For example OpenSSH supplies a set of 40 DH groups for each 1023, 1535,
2047, 3071, 4095, 6143, 8191-bit primes . During key exchange one of
these groups with desired size is selected in server by random. The
OpenSSH server administrator can also generate his own set of DH
parameters, for each prime length.

OpenSSH supports also elliptic curve Diffie-Hellman key agreement using
NIST curves and Curve25519.

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>