On Tue, Jul 28, 2015 at 07:17:05PM +0000, Viktor Dukhovni wrote: > On Tue, Jul 28, 2015 at 01:11:31PM -0500, Nico Williams wrote: > > > My proposal for stapling DNSSEC/DANE is as follows: > > > > - Use a DNS response whose answer is the TLSA RRset and whose > > additional section contains all the DNSSEC RRsets needed to validate > > the answer, chaining all the way to ., of course. > > Except that multiple answer RRs might need validation when there > are CNAMEs from the original domain to the TLSA base domain, and > possible CNAMEs from the prefixed (_port._prot) TLSA base domain > to the ultimate TLSA record. > > All the CNAME records need to be validated, not just the final > TLSA RRset.
Sure. The CNAMEs should be in the answer section too, no? Though it'd be OK if they were in the additional section. The point is that all of them have to be in there. An alternative would be to have multiple DNS responses, one for each CNAME and one for the TLSA RRset. The latter might be necessary if 64KB is not enough to store the entire stapling. Thoughts? > > Validating them requires a library, but ideally we could define a > > protocol to speak to caching validating resolvers for validating stapled > > DNSSEC, my proposal for which is: > > > > - Send the stapled DNSSEC response as a query that the caching > > validating resolver must then respond to with an error if it does not > > validate, or with an answer that contains just the answer RRset > > (which must match the query). > > > > Caching validating resolvers would be allowed to also ignore the > > answer and additional RRs in the query and instead answer the > > question as usual. Clients would have to check the response to make > > sure they got the same TLSA RRset as stapled. > > > > Obviously this would work for RRs other than TLSA. > > The protocol would have to return AD=1 and all the RRs from the > query in the answer section. Yes. _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
