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

Peter Gutmann:
> Daniel Kahn Gillmor <dkg@fifthhorseman.net> 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?
> 

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.

>> 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.
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
> 