Subject: Call for Adoption: draft-reschke-rfc54987bis

From: Mark Nottingham <[email-masked]>
Date: Tue, 31 Mar 2015 15:08:06 +1100

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.

Regards,

--
Mark Nottingham   https://www.mnot.net/

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 31 Mar 2015 07:42:45 +0200

On Tue, Mar 31, 2015 at 03:08:06PM +1100, Mark Nottingham wrote:
> Based on the feedback received, I believe that we should adopt this document
> as a WG product, with a target of Proposed Standard.
> 
> 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

---

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 31 Mar 2015 16:57:03 +0900

> does not, the client can abuse the %-encoding to try to hide some

This makes a lot of sense, but we have to be careful that this doesn't 
apply to all US-ASCII characters; there will be some that have to be 
escaped because of syntactic constraints.

<rant>
It's really a pitty that more than 25 years after the first version of 
HTTP, we are still carrying around this kind of antiquated baggage.
</rant>

I see that UTF-8 is the only encoding that's a MUST in the draft, so at 
least that's progress in the right direction (although rather glacial).

Regards,   Martin.

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 31 Mar 2015 10:19:01 +0200

> escaped because of syntactic constraints.

Absolutely, I was making a general point. For sure, commas, semi-colons,
spaces, tabs, quotes for example should be encoded.

Willy

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Tue, 31 Mar 2015 14:40:36 +0000

--------
In message <[email-masked]>, Mark Nottingham wri
tes:

>Based on the feedback received, I believe that we should adopt this
>document as a WG product, with a target of Proposed Standard.

Solving the problem:  Yes, good idea.

"Solving" it this way:  Bad idea.

First, we're worried about transmission times for HTTP so making
the charset selection per header-subfield is a horribly inefficient
way to solve the problem.

Second, do we really want to make it possible to have one subfield
of a header be KOIR8 and the next subfield be codepage 1251 ?

Third, are there *any* valid reasons to even allow other charsets
than ISO-8859-1 or UTF-8 from 2015 forward ?

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[email-masked]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 31 Mar 2015 20:25:21 +0200

> way to solve the problem.

I think it still makes sense because some intermediaries could be each
adding one header field and it would really not be handy for them to
have to lookup a certain header to know what format to emit theirs.
However, maybe per-header could be enough. But I guess Julian wanted
to ensure that interoperability is the least possibly impacted, which
probably starts by not mangling the header value before the semi-colon
for cases which already work and whose encoding is "implicit".

> of a header be KOIR8 and the next subfield be codepage 1251 ?

I think that's a legitimate question.

> than ISO-8859-1 or UTF-8 from 2015 forward ?

Idem. And if we don't need to do more than that, then probably we
just need a boolean to say "this is not ISO-8859-1, hence this is
UTF-8" and make the encoding implicit by the sole presence of the
encoding tag (eg: the "*" or "=", I don't remember right now).

Best regards,
Willy

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Tue, 31 Mar 2015 20:56:41 +0000

--------

>encoding tag (eg: the "*" or "=", I don't remember right now).

In that case I could live with it being per field, because the
signal could be a single character and we could probably
dispense with the % encoding too.

---

From: Amos Jeffries <[email-masked]>
Date: Wed, 01 Apr 2015 14:18:07 +1300

> encoding tag (eg: the "*" or "=", I don't remember right now).

That sound better to me.

Amos