Re: [IPsec] Benjamin Kaduk's Yes on draft-ietf-ipsecme-split-dns-14: (with COMMENT)

[Paul Wouters <[e-mail]>]

On Tue, 20 Nov 2018, Tero Kivinen wrote:

> Yes, as I have seen so many times that people pass strings for
> configuration directly from the remote end to the configuration file,
> either because of it is easy, or by accident (shellshock, all kind of
> CGI issues etc).

That's why we have the Security Considerations:

    The content of INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA may be
    passed to another (DNS) program for processing.  As with any network
    input, the content SHOULD be considered untrusted and handled
    accordingly.

> Using wireformat and forcing IKE library to do one line of code to
> convert wireformat to restricted presentation format removes that kind
> of issues:

Sure, but it would add two conversions that shouldn't be needed at all.

> On the other hand generating the wire format from the values coming
> from configuration is similarly very easy (provided it comes from
> normal config file not from dns configuration file):

Most likely, when automating this, it would be coming from live DNS
output, eg the dig command. And not some new config file syntax for
this. If I wouldnt use files as in my previous email's example, I
would still want to be able to configure it like:

 	modecfgdns-ds="example.com. IN DS 12345 8 1 BLOB"

But pointing to a file with just DNS RRTYPEs is much easier, especially
if you have 20 internal domains, as most universities seem to have :P
Then you don't have to have duplicate keywords and/or ordening issues,
and you wouldn't have large blobs in your config file. It is just much
easier to create and maintain this in dig command output, so DNS
presentation format.

> Presentation format includes things like comments, newlines,
> whitespace etc.

> That is the reason I do not like to have presentation format inside
> the binary wire formats like IKE. We do not need to do string parsing,
> or regex processing in IKE library, but to properly parse presentation
> format you need to do that.

I think you can do this without regexp Tero :)

> going to be in the presentation format. I think most people do use
> configuration formats like:
>
> modecfgdns1=1.2.3.4
> modecfgdns2=8.8.8.8
> modecfgdomain1=example.com
> modecfgtadnsseckeytag1=1270
> modecfgtadnssecalg1=8
> modecfgtadigesttype1=1
> modecfgtadigestdata1=506AD3A656...

This would be terrible to generate from live DNS output. Much harder
than "dig ds example.com @internalDNS > dns.txt"

> Yes. This is needed. I would actually also would like to have text
> explaining can you have comments whitespace, newlines etc inside the
> Digest Data or not too, while we are at it. I would expect that most
> of the implementations would not necessarely like those and sending
> those over the wire is just wasting bytes.

I'm confused what you are suggesting here. You say it should support the
crazy stuff but then suggest implementations will just not support the
crazy stuff?

>>> and so on, instead of:
>>>
>>>       INTERNAL_DNSSEC_TA(1270,8,1,0x506AD3A656D14D924655877628FFD6A98D7A847E)

It would be:

        INTERNAL_DNSSEC_TA("1270 8 1 0x506AD3A656D14D924655877628FFD6A98D7A847E")

Note that here the domain name is not even part of the data. If you were
sending presentation format, it would be nicer:

        INTERNAL_DNSSEC_TA("example.com. IN DS 1270 8 1 0x506AD3A656D14D924655877628FFD6A98D7A847E")

And there would be no ordering constraints for INTERNAL_DNSSEC_TA()
needing to immediately follow INTERNAL_DOMAIN()

Paul