In search of: Lightweight secure tunnel protocol for use between well-known peers

  • Articolo

I have an immediate job opening for an open standard or multivendor transport layer security protocol that

  1. does NOT rely on or tie into PKI and especially
  2. doesn’t require the exchange of X.509 certificates for an initial handshake,
  3. supports session resumption, and
  4. can be used with a minimal algorithm suite that is microcontroller friendly (AES-256, SHA-256, ECDH)

Because

  1. For “service assisted connectivity” where a device relies on a gateway to help with any defensive measures from the network layer on up, the device ought to be paired with exactly one (cluster of) gateway(s). Also, an unobserved device should not pose any threat to a network that it is deployed into (see the fridges abused as spam bots or local spies) and therefore outbound communication should be funneled through the gateway as well. TLS/PKI specifically enables promiscuous clients that happily establish sessions with any “trustworthy” (per CA) server, often under direction of an interactive user. Here, I want to pair a device with a gateway, meaning that the peers are known a priori and thus
  2. the certificate exchange is 3-6kb of extra baggage that’s pure overhead if the parties have an existing and well-known peer relationship.
  3. Session resumption is required because devices will get disconnected while roaming and on radio or will temporarily opt to turn off the radio, which might tear sockets. It’s also required because the initial key exchange is computationally very expensive and imposes significant latency overhead due to the extra roundtrips.
  4. Microcontroller based devices are often very constrained with regards to program storage and can’t lug a whole litany of crypto algorithms around. So the protocol must allow for a compliant implementation to only support a small set of algos that can be implemented on MCUs in firmware or in silicone.

Now, TLS 1.2 with a minimal crypto suite profile might actually be suitable if one could cheat around the whole cert exchange and supply clients with an RFC5077 session resumption ticket out-of-band in such a way that it effectively acts as a long-term connection authN/Z token. Alas, you can't. SSH is also a candidate but it doesn't have session resumption.

Ideas? Suggestions? clemensv@microsoft.com or Twitter @clemensv

Comments

  • Anonymous
    February 06, 2014
    The link for [1] seems to be missing. Also, you don't mention what the actual crypto properties you want in the protocol... As for TLS, certificates aren't required by the protocol (though I don't know of anyone that uses TLS with just Diffie-Hellman ephemeral keys in practice), though not sure if that is compatible with RFC5077. As for SSH, I'm assuming you have seen this proposal? cnds.eecs.jacobs-university.de/.../2009-im-ssh-resumption.pdf

  • Anonymous
    February 06, 2014
    One problem with TLS is that existing stacks assume certs. I'm actually ok with a fixed key pair or even symmetric keys to drive the session key exchange. I know the SSH session resumption proposal, but that's not helping me, because it's not an actual thing.

  • Anonymous
    February 06, 2014
    Agree that some TLS implementations don't support this. I've certainly used anonymous key exchange handshakes with OpenSSL and others successfully quite nicely, though I have no experience with any implementation of RFC 4279. Also agree with the SSH thing, but it wasn't clear to me if you were looking for an existing, widely deployed protocol or other alternatives. And again, not sure what you want the protocol to support. Merely confidentiality, or do you also need it to support server-side or mutual authentication?

  • Anonymous
    February 06, 2014
    I need authentication by ways of the two parties agreeing on a shared secret or key pair. That is sufficient.