Re: [mosquitto-dev] eDRX and MQTT

[Greg Troxel <gdt@xxxxxxxxxx>]

Frank Pagliughi <fpagliughi@xxxxxxxxxxxxxx> writes:

> I've never tried TLS caching, but that seems an interesting path to
> explore. But I don't know that it would work. The MQTT server expects
> a single MQTT connect packet per network connection - as the first
> packet received.

My understanding is little fuzzy, but I think the idea is that you get a
new TLS connection in terms of each side having a fresh connection with
no client/server state.  But, instead of having to do the full DH
exchange, authenticate, establish session keys, the client is able to
say "I am reusing the crypto context from before, with identifier X".
Then both sides use their symmetric keying material that they each
remmembered.  From the TLS security point of view, the fact that the old
TCP connection is gone and there is a new one is not important.  I would
guess that username/password login needs to be done again, although the
resumed session is not really different from the original one in terms
of being able to treat data that passed the MAC as having come from the
authenticated entity.

I can certainly see your point about how it would confuse applications
if the new TCP connection was spliced into the old one without warning.
But I think the idea is to have a new logical connection, just avoiding
the crypto negotiation.  So the behavior as seen by the client and
server programs should be the same, but with fewer round trips and fewer
bignum operations.

https://tools.ietf.org/html/rfc5246
https://tools.ietf.org/html/rfc5077
https://blog.cloudflare.com/tls-session-resumption-full-speed-and-secure/

Probably, depending on TLS libraries, this is already happening in some
cases.  But the server-side code might have to opt in.