Have Client<->Server agree cipher rather than hardcoded

[benaadams]

As per https (TLS) have the client and server agree what cipher suite to use rather than hardcode it as ChaCha20/Poly1305

This will allow platform encryption libraries to be used (e.g. native Win/macOS, and chosen Linux); which will be updated with the natural flow of OS security patches - rather than having a game lib dependency which relies on the developer to release patched versions. (though could still use libsodium if preferred)

Also allows for new ciphers and old ciphers to be depreciated; or prioritized by OS security updates rather than requiring game updates.

[Drawaes]

It's pretty important to be able to remove ciphers when they have been found to be rubbish. Also AES is a lot faster than chacha if you are talking Intel. ChaCha is only really preferable for non Intel chips

[gafferongames]

I'm OK to consider this for a 1.1 version of netcode.io. We should also provide private/public key support, so we don't need shared public keys between matcher and server instances, opening the way for user hosted servers. Anything else you can think of?

[gafferongames]

How about instead of saying client/server agree, we simply say that mulitple cipher options are available, and the web backend decides which one is used. This way, a client when connected to the web backend over HTTPS would negotiate which cipher they want to use, or fall back to a default (perhaps AES). This keeps the protocol between client and server simple, but provides the same benefits you describe.

[gafferongames]

Also, are we talking about the cipher set to use for the connect token, challenge token, packets between client and server, or all of the above?

[Drawaes]

I think the connection token should/will have minimal perf impact. It's the "stream" encryption I would focus on.

[Drawaes]

As for "agree" if you take the SSL/TLS model, it is normally the client spits up a set they can support in order of preference, then it is up to the server to decide what it does, does it honour the clients preference or say, nah I want this one specifically.

[benaadams]

This way, a client when connected to the web backend over HTTPS would negotiate which cipher they want to use, or fall back to a default (perhaps AES).

Yep this is what I was thinking; likely it will be the same as what is used for HTTPS, but in most servers what encryption https is using is generally opaque as you don't really care, just that is "being handled"; so some way of communicating it on UDP "connection" start up.

Also the web server may hand off to a different server for the UDP; or have https offload at load balancer, so some negotiation may be needed. Something like https does:

The handshake begins when a client connects to a TLS-enabled server requesting a secure connection and the client presents a list of supported cipher suites (ciphers and hash functions) - in preferred order.

From this list, the server picks a cipher and hash function that it also supports and notifies the client of the decision.

However, as the startup/auth is done encrypted (e.g. under https); have a lot of leeway on key exchange etc, and only need one off session keys?

Though @Drawaes knows more about encryption protocols and their implementations than me 😄

[gafferongames]

As for "agree" if you take the SSL/TLS model, it is normally the client spits up a set they can support > in order of preference, then it is up to the server to decide what it does, does it honour the clients
preference or say, nah I want this one specifically.

I know, but we don't have to blindly follow how other protocols work.

I don't think there is any value to doing it that way in this case, and in fact it would make netcode.io worse.

A netcode.io client cannot connect to a server without authenticating with the web backend and getting a connect token, so we can simply negotiate that crypto at that point instead.

[gafferongames]

Closing this because it's pretty clear what to do for netcode 1.1 spec at this point.

[Drawaes]

I wasn't meaning you have to do it at end server time, I was simply saying the concept of the client gives a "list" and then later a "server" (front end auth server or the runtime server) makes the final call. That stops clients from forcing bad decisions.

[gafferongames]

Yes, the client provides a list to the web backend upon requesting a connect token. Will add this to 1.1

[z-s-e]

I am kind of new to UDP-based protocols, so this might be an uninformed question, but I was also wondering why encryption and authentication is baked into the protocol, instead of simply wrapping it in DTLS.

I'd think an independent authentication/crypto layer such as DTLS is desirable for being able to update it without having to updating/breaking the base protocol as well as not having to maintain the lower level crypto code yourself (but delegate that to the TLS library).

If DTLS is somehow unfit for these kinds of protocols, maybe you could give some insight to this in one of your upcoming blog posts? And btw, thank you very much for your blog, it is very inspiring and well written.

[gafferongames]

It's to keep it simple.

[z-s-e]

If by "simple" you mean kind of "self-contained" or "understandable down to the upd packet", that is a fair goal to have.

But your protocol itself would certainly be more simple if it didn't have any authentication/crypto stuff in it and just rely on the upper layer to provide that - especially if you plan to add cipher suite negotiation as well which is known to be a possible attack vector (as has been in TLS). Personally I'd rather rely on a standard than something self written there. Though I may just take this all to seriously anyway, it is not a protocol for banking transactions after all ;)

[gafferongames]

Yes we wish for netcode.io to be simple to understand, self-contained and secure.

I disagree that using DTLS would make this library simpler. It would make it more complex. Since we have no cipher suite negotiation by design, that attack vector does not exist. Less is more.

We use very secure cryptography primitives from libsodium. No need to rely on DTLS standard for security. If you think chacha poly AEAD IETF primitive in about to be broken soon, I guess we have other problems.

If you wish to use a standard, please go ahead, but that's not what this library is about, and it never will be. We can do better than just throwing our hands up in the air and trusting a standard.

cheers

[z-s-e]

Using state of the art standard cryptographic primitives is not enough though, you can still have security vulnerabilities in the protocol itself - the mentioned TLS negotiation problem was also more in the protocol than the primitives afaiu.

You certainly seem competent enough to be able to get the protocol right in this regard. I was more coming from your blog posts that encourage writing one's own specialized protocol. For someone who isn't a crypto expert (like me), wouldn't you rather recommend using DTLS (assuming netcode.io does not fit the intended purpose) instead of doing this protocol part by hand?

Anyway, I hope I didn't pester you too much. Thanks again

[Drawaes]

I think if you fully control both ends you managed to make a point about security just above. That is by making no negotiation and stripping away uneeded features you actually can make a far more secure protocol. Negotiation of ciphers for instance is a huge attack area in TLS DTLS

[gafferongames]

Exactly. This is exactly what netcode.io does - Glenn

…

On Aug 13, 2018, at 2:25 PM, Tim Seaward ***@***.***> wrote: I think if you fully control both ends you managed to make a point about security just above. That is by making no negotiation and stripping away uneeded features you actually can make a far more secure protocol. Negotiation of ciphers for instance is a huge attack area in TLS DTLS — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub, or mute the thread.

[Drawaes]

Yeah.. I don't know if it came across as so but I was backing your approach ;) it also cuts down on protocol overhead if you remove negotiations.

[gafferongames]

I totally saw that. You very succinctly explained why in netcode.io's case, we can do something simpler than DTLS, while still remaining secure. - Glenn

…

On Aug 13, 2018, at 3:28 PM, Tim Seaward ***@***.***> wrote: Yeah.. I don't know if it came across as so but I was backing your approach ;) it also cuts down on protocol overhead if you remove negotiations. — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub, or mute the thread.