Re: HTTP Unprompted Authentication

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