On Wed, Mar 22, 2017 at 4:50 PM, Viktor Dukhovni <ietf-d...@dukhovni.org> wrote:
> > > On Mar 22, 2017, at 10:56 AM, Melinda Shore < > melinda.sh...@nomountain.net> 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]. :-) > I think the reason for the last sentence quoted above is that DNS name compression is defined in terms of an offset from the beginning of the DNS message, and the draft as currently written uses a sequence of RRsets rather than a complete DNS message. I sympathesize with djb's critique. If DNS wasn't designed in the early 80's then perhaps we would have had something different. I supposed we could redefine name compression for this draft to use an offset from the beginning of the chain data. Does the proposed compression of certificate chains include extensions in the Certificate message also? If so, the DNSSEC chain extension would automatically be covered. Generally speaking, I would not be opposed to compressing the DNSSEC chain extension with a normal compression algorithm. Perhaps some empirical measurements might be useful to determine whether it yields significant enough savings. Large parts of the dnssec chain (signatures and keys) probably aren't terribly compressible, although I guess the same issue exists for certificate chains, and if it's worth it for the latter .. -- Shumon Huque
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
