Paul and Paul,

Thanks for the additional review and dialog. I am currently reviewing this 
document as the shepherd. It would be good to resolve these issues before 
moving the draft forward.

I will watch this thread for a resolution before submitting the shepherd 
writeup.

Thanks,
Dave

> -----Original Message-----
> From: IPsec [mailto:[email protected]] On Behalf Of Paul Hoffman
> Sent: Sunday, January 21, 2018 10:29 PM
> To: [email protected]
> Cc: [email protected]
> Subject: Re: [IPsec] [Ext] Re: WG Last Call comments on 
> draft-ietf-ipsecme-split-
> dns
> 
> On Jan 21, 2018, at 7:20 PM, Paul Wouters <[email protected]> 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
> [email protected]
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iet
> f.org%2Fmailman%2Flistinfo%2Fipsec&data=02%7C01%7Cdavid.waltermire%4
> 0nist.gov%7Ccb3cb4d514f64ba8e4d908d561484fb5%7C2ab5d82fd8fa4797a
> 93e054655c61dec%7C1%7C0%7C636521885562888149&sdata=rZ0CDHHaez
> tWhdhrNHtkvtMC0X%2F7EZonxF52J0vlLUM%3D&reserved=0

_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec

Reply via email to