Re: [IPsec] [Ext] Re: WG Last Call comments on draft-ietf-ipsecme-split-dns

[Paul Hoffman]

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

[Paul Wouters]

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

[Paul Hoffman]

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