On Fri, Jun 10, 2016 at 10:03 AM, Paul Wouters <[email protected]> wrote:
> On Fri, 10 Jun 2016, Stephane Bortzmeyer wrote: > > * publishing keys in the DNS, secured with DNSSEC (as in DANE), which >> raises an interesting bootstrap problem, >> > > Ohhh I forgot about that. I should have coffee before making up crypto > schemes (and before I suggest adding a new DS key type :) One possible way of addressing the chicken-and-egg problem is for the DNS/TLS authoritative server to employ the proposed TLS DNSSEC chain extension to deliver its DANE record chain during the TLS handshake. This has already been proposed for the stub-recursive case. See section 9.2.2 of https://tools.ietf.org/html/draft-ietf-dprive-dtls-and-tls-profiles > For recursive's that is a little harder because the reverse tree is > not so useful. While validating dns.google.com is easy, there can > easilly be a evil.com certificate that also references 8.8.8.8. For the stub to recursive case, the current authentication profiles draft assumes that the stub is preconfigured with the hostname (or service name) of the recursive server. So no reverse DNS entries are involved. -- Shumon Huque
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
