Subject: Re: https at ietf.org

From: David Conrad <[email-masked]>
Date: Sun, 1 Dec 2013 16:09:08 -0800

Phillip,

On Nov 30, 2013, at 11:08 AM, Phillip Hallam-Baker <[email-masked]> 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

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 2 Dec 2013 16:02:28 -0500

On Sun, Dec 1, 2013 at 7:09 PM, David Conrad <[email-masked]> 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.
>
> 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
>

The reason that I said you have no idea what you are talking about is that
you describe these processes as if they are unique to the ICANN root rather
than being general practice for management of offline roots in general.

These processes were in use in commercial PKI before the first DNSSEC draft
was written over twenty years ago. And before that they were in use at the
NSA. They are designed to impress clients (or Congressmen) as much as
provide security.

What you do not appear to grasp is that the processes for online roots are
necessarily different as these have to be used at regular intervals. While
it might be practical to sign the DNS root zone offline, it certainly is
not practical to sign .com or any other TLD of consequence offline (except
possibly .gov).

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

Actually they are both since it is claimed that an NSL has the power to
compel an action by the key holder in addition to not reporting that it
happened. In this respect an NSL is no different to a court order except
that they are issued by a US government agency rather than a court and are
not subject to normal due process and accountability.

In that respect an NSL is unique to US jurisdiction, contrary to claims
made by some. It is a warrantless search order.

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

Every CA is required to publish a CP and CPS. These are public documents.

The ICANN practice is entirely derivative of the practice of commercial CAs
and the NSA. This is hardly surprising given that VeriSign was operating as
a commercial CA at the time the DNSSEC root processes were decided.

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"?
>

Well even Diginotar didn't lose control of their offline root so the more
apt comparison would be to a compromise at one of the TLDs where the
processing is necessarily online.

The issue in the case of Diginotar was that they had a perfectly fine audit
and the audit was completed correctly. The problem was that the audit did
not actually cover the public CA which it was used to gain inclusion in the
root programs.

-- 
Website: http://hallambaker.com/

---

From: David Conrad <[email-masked]>
Date: Mon, 2 Dec 2013 14:28:37 -0800

Phillip,

On Dec 2, 2013, at 1:02 PM, Phillip Hallam-Baker <[email-masked]> wrote:
> [...]

At no point did I suggest the key management processes were unique to ICANN nor did I suggest ICANN invented any of the processes out of thin air nor did I make any statement regarding the viability of online vs. offline signing of TLDs or the root or that the processes need be the same. You appear to be having a different conversation than the one Ted and I were engaging in and are attributing to me assertions I did not make (and don't necessarily agree with). I'm unclear how this is helpful.

My complaint was simply that I believe it is more useful to describe actual attacks and the vulnerabilities that allow for those attacks than it is to say "NSL" as if it a secret decoder ring.  Feel free to disagree with that complaint.

> In that respect an NSL is unique to US jurisdiction, contrary to claims made by some. It is a warrantless search order. 

I would be surprised to discover the US is unique in allowing the existence of warrantless search orders under the guise of national security, however that does not appear to be relevant to this particular thread.

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

I was not talking about the documents, I was talking about the actual operations. As you've indicated in the Diginotar case "... the audit did not actually cover the public CA which it was used to gain inclusion in the root programs." Since as far as I know, _all_ handling of the root key by ICANN is done in a public way (see http://data.iana.org/ksk-ceremony/15/ for the recordings of the most recent key ceremony), I'm asking how would ICANN "turn Diginotar"?

Regards,
-drc

---

From: Doug Barton <[email-masked]>
Date: Thu, 05 Dec 2013 23:04:00 -0800

On 12/02/2013 01:02 PM, Phillip Hallam-Baker wrote:
> These processes were in use in commercial PKI before the first DNSSEC
> draft was written over twenty years ago.

Yes, ICANN took advantage of a large existing knowledge base to create a 
method of securing the root KSK. It would have been foolish to do 
otherwise.

> What you do not appear to grasp is that the processes for online roots
> are necessarily different as these have to be used at regular intervals.

David is far too polite a person to say so, but frankly I find your 
condescension offensive. To the extent that you have useful things to 
contribute to the discussion it would be great if you could do so 
without being rude. If for no other reason than the gratuitous rudeness 
obstructs whatever valid points you may have.

> While it might be practical to sign the DNS root zone offline, it
> certainly is not practical to sign .com or any other TLD of consequence
> offline (except possibly .gov).

Rather than continuing to discuss theory, what would be useful at this 
point would be for you to do what has been asked several times now. 
Describe, in detail, what your threat vector is. Include in your 
description the method by which the root, or any other trust anchor 
would be compromised, and how that compromise would affect end users 
_given how DNSSEC works today_. Otherwise, please stop shouting "the sky 
is falling."

Doug

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 8 Dec 2013 13:21:19 -0500

On Fri, Dec 6, 2013 at 2:04 AM, Doug Barton <[email-masked]> wrote:

> method of securing the root KSK. It would have been foolish to do otherwise.

David asserted that the processes used by ICANN provided greater security
than those for PKIX PKI, I was pointing out that the claim made is false.

> contribute to the discussion it would be great if you could do so without
> being rude. If for no other reason than the gratuitous rudeness obstructs
> whatever valid points you may have.

When someone repeats FUD after having the issue explained to them
repeatedly I tend to start speaking plainly.

And I am far too polite to point out that the manner of your response is
hypocritical.

> point would be for you to do what has been asked several times now.

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.

The problem of securing an online system is intrinsic to the problem of
running PKI at scale.

> description the method by which the root, or any other trust anchor would
> be compromised, and how that compromise would affect end users _given how
> DNSSEC works today_. Otherwise, please stop shouting "the sky is falling."

Please stop making unfair comparisons. Comparing the offline security
management of DNSSEC to the performance of the online CA system is not a
fair comparison. The offline components of the two systems are essentially
identical.

---

From: David Conrad <[email-masked]>
Date: Sun, 8 Dec 2013 18:24:12 -0500

Phillip,

> Yes, ICANN took advantage of a large existing knowledge base to create a method of securing the root KSK. It would have been foolish to do otherwise.
> David asserted that the processes used by ICANN provided greater security than those for PKIX PKI, I was pointing out that the claim made is false.

This is the second time you have falsely claimed I have made assertions that I have not.

Please stop.

I have said precisely nothing about the processes of the PKIX PKI other than I understood the operation of the DNSSEC root KSK to be more public and open than "the operation of (many? most? all?) commercial CAs". 

If you disagree with that statement, please provide evidence that shows commercial CAs operating at least as openly and transparently as ICANN's handling of the DNSSEC root KSK.

Whether this increased level of openness/transparency provides greater security may be an interesting topic to explore, but I have not made any assertions to that effect in this thread.

> When someone repeats FUD after having the issue explained to them repeatedly I tend to start speaking plainly.

Again, you appear to having conversations outside of the context of this thread and misattributing those conversations.  

Please stop.

If you have evidence I have repeated FUD, please provide it.

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

I am unaware of any claim I might have made regarding DNSSEC that is not supported by evidence.  Can you please provide a reference to such a statement.  Thanks.

Regards,
-drc

---

From: Doug Barton <[email-masked]>
Date: Sun, 08 Dec 2013 18:22:42 -0800

On 12/08/2013 10:21 AM, Phillip Hallam-Baker wrote:

> 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?

Doug

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 9 Dec 2013 00:41:54 -0500

On Sun, Dec 8, 2013 at 9:22 PM, Doug Barton <[email-masked]> wrote:

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

What I said was that any root management is vulnerable to government
coercion. And that is still obviously true.

Having performed a root key generation in public does not guarantee that
future operations will be public. If we assume that the government has the
power to coerce the root key manager they can coerce the vendor of the
evidence bags to provide some un-numbered ones and then number them
themselves.

In fact I have some unnumbered evidence bags. Most of the vendors send them
out as free samples on request.

It is not a criticism of the particular process, it is a fundamental
constraint.

Publishing the legit ceremonies might provide some additional transparency
but does not prevent an illegitimate ceremony being inserted.

Can't even control it using the crypto hardware since the attacker can
coerce them as well. There is no ground truth you can depend on under that
attack.

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.

---

From: Doug Barton <[email-masked]>
Date: Mon, 09 Dec 2013 14:54:18 -0800

On 12/08/2013 09:41 PM, Phillip Hallam-Baker wrote:
>
>
>
> On Sun, Dec 8, 2013 at 9:22 PM, Doug Barton <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     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?
>
>

So your proof consists of, "Of course I'm right?"

> future operations will be public.

Let's take as a truism that we cannot guarantee that future events will 
be public, sure. However the question remains, how does any government 
influence the situation to their benefit without the public knowing? 
After all, the whole point of this exercise is for them to be be able to 
"slip something in" undetected, right?

Given that the ZSK rolls happen on a predefined schedule, and have 
always been public, and all of the relevant ZSKs are visible in the zone 
file; wouldn't changing either of the first 2 parameters raise many, 
many alarm bells? And if the new ZSK that showed up on schedule was 
different than the pre-announced one, wouldn't that raise just as many 
bells?

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

> 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. :)

Doug

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 9 Dec 2013 19:23:00 -0500

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

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

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.

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

---

From: Mark Andrews <[email-masked]>
Date: Tue, 10 Dec 2013 11:52:58 +1100

In message <CAMm+LwgptxAAmCxqP9g8-+EOjwapwb2PJjVvvSe=[email-masked]>
> power to pass legislation and a future president might claim that they

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.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 9 Dec 2013 22:39:35 -0500

On Mon, Dec 9, 2013 at 7:52 PM, Mark Andrews <[email-masked]> wrote:

> > >>         So I don't have to fix DNSSEC, all I need to fix here is to
> have
> > >>         David

It is trivial to fix when the validation is taking place in a service in
the cloud (aka a resolver).

Rather less easy to do if people drink the DANE cool-aid and do the job at
the end point.

Now you can take this point as either arguing against doing DANE or
considering the risk and deploying the appropriate control. But you do have
to consider it.

What you are in effect asserting is that the resolver providers are the
apex of the trust chain and so there is a diffuse trust surface rather than
a sharp point. Which is true when the validation takes place in the
resolver.

---

From: John C Klensin <[email-masked]>
Date: Tue, 10 Dec 2013 09:00:22 -0500

--On Monday, December 09, 2013 22:39 -0500 Phillip Hallam-Baker
<[email-masked]> wrote:

>...
>> 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 trivial to fix when the validation is taking place in a
> service in the cloud (aka a resolver).
> 
> Rather less easy to do if people drink the DANE cool-aid and
> do the job at the end point.
> 
> Now you can take this point as either arguing against doing
> DANE or considering the risk and deploying the appropriate
> control. But you do have to consider it.
> 
> 
> What you are in effect asserting is that the resolver
> providers are the apex of the trust chain and so there is a
> diffuse trust surface rather than a sharp point. Which is true
> when the validation takes place in the resolver.

I am probably going to regret getting involved in this thread,
but I would draw two rather different conclusions from the above
and a number of other comments:

(1) We have seriously oversold DNSSEC as a data quality and
reliability mechanism when it is merely a transmission integrity
mechanism.  The former is about the DNS and associated
registration database (e.g., "whois") records being accurate,
secure, and maybe even information-containing.  The latter is
merely about an assurance that the data one receives hasn't been
altered in transit in the DNS.

Now most of the people who have been involved in the design and
implementation of DNSSEC have been quite careful about the
above, at least most of the time.  But sometimes they are sloppy
about their language, sometimes they say "DNNSEC" and people
hear "DNS Security" and make inferences to data quality.  More
important, there is an (illogical) chain of reasoning from
"DNSSEC is in use" to "[now] the DNS is secure" to "all of the
data provided by the DNS or its supplemental databases are of
high quality".  

While the integrity checks of DNSSEC provide some protection
against some types of attacks on the "data quality" part of the
DNS environment, the attacks they protect against are very
difficult.  An attacker with the resources to apply them would
almost certainly find it easier, less resource-expensive, and
harder to detect to attack registry databases (before data are
entered into DNS zones and signed), registrar practices, or
post-validation servers.  Non-technical attacks, such as the
oft-cited hypothetical NSL, are easily applied at those points
as well -- much more easily than tampering with keys or
signatures.

(2) In a different version of some of the comments on the
thread, the "where to validate" question is important.  If one
tries to validate at the endpoints, endpoint systems, including
embedded ones, should have the code and resources needed to
validate certs and handle rollovers, even under hostile
conditions, and that isn't easy.  If one relies on intermediate,
especially third-party, servers to validate, than much of the
expected integrity protection is gone... and the number of times
such servers have been compromised would make this a
non-theoretical problem even without concerns about
governmental-type attacks (NSL and otherwise) on those servers.
No easy solutions here.

I don't know where that combination of situations leaves
initiatives like DANE, but I suspect we should be looking at
trust conditions and relationships a lot more carefully than the
discussions and claims I've seen suggest we have been doing.

    john

---

From: Doug Barton <[email-masked]>
Date: Tue, 10 Dec 2013 11:43:55 -0800

> I am probably going to regret getting involved in this thread,

GMTA :)

> difficult.

John,

IMO you're spot on with all of the above. Especially about being careful 
with our language about what DNSSEC is designed to do. I try very hard 
to be precise, but it's good to have this reminder periodically.

> An attacker with the resources to apply them would

As previously mentioned, these attacks are theoretically possible, but 
they are trivially detectable since all of the critical data is visible 
in the DNS. They may not be _immediately_ detectable, and in fact likely 
would not be detected immediately; where "immediate" is going to vary 
widely depending on the value/profile of the target. But we have plenty 
of experience with people noticing DNS problems for critical resources. 
Even in the DNSSEC case we have major players doing DNSSEC validation 
now (Comcast and Google leap to mind) so shenanigans involving DNSSEC 
are going to be noticed.

The point I'm trying to get across here is that any sort of manipulation 
of the DNS by a 3rd party (such as a malicious hack, NSL, etc.) is 
valuable only to the extent that it can go unnoticed, and therefore 
cause innocent end users to depend on the 3rd party's resources instead 
of the valid ones _without their knowledge_.

We don't need DNSSEC to see that this sort of thing only works for a 
limited time. We have had lots of events where high profile sites have 
had their registrar data changed, and there is a huge public hue and 
cry. Of course a skillful attacker could create a phishing page that 
looks enough like the real site to gather a non-trivial number of user 
passwords, but again, we don't need DNSSEC for that. In fact, if the 
sophisticated attacker manages to socially engineer the registrar 
credentials (the most popular form of this type of attack) then they can 
update the DS record in addition to the NS records, and have a fake site 
that validates perfectly.

But even that sort of attack would only work for a short period of time. 
More importantly, the ability to slide the malicious data into the DNS 
at all is going to be proportional to the location of the resource in 
the tree. We already know that individual zones are vulnerable to 
registrar attacks. However new TLD DS records in the root are greeted 
with fanfare (at least amongst a fairly substantial number of DNS 
wonks), so the ability to slip stuff in at that level is minimal at 
best. This is more true at the root itself.

So to be concise (yeah, I know, too late) claiming that DNSSEC is 
vulnerable to external manipulation at the root or TLD level is almost 
certainly wrong. There are theoretical attacks that could be launched, 
but their practical value is nil. If someone has a valid attack that 
uses a method I haven't taken into account, they should find a trusted 
channel to make that known.

> governmental-type attacks (NSL and otherwise) on those servers.

Again, spot on. I've been saying for many years now that the most 
interesting part of DNSSEC is going to be local on the end user side. 
Pushing validation all the way down is critical.

> discussions and claims I've seen suggest we have been doing.

I like DANE a lot, and I think it has a critical role going forward. The 
problem is that it is only as valid as the registrar data for the zone. 
So it's not clear that DANE is going to be a complete replacement for a 
CA-provided cert.

Doug

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 10 Dec 2013 20:09:18 -0500

On Tue, Dec 10, 2013 at 2:43 PM, Doug Barton <[email-masked]> wrote:

> they are trivially detectable since all of the critical data is visible in
> the DNS. They may not be _immediately_ detectable, and in fact likely would
> not be detected immediately; where "immediate" is going to vary widely
> depending on the value/profile of the target. But we have plenty of
> experience with people noticing DNS problems for critical resources. Even
> in the DNSSEC case we have major players doing DNSSEC validation now
> (Comcast and Google leap to mind) so shenanigans involving DNSSEC are going
> to be noticed.
>

As we learned with the WebPKI, that is only the case if you have a deployed
monitoring infrastructure. It is not that difficult to do but you do have
to do it.

> of the DNS by a 3rd party (such as a malicious hack, NSL, etc.) is valuable
> only to the extent that it can go unnoticed, and therefore cause innocent
> end users to depend on the 3rd party's resources instead of the valid ones
> _without their knowledge_.
>

Covert attacks are detectable. But that is only a defense if you have the
ability to switch to another root or override the trust assertions of the
root.

> limited time. We have had lots of events where high profile sites have had
> their registrar data changed, and there is a huge public hue and cry. Of
> course a skillful attacker could create a phishing page that looks enough
> like the real site to gather a non-trivial number of user passwords, but
> again, we don't need DNSSEC for that. In fact, if the sophisticated
> attacker manages to socially engineer the registrar credentials (the most
> popular form of this type of attack) then they can update the DS record in
> addition to the NS records, and have a fake site that validates perfectly.
>

But people do need to be careful about DANE and about Certificate pinning.

> More importantly, the ability to slide the malicious data into the DNS at
> all is going to be proportional to the location of the resource in the
> tree. We already know that individual zones are vulnerable to registrar
> attacks. However new TLD DS records in the root are greeted with fanfare
> (at least amongst a fairly substantial number of DNS wonks), so the ability
> to slip stuff in at that level is minimal at best. This is more true at the
> root itself.
>
> certainly wrong. There are theoretical attacks that could be launched, but
> their practical value is nil. If someone has a valid attack that uses a
> method I haven't taken into account, they should find a trusted channel to
> make that known.

If we are comparing like with like, the practical value of the attacks
against the WebPKI have been limited, with the exception of DigiNotar

> Pushing validation all the way down is critical.

But if you do that you eliminate the wiggle room that your earlier argument
relied on.

You can solve any security problem if you have an intelligent party with
global knowledge making the decisions. But you can only deploy code at the
end point that is Turing complete and works on the information visible to
it there.

If we are proposing to only do verification in a resolver then the NSL etc.
issues are manageable because it is a service in the cloud and can be
reconfigured.

But the WebPKI works end to end and has the entire decision process
embedded in the end point code. If you want to use DNSSEC end to end you
have to meet the same requirement. In that scenario your proposal that we
deal with lock in issues by using common sense is now a deus ex machina
because machines don't have common sense.

---

From: Douglas Otis <[email-masked]>
Date: Tue, 10 Dec 2013 22:26:36 -0800

> as well -- much more easily than tampering with keys or

Dear John,

The opacity of CAs, DNS, and BGP place all forms of security at risk!  These mechanisms are never stronger than their weakest link.  Without burdensome cryptographic checking, no Internet service should be trusted.  DANE in conjunction with DNSSEC affords a much needed transparency to expose exchanges at risk.

TLS should be considered a two-way certificate exchange resolving domains rather than individuals.  For example, a federated service like email lacking two-way certificate checks can not be defended from abuse, nor can privacy of those using such a service be assured.  Transparency in the security mechanism should fully illuminate domains, not individuals.  TLS and StartTLS contain elements for two-way certificate exchange and can make a needed transition from CAs to DANE while providing a verifiable chain of trust to the controlling domain.

Of course, websites have adopted synthetic domains as an alternative for web cookies. When naughty synthetic domains are used, no amount of encryption protects individuals when metadata remains fully apparent.  Perpass documents should have included stronger statements about protecting services as apposed to suggesting shortcuts in the guise of affording privacy.  No conversation should ever be considered private without first ensuring the controlling domain at each end of the exchange.

Regards,
Douglas Otis