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

Hi, firstly, this is a subtle and unpleasant problem.

Roy's point is really right, but I think there might be some room when the
"%" (terrible choice) appears between two square brackets.

It's going to break stuff, though. GMail doesn't even work. So his point,
and mine, about it breaking the grammar is right.

---

[image: Screenshot 2023-03-27 at 1.12.07 PM.png]


---

The other problem is that there are actually a bunch of programs using this
busted syntax. So, it's not right to say it doesn't work. But Roy's point
is right, imho, and we should change IPv6 literal. Here, I'm only trying to
make the choice clear, not decide.

thanks,
Rob


On Mon, Mar 27, 2023 at 1:11 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?
>
> 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
>

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