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

Hi Fred,

Thank you for your quick response. My responses are between the lines.

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

The description provided at https://fidoalliance.org/mds/ is 
insufficient to understand it. However, when taking a look at the root 
certificate,
an information which should be present in it is missing: the location 
where certificates issued by the root CA are published. This would be 
useful
to construct the certification path, otherwise a Relying Party has no 
automatic way to locate them. The authority information access extension
(described in section 4.2.2.1. from RFC 5280) when using the 
accessMethod OIDs: id-ad-caIssuers should be included in the root 
certificate and
repositories containing intermediate CA certificates should be made 
publicly available.

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

I am not surprised when you say that this method is nor widely used, .. 
if used at all.
Since there are no minimal security requirements, the benefits of the 
current approach are questionable.

> 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 ;) ]

As we all know, fully preventing DOS is not possible whatever the 
context is. However, this is not a reason for leaving doors wide open.

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

As you know, many specifications used the SHOULD wording. We should say 
that KeyHandles SHOULD have fixed length.
One other problem (in addition to the leakage of non necessary 
information) when using KeyHandles with variable length,
will be the impossibility to migrate credentials from one hardware 
device into another hardware device. We need to have
a look at the future. Hardware device replacement is currently not 
addressed in FIDO, AFAIK.

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

The main reason will be for backward compatibility, but "key handle" is 
not the right name at least from a Relying Party point of view.
ISO standards related to authentication are using the word "identifier", 
they are not using the wording "key handle".

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

We all know that if we provide to a well known laboratory _a single_ 
smart card and ask it to find the private key, it is likely to fail 
because it will damage the chip.
However, if we provide to the same well known laboratory _one__hundred_ 
smart cards and ask it to find the private key, it is likely to succeed 
after damaging 20
of chips. Using the same private key in about 100.000 smart cards (as 
recommended) is very a bad practice.

> 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.
If my name is "Fred Smith" and if two different relying parties have 
opened an account under that claimed name and want to be reasonably 
confident
that it is the same individual, they could use that information to raise 
their level of confidence. This is why I said that full pseudonymity is 
not achieved.
The golden rule is not to reveal anything information that could help.

> Again, a rightly done FIDO MetaData Service might help to mitigate 
> this "problem".

A FIDO MetaData Service does not seem to be necessary. A client should 
be able to register without using an attestation certificate
(even if it has one). If the Relying party is not pleased with that 
registration message, it could send an error code and inform the client
about which kind of authenticators he would like to be used. This is the 
kind of approach that should  be supported.

> 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 :)

Well, it is like rearranging the deck chairs on the Titanic.

Denis

>
> 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 
> <mailto: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
>
>
>