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

[Peter Gutmann <[e-mail]>]

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

>yes, and that's a deliberate choice, as documented (perhaps not well enough?)
>in the draft under "Choice of Groups".

The reasons given aren't very convincing, it's just "they're too widely used".
On the one hand that could be a problem, but it's also a huge advantage,
you're just documenting existing practice rather than forcing everyone to
switch to an entirely new set of groups they've never seen before.  If I'm
using OpenSSL (which it seems two thirds of the planet is) I just call
get_rfc2409_prime_1024() or get_rfc3526_prime_2048() or whatever, for pretty
much any version of OpenSSL in current use, and it works.  Apache already uses
these parameters by default (or did, I haven't checked recently).  If you want
to invent new, nonstandard parameters then by all means feel free to do so,
but don't lock out the existing ones that have been in widespread use for
years.

>Some of the MODP groups (768, 1024, 1536 at least) are also smaller than we
>should be explicitly supporting in updated tools, so i don't think re-
>blessing them into another standard is a good idea.

Shorter groups are still required for embedded devices. You're not "blessing"
them, you're just giving people the option to use them.  If you require the
use of large groups as the current draft does then you're automatically
excluding it from being used by many embedded devices.

>One counterargument i'm aware of is that systems that want to support both
>sets of groups would need to have a larger table of known moduli. So perhaps
>the argument is that extremely memory-constrained devices running both TLS
>and IPSec (or TLS with SRP) could share a table of known moduli to reduce RAM
>consumption?  

Constrained devices won't be using 2K+ bit groups anyway so in a sense this
isn't a problem, but "solving" things by excluded whole classes of users
doesn't seem like a good approach to things.

>We had a discussion about the use of e-derived safe primes instead of pi-
>derived safe primes in Toronto, and no one seemed to think that the groups
>currently proposed were any worse than the MODP groups.

They're not worse, but they're also both completely different from the de
facto standard groups and can't be used by whole classes of users.  As I
mentioned earlier, if you want to introduce fancy new groups then by all means
go ahead, but don't lock out existing uses and users.

Peter.