Re: https at ietf.org

[David Conrad <drc@xxxxxxxxxxxxxxx>]

Phillip,

On 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.

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

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail