Re: [TLS] A few comments on draft-ietf-tls-dnssec-chain-extension-02.txt

[Viktor Dukhovni <[e-mail]>]

> On Mar 22, 2017, at 10:56 AM, Melinda Shore <[e-mail]> wrote:
> 
> The draft could definitely benefit from
> additional review.

I find it ironic that section 4 includes:

   The components of the authentication chain are built by starting at
   the target record set and its corresponding RRSIG.  Then traversing
   the DNS tree upwards towards the trust anchor zone (normally the DNS
   root), for each zone cut, the DNSKEY and DS RRsets and their
   signatures are added.  If DNS responses messages contain any domain
   names utilizing name compression [RFC1035], then they must be
   uncompressed.

while at the same time there is ongoing discussion of *adding* compression
of the server certificate chain (as a TLS 1.3 extension).  Would the
compression of server certificates also cover compression of the DNSSEC
chain extension?  If so, perhaps this would be a belated moral victory
for DJB[1]. :-)

-- 
-- 
	Viktor.

[1] https://cr.yp.to/djbdns/notes.html

Compression

Compression DNS packets use an ad-hoc compression method in which
portions of domain names can sometimes be replaced with two-byte
pointers to previous domain names. The precise rule is that a name
can be compressed if it is a response owner name, the name in NS
data, the name in CNAME data, the name in PTR data, the name in MX
data, or one of the names in SOA data.

One problem with DNS compression is the amount of code required to
parse it. Reliably locating all these names takes quite a bit of
work that would otherwise have been unnecessary for a DNS cache.
LZ77 compression would have been much easier to implement.

Another problem with DNS compression is the amount of code required
to correctly generate it. (RFC 1035 allowed servers to not bother
compressing their responses; however, caches have to implement
compression, so that address lists from some well-known sites don't
burst the seams of a DNS UDP packet.) Not only does the compressor
need to figure out which names can be compressed, but it also needs
to keep track of compression targets earlier in the packet. RFC
1035 doesn't make clear exactly what targets are allowed. (Most
versions of BIND do not use pointers except to compressible names;
suffixes of the query name are excluded. dnscache uses pointers to
suffixes of the query name.)

Another problem with DNS compression is that it's not particularly
effective. LZ77 would have done a noticeably better job on current
data, and a much better job on new record types that might become
popular in the future. (BIND versions 4.9.* through 8.1.2 compress
names in new record types, such as RP and SRV, in blatant violation
of RFC 1035. The names are not decompressed by caches that do not
know about the new types. This is an interoperability disaster.)