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

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

Hi Ted,

On 17-Jun-22 01:36, Ted Lemon wrote:
>>     The URI syntax specification[RFC3986 <https://www.ietf.org/archive/id/draft-ietf-6man-rfc6874bis-01.html#RFC3986>]states that URIs have a global scope, but that in some cases their interpretation depends on the end-user's context. URIs including a zone identifier are to be interpreted only in the context of the host at which they originate, since the zone identifier is of local significance only.
> 
> 
> Does this mean that when a browser loads a web page, and that web page contains IPv6 address literal URIs with zone identifiers, and the source of the web page was not the local host, the URIs are un-interpretable? That is, what does "at which they originate" mean?

Hmm. I think it needs to be more explicitly worded.

If I create an HTML document that includes

<a href="http://[fe80::2ea3:fdff:fea4:dde7%7]">Brian's CE router</a>

and I then open that document with my browser, I would be able to open my CE's web interface from that document. But if I send that document to you, the URL will appear valid but will be useless.

In fact, on any o/s that supports a default zone for link-local addresses, this works today (at least with FireFox):

<a href="http://[fe80::2ea3:fdff:fea4:dde7]">Brian's CE router (no zone)</a>

However, that won't do anything useful for you unless by chance such an address exists on your LAN.

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

> 
>>     The various use cases for the zone identifier syntax will cause it to be entered in a browser's input dialogue box.
> 
> 
> Do you mean "the zone identifier syntax is only expected to be entered in the browser's dialog box: there is no use case for such a URI appearing elsewhere?" Or at least "The various use cases for the zone identifier syntax all involve entering it in the browser's input dialogue box?" I feel very uncomfortable with "cause" in this sentence.

Yes, will rephrase.

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

I can, however, see use cases where embedding such a URL in a web page would actually be useful to a service technician, so I'm fairly sure that saying "don't do this" won't work.

> 
> Anyway, overall I think the document is good and the above are all nits, not reasons not to publish. So I support publishing the document. Thanks for doing the work!

Thanks,
    Brian