It's like TLS but stateless. In TLS, a handshake is established in at least one round for the key exchange. Thus TLS is stateful.

Suppose we want to have an authenticated and encrypted communication protocol over a stateless transmission channel, or the cost of maintaining states between messages is too high. For example, using HTTP as an underlying transmission channel instead of raw TCP sockets. HTTP is inherently stateless, and it's hard to keep track of the sender of HTTP message behind proxies. Maintaining states over HTTP cost more.

I'm looking for an existing protocol that can be used in such cases. Such that each message is self-contained to complete the full key exchange and authentication. Also it has to address replay attack in some degree since there's no handshake round, just like TLS 1.3 0-RTT.

Of course we have to assume the client and server know each other's public keys. Also by the nature of HTTP/1, server can only reply to a message but can not initiate a conversation with a client. Therefore, only a RPC style protocol is enough for this case, but a more general protocol is preferred.

I have already implemented a custom protocol for this, but it would be much better if there are well maintained protocols for this.

  • $\begingroup$ Avoiding replay attacks seems impossible to me if you're not maintaining any state (possibly unless you include some kind of time related check). Otherwise it is just applying hybrid encryption. I'm not aware of any specific protocol though. $\endgroup$ – Maarten Bodewes Dec 14 '18 at 0:00
  • $\begingroup$ @MaartenBodewes I used a TTL for all idempotent requests (it's of course up to the application to decide which operations are considered idempotent, just like TLS 1.3 0-RTT does). TTL doesn't guarantee safety against replay, it's just a quicker way for server to reject expired messages. For non-idempotent operations I used tokens to ensure the operation can only execute once. It of course introduced some states and added one round of the communication since it's inevitable. But it's the minimum level of state we can add to the protocol, as global tokens don't need to link with sessions. $\endgroup$ – Rix Dec 14 '18 at 0:53
  • $\begingroup$ Great, as long as you and the users of the protocol are (kept) aware of the dangers :) $\endgroup$ – Maarten Bodewes Dec 14 '18 at 2:35

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Browse other questions tagged or ask your own question.