On Tue, Jul 28, 2015 at 07:45:14PM -0400, Shumon Huque wrote: > In case others missed it, it's the following draft: > > https://tools.ietf.org/html/draft-shore-tls-dnssec-chain-extension-01
I had, yes. Thanks for the pointer. > Debate is going on about the precise format of the chain data. The draft > currently doesn't use DNS "messages", but rather wire format DNS RRs > wrapped in a bit of TLS presentation syntax, but we're discussing other > possibilities. If we were to use DNS messages, there is already a proposal > from Paul Wouters which we might also look into: I much prefer using DNS messages, yes. > https://tools.ietf.org/html/draft-ietf-dnsop-edns-chain-query-02 > > I've already stated my personal preference for a chain of wire format DNS > RRs that could be fed into existing DNS library functions, but I'd like to > come to a consensus that is acceptable to most of the likely implementers. A wire-format response could be fed to a library too. And to a validating resolver. The point is that the protocol to the local caching validating resolver *is* the API. That's because light-weight non-validating resolver libraries to speak to it are universally available. And because the local caching validating resolver is the best place to cache. (A caching validating resolver might find a lot of the signatures and validations thereof cached. The caching validating resolver may not want to cache stapled DNSSEC even if it's valid to avoid cache poisoning issues, but it could still pay to cache the validations.) Resolver libraries are nice, but mostly only for when one cannot ensure that there is a local caching validating resolver, or when one cannot trust it, or when one is building a local caching validator. > One concern we've heard is that some folks don't want to import a large DNS > library into their application that has a whole of bunch of unnecessary > code (e.g. all the DNS transport code). Exactly. See above. > > 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. And the public keys. > Another method of reducing the chain size we are considering is client side > caching of RR sets and server side omission of the same. Sure, you can omit keys and signatures nearer to the root. Nico -- _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
