4 ms·

Middleboxes are a great example of why cTLS isn't the right direction. cTLS is a smaller TLS, but like TLS, doesn't deal with being proxied. This is by design,

by bdamm 7y ago

Middleboxes are a great example of why cTLS isn't the right direction. cTLS is a smaller TLS, but like TLS, doesn't deal with being proxied. This is by design, of course, because MITM is bad and proxies are MITM. However, there are no deployed wide-area low-power IoT networks I know of that do not use application-layer proxies. Even the cellular offerings I've seen are depending on data collection services as a middle man. OSCORE/EDHOC has been designed to accommodate proxies and provide a secure transport through the proxy, while still allowing the proxy to do its part. Even HTTPS CONNECT doesn't do this. And EDHOC by itself can be used in more exotic key exchange schemes, which it turns out does pop up all the time in IoT design. So yeah, cTLS is a smaller TLS. Which like TLS doesn't meet the needs of today's IoT designers.

jore 7y ago
How long does it normally take for such a draft to become a standard - 4-5 years or less?
harshreality 7y ago
If an app isn't aware it's being proxied, how do you keep TLS secure but allow proxying anyway? There are already solutions for proxying apps/clients when they can be made proxy-aware. One option is to add your corporate CA to the trusted roots list (and transparently proxy through something that auto-generates certs). Another is to have the app explicitly connect to a corporate proxy.company.com site running a forward proxy (non-transparent proxying). What other solutions are necessary? It seems like cTLS is not addressing proxy ability because there's no need to address it. cTLS is addressing power/complexity requirements only, right? For consumer IoT devices, this is all begging the question of whether IoT devices should be directly connecting to anything external. Something like Mozilla's WebThings gateway[1] needs to catch on and become standardized. Even for IoT devices that are capable of supporting TLS to arbitrary internet endpoints, having such devices all talking to arbitrary external sites is a disaster. [1] https://www.google.com/search?q=ycombinator+mozilla+webthings https://www.google.com/search?q=ycombinator+mozilla+webthing...
- cryptonector 7y ago
  I agree. I'm interested in hearing more about why proxies/MITMs need to be supported as first-class actors.
  - 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.

by bdamm 7y ago

jore 7y ago

How long does it normally take for such a draft to become a standard - 4-5 years or less?

harshreality 7y ago

If an app isn't aware it's being proxied, how do you keep TLS secure but allow proxying anyway? There are already solutions for proxying apps/clients when they can be made proxy-aware. One option is to add your corporate CA to the trusted roots list (and transparently proxy through something that auto-generates certs). Another is to have the app explicitly connect to a corporate proxy.company.com site running a forward proxy (non-transparent proxying). What other solutions are necessary? It seems like cTLS is not addressing proxy ability because there's no need to address it. cTLS is addressing power/complexity requirements only, right? For consumer IoT devices, this is all begging the question of whether IoT devices should be directly connecting to anything external. Something like Mozilla's WebThings gateway[1] needs to catch on and become standardized. Even for IoT devices that are capable of supporting TLS to arbitrary internet endpoints, having such devices all talking to arbitrary external sites is a disaster. [1] https://www.google.com/search?q=ycombinator+mozilla+webthings https://www.google.com/search?q=ycombinator+mozilla+webthing...

cryptonector 7y ago
I agree. I'm interested in hearing more about why proxies/MITMs need to be supported as first-class actors.
- 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.