Subject: [http-auth] Comment on "Signing HTTP Messages"

From: Richard Gibson <[email-masked]>
Date: Mon, 29 Jan 2018 21:55:23 -0500

https://tools.ietf.org/html/draft-cavage-http-signatures-09#section-2.2 
specifies the following:

 > If any of the parameters listed above are erroneously duplicated in 
the associated header field, then the last parameter defined MUST be used.

This may expose a client security vulnerability for attacks analogous to 
HTTP header injection. Is there a compelling reason not to reject 
requests that specify the same parameter more than once?

 > Any parameter that is not recognized as a parameter, or is not 
well-formed, MUST be ignored.

This will almost certainly limit future changes, since legacy clients 
won't implement desired behavior changes from new parameters _and_ will 
fail to signal that inability. Is there a compelling reason not to 
reject requests that specify unknown parameters?

---

From: Yoav Nir <[email-masked]>
Date: Tue, 30 Jan 2018 18:54:08 +0200

Hi, Richard

The http-auth mailing list is for the now-defunct working group HTTP-Auth.

The proper list for draft-cavage is the HTTP-bis WG mailing list: [email-masked] <mailto:[email-masked]>

Yoav

> On 30 Jan 2018, at 4:55, Richard Gibson <[email-masked]> wrote:
> 
> https://tools.ietf.org/html/draft-cavage-http-signatures-09#section-2.2 specifies the following:
> 
> > If any of the parameters listed above are erroneously duplicated in the associated header field, then the last parameter defined MUST be used.
> 
> This may expose a client security vulnerability for attacks analogous to HTTP header injection. Is there a compelling reason not to reject requests that specify the same parameter more than once?
> 
> > Any parameter that is not recognized as a parameter, or is not well-formed, MUST be ignored.
> 
> This will almost certainly limit future changes, since legacy clients won't implement desired behavior changes from new parameters _and_ will fail to signal that inability. Is there a compelling reason not to reject requests that specify unknown parameters?
> 
> _______________________________________________
> http-auth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/http-auth