W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2022

Re: HTTP Unprompted Authentication

From: Nick Harper <ietf@nharper.org>
Date: Thu, 13 Oct 2022 14:40:31 -0700
Message-ID: <CACcvr=kPG=f2PEx4yhhd5dAGEy6uZNOKQBk7v=cjfK8=azB4OA@mail.gmail.com>
To: Ilari Liusvaara <ilariliusvaara@welho.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
I agree with Ilari - do not use the TLS SignatureAlgorithm and
HashAlgorithm registries that were orphaned by RFC 8447. For (asymmetric)
signatures, you could use the 16-bit TLS SignatureScheme registry (
https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-signaturescheme
).

The draft is very light on details about where the user's key (private or
symmetric) comes from. I assume that key
generation/distribution/registration/etc is out of scope for this draft,
but the draft should address the security properties expected of said key,
e.g. can a key be used for Unprompted Authentication and another use?

There's no mention of how a server should process this header and respond
to it. Given that the purpose is to be unprobable, the draft should
probably say something to the effect of "if a server receives a header it
is unable to validate, it should process the request as if the header were
not present". The security considerations should also discuss ways that a
server might inadvertently reveal that it serves resources protected by
this mechanism.

On Thu, Oct 13, 2022 at 1:09 PM Ilari Liusvaara <ilariliusvaara@welho.com>
wrote:

> On Thu, Oct 13, 2022 at 11:58:56AM -0700, David Schinazi wrote:
> > Hello HTTP enthusiasts,
> >
> > ---------- Forwarded message ---------
> > Name:           draft-schinazi-httpbis-unprompted-auth
> > Revision:       00
> > Title:          HTTP Unprompted Authentication
> > Document date:  2022-10-13
> > Group:          Individual Submission
> > Pages:          9
> > URL:
> >
> https://www.ietf.org/archive/id/draft-schinazi-httpbis-unprompted-auth-00.txt
>
> Some quick comments:
>
> - I do not see requirement for TLS 1.3 or Extended Master Secret
>   anywhere. It is not safe to use TLS Exporters for authentication
>   otherwise.
>
> - There is no requirement to include hash algorithm in signatures.
>   There are TLS signature algorithms that mean totally different
>   things depending on hash function, and more of those could
>   appear in the future. E.g, signatures 7 and 8 already have double
>   meaning (EdDSA [hash 8] and some Chinese stuff [hash 7]).
>
> - The signatures do not appear to be contextualized in any way,
>   which is questionable. For example, one could use the same
>   contextualization mechanism that TLS 1.3 uses (which prepends
>   64 spaces, a context label and NUL [one zero octet]).
>
>
>
> -Ilari
>
>
>
>
>
>
>
Received on Thursday, 13 October 2022 21:40:56 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 28 January 2023 21:29:46 UTC