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

[Paul Wouters <[e-mail]>]

On 2018-11-18 6:14 p.m., Tero Kivinen wrote:
> Actually the text in section 2.2 is confusing. It is claiming that
>     This attribute lists the corresponding internal DNSSEC
>     trust anchor in the DNS presentation format of a DS record as
>     specified in [RFC4034].
>
> The format we use for DS records is not presentation format, nor is it
> wire format.


That's correct. We used some strange compromise text :(


> In section 3.2 we see that we are using Wire format for DNSKEY Key
> Tag, DNSKEY Alg and Digest Type, but presentation format for Digest
> Data.
>
> I.e., we do split the DNSKEY Key Tag, DNSKEY Alg, and Digest type
> fields out from the presentation format and encode them as 16- and
> 8-bit integers in wire format, but then for the Digest Data, which in
> wire format would be just binary blob, we use Presentation format of
> the DS, i.e., hexadecimal with all kind of parenthesis, comments,
> escaping mechanisms and newlines.
>
> I myself would have been much more happy with wire format also for
> Digest Data, but authors wanted to allow things like:

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


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

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. And a 
security check could simply reject all characters outside [A-Za-z0-9\-_\.]*

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.


So I think we have two options:

1) Clarify the text that the DS RRtype data is not in either wire or 
presentation format.

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)


Paul






>
> 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         |
>     +---------------------------------------------------------------+