Re: draft-montenegro-httpbis-uri-encoding

Hi, can you give a specific example? A real-world URL you want to
block, and how an adversary could circumvent it. The threat model may
be obvious to your industry, but not so much to the others.

On Mon, Mar 24, 2014 at 4:20 AM, Nicolas Mailhot
<nicolas.mailhot@laposte.net> wrote:
>
> Le Sam 22 mars 2014 00:30, Mark Nottingham a écrit :
>
>> In particular, this seems like something that needs to be coupled to
>> *where* the link originates; e.g., a browsers' behaviour for a link from
>> an address bar is likely to be different than that from an 'a' tag, and
>> even again different from a JavaScript-generated link.
>
> True.
> What last decade unicode migration taught us, is that once you allow text
> with undefined encoding in the pipeline, things are going to fail.
> Encoding really wants to be end-to-end.
>
> Still, this is little different from mime-types, where everyone relies on
> mime-type hints for things to work well, but servers and web clients
> sometimes have to infer them in less-than optimal ways to fill in the http
> headers. Asking for url encoding to be defined at the http level (with a
> fallback to a clear encoding default otherwise) is similar, with the
> detection pushed to servers and web clients, which will presumably push
> for better behaviour elsewhere to avoid being saddled with the heuristics
> currently pushed on network nodes.
>
> I'll add that we are living in an insecure world right now, that to
> mitigate security problems everyone has been adding blacklists of
> known-bad urls (from browsers to java to adobe reader to various security
> extensions) but those blacklists rely on someone being able to review and
> curate them. Which is obviously is a problem when you start to accept URLs
> you're not able to decode or display in any reasonable manner.
>
> Regards,
>
> --
> Nicolas Mailhot
>

Received on Monday, 24 March 2014 15:06:39 UTC