On Fri, Jun 10, 2016 at 11:46 PM, Paul Wouters <[email protected]> wrote:
> That assumes DNS lookups are for TLS......
>
I'm not sure I follow you Paul. This should work for any recursive
to authority communication where TLS and DANE is available. To
quickly sketch out what I was thinking (this is off the cuff and likely
needs refinements/corrections; feel free to poke holes if you find
any) ...
Resolver signals dnssec_chain support in TLS handshake with a
TLS equipped authoritative server. If server response provides the
dnssec_chain, then perform DANE authentication of the server. Otherwise,
authenticate the server in some other way (public CA system, static
pre-configuration, or if allowed, just resort to unauthenticated TLS).
Note: in this scheme, the TLSA record is associated with the zone name,
not the NS record name, because a DNSSEC secured referral authenticates
the zone name (not NS names provided in referral data). This means
sharing a TLSA record set across all nameservers for a zone, but not
necessarily TLS server credentials. The TLSA RRset could identify
multiple distinct certificates or keys, if zone operators wanted
compartmentalization of TLS credentials across servers (which might
be important if multiple organizations are involved in running the
servers).
(It may be possible to securely authenticate DANE records at the NS
names instead - but I haven't thought through that case yet. The zone
name method seems simpler.)
res-> .
connect with TLS
verify DANE auth chain for _853._tcp. TLSA
authenticate server cert, pubkey, or raw pubkey
query: www.example.org. A
response: signed referral to org.
res->com.
connect with TLS
verify DANE auth chain for _853._tcp.org. TLSA
authenticate server cert, pubkey, or raw pubkey
query: www.example.org. A
response: signed referral to example.org.
res->example.com.
connect with TLS
verify DANE auth chain for _853._tcp.example.org. TLSA
authenticate server cert, pubkey, or raw pubkey
query: www.example.org. A
response: answer: www.example.org. A 1.2.3.4
DANE can be used selectively where available in this scheme. e.g. If
the root servers don't do DANE (or TLS), the resolver obtaining a
secure delegation could follow referrals and then attempt DANE
authentication with the delegated zones, etc.
A possible objection to using the TLS extension is that authoritative
servers now have to do additional work querying for and maintaining
the chain for their own DANE record. But that's small potatoes compared
to the aggregate work of doing TLS.
I'm not advocating this approach at this stage. Just sketching out a way
that DANE might be used to provide authenticated TLS between resolver
and authority servers. And obviously, other modes of authentication will
need to be supported as well in the general case, because DNSSEC is
not universally deployed.
--
Shumon Huque
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
