> Thinking about it, what would you want for an unreliable stream beside encryption? Isn't DTLS taking care of what you want?
No, the encryption/transport is a nice part, but I'm also working on other stuff like federated authentication.
Besides, why would a developer want to use different stacks when he can use one that includes all the others? I believe protocols should be as general as possible, so I really see no reason not to include this.
> Are you comparing it to TLS 1.3? If you're doing a PSK-based handshake with no key exchange, they should provide the same security properties.
I was comparing it to a standard TLS key exchange with PFS enabled.
> Can you tell me what you're talking about? I don't know the spec by heart.
As I said I remember old information so I have not checked the latest draft, but I am sure that after the connection is set up the server and client continue to flip a single bit somewhere, and hash the result. This hash is sent by the client to the server so that the server can check that the client owns the IP and is actually receiving the data.
Don't know if they still have it, but it was there a couple of years ago.
> the server and client continue to flip a single bit somewhere, and hash the result
There is a "message authentication hash" being sent in messages and I can't see anything about that in the spec, so that might be it?
But two things about that:
* I don't think it makes much sense to prove that you own the IP after the handshake has been done. It's mostly a countermeasure to DoS attacks for the very first handshake message
* The client should actually be able to roam and change IP without having to re-negotiate a secure connection with the server, as long as it uses the same 64-bit connectionID.
Think Jabber, AD, kerberos, email... those are federated environments.
Basically you tie a user to a domain, have some way to discover all domains, and design an authentication that can be trustworthy enough for the interaction of multiple domains. The end result is that your username is (more or less) trusted on other domains.
Of course, it does not mean that what I'm building is limited to federation, but it simplifies a lot of things after a while.
> There is a "message authentication hash" being sent in messages and I can't see anything about that in the spec, so that might be it?
By the name it is either that or you are talking about the MAC of each packet, but it could be that, yes.
> * I don't think it makes much sense to prove that you own the IP after the handshake has been done. It's mostly a countermeasure to DoS attacks for the very first handshake message
> * The client should actually be able to roam and change IP without having to re-negotiate a secure connection with the server, as long as it uses the same 64-bit connectionID.
Yes, I think only QUIC has such a mechanism. It was probably introduced exactly to handle roaming stations, and avoid having to require another check before the server can send data to the new IP. If no such check is in place, then you could start a file transfer and then spoof the source IP to that of someone you wanted to DoS.
No, the encryption/transport is a nice part, but I'm also working on other stuff like federated authentication. Besides, why would a developer want to use different stacks when he can use one that includes all the others? I believe protocols should be as general as possible, so I really see no reason not to include this.
> Are you comparing it to TLS 1.3? If you're doing a PSK-based handshake with no key exchange, they should provide the same security properties.
I was comparing it to a standard TLS key exchange with PFS enabled.
> Can you tell me what you're talking about? I don't know the spec by heart.
As I said I remember old information so I have not checked the latest draft, but I am sure that after the connection is set up the server and client continue to flip a single bit somewhere, and hash the result. This hash is sent by the client to the server so that the server can check that the client owns the IP and is actually receiving the data.
Don't know if they still have it, but it was there a couple of years ago.