Re: [IPv6] [Last-Call] Artart last call review of draft-ietf-6man-rfc6874bis-02

> On Mar 27, 2023, at 1:10 PM, Brian E Carpenter <[email protected]> wrote:
> 
> Roy,
> On 28-Mar-23 07:26, Roy T. Fielding wrote:
>> On Mar 26, 2023, at 7:33 PM, Brian E Carpenter <[email protected]> wrote:
>>> On 27-Mar-23 14:37, Rob Sayre wrote:
>>>> On Sun, Mar 26, 2023 at 6:31 PM Brian E Carpenter <[email protected] <mailto:[email protected]>> wrote:
>>>>    I 100% fail to understand what you mean.
>>>>    http://[fe80::abcd-eth0] won't parse today any better than http://[fe80::abcd%eth0]. Neither of them respects the current grammar. Whatever we do here extends the grammar.
>> The difference is that % is only allowed within a pct-encoding and that
>> is heavily enforced at all layers, including those that don't parse the URI,
>> because it can be used for vulnerability probing/exploitation.
> 
> Let me see if I can paraphrase that. It seems that you are saying that even if the strict ABNF grammar permits a bare % all (or at least many) implementations will still not allow it?

Yes. It's because of double-encoding issues, like %%30%61, and a variety of other
spoofing attacks on UI.

Note that the primary blocking points are CDNs, origin servers, and WAFs.
It's not that they do URI parsing with a different ABNF -- they are doing
string scans for invalid character sequences in untrusted input.  Some are
even doing bayesian scans based on prior attack examples, which isn't
the least bit interested in ABNF.

Authoring tools will sometimes enforce ABNF, but I don't think that is something
you would worry about for this use case.

> I'm at a loss to understand the vunerability, though. The proposal is that exactly one bare % is allowed but only within the [ ] pair. There is no requirement for percent-encoding within the [ ] pair otherwise. If percent-encoding was supported there, something like http://[fe80::abc%64] would work today. But percent-encoding is not supported there, because no version of the syntax says it is.

Yes, even though it might have been convenient to allow UTF-8 encoded hostnames
using pct-encoding, they are not allowed by the ABNF (on purpose, by WG decision).

But actual implementations vary in where, or at what point, they show that as an
error, or even attempt to work around them by replacing %xx with UTF-8 or
punycode. [E.g., the location bar in a browser is not a URI -- it's a UTF-8 search
string, and 3986 doesn't apply to it until the sausage gets sent on the wire.
The same is true of links in email -- how your client decides that a given string
is a reference instead of plain text is an art, undefined by any standard.]

Hence, we don't want to give permission for one RFC to start adding something
that looks like a pct-encoding in the host, as an update to 3986, because we
already explored that space as a WG and backed away in horror. URI is
supposed to be the gold standard -- like the postal system's standard for
addressing. It is specifically limited to what is known to work everywhere.

It doesn't even matter how specific the suggested syntax is to a part of the
IPv6 literal, since folks around here learn by example and have a bad habit
of picking the worst examples for their next project. It's a slippery slope.

>> There is literally no way forward in which % enters the URI grammar in any
>> other form, ever, particularly in a way that is indistinguishable from an attack.
> 
> In what way can http://[fe80::abcd%rubbish] be construed as an attack when http://[fe80::abcd-rubbish] would not be? I'm truly unable to see the problem here.

Because -rubbish is entirely innocuous, whereas %0arubbish is a known attack,
as is any %xx where xx might coincide with some octet of a nasty unicode
character that isn't expected here. Because it gets extracted from the URI and
stuck in a header field decoded. Or because it bypasses some regular expression
check inside a mod_rewrite or a WAF.

>> It's equivalent to handing out megaphones at an opera while requesting
>> patrons not to use them except for emergencies. We don't do that.
>> We have had this discussion before. The answer hasn't changed. I don't care
>> what other RFCs decided to use % as a delimiter. Update them. I don't care how
>> much easier it makes copy/pasting -- change the other RFC. I don't even care
>> if IPv6 as a whole gets flushed down the proverbial toilet just because you can't
>> do local addressing using an obviously forbidden character. They made a bad
>> decision, one that could have been fixed immediately after publication, but
>> chose instead to suggest that the rest of the world change for them. Too bad.
>> Choose a different delimiter (or no delimiter at all if that is self-evident from
>> the IPv6 literal length). 
> 
> We need a delimiter because fe80::abc and fe80::abcd are both valid addresses. But do I understand that your objection vanishes if we accepted the inconvenience of switching to "-"?

Yes. I don't have an opinion on the Mozilla question about the use case in general.
Martin is usually right about those things.

>> Yes, it is still a change to the URI grammar, but a
>> coherent change that does not reach across all layers of the stack to unilaterally
>> switch a detected vulnerability into a feature request. It's a contained evolution,
>> whereas using % something something inside the host portion of a URI
>> is known to be highly radioactive.
> 
> To be clear, https://%77ww.ietf.org/ <https://www.ietf.org/> is or isn't radioactive? Works fine on my browser.

My Mail app rewrites that as a link to www.
The macos context menu thinks it is a link to 77ww (it ignores the %).
Pasting it to Firefox and Safari will translate %77ww to www before making
the request. Chrome will remove the cname entirely and go to ietf.org <http://ietf.org/>.

To see the blocks in action, you have to send the request in HTTP to a large
site or CDN using gateways internally. They change over time.

....Roy

_______________________________________________
art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/art