Re: draft-ietf-httpbis-unprompted-auth-03

Thanks for your review Ilari! Responses inline.
David

On Thu, Jun 29, 2023 at 2:11 AM Ilari Liusvaara <ilariliusvaara@welho.com>
wrote:

> Some quick comments (this includes -04):
>
>
> - Using sf-binary is creating great deal of unnecressary complexity.
>   Much simpler would be to use base64url for binary fields. Furthermore,
>   it turns out all base64url characters are token-valid, so one would
>   not even need the double quotes!
>

That's reasonable. Personally, I don't have a strong opinion either way,
but I suspect others might. I've added this to
https://github.com/httpwg/http-extensions/issues/2581
and we can discuss at 117.

- I don't think inserting delays to hide if validation succeeded or
>   failed is a good idea.
>
>   Another way to deal with it would be to always try to validate the
>   signature if in scope with protected resources. This can abort early
>   e.g., if key is not found.
>

I agree that delaying isn't always the best approach. In -04 I've softened
the text to only mention it as an option instead of requiring it.

- There was a review comment about relative appeal of the options of
>   doing validation in the TLS terminator versus pushing it downstream.
>
>   Two reasons one might want to push the validation downstream are:
>
>   1) Avoiding configuration logistics challenges with keys.
>
>   2) The backends being better equipped to deal with load compared to
>      the TLS terminator (especially if using HTTP/3).
>

Our "intermediary considerations" section presents two options for folks
who want to push the validation to a backend, but I don't think we need
to motivate that - every deployment has different requirements and I
don't think these reasons apply to all.

  There was also comment about TLS terminator to be better equipped for
>   caching. It seems to me that backend could cache N most recent
>   successful nonces, and skip validation if nonce is found in the
>   cache.
>

I'm not sure I follow. This optimization seems risky and I don't think we
need to specify it.

  I noticed that there does not seem to be one place that contains the
>   headers that should be dropped unless configured otherwise (for
>   trusted reverse proxy upstream).
>
>   Here is a list of such headers from some piece of code I wrote:
>
>   - client-cert
>   - client-cert-chain
>   - x-src-ip
>   - x-real-ip
>   - x-forwarded-*  (i.e., anything starting with "x-forwarded-").
>
>   Which gives very dirty idea of using something starting with
>   x-forwarded- for signaling this stuff.
>

This sounds relevant to HTTP as a whole, and not specific to this draft.