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

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.

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

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