In message <CAMm+LwgptxAAmCxqP9g8-+EOjwapwb2PJjVvvSe=N6A79WZqXA@xxxxxxxxxxxxxx> , Phillip Hallam-Baker writes: > On Mon, Dec 9, 2013 at 5:54 PM, Doug Barton <dougb@xxxxxxxxxxxxx> wrote: > > > On 12/08/2013 09:41 PM, Phillip Hallam-Baker wrote: > > > >> > >> > >> > >> On Sun, Dec 8, 2013 at 9:22 PM, Doug Barton <dougb@xxxxxxxxxxxxx > >> <mailto:dougb@xxxxxxxxxxxxx>> wrote: > >> > >> On 12/08/2013 10:21 AM, Phillip Hallam-Baker wrote: > >> > >> As I pointed out, what I was objecting to was yet another > >> iteration of > >> someone asserting that the DNSSEC PKI is different from the CA > >> system in > >> a way that it is not actually different. > >> > >> So I don't have to fix DNSSEC, all I need to fix here is to have > >> David > >> and others stop making claims for the protocol that are not > >> supported by > >> evidence. > >> > >> > >> Um, no. What you originally asserted was that the root was > >> vulnerable to being hijacked by an NSL. You have yet to provide any > >> evidence of that, and when confronted by evidence to the contrary > >> you changed the subject. > >> > >> So leaving aside the fine points of PKI and how they do or do not > >> relate to the root, do you have _any_ evidence to support your > >> original assertion? > >> > >> > >> What I said was that any root management is vulnerable to government > >> coercion. And that is still obviously true. > >> > > > > So your proof consists of, "Of course I'm right?" > > > No it consists of the argument that followed but you chose to respond to > before you read it. > > Publishing the legit ceremonies might provide some additional > >> transparency but does not prevent an illegitimate ceremony being inserted. > >> > > > > Theoretically that's true, sure. But the real question is what practical > > benefit would it have for the coercer? Again I'm asking for you to outline > > the attack you have in mind in detail. > > > Same as for CA PKI, they can make use of the bogus cert in some closed > network and hope that the network does not reach ground truth and discover > the attack. > > There is however another important attack that is unique to DNSSEC which is > a denial of signature attack. In the CA system you can always choose > another CA. So a legitimate signing request will always be satisfied by > some CA in some jurisdiction. The risk in DNSSEC is that the ICANN root > signer is coerced publicly to refuse to sign some domain. Congress has the > power to pass legislation and a future president might claim that they > already have the power. Which is trivial to work around by adding a TA for the zone in question. Remember the zone publishes the DNSKEY and DNSSEC is designed to work with islands of trust. RFC 5011 give a crude mechanism for following DNSKEY changes. For a similar reason removal of TLD's can't happen as people can still graft on namespace and establish TA's for the grafted on namespace. > It is not a threat right now because the cost of switching from the ICANN > root is small. But it is a risk that should cause concern and there are > steps that would mitigate it. The biggest problem is that it makes ICANN > too attractive as a takeover target. > > The point at which it would become an issue is when there are embedded > devices that are verifying DNSSEC chains that are not able to accept a root > key update. Enabling a root key update is one possible solution but it > creates a new set of risks. > > People can argue that 50 CAs is too many but one CA is too few unless you > are running it for yourself alone. > > > There are several possible solutions possible but they all come down to > diffusing the trust at the very apex of the DNS so that no party is able to > unilaterally defect. > > > The only real control is that any attack leaves irrefutable evidence and > >> only a government has the ability to mount such an attack. The idea that > >> the NSA or FBI would take such a step in the case of the DNS is > >> ridiculous, it would be tantamount to a treaty violation. But the idea > >> that they would take similar action against a US based CA or browser > >> provider is equally ridiculous. > >> > > > > Sorry, I don't understand most of what you wrote in the paragraph above. > > It sounds interesting though. :) > > > The point is that the work that Ben Laurie and others have done on > Certificate Transparency is just as applicable for DANE Certs. > > -- > Website: http://hallambaker.com/ > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@xxxxxxx