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 |
+---------------------------------------------------------------+
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
