TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

DNSSEC: Complexities and Considerations

33 点作者 fcambus超过 10 年前

3 条评论

tptacek超过 10 年前
DNSSEC suffers from the zone exposure problem because its design was, for many intents and purposes, nailed down in the 1990s based on assumptions about cryptography from the 1990s. Specifically:<p>* DNSSEC was designed to assume that keys would be kept offline, because online signatures were thought not to be performant enough†.<p>* DNSSEC was designed to provide authenticated denial, because it was designed during a time when support protocol maintainers believed they needed built-in countermeasures for high-level DOS attacks.<p>The assumption behind these design goals are both dubious, but particularly noxious when combined.<p>There is more wrong with DNSSEC than NSEC3, for whatever it&#x27;s worth; for instance, start with the fact that it&#x27;s based on RSA PKCS1v15; until recently (last time I checked, within the last 18 months), the <i>root</i> of the hierarchy used 1024 bit keys.<p>These are, of course, technical issues. There&#x27;s a fundamental Internet design problem with DNSSEC, too, which is that the roots of the DNS hierarchy are overwhelmingly controlled by world governments. DNSSEC is, at bottom, a centralized PKI dominated by the US Government.<p>But don&#x27;t worry, this is only what DNS advocates want you to store your TLS keys in.<p>The entire security model for the Internet has been tuned for the last 15 years <i>not to assume the DNS was secure</i>. DNSSEC does not in any meaningful way exist today. If your most important adversary is the kind of online criminal that might employ DNS redirection to steal your credit cards, the risk&#x2F;reward for DNSSEC might arguably make sense (I think you&#x27;d lose that argument, though). If your most important adversary is GCHQ and NSA, then the Internet is far more threatened by the deployment of DNSSEC than it is by DNSSEC&#x27;s absence.<p>† <i>(this believe has since been retconned into a belief that keeping keys online is &quot;insecure&quot;, which is Rosencrantz and Guildernstern-style amusing given that DNSSEC controls only hostname mappings and that virtually every other system that protects</i> content <i>does keep keys online)</i>
评论 #8565082 未加载
评论 #8565671 未加载
评论 #8565080 未加载
Panino超过 10 年前
Design by committee generally leads to poor results. A much better approach is the competition method, where e.g. the public is asked for proposals to secure DNS as in the AES, eSTREAM, PHC, and CAESAR competitions.<p>DNSSEC was not &quot;design by committee&quot; -- it was &quot;design by multiple committees, all stuck in the 1990s.&quot; And this is what we get.<p>Personally I say: DNSCurve &gt; DNS &gt; DNSSEC. I would support a DNS security competition, even if DNSCurve (which I&#x27;ve deployed) were not selected. DNSSEC wouldn&#x27;t stand a chance in a public competition.
rdl超过 10 年前
I&#x27;ve been pretty down on DNSSEC due to the &quot;baroque&quot; nature of the whole thing (which this blog post shows); also, giving extra power to country-level ccTLDs vs. the slightly-more-independent SSL&#x2F;x509 CAs.<p>However, DANE makes DNSSEC make sense in some cases, especially when you start using it for things other than web traffic. DNSSEC&#x2F;DANE for STARTTLS SMTP would be a good improvement over the &quot;no cert checking at all, and even cert failures are ignored&quot; model today.