W3C home > Mailing lists > Public > public-webauthn@w3.org > December 2019

Re: [webauthn] Add a way to use webauthn without Javascript (#1255)

From: David Schinazi via GitHub <sysbot+gh@w3.org>
Date: Tue, 03 Dec 2019 18:54:54 +0000
To: public-webauthn@w3.org
Message-ID: <issue_comment.created-561306389-1575399293-sysbot+gh@w3.org>
Hi folks, I work on HTTP/3 and QUIC for Chrome. I'm jumping in to answer questions about QUIC authentication.

There hasn't been much discussion of "pluggable authn mechs" in the IETF QUIC working group. More specifically, the IETF QUIC WG is currently very focused on shipping HTTP/3 with TLS 1.3. That said, the QUIC [transport](https://tools.ietf.org/html/draft-ietf-quic-transport-24) and [authentication](https://tools.ietf.org/html/draft-ietf-quic-tls-24) documents were intentionally split so that one could "plug" a new authentication/key exchange scheme as a replacement for TLS. The one example I know of is [nQUIC](https://eprint.iacr.org/2019/028.pdf), but even that is a research project that was never deployed in production.

Another area of research that is worth noting is the integration of a PAKEs with TLS. One prominent candidate is [OPAQUE](https://eprint.iacr.org/2018/163.pdf): see [OPAQUE-TLS](https://tools.ietf.org/html/draft-sullivan-tls-opaque-00). The idea there is to allow proof of password ownership to be transmitted at the TLS layer without actually transmitting the password. This also provides bindings between the exchange and the TLS connection, making man-in-the-middle proxies' lives harder.

So if Webauthn were to pursue authentication at the transport layer, then I would strongly recommend making this at the TLS layer instead of QUIC, because it would allow working over networks that block UDP (or server deployments that aren't ready for QUIC yet), and also because it would not require reinventing a new authentication / key exchange scheme, which is fraught with peril.

All that said, I'm not sure moving webauthn to the transport is necessarily the right idea. Almost all Web/HTTP authentication has been historically performed at the application layer; and, if we were to change it, it should probably involve a bigger effort that also tries to do this for passwords. But that might take copious amounts of time and might derail the conversation about Javascript...

-- 
GitHub Notification of comment by DavidSchinazi
Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1255#issuecomment-561306389 using your GitHub account
Received on Tuesday, 3 December 2019 18:54:56 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:59:09 UTC