3 ms·

There are good reasons why agility is bad. It never works the way people imagine. The fantasy is people think "in case of a sudden algorithm break we can quick

by hannob 6y ago

There are good reasons why agility is bad. It never works the way people imagine. The fantasy is people think "in case of a sudden algorithm break we can quickly switch to a better algorithm". This is wrong because: a) there are no sudden algorithm breaks. You always know way in advance before something is broken. (In the case of SHA-1 there was more than a decade between early warnings and the first attack.) In the case of Git the warnings about SHA-1 are older than Git itself. The problem wasn't lack of agility, the problem was choosing an algorithm that was already known to be bad. b) if you have agility it means people will continue supporting bad algorithms and use agility as an excuse. b) happened exactly in TLS. Padding oracles were known, but people chose to ignore it. In TLS 1.2 they included better algorithms (GCM), but chose to keep the bad ones (CBC/HMAC). Then more padding oracle attacks happened. Then people said "oh we have agility, we can disable CBC and ... well nobody supports GCM yet... let's use this other broken thing we have called RC4". Then attacks on RC4 came in. If by the time people designed TLS 1.2 they would've said "we know RC4 is weak, we know CBC/HMAC (as used in TLS) is weak, we will just support GCM" none of that mess would've happened.

upofadown 6y ago
>The fantasy is people think "in case of a sudden algorithm break we can quickly switch to a better algorithm". That isn't really what people are afraid of. They are afraid of the time, money and wasted effort that comes from having to completely rewrite everything. These cryptographic hashes are sort of a worst case. They often end up being part of a defined interface of some sort like a cryptographic identity. So starting over from scratch can have a high social cost as well. I think that when considering the lessons from the TLS case that people are forgetting that many applications do not work at all like TLS. You have to have the wisdom to throw out wisdom that does not apply when designing these things. GIT is an excellent example of such an application.
- cyphar 6y ago
  You don't have to rewrite everything though. The rest of Git doesn't need to be rewritten if you change hash functions, nor does the rest of WireGuard if you change encryption or key exchange constructions. Newer constructions of similar crypto primitives can be used in the same way to solve the same problem. The key question is should a single version be able to handle both the old (broken) construction and the new (not broken) construction? There is fairly good evidence that allowing that leads to lots of potential for security issues due to all sorts of downgrade tricks that force users to switch to the broken version (or even worse, use the fact there are two versions to break the crypto as happened with DROWN). However, not allowing it has obvious consequences for usability (Python 3 comes to mind as a non-crypro example where having a hard cutover really didn't work).
corty 6y ago
The changeover to TLS1.2 only ever could have worked because of agility. Without at least protocol version agility (which implies cryptographic agility), one couldn't talk TLS and its successor on the same port, because there wouldn't be any other way to distinguish them. A new TCP port assignment would have been possible, but a total and utter disaster. Countless firewalls, appliances, routers, middleboxes, rulesets and similar stuff assume that HTTPS is on port 443, changing that would at least take a decade. That the allowed set of ciphers didn't change enough with TLS1.2 may be right, but doesn't matter for why we do need agility. Agility is necessary and TLS is the poster-child for why we need agility in such protocols. Whether the same applies for git, where the network protocol isn't that important and ingrained is of course debatable, I think you are right there. But what git has to do now is create agility by cramming it in somewhere, using cludges, hacks and whatever might be possible without breaking too much. It remains to be seen if the cludge will be free of security problems.
- cyphar 6y ago
  Given the plethora of downgrade attacks against TLS that have been found over the decades, I'd really hope that there is a better poster-child for cipher agility. If the canonical example of "cipher agility working as intended" is TLS, then I want off this rollercoaster ride.
  - corty 6y ago
    TLS agility is definitely not the poster-child for a good implementation. I do not know if there is any cipher agility implementation I would really call good. However, TLS is the prime example for why we desperately need agility anyways. Just look at the myriads of ways things broke just by trying to get TLS1.3 to work. And now imagine that totally without any agility mechanism. We would still plan for the big introduction of TLS1.3 a few years into the future.
- hannob 6y ago
  The "fun fact" here is that TLS version negotiation does not really work. Which is why in TLS 1.3 it still technically is using a TLS 1.2 handshake with an extension adding the new version. But appart from that: Having the ability to have a new version is a completely different concept from what people usually call "cryptographic agility". The latter is usually used to describe a system where you can pick and choose from a variety of algorithms, good and bad ones so everyone gets what they want. Which TLS unfortunately still does - TLS 1.3 could be so much simpler if they just removed any algorithm choices.

by hannob 6y ago

upofadown 6y ago

>The fantasy is people think "in case of a sudden algorithm break we can quickly switch to a better algorithm". That isn't really what people are afraid of. They are afraid of the time, money and wasted effort that comes from having to completely rewrite everything. These cryptographic hashes are sort of a worst case. They often end up being part of a defined interface of some sort like a cryptographic identity. So starting over from scratch can have a high social cost as well. I think that when considering the lessons from the TLS case that people are forgetting that many applications do not work at all like TLS. You have to have the wisdom to throw out wisdom that does not apply when designing these things. GIT is an excellent example of such an application.

cyphar 6y ago
You don't have to rewrite everything though. The rest of Git doesn't need to be rewritten if you change hash functions, nor does the rest of WireGuard if you change encryption or key exchange constructions. Newer constructions of similar crypto primitives can be used in the same way to solve the same problem. The key question is should a single version be able to handle both the old (broken) construction and the new (not broken) construction? There is fairly good evidence that allowing that leads to lots of potential for security issues due to all sorts of downgrade tricks that force users to switch to the broken version (or even worse, use the fact there are two versions to break the crypto as happened with DROWN). However, not allowing it has obvious consequences for usability (Python 3 comes to mind as a non-crypro example where having a hard cutover really didn't work).

corty 6y ago

The changeover to TLS1.2 only ever could have worked because of agility. Without at least protocol version agility (which implies cryptographic agility), one couldn't talk TLS and its successor on the same port, because there wouldn't be any other way to distinguish them. A new TCP port assignment would have been possible, but a total and utter disaster. Countless firewalls, appliances, routers, middleboxes, rulesets and similar stuff assume that HTTPS is on port 443, changing that would at least take a decade. That the allowed set of ciphers didn't change enough with TLS1.2 may be right, but doesn't matter for why we do need agility. Agility is necessary and TLS is the poster-child for why we need agility in such protocols. Whether the same applies for git, where the network protocol isn't that important and ingrained is of course debatable, I think you are right there. But what git has to do now is create agility by cramming it in somewhere, using cludges, hacks and whatever might be possible without breaking too much. It remains to be seen if the cludge will be free of security problems.

cyphar 6y ago
Given the plethora of downgrade attacks against TLS that have been found over the decades, I'd really hope that there is a better poster-child for cipher agility. If the canonical example of "cipher agility working as intended" is TLS, then I want off this rollercoaster ride.
- corty 6y ago
  TLS agility is definitely not the poster-child for a good implementation. I do not know if there is any cipher agility implementation I would really call good. However, TLS is the prime example for why we desperately need agility anyways. Just look at the myriads of ways things broke just by trying to get TLS1.3 to work. And now imagine that totally without any agility mechanism. We would still plan for the big introduction of TLS1.3 a few years into the future.
hannob 6y ago
The "fun fact" here is that TLS version negotiation does not really work. Which is why in TLS 1.3 it still technically is using a TLS 1.2 handshake with an extension adding the new version. But appart from that: Having the ability to have a new version is a completely different concept from what people usually call "cryptographic agility". The latter is usually used to describe a system where you can pick and choose from a variety of algorithms, good and bad ones so everyone gets what they want. Which TLS unfortunately still does - TLS 1.3 could be so much simpler if they just removed any algorithm choices.