Confirm
298
edits
Changes
m
→Security Considerations
TLS intercepting proxies essentially man-in-the-middle connections made to them. With certificate-based domain validation, users simply install an exception corresponding to the certificate of the proxy, allowing it to be a root of trust. The same idea could be used here, but it would be cumbersome. The proxy would have a root DNSKEY trusted by users. Upon any connection, the proxy could create a chain of DNS records rooted by that key. The users would then verify that chain. This obviously does not work if the DNSSEC chain lookup is done out of band. Another option is to simply fall back on certificate-based validation (with an exception installed by users). Hopefully the proxy itself would verify the DNSSEC chain in its connection to the actual server.
If there is a mechanism for the client to say what keys have already been validated (thus decreasing the length of the chain a server must send), there may be privacy implications. For instance, if a only small number of sites have their DS records signed by a specific key from .com and the client indicates they have already validated that specific key, another server knows the client has visited one of those sites. There may be a way for a client to instead indicate they have all of the keys for a zone as of a certain time (i.e. "now"), thus eliminating a privacy leak.
== DNSSEC Libraries ==
