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.
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. 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".
If we are positing the failure of those controls in one case then we should
posit the same attack in the other.
I agree 100%.
At least in the CA trust scheme there is a choice of trust providers.
This does not appear to have been an advantage in practice since it would seem
non-public practices on the part of a few CAs put relying parties at risk.
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"?
Regards,
-drc
signature.asc
Description: Message signed with OpenPGP using GPGMail