On Tue, Jul 28, 2015 at 05:26:16PM -0800, Melinda Shore wrote:
> On 7/28/15 4:35 PM, Viktor Dukhovni wrote:
> > This is based in part on the architectural assumption that in many
> > cases the right way to process it on the client side will be a
> > hand-off a local DNS service.
>
> I think the primary concern about that is the possibility
> of introducing additional latency, given that we're trying
> to minimize the DANE performance hit on clients like browsers,
> who tend to be extremely sensitive to delay.
I expect that the latecy to reach 127.0.0.1 is quite low. And will
only be incurred intermittently (client-side validated TLSA RRset
cache). When I say "local DNS service", I really mean *local*.
> But in either case, whether we're using a resolver
> in a DNS library or handing it off to a service, encoding
> the records in DNS wire format is going to be easiest for
> implementers. Several people have talked about writing
> their own bare-bones resolver that does not use an entire
> DNS library but I don't have any sense that that's going
> to be a common case. It's worth talking to people working
> with highly constrained devices in any event.
The question is not only whether individual RRs are in wire format
(which we already agree on), but whether the entire payload is a
DNS packet with all the usual headers and sections. At present
the draft departs from that format, and there is some merit in
considering whether that's wise.
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.
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).
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.
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.
Support for this should ultimately (or immediately) migrate from
application code to TLS toolkit code, with the application asking
the TLS library to enable DANE stapling support as appropriate.
(Some applications, not suffering from last-mile problems, will
simply perform their own DNS lookups, often against the same
127.0.0.1 nameserver that is not locked up in a captive portal).
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
