On Mon, 22 Jan 2018, Paul Hoffman wrote:
Greetings. This document is still listed as in WG Last Call, although I haven't
seen anything in the archive about that Last Call closing.
Yeah, the WGLC ended Nov 9. I have pinged the chairs a few times
already, and requested an early code point for INTERNAL_DNSSEC_TA.
(we already have one for INTERNAL_DNS_DOMAIN)
The document seems mostly fine, and it certainly seems like a useful IPsec
extension. I have only two concerns:
Thanks for the review!
- Section 5 says:
An initiator SHOULD ignore INTERNAL_DNS_DOMAIN attributes containing
domains that are designated Special Use Domain Names in [RFC6761],
such as "local", "localhost", "invalid", etc. Although it may
explicitly wish to support some Special Use Domain Names.
There is no way that an implementation can easily follow what is in the IANA registry for
Special Use Domain names. Further, given that that the names are going to be internal,
there isn't a good reason to prevent them from being used beyond the normal "don't
make up names that someone else might be using" argument. The second sentence
(fragment) doesn't give enough detail to help an implementer. I think that this whole
paragraph can be safely removed.
I think that's fair. Especially if there will be a .internal or
something, the advise could at best be "clients should be very
careful accepting certain special domains". I will removed the
paragraph.
- Section 6 says:
The content of INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA may be
passed to another (DNS) program for processing. The content MUST be
verified and sanitized before passing it to other software. For
example, domain names are limited to alphanumeric characters and the
minus ("-") and underscore ("_") symbol and if other other characters
are present, the entire payload could be ignored and not passed to
DNS software, or the malicious characters could be filtered out
before passing the payload to DNS software.
That is not correct. *Host* names are limited, but domain names are not. Domain
names can have any octet in them. This is a common misunderstanding in the DNS;
see RFC 7719 for definitions of DNS terms. I suggest that this paragraph be
changed to:
That somewhat contradicts 7719 in which document you state:
Note that any label in a
domain name can contain any octet value; hostnames are generally
considered to be domain names where every label follows the rules
in the "preferred name syntax"
So a hostname - if FQDN - could have a leftmost label with other stuff
in it, but everything to the right of the zone cut would have to be
compliant to the restrive set. And we were talking about domain names,
and not hostnames.
The content of INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA may be
passed to another (DNS) program for processing. Some DNS programs
only handle domain names in host name format, although many are
inconsistent about this.
I would prefer to keep the focus on the security part. If there are
weird characters, don't blindly pass those along. Whether something
is a legit hostname or domainname is not very relevant to the IKE
or IPsec layer. Whoever _receives_ the information can determine
that part. We are mostly concerned about passing foo`cat /etc/passswd`.com
So how about:
The content of INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA may be
passed to another (DNS) program for processing. The content MUST be
verified to not contain any malicious characters, before it is
passed to other programs for DNS processing. If it contains malicious
characters, the payload should be ignored or sanitized. Whether a
specific combination of non-malicious characters constitute a valid
DNS domain name is best left to be decided by the DNS software that
receives the contents of these payloads.
Paul
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
