Re: Call for Adoption: draft-reschke-rfc54987bis

On 2015-04-01 21:19, Willy Tarreau wrote:
> On Wed, Apr 01, 2015 at 10:13:23AM +0200, Julian Reschke wrote:
>> On 2015-03-31 07:42, Willy Tarreau wrote:
>>> 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?
>
> Just like we said that multiple content-length values are not acceptable
> if different despite most implementations not doing the check yet. I mean,
> by not specifying the control, we can leave the hole open.

I don't think that there *is* a hole.

>> b) How do you want to signal an error on a *response*?
>
> Good point. In haproxy we return a 502 bad gateway when the server
> returns something unparsable. Only the client receives it and (in
> rare occasions) reports it.

For Content-Disposition, this would likely break things that "work" 
today (for some value of "work").

>>> 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.
>
> I had never heard about %-encoding in header fields to be honnest,
> and I don't know which servers or intermediaries decode them given
> that unless I'm mistaken, "%" is a valid character in a header field
> and doesn't imply %-encoding.

You may want to re-read the spec. It only applies to specific parameter 
names ending in "*".

>>> 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.
>
> That can become delicate.

It doesn't seem to be a problem today.

>> For instance,
>> RFC 6266 discusses these constraints for the filename parameter.
>
> Indeed, I wasn't aware of this. And it uses the same syntax as in
> your proposal.

It uses the encoding defined in RFC 5987, and that's the spec we would 
be revising here.

>>> Otherwise I think it could be useful indeed.
>>
>> It already is, and has been for a long time.
>
> It's just that I never heard about this.
>
> I really think that in the future we should make better use of the
> 8bit-clean path of HTTP/2 to avoid having to repeat such exceptions,
> but I'm sure we'll have to go a long way before reaching this stage :-/

I agree, but that's a completely orthogonal project.

Best regards, Julian

Received on Wednesday, 1 April 2015 19:45:39 UTC