Re: Consensus call to include Display Strings in draft-ietf-httpbis-sfbis

[Poul-Henning Kamp <[e-mail]>]

--------
Roy T. Fielding writes:

> I think this would have been better in parts, namely

Agreed.

> My suggestion would be to limit the string to non-CNTRL
> ASCII and non-control valid UTF-8. We don't want to allow
> anything that would twist the feature to some other ends.
> [...]
> Note that I am not saying that we should consider normalization
> or any other weirdness specific to Unicode.

Each new version of UniCode adds new code points, and they decided
up front that UniCode sequences would not be versioned.

Instead they issued guidance, and I'm paraphrasing here: "If you
receive a code-point you dont recognize, assume the sender has a
new version of UniCode than you do and display something safe and
distinct."

I have also never seen a document where UniCode clearly and
definitive promise to never add further control characters.

So checking that you have "non-control valid UTF-8" is always going
to require a (moderately) up-to-date representation of which unicode
codepoints are valid and which of those are controls.

Why would we inflict that burden at the HTTP level ?

> We just need to stay within the confines of what has already
> been defined as valid and safe UTF-8.

Do you have a specific document in mind here ?

> In general, it is safer to send raw UTF-8 over the wire in HTTP
> than it is to send arbitrary pct-encoded octets, simply because
> pct-encoding is going to bypass most security checks long enough
> for the data to reach an applications where people do stupid
> things with strings that they assume contain something that is
> safe to display.

This is precisely why I think we should /never/ employ pct-encoding
in HTTP headers.

Given that HTTP is increasingly being treated as a transport protocol,
(not that I agree with that either,) I think it is a much safer
approach to handle UTF8 as opaque binary data at the HTTP level,
and transfer it as such, in sf-binary fields.

> Everything else is being
> actively targeted by pentesters and script kiddies, on every
> public server on the Internet, to the point where we have to
> block it within CDN configurations just to avoid overloading
> the origin servers.

100% agreement: The only thing DisplayString offers over sf-binary,
is increased risk.

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