On Sun, Dec 1, 2013 at 7:09 PM, David Conrad <drc(_at_)virtualized(_dot_)org>
wrote:
Phillip,
On Nov 30, 2013, at 11:08 AM, Phillip Hallam-Baker
<hallam(_at_)gmail(_dot_)com>
wrote:
As I'm sure you're aware, for this attack to work, not only would the US
government need to compromise the root KSK HSMs and a rather Byzantine set
of safeguards, they would also presumably need to do so in a way that would
reduce the likelihood that the compromised elements would be noticed.
You clearly do not understand the nature of those controls.
And you clearly did not understand the point of my message. To (re)state
the obvious: the controls put in place were an attempt to alleviate
concerns expressed by the Internet (well, primarily the DNS knowledgable)
community about whether ICANN's handling of the root KSK was trustworthy
given the set of assumptions and constraints the root management partners
(ICANN, Verisign, and NTIA) were placed under both by the Internet
community at large but also the US Dept. of Commerce, NTIA (since signing
the root was seen as part of the IANA functions contract). I agree that
base assumptions under which the controls were created have changed and as
such, the DPS and the practices implemented under it should be reviewed and
likely revised
The reason that I said you have no idea what you are talking about is that
you describe these processes as if they are unique to the ICANN root rather
than being general practice for management of offline roots in general.
These processes were in use in commercial PKI before the first DNSSEC draft
was written over twenty years ago. And before that they were in use at the
NSA. They are designed to impress clients (or Congressmen) as much as
provide security.
What you do not appear to grasp is that the processes for online roots are
necessarily different as these have to be used at regular intervals. While
it might be practical to sign the DNS root zone offline, it certainly is
not practical to sign .com or any other TLD of consequence offline (except
possibly .gov).
What I was arguing against was waving "NSL" around as a totem. NSLs aren't
an attack, they're a way of hiding the attack. I'm suggesting that it is
more useful to identify attacks and address the vulnerabilities that lead
to those attacks.
Actually they are both since it is claimed that an NSL has the power to
compel an action by the key holder in addition to not reporting that it
happened. In this respect an NSL is no different to a court order except
that they are issued by a US government agency rather than a court and are
not subject to normal due process and accountability.
In that respect an NSL is unique to US jurisdiction, contrary to claims
made by some. It is a warrantless search order.
Given the way DNSSEC works and the complexity/risk of disclosure inherent
in how the DNSSEC root key is handled and validation is done, I personally
think it is far more likely the target's validating resolver will be
compromised (particularly given most people rely on validating resolvers
operated by third parties) but that isn't to say that we should ignore the
potential vulnerabilities that might exist in the handling of the root KSK.
The point is that unlike the operation of (many? most? all?) commercial
CAs, the operation of the root KSK by ICANN is public and open for
input/improvement. As I said in a previous message "send text".
Every CA is required to publish a CP and CPS. These are public documents.
The ICANN practice is entirely derivative of the practice of commercial CAs
and the NSA. This is hardly surprising given that VeriSign was operating as
a commercial CA at the time the DNSSEC root processes were decided.
If ICANN were to turn DigiNotar it is the only option, it is not only 'too
big to fail' it is the only possible provider.
Not knowing all the details of the Diginotar case I'm honestly curious:
given the very public nature of every step of ICANN's role related to the
root KSK, how would it "turn Diginotar"?
Well even Diginotar didn't lose control of their offline root so the more
apt comparison would be to a compromise at one of the TLDs where the
processing is necessarily online.
The issue in the case of Diginotar was that they had a perfectly fine audit
and the audit was completed correctly. The problem was that the audit did
not actually cover the public CA which it was used to gain inclusion in the
root programs.
--
Website: http://hallambaker.com/