Re: WebCrypto.Next needs a Google/Microsoft statement on U2F

On 2013-12-29 12:06, Jeffrey Walton wrote:
> All in all, it looks good but there could be some disappointment.

Ignoring some of the technical details (the true spec is still secret...) I have a couple of comments.

> 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.

It is the client/device that mints keys, not a central server.  Unlike
password-based systems there are no user-keys to steal on the server.


> 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.

Is the problem here that you can refuse to disclose a password while a token
can be taken without permission?  If you are thinking about dictator-like regimes,
I believe most people would handover whatever they ask for, be it a password
or token.

If the service provider is "cooperative" it doesn't matter what kind of
authentication solution you use.  This is how NSA did/does it.

Anders



> 
> 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:37:05 UTC