On Sun, Dec 1, 2013 at 7:09 PM, David Conrad <drc@xxxxxxxxxxxxxxx> wrote:
Phillip,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 revisedOn Nov 30, 2013, at 11:08 AM, Phillip Hallam-Baker <hallam@xxxxxxxxx> 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.
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.
Website: http://hallambaker.com/