Intent to Ship: WebAuthn PRF extension

281 views
Skip to first unread message

Adam Langley

unread,
Jul 17, 2020, 6:38:24 PM7/17/20
to blink-dev
a...@chromium.org https://w3c.github.io/webauthn/#prf-extension N/A The PRF extension to WebAuthn allows an HMAC, stored on the security key, to be evaluated when getting a credential. This can be used to derive secret keys used to encrypt user data. https://groups.google.com/a/chromium.org/g/blink-dev/c/t_9QdJ7hcls/m/CAAOGBIVBgAJ
Support on Windows >= 1903 depends on Microsoft implementing it in Windows. Support on Android depends on Android's WebAuthn library supporting it. Gecko: No signal WebKit: No signal Web developers: No signals We have had requests for this general feature, although I'm not aware of opinions about the final form of it. The spec contains provisions for evaluating the PRF at credential creation time. But that depends on future changes to CTAP, the security key protocol, and thus is not implemented at this time. If a future CTAP 2.2 supports this, as we hope it will, that support will be added later. Some platforms may have assumed that the web would not ever be able to access the HMAC oracles in security keys. Therefore the HMAC inputs are hashed with a context string before being used, thus preventing sites from evaluating any HMAC input from the native domain.
This feature is supported by Chromium's simulated security key and can be used by Web Driver tests and, later, could be exposed in DevTools. Yes Support on Windows >= 1903 depends on Microsoft implementing it in Windows. Support on Android depends on Android's WebAuthn library supporting it.

Manuel Rego Casasnovas

unread,
Jul 21, 2020, 6:18:31 AM7/21/20
to blin...@chromium.org


On 18/07/2020 00:37, Adam Langley wrote:
> TAG review
> N/A

Any good reason to not request a TAG review?

> /Gecko/: No signal
> /WebKit/: No signal

Have we asked them for feedback?

Please check the new document regarding signals for more information:
https://docs.google.com/document/d/1xkHRXnFS8GDqZi7E0SSbR3a7CZsGScdxPUWBsNgo-oo/edit#heading=h.tgzhprxcmw4u

Bye,
Rego
pEpkey.asc

Adam Langley

unread,
Jul 24, 2020, 12:59:58 PM7/24/20
to blink-dev, Manuel Rego
On Tuesday, July 21, 2020 at 3:18:31 AM UTC-7 Manuel Rego wrote:
On 18/07/2020 00:37, Adam Langley wrote:
> TAG review
> N/A

Any good reason to not request a TAG review?

I'm not sure what question we would be seeking input on. I.e. there are lots of small changes in WebAuthn level two, and we don't want to spam TAG, so what warrants consideration? Some times there are obvious red flags, but this seems minor. However, I might be missing an alternative perspective.
 
> /Gecko/: No signal
> /WebKit/: No signal

Have we asked them for feedback?

Both groups are present in the working group and neither objected. I'll ask J.C. (from Mozilla) to weigh in here.


Cheers

AGL

J.C. Jones

unread,
Jul 29, 2020, 4:31:24 PM7/29/20
to blink-dev, a...@chromium.org, Manuel Rego

Thanks for the ping, Adam.

Mozilla doesn’t see why this capability belongs in Web Authentication, nor why something so powerful should be implemented as an extension to something otherwise unrelated, even if they share the same wire protocol. Blink-dev isn’t the correct venue, but I’d like to start a thread in the WG mailing list asking to clarify why this hardware-backed secret derivation scheme is proposed to be implemented in this fashion, as an extension to the web’s authentication signature specification.

Cheers,

J.C.

Adam Langley

unread,
Jul 29, 2020, 5:09:17 PM7/29/20
to J.C. Jones, blink-dev, Manuel Rego
On Wed, Jul 29, 2020 at 1:31 PM J.C. Jones <j...@mozilla.com> wrote:

Mozilla doesn’t see why this capability belongs in Web Authentication, nor why something so powerful should be implemented as an extension to something otherwise unrelated, even if they share the same wire protocol. Blink-dev isn’t the correct venue, but I’d like to start a thread in the WG mailing list asking to clarify why this hardware-backed secret derivation scheme is proposed to be implemented in this fashion, as an extension to the web’s authentication signature specification.

Can you open an issue on the GitHub for that? While this could just be exposed to extensions, we have had requests for this to be a web-exposed feature (bug, and also a large password-manager have asked directly).

To avoid extra round trips, do you have concerns about any of the other things on the prototype list?


Cheers

AGL


J.C. Jones

unread,
Jul 29, 2020, 6:08:56 PM7/29/20
to blink-dev, a...@chromium.org, blink-dev, Manuel Rego, J.C. Jones
Thanks, Adam.

I will indeed open an issue as soon as I can, I'm working on the details now, as I want it to be as concrete as I can make it.

I don't see any other things of equal concern on your prototype list, though I don't understand the utility of all the parts. I imagine we'll have to explain that when they go to a PR, so I'll raise issues as I see it needed.

Cheers,
J.C.

J.C. Jones

unread,
Jul 30, 2020, 12:19:22 PM7/30/20
to blink-dev, J.C. Jones, a...@chromium.org, blink-dev, Manuel Rego

Mozilla has filed an issue upstream at the WebAuthn working group calling to remove this extension from the Web Authentication working draft and instead possibly add it into WebCrypto. As-is, this extension has confusing properties for application developers, and will not be extensible in the future in a way that hardware-backed, origin-bound encryption support deserves.

Link: https://github.com/w3c/webauthn/issues/1462

Cheers,
J.C.

Alex Russell

unread,
Aug 13, 2020, 3:12:51 PM8/13/20
to blink-dev, J.C. Jones, a...@chromium.org, blink-dev, Manuel Rego
Hey all,

Sorry for the slow follow-up. It isn't entirely clear what the end-developer code difference and end-user experienced differneces between these two approaches to the API design would be. Has anyone produced an analysis along these lines? The "confusing for app developers" claim, in particular, feels like something that should be straightforward to demonstrate in example code.

Regards

J.C. Jones

unread,
Aug 18, 2020, 11:01:55 AM8/18/20
to Alex Russell, blink-dev, a...@chromium.org, Manuel Rego
As an update, we're working through this issue in the working group, and seem to have at least two paths forward; I owe the WG at least one PR, which is in-progress.

I believe the Github issue illustrates the dangers of confusing application developers reasonably well, though the primary danger lies for developers who want the hardware-backed secret keys without combining it (in the same method call) with an authentication operation: there lie cryptographic minefields, as illustrated in the Github issue. Improving on that situation is still up-in-the-air.

J.C.

Alex Russell

unread,
Aug 20, 2020, 3:10:44 PM8/20/20
to blink-dev, J.C. Jones, blink-dev, Adam Langley, Manuel Rego, Alex Russell
Per the thread, it appears that this design moving forward doesn't preclude additions to webcrypto along these lines. I'm included to approve this as a result, particularly given that no analysis along the lines I requested have been produced.

Do I misread the situation?

J.C. Jones

unread,
Aug 20, 2020, 5:59:48 PM8/20/20
to Alex Russell, blink-dev, Adam Langley, Manuel Rego, Alex Russell
I disagree that no analysis has been produced, as it exists in the first comment of the Github issue.

Nevertheless, I do agree that the substance of what is already specified is reasonable to proceed with experiments; my intentions are to be additive to the proposed API.

Also, although this extension is not within the agreed-upon features scope of WebAuthn's working group charter, the remedy for that does not require the extension be abandoned, but more likely moved, which hopefully will gather a wider audience to look at and comment on its properties and ergonomics. That would also remove it from the burden of being in the late stages of finalizing WebAuthn Level 2, and give the community more room to iterate on it if needed.

J.C.
Reply all
Reply to author
Forward
0 new messages