Subject: [IPsec] draft-pauly-ipsecme-split-dns-01 discussion

From: Paul Wouters <[email-masked]>
Date: Tue, 26 Jul 2016 09:53:44 -0400 (EDT)

At the last IETF, we discussed draft-pauly-ipsecme-split-dns-01.

The authors had one question, related to whether we should use the
DNSKEY or DS record format for the INTERNAL_DNSSEC_TA CP payload.

I talked to the bind, knot and unbound people about this.

Bind cannot perform a runtime trust anchor reconfiguration via its rndc tool.
So you need to create trust anchor files to read in. These files use the
DNS presentation format and currently support only the DNSKEY format,
not the DS format. This makes sense because this is not a runtime
operation where you send the information of ( IP of nameserver, trust
anchor, domain name).

The unbound developers at the last IETF were not sure about the
capabilities of unbound-control. The man page lists that you can configure
trust anchors via DNSKEY or DS record. Running a test command via:

 	sudo unbound-control set_option trust-anchor: "<DS RECORD>"

with or without an unbound-control forward_add domain 1.2.3.4 (to a real
recursive nameserver) did not seem to properly pickup the trust anchor
and still returned data as insecure.

The knot developers weren't sure what was supported, but said they would
support whichever option we needed.

I did not yet test sysatemd-resolved.

It seems the software still needs work, so probably those vendors can
adapt based on our requirements. So I think we can pick the option we
prefer the most. In my opinion, that would be the DS record, because it
is not as bulkt as DNSKEY records.

A second discusion item that came up was the danger of using strings for
this option, where people could possibly put evil items in the string,
such as "IN DS `cat /etc/passwd`". If the DNS wire format is used,
this attack would be prevented. My issue with that is that I would still
need to convert the wire format to presentation format to present it to
the on-the-fly reconfiguration tools of the DNS server. So I don't see
much value in this additional conversion from a security point of view.

If I missed anything else from discussions at the last IETF, please let
me know. I think the important part was for more people to read the
draft and give us feedback, so we can move on with the draft. As Tommy
said, a standarized option for DNS handling is badly needed for IKEv2.

Paul

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 27 Jul 2016 18:11:40 +0300

[not wearing chair hat]

> is not as bulkt as DNSKEY records.

I think DS records are fine. They are smaller, which is always
benefit, and if software needs to be changed anyways, then I assume it
is no matter which we pick... 

> much value in this additional conversion from a security point of view.

I think we do need to add some kind of warning for implementors in the
security considerations section saying do not just put that string and
give it to the resolver, verify that it is in correct format before
giving it out.

I mean the textual representation have all kind of other things you
can do so you really want to make sure there is nothing extra in the
value. Perhaps even include regex to match that value does not have
anything extra or dangerous...

We also do not want to allow server to feed in any other ds records
than what it is supposed to serve, and we do not want allow it to feed
in any other records like "www.facebook.com. IN CNAME evil.com". 
-- 
[email-masked]

---

From: "Paul Hoffman" <[email-masked]>
Date: Sat, 30 Jul 2016 09:48:27 -0700

Greetings. I support the adoption of this draft as a WG document. I have 
a minor editorial quibble (it should be "split DNS" instead of 
"Split-DNS"), and would like a reference to RFC 2775, but those can be 
dealt with as the WG discusses the document.

--Paul Hoffman