Re: [IPsec] [Ext] Re: WG Last Call comments on draft-ietf-ipsecme-split-dns
On Jan 21, 2018, at 7:20 PM, Paul Wouters wrote: >> - 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" There is no contradiction between what I say above and that. > 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. Nonono. Nothing in the definition of domain name or hostname has anything to do with label position. > >> 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. If you're talking about domain names, there are no "weird characters": they are just blobs of octets. > 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 ...which is a valid domain name (assuming an ASCII or UTF-8 encoding for the octets). > > 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. > Unless you can define "malicious", I would disagree. In fact, unless you can define "character", you will also have a problem (some encodings of characters take up multiple octets). If you really want to go down this path, you must say something like "domain names where each label consist only of octets which map to the ASCII encoding of the following values: A to Z, a to z, 0 to 9, "-", and "_". --Paul Hoffman ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WG Last Call comments on draft-ietf-ipsecme-split-dns
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 IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] WG Last Call comments on draft-ietf-ipsecme-split-dns
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. The document seems mostly fine, and it certainly seems like a useful IPsec extension. I have only two concerns: - 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. - 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: 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. --Paul Hoffman ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec