On Mon, Feb 8, 2016 at 10:13 PM, Frederic Martin <fredletaman...@gmail.com> wrote:
> Hi, > > thanx for the answer. > > Quoting Dirk Balfanz (one of the TLS Channel ID specifications author, a > few days ago on FIDO DEV forum): > > "the new spec that replaces ChannelID is called "Token Binding", and is in > the process of being standardized by the IETF ( > https://datatracker.ietf.org/wg/tokbind/documents/). > > It turns out that as far as FIDO is concerned, a Token Binding key or a > ChannelID key are really the same thing: it's a public key that will be > included in the client data and signed by the Authenticator. So while > you're correct in pointing out that it's a bit weird that FIDO should > reference a non-standard, other than changing a few words here and there I > don't expect any changes to the FIDO specs once the Token Binding drafts > have become standards." > > Source : > https://groups.google.com/a/fidoalliance.org/d/msg/fido-dev/hn_T6pKS0wU/aEO29oIeEAAJ > I'm not following how this is responsive to my point, which isn't about the text in FIDO but rather about what actually goes into Firefox. From that perspective, what Dirk says is correct, namely that the FIDO interface to Token Binding and Channel ID are very similar. However, we have to implement one or the other or both in TLS, and I don't see a lot of value in doing both. I am still concerned about Mozilla Foundation deciding not to implement > this protection inside Firefox for two main reasons. > > 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. This would rather be a > more secure decision to fully implement the best options. (I am working for > a FIDO U2F device manufacturer and that's what we did on our side). I don't understand this point. The manufacturer doesn't implement token binding: it's in the browser stack. 2) Firefox users could be discriminated out of servers implementing this > protection. Even if this is mostly/only the case on Google authentication > servers now, this would already make a difference. I am not a Google fan > boy -and I am working with other online services to integrate FIDO U2F > technology- but protecting their services accounts is often what everyone > is thinking about now when discussing FIDO U2F (protecting Gmail, Gdrive, > Youtube, or whatever Google related accounts). Did you speak with Google > team guys to know if they will let Firefox be compatible with their FIDO > U2F second factor option even without ChannelID protection on the client > side? Well, I see Ryan Sleevi responded below, but no, I haven't validated this one way or the other with Google. With that said, I would be somewhat disappointed if Google required Token Binding with U2F, given that they don't require it without U2F. It's certainly not consistent with previous claims -- or the underlying design of FIDO -- to say that token binding is required for FOD to add value. > (this would mean that they'll accept to lower their security to make it > compatible to Mozilla/Firefox implementation... Not really. See above. They can decide that, even if questionable...) > Well, it's worth noting that while they are different mechanisms, U2F + pinning offers much of the MITM protection that Token Binding provides, and Firefox already pins Google services. -Ekr -- > Fred > > On Monday, February 8, 2016 at 5:28:37 PM UTC+1, Eric Rescorla wrote: > > On Fri, Feb 5, 2016 at 3:22 PM, Fred Le Tamanoir > > wrote: > > > > > Hi, > > > > > > Great news about you making progress on this ! > > > > > > Since I read here and there that you are working with Firefox & Chrome > U2F > > > support consistency in mind, what's your take on TLS Channel ID (Token > > > Binding) support inside Firefox ? > > > > > > It is a recommended feature for FIDO U2F client (Firefox here) inside > > > official specifications for additional protection against MITM > attacks... > > > and it is implemented on Google authentication servers (and on Chrome > > > client side of course). I don't know if Google team will make it > mandatory > > > for non-Chrome browsers to be compatible with their own authentication > > > servers but anyway, I think this is an important issue to be > discussed... > > > > > > > See: > > > https://groups.google.com/d/msg/mozilla.dev.platform/IVGEJnQW3Uo/o9WzWgEqCwAJ > > > > We're not likely to implement Channel ID, but we probably will implement > > Token Binding > > when it seems sufficiently stable > > > > -Ekr > > > > > > > > > > > > ...and my personal point: we need this :) > > > > > > On Thu, Feb 4, 2016 at 10:49 PM, J.C. Jones <jjo...@mozilla.com> > wrote: > > > > > > > All, > > > > > > > > We're making progress on implementing FIDO U2F in Firefox. The > effort is > > > > split into a number of bugs at present. First, a quick rundown of > where > > > we > > > > are: > > > > > > > > * The tracking bug for U2F support is Bug 1065729. > > > > * Bug 1198330 is to implement USB HID support in Firefox. > > > > * Bug 1231681 implements the WebIDL and the outline of the JS API. > This > > > > bug's code is in review. > > > > * Bug 1244959 completes the AppId/FacetId algorithm. > > > > * Bug 1245527 implements the state machines (USBToken) between the > JS API > > > > and the USB HID support. > > > > * Bug 1244960 expands an NSS-based U2F token (NSSToken) for expanded > > > > integration and developer testing. > > > > > > > > A couple of notes/clarifications about how we're planning to build > U2F > > > > support: > > > > > > > > * The `window.u2f` API endpoint will only be available to code loaded > > > from > > > > secure origins, in keeping with our policy for new features [1]. > (This is > > > > also consistent with U2F support that is built into recent versions > of > > > > Google Chrome.) > > > > * We are implementing the high-level JavaScript API version 1.1. The > > > > specification for v1.1 is not yet published, but is already > implemented > > > in > > > > recent versions of Chromium [2]. > > > > * For the time being, U2F support will be gated behind preferences > and > > > > disabled by default. > > > > > > > > [1] > > > > > > > > https://blog.mozilla.org/security/2015/04/30/deprecating-non-secure-http/ > > > > [2] > > > > > > > > https://chromium.googlesource.com/chromium/src/+/master/chrome/browser/resources/cryptotoken/webrequest.js > > > > > > > > - J.C. > > > > > > > > > > > > On Wed, Jan 27, 2016 at 2:44 AM, Frederic Martin > > > > > wrote: > > > > > > > >> <http://w3c.github.io/websec/web-authentication-charter>Nearly two > > > >> months since that post... > > > >> Any news on this ? > > > >> > > > >> a) on Mozilla Foundation joining FIDO Alliance? > > > >> b) on FIDO U2F implementation inside Firefox Core? > > > >> > > > >> Thanx. > > > >> _______________________________________________ > > > >> dev-platform mailing list > > > >> dev-platform@lists.mozilla.org > > > >> https://lists.mozilla.org/listinfo/dev-platform > > > >> > > > > > > > > > > > _______________________________________________ > > > dev-platform mailing list > > > dev-platform@lists.mozilla.org > > > https://lists.mozilla.org/listinfo/dev-platform > > > > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
