Hi Tony, On 2014-02-14, at 16:02, Tony Finch <[email protected]> wrote:
> I think it's fairly obvious that I wrote just enough to get the idea > across in a reasonably complete form, but didn't bother with thorough > references (in particular not to your previous work, sorry!) or thorough > review of formal terminology. Right, completely understood. That's how I read it. >>> o The concentration of trust in the root is politically >>> uncomfortable. >> >> This may be true, depending on exactly what you mean, but I doubt it's >> universally true (perhaps not even widely true). I'm not sure I >> understand the motivation for including that statement has in a >> technical specification, especially when you consider that the intended >> trust mechanisms were designed to be dispersed amongst multiple (e.g. >> vendor) authorities. > > Unfortunately the X.509 signatures do not disperse trust, they duplicate > it. A bootstrapping validator trusts (== is vulnerable to compromise of) > any one of its X.509 CAs. > > The key point of the quorum-of-witnesses idea is that no single witness is > trusted in the way that an X.509 CA is. I think there's an inherent assumption here that by validating a certificate, a bootstrapping validator might be vulnerable against any one of the various attacks that have afflicted browsers, the core problem there being that of the browser list and not the mechanics of validating a certificate. To be clear, what was imagined was that a codebase which already has the ability to validate signatures over (say) software updates would easily be able to validate a certificate retrieved from data.iana.org that has the same kind of signature. The IANA people imagined that they would solicit specific signatures from specific keys relevant to bootstrapping, not that they would obtain signatures from commercial CAs and trust the browser list to do the right thing. Since the security of iOS (to choose an example at random) already relies upon the ability to validate signatures made by some Apple private key, using that same key to validate the integrity of a trust anchor bundle retrieved in the clear seemed like a nice easy way to import trust in something for which trust is important. As I mentioned, no such vendor has done this. This is just for clarification, not because I think it's a better mechanism than the one you proposed. >> The existing mechanisms (again, lamentably light on implementation) >> would also facilitate this. The mechanisms in the validator-bootstrap >> draft I referred to earlier allow trust anchor retrieval with no ability >> to validate, authenticating the retrieved data using appropriate local >> methods (e.g. the key that signed the code is used to test the signature >> of the data the code retrieved). > > However the existing mechanisms rely on a lot of infrastructure which has > to be accessed with validation turned off. My root witnesses idea uses > only the DNS and leaves validation switched on while bootstrapping. I think validation categorically needs to be off until the validator has been bootstrapped (not just for this proposal, but in general). No validation is possible before you have a stable sense of time and a trusted set of local DNSSEC trust anchors. Acting as though you are validating when you can't possibly be seems like a bad idea, since if you can game validators to get stuck in that state you've defeated DNSSEC. We tried to spell this out in draft-jabley-dnsop-validator-bootstrap. It occurs to me that we now have three drafts that speak to an active need (and try to fill a gap in DNSSEC deployment that at least some of us think needs to be filled): draft-jabley-dnsop-validator-bootstrap draft-jabley-dnssec-trust-anchor draft-fanf-dnsop-trust-anchor-witnesses It's not entirely obvious that dnsop is the right place for these (maybe we should talk to opsec? homenet, in the sense that these mechanisms need to be automatable without local operators?). But I think if they are going to go anywhere they need thorough working group review, and should not proceed as independent submissions -- this is an important set of definitions for real-world operation of the IANA root zone, and it needs to be as right as we can make it. Suz/Tim/ADs: opinions on whether this is a useful bundle of work for dnsop? (No, I'm not (necessarily) requesting another agenda slot for London :-) Joe
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
