Ilari Liusvaara <ilariliusva...@welho.com> writes: >On Thu, Sep 22, 2016 at 05:11:39AM +0000, Peter Gutmann wrote: >> It also means you're going to be in for a rude shock when you encounter the >> ocean of embedded/SCADA/IoT devices with non-mainstream TLS implementations. > >That did not check for interop with any mainstream TLS library?
Mainstream TLS 1.3 libraries? Since the spec is still subject to weekly changes, I doubt there's anything to interop test with. (It's actually a bit of a rhetorical question, since I've seen little to no evidence that embedded/SCADA/etc has any intention of throwing away their existing investment and starting again with 1.3 or 2.0 or whatever it'll be called, I doubt there'll be much to non-interop with. >Also, code to "recover" tends to introduce security issues if used in >security protocols. This isn't "code to recover", it's just normal code. If anything, it's adding additional code to check for problems that aren't really problems that'll lead to security issues. >Well, the problem you encounter first with HTTP/2 is that it really dislikes >unencrypted operation. Which impiles you pretty much need encryption. Which >impiles you pretty much need the WebPKI certificate model... Which tends to >be poor match for anything except named servers on the internet, which tends >not be suitable for IoT stuff... Yup. The HTTP/2 folks' response to this at the time was "let them eat 1.1", pretty much guaranteeing a fork of the HTTP protocol, with two different versions being maintained in perpetuity. Peter. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
