4 ms·

This is unlikely to get adopted as a standard, because it only exists in response to OSCORE[1] and EDHOC[2]. The draft is an effort to prove that the TLS workin

by bdamm 7y ago

This is unlikely to get adopted as a standard, because it only exists in response to OSCORE[1] and EDHOC[2]. The draft is an effort to prove that the TLS working group, which almost exclusively deals with large-scale devices such as laptops, phones, and servers, will listen to and address the needs of the embedded devices (IoT) community. The challenge is that the draft didn't exist until a working group formed to create a light-weight protocol, thereby proving that the TLS working group actually won't address embedded. Whether cTLS or EDHOC become RFCs remains to be seen, but my money is on EDHOC. [1] https://datatracker.ietf.org/doc/rfc8613/ https://datatracker.ietf.org/doc/rfc8613/ [2] https://datatracker.ietf.org/doc/draft-selander-ace-cose-ecdhe/ https://datatracker.ietf.org/doc/draft-selander-ace-cose-ecd...

tialaramex 7y ago
It's slated as Informational not Standards Track. You say that "The draft is an effort to prove that the TLS working group, which almost exclusively deals with large-scale devices such as laptops, phones, and servers, will listen to and address the needs of the embedded devices (IoT) community" but you don't present any evidence for that whatsoever. Rescorla's presentation of this at the IETF just gone didn't sound to me like he was trying to "prove" anything to the IoT community, whether to the extent that's represented by core (the working group that produced RFC 8613) or in a broader sense, it would surely make sense for anyone trying to do that to present _to_ that community and not to the TLS Working Group. cTLS is just smaller TLS, it doesn't even say "This is for embedded" anywhere. The reason TLS itself isn't smaller is purely for interop reasons, if you don't have interop concerns (e.g. there aren't middleboxes in your network) then cTLS in principle gives you all the same benefits for less bits on the wire.
- cryptonector 7y ago
  The target track can change at any time. The TLS WG might well adopt it.
- 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

by bdamm 7y ago

tialaramex 7y ago

It's slated as Informational not Standards Track. You say that "The draft is an effort to prove that the TLS working group, which almost exclusively deals with large-scale devices such as laptops, phones, and servers, will listen to and address the needs of the embedded devices (IoT) community" but you don't present any evidence for that whatsoever. Rescorla's presentation of this at the IETF just gone didn't sound to me like he was trying to "prove" anything to the IoT community, whether to the extent that's represented by core (the working group that produced RFC 8613) or in a broader sense, it would surely make sense for anyone trying to do that to present _to_ that community and not to the TLS Working Group. cTLS is just smaller TLS, it doesn't even say "This is for embedded" anywhere. The reason TLS itself isn't smaller is purely for interop reasons, if you don't have interop concerns (e.g. there aren't middleboxes in your network) then cTLS in principle gives you all the same benefits for less bits on the wire.

cryptonector 7y ago
The target track can change at any time. The TLS WG might well adopt it.
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