On Monday, February 8, 2016 at 10:54:36 PM UTC+1, Ryan Sleevi wrote: > On Mon, Feb 8, 2016 at 1:13 PM, Frederic Martin wrote: > > > > 1) From a security architect perspective. This is an official > > recommendation that makes sens to prevent MITM attacks. FIDO U2F was > > created to minimize/eliminate that kind of risk. > > U2F itself addresses phishing. Token Binding (attempts) to address > MITM, but it's worth noting that they are separate problems with > separate solutions. U2F / FIDO are still able to handedly address the > former problem, without requiring treatment of the latter - it merely > establishes how they can be used cooperatively, but that's not > intrinsically necessary, nor necessarily wise.
Regarding "Addressing phishing", we all know this is a claim that can be supported very badly :) I heard so many times SMS codes and/or (T)OTP were supposed to cover that. Of course not. We both know that. Oh My. http://www.neowave.fr/pleaseno/SMS_OTP_TOTP_QRCODE_SSL_ARE_NOT_SOLUTIONS.pdf I really do support the simplified PKI design behind FIDO U2F (I am used to more standard and more complex to deploy PKI based token...) and I believe FIDO U2F is a great way to fight phishing attacks... but FIDO U2F security was designed to rely partially on SSL security since the server is identified through its hashed domain name... and users are supposed to be confident with this domain name through SSL server certificates. That's why... while I agree that fighting phishing and MITM may be different problems with different solutions, even the official FIDO U2F specifications makes it clear that TLS Channel ID is a recommended Security Measure linked to U2F architecture. Search "[SM-12]" inside https://fidoalliance.org/specs/fido-u2f-v1.0-nfc-bt-amendment-20150514/fido-security-ref.html I don't say there is a magical solution when mixing decentralized PKI and "pyramidal" PKI and there is no true server to device mutual authentication, SSL/TLS is used at this level (FIDO U2F Client/browser is still in charge of server authentication), SSL/TLS security is really linked to U2F regarding to MITM attacks conter measure. > > 2) Firefox users could be discriminated out of servers implementing this > > protection. > > Hopefully, you can likely recognize why this represents a very > troubling problem of Token Binding - it enables service providers > greater control to discriminate against users, reducing user freedom > and the role of the browser as the user's agent. Oh, there are already tons of way to discriminate browsers :) Here it is just trying to push security recommendations to the max. FIDO U2F technically even allow servers to discriminate token manufacturers. It goes both way and I am not even sure it is a real problem... For now, the real problem is that FIDO U2F is the most secure way for users to authenticate directly to Google, Dropbox or GitHub services... and Firefox users (like myself) are already discriminated out of this security level/option. GitHub server authentication do not use TLS Channel ID (that's why we can already use firefox with the FIDO U2F Firefox addon from Pawel Chmielowski). For now, you can make your firefox trying to impersonate Chrome, it won't pass Google servers TLS Channel ID. > While I think there's no disagreement that 'hostile' MITM is bad, > there are plenty of cases where users intentionally and actively MITM > themselves, for purposes that range from 'clearly legitimate' to > 'questionable, but it's the user's call". In the case of "clearly > legitimate", consider the work of security researchers and developers > who wish to MITM themselves or their applications, in order to > determine what data is leaking out. Any solution that actively > prohibits this can end up undermining user's security. > > If you think this is academic, consider that many service providers > consider it a form of DRM to employ - that is, preventing MITM - and > as such, represent's a loss of user privilege. What if your favourite > sites all required you to do this, or other forms of protection (such > as hardware-attested token binding keys that reveal unique > identifiers). While the idea is that token binding keys can be > rotated, we've certainly seen sites, particularly video providers, use > every available fingerprinting mechanism they can in order to restrict > how and on which devices a user accesses a given service - I doubt we > would want to see or encourage more of that. > > I think it's important to consider the harmful effects that Token > Binding will have, and not just the positive. And that's why it's > worthwhile to keep it under consideration, rather than commit. It is > truly unfortunate that Chrome decided to launch this feature, without > public discussion or review, and without concern for the implications > of the ecosystem such as the one you raise - providers like Google > using it to block out other browsers. I am hardly following you on this... I probably missed something. Perhaps I underestimated a side effect of TLS Channel ID. How can it used to have enhanced user/browser fingerprint or shady DRM related features ? AFAIK, Google is simply using this added protection on their servers. For now, I kind of approve this added protection mechanism, but -like I said- perhaps I am forgetting something bad here. On the client side, I can still fully follow how TLS Channel ID is used inside my browser... I don't know if Google servers will allow FIDO Clients/browsers to use their authentication servers if not compatible with this added protection, that's all. IMHO, it is an added value but if you just want to know if Firefox users would be discriminated without implementing TLS Channel ID, you'd rather ask Google team now to avoid bad surprise... then you'll be be able to decide with this information in mind. At the end, you can still chose to be incompatible with their services. Or Google can chose to forget TLS Channel ID... Whatever :) I wanted to know if you already knew about Google position (Of course I will try to ask them too now...) and what was your/Mozilla dev team own position on TLS Channel ID (I am still confused on that point anyway...) Please keep in mind that I am -and many other secure web application architect/dev- very positively excited that Firefox will support FIDO U2F. This will bring enhanced security for online authentication but for many many other derived and hacked/tweaked applications. Whatever your choice will be regarding TLS Channel ID. _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
