On Tue, Jul 28, 2015 at 07:45:14PM -0400, Shumon Huque wrote:
> > The data will need to (and I expect will) fit into 16K so, it can
> > go into a TLS handshake message. To that end, and in any case,
> > the extension should I think support DNS name "compression", and
> > should be encouraged to do use it (the draft says otherwise at
> > present).
>
> Right, it says to uncompress the names right now. Name compression is
> defined in terms of pointers to offsets from the beginning of the DNS
> message. Since we don't currently use DNS messages, we'd have to redefine
> name compression to be something else, like an offset from the beginning of
> the chain data structure. That would probably be fine, but I wonder if it's
> really worth it. The size of the chain is likely going to be dominated not
> by domain names, but by all the DNSSEC signatures, which aren't very
> compressible.
Well, certainly the signature and DNSKEY fields don't compress very
well, but there are still lots of domain names floating around.
With ECC signature algorithms (which I hope will eventually be the
dominant algorithms in DNSSEC), the key and signature fields are
much smaller, making it possible for name compression to make a
non-trivial difference.
Also if the response is in DNS wire format, it becomes easier to
just punt the packet for verification to the local validating
resolver (jailed inside a captive portal and fed crumbs of useful
work to do by applications forwarding data from remote TLS servers).
With care the server's response might already be in the form of
the appropriate query (or possibly new DNS opcode), so that the
client can just copy it to 127.0.0.1:53 after a quick syntax check,
and wait for a response. That would be a much simpler approach
than compiling DNS logic into each and every application.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
