- 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>
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