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

[Alyssa Rowan <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 24 October 2014 12:32:35 BST, Peter Gutmann <[e-mail]> 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
-----BEGIN PGP SIGNATURE-----
Version: APG v1.1.1

iQI3BAEBCgAhBQJUSk5qGhxBbHlzc2EgUm93YW4gPGFrckBha3IuaW8+AAoJEOyE
jtkWi2t6pZcQAKUWhsd8eY7kJjc9bEdFN/bY1xL4qeeE3gj199P89zLfgPGrfVMN
xhya/luKqPg4mrUbXqiVMoAjFxC+RUvN4SHVEcQRX8BUI1t4Z/Dpcm4T9z2nXJYV
3qB3++fJIbD7P9Ep7Q4TQUVMfho5UI1fyVtvG/Hnl4NjrIAW5q5JVkf2urKvfL35
K3oe1UVVoWG83EXMy16YgCAaduwrMQLs+lAFRLvnywTf1e3fj1gfMtq5v0GkzGoJ
5u+ukpesC+B7POlUb6FSKdGEU9NDdojP6g1Uykg2SW4s+Ad8WZ6qTL7verh/AOoJ
9IzF46UOccJtVvWuVGHyYhBtIxUmCJytaAmD7s3hjY0qlTOEqm0WlW0vblXAxXJe
mgCE2k4Ms9fyYf4+t7QBiZ46ZoVkOPQEwhT9V9MgrKdSOdDtgELOJjFh3DK11X0m
IqJ1F8aY5ijxQxFGvJEEt4bWK9HOO9dinNOXC5ObyJouRMp6XviLqwSQcFRXGWsD
x0HiPVmCFe31k8kljeSP2lMVRaEVd49O4PRZYjg2PbdGcZDQ/Rpx5TSB0DN1Ds5E
GdQ8/W5wI/vI/QASTA/DIAZP5FAyYorhOOqvOiamEEhiL5+kQmPAzunS7uSrHPqo
IT5HWPVE3DKbOIBK4aWX5eyymia18Ub+DUOJlE9R9hmsQMEfh7fSjNaD
=pcZG
-----END PGP SIGNATURE-----