- From: Deb Cooley via Datatracker <noreply@ietf.org>
- Date: Tue, 17 Sep 2024 07:33:05 -0700
- To: "The IESG" <iesg@ietf.org>
- Cc: draft-ietf-httpbis-unprompted-auth@ietf.org, httpbis-chairs@ietf.org, ietf-http-wg@w3.org, tpauly@apple.com, tpauly@apple.com
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. 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.
Received on Tuesday, 17 September 2024 14:33:10 UTC