Hacker News Reader

> And besides, how will you update our map that says that protocol "age" 1 uses rsa, "age" 2 uses ed25519?

With protocol versions, which don't require a registry for the primitives. Like, there is no number that means RSA and no number that means Ed25519, there is just age v1 and age v2, and each of them uses only the one specified primitive. If you want to call version numbers registries, sure, but I think you get what I mean.

People bring up "what about AES hardware" a lot, but they also seem to like Wireguard, which also happens to be the fastest VPN option for most deployments. Well, Wireguard just silently went and did what I'm advocating, including only supporting ChaCha20Poly1305.

So instead of having "primitive1 = rsa" you have "age1 = rsa".

It's the same thing. You are just bumping the protocol version faster, and confusing people because protocol 42 will be just another crypto change, but 43 will be a complete protocol rewrite.

Meanwhile each protocol version needs to be standardized and accepted by the whole world. That stuff is not fast

Your theory doesn't seem to have stopped WireGuard from becoming a successful high-performance VPN protocol/implementation.

Interesting. I was about to comment how well known and widespread everything on the article is, and welcome the author to the last decade... so reading your disagreement is really unexpected.

Crypto algorithm negotiation is an artifact of the 90's. Currently crypto is much more stable than communication protocols, so there is no need to negotiate them, and the negotiations are vulnerable to attack so one just can not keep support for broken clients, however practical it is to update them.

And, anyway, protocol version negotiation is still pretty much a thing.

current crypto is not stable. at all.

challenges for new standards are underway, AEAD standardization is relatively new, ECC is no longer quantum proof, we still have no definite idea on lattice and so on. Even CHAHCA has multiple evolutions.

DJB, famous and influential cryptographer worked on MinimaLT, a protocol that only uses one primitive and has no negotiation. go check how widespread it is, then think on your ability to convince the world on how good your choice is.

> one just can not keep support for broken clients, however practical it is to update them

In an ideal world I would agree. Not in this one

BTW, I see no difference in version negotiation and primitive negotiation. You can't say "primitive negotiation is bad!" and "protocol negotiation is not bad!". Especially since negotiating protocol versions without crypto primitives is just screaming for downgrade attacks.

If done correctly, it's the same mechanism. if not, both can have the same flaws.

This distinction between protocol version support and primitive support reeks of lack of knowledge in the field (both crypto and protocols), insecurity of the product, and sounds just like an impractical philosophy (especially due to the article renaming many common names of common fields).

Code reuse is a (big) thing. If a software supports multiple "ages", those will be handled with a "registry".

Evolution is another. People have taken huge pains to extend features and capabilities of existing protocols. QUIC is winning probably not only due to google, but also due to its internal versioning of various features.

TLS history showed us that upgrading the cipher list and deprecating the old ones is incredibly faster than trying to update the TLS protocol version. I can really see no reason why anyone would want to go back to the days of unupgreadable protocols and their nightmares

> BTW, I see no difference in version negotiation and primitive negotiation. You can't say "primitive negotiation is bad!" and "protocol negotiation is not bad!". Especially since negotiating protocol versions without crypto primitives is just screaming for downgrade attacks.

Primitive negotiation involves primitives being decided at runtime. This means you can, for example, tell a system that normally does RSA verification to switch to HMAC-SHA256 instead (but using the RSA public key as a HMAC shared key). This is what bit many JWT implementations.

Protocol negotiation involves primitives being decided at the time that a protocol version is defined, and then you can only select the version to use. You don't get to tell the server "use this encryption algorithm in this mode", you can only say "use v2" or "use v3". There is no mix-n-match potential.

You can't use v2 age with RSA.

This isn't a subtle difference. Most cryptography vulnerabilities occur at the joinery between primitives.

That’s why cryptographic systems where “governments, standard bodies, cryptographers, companies, banks, hw manufacturers and others” need to agree on things don’t tend to be very secure.

[insert link to some of Moxie’s rants]

> And besides, how will you update our map that says that protocol "age" 1 uses rsa, "age" 2 uses ed25519? That's right, with "Registries". Unless you convince the whole world to just instantly switch to the new version at the same time, so that you can also drop the old version.

There is a not so subtle difference here.

Rule: When more than one algorithm is implemented in a protocol, negotiation is unavoidable. What you can choose is to do one of two things:

1. Run-Time Negotiation --- Within a given version of a protocol, you can have multiple simultaneous in-flight algorithms, modes, key sizes, etc. at play.

2. Compile-Time Negotiation -- Version 1 only does Algorithm ABC with config XYZ, Version 2 does Algorithm DEF with config VXW. You cannot get version 1 with another algorithm.

(I use "Compile-Time" somewhat hand-wavy here; some programming languages are interpreted instead of compiled.)

It should be plainly obvious why option 1 is more dangerous and harder to prove secure than option 2.

> how will you update our map that says that protocol "age" 1 uses rsa, "age" 2 uses ed25519?

I'd imagine most (but not all) cipher suite changes would also include meaningful protocol changes as well, so a registry that tells you about cipher suites wouldn't help. And, if this is for open consumption, the client has to deal with servers that haven't updates too, so you need version negotiation, unless the old cipher is super bad. My personal experience is more with centralized servers, where I could guarantee protocol changes were fully distributed to servers, so clients did not have to negotiate. And we had to support old protocols until the last client that used it was expired.

Just out of curiosity, don’t you think that in strictly versioned software, ie software that everyone has to be running the same version at runtime for it to work, you could enforce such versioning primitives?

I think there’s a world where forcing users to have a little choice as possible about how they use a cryptographic system keeps them safer, don’t you?

> software that everyone has to be running the same version at runtime for it to work

Have you ever attempted a flag day? Even at a small scale organization it's a nightmare - imagine trying to do it at Credit Card Processor (tens of millions of devices) or Google's (billions of devices) scale.