Björn Haase <bjoern.ha...@conducta.endress.com> writes: >BTW, This is actually why we in the ICS business need TLS1.3 with its fast >options on tiny devices such as X25519 and Ed25519. That's by integer factors >faster on devices such as the M0 or the MSP430 than all of the fastest legacy >options, such as P256!
How are you going to get TLS running on an MSP430 or even an M0? You can barely do anything on an MSP430 (it's enough of a challenge getting a TCP/IP stack going on that, uIP is a rather clever piece of programming but beyond that you can barely serve web pages from it), and an M0 isn't much better. See specifically p.12 of https://www.cs.auckland.ac.nz/~pgut001/pubs/problems.pdf for the MSP430 (those slides predate this thread by a number of years, so it's not something I've set up just for this thread). I would actually love to see a TLS 1.3 implementation on an MSP430. As far as I know it's physically impossible, but if someone did it it'd be both fascinating and horrifying to see what they had to do to make it work. In any case it's not the crypto that's the problem, the biggest code and memory issues are, in order: 1. Certificates. 2. The TLS protocol. 3. The crypto. where (1) >> (2) >> (3). That's why I mentioned in a previous message implementations that use memcpy() for their cert management, which eliminates (1). To process the cert / cert chain, you scan the network read buffer for the string "\x06\x09\x2A\x86\x48\x86\xF7\x0D\x01\x01\x01" and copy out the two integers that follow, so your cert processing is reduced to a few pages of code (the thinking behind this is explained on p.23 of the same slide set). Then you've got (2), which has been getting more and more problematic with each rev of the spec as more and more options get added with each new rev. Luckily you can fast-path the single option you want to support, for example for TLS 1.2 with DHE+RSA you don't need extensions, and if you can do ECC and see an ECC suite in the client hello then you ignore the incoming TLS extensions and write back a fixed blob specifying -256 for everything (P256, SHA256, etc), uncompressed points, and so on. Another thread mentioned that you can't do TLS 1.2 without extensions, when in fact you can, you just rely on the fact that everything supports -256 by default. (This is also why -LTS makes the -256 otions a MTI, it's the de facto default anyway). This is where 1.3 is a problem, not a feature. It's now got so much MTI complexity, most of which is completely unnecessary for SCADA, that any minor gain you might make in the crypto implementation is completely lost in the TLS protocol implementation overhead. I don't know how vendors are going to deal with this. There'll be some tricks used, like the TLS 1.2 "extension handling", but I don't know about the rest. My guess is they'll stay with 1.2, in the same way that they're staying with HTTP 1.1 when 2.0 exhibited the same problems. Having said that: "Predictions are always difficult to make, especially about the future". Peter. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
