Subject: RE: DNSSEC is NOT secure end to end

From: Christian Huitema <[email-masked]>
Date: Sat, 30 May 2009 17:29:21 -0700

> That is, security of DNSSEC involves third parties and is not end
> to end.

That is indeed correct. An attacker can build a fake hierarchy of "secure DNS" assertions and try to get it accepted. The attack can succeed with the complicity of one of the authorities in the hierarchy. It is a classic "attack by a trusted party".

Problem is, hop-by-hop security will not protect against an attack by an intermediate authority. If an intermediate authority has been compromised, it can just as well insert a fake NS record -- that's not harder than a fake record signature. Hop-by-hop security will securely connect to the wrong name server, to which the wrong NS record points...

-- Christian Huitema

---

From: Thierry Moreau <[email-masked]>
Date: Mon, 01 Jun 2009 10:22:12 -0500

To the IETF mailing list subscribers:

The US government involvement in DNSSEC operations is almost certainly 
not in-scope for the ietf mailing list. Thus, it would be 
counterproductive to start a discussion based on Mr. Baptista comments 
on this topic (hence no in-line comments in the original message below).

However, the question remains: which forum, if any, is appropriate for a 
discussion? I don't have the answer, so I merely share the following 
observations.

A) ICANN was specifically requested to abstain from public consultations 
about its proposal to deploy DNSSEC at the root. This is in a letter 
from US Department of Commerce to ICANN, ref 
http://www.icann.org/correspondence/baker-to-twomey-09sep08.pdf (filed 
among other documents in http://www.icann.org/correspondence/ ).

B) The US Department of Commerce issued a public comment notice (the 
deadline is now past), see http://www.ntia.doc.gov/DNS/DNSSEC.html . 
This forum has been used by Mr. Baptista. I was favourably impressed by 
the material written by NTIA staff (and published in the Federal 
Register), so I would recommend this reading (at 
http://www.ntia.doc.gov/frnotices/2008/FR_DNSSEC_081009.pdf ). However, 
this "forum" is not really interactive.

C) Some other forums on which DNSSEC protocol and operational aspects 
are discussed frequently avoid and/or terminate discussions about US 
government involvement in DNSSEC operations for the DNS root. I do not 
blame their moderator or anybody else, I'm just reporting an observation.

D) If any stakeholder group or representatives see some effectiveness in 
the WSIS, the discussions on DNSSEC deployment would fall under the 
heading "critical Internet resources." I don't see much potential for 
active discussion on this front, but it's only my opinion.

So, that's it. Anybody has other suggestions for an appropriate forum 
for DNSSEC deployment at the root *including* US government involvement?

Regards,

- Thierry Moreau

Joe Baptista wrote:

> 
> DNSSEC indeed violates the end to end principle.  It's simply that 
> simple.  And it asks us to put our trust in the root a.k.a. ICANN.  I 
> don't think governments world wide are going to put their trust and 
> faith in ICANN.  The U.S. Government is the only government that has 
> been bamboozled into adopting DNSSEC into .gov infrastructure.
> 
> I wonder how President Obama would feel about handing over the keys to 
> U.S. Government infrastructure to a U.S. contractor.  I'd have trouble 
> sleeping at night if that was the case.
> 
> I've addressed this at length in my comments to the NTIA.
> 
> http://www.ntia.doc.gov/DNS/comments/comment034.pdf
> 
> If the U.S. government wants DNSSEC today then it must nationalize the 
> roots.  I don't even trust Vixie with the root.  I remember when he 
> hijacked the root with Postel.  Or as they put it "we were only running 
> an experiment".
> 
> In any case the new infrastructure campaign demands U.S. government 
> roots be set up to exclusively serve U.S. network infrastructure.
> 
> regards
> joe baptista
> 
> p.s. If you want to secure the DNS end to end - think DNSCurve - not DNSSEC.
> 
> http://dnscurve.org/
> 
> 
> On Sat, May 30, 2009 at 7:27 PM, Masataka Ohta 
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Francis Dupont wrote:
> 
>      > => not only this is very arguable (for instance about the resource
>      > exhaustion) but no hop-by-hop/channel security, even something as
>      > strong as TSIG, can provide what we need, i.e., end-to-end/object
>      > security (*).
> 
>     Unless your meaning of end-to-end differs from that of David Clark,
>     the following argument of his paper is applicable to DNSSEC.
> 
>            http://portal.acm.org/citation.cfm?doid=383034.383037
>            Rethinking the design of the Internet:
>            The end to end arguments vs. the brave new world
> 
>            The certificate is an assertion by that (presumably
>            trustworthy) third party that the indicated public key
>            actually goes with the particular user.
> 
>            These certificates are principal components of essentially
>            all public key schemes,
> 
>      > PS (*): I use the common meaning of end-to-end, not Masataka
>     Ohta's one.
> 
>     I'm afraid you don't know who David Clark is and how he is related
>     to the end to end argument.
> 
>     However, all the people who are qualified to discuss end to end do
>     know him and his argument.
> 
>                                                            Masataka Ohta
> 
>     _______________________________________________
>     Ietf mailing list
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/listinfo/ietf
> 
> 
> 
> 
> -- 
> Joe Baptista
> 
> www.publicroot.org <http://www.publicroot.org>
> PublicRoot Consortium
> ----------------------------------------------------------------
> The future of the Internet is Open, Transparent, Inclusive, 
> Representative & Accountable to the Internet community @large.
> ----------------------------------------------------------------
>  Office: +1 (360) 526-6077 (extension 052)
>     Fax: +1 (509) 479-0084
> 
> Personal: www.joebaptista.wordpress.com 
> <http://www.joebaptista.wordpress.com>
> 
> 
> 
> -- 
> Joe Baptista
> 
> www.publicroot.org <http://www.publicroot.org>
> PublicRoot Consortium
> ----------------------------------------------------------------
> The future of the Internet is Open, Transparent, Inclusive, 
> Representative & Accountable to the Internet community @large.
> ----------------------------------------------------------------
>  Office: +1 (360) 526-6077 (extension 052)
>     Fax: +1 (509) 479-0084
> 
> Personal: www.joebaptista.wordpress.com 
> <http://www.joebaptista.wordpress.com>
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 02 Jun 2009 22:38:28 +0900

> That is indeed correct. An attacker can build a fake hierarchy of
> "secure DNS" assertions and try to get it accepted. The attack can
> succeed with the complicity of one of the authorities in the
> hierarchy. It is a classic "attack by a trusted party".

Yes, the hierarchy has hops.

For my domain: "necom830.hpcl.titech.ac.jp", hierarechy of zones
have hops of ".", "jp", "ac.jp", "titech.ac.jp" and
"hpcl.titech.ac.jp". The authority hops are IANA, JPNIC, my
university, and my lab. Though you may have direct relationship
with IANA, JPNIC is the third party for both you and me.

> If an intermediate authority has
> been compromised, it can just as well insert a fake NS record --
> that's not harder than a fake record signature.

So, with a compromised hop of an intermediate authority, record
signature on the faked next hop key can be generated.

Then, with a private key corresponding to the faked next hop key,
record signature on the faked second next hop key can be generated.

Then, with a private key corresponding to the faked second next
hop key, record signature on the faked third next hop key can be
generated.

Yes, security of DNSSEC is totally hop by hop.

							Masataka Ohta

---

From: Thierry Moreau <[email-masked]>
Date: Tue, 02 Jun 2009 09:09:13 -0500

> with IANA, JPNIC is the third party for both you and me.

This is exactly like a chain of PKI CA's (replacing the path from bottom 
to top of zone hierarchy):

   For my [end-user administrative units], [chain of CA's] have hops of 
[CA run by IANA], [CA run by JPNIC], [CA run by my university], and [CA 
run by my lab].

I don't know what is meant by a direct relationship with IANA.

> signature on the faked next hop key can be generated.

Exactly the same with a compromised intermediate CA.

> record signature on the faked second next hop key can be generated.

Exactly the same with a private key corresponding to the next 
intermediate CA along the chain (i.e. the one certified by the 
compromised CA).

> hop key, record signature on the faked third next hop key can be

Same thing.

> Yes, security of DNSSEC is totally hop by hop.

Thus, you imply a definition of hop by hop along digital signature 
relationships. Indeed, DNSSEC security is limited to the weakest link 
along the chain from the bottom to the top of the DNS hierarchy. Nothing 
new there. I don't think any DNSSEC expert ever claimed differently.

Regards,

- Thierry Moreau

---

From: Richard Barnes <[email-masked]>
Date: Tue, 02 Jun 2009 10:14:11 -0400

This debate has nothing to do with the security properties of DNSSEC.

A basic assumption of the DNS is that what the authoritative server for 
zone says is, well, authoritative.  The structure of DNS itself entitles 
JPNIC to point ac.jp wherever they want; by using a name within the .jp 
domain, you are agreeing to act within JPNIC's domain of control.  JPNIC 
could set up an authoritative server for hpcl.titech.ac.jp completely 
independently of you, regardless of DNSSEC, and from the perspective of 
the DNS, that would be the right answer.

All DNSSEC does is make the assertions made in the DNS reliable -- it 
does nothing to change the locus of control.

On the other hand, you can certainly use the DNSSEC protocol elements to 
do peer-to-peer security, just like you can use private DNS servers, and 
just like you can use TLS without trust anchors (i.e., with self-signed 
certs).  Just hand out the public half of your ZSK to people you want to 
be able to verify names within your zone.

--Richard

---

From: Thierry Moreau <[email-masked]>
Date: Tue, 02 Jun 2009 10:07:58 -0500

> the DNS, that would be the right answer.

I guess what Masataka was referring to is a different source of 
variance, i.e. an impersonation of JPNIC's authority over its domain of 
control (using a compromised JPNIC's private key).

> does nothing to change the locus of control.

Reliable through a chain fo digital signatures. Reliable to the extent 
an impersonation attack (on the locus of control) does not occur based 
on a compromised private signature key.

> be able to verify names within your zone.

Then you reduce the chain of digital signatures to a single one, raising 
confidence level at the cost of more key management hindrance.

Indeed, this thread seems to be another attempt to understand the basic 
DNSSEC properties.

- Thierry

---

From: Richard Barnes <[email-masked]>
Date: Tue, 02 Jun 2009 11:41:23 -0400

> control (using a compromised JPNIC's private key).

This is still just an extension of the trust you already have in your 
parent domains.  You already have to trust that a parent domain's 
servers aren't going to be subverted and used to provide false answers. 
  And since the most likely way for a DNSSEC key to get compromised is 
for it to be stolen (rather than cracked via the public key or 
signatures), these two levels of trust turn out to be the same.

(In fact, a wily attacker would just use his access to the zone to make 
his changes, rather than having to spoof every client / resolver / cache 
individually.)

There really is very little new here, in terms of the trust that's being 
  placed in zone maintainers.  It's just that DNSSEC now allows you to 
have the maintainers (which you already trust, see above) protect the 
integrity of records they send to you as they go across the wire.

(That is: You already trust the zones above you to maintain the 
integrity of the zone on the *server*; DNSSEC just extends that 
protection on the *wire*.)

--Richard

---

From: Thierry Moreau <[email-masked]>
Date: Tue, 02 Jun 2009 11:08:34 -0500

Richard Barnes wrote:
> integrity of the zone on the *server*;
> 

This assumption does not stand universally. For some DNS users/usage, 
DNSSEC signature verification will be a must. The discussion implicitly 
referred to such uses.

Then, it is legitimate to appraise the overall confidence in the DNSSEC 
chain of signatures, and to pinpoint the weakest link (e.g. the zone 
manager having the greatest likelihood of lousy private key protection 
in place).

Indeed, DNS+DNSSEC is no different from plain DNS for those who are 
satisfied with the plain DNS. For those awaiting DNS+DNSSEC for some 
uses, it is useful to understand DNSSEC chains of digital signatures.

Accesssorily, the zones "above you" means nothing to a relying party 
that is not validating its own domain.

Regards,

-- 

- Thierry Moreau

---

From: Paul Wouters <[email-masked]>
Date: Tue, 2 Jun 2009 13:21:42 -0400 (EDT)

> Yes, security of DNSSEC is totally hop by hop.

Just as DNS was designed to work. hierarchical. If you want to
add additional protection because you don't trust your parents,
no one stops you from using a DNSSEC capable resolver that has
DNSSEC zones configured directly, without relying on the parent.

I can't preload 50 million keys. I cannot build trust relations
with 50 millions domains. Just like we could not preload 50
million nameserver pointers.

Hierarchy is the strength of DNS, not its weakness. DNSSEC allows
you to specifically bypass the hierarchy for whatever zone you
want. The only real question is, how does Masataka Ohta scale?

My suspicion is that you don't scale to 50M domains, and that
you will be forced to outsource some of that trust. DNSSEC
does the outsourcing of trust distributed to the same people
who are already responsible for the data you're about to trust.

And note that even if you scale to 50M domains, I don't, so don't expect
me to setup a trust relationship with you specifically.

Paul

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 03 Jun 2009 08:32:23 +0900

> intermediate CA along the chain (i.e. the one certified by the 

The paper of David Clark says PKI is not secure end to end.

Some tried to argue against by saying DNSSEC is so special that
it is secure end to end.

But, as you can observe, DNSSEC is no special and not secure end
to end.

> I don't think any DNSSEC expert ever claimed differently.

I am the DNSSEC expert and see some people having a lot less
expertise than me says DNSSEC secure end to end.

They are incorrect or using different terminology on "end to end"
not acceptable to the Internet community.

						Masataka Ohtqa

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 03 Jun 2009 08:42:39 +0900

> DNSSEC signature verification will be a must. The discussion implicitly 

A problem of blindly believing a zone administration is that it is
only as secure as blindly believing an ISP administration.

Attacking a router of a large ISPs is as easy/difficult as attacking
a signature generation mechanism of a large zone.

Moreover, administration of LAN of a local organization (my universty,
for example) is as secure as administration of a zone local to the organization.

You can, for example, bribe a personnel or two, against which there
is no cryptographical protection, which means PKI is weakly secure.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 03 Jun 2009 09:04:18 +0900

> million nameserver pointers.

That is the essential point of the paper of David Clark:

	These certificates are principal components of essentially
	all public key schemes, except those that are so small in
	scale that the users can communicate their public keys to
	each other one to one, in an ad hoc way that is mutually
	trustworthy.

A credit card brand (VISA, for example) may manage more than
50 million PIN numbers. But, it uses agents to do so. The security
of the system depends on not only (cryptographical) security between
the brand holder and agents but also social security of the agents.

Though 4 digit PIN or 16 bit message ID of DNS is cryptographically
not very secure, it is a cryptographical issue of each hop, having
nothing to do with social security between hops, introduction of
which is inevitable for large infrastructures.

						Masataka Ohta

---

From: Paul Wouters <[email-masked]>
Date: Tue, 2 Jun 2009 20:35:05 -0400 (EDT)

> is no cryptographical protection, which means PKI is weakly secure.

You have never heard of a Hardware Security Module?

Paul

---

From: Mark Andrews <[email-masked]>
Date: Wed, 03 Jun 2009 10:47:31 +1000

> a signature generation mechanism of a large zone.

	The difference is we *have* to trust the zone administration.
	There is no scalable way to avoid that trust issue.

	We don't have to trust the router adminstration or caching
	server administration or authoritative server adminstration.
 
> for example) is as secure as administration of a zone local to the organizati

	I've been on plenty of LAN's which I would treat as "hostile".
 
> is no cryptographical protection, which means PKI is weakly secure.

	Which is not a arguement for not doing DNSSEC.  Knowing
	where the risks are is how you do risk management.  If you
	arn't willing to accept some risks then don't connect to the
	net.
 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Wed, 03 Jun 2009 10:55:20 +1000

In message <[email-masked]>, Paul Wou
> You have never heard of a Hardware Security Module?
 
	HSM doesn't stop the wrong data being signed.  It just stops
	it being signed on machines other that the designated servers.

	Mark

---

From: Paul Wouters <[email-masked]>
Date: Tue, 2 Jun 2009 21:00:05 -0400 (EDT)

> 	it being signed on machines other that the designated servers.

The context was the "false security" of DNSSEC and the "third party  trust".
Obviously changing the raw dns data is possible both with and without DNSSEC.

Paul

---

From: Mark Andrews <[email-masked]>
Date: Wed, 03 Jun 2009 11:09:42 +1000

In message <[email-masked]>, Paul Wou
> Obviously changing the raw dns data is possible both with and without DNSSEC.

	If you are "bribing personel" you need to assume they can
	do anything the orginisation they work for can do.  HSM's
	don't help in this case.  HSM's have their place but you
	need to understand the limitations of the devices.  HSM's
	are better than just having the private component of a
	public key sitting on a disk somewhere but in most operational
	enviornments they don't add that much more security to the
	process.

	Mark

---

From: Michael StJohns <[email-masked]>
Date: Tue, 02 Jun 2009 22:20:45 -0400

At 09:09 PM 6/2/2009, Mark Andrews wrote:
>  HSM's

It depends on the HSM.  For example, there are HSMs that allow you to program just about any policy you want - including the requirement to have at least N people agree that something needs to be signed.   The size of "N" is chosen to balance need for accountability with that of usefulness.  I.e. requiring 20 people to turn the keys to get something signed is probably not useful.  Permitting 1 person to sign without further oversight is probably not enough accountability.

So saying they don't add much more security is really a statement that might be correct under really bad management practices, but mostly isn't.

For example, even a simple version of keeping the set of  HSM PIN holders distinct from set of people allowed to physically access the HSM for signing provides a substantial amount of operational security.

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 03 Jun 2009 15:27:42 +0900

> 	The difference is we *have* to trust the zone administration.

Zone administration involves multiple operations.

Though we have to trust the zone administration put correct referral
and glue data in a master zone file, unless we use DNSSEC, we don't
have to trust the zone administration never issue certificates over
forged keys of child zones.

You know, the former operation is much simpler, thus more secure,
than the latter.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 03 Jun 2009 16:52:13 +0900

Christian Huitema wrote:

> NAT routers come to mind. DNSSEC
> is immune to such attacks, a big advantage in practice.

I'm afraid DNSSEC and some NAT interact terribly.

> Also, it is actually possible to improve on DNSSEC by introducing
>  additional knowledge. If two domains have an establish relation,
> their servers can memorize the relevant public keys. If a host
> has a relation with a domain, it can memorize that domain's
> public key. This kind of "peer-to-peer" improvement makes the
> domain-to-domain or host-to-domain DNSSEC service immune to
> attacks by nodes higher in the hierarchy.

Do you know that the paper particularly discusses on revocation?

It is written in the paper that:

	It can happen that a user loses his private key (the value
	that goes with the given public key) through inadvertence or
	theft; alternatively, a user may become unworthy in some way
	relevant to the purpose for which the certificate has been
	issued. Under such circumstances, the certificate authority
	(third party) would want to revoke the certificate. How can
	this be known?

Your "improvement" makes the entire system more complex only to
introduce new difficulties for revocation.

						Masataka Ohta

---

From: Bill Manning <[email-masked]>
Date: Wed, 3 Jun 2009 00:56:02 -0700

> Yes, security of DNSSEC is totally hop by hop.

	i think the distinction here might be characterised by 
	the use of terms:

	-channel security
	-data integrity

	DNSSEC - the signing of the data, provides a means to ensure the
	accuracy and integrity of the data, the payload.  Given the design
	of the DNS, that data can come from an authoritative source or a cache.
	there is no expectation that the data will emerge from or through any
	given path/source.  Once the data is received, it is possible to determine
	if the data is a) intact, and b) untampered with. There is no hop/hop at
	the transport level cause DNS really doesn't work that way today.  

	Channel Security - hop/hop can be done a couple of different ways. IPsec,
	TSIG, SIG(0), DNSCurve et.al.  From a resolver point of view, this type
	of security is usually done only one hop away, to the prefered cache or 
	(small) set of authoritative servers.  It could be possible, but unweildy
	to do complete channel security.  But to what end?  

--bill
Opinions expressed may not even be mine by the time you read them, and
certainly don't reflect those of any other entity (legal or otherwise).

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 04 Jun 2009 12:35:02 +0900

> 	i think the distinction here might be characterised by 

Don't try to confuse the terminology.

With the terminology of "channel", the paper addresses the issue
that security by channels between zones or zone administrators
depends on security of intermediate zones and is not end to end.

> 	-data integrity

Date integrity is maintained through the channels between zones
hop by hop.

> 	accuracy and integrity of the data, the payload.

The problem is that the accuracy and integrity of DNSSEC is not
cryptographically but socially secure.

So is plain old DNS.

So, there is no point to deploy DNSSEC.

							Masataka Ohta

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 4 Jun 2009 10:22:18 -0400

> You know, the former operation is much simpler, thus more secure,

If an attacker can get its bogus data into the referring zone, who
cares whether it's NS data or DS data?  One of the important things we
are trying to add with DNSSEC is some means of assuring ourselves that
the referral we got was the one that comes from the actual authority
for that referall, rather than some other agent spoofing the response.
DNSSEC appears to provide that assurance, and so far you have provded
not one jot of evidence that it does not.

I fail completely to see how it is easier to put the wrong DS record
in the parent than it is to inject bad NS data in there.  If you can
put illegitimate data in, there are two possibilities:

    1.  You put it in via some legitimized mechanism (e.g. via SQL
    injection, you manage to get data that wasn't intended to be in
    the zone into the zone).  This causes that illegitimate data to be
    treated as legitimate, and probably signed and such.  This is a
    bad attack, of course, but it is available today.  This is no
    different than being able to plant some evil file on the corporate
    file server inside the VPN: the security is breached not by
    failure of its mechanisms, but by failure of authentication.
    DNSSEC doesn't solve this, I agree; that's because the
    _provisioning_ of data is beyond the scope of the DNS protocol
    itself.  In any case, surely a more effective attack in this case
    is to get phony NS or A data (or whatever) into the zone than to
    put phony DS data.  The latter will get you at best a DoS, whereas
    the former allows you to take control of the target zone.

    2.  You put it in via some illegitimate mechanism (e.g. by
    intercepting the wire transmission and adding the data to the
    stream).  Unless the keys are somehow compromised, this
    vulnerability is exactly what DNSSEC aims to stop.  I don't see
    any argument from you that this DNSSEC capability is not
    effective.  If you have such an argument, it'd be nice to hear it
    before we continue with the efforts at deployment.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Marc Manthey <[email-masked]>
Date: Thu, 4 Jun 2009 20:18:20 +0200

> So, there is no point to deploy DNSSEC.

no ?

http://jprs.co.jp/en/topics/081125.html

regards

Marc

--   
Les enfants teribbles - research / deployment
Marc Manthey
Vogelsangerstrasse 97
D - 50823 Köln - Germany
Vogelsangerstrasse 97
Geo: 50.945554, 6.920293
PGP/GnuPG: 0x1ac02f3296b12b4d
Tel.:0049-221-29891489
Mobil:0049-1577-3329231
web : http://www.let.de

Please note that according to the German law on data retention,  
information on every electronic information exchange with me is  
retained for a period of six months.

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 05 Jun 2009 08:10:55 +0900

> no ?

No, no point.

> http://jprs.co.jp/en/topics/081125.html

FYI, JPRS, which is a commercial entity to administrate JP domain,
is commercially motivated not to admit it merely an untrustworthy
third party.

In general, registries welcome DNSSEC, no matter how secure it is,
as long as its complicated operation works as an excuse to increase
(or not to reduce) registration charge and registries' revenue.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 05 Jun 2009 08:22:56 +0900

> If an attacker can get its bogus data into the referring zone,

I never said such a thing.

I said "issue certificates over forged keys of child zones".

The attack is possible by those who have access to signature
generation mechanisms and the attack is not visible until the
false certificates are used later.

People introduced DNSSEC believing DNSSEC makes cache poisoning
not a problem, are ready to accept false certificates through
unprotected cache.

Thus, we must, anyway, protect cache.

Then, where is the point to introduce DNSSEC only to have another
possibility of security holes?

						Masataka Ohta

---

From: Doug Otis <[email-masked]>
Date: Thu, 4 Jun 2009 20:32:11 -0700

On Jun 3, 2009, at 8:35 PM, Masataka Ohta wrote:

> cryptographically, but socially secure.

DNS over UDP is prone to port/transaction-id guessing,  where  
cryptography could play a protective role.  The risk of these values  
being guessed increases whenever NATs reduce port diversity, or  
operate in a predictable manner.  Protocols such as SPF that embed  
macros into DNS, allow hundreds of transactions to be chained.  The  
entire chain might result from the local-parts of a single email.  
These transactions can target otherwise uninvolved victims or evil  
domains.  When an evil domain is the target of SPF transactions,  
attackers can discover the nature of the resolver.  Afterwords, with  
only one transaction targeting the evil domain, and others targeting  
their victim, the guesswork for injecting poison is reduced, where  
even ACLs offer no protection.  The growing speed of today's Internet  
makes this an ever growing concern.

While DNSSEC might prevent caches from being poisoned, EDNS0 creates  
new concerns also aggravated by SPF.  Since the 512 byte DNS message  
size did not accommodate RSA signatures, EDNS0 is required to adjust  
message limits.  EDNS0 allows bad actors to further leverage DNS  
transactions, such as those that might emanate from cached SPF records  
to initiate more than 20 TXT record transactions when a recipient  
evaluates a single email.  The TXT records might be policy documents  
not intended for machine consumption or wildcard SPF records  
enumerating address authorizations for outbound MTAs.  The flexibility  
sought by SPF has created a sizable list of concerns, where caution  
was often countered with distain for DNS.

It might have been better to have specified limits for EDNS0, such as  
a minimum message size of 1280 and a maximum at 1424, where  
transactions that don't comply are refused.  UDP allows source  
spoofing, which could allow bad actors a means to create packet  
fragmentation by incorrectly setting message.  If addition, when  
fragmentation does occur, DNS transactional-ids offer little  
protection for packet fragments that may contained unsigned  
information.  DNS will need to be become pedantic about confirming  
information, perhaps also enforcing the use of checksums and message  
size.

While DNSSEC may not require channel security at some point when a  
trust anchor can be safely found, DNS over UDP remains a brute.  When  
an SPF process sequence prematurely times out, rather than waiting for  
exponential back-off, SPF simply begins another sequence, ignoring  
congestion avoidance.

SCTP carrying either DNS or DNSEC packets would ensure DNS remains  
tame despite much of the abuse.  Unlike TCP, SCTP does not commit  
resources without return of a cookie, but can start data exchanges  
sooner.  SCTP can carry simultaneous DNS messages and can can keep a  
large number of sparse connections per port active.  Perhaps recursive  
resolvers might be more responsive with SCTP than with UDP.   
Importantly, the source of abusive DNS behavior can be identified and  
thereby avoided.  This is not true for either TCP or UDP.

-Doug

---

From: Mark Andrews <[email-masked]>
Date: Fri, 05 Jun 2009 14:26:11 +1000

> possibility of security holes?

We still lock doors and windows despite the possiblity of people
breaking in by lifting tiles.  Attacks at the registry level are the
equivalient of lifting tiles.  It happens sometimes.  Locking the
doors and windows stops most attacks however.

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 05 Jun 2009 18:20:22 +0900

> breaking in by lifting tiles.

I'm afraid DNSSEC people have been arguing against SCTP saying
DNSSEC is good enough.

Worse, though I have been warning for these 15 years that cached
glue may be used only for glue with same refferal, a broken
concept of bailiwick was introduced only to enable so called
Kaminsky attack.

> Attacks at the registry level are the
> equivalient of lifting tiles.  It happens sometimes. 

Protection of DNSSEC at the registy level is equivalent
to protection against lifting tiles. Not practical at all.

> Locking the doors and windows stops most attacks however.

Then, let's lock the doors and windows first, before working on
DNSSEC.

						Masataka Ohta

---

From: Bill Manning <[email-masked]>
Date: Fri, 5 Jun 2009 04:13:37 -0700

So quit trying to be a dead horse that is not even there.
If you are so interested in transport layer security, then
by all means, encourage, promote, and develop solutions.

STCP is one such measure.  IPSEC is another.  there are 
many choices.

transport level security (integrity, authenticity) are orthoginal
to application level security (DNSSEC, SSH, HTTPS, etc)

DNSSEC was never designed to provide or assure end to end security
as seen at the transport layer.  It couldn't, since its not a transport
protocol.

or is there some subtle nuance that I am missing in your arguement
that is being overshadowed by your strident insistance that DNSSEC is
not secure end to end.  I agree with you that it is not, and I say
so what... thats not what it was designed for.  

-- 
--bill

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 05 Jun 2009 21:32:04 +0900

> by all means, encourage, promote, and develop solutions.

The discussion of the paper of David Clark about public key is not
on a transport but on an administrative layer.

The paper says:

	However, there is a key role for a third party, which is to
	issue a Public Key Certificate and manage the stock of such
	certificates; such parties are called certificate authorities.

and the issuance and management of certificates, which is the key,
involves no transportation of the certificates and is not transport
but local (local to zone) administrative issues.

Or, if you insist the paper discusses on transport layer security
of public key cryptography, please feel free to quote the relevant
part of the paper.

I mention transport security merely because it is still required
with DNSSEC, because administrative security of DNSSEC is
cryptographically weak.

So, let's throw away DNSSEC and the broken-from-the-beginning
idea of bailiwick. Let's move on to lock the doors and windows.

						Masataka Ohta

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 5 Jun 2009 08:38:14 -0400

> (or not to reduce) registration charge and registries' revenue.

That is a serious charge.  I've seen no evidence that DNSSEC
represents a revenue opportunity for registries.  On the contrary, so
far as I've seen, most registries are introducing it without any fee,
even though it represents a substantial additional operational cost.
(Indeed, some of us were at times under the impression that the
practical inability to charge anything in order to offset this
additional cost was one of the biggest barriers to DNSSEC deployment.)
What registries are you thinking of that are charging extra for DNSSEC
delegations (i.e. for accepting a DS record)?

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 05 Jun 2009 22:15:38 +0900

Shane Kerr wrote:

> I think we all understand that it is possible to inject bad data into
> the DNS at the parent.

What do you mean "the parent"?

Do you mean master zone file of the parent or some caching server
expected by a client to have parent data?

> What I do not understand about this comment is how transport security
> can help in that case. Can you please explain?

Explanation depends on your definition of "the parent".

							Masataka Ohta

---

From: David Wilson <[email-masked]>
Date: Wed, 03 Jun 2009 21:38:39 +0100

> Yes, security of DNSSEC is totally hop by hop.

I am nervous of adding to this debate (and should it really be on ASRG?)
However, I think there is some difference in the way people are using
some terms. My understanding of the terms hop-by-hop and end-to-end is
this:

A data item traverses a number of nodes within a network. (E.g. a UDP
datagram moving through an inter-network, or a Email message from its
submitting UA via a sequence of MTAs to the recipient's UA).

"End-to-end" security means that the security of that data item does not
depend on the trustworthiness of any intermediate node, or channel.

"Hop-by-hop" security means that you do rely on the trustworthiness of
the intermediate nodes and channels. (E.g. CRC provides no defence
against deliberate tampering, TLS for email is only as trustworthy as
the least trusted intermediate MTA).

PKI establishes a "chain of trust" between the signing certificate (i.e.
the certificate containing the public key corresponding to the private
key used to generate the signature) and your trust anchors (which you
choose). This is not really "hop-by-hop" as data is not hopping. Like a
real chain, it is only as strong as its weakest link. However, the chain
operates in a different 'space' from that used to transfer the data
being protected. 

As far as I understand, the key thing which DNSSEC gives you is data
origin authentication (although that by itself without data integrity
would be useless). The DNS attacks which were the start of the
discussion are all based on the attacker sending false data to the
system under attack. Having an effective means for determining from whom
data comes is necessary to overcome this kind of attack.

best regards

David Wilson

---

From: Christian Huitema <[email-masked]>
Date: Wed, 3 Jun 2009 00:23:58 -0700

> new there. I don't think any DNSSEC expert ever claimed differently.

Even in the presence of the "attack by a trusted party", there are still huge differences between DNSSEC and "transport-hop-by-transport-hop" security. Transport based solution, SCTP or TCP, are open to attacks by any party in the path between two hops -- NAT routers come to mind. DNSSEC is immune to such attacks, a big advantage in practice.

Also, it is actually possible to improve on DNSSEC by introducing additional knowledge. If two domains have an establish relation, their servers can memorize the relevant public keys. If a host has a relation with a domain, it can memorize that domain's public key. This kind of "peer-to-peer" improvement makes the domain-to-domain or host-to-domain DNSSEC service immune to attacks by nodes higher in the hierarchy.

-- Christian Huitema

---

From: Shane Kerr <[email-masked]>
Date: Fri, 05 Jun 2009 14:41:28 +0200

Ohta-san,

Thanks,

--
Shane

---

From: Shane Kerr <[email-masked]>
Date: Fri, 05 Jun 2009 16:12:34 +0200

Ohta-san,

> expected by a client to have parent data?

I "the parent" in the same sense as in RFC 1034 - the delegating level.
So, for EXAMPLE.COM this would be COM.

--
Shane

---

From: Paul Wouters <[email-masked]>
Date: Fri, 5 Jun 2009 12:44:52 -0400 (EDT)

> Also, it is actually possible to improve on DNSSEC by introducing additional knowledge. If two domains have an establish relation, their servers can memorize the relevant public keys. If a host has…

How do you handle key changes? How do you determine if the key change
is performed by the domain holder or an attacker?

There is no reason for such a "leap of faith" caching. In fact, with
SSHFP records, we can also nail down that leap of faith for ssh finally :)

Paul

---

From: Doug Otis <[email-masked]>
Date: Fri, 5 Jun 2009 11:37:05 -0700

On Jun 3, 2009, at 12:23 AM, Christian Huitema wrote:

>> relationships. Indeed, DNSSEC security is limited to the weakest  
>> link along the chain from the bottom to the top of the DNS  
>> hierarchy. Nothing new there. I don't think any DNSSEC expert ever  
>> claimed differently.
>
> Even in the presence of the "attack by a trusted party", there are  
> still huge differences between DNSSEC and "transport-hop-by- 
> transport-hop" security. Transport based solution, SCTP or TCP, are  
> open to attacks by any party in the path between two hops -- NAT  
> routers come to mind. DNSSEC is immune to such attacks, a big  
> advantage in practice.
>
> their servers can memorize the relevant public keys. If a host has a  
> relation with a domain, it can memorize that domain's public key.  
> This kind of "peer-to-peer" improvement makes the domain-to-domain  
> or host-to-domain DNSSEC service immune to attacks by nodes higher  
> in the hierarchy.

Private ad-hoc caching of keys would make DNS fairly fragile.   While  
the trust anchor issue for DNSSEC looms, DNS will remain prone to  
inadvertently cached unsigned content.   Benefits obtained by using  
DNS over SCTP would be significant protection from out-of-path  
poisoning, whether information is signed or not.  Once DNSSEC is fully  
implemented and trust anchor issues are resolved, information  
contained within DNS would not depend upon transport protections.   
When that might happen remains unknown.  However, once DNSSEC becomes  
widely adopted, the Internet may need protection from UDP/EDNS0 source  
spoofing.  For this, SCTP would offer protection from source spoofing  
that DNSSEC does not prevent.  EDNS0 should also have min/max limits  
imposed, where packets of a greater size should  be handled by SCTP.

The brute force strategy that allows DNS over UDP to cope with source  
spoofing and misuse, also makes DNSSEC over UDP a greater risk.  UDP  
does not lend itself to being moderated or flow controlled, as some  
suggest.  Although TCP permits flow control, TCP is much more  
vulnerable to resource exhaustion, creating significant costs when  
defending TCP services compared to those using UDP or SCTP.   
Reliability, performance and DDoS immunity makes SCTP an attractive  
solution over TCP.  SCTP should perform well as a transport for either  
DNS or DNSSEC.  SCTP would also provide improved security and  
performance for HTTP as well. :^)

-Doug

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 06 Jun 2009 12:04:30 +0900

> So, for EXAMPLE.COM this would be COM.

If you mean COM zone, it is not necessary to inject any data into
the zone.

You, instead, can inject a forged certificate into some cache used
by your victim.

It will be extremely easy if people are deceived that DNSSEC were
so secure that no proteciton on cache were necessary.

							Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 06 Jun 2009 13:09:38 +0900

David Wilson wrote:

> some terms.

According to the terminology of David Clark, PKI including DNSSEC
is not secure end to end.

> depend on the trustworthiness of any intermediate node, or channel.

According to the terminology of David Clark, certificate authorities
are intermediate nodes.

If you have different terminology, use it outside of the Internet
community but not within.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 08 Jun 2009 14:22:28 +0900

Phillip Hallam-Baker wrote:

> I was at a dinner with Dave Clarke last week. Those who invoke his
> name in these arguments rarely seem to have read his paper on the end
> to end principle IN NETWORKING.

Which paper is, are you saying, "his paper"? The original one or
latter one (published in 2001) which includes discussion on PKI,
which I referred in previous mails.

As you say "IN NETWORKING", I'm afraid you haven't read his original
paper "END-TO-END ARGUMENTS IN SYSTEM DESIGN", which is on "system
design" in general and not necessarily "in networking". For example,
in the original paper, RISC (Reduced Instruction Set Computer) is
given as an example of end to end design.

> Depending on your level of abstraction you choose to work at you can
> argue that anything is an end.

Apparently, he taught you basic points in his original paper
but not beyond.

It is discussed in the original paper that:

	Identifying the ends
	Using the end-to-end argument sometimes requires subtlety
	of analysis of application requirements.
	one must use some care to identify the end points to which
	the argument should be applied.

Beyond the original paper, the application of the end to end
argument to PKI including DNSSEC is discussed in his latter
paper in 2001 with PROPERLY IDENTIFIED "end points". In the
paper, certificate authorities are identified to be third
parties. 

With the discussion, there is no point denying "DNSSEC is NOT
secure end to end".

> It would be nice if the paper was available in unencumbered form.

Both of the papers are freely downloadable.

The original paper:

http://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.pdf

The paper in 2001:

http://www.csd.uoc.gr/~hy558/papers/Rethinking_2001.pdf

You should have read both of them to make the dinner more valuable.

> Publication in ACM does not help anything but the author's academic
> career.

I gave a link to the paper in 2001 through ACM because it has DOI,
assuming that anyone can use search engines and that all the people
who talks about the end to end principle should have read the
original paper in advance.

						Masataka Ohta

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 08 Jun 2009 11:25:36 +0200

> even though it represents a substantial additional operational cost.

The organization operating .SE charges for DNSSEC.  According to [1] it
costs 250 SEK annually (~22 EUR or ~30 USD) extra per year to protect a
domain name with DNSSEC.

/Simon

[1] http://www.iis.se/docs/se-dnssec_-_broschyr_eng_ny_.pdf

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 08 Jun 2009 21:46:20 +0900

> You said transport security can help. How can it in this case?

With plain old DNS, zone administrators have to make master
zone files secure not to include forged data.

Other administrators take care of transport security, for example,
to make port numbers randomized, which makes plain old DNS
reasonably secure.

With DNSSEC, however, a new administration mechanism to generate
signatures is mandated, which is NOT automagically secure and
introduces new administrative security holes.

Thus, even if master zone files are administrated as secure as
plain old DNS administration, the signature generation mechanisms
may be hacked.

Unlike forgery on master zone files, which is published and
detected by periodic checking by thid parties, attack by
unpublished forged signature will not be noticed until a victim
is attacked, the victim noticed the (resulting loss by successful)
attack and the victim has sufficient knowledge on DNSSEC.

Still, the victim may be protected, if the victim can not be
injected forged signature through transport.

> Also, how can you create a forged certificate?

By attacking signature generation mechanisms, which is a security
hole specific to DNSSEC not shared by plain old DNS.

Note that DNSSEC does not give any cryptographical protection
against attacks on the signature generation mechanisms.

						Masataka Ohta

---

From: Mans Nilsson <[email-masked]>
Date: Mon, 8 Jun 2009 14:49:11 +0200

> costs 250 SEK annually (~22 EUR or ~30 USD) extra per year to protect a
 
Not anymore; it is included with the registration since .SE went to a
registry-registrar model a year ago. However, the registrar may choose
to charge for the work associated with doing DNSSEC.

-- 
Måns Nilsson

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 08 Jun 2009 22:04:10 +0900

>>That is a serious charge.

> costs 250 SEK annually (~22 EUR or ~30 USD) extra per year to protect a

That is the serious charge.

Thank you for the information.

Are there anyone who is not working for registries and is still
interested in deploying DNSSEC for the extra charge despite the
lack of cryptographic security?

If not, let's conclude the thread with a consensus to abandon DNSSEC.

						Masataka Ohta

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 08 Jun 2009 17:12:48 +0200

> to charge for the work associated with doing DNSSEC.

That is good to hear.  It would be better if the web pages would reflect
the new order.

/Simon

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 8 Jun 2009 00:02:31 -0400

The end to end security argument came earlier, it is referenced as an
antecedent to lend support to the then novel idea of applying it to a
network. And it is an argument about the best place to manage
complexity.

No internet security is end to end, no internet security protocol can
be end to end as the ends of the security relationship are PEOPLE and
ORGANIZATIONS.

It would be nice if the paper was available in unencumbered form.
Publication in ACM does not help anything but the author's academic
career. There are real problems with DNSSEC but not those that tend to
gain advancement there,

On Sat, May 30, 2009 at 7:27 PM, Masataka
Ohta<[email-masked]> wrote:
>> PS (*): I use the common meaning of end-to-end, not Masataka Ohta's one.
>

-- 
-- 
New Website: http://hallambaker.com/
View Quantum of Stupid podcasts, Tuesday and Thursday each week,
http://quantumofstupid.com/

---

From: Shane Kerr <[email-masked]>
Date: Mon, 08 Jun 2009 10:36:15 +0200

Ohta-san,

--
Shane

---

From: David Wilson <[email-masked]>
Date: Mon, 08 Jun 2009 20:54:09 +0100

> is not secure end to end.

DNSSEC provides two things. Firstly, it provides the means to digitally
sign RRsets. This provides data origin authentication and data
integrity. As this operates at the DNS application layer, this is
clearly "end to end" within David Clark's terminology. It does not rely
on any security services in the lower communication layers (in the way
that, for instance, relying on TCP would).

This origin authentication and integrity is precisely what is required
to avoid the DNS cache poisoning which is the kind of vulnerability
which prompted this discussion.

This aspect of DNSSEC does not require the use of any PKI. A security
aware resolver can obtain by some out-of-band means the public signing
key for some "island of security", and choose to trust that key.

However, such bilateral arrangements do not scale to the Internet. So,
DNSSEC provides a means for an Authentication Chain, to use the specific
DNSSEC term. A signed zone can authenticate the key of a child zone.
There is a chain here. However, it is of a significantly different
character to a communication network. Whether it is "end to end" or not,
is for a different discussion.

> community but not within.

I get the impression from you that DNSSEC is to be disregarded because
it is not "end to end". However, the opinion of "the Internet community"
as regards DNSSEC has been made clear in the last few days, given these
announcements:

http://www.nist.gov/public_affairs/releases/dnssec_060309.html

http://pir.org/index.php?db=content/Website&tbl=ORG_Advantage&id=2

http://www.networkworld.com/news/2009/022409-verisign-dns-security.html?hpg1=bn

If the Internet community agrees with you that DNSSEC is not "end to
end", then this does not seem to divert them from implementing it.

best regards

David

---

From: David Wilson <[email-masked]>
Date: Mon, 08 Jun 2009 21:28:57 +0100

> given as an example of end to end design.

Er, no. The article states:

"The arguments that are used in support of reduced instruction set
computer (RISC) architecture are similar to end-to-end arguments."

I.e. the arguments for end to end are similar to the arguments for RISC.
This is not the same as saying that RISC is an example of end to end
design.

> You should have read both of them to make the dinner more valuable.

[Interesting articles, which took me back to discussions 20 years ago as
regards connectionless vs. connection oriented networks.]

It is clear from both of these that the basic subject is data
communication over a communication system. Thus the second article
quotes from the first article thus:

"The function in question can completely and correctly be implemented
only with the knowledge and help of the application standing at the
endpoints of the communications system. Therefore, providing that
questioned function as a feature of the communications systems itself is
not possible."

So the basic object under consideration here is a "communication
system". 

It is clear from the first article that what is envisaged is a layered
model, (c.f. the conclusion). I would not be surprised if this kind of
thinking was input to the development of the OSI model for data
communications, which does set out to assign to each layer an
appropriate function.

The basic thesis of the article is that functions concerned with, for
instance, security and reliability are best done in the upper layers,
even the top (application) layer, as the application cannot rely
entirely on the lower layers to "do their stuff".

Thus "end to end" is about communication from one application layer to
the peer application layer down through the layers at one system, and
then up through the layers at the other system. So, I would paraphrase
the "end to end design principle" as the "application to application"
design principle.

I note that in models like the OSI model, only the lowest layer have
intermediate systems. (That's why layer 3 is called the network layer).
The article in no way implies that it is the existence of intermediate
systems which is the deciding factor in the design. "End to end" is not
in contrast to "hop by hop".

So, applying this to DNSSEC's PKI, this is clearly an application layer
security system. The system does not depend upon the security or
reliability of any lower layers (or, indeed, intermediate systems). So,
it would seem to fit the "end to end design" of this article.

The second article is a discussion about how the end-to-end design
principle might need to be modified in the light of the realities of the
modern Internet. In the present context of DNSSEC, the discussion of
trust is important.

best regards

David

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 09 Jun 2009 08:54:48 +0900

> integrity.

The provision is through hops of certificate authorities, which
is what is discussed in latter paper of David Clark published in
2001. Read it.

> As this operates at the DNS application layer, this is

If you read the paper, you can find the lower layer of PKI consists
of communication with or between certificate authorities.

Compromising a certificate authority in the lower communication
layer breaks the security of data origin authentication and data
integrity.

> which prompted this discussion.

As has been discussed in the thread, DNSSEC is NOT a protection
against cache poisoning, because caches poisoned with forged
certificate breaks the security.

> This aspect of DNSSEC does not require the use of any PKI.

Read the 2001 paper on why PKI not end to end and why DNSSEC no
exception. The paper explains why scale breaks the end to end
property.

> it is not "end to end".

Being "end to end" has practical advantages.

See above on how useless DNSSEC is to avoid cache poisoning, which
was the motivation to deploy it.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 09 Jun 2009 09:23:33 +0900

> Er, no. The article states:

The paper states:

	any attempt by the computer designer to anticipate the
	client's requirements for an esoteric feature will
	probably miss the target slightly and the client will end
	up reimplementing that feature anyway

which is an end to end argument where communication is at high
level between computer designers and their clients.

> communication over a communication system.

That is true only with the widest meaning of "communication". However,
"IN NETWORKING" by Phillip has a lot narrow meaning and even the
original paper says:

	A version of the end-to-end argument in a non-communication
	application was developed in the 1950's by system analysts
	whose responsibility included reading and writing files on
	large numbers of magnetic tape reels.

> So, applying this to DNSSEC's PKI, this is clearly an application layer

If you want to draw some conclusion from the 2001 paper, quote
text from the paper. There is no point to reiterate it with
your subtly modified terminology only to give a subtly modified
impression on the content of the paper.

> modern Internet.

That is an explanation on the motivation to write the paper and
the conclusion of the paper is:

	We argue that the open, general nature of the Net, which
	derived from the end to end arguments, is a valuable
	characteristic that encourages innovation, and this
	flexibility should be preserved.

which means the end to end argument is not modified.

Instead, the paper, for example, says for regulations to be
realistic, they should follow the end to end principle.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 09 Jun 2009 12:37:26 +0900

Phillip Hallam-Baker wrote:

> Please learn to express your opinions in a manner that is appropriate
> to a professional forum rather than a bar room brawl.

> The link you gave was to a paywalled version of the paper. I did not
> bother to read the authors once I discovered it was paywalled.

Thank you for demonstrating a perfect manner for a professional
forum to deny a reference to an ACM article because it is paywalled.

So, we, professionals, should, of course, not discuss about DNS,
because domain registration is not free but badly monopolized.

Before closing the discussion, cloud you teach me the name and
location of the restaurant you have had dinner with David Clark
obviously free of charge?

Free dinner is better than free lunch.

						Masataka Ohta

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 9 Jun 2009 08:54:13 -0400

Hi,

[ASRG removed, since I cannot see even a little bit how this is
on-topic there.  But if you think it is, feel free to republish this
as you like.]

> certificate breaks the security.

To beat the stain on the ground that betokens the long-since-passed
equine presence, you haven't answered the question, posed to you
several times, how this poison-with-forged-certificate is supposed to
work.

If I have a validating resolver, and I get data from a poisoned cache,
then I attempt to validate the signature over that data, checking
the chain of signatures from that data all the way back to some trust
anchor I have configured.  Therefore, in order to poison a cache with
a forged certificate, one of two things has to have happened:

    1.  The forger managed to forge keys and inject them in the
    poisoned cache such that one of those keys will be valid according
    to the trust anchor I have installed.  Is this the threat you
    claim?  If so, and assuming you're not saying that the crypto is
    weak (in which case we have way bigger problems than forged DNS
    data), that just seems to be a claim that the signing procedures
    can be subverted.  And yes, of course, a security system is
    possibly subverted by poor operation.  I'm not sure what the
    surprise is supposed to be here.  You can argue just as easily
    that the DNS is badly secured because it's possible to convince a
    registrar to publish the wrong data for a domain (a problem we've
    certainly seen in action more than once).  It is indeed possible
    to get bad data into the system, and DNSSEC doesn't completely
    protect against such bad data coming in; but that is no criticism
    of DNSSEC.

    2.  The forger managed to forge data that is not validatable in a
    chain from any trust anchor I have, and managed to convince me to
    trust it anyway.  If this is the threat you claim, I want to know
    how this works.  If you're right, then DNSSEC is indeed completely
    broken.  We need to know that now, before more deployment goes on.

If neither of (1) or (2) happens, then my attempt to validate the data
will fail, marking the data bogus.  It is true that this is a vector
for denial of service: I won't connect to a site with invalid DNS
data.  I'm having a hard time coming up with a reason why that is
worse than "I go to the site controlled by Dr Evil."  

Best regards,

Andrew

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: David Wilson <[email-masked]>
Date: Tue, 09 Jun 2009 09:05:15 +0100

On Tue, 2009-06-09 at 08:54 +0900, Masataka Ohta wrote:
> The provision is through hops of certificate authorities,

As I clearly stated, the actual signing is end to end, and if the
receiver has chosen to trust the explicit key used to sign, there is no
involvement of PKI. The presence of a valid digital signature is good
evidence that the data originated in that form from the owner of the
private key corresponding to the public key used for verification.

> which is what is discussed in latter paper of David Clark published in
> 2001. Read it.

I have, and I cannot find any explicit sentence which uses the phrase
"hops of certificate authorities". Nor can I find any statement which
states anything to the effect "PKI is not end to end and is therefore
bad". If these are present, please point them out. He does state "Each
interaction is nominally ... but its robustness depends on the larger
context composed of the whole sequence."

It does state, in effect, "PKI is difficult" (particularly because of
the revocation problem) but that is well known. But it also gives me the
impression that it says that this kind of thing is necessary, because of
the trust issue on the modern Internet.

I'm not sure of the reason for your insisting that DNSSEC is not end to
end.

I must apologise to the Asrg list for continuing this discussion, which
seems to have just gone down a pointless semantic hole.

---

From: David Wilson <[email-masked]>
Date: Tue, 09 Jun 2009 09:17:00 +0100

> certificate breaks the security.
I think you need to explain how this happens in detail. For instance, an
attacker wishes to poison the cache of some ISP's DNS server for
'example.com.". Currently, it gets the server to request information
about example.com from its authoritative server, and sends information
that purports to be from that server. It needs to guess some properties
of the original request, but there have been and are various features of
DNS servers which make this easier than you might think. Without DNSSEC,
the attacked DNS resolver simply accepts the information.

With DNSSEC, a security aware resolver will want to check the signature.
The information is only accepted if the signature checks out, and the
key is trusted. If the key is a trust anchor, then the check is
complete. If not, then the resolver needs to get the DS RR for
example.com from com's DNS server. This information is itself signed
with com's signing key. So, it will not accept that unless it verifies.
If com's signing key is not a trust anchor, then it will get com's DS RR
from the root. Also signed by root, and the root key is probably a trust
anchor.

If any of this information is not available, or is not signed, then the
trust chain is not present, and the original information is not accepted
by the security aware resolver.

So, perhaps you can explain how an attacker can get a security aware
resolver to accept information which will subvert this?

I think you have proposed that an attacker might explicitly subvert the
chain. In this case it would involve getting the com DNS server to
accept a DS RR for example.com. This is altogether harder problem for
the attacker, and is of a significantly different character than cache
poisoning, as it involves actual changes to the DNS servers, rather than
just persuading resolvers to accept incorrect information.

But, perhaps this mechanism would better be reported to people other
than the asrg.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 8 Jun 2009 22:37:38 -0400

Masataka-san

You are entitled to your opinion but not to converse in the abusive
and insulting manner you have chosen to use if you wish to receive a
reply.

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 10 Jun 2009 09:18:22 +0900

> I think you need to explain how this happens in detail.

In detail??? See below.

> With DNSSEC, a security aware resolver will want to check the signature.

Except for glue A.

							Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 10 Jun 2009 09:39:16 +0900

> As I clearly stated,

As we are discussing on concepts described in two papers, your
own statement without proper quotation from the papers does
not mean anything.

> the actual signing is end to end,

The security hole is located not between certificate authorities
but within certificate authorities.

To quote from the 2001 paper,

	Transactions based on a wellknown public key can be rather
	simple two-party interactions that fit well within the end
	to end paradigm. However, there is a key role for a third
	party, which is to issue a Public Key Certificate and
	manage the stock of such certificates; such parties are
	called certificate authorities.

the first sentence roughly corresponds to your statement "the
actual signing is end to end", however...

And the third parties of certificate authorities constitute
a chain, a channel, hops or whatever terminology you might
use, which is not end to end.

						Masataka Ohta

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 10 Jun 2009 12:59:11 -0400

> > With DNSSEC, a security aware resolver will want to check the signature.

That's not a vector for attack.  Glue records from the parent side of
the cut are not authoritative data in the parent zone, because the
zone in question has been delegated away.  They're only to be used to
stick the two sides of the cut together.  (Indeed, treating the
parent-source glue data as authoritative and reusing it as answer data
is in fact a source of poison attacks, as you have quite cogently
pointed out more than once.)  If you are validating data, why would
you not follow the chain to the glue record (secured on each side of
_that_ cut by the DS/DNSKEY pairs) and validate the signature on the
authoritative data you get?  You'll get a signature over the A record
from the child server, and that signature will either pass or fail
validation according to the same rules as before.  (Glue records on
the child side do, of course, come with RRSIGs which can be validated
just like anything else.)

I think people have already heard enough from me on this topic, so I
won't post on it any more.  But if you have a real attack that
actually works against DNSSEC in the cases you keep insisting it does,
please show it.  Otherwise, please stop insisting DNSSEC is broken.
You haven't shown that it is, and you seem to be making no effort to
provide such a demonstration.  There's no question that DNSSEC is
complicated, and that it provides a whole new pile of ways for zone
administrators to screw things up: new features provide a new
opportunity for mistakes.  But that's nowise a proof that DNSSEC
itself does not do what it says it does.

Best regards,

Andrew

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 11 Jun 2009 07:54:52 +0900

> That's not a vector for attack.

Glue is the vector for most, if not all, attacks including
Kaminsky's and DNSSEC with forged certificates.

> If you are validating data, why would
> authoritative data you get?

Following the chain over a forged certificate to confirm
forged data have valid signatures?

Or, what if the glue is inside a grand child zone on which no
nameservers are responding?

When DNSSEC was designed, I pointed out several detailed
but fatal problems including that glue can not be secured.
The WG had a different fantasy. The WG wasted about 10 years
for experimental deployment only to confirm that I have been
perfectly correct and the protocol was modified.

So, you don't have to waste yet another 10 years only to
reconfirm it.

>>>With DNSSEC, a security aware resolver will want to check the signature.

which makes DNSSEC as insecure as plain old DNS.

						Masataka Ohta