Re: [TLS] PSK in 1.3?

[Watson Ladd <[e-mail]>]

On Sun, Oct 19, 2014 at 6:41 AM, Hauke Mehrtens <[e-mail]> wrote:
> On 10/19/2014 03:03 PM, Yoav Nir wrote:
>> As Ilari said, there are ciphersuites with PSK and FS.
>>
>> I don’t see what the rationale can be to allow non-PFS for PSK authentication, but prohibit it for certificate authentication.  That would imply that we can make a blanket statement that the data passed in PSK-authenticated sessions is inherently low-value or non-private.  I don’t think we can make that statement.
>
> For using PFS some asymmetric cryptography is needed in addition to the
> symmetric cryptography and without PFS only symmetric cryptography is
> needed. For normal desktop usage this does not matter, but when you want
> to use TLS and DTLS on some embedded devices like Class 1 node (see
> rfc7228 section 3.) with ~ 10 KiB ram and ~ 100 KiB flash and a slow CPU
> (~ 10MHz) without any hardware cryptography support a DTLS handshake
> without PFS is possible in under two seconds while doing a handshake
> with PFS with asymmetric cryptography like ECC would take more than 10
> seconds or even minutes.
> In addition adding ECC also adds some more code.
>
> I tried a DTLS handshake between two simulated MSP430X and it took 3.3
> seconds for the PSK handshake using TLS_PSK_WITH_AES_128_CCM_8 and it
> took 336 seconds for a handshake using the
> TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 cipher suite on the curve secp256r1
> without client authentication and 499 seconds with client
> authentication. The slow part was the elliptic curve multiplication
> which took 47 seconds. (my code was not very optimized and this was a
> very slow CPU)

These costs are close to the costs presented in
http://discovery.csc.ncsu.edu/software/TinyECC/TR-2007-36.pdf, and so
are in the right ballpark. However, there are several reasons why
ECDHE_ECDSA is not optimal. The first is signing and validation takes
a long time, the second is that genus 2 is faster. I also think there
are some papers that get better multiplication times, but I don't
think dramatically so.

If we want, we can fix these reasons by moving to solutions like the
Triple-DH handshake. But this ends up forcing new certificates and
kinds of keys on everyone, and getting genus 2 through CFRG should be
easy, but won't be/compatibility concerns.

You seem to have a point though: embedded devices use TLS because it
can avoid public key cryptography. Removing that option has costs, and
makes TLS 1.3 less useful than otherwise. Now, would sticking with TLS
1.2 be an option?

Sincerely,
Watson Ladd

>
> Hauke
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls



-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin