Re: [TLS] Confirming Consensus on removing RSA key Transport from TLS 1.3

[Alyssa Rowan <[e-mail]>]

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

On Thu, Mar 27, 2014 at 09:55:27AM +0100, Hanno Böck wrote:
> Appart from the other issues, I think it would make a lot of sense to
> change DHE handling in TLS 1.3 away from "server can have arbitrary
> parameters".

I'm wondering: why even keep DHE around at all?

Let's face it: traditional DHE runs like an absolute dog compared to ECDHE using secp256r1, or especially curve25519 (which we have a live draft for now: I'm ready to start driving deployment almost as soon as we get a curve number!).

Speed is why people were reluctant to deploy PFS, and in many cases in the wild, advised increasing TLS server performance by disabling it (which is bad for everyone). ECDHE eliminates that problem.

Show of hands: who *really* wants to deploy 2048-bit (or above) DHE, when they could have curve25519 instead?

Suggestion: remove static RSA *and* traditional DHE and mandate ECDHE for key exchange in TLS 1.3. I propose,
 curve25519 as mandatory-to-implement and secp256r1 as recommended-to-implement [? Also mandatory, maybe?], both in constant time, which is comparatively easy, especially for 25519.

That would simplify the protocol considerably (decreasing the code and protocol surface to audit), increase its baseline security well above 2048-bit DH, to ~3072-bit (ish) levels, reduce the size of the exchanges and massively reduce the CPU load on both servers and clients.

That seems to me like a win for every one of the good guys and none of the bad guys: TLS 1.3 gets both simpler, easier to audit, more secure *and* faster - and that's the kind of thing that'll drive 1.3 adoption in my opinion. Thoughts?

- --
/akr
-----BEGIN PGP SIGNATURE-----
Version: APG v1.1.1

iQI3BAEBCgAhBQJTNBkkGhxBbHlzc2EgUm93YW4gPGFrckBha3IuaW8+AAoJEOyE
jtkWi2t67zwQAL0qda+2JX6ODJLzhuvKI6v82ng4cWvNh/OnVZ7CNKKq2JR/AdBj
CftYldhG/8ETi4chPhie3q4ovc+uo3NtP1W95zo696s1wPKDYI7/d60SrxvycdSA
zStYAmSxK39cXDvm9iyNNGTVPdvwbZAkiQjFGh+pXIN0c8SP4L11FtDaVhe/7/Ee
4Fn2cpSe9FojMbB7XYqO9QIeLsUzeEgfNBdL58P9ZbpkBK7SsHzu9u5LSSh+vtsF
ejbgwuvaPxDuRVGgKffI3lSUC4GCm0krqgou1eDM2uWMKoBydSOC4JMFbZDWrMrC
1CHDpnyhgU9a6dnBbI6W3mf/vrIddHeN2PAQHyAC7aRhMrMgLqNN7SuXo4ifFmco
tbSNCyiTguYE1juOMsxwMSRGjd0AMM3TSkY85COduWiEjvekfVyuT540CClqrar/
JqHgdo69SjNDT24sGfcMpji/5Hklg+pkUPX/pX9yVzZPUvfER6bRhnb2FaHFvvx0
rPBO/VOgTIP+0DRPYcSNVrkSymFSNs2wBwf8D3FrPa+6gKfByFIelLDY68nDs9O8
v2r+iiNIKKp97CNYJPvzx2srR7IDJF908ZA7U5v5fmUs3+JEV1VxRONwtxj+hJj4
qbQSdOwF/n8uRRsEZ+Z8vAbdo35j8v0DHCnn8T3DxE1qE1ymLFH9XqiK
=g6eK
-----END PGP SIGNATURE-----