On Tue, Jul 28, 2015 at 04:03:12PM -0800, Melinda Shore wrote: > On 7/28/15 3:57 PM, Viktor Dukhovni wrote: > > See my follow-up message. I think you should reconsider. > > Nothing's cast in concrete, and your point about ECC signatures > is well-taken. We'll likely get a revision out by the end of > August. Because this is a TLS extension we'll be working with > the TLS working group, and it's not clear at this point what > sort of biases they'll have that are different from the > preferences of DNS experts.
Why should their biases be all that different from ours? A TLS implementor could want to implement a DNS resolver from scratch, but since they'll need to deal with DNS the protocol, why should stapling DNSSEC as a DNS response be difficult for them? Or a TLS implementor could want to use an off-the-shelf DNS implementation, in which case it wouldn't be hard to use a DNS response as the container for the stapled RRs. In the best case the TLS implementaor can just feed the response as-is (see previous posts), whereas with any other encoding there's no such best-case. Existing code would make a difference. I'm aware of AGL's stapled DNSSEC code, but that's one implementation -- it'd have to be a widely-used implementation to make that big a difference. More than that, I object to each protocol coming up with its own stapling format. Whatever is good for protocol X, ought to be good for protocol Y. A proliferation of DNSSEC stapling containers would only serve to make implementors sad. Nico -- _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
