[theamk]

> Yes, but the packet replay protection is due to the sequence number of the packet that happens after the session is established.

The TLS does not use pre-shared keys. Instead, every time a client establishes a new connection, there is a "key exchange" phase. Here is a simplified explanation:

1. client generates a random number, does some math on it, encrypts with server's certifcate, and sends to server;

2. server generates another random number, does some math on it, and sends to client.

3. after more math (see https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exc... ), both client and server get the session key. If the exchange was not tampered with, both client and server get the same session key.

4. client and server exchange messages encrypted with session key. If they both have the same session key, they will be able to decrypt the message properly; otherwise, the connection is closed.

5. Now client can send a command, such as "open door"

The reason replay protection works is because every time session is established, the server will choose a different random number in step 2. So if you try to replay, then step 3 will generate different session keys, and step 4 will fail.

Once the connection is established, there is a separate counter for replay protection, but it does not have to be complicated -- because we know that the session key is unique to this session alone.

This is how TLS / DTLS / QUIC do replay protection. Do you agree that these protocols are fully replay-protected?

[dwviel]

Yes, I agree that TLS provides replay protection on a suitably reliable network. Don’t know about DTLS or QUIC but I will look further into these. We didn’t really look to much at TCP and TLS, etc. because early on we made design decisions to have components adopt an autonomous posture and work with unreliable networks, as can often be the case for controls. That led us to reject all connection based network protocols such as TCP to avoid the coupling it creates, and to create a very simple, one step protocol for robustness and simplicity. But, I can see where use of TCP and TLS could be useful, even for us, in some cases. To some extent this is a design philosophy that is biased towards simplicity. I’ve noticed that in the software industry there is a bias towards complexity. Almost a need among some to built “Rube Goldberg machines” for everything. Each time a new issue is raised the solution is to add new functionality or feature to handle it until the system is a complex monstrosity, instead of reevaluating the whole enterprise from first principles in light of new requirements. Our concentration is on design. As I like to say “Code is nice, but design is everything.”, and its corollary “No amount of code ever made up for a poor design.” Our concern was to remain compatible with standards to the extent needed to remain switchable and routable on Ethernet and IP networks, but to reduce the problem of controls messaging to the simplest possible level while retaining a high level of security.

[theamk]

Look, you keep saying "on a suitably reliable network". Where do you get this stuff? TLS replay protection is always present and does not depend on network reliability at all. You might not establish TLS connection if your network is super bad, but it does not mean replay is possible.

Can you PLEASE tell me how unreliable network allows TLS replay (or DTLS replay, or QUIC replay -- they all do key negotiation)