4 ms·

Sure. The kinds of IoT devices I work with aren't consumer IoT. We operate networks of devices where a sensor may be attached to a network interface and the app

by bdamm 7y ago

Sure. The kinds of IoT devices I work with aren't consumer IoT. We operate networks of devices where a sensor may be attached to a network interface and the application driving that sensor is somewhere out on the Internet (perhaps on a VPN). The application wants to connect to the sensor (perhaps for configuration) and to do that needs access to the network on which that device is operating. The network won't be exposed to the public Internet, and is protected via access rules enforced at a proxy, and traffic management may be done at a proxy as well. The application vendor may not trust the network operator with payloads, so wants to keep their payloads secret. So the result is a need for proxies where the payload is secret, but the destination is not, and a secure end-to-end envelope (from the application to the sensor) can be formed. TLS can't address this. Nor can VPNs.

cryptonector 7y ago
The way I'd build this, if I had to, is to a) terminate TLS at the proxy, b) use some an interior protocol (possibly TLS) between the client and the sensor, with the client telling the sensor a digest of (or perhaps the whole) EE certificate presented by the proxy. This might look like a CONNECT if the proxy will permit it, though using HTTPS to talk to the proxy, not HTTP, naturally. Or it might look like a full-duplex POST to the sensor through the proxy, with TLS being spoken over that POST. If neither CONNECT nor full-duplex POST are options, I might try Websockets, and as a last resort, I'd split up the protocol into multiple POSTs, one for each round trip. EDIT: At any rate, this sounds exactly like what CONNECT is for, and this covers your needs: - The client trusts the proxy if it can authenticate it. The proxy is an explicit client-side proxy, though it's actually on the server-side, which might seem strange. - The client trusts the device if it can authenticate it. The proxy cares only to decide whether to route the request. - The proxy may need the client to authenticate to the proxy -- there exist headers for this, and the client could also use a user certificate in the TLS connection to the proxy. - The client may need to authenticate to the device, which it can do in the TLS connection to the device that runs over the outer CONNECT, with all existing choices for authentication available. The only strange thing is that historically client-side proxies are accessed w/o TLS, but you really need to use TLS here because the "client-side proxy" is actually far away, across the big bad Internet. That client-side proxies are usually talked to w/o TLS is really a bug. EDIT: If you find that getting your client to use TLS to talk to the proxy is difficult, just think how much more difficult it is to implement a new protocol from scratch.
- bdamm 7y ago
  You missed the requirement for the payloads to be secret from the proxy. If the proxy is terminating TLS, then the payload isn't secret from the proxy (and the sensor can't authenticate the source except as from the proxy, either.) It's worth adding that in my case there is no TCP or HTTP, so the home stretch over the LPWAN is UDP and CoAP.
  - cryptonector 7y ago
    I did not miss that. The client runs the TLS connection end-to-end (to the device) over the CONNECT. That connection will be secure relative to the proxy. That there's no TCP/HTTP doesn't alter any of this. You can use UDP and DTLS this way, except you'll have to create the proxy protocol, and you'll need the proxy to maintain some "connection" state, and you'll need to expose inner connection close to the proxy so it can cleanup that "connection state".
    - 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.

by bdamm 7y ago

cryptonector 7y ago

The way I'd build this, if I had to, is to a) terminate TLS at the proxy, b) use some an interior protocol (possibly TLS) between the client and the sensor, with the client telling the sensor a digest of (or perhaps the whole) EE certificate presented by the proxy. This might look like a CONNECT if the proxy will permit it, though using HTTPS to talk to the proxy, not HTTP, naturally. Or it might look like a full-duplex POST to the sensor through the proxy, with TLS being spoken over that POST. If neither CONNECT nor full-duplex POST are options, I might try Websockets, and as a last resort, I'd split up the protocol into multiple POSTs, one for each round trip. EDIT: At any rate, this sounds exactly like what CONNECT is for, and this covers your needs: - The client trusts the proxy if it can authenticate it. The proxy is an explicit client-side proxy, though it's actually on the server-side, which might seem strange. - The client trusts the device if it can authenticate it. The proxy cares only to decide whether to route the request. - The proxy may need the client to authenticate to the proxy -- there exist headers for this, and the client could also use a user certificate in the TLS connection to the proxy. - The client may need to authenticate to the device, which it can do in the TLS connection to the device that runs over the outer CONNECT, with all existing choices for authentication available. The only strange thing is that historically client-side proxies are accessed w/o TLS, but you really need to use TLS here because the "client-side proxy" is actually far away, across the big bad Internet. That client-side proxies are usually talked to w/o TLS is really a bug. EDIT: If you find that getting your client to use TLS to talk to the proxy is difficult, just think how much more difficult it is to implement a new protocol from scratch.

bdamm 7y ago
You missed the requirement for the payloads to be secret from the proxy. If the proxy is terminating TLS, then the payload isn't secret from the proxy (and the sensor can't authenticate the source except as from the proxy, either.) It's worth adding that in my case there is no TCP or HTTP, so the home stretch over the LPWAN is UDP and CoAP.
- cryptonector 7y ago
  I did not miss that. The client runs the TLS connection end-to-end (to the device) over the CONNECT. That connection will be secure relative to the proxy. That there's no TCP/HTTP doesn't alter any of this. You can use UDP and DTLS this way, except you'll have to create the proxy protocol, and you'll need the proxy to maintain some "connection" state, and you'll need to expose inner connection close to the proxy so it can cleanup that "connection state".
  - 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.