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

[Tero Kivinen <[e-mail]>]

Paul Wouters writes:
> The authors would have been happy with full presentation format for
> both :) 
> 
> You were the one that raised an issue that strings would be passed 
> carelessly and could be abused by peer's to try and get a shell :P

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).

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

printf("DS %d %d %d %s\n", unpack("nCCH*", $cfg_payload));

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):

$cfg_payload = pack("nCCH*", $dnskey_key_tag, $dnskey_alg,
	            $digest_type, $digest_data_in_hex);


On the other hand parsing presentation format is much harder issue... 

> >
> >       INTERNAL_DNSSEC_TA(1270,8,1,"( 506AD3A656  ; comments
> > 		D14D9246558 ; in file
> > 		77628FFD6A98D7A847E ) ; more")
> 
> I don't remember that I wanted to have comments. If I did, I certainly 
> don't care now and I would be happy to move everything back to 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 would not want to use wireformat anywhere, because as I argued in the 
> past, the IKE daemon is just passing on this information and for it to 
> need to convert its DNS configuration, which is guaranteed to be in DNS 
> presentation format, it would need to copy some DNS conversion code or 
> link against some DNS library to convert it to wire format.

I do not see any reason why the incoming configuration from IKE is
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...

or pseudo presentation format (which really isn't presentation format
as it does not allow comments or newlines inside () etc).

modecfgta1=1270 8 1 506AD3A656...
    
> And a security check could simply reject all characters outside
> [A-Za-z0-9\-_\.]*

For presentation format that is not enough (for example it does not
git rid of comments or newlines and paranthesis), and even then it is
wrong is it does not allow any whitespace. For pseudo simplified
presentation format it is too much, as it allows dash, underline, and
period which are not needed...

> On the other end, passing the DNS information from IKE daemon to the 
> system is most likely happening over a DNS presentation API as well, as 
> all API's supporting commandline configurations cannot take DNS wire 
> format but take DNS presentation format.

As I said converting wire format to simplified presentation format
(which is still valid presentation format) is trivial. 

> So I think we have two options:
> 
> 1) Clarify the text that the DS RRtype data is not in either wire or 
> presentation format.

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. 

> 2) Change the DS RRtype data to also be fully DNS presentation format.
> 
> 
> I have a preference for 2) but I guess the working group in the past 
> reached consensus on 1)
> 
> > Which is then encoded as:
> >
> >                         1                   2                   3
> >     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> >     +-+-----------------------------+-------------------------------+
> >     |R|   Attribute Type 0x19       |      Length 0x48              |
> >     +-+-----------------------------+---------------+---------------+
> >     | DNSKEY Key Tag 0x04  0xf6     |DNSKEY Alg 0x8 |Digest Type 0x1|
> >     +-------------------------------+---------------+---------------+
> >     |  0x28 "("        0x20 " "        0x35 "5"        0x30 "0"     |
> >     |  0x36 "6"        0x41 "A"        0x44 "D"        0x33 "3"     |
> >     |  0x41 "A"        0x36 "6"        0x35 "5"        0x36 "6"     |
> >     |  0x20 " "        0x20 " "        0x2B ";"        0x20 " "     |
> >     |  0x63 "c"        0x6f "o"        0x6d "m"        0x6d "m"     |
> >     |  0x65 "e"        0x6e "n"        0x74 "t"        0x73 "s"     |
> >     |  0x0a "\n"       0x09 "\t"       0x09 "\t"       0x44 "D"     |
> >     |  0x31 "1"        0x34 "4"        0x44 "D"        0x39 "9"     |
> >     |              ...                                              |
> >     +---------------------------------------------------------------+
> >
> > and so on, instead of:
> >
> >       INTERNAL_DNSSEC_TA(1270,8,1,0x506AD3A656D14D924655877628FFD6A98D7A847E)
> >
> > with DS wire format encoding for Digest Data would result following
> > attribute:
> >
> >                         1                   2                   3
> >     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> >     +-+-----------------------------+-------------------------------+
> >     |R|   Attribute Type 0x19       |      Length 0x1c              |
> >     +-+-----------------------------+---------------+---------------+
> >     | DNSKEY Key Tag 0x04  0xf6     |DNSKEY Alg 0x8 |Digest Type 0x1|
> >     +-------------------------------+---------------+---------------+
> >     |  0x50            0x6a            0xd3            0xa6         |
> >     |  0x56            0xd1            0x4d            0x92         |
> >     |  0x46            0x55            0x87            0x76         |
> >     |  0x28            0xff            0xd6            0xa9         |
> >     |  0x8d            0x7a            0x84            0x7e         |
> >     +---------------------------------------------------------------+
-- 
[e-mail]