Clean up signature references and text #2143

jricher · 2022-06-01T21:37:34Z

Multiple editorial and example cleanups:

move italics, closes Formatting of italicized items in plain text version #2135
clean up ABNF, closes message-signatures: ABNF ref missing #2138
fix dangling references, closes message-signatures: broken deep links #2137
update request-response example
add query-param example, closes [signatures] Include example of "@query-params" in list of covered components #1981
call out weirdness with Set-Cookie, closes Multiple Set-Cookie headers are not well supported #1183

draft-ietf-httpbis-message-signatures.md

…elds, make base generation fail on unknown parameters

martinthomson · 2022-06-06T22:22:39Z

draft-ietf-httpbis-message-signatures.md

@@ -1790,6 +1793,20 @@ From here, the signing process proceeds as usual.

 Upon verification, it is important that the verifier validate not only the signature but also the value of the Content-Digest field itself against the actual received content. Unless the verifier performs this step, it would be possible for an attacker to substitute the message content but leave the Content-Digest field value untouched. Since only the field value is covered by the signature directly, checking only the signature is not sufficient protection against such a substitution attack.

+## Non-List Field Values {#security-non-list}
+
+When an HTTP field occurs multiple times in a single message, these values need to be combined into a single one-line string value to be included in the HTTP signature base, as described in {{create-sig-input}}. Not all HTTP fields can be combined into a single value and still be a valid value for the field. However, for the purposes of generating the signature base, the message component value is never read back out of the signature base string and used in anyway. Therefore it is considered best practice to treat the signature base generation algorithm separately from processing the field values by the application, particularly for fields that are known to have this property.


"and used in anyway" ?

martinthomson · 2022-06-06T22:25:47Z

draft-ietf-httpbis-message-signatures.md

+
+When an HTTP field occurs multiple times in a single message, these values need to be combined into a single one-line string value to be included in the HTTP signature base, as described in {{create-sig-input}}. Not all HTTP fields can be combined into a single value and still be a valid value for the field. However, for the purposes of generating the signature base, the message component value is never read back out of the signature base string and used in anyway. Therefore it is considered best practice to treat the signature base generation algorithm separately from processing the field values by the application, particularly for fields that are known to have this property.
+
+For example, the Set-Cookie field {{COOKIE}} defines an internal syntax that does not conform to the List syntax in {{STRUCTURED-FIELDS}}. This field is also typically sent as multiple fields with distinct values when sending multiple cookies. When multiple Set-Cookie fields are sent in the same message, it is not possible to combine these into a single and be able to parse and use the results, as discussed in {{HTTP, Section 5.3}}. Therefore, all the cookies need to be processed from their separate header values, without being combined, while the signature base needs to be processed from the special combined value generated solely for this purpose.


This misses the attack.

Say you have:

Set-Cookie: that, happens, to, contain, a, comma

An attacker is now able to construct a variant message that produces the same signature:

Set-Cookie: that, happens Set-Cookie: to, contain, a, comma

This will be processed differently, but it will be signed and treated as such.

For me, this is an unacceptable property of a signature scheme.

Thanks, I didn't call out the commas specifically here but I'll tweak the text to address that.

jricher added 8 commits June 1, 2022 14:12

move italics, closes #2135

eb1f253

clean up ABNF, closes #2138

87413ff

remove trailing whitespace

cbd9816

fix dangling references, closes #2137

754b25b

update request-response example

4a256da

clean up header display

bc0296f

add query-param example, closes #1981

4bee5d5

call out weirdness with Set-Cookie, closes #1183

603740d

jricher requested a review from richanna as a code owner June 1, 2022 21:37

jricher added the signatures label Jun 1, 2022

jricher commented Jun 1, 2022

View reviewed changes

draft-ietf-httpbis-message-signatures.md Outdated Show resolved Hide resolved

jricher added 5 commits June 1, 2022 17:39

Update draft-ietf-httpbis-message-signatures.md

4d321a2

added discussion on non-list fields and collisions across multiple fi…

26f260c

…elds, make base generation fail on unknown parameters

fix whitespace

214ed26

fix reference anchors

329df17

update RFCs for HTTP core

040ae6d

martinthomson requested changes Jun 6, 2022

View reviewed changes

jricher added 2 commits June 17, 2022 16:30

add comma discussion

4e1e849

discuss set-cookie better

3e5058f

jricher merged commit 48485cd into main Jun 17, 2022

jricher deleted the text-ref-cleanup branch June 17, 2022 20:47

jricher mentioned this pull request Jun 17, 2022

Wrapped encoding for problematic fields #2166

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Clean up signature references and text #2143

Clean up signature references and text #2143

jricher commented Jun 1, 2022

martinthomson Jun 6, 2022

martinthomson Jun 6, 2022

jricher Jun 7, 2022


		When an HTTP field occurs multiple times in a single message, these values need to be combined into a single one-line string value to be included in the HTTP signature base, as described in {{create-sig-input}}. Not all HTTP fields can be combined into a single value and still be a valid value for the field. However, for the purposes of generating the signature base, the message component value is never read back out of the signature base string and used in anyway. Therefore it is considered best practice to treat the signature base generation algorithm separately from processing the field values by the application, particularly for fields that are known to have this property.

		For example, the Set-Cookie field {{COOKIE}} defines an internal syntax that does not conform to the List syntax in {{STRUCTURED-FIELDS}}. This field is also typically sent as multiple fields with distinct values when sending multiple cookies. When multiple Set-Cookie fields are sent in the same message, it is not possible to combine these into a single and be able to parse and use the results, as discussed in {{HTTP, Section 5.3}}. Therefore, all the cookies need to be processed from their separate header values, without being combined, while the signature base needs to be processed from the special combined value generated solely for this purpose.

Clean up signature references and text #2143

Clean up signature references and text #2143

Conversation

jricher commented Jun 1, 2022

martinthomson Jun 6, 2022

Choose a reason for hiding this comment

martinthomson Jun 6, 2022

Choose a reason for hiding this comment

jricher Jun 7, 2022

Choose a reason for hiding this comment