3 ms·

This is kind of a lot of work when there could be a protocol that I can use instead. Like OSCORE with EDHOC. Sure I can go gluing things together but that's mor

by bdamm 7y ago

This is kind of a lot of work when there could be a protocol that I can use instead. Like OSCORE with EDHOC. Sure I can go gluing things together but that's more work for me and my people. We have other things to do like build kick ass network management tools etc.

cryptonector 7y ago
Having had to maintain proxies, yes, it's a lot of work. But! Building a new protocol, and implementations for it, and applications for it, has got to be strictly more work than building a nested TLS protocol and implementation. More work for you, and for the rest of us who would have been happy not to have to deal with it but are forced to by new realities on the ground created by people who thought a new protocol would be less work. More chances to get the crypto wrong. I'm not keen on this. I'm all-in on TLS 1.3, not because it's great but because it's the only way to reduce the pressure to create new legacy. Legacy is fantastically expensive, so I'd rather not create more of it if we don't have to. To be fair, I'm told that even TLS 1.3 might not fit the power profile of IoTs, however, that's ameliorated by time, and it would also be ameliorated by cTLS, so I'm not sure that's enough to justify a new protocol.
- bdamm 7y ago
  Well, we have legacy anyway, because I can't economically use TLS or DTLS this way, so I already have a proprietary protocol. Presumably other designers are in the same position I am. And I'm not the only one looking hard at EDHOC and OSCORE, there are some pretty significant hitters in the IoT scene right now that are also looking at this and for the same reasons we are - standardized approaches in an industry sorely needing both standards and functional solutions that work on real networks. But yeah, building protocols is hard. I should know, since I've been building a dead-end protocol for over 10 years, including HSM support, massive scale, proxy scenarios, HA support, and blistering pen tests, that I am very ready to give up for OSCORE/EDHOC. TLS is not going to be "ameliorated by time"; RF isn't getting cleaner, radios are already very efficient, power management has gotten decent and there's not a lot left to squeeze. Putting bits in the air will continue to cost money. Embedded IoT will continue to chase the tiniest scrappiest cheapest hardware. Where do you think this "amelioration" is going to come from? TLS is going to get worse for IoT over time, not better. There will be ever more code points in TLS. The WG is going to continue to focus on big-box issues, privacy issues, server deployment issues, ever finer controls on timing attacks, extensions for SNI and other CDN issues. IoT problems will be solved elsewhere, with a different protocol, and that's fine.
  - cryptonector 7y ago
    I'm curious what all we could throw out in a cTLS or uTLS to serve the power/RF constrained environments of IoTs. If we must have a new protocol, I'm keen on making it as similar as possible to TLS 1.3 that the costs of designing, reviewing, implementing, and maintaining it, are much lower than that of a brand new protocol.
    - bdamm 7y ago
      There are SO MANY changes to be made for constrained devices. Just a couple quickies, certificate order is all backwards. Eliminate basically all use of DER, preferring CBOR instead. Define larger coarse protocol presets instead of dozens of optional extension points. Also TLS has no certificate caching, which for some radios is nearly fatal and will be a major issue with embedded and PQC. Etc..

by bdamm 7y ago

cryptonector 7y ago

Having had to maintain proxies, yes, it's a lot of work. But! Building a new protocol, and implementations for it, and applications for it, has got to be strictly more work than building a nested TLS protocol and implementation. More work for you, and for the rest of us who would have been happy not to have to deal with it but are forced to by new realities on the ground created by people who thought a new protocol would be less work. More chances to get the crypto wrong. I'm not keen on this. I'm all-in on TLS 1.3, not because it's great but because it's the only way to reduce the pressure to create new legacy. Legacy is fantastically expensive, so I'd rather not create more of it if we don't have to. To be fair, I'm told that even TLS 1.3 might not fit the power profile of IoTs, however, that's ameliorated by time, and it would also be ameliorated by cTLS, so I'm not sure that's enough to justify a new protocol.

bdamm 7y ago
Well, we have legacy anyway, because I can't economically use TLS or DTLS this way, so I already have a proprietary protocol. Presumably other designers are in the same position I am. And I'm not the only one looking hard at EDHOC and OSCORE, there are some pretty significant hitters in the IoT scene right now that are also looking at this and for the same reasons we are - standardized approaches in an industry sorely needing both standards and functional solutions that work on real networks. But yeah, building protocols is hard. I should know, since I've been building a dead-end protocol for over 10 years, including HSM support, massive scale, proxy scenarios, HA support, and blistering pen tests, that I am very ready to give up for OSCORE/EDHOC. TLS is not going to be "ameliorated by time"; RF isn't getting cleaner, radios are already very efficient, power management has gotten decent and there's not a lot left to squeeze. Putting bits in the air will continue to cost money. Embedded IoT will continue to chase the tiniest scrappiest cheapest hardware. Where do you think this "amelioration" is going to come from? TLS is going to get worse for IoT over time, not better. There will be ever more code points in TLS. The WG is going to continue to focus on big-box issues, privacy issues, server deployment issues, ever finer controls on timing attacks, extensions for SNI and other CDN issues. IoT problems will be solved elsewhere, with a different protocol, and that's fine.
- cryptonector 7y ago
  I'm curious what all we could throw out in a cTLS or uTLS to serve the power/RF constrained environments of IoTs. If we must have a new protocol, I'm keen on making it as similar as possible to TLS 1.3 that the costs of designing, reviewing, implementing, and maintaining it, are much lower than that of a brand new protocol.
  - bdamm 7y ago
    There are SO MANY changes to be made for constrained devices. Just a couple quickies, certificate order is all backwards. Eliminate basically all use of DER, preferring CBOR instead. Define larger coarse protocol presets instead of dozens of optional extension points. Also TLS has no certificate caching, which for some radios is nearly fatal and will be a major issue with embedded and PQC. Etc..