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

[Peter Gutmann <[e-mail]>]

Alyssa Rowan <[e-mail]> writes:
>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.

I'm not actually sure where this 768-bit figure came from, I don't see it
anywhere in RFC 3526, which starts at 1536 bits.  Now there is a need for
1024-bit groups to support widespread existing use, but not 768 bits.

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

I've been trying to avoid giving specific examples because then people are
going to focus on individual cases rather than the general problem, but here
are three real use cases from actual deployed or about-to-be-deployed gear.

1. The device has a negative code budget, in that features had to be removed
elsewhere to make room for the crypto (oh, and a negative CPU budget in that
it's really too slow for 1024-bit DH, but we can hold our noses and rely on
session resumption with long-term cacheing).  Adding a few bytes of definition
for a TLS extension specifying a 1024-bit group is OK, adding an ECC
implementation is a complete non-starter.  Currently in the process of being
deployed, expected lifetime is until the hardware fails.

2. The device has hard real-time requirements and can't do dynamic memory
allocation, you get a fixed (small) amount of RAM at build time and that's
all.  The ECC routines (from OpenSSL) with their large memory footprint and
allocation and de-allocation of memory can't be used.  DH can.  Already
deployed but can be upgraded (slightly) in new releases, see (1).

3. The device has gone through a type-approval process and can't be changed
any more barring maintenance (see (1) again).  The vendor won't pay for an ECC
implementation, and even if they did they're not going to restart the whole
type-approval process from scratch.  Rest as for (2).

(In any case ECC is only useful if you can persuade all of your competitors to
do it as well, since if you implement it any no-one can talk to you it's not
much use.  Since the competitors will be facing the same issues as 1...3
above, they probably won't bother with ECC).

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

SCADA security has very, very different requirements than conventional
security, because availability trumps everything else.  In addition SCADA
security is actually problems with backdoors, hardcoded passwords, open ports,
insecure protocols, and a million other things, not the size of the DH key you
use for your TLS handshake.

Adding the ability to secure the DH parameters for existing devices is a small
but significant improvement on security over what's currently being done.  The
choice isn't "secure existing stuff even if it may be not-best-practice vs.
recommend that people upgrade to best-practice stuff", it's "secure existing
stuff or do nothing at all".  Anything that requires hardware changes (bigger
DH groups, switching to new hardware that can handle ECC) becomes "do
nothing".  So instead of ten years of slightly-more-secure DH it's ten years
of no extra security.

(If dkg really doesn't want to add support for the existing groups, I'm happy
to knock out an Informational RFC with the necessary definitions in that based
on his work, it shouldn't take long at all, and he won't have to put his name
to any of it).

Peter.