On Wed, Jul 29, 2015 at 01:48:40AM +0000, Viktor Dukhovni wrote: > There are perhaps compelling reasons to serialize the multiple RRs > differently, but I think they really ought to be *compelling* to > trump the potential advantages of using the existing DNS format.
Right, because firstly the DNS message format is in widespread use (understatement of the month), and secondly because anyone wishing to use DNS to the loopback resolver as the validation API will appreciate not having to re-encode the thing, and thirdly because anyone trying to obtain a stapled DANE payload will appreciate being able to use DNS to the loopback resolver as the API for obtaining it. DNS is such a stable and universal protocol that it is an API. That's a huge benefit. > The tricky bit is what DNS opcode should be in the DNS header for > such a payload. Potentially, something new that constitutes a > request for validation of a set of RRsets (from the answer section) > via supporting RRSIG/DNSKEY/DS records (from the additional section). Whatever the stapler puts in, the relying party has to check/coerce the header to be as the loopback resolver will expect. There is no need to parse the rest of the stapled response, as the local resolver daemon ought to be secure and less-privileged than the relying party. > Nameserver implementors would then ideally support the new opcode, > allowing applications to defer most of the work to the *local* > (127.0.0.1, ::1) nameserver. Yes. > Client libraries would then just need to parse the validated answer, > to make sure that the CNAME chains are pertinent (not merely > authentic), and the TLSA records match the server certificates. And note: only the header and the answer section, since the signatures will have been validated and therefore of no further interest. Nico -- _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
