6 ms·

Well, it is resistant to to the vast majority of downgrade attacks that plague just about every other widely used crypto protocol. While it's true that if a pro

Well, it is resistant to to the vast majority of downgrade attacks that plague just about every other widely used crypto protocol. While it's true that if a problem comes up, you'll have to throw the entire protocol suite, that's basically no worse than any of the others. The only case where agility can be helpful is when there are different vulnerabilities known in the MAC, cipher, etc - but there is some combination you can mix-and-match that is still believably secure. I tend to side with Donenfeld here, that this improbable possibility is not worth supporting. Note that WireGuard does have an "entire protocol" version; it's possible to support more than one at a timel; However, it does away with the 50 mix-and-match version that an agile protocol has, and the downgrade attacks that mean the whole thing is only as strong as the weakest combination.

tialaramex 8y ago
> Note that WireGuard does have an "entire protocol" version; Where? Neither a search nor a brief manual inspection of the protocol design mentions such a feature. > it's possible to support more than one at a time Just a moment ago you were cheering on WireGuard's simplicity and lack of vulnerability to downgrade attacks, and now we're talking about how an implementation might actually offer more than one, whereupon you're back to worrying about downgrade attacks. TLS has a number of specific anti-downgrade countermeasures, it will not surprise anyone to discover that WireGuard's paper as well as not describing this "entire protocol" version feature you've mentioned also has nothing about downgrade prevention...
- tptacek 8y ago
  TLS was designed to avoid downgrade attacks and failed. It's a uniquely bad example of the argument you're trying to make.
  - tialaramex 8y ago
    As discussed previously, TLS is old and successful, which gives you a lot more to talk about than protocols too young to say their own names and barely heard of outside the nerdiest circles. The most recent example where attackers get to do a TLS downgrade is Logjam, where they tie things up for long enough to solve the Discrete Log problem and then use their solution to cover up an earlier lie so that the downgrade protection doesn't trigger. This sort of trick also wouldn't work against TLS 1.3's downgrade protection, because rather than use a removable sentinel they baked the sentinel into the shared entropy. This sets up a catch 22. If you remove the sentinel to hide your tracks, the connection fails due to a mismatch, but if you leave the sentinel there then a client knows what's up.
    - tptacek 8y ago
      I might just be sleep deprived from hauling myself to Vegas, but this is word salad to me. SSL 3.0 and TLS were designed by some of the best cryptographers in the world specifically to avoid downgrade attacks, and the approach failed. Obviously, TLS 1.3 doesn't have glaring downgrade attacks; its a new protocol. TLS is, as I said, a terrible example of how complicated handshaking can defend against downgrade attacks (for the best possible example of this, see DROWN, which actually manages to leverage SSL 2 attacks against TLS!). On the other hand, WireGuard can't have downgrade attacks: the precise configuration of crypto constructions used in the protocol is baked into the constructions themselves as domain separation parameters.
      - tialaramex 8y ago
        Sure, lets blame the travel. You're very kind to Paul Kocher in naming him one of the "best in the world". Maybe he'd just gone to Vegas too when he decided you could get away with abusing RSA decryption to implicitly authenticate the recipient? In grouping cross protocol attacks like DROWN in as downgrades you undo your own arguement. WireGuard with this unusual definition can become vulnerable to downgrade, bad guys might get your WireGuard v2 private keys by abusing the legacy WireGuard v1 protocol, the deliberate lack of compatibility between the two not withstanding. Of course the specifics of DROWN can't work against WireGuard, nor against TLS 1.3, but you're insisting this isn't about specifics, it's a general "lesson"
        tptacek 8y ago
        I'm pretty comfortable with my assessment of Kocher. It's easy to look up what he's been up to. Help me understand how exactly someone would get WireGuard's v1 Noise primitives, which bake the v1 construction identifiers and a v1 constant into the derivation of all secrets as the literal first step of the protocol, to generate something that would be comprehensible to a hypothetical v2 of the protocol.
        tialaramex 8y ago
        My crystal ball is cloudy. No, no, you're right, back in 1996 the "best in the world" were incompetent buffoons, whereas today we know exactly how to do this right and we definitely haven't overlooked anything /s
- Tharre 8y ago
  > Where? Neither a search nor a brief manual inspection of the protocol design mentions such a feature. Pages 9 and 10 in the whitepaper, see IDENTIFIER and CONSTRUCTION. That being said, supporting broken crypto is a bad idea. Should any of the crypto primitives be broken, the way to move forward would be to replace them, not have WireGuard support 2 protocol versions simultaneously.
- beagle3 8y ago
  You are correct, it isn't explicitly mentioned; I've reread the technical paper just now, and recalled the (internal, with colleagues) discussion I had in the past, from which I had this conclusion - "whole protocol version" is an emergent property of wireguard, not a a designed one - it is possible that a newer version of wireguard will respond to both a newer and an older protocol properly (provided it wants to, and it can tell them apart -- which should be trivial, e.g. by changing a mac parameter, in the unlikely case that the newer version would keep the mac) - or alternatively, just use different UDP ports, one for each version. I apologize for mistakenly remembering that this was a public discussion. > Just a moment ago you were cheering on WireGuard's simplicity and lack of vulnerability to downgrade attacks, and now we're talking about how an implementation might actually offer more than one, whereupon you're back to worrying about downgrade attacks. Yes, but I don't think there's a conflict here - technically, you could have two versions running on two machines, and pick the "right one" through sticky UDP load-balancer session after you've seen which one replies (so long as the two versions are sufficiently different that an initiation packet for one does not qualify for the other). What I'm saying is that it can also be implemented within the same kernel, and I believe that one way or another, it will. In that sense, it's about as bad as TLS. I believe Wireguard's opinionated design is better because it inherently pushes this up the stack; The way it is implemented now, if (and when) it needs to be replaced, it will be of comparable difficulty to switch WG1 to WG2 or WG1 to (something-else-that's-comparable)1; Unlike TLS in which the upgrade is usually "well, get the new version of this lib and you'll be ok" -- which is essentially guaranteed to be the path chosen, and since backward compatibility is often prized, is much more likely to be exploitable. Technically speaking, the only thing one can say for sure "zero agility is simpler to implement", and "protocol agility requires a lot of care to avoid downgrade attacks, but provides backward compatibility". Everything else is basically dependent on the hard-to-estimate probabilities one assigns to "diligence of upgrades", "importance of security", "seriousness of vulnerabilities", "difficulty of configuration" which vary a lot based on your axioms. Based on my experience, I prefer the approach WG is taking. YMMV.
  - tptacek 8y ago
    The whole Noise construction is "versioned" by the primitives it's instantiated with, through domain separation constants. That's what the weird English strings in the protocol do. Whole-protocol versioning is part of Noise, and thus of WireGuard.

tialaramex 8y ago

> Note that WireGuard does have an "entire protocol" version; Where? Neither a search nor a brief manual inspection of the protocol design mentions such a feature. > it's possible to support more than one at a time Just a moment ago you were cheering on WireGuard's simplicity and lack of vulnerability to downgrade attacks, and now we're talking about how an implementation might actually offer more than one, whereupon you're back to worrying about downgrade attacks. TLS has a number of specific anti-downgrade countermeasures, it will not surprise anyone to discover that WireGuard's paper as well as not describing this "entire protocol" version feature you've mentioned also has nothing about downgrade prevention...

tptacek 8y ago
TLS was designed to avoid downgrade attacks and failed. It's a uniquely bad example of the argument you're trying to make.
- tialaramex 8y ago
  As discussed previously, TLS is old and successful, which gives you a lot more to talk about than protocols too young to say their own names and barely heard of outside the nerdiest circles. The most recent example where attackers get to do a TLS downgrade is Logjam, where they tie things up for long enough to solve the Discrete Log problem and then use their solution to cover up an earlier lie so that the downgrade protection doesn't trigger. This sort of trick also wouldn't work against TLS 1.3's downgrade protection, because rather than use a removable sentinel they baked the sentinel into the shared entropy. This sets up a catch 22. If you remove the sentinel to hide your tracks, the connection fails due to a mismatch, but if you leave the sentinel there then a client knows what's up.
  - tptacek 8y ago
    I might just be sleep deprived from hauling myself to Vegas, but this is word salad to me. SSL 3.0 and TLS were designed by some of the best cryptographers in the world specifically to avoid downgrade attacks, and the approach failed. Obviously, TLS 1.3 doesn't have glaring downgrade attacks; its a new protocol. TLS is, as I said, a terrible example of how complicated handshaking can defend against downgrade attacks (for the best possible example of this, see DROWN, which actually manages to leverage SSL 2 attacks against TLS!). On the other hand, WireGuard can't have downgrade attacks: the precise configuration of crypto constructions used in the protocol is baked into the constructions themselves as domain separation parameters.
    - tialaramex 8y ago
      Sure, lets blame the travel. You're very kind to Paul Kocher in naming him one of the "best in the world". Maybe he'd just gone to Vegas too when he decided you could get away with abusing RSA decryption to implicitly authenticate the recipient? In grouping cross protocol attacks like DROWN in as downgrades you undo your own arguement. WireGuard with this unusual definition can become vulnerable to downgrade, bad guys might get your WireGuard v2 private keys by abusing the legacy WireGuard v1 protocol, the deliberate lack of compatibility between the two not withstanding. Of course the specifics of DROWN can't work against WireGuard, nor against TLS 1.3, but you're insisting this isn't about specifics, it's a general "lesson"
      - tptacek 8y ago
        I'm pretty comfortable with my assessment of Kocher. It's easy to look up what he's been up to. Help me understand how exactly someone would get WireGuard's v1 Noise primitives, which bake the v1 construction identifiers and a v1 constant into the derivation of all secrets as the literal first step of the protocol, to generate something that would be comprehensible to a hypothetical v2 of the protocol.
        tialaramex 8y ago
        My crystal ball is cloudy. No, no, you're right, back in 1996 the "best in the world" were incompetent buffoons, whereas today we know exactly how to do this right and we definitely haven't overlooked anything /s
Tharre 8y ago
> Where? Neither a search nor a brief manual inspection of the protocol design mentions such a feature. Pages 9 and 10 in the whitepaper, see IDENTIFIER and CONSTRUCTION. That being said, supporting broken crypto is a bad idea. Should any of the crypto primitives be broken, the way to move forward would be to replace them, not have WireGuard support 2 protocol versions simultaneously.
beagle3 8y ago
You are correct, it isn't explicitly mentioned; I've reread the technical paper just now, and recalled the (internal, with colleagues) discussion I had in the past, from which I had this conclusion - "whole protocol version" is an emergent property of wireguard, not a a designed one - it is possible that a newer version of wireguard will respond to both a newer and an older protocol properly (provided it wants to, and it can tell them apart -- which should be trivial, e.g. by changing a mac parameter, in the unlikely case that the newer version would keep the mac) - or alternatively, just use different UDP ports, one for each version. I apologize for mistakenly remembering that this was a public discussion. > Just a moment ago you were cheering on WireGuard's simplicity and lack of vulnerability to downgrade attacks, and now we're talking about how an implementation might actually offer more than one, whereupon you're back to worrying about downgrade attacks. Yes, but I don't think there's a conflict here - technically, you could have two versions running on two machines, and pick the "right one" through sticky UDP load-balancer session after you've seen which one replies (so long as the two versions are sufficiently different that an initiation packet for one does not qualify for the other). What I'm saying is that it can also be implemented within the same kernel, and I believe that one way or another, it will. In that sense, it's about as bad as TLS. I believe Wireguard's opinionated design is better because it inherently pushes this up the stack; The way it is implemented now, if (and when) it needs to be replaced, it will be of comparable difficulty to switch WG1 to WG2 or WG1 to (something-else-that's-comparable)1; Unlike TLS in which the upgrade is usually "well, get the new version of this lib and you'll be ok" -- which is essentially guaranteed to be the path chosen, and since backward compatibility is often prized, is much more likely to be exploitable. Technically speaking, the only thing one can say for sure "zero agility is simpler to implement", and "protocol agility requires a lot of care to avoid downgrade attacks, but provides backward compatibility". Everything else is basically dependent on the hard-to-estimate probabilities one assigns to "diligence of upgrades", "importance of security", "seriousness of vulnerabilities", "difficulty of configuration" which vary a lot based on your axioms. Based on my experience, I prefer the approach WG is taking. YMMV.
- tptacek 8y ago
  The whole Noise construction is "versioned" by the primitives it's instantiated with, through domain separation constants. That's what the weird English strings in the protocol do. Whole-protocol versioning is part of Noise, and thus of WireGuard.