Re: WG Last Call for for draft-ietf-6man-rfc6874bis

[Brian E Carpenter <[e-mail]>]

Thanks Ted. We definitely need to clarify the text, after the WG last call expires.

Regards
    Brian

On 18-Jun-22 02:27, Ted Lemon wrote:
> On Thu, Jun 16, 2022 at 10:55 PM Brian E Carpenter <[e-mail] <mailto:[e-mail]>> wrote:
> 
>     On 17-Jun-22 01:36, Ted Lemon wrote:
>      >>     It is desirable for all URI parsers to recognise a zone identifier according to the syntax defined inSection 3 <https://www.ietf.org/archive/id/draft-ietf-6man-rfc6874bis-01.html#spec <https://www.ietf.org/archive/id/draft-ietf-6man-rfc6874bis-01.html#spec>>. Any code handling percent-encoding or percent-decoding must be aware that the "%" character preceding the zone identifier is never itself percent-encoded, as specified by ABNF above. In terms of Section 2.4 of[RFC3986 <https://www.ietf.org/archive/id/draft-ietf-6man-rfc6874bis-01.html#RFC3986 <https://www.ietf.org/archive/id/draft-ietf-6man-rfc6874bis-01.html#RFC3986>>], this "%" character is acting as a delimiter, not as data.
>      >
>      >
>      > Would it be correct to say that the text within an IPv6 address literal never contains percent-encodings? If so, then it might be less complicated to just say that. I think a parser that follows this rule would be more regular than one that doesn't make this restriction and does allow percent encoding within the literal except in the case of the stated exception.
> 
>     That's what the proposed ABNF is supposed to say. We should clarify the text a bit more.
> 
> 
> I think the reason I didn't see this when reviewing is that the ABNF for the address literals is not present in the update. So yeah, a note saying that this is the case might be helpful, although I agree that the ABNF does actually address this problem, if you combine the two documents as intended.
> 
>      > In the security considerations section, I think if the syntax were only allowed in the case of input into the browser's dialog box, then most of the possible attacks would go away. If there is no anticipated use case other than manual input (perhaps a scripted input would also count) then unless the script would be allowed to open the URI but not otherwise probe IPv6 address literals, it's hard to see what additional vulnerability this would create.
> 
>     I still have to review Phillip Tiesel's comment carefully, but if there is a real exploit, I'm pretty sure it would have to be Javascript, trying to find other devices on the LAN. I'm not sure why that would be more interesting than trying to find other devices with routeable IPv6 addresses in the same prefix, which is feasible today (and the reason why we recommend pseudo-random interface IDs). And at least on a Windows target, you don't need a Zone ID, so you could do it today. But the search space is still 2^64 in all cases. That's our primary defence against such attacks.
> 
> 
> Ah, I think you've made the key point here:
> 
>       I'm not sure why that would be more interesting than trying to find other devices with routeable IPv6 addresses in the same prefix, which is feasible today (and the reason why we recommend pseudo-random interface IDs).
> 
> 
> I think you should say this explicitly in the security considerations. I suppose there is one small difference between probing for a GUA and probing for a LLA: you know what the prefix of the LLA is going to be. So /that/ is the new "vulnerability" that this document potentially creates, although as you say I think exhausting that number space from a Javascript program would be ... difficult...