That's a Dan Harkins protocol; Harkins is a little notorious for Dragonfly, a PAKE he tried to get "approved" by IETF CFRG before being slagged by Trevor Perrin†, who wrote up a particularly simple and nasty side channel attack on the elliptic curve point generation technique Dragonfly used. SAE includes what looks like the same "hunt-and-peck" point generator.
All I ever read about the Dragonfly PAKE was trevp taking it apart on CFRG, but from a quick skim of this paper and the IETF draft Harkins wrote for Dragonfly, this looks like it's just an instantiation of Dragonfly.
That would be pretty funny.
What is it about WiFi security that makes it such a backwater?
> What is it about WiFi security that makes it such a backwater?
The fact that the specs are developed behind closed doors in pay-to-play venues? At least, IME, there's a pretty strong correlation between specs developed behind closed doors and bad specs.
This reminds me that not all of the attacks we know on WEP now was known when TKIP was developed in 2001-2002. The worst is probably the WPS debacle though.
There is plenty of more discussion on IETF mailing lists (and probably elsewhere too). Ultimately on a glance I can't say how trustworthy Dragonfly is because of the controversy. Perrin has obvious strong dislike for it, but that alone is not yet the end of the world.
"I'd like to request the removal of Kevin Igoe from CFRG co-chair."
"Twice Kevin suggested a technique for deriving the Dragonfly
password-based element which would make the protocol easy to break
[IGOE_1, IGOE_2]. He also endorsed an ineffective attempt to avoid
timing attacks by adding extra iterations to one of the loops [IGOE_3,
IGOE_4]."
Note that Kevin Igoe's mail address is "at nsa.gov" and all the quoted "accidents" happened before Snowden disclosures (which were in the Summer of 2013).
It does indeed seem to be DRAGONFLY (I'd heard rumours indicating such in advance): a surprising choice for an interactive protocol with attacker-observable timings, I felt, given its already chequered reputation?
I couldn't possibly speculate as to why, but one does feel inclined to agree that the people behind wireless LAN security haven't always generally chosen high quality methods in the past, and this feels to me like it could well be a continuation of that pattern.
I tried to read the device provisioning protocol. To read it, I would need to fill out a form to ask for permission and to agree to some contract. No thanks.
Given that “easy connect” seems to require no UI at all on the IoT device, I suspect it’s vulnerable to fairly trivial to reassociate a victim device to a rogue network, and it may be impossible to defend against at attacker who has ever seen the QR code without replacing the device outright.
The right way to do this is probably to arrange for IoT wireless clients to each get its own private VLAN and to have no ability to engage in any communication other than bandwidth-limited device-initiated traffic to the public Internet.
Mincing words isn't a good idea for this sort of thing.
This is becoming a standard that will be used to protect the data of a billion+ users over time as devices get upgraded.
I assumed they were referring to Trevor's IETF posts; the Igoe and Dragonfly comments he posted are about as intemperate as I've ever seen him, in any venue. He is not an angry dude.
Oh! I only read the first thing you linked at first so maybe misunderstood. It does heat up a bit after but only seems 'visceral' in the way showing a bit of ankle is 'racy'. Then again, I don't know anything about the civility baseline of the list or people involved.
I didn't really follow it very far, I did notice Dan Harkins quickly got assholier-than-thou. But there's no shortage of crypto or general tech talk that is worse.
After some years staring at this I've decided everything looks this way if you're used to the Web PKI. I tried very hard at first to assume that the PCI SSC, the EMV group, Wi-Fi Alliance and suchlike are doing great work but it's behind closed doors and so invisible to me. That theory has been challenged so thoroughly that I feel compelled to reject it.
Four things that stick in my mind in no particular order in relation to this realisation:
1. Peter Gutmann's out of the blue attack on ACME when it was relatively young. Gutmann's SCEP doesn't solve the problem, and at first my assumption was that he just needed to have that explained. After a while I realised that SCEP's success depends up not understanding what the real problem is, and SCEP is widely deployed outside the Web PKI largely _because_ choosing not to understand the problem suits those applications perfectly well. ACME can't displace SCEP in such applications but its existence might cause people to ask uncomfortable questions and perhaps Peter would (unconsciously?) rather that didn't happen.
2. Eric Rescorla's explanation of what a great environment HTTP (and particularly web browsers) is for a cryptographic adversary. In the literature imaginary bad guys often get to watch one party do a million message/reply back and forths, time them accurately and then send a million bytes of nonsense data to the target as setup for their attack, and in many applications this would be ludicrous in practice, the target would obviously react, how could you do cause anyone to send so many messages without attracting notice, let alone time them? So the attacks seem just theoretical. But on the web you can just write some Javascript and victims will happily run it for you on their computers.
3. Dean Coclin of Symantec and eventually the various banks/ payment providers etcetera that had hidden behind Symantec explaining that such institutions really _needed_ security, unlike mere cat blogs and search engines, but of course they couldn't be expected to react to notice of serious issues with an obsolete hash algorithm in a timely fashion, and so surely they ought to get an extra year or five to upgrade from SHA-1, and if they didn't there'd be dire consequences.
4. ETSI's work on the "Middlebox Security Protocol" aka ETSI TS 103 523. Obviously most of this happens out of view, so we have no idea if there's something productive being discussed - but they kindly (?) shared their work in progress documents with outsiders including the TLS Working Group and er... yuck. I mean... see for yourself:
† https://www.ietf.org/mail-archive/web/tls/current/msg10922.h...
Later:
All I ever read about the Dragonfly PAKE was trevp taking it apart on CFRG, but from a quick skim of this paper and the IETF draft Harkins wrote for Dragonfly, this looks like it's just an instantiation of Dragonfly.
That would be pretty funny.
What is it about WiFi security that makes it such a backwater?