Re: Call for Adoption: draft-reschke-rfc54987bis

On 2015-03-31 07:42, Willy Tarreau wrote:
> On Tue, Mar 31, 2015 at 03:08:06PM +1100, Mark Nottingham wrote:
>> We discussed this document in Dallas:
>>    <>
>> 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.

a) It's not the case right now. How do you want to get this change 
deployed in practice?

b) How do you want to signal an error on a *response*?

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

Yes, that's the case right now. I'd argue that the spec has been out for 
ages, so the intermediary ought to be fixed.

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

I think that depends on the header field it is used in. For instance, 
RFC 6266 discusses these constraints for the filename parameter.

> Otherwise I think it could be useful indeed.

It already is, and has been for a long time.

Best regards, Julian

Received on Wednesday, 1 April 2015 08:13:55 UTC