- From: Jeffrey Walton <noloader@gmail.com>
- Date: Sun, 29 Dec 2013 06:06:08 -0500
- To: Anders Rundgren <anders.rundgren.net@gmail.com>
- Cc: "public-webcrypto-comments@w3.org" <public-webcrypto-comments@w3.org>
All in all, it looks good but there could be some disappointment. ***** >From Slide 8: Top picture with cell phones. Most devices that I am familiar lack the ports required for the Yubikey, unless it has a min-USB interface. But Yubico's site does not show such a device (http://www.yubico.com/products/yubikey-hardware/). ***** >From Slide 10: * User's device mints new key pair, gives public key to server * Server asks user's device to sign data to verify the user. That looks like a central server, and its probably a weak point in the system. What happens when law enforcement or government says, "reset the password on this account, and associate this Yubikey with the account." The user and relying parties could be in for a world of hurt. Folks could turn a {naive|blind} eye in the past, but its really hard to do now in the post-Snowden era. The breadth and depth of infiltrations and subversions is unprecedented. Open Question: what are the protocols used with the hardware? Is it, send a challenge and then wait for a response? Should past logins be tied to new logins in an attempt to ensure continuity of the enrollment key? How does a relying party ensure continuity? ***** >From Slide 10: * Fast crypto in device (Elliptic Curve) This probably won't happen in practice anytime soon because it is a patent minefield. As far as I know, Certicom is not licensing to anyone. You can't even get a response for their IPR Contribution in SSL/TLS ([0]). It appears Certicom is just setting traps for patent violations, and its unfortunate the IETF has allowed things to get so out of hand. And its really unfortunate new protocols a being developed with the traps built-in. ***** >From Slide 11: * UI seen by user completely under server control This sounds a bit tenuous. ***** We need to see the legal surrounding these devices and systems. The lawyers usually shed all risk in them, and we can use the lawyer's observations to identify more risk than that which percolates to the top from a slide deck. Jeff [0] http://www.certicom.com/images/pdfs/certicom%20-ipr-contribution-to-ietfsept08.pdf On Sat, Dec 28, 2013 at 1:46 AM, Anders Rundgren <anders.rundgren.net@gmail.com> wrote: > For those who think U2F is something completely different the following lines from an early (still public...) specification > > > https://docs.google.com/presentation/d/16mB3Nptab1i4-IlFbn6vfkWYk-ozN6j3-fr7JL8XVyA/edit?pli=1#slide=id.g19c09a112_2_88 > > Direct Access from Browser: > > No client middleware to install > > Simple Javascript API: 'Create Key Pair' and 'Sign' > Not just tied to login! Use anytime you want to strongly verify user. > > > should be an eye-opener. > > On 2013-12-19 05:04, Anders Rundgren wrote: >> Gentlemen, >> >> AFAICT, there's a considerable overlap between WebCrypto.Next >> http://www.w3.org/2012/webcrypto/wiki/WG_Future_Work >> and U2F. At least for the stuff that relates to user keys and tokens. >> >> It seems like an awful waste of precious cycles developing additional specifications >> if two of the most prominent parties have already decided to do something else. >> >> Would it be possible getting some kind of position on this? >> >> Thanx, >> Anders >> >> http://www.forbes.com/sites/amadoudiallo/2013/11/30/google-wants-to-make-your-passwords-obsolete/ >> >> http://fidoalliance.org/news/MicrosoftAnnounce.pdf
Received on Sunday, 29 December 2013 11:06:35 UTC