W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2015

Re: Call for Adoption: draft-reschke-rfc54987bis

From: Willy Tarreau <w@1wt.eu>
Date: Tue, 31 Mar 2015 07:42:45 +0200
To: Mark Nottingham <mnot@mnot.net>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <20150331054245.GB7069@1wt.eu>
On Tue, Mar 31, 2015 at 03:08:06PM +1100, Mark Nottingham wrote:
> We discussed this document in Dallas:
>   <http://tools.ietf.org/html/draft-reschke-rfc5987bis>
> 
> Based on the feedback received, I believe that we should adopt this document
> as a WG product, with a target of Proposed Standard.
> 
> I've discussed it with our Area Director, who agrees that it's a reasonable
> thing for us to do.
> 
> Since this is a bis effort with a primary aim of aligning with RFC723x, I
> think we can do this relatively quickly, with a target of going to IETF LC by
> Prague.
> 
> Please comment on-list; we???ll make a decision about adoption at the end of
> the week.

After a quick review, I think we should make it stricter. Currently,
it suggests that recipients should be prepared to receive invalid code
sequences but that can be dangerous when passing through multiple
intermediaries because all of them could have different fallback
methods. I'd rather make it clear that any recipient in the chain
which finds an encoding issue must return a 400 bad req.

Also, I'd prefer to make it explicitly forbidden to %-encode US-ASCII
characters because this could be used to bypass some WAFs for example :
if it is detected that a server implements this standard and is able
to %-decode some attributes in header fields, and a WAF in the middle
does not, the client can abuse the %-encoding to try to hide some
activities.

In addition to this, probably that we should make it clear that some
characters must not be emitted nor encoded (NUL, CR, LF). The risk is
that some intermediaries decode them and replace them before passing
the request to the next hop and change the message header structure,
resulting in issues similar to HTTP request smugling attacks.

Otherwise I think it could be useful indeed.

Thanks,
Willy
Received on Tuesday, 31 March 2015 05:43:11 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:43 UTC