Re: Deb Cooley's No Objection on draft-ietf-httpbis-unprompted-auth-11: (with COMMENT)

Hi Deb, and thanks for your review.
I've landed the following commit in response to your comments:
https://github.com/httpwg/http-extensions/commit/5d4d453f48525145c3e3c3771bb105e39ca7b6f2
More detailed responses inline.
David

On Tue, Sep 17, 2024 at 7:33 AM Deb Cooley via Datatracker <noreply@ietf.org>
wrote:

> Deb Cooley has entered the following ballot position for
> draft-ietf-httpbis-unprompted-auth-11: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-httpbis-unprompted-auth/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Thanks to Rich Salz who did the secdir review.
>
> I have two small comments:
>
> Section 3.1, para 1:  the character 'a' as a type of parameter looks like a
> typo.  The font change in the html version of the draft still isn't much
> different than the normal draft font.  Maybe quotation  marks would help
> (like
> in Section 4)?  Note:  there are other parameters used in section 3.2,
> these
> aren't normally regular words in English, so they aren't as confusing.  But
> whatever you do for 'a' should be done for the others.  Also note:  I have
> not
> looked at this in the text version of the draft.
>

The HTTP style guide [1] recommends using double quotes when defining header
fields (and by extension, parameters) and not using double quotes when
referring
to them. We followed that in this document, so we use double quotes in
section 4, on no quotes in other sections. I used the backtick notation in
markdown
to get a slight differentiation, but I agree with you that more could be
done in the
CSS of our documents - that's not specific to this draft though.

In hindsight, I think that you're right and we should have picked a
different letter
than "a" because "a" is a word in English, but at this point it doesn't
warrant
making a compatibility-breaking change.

[1] https://httpwg.org/admin/editors/style-guide#header-and-trailer-fields

Section 3.3:  'prefixed with static data before being signed to mitigate
> issues
> caused by key reuse'.  I'd like to understand what is meant by this (not
> necessarily a draft change).  Normally key reuse issues are mitigated by
> non-static data, a nonce, or something that is guaranteed to be
> different.  I
> don't understand why adding a static prefix mitigates a key reuse issue.
> Nor
> do I understand what the key reuse issue would be - reuse of the key
> exporter
> output?  or something else?  If this is tied to the para/sentence in
> Security
> Considerations ( thou shalt not use in other protocols - I'm paraphrasing),
> then I think a short phrase in Section 3.3 could help the reader.
>

The key being reused here is the authentication private key (or rather, the
authentication asymmetric keys). I've made an editorial change to clarify
that.
The issue would be if someone used their asymmetric keypair in both
concealed
auth and let's say TLS raw keys, or TLS certificate keys, or IKEv2 auth
keys.
This is indeed tied to the reuse text in the Security Considerations
section.
I've added references between the two, and additional text that hopefully
clarifies things.