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

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?

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.

> 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.

> 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, 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/ is or isn't radioactive? Works fine on my browser.

Regards
    Brian
  
> I am not saying this to argue. It is something in RFC3986 that cannot be
> changed, even by the editor, in the same way that we can't change the
> bit layout of IPv4 when that RFC is updated.
> 
> ....Roy
> 
_______________________________________________
art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/art