On Friday, December 15, 2017 at 5:39:37 PM UTC-6, Ryan Sleevi wrote: > That is not what is required. There is no special enrollment dance - that > is simply straight up misrepresenting it. Your vision is not aligned with > the reality of it.
I've never been to a banking website where there wasn't a special enrollment dance. There's always one part in establishing the website unique user identity and then tying the "web account" to your underlying online financial accounts. That second part seems to always involve entering lots of not-easily-changed personal identifying information. The best authentication mechanisms in the world won't help you if your first contact is with a phishing site rather than the real bank. Am I really missing something here? > > While on the topic of U2F/WebAuthN, it is noteworthy that current > > iterations effectively do not offer even a modicum of MITM protection. > > > That is not correct. I agree, in part - I overreached there. There is/are MITM protection mitigation(s) -- if we count yet more TLS extension negotiations. Requiring TLS stack modifications. WebAuthN's Token Binding mechanism does this per https://tools.ietf.org/html/draft-ietf-tokbind-protocol-16 esp at section 1.2. > > Assuming that one is able to get a bad certificate for the target website, > > the calculated auth token can be intercepted. I'm aware there are optional > > features which mitigate the MITM threat. These, of course, require protocol > > support inside the TLS endpoint and so will be pervasive...like good OCSP > > stapling support is, but with a deployment cycle that hasn't even started > > yet and a market penetration time-scale that might well be even worse. > > > This is both technically inaccurate and not relevant to the discussion of > phishing. It borderlines bad faith to non-sequitor like that - as an > attempt to shift the discussion and goals to avoid having to acknowledge > the points made. Perhaps irrelevant, not bad faith and not entirely inaccurate. The spec at https://www.w3.org/TR/webauthn/#dom-collectedclientdata-tokenbindingid does note in section 5.8.1 that the tokenBindingId can be omitted if no token binding has been negotiated, effectively rendering - it would seem - token binding as optional. Which seems sure to get it implemented that way. Other than token binding, I'm not seeing real MITM protection? > > > > > (As an aside, why did they not utilize the already in-browser and > > MITM-proof auth capability of TLS client certificates -- even if the token > > had to create a self-signed surrogate client certificate per origin to > > maintain anonymity -- all without needing new TLS bolt-ons?) > > > I find it very difficult, in this context and this thread, and with the > pejoratives used, to believe this is a good faith question, but it > certainly is not productive. > > You can certainly ask on the WebAuthN discussion, in which I’m sure folks > would be more than happy to point out the misunderstanding that underscores > the question. I do apologize and promise it was not in bad faith. I actually found that someone already raised this as an issue on the spec's GitHub project. There's some good discussion on the topic there. I get why they elected not to do this (at least so far). That said, in all the discussion, there is no mentioned alternative save for token binding, which comes up several times in that discussion, with downside of TLS stack modification being a barrier. If interested, https://github.com/w3c/webauthn/issues/391 I do recognize that I've been... demanding in this discussion and probably abrasive on occasion. For the little that I'm sure it's worth, I offer up the following: I am of the opinion that the EV program as it exists today, with the now current standards of data inclusion and validation does not achieve a sufficient benefit to justify the UI it currently enjoys. Despite this, I would wish to fix it (however difficult) rather than discard the UI. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
