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.
> 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.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
