By the way, I just got informed (from Google) that TLS Channel ID, even if activated on Google servers (including appspot), is only enforced for few users for now (even If I am not sure how they do that :) )
So Firefox users should not be blocked for that reason :) They seem to agree you probably should focus on "the updated specification, the Token Binding one. Since that has a better chance of getting approved in the IETF" https://tools.ietf.org/html/draft-ietf-tokbind-protocol-04 So great news. Please consider looking the new Token Binding specifications... Thanx again for all your great work. -- Frédéric On Monday, February 8, 2016 at 11:36:38 PM UTC+1, Eric Rescorla wrote: > 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
