Re: Eleven comments on " Web Authentication: An API for accessing Public Key Credentials". W3C Working Draft, 5 May 2017

Hi Denis, I am not part of official WGs but I think I tested every U2F
hardware and software implementations available :)
I work for a U2F device manufacturer and am involved in some U2F and
U2F-derivated projects...
.... and like you, I am following WebAuthN specifications ongoing works.

Regarding some of your suggestions, my main two cents:

Point 2 about Attestation Certificate:
------------------------------------------------
Obvious reminder to start : Attestation Certificate allow servers to
discriminate U2F implementations. Some implementations (and devices) are
secure, a few other ones are clearly less secure... So this is an important
feature that should be preserved. This is for now totally optional to use
any kind of "valid" certificate, meaning linked to a well known root CA and
most of products use self-signed certificates. If server side don't care
about it, this is fine. By the way, Fido Alliance is trying to have a
central service about this https://fidoalliance.org/mds/ and this could be
a great way to check if the key pairs were generated inside a secure
implementation. FIDO Alliance is trying to level up their security
certifications (far from perfect but that's a good start). Attestation
certificate is an important part of the architecture security.

Reminder: Most of U2F compatible servers do not even check the chain of
trust related to Attestation Certificates. This is totally optional. This
could be the same for WebAuthN ? It will probably depend on the success of
a future WebAuthN MetaData Service...

Quoting your post: "This would be a very bad practice. One of the
consequences is that it would be possible to create numerous unused
accounts without even the burden of generating key pairs. This is a door
wide opened for denial of service." I followed your proposed proof of
possession (PoP) way of doing and with the very light burden of having to
generate key pairs, we have the same problem. I don't see how it can limit
potential DOS attacks based on "fake" keys generation (or did I miss
something?). [ Note/Trick: As a U2F software implementation, you can even
use the freshly generated user public key as a fake attestation certificate
public key to already achieve your goal inside a U2F product ;) ]

Point 3 about Key Handle Size and usage:
--------------------------------------------------------
Even just for backward compatibility requirements, KeyHandles can't have
fixed length: Existing FIDO U2F products already use different sizes of key
Handles (it may vary by manufacturers, products...). The majority of
already existing FIDO U2F use Key wrapping (even if I don't enjoy how it is
done most of the times...).

IMHO, client Identifier would not be a good name for many different
reasons...

Point 11 about Attestation private Key security:
--------------------------------------------------------------
I agree with your point: "If the private key is extracted using a set of
authenticators sharing the same private key, it is possible to create
"fake" hardware authenticators" ... BUT this is why most of U2F products
manufacturers are using Secure Elements (smart cards components): to avoid
such extraction and to assure the authenticity of the manufacturers (and
its implementations).

Can you explain this part "the use of the same private key and certificate
by hardware authenticators does not allow to achieve full pseudonymity"? I
don't understand that point since if a same attestation certificate is used
inside a large number of products, it preserves pseudonymity. Again, a
rightly done FIDO MetaData Service might help to mitigate this "problem".

Bonus:
---------
Another small privacy and DOS concern: a badly handled "shared counter"
inside U2F implementations may be a problem too... Man, this counter
"protection" was a bad-good idea :)

Regards
--
Frederic MARTIN
System & Security Architect
U2F Cheat Sheet: https://gg.gg/u2fcs


On Mon, Jul 24, 2017 at 4:57 PM, Samuel Weiler <weiler@w3.org> wrote:

> On 7/24/17 10:21 AM, Denis Pinkas wrote:
>
>> Hello,
>>
>> I am a member of the OAuth WG and of the SAAG WG. I read the draft notes
>> from the SAAG IETF 99 where a few words
>> from Sam Weiler (W3C) have been reported:
>>
>> WebAuthn making good progress. Trying to get more eyes doing privacy and
>> security reviews on specs.
>> Please get in touch with me if you want to keep our WGs from doing
>> stupid things.
>>
>> The terms used by Sam are rather odd: "keep our WGs from doing /stupid
>> things/" and I am wondering why these terms have been used.
>> If it was simply to draw our attention, the goal has been reached.
>>
>
> The SAAG minutes don't quite capture that I was trying to share two very
> distinct thoughts.  To the extent that's my fault rather than the scribe's,
> I apologize.
>
> I don't think the WebAuthn spec is in terrible shape - indeed, I was
> trying to report that the WG is moving along nicely.
>
> I am, however, trying to recruit reviewers for other W3C specs - our other
> working groups sometimes suffer from a deficit of privacy- and
> security-aware eyes reading their specs, and I'm hopeful that some in the
> IETF security community might be interested in helping us correct that.
>
> Thank you for your comments on the WebAuthn spec.  I'll leave it to the WG
> to offer a substantive reply.
>
> -- Sam
>
>
>