Re: HTTP Unprompted Authentication

Thanks Ilari and Nick for the reviews. 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 Thu, Oct 13, 2022 at 2:44 PM Nick Harper <ietf@nharper.org> wrote:

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