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

[Tero Kivinen <[e-mail]>]

Paul Wouters writes:
> On Fri, 16 Nov 2018, Waltermire, David A. (Fed) wrote:
> 
> > One comment on your COMMENT wearing chair and shepherd hats:
> >
> >> We have to use DNS presentation format for the DS records and not wire
> >> format?
> >
> > The group was "split" on this question. We did a hum, with most
> > responding in the room that they either did not care or had a
> > slight preference for presentation format. This is why it is this
> > way. 
> 
> Note that we did not use humming as a vote. The humming gave an idea of
> the room that the disadvantage of IKE software needing to understand and
> convert wire to/from presentation format only to prevent "string
> overflow errors" was not worth the trouble of forcing a wire format,
> especially since IKE just relays this information to another
> application, and this API almost certainly uses presentation format
> (for example, unbound-control)

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.

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:

     INTERNAL_DNSSEC_TA(1270,8,1,"( 506AD3A656  ; comments
		D14D9246558 ; in file
		77628FFD6A98D7A847E ) ; more")

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]