Re: HTTP Unprompted Authentication

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 <
https://github.com/DavidSchinazi/draft-schinazi-httpbis-transport-auth/issues>.
We'll look into addressing them once we have a decision from the WG whether
there is interest in adoption.

David

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

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