4 ms·

The article basically says that it's bad to support multiple choices (crypto primitives) in a protocol. > If you need to enumerate the options you support, it

The article basically says that it's bad to support multiple choices (crypto primitives) in a protocol. > If you need to enumerate the options you support, it means that not only you support multiple ones, which is already bad, but you need to communicate the choices in the protocol itself, meaning you do runtime negotiation. Do you want bugs? Because that’s how you get bugs. The author then says that we should just bump the version of the protocol each time we change the ciphers. This already assumes that every time there is always only one algorithm that governments, standard bodies, cryptographers, companies, banks, hw manufacturers and others can agree to. Good luck with that 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. > The industry now understands updating and patching software quickly is critical Not my experience with cellphones, iot, pcs or even servers of any os I might be in a bad mood, but I don't feel the article provides any practical option or that the author has thought this out much

josh2600 6y ago
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?
- awalton 6y ago
  > 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.
toast0 6y ago
> 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.
shp0ngle 6y ago
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]
FiloSottile 6y ago
> 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.
- Luker88 6y ago
  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
  - some_furry 6y ago
    Your theory doesn't seem to have stopped WireGuard from becoming a successful high-performance VPN protocol/implementation.
some_furry 6y ago
> 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.
marcosdumay 6y ago
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.
- Luker88 6y ago
  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
  - 6y ago

josh2600 6y ago

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?

awalton 6y ago
> 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.

toast0 6y ago

> 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.

shp0ngle 6y ago

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]

FiloSottile 6y ago

> 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.

Luker88 6y ago
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
- some_furry 6y ago
  Your theory doesn't seem to have stopped WireGuard from becoming a successful high-performance VPN protocol/implementation.

some_furry 6y ago

> 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.

marcosdumay 6y ago

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.

Luker88 6y ago
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
- 6y ago