In message
<CAMm+LwgptxAAmCxqP9g8-+EOjwapwb2PJjVvvSe=N6A79WZqXA(_at_)mail(_dot_)gmail(_dot_)com>
, Phillip Hallam-Baker writes:
On Mon, Dec 9, 2013 at 5:54 PM, Doug Barton <dougb(_at_)dougbarton(_dot_)us>
wrote:
On 12/08/2013 09:41 PM, Phillip Hallam-Baker wrote:
On Sun, Dec 8, 2013 at 9:22 PM, Doug Barton <dougb(_at_)dougbarton(_dot_)us
<mailto:dougb(_at_)dougbarton(_dot_)us>> 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(_at_)isc(_dot_)org