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

[Peter Gutmann <[e-mail]>]

Daniel Kahn Gillmor <[e-mail]> 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.