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