W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2023

Re: HTTP Unprompted Authentication

From: David Schinazi <dschinazi.ietf@gmail.com>
Date: Mon, 6 Feb 2023 17:30:28 -0800
Message-ID: <CAPDSy+7Xmp5Fx=kQx3OsoDumGJnfh-Meb-yw_ddvYNog3x0JZA@mail.gmail.com>
To: Ilari Liusvaara <ilariliusvaara@welho.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Thanks Ilari for the comments. I agree with your points and think we can
resolve them in a pretty straightforward way. To make sure we don't lose
them, I've filed them as individual GitHub issues <
We'll look into addressing them once we have a decision from the WG whether
there is interest in adoption.


On Sun, Feb 5, 2023 at 2:01 AM Ilari Liusvaara <ilariliusvaara@welho.com>

> On Fri, Feb 03, 2023 at 04:30:16PM -0800, David Schinazi wrote:
> > Hi HTTP enthusiasts,
> >
> > When I presented HTTP unprompted authentication at the last IETF,
> > there appeared to be interest in the room but Ben raised some concerns.
> > The chairs asked me to resolve those before asking about adoption.
> > Ben and I met and were able to resolve them by changing the document
> > to reuse the HTTP Authentication Schemes registry instead of defining
> > a new one. This change is visible in revision -01:
> >
> https://www.ietf.org/archive/id/draft-schinazi-httpbis-unprompted-auth-01.html
> > and a diff is here:
> >
> https://author-tools.ietf.org/iddiff?url2=draft-schinazi-httpbis-unprompted-auth-01
> >
> > Chairs, I would now like to ask for an adoption call if you think that's
> a
> > good idea.
> - In section 2, I see this text:
> ------------------------------------------------------------------------
> This includes any use of HTTP over TLS as typically used for HTTP/2
> [HTTP/2], or HTTP/3 [HTTP/3] where the transport protocol uses TLS as
> its authentication and key exchange mechanism [QUIC-TLS].
> The user agent leverages a TLS keying material exporter [KEY-EXPORT] to
> generate a nonce which can be signed using the user's key.
> ------------------------------------------------------------------------
> I think implying that it works for any TLS is rather bad, even if there
> was security considerations narrowing the scope (which there do not seem
> to be).
> The problem is that the original TLS 1.2 keying material exporter is
> flawed in a way that it can not be safely used for authentication. Now,
> either TLS 1.3 or the Extended Master Secret extension fixes this flaw.
> The TLS as used in HTTP/3 is TLS 1.3, so it will be okay. But TLS as
> used in HTTP/2 can be TLS 1.2 without EMS, which is not okay. And
> then there is HTTP/1.1, which has no TLS requirements at all.
> - The "TLS SignatureAlgorithm" and "TLS HashAlgorithm" registeries
> have been deprecated. A solution would be to just remove the h= and
> s= parameters: The server could look those up from the key (precludes
> variable-hash RSA keys, but I do not think those are actually
> important).
> - The signature/HMAC is taken over raw nonce, which I do think is a
> good idea. A solution would be using the TLS 1.3 signature format
> with some specific label.
> - In section 6, it is said that intermediaries will validate the
> authentication themselves. It would be possible for intermediary to
> export the nonces (which are not sensitive), and send those to the
> back-end (I have done PoC implementation of this).
> -Ilari
Received on Tuesday, 7 February 2023 01:30:53 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 7 February 2023 01:30:54 UTC