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

From: Peter Gutmann <[email-masked]>
Date: Fri, 24 Oct 2014 14:55:10 +0000

Alyssa Rowan <[email-masked]> writes:

>>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 the need to implement an entirely new type of crypto on a constrained
device with a ten-year product cycle for which the crypto development budget,
now that it's already been deployed for several years, is $2.50.  Revving the
firmware on new products to support a new TLS extension for EDH indication
will probably happen at some point.  Re-doing the crypto to implement and
support ECC may happen in five to ten years, if there's enough code space in
the flash.

>No, it's blessing them even to list them. People will probably implement what
>we specify.

So put in a note saying that use isn't recommended.  This isn't a bunch of
Windows PCs with automatic update turned on, its unknown millions of embedded
devices whose firmware is updated when the device falls apart and gets
replaced, and for which you may get away with a small tweak from time to time
but can't do any significant re-engineering once it's type-approved ("it
works, don't touch it any more").

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

... who probably won't be using that capability to attack a power meter, or a
flow monitor.  This isn't protecting nuclear weapons launch facilities, it's
for remote monitoring of fluid flows, or power metering, or a million other
SCADA applications that merely need better-than-nothing security.  Being able
to say "only use this DH group" is an improvement on current practice in which
anything is accepted.

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

So you're producing an RFC which will automatically be ignored, in fact which
will *have* to be ignored, by a significant market segment, and they'll stay
with their existing unverified DH.  The RFC will then have completely failed
to achieve what it's intended to achieve.

Peter.

---

From: Geoffrey Keating <[email-masked]>
Date: 24 Oct 2014 13:14:50 -0700

> works, don't touch it any more").

As a rule, devices whose firmware isn't/won't/can't be updated, won't
implement any new RFC, including this one.  So we are writing this RFC
for devices whose firmware will be updated and which are willing to
adopt 21st century technologies like ECDH or 2048-bit DH.

(And, for the record, I think it's insane to be even considering
standardising anything to do with 768-bit DH other than MUST NOT use
it!)

---

From: Alyssa Rowan <[email-masked]>
Date: Fri, 24 Oct 2014 22:05:37 +0100

On 24/10/2014 15:55, Peter Gutmann wrote:

> Re-doing the crypto to implement and support ECC may happen in five
>  to ten years, if there's enough code space in the flash.

So, you want to use 768-bit groups… for five to ten years… yeah, I'm
not too comfortable with that.

>> No, it's blessing them even to list them. People will probably 
>> implement what we specify.
> So put in a note saying that use isn't recommended.

…or, you could not put it in.

Intentionally specifying something new, in a security-oriented RFC,
that by the way you absolutely shouldn't use because it's insecure,
seems a bit reckless to me.

> ("it works, don't touch it any more").

I think we really ought to be getting rid of skeletons in the closet,
not adding new ones - despite Hallowe'en being next week, and that
phrase being appropriately spine-chilling! ;)

(BTW: Lost, embedded devices; too small to use a 2048-bit group for…
some reason? RAM?; yet negotiate (768|1024|1536) DHE…

…wild guess here: RSA key signing this exchange is totally
minty-fresh? …and actually checked? With something that isn't MD5? And
the DHE keys aren't generated with 2 bits of entropy and a potato
because the $2.50 intern lunch budget didn't cover an RNG? <g>)

>> 768 and 1024 are crackable today by any reasonably well-funded 
>> adversary with access to a chip fab, as you well know;
> ... who probably won't be using that capability to attack a power 
> meter, or a flow monitor

…or a centrifuge? ¬_¬

SCADA security - or lack thereof - is a very big problem. I don't
agree that specifying groups for future use that we _know_ are too
small, helps do anything but make it worse.

- -- 
/akr

---

From: Stephen Checkoway <[email-masked]>
Date: Fri, 24 Oct 2014 18:44:03 -0400

The arguments against including small groups seem clear:

1. New things shouldn't be using small groups.
2. Old things that can't/won't be updated _won't be updated_ no matter what a new RFC says.
3. This doesn't prohibit arbitrary groups so anything that needs to keep using small groups can keep using small groups.

The argument for including small groups seems to be (and correct me if I've missed something):

Old things can't/won't be updated except for (maybe) small tweaks and this extension is a small tweak that would enable these devices to keep doing what they're already doing: using small groups.

Particularly in light of 3, I don't find the argument for including them compelling.

S

On Oct 24, 2014, at 5:05 PM, Alyssa Rowan <[email-masked]> wrote:

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

-- 
Stephen Checkoway