On Thu, Feb 13, 2025 at 11:44 AM Brian E Carpenter <brian.e.carpenter@xxxxxxxxx> wrote:
Hi Tero, thanks for the review.
On 14-Feb-25 01:03, Tero Kivinen via Datatracker wrote:
> Reviewer: Tero Kivinen
> Review result: Has Issues
>
> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the
> IESG. These comments were written primarily for the benefit of the
> security area directors. Document editors and WG chairs should treat
> these comments just like any other last call comments.
>
> This document specifies how the zone identifiers should be used in
> textual format, but leaves the use in web browsers out of scope.
> There is another (now expired) document that explains how to use
> zone identifiers in uri context. I think the term used:
>
> Because of this, the recommendations and normative statements in this
> document do not apply to web browsers.
>
> is misleading as lots of configuration happens in the web browsers, but
> not in the context of uri. I.e., I would assume this document to apply
> when you configure a network switch over https, and enter zone identifiers
> in the web page form.
Thanks, that's a subtle point. We will find a way to cover it.
Possibly just "... do not apply to URIs in web browsers."
Or perhaps "... do not apply to URIs fetched by web browsers."
(Fetch is a term of art for browser networking [1])
David
> Also this document uses IPv4 addresses which are not from the block
> reserved for examples.
The only one I can see is in the sentence:
>>> For example, a typical home router may today be configured via "192.168.178.1" but not via "fe80::1%eth0"
which only makes sense by using an RFC 1918 address, so I think
we have no choice. We could use 10.1.1.1, which is a bit more
obvious.
>
> Security considerations do list typical issues but one of the issues
> with zone identifiers is that the set of characters it can use is
> not defined, thus web-form, etc might have difficulties to remove
> unsafe characters. For example entering zone identifiers of
> "fe80::1%`echo string > /etc/config`" might allow users to cause
> unauthorized changes to the system without proper authentication.
>
> On the other hand just automatically limiting zone identifiers
> to ascii letters and numbers does not work, as they may contain
> some special characters like "." or "-".
That's true, and in any case RFC 4007 does not restrict the character
set in any way, so if we add any restriction here it might break
some existing implementations. I'm not sure that there is anything
useful we can write here. Do you have any suggestions?
Regards
Brian
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
