Re: HTTP Unprompted Authentication

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.

Thanks,
David

On Thu, Oct 13, 2022 at 2:55 PM David Schinazi <dschinazi.ietf@gmail.com>
wrote:

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