4 ms·

Algorithmic agility has proved to be a huge area of vulnerability in a lot of security protocols. I think new protocols should explicitly choose the crypto alg

Algorithmic agility has proved to be a huge area of vulnerability in a lot of security protocols. I think new protocols should explicitly choose the crypto algorithms and the only way to change them would be to upgrade the protocol as a whole.

zamadatix 5y ago
I don't think the problem is that the protocol supports algorithms without versioning it's that it isn't known what the remote side is using on the first connection. Moving this to 4 protocol versions still doesn't tell you which you should use to connect to the remote system, that problem would still need to be solved.
- wrs 5y ago
  It wouldn’t have to be entirely different, it could just be a major version update. But the vast majority of sysadmins can understand and deploy a major version update. The same cannot be said of specific algorithm ordering tradeoffs or other such detailed configuration.
  - zamadatix 5y ago
    Again you're just shifting the problem one layer up not solving it. The burden on the sysadmin is it knowing which version to connect with for a particular remote resource. They don't care if that's knowing it's algorithm set 4 or protocol version 4 (which uses algorithm set 4 behind the scenes) since the actual problem is they aren't checking the remote resource to see if it matches prior to connecting. And just the same as using algorithm set 3 to connect to a MITM proxy for a device that should have used algorithm set 4 you'll also have the same problem using protocol version 3 to a MITM proxy for a device that should have used protocol version 4.
    - wrs 5y ago
      Agreed, it’s definitely best to just never change the protocol. But if you do have to change it someday (quantum cryptanalysis?) it’s better to have a single setting introduced at that point than to have 15 settings with no correct answer introduced at the very beginning.
jeroenhd 5y ago
I think algorithmic agility is exactly why TLS 1.0 has remained secure for so long (and, to a point, SSL 3 too). We're already running into compatibility problems with IoT devices and server management boards because of HTTPS and that's just with TLS <1.2 being turned off after many years. I don't believe changing the protocol even faster will benefit most applications. The world has barely implemented http/2 and yet we're already on http/3 based on yet another entirely different protocol.
- tptacek 5y ago
  You'd think that, but you'd be mostly wrong. Many (most, I think?) TLS vulnerabilities have been fixed not by ciphersuite configuration changes but by upgrades to the entire protocol. The most famous configuration workaround --- BEAST prompting people to go from AES to RC4 --- pushed people into an even more grievously insecure cryptosystem. For the most part, I think negotiable ciphers have been discredited among cryptography engineers. Certainly, it's a design smell in new protocols.

zamadatix 5y ago

I don't think the problem is that the protocol supports algorithms without versioning it's that it isn't known what the remote side is using on the first connection. Moving this to 4 protocol versions still doesn't tell you which you should use to connect to the remote system, that problem would still need to be solved.

wrs 5y ago
It wouldn’t have to be entirely different, it could just be a major version update. But the vast majority of sysadmins can understand and deploy a major version update. The same cannot be said of specific algorithm ordering tradeoffs or other such detailed configuration.
- zamadatix 5y ago
  Again you're just shifting the problem one layer up not solving it. The burden on the sysadmin is it knowing which version to connect with for a particular remote resource. They don't care if that's knowing it's algorithm set 4 or protocol version 4 (which uses algorithm set 4 behind the scenes) since the actual problem is they aren't checking the remote resource to see if it matches prior to connecting. And just the same as using algorithm set 3 to connect to a MITM proxy for a device that should have used algorithm set 4 you'll also have the same problem using protocol version 3 to a MITM proxy for a device that should have used protocol version 4.
  - wrs 5y ago
    Agreed, it’s definitely best to just never change the protocol. But if you do have to change it someday (quantum cryptanalysis?) it’s better to have a single setting introduced at that point than to have 15 settings with no correct answer introduced at the very beginning.

jeroenhd 5y ago

I think algorithmic agility is exactly why TLS 1.0 has remained secure for so long (and, to a point, SSL 3 too). We're already running into compatibility problems with IoT devices and server management boards because of HTTPS and that's just with TLS <1.2 being turned off after many years. I don't believe changing the protocol even faster will benefit most applications. The world has barely implemented http/2 and yet we're already on http/3 based on yet another entirely different protocol.

tptacek 5y ago
You'd think that, but you'd be mostly wrong. Many (most, I think?) TLS vulnerabilities have been fixed not by ciphersuite configuration changes but by upgrades to the entire protocol. The most famous configuration workaround --- BEAST prompting people to go from AES to RC4 --- pushed people into an even more grievously insecure cryptosystem. For the most part, I think negotiable ciphers have been discredited among cryptography engineers. Certainly, it's a design smell in new protocols.