Comment by Ao7bei3s | Hacker News Reader

Comment by Ao7bei3s | Hacker News Reader

Parent Full thread

Just naive, not arrogant (it's ok & encouraged to think through things yourself, even if there already is a solution. you can't expect to come up with actually new good things on day 1.).

You've described the obvious part - this is in any crypto intro course. But it's not even getting the details of that right (which is _a_ challenge) that's interesting, because that's not where wireguard innovates. Well it does actually propose a nice scheme, but still - OpenVPN (in TLS mode), IPSEC (with IKE, else it's DIY) and, in a way, HTTPS already have working schemes.

wireguard shines is other areas: the simple (factor 500 smaller code than IPSEC/IKE), performant and fully in-kernel (both unlike OpenVPN) implementation, ifaces instead of xfrm policies (for IPSEC. though that's not entirely far, you can have VTI's. they just don't scale well we've found.), the lessons learned wrt crypto agility (tl;dr: don't), implicit source verification, the beautiful DOS cookie implementation (feels nicer than TA key), that servers are silent/invisible unless you know their public key (cant provoke any response packets without), all connections are p2p. To name a few. Read the Wireguard paper. It's short and very approachable.

> ... that servers are silent/invisible unless you know their public key (cant provoke any response packets without) ...

Yes, this is beautiful.

> lessons learned wrt crypto agility (tl;dr: don't)"

This definitely doesn't qualify as a lesson learned. It's maybe, maybe, best current practice, if you squint.

We've even seen in other threads the WireGuard author arguing that oh, well, if there's a problem with say key exchange (it has a "conventional" elliptic curve key exchange and so an adversary with a big Quantum Computer definitely breaks that) then you can still rescue with PSKs. And as well as not addressing problems in any other primitive that doesn't stand up to a laugh test. If PSKs were fine you would already use PSKs and not have all this complicated public key dance at all.

In reality if there's any problem you have to throw WireGuard itself away. So the hope is maybe all these primitives are fine. And that hope will seem 100% on the money right up until it isn't. We will see then, I think, valuable character information about its designers and key proponents, in light of how they react to that particular lesson, for example in helping people migrate off their now fatally damaged baby.

The lesson learned wasn't "don't" it was that "more is always better" is wrong, we didn't need fifteen mediocre symmetric block ciphers without much cryptanalytic research behind them in TLS. But zero agility _definitely_ hasn't proven itself to be the right choice here either, it's just less work to implement.

If reconfiguring a service to use a different crypto algo was easy then I’d agree with you. But it is often really hard and makes config difficult.

To be honest, when something like WireGuard becomes victim to a flaw in one of the primitives then I’d rather they release a WireGuard 2 to address it - keep as much config the same as possible but throw away any notion of backwards compatibility with vulnerable versions.

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.

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

TLS was designed to avoid downgrade attacks and failed. It's a uniquely bad example of the argument you're trying to make.

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.

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.

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"

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.

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

This isn't an answer to the question I asked, it's just huffing.

You didn't ask a question. You did ask me to "help you" see into the future and I informed you that my crystal ball is cloudy.

That's a weird way to say "ok, I was wrong about it being possible to recapitulate DROWN using WireGuard v1 and any hypothetical WireGuard v2".

An ability to recognise that "I don't know a successful attack" isn't the same as "it's impossible to attack" is why I don't share your (as yet unjustified) confidence in zero agility. It's a microcosm of this thread.

I'm sorry, but you're being slippery, and I'm not going to pretend that's a valid argument. It is not my claim that nobody will find vulnerabilities in WireGuard. I hope they do! Generalizing and weaponizing crypto exploits is something I work on professionally and I'm a cheerleader for team breaker.

My claim is that a cross-protocol attack like DROWN will not work on WireGuard, and I explained why.

Rather than acknowledge that explanation, you either (a) rattle off irrelevant details or (b) retreat to abstractions. But there's no abstraction to retreat to. DROWN isn't an unknowable attack. You can just read the paper to see how it works. After you do that, I suggest you read the WireGuard white paper, which is short and straightforward (the cryptographic details make up only about a third of it). You've said several things on this thread that lead me to believe you haven't yet read it, and I think you'll find it enlightening.

On that last sentence - TLS 1.3 can be vulnerable here under the same circumstances as TLS 1.2, I have no idea what I was thinking here, I was reminded by Appendix E.8 of the RFC this morning so I guess appendices are good for something.

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

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.

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.

> 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

No, it's not merely emergent. The handshake identifier string explicitly has a "v1" in it, and message types have explicit type identifiers.

No. Were Chapoly to be broken next year, we wouldn't "throw away" WireGuard. We'd simply instantiate it over a new set of primitives. That is part of the point of deriving it from Noise.

The idea behind zero-negotiation cryptography is that if there's a problem with the primitives behind the protocol, you version the whole protocol, rather than hoping that some complicated negotiation scheme can future-proof it. No part of TLS's security problems have stemmed from "fifteen mediocre symmetric block ciphers"; rather, almost all of them have come from the TLS protocol's complicated handshaking.

It's not about the inconvenience for WireGuard's author in writing a modified protocol document, "simply" instantiating the protocol with new primitives (or parameters, or any changes at all) means throwing WireGuard away as far as all the end users are concerned. For the sort of hobbyist "Hey, I hacked this together in five minutes, awesome" types running Wireguard today in a trivial pair-wise configuration this is no trouble. For a system with fifty thousand ordinary users this is a complete nightmare, and I expect what they'll do is consider that a lesson learned, no more WireGuard.

But perhaps at least some of them will try to muddle along as others have described below, let's try both versions and see what works. Then we don't need a flag day... Whereupon of course they've got a downgrade problem.

Because TLS has been such an overwhelming success there have been a lot of problems.

Let's start with BEAST. BEAST attacks the way TLS 1.0 does IVs. Is that anything to do with "complicated handshaking" ? Nope, not related at all.

Soon after that there's Lucky 13. This attacks CBC modes with a timing-based padding oracle. Handshaking? Nope.

How about RC4 being broken - Handshake problem? Nope, the RC4 stream cipher is just not as good as intended.

CRIME was a compression oracle, still not handshaking.

Coppersmith's and ROCA, as well as the Debian hilarity show that even minting private keys might be too hard, at least in RSA, for people to do it correctly. Once again, not related to handshaking.

Now Logjam really does come down to the complicated handshake, although it does also need a client which is a total sucker.

Some? Yes. "Almost all" isn't correct. Lots of problems with cryptographic primitives and implementation bugs, maybe WireGuard will be popular enough to have so many implementations and to have such a large number of researchers trying to break it...

Let's start with BEAST.

That's an interesting one to pick. It could not be fixed by negotiation and configuration at all, in the end. The entire protocol version had to be thrown away.

Beast works on TLS 1.0

The die-die-die draft would never have been written if we were looking at a situation where TLS 1.0 was gone in practice on the web, let alone SMTP and other slower-moving environments. Even PCI's day-late, dollar-short June 2018 deadline would have been irrelevant if you're right. You aren't right.

No, BEAST's story is much more interesting than that, there were three mitigations and one remains widely in use.

One "configuration" mitigation was to move to RC4 since that's not a block cipher so the CBC mode attack doesn't work by definition. This is no longer considered acceptable because RC4 is way weaker than we'd thought at the time.

The next mitigation is "empty fragments". An attacker only gets to peak at certain data using BEAST (and then they expand the attack and get everything) but we can arrange for the vulnerable block to have zero length, and then the attacker didn't achieve anything for all their effort. We waste a few bytes on the wire, but this works fine by the specification. Alas, some real world implementations had been written to reject these "empty fragments", which had never been needed previously and so you couldn't actually use this in products like web browsers.

Instead client implementations began doing 1/n-1 split, which moves a single byte instead of nothing. The attacker has 1-in 2^16 chance to guess this using BEAST, but it's a single byte, so they had 1-in- 2^8 chance to guess it without BEAST, and thus BEAST is worthless if you can do this.

Of course it's still _wasteful_ but it's both protocol compliant and an effective mitigation. How about that?

'pvg is right. You're rattling off lots of random technical details about the attack, but his single sentence captures a core problem with "agility": despite having all the complicated handshaking, a whole protocol version had to be burned to fix the problem.

Your confused argument suggests that because BEAST involved chained IVs and not the TLS handshake, it's an example of how the handshake didn't sabotage TLS. You're right: it's not. It's an example how the handshaking, which sabotaged TLS through other attacks, didn't buy anything material for TLS.

The confusion seems to lie with you here if it's with anyone. The stop gap RC4 preference is explicitly enabled by handshaking.

Beyond that though you seem to have your history out of order, BEAST is a TLS 1.0 attack, but TLS 1.2 was finished years before BEAST was published.

It's not a case of a protocol version "had to be burned to fix the problem" but two subsequent protocol versions had already shipped years ago which fixed the underlying cause and, as is the reality for which you seem so ill-prepared, scarcely anybody had upgraded.

All these years later financial services companies are getting waivers from PCI saying their cheap third rate POS terminal "has a mitigating control" and so it's fine that they still do TLS 1.0. So that's nice. Nice for them I mean. Hey, if you're "lucky" one day they'll be relying on a ten year out-of-date WireGuard, as enthusiastically endorsed by Thomas Ptacek. And every time you're asked about it you can spit feathers. How dare they. Like I said, if you're lucky.

As messy and uphill as it has been, the journey from SSLv2 to TLS 1.3 was only possible with the handshake.

Thai Duong did BEAST during the brief window he worked with me at Matasano, so I'm pretty sure I have the chronology right.

but two subsequent protocol versions had already shipped

That doesn't really address the 'agility didn't help here' point at all. The argument against agility as a design approach is straightforward and widely articulated - it's obviously informed by the SSL/TLS experience but doesn't outright depend on it. It's not too difficult to imagine that there could be some sort of coherent counter-argument. If you have one, though, it's impossible to parse it out from this enthusiastic mixture of non-responsive detail and superciliousness.

But it did help there, as I already pointed out and you ignored twice.

It did not help here. In fact, it amplified the problem. We knew RC4 to be broken when BEAST was announced. Nevertheless, people enabled it, as a "stopgap", to deal with BEAST. RC4 is arguably less secure than BEAST-affected TLS (BEAST was in practice quite difficult to trigger), and, either way, all those RC4 deployments ended up also needing to be scoured off the Internet!

Reply on news.ycombinator.com