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

From: Peter Gutmann <[email-masked]>
Date: Fri, 24 Oct 2014 11:32:35 +0000

Daniel Kahn Gillmor <[email-masked]> 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.

---

From: Alyssa Rowan <[email-masked]>
Date: Fri, 24 Oct 2014 14:04:43 +0100

On 24 October 2014 12:32:35 BST, Peter Gutmann <[email-masked]> wrote:

>>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.

With respect, no, they aren't. 256-bit ECDHE is --> that way. Don't use 1024-bit DHE; use 256-bit ECDHE. More security, more speed, less size; and that's even before CFRG's Christmas present of (X25519|numsp256t1).

Constrained devices are absolutely no excuse for second-or-third-rate crypto. Certainly not today when we know better.

>…you're just giving people the option to use them.

No, it's blessing them even to list them. People will probably implement what we specify. They'll assume we did a good job. If we give people the option to use them, they'll use them. It's inappropriate to use them, because they're widely considered too small to use anymore. So don't list them. Simple.

Technology marches on, I'm afraid; key sizes need to march on too. 768 and 1024 are crackable today by any reasonably well-funded adversary with access to a chip fab, as you well know; 1536 may not be, but I wouldn't chance it anymore as Moore's law benefits the attacker more than embedded devices, attacks always get better over time, and the most pernicious adversaries record traffic in case they can crack it later. It may not be cheap or very practical for them to do so, but we can nevertheless avoid it, so we should.

Keep the groups to >= 2048-bit, please.

- --
/akr

---

From: Manuel Pégourié-Gonnard <[email-masked]>
Date: Fri, 24 Oct 2014 18:51:55 +0200

On 24/10/2014 13:32, Peter Gutmann wrote:
> them, you're just giving people the option to use them.

People already have the option to use arbitrary groups, and it itsn't going away
with this draft. This draft is about improving security, I don't think it makes
sense to standardise shorter groups in this context.

Manuel.

PS: besides, I agree that constrained devices had better use ECC anyway.