Subject: Let's move on - Let's DNSCurve Re: DNSSEC is NOT secure end to end

From: Joe Baptista <[email-masked]>
Date: Fri, 5 Jun 2009 11:52:07 -0400

On Fri, Jun 5, 2009 at 8:32 AM, Masataka Ohta <
[email-masked]> wrote:

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

Words of wisdom.  I however propose we do not throw it away.  I propose it
be allowed to wither on the vine until DNSSEC life signs show it as being
dead.  Then the IETF can then do it's job and give it the proper burial it
deserves.

I propose all developers simply secure the DNS.  A transparent solution tha
is available NOW - is DNSCurve.  Will ensure the end to end transport of DNS
UDP packets is secure.  And that basically fixes once and for all the
insecurity we have in the UDP transport.

DNSCurve encrypts all DNS packets.  DNSSEC does not.

DNSCurve cryptographically authenticates all DNS responses, eliminating
forged DNS packets.  DNSSEC does not.

DNSCurve very quickly recognizes and discards forged packets, so attackers
have much more trouble preventing DNS data from getting through. DNSSEC does
not.

so I ask you - who wins the cookie in this race?

regards
joe baptista

-- 
Joe Baptista

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

---

From: Stephen Kent <[email-masked]>
Date: Wed, 10 Jun 2009 13:11:45 -0400

Joe,

You have argued that DNSSEC is not viable because it requires that 
everyone adopt IANA as the common root.  I agree that under the 
current IANA management situation many folks may be uncomfortable 
with IANA as the root.  However, in practice, the world has lived 
with IANA as the root for the non-secure version of DNS for a long 
time, so it's not clear that a singly-rooted DNSSEC is not viable 
based on this one concern.  Moreover, DNSSEC is a form of PKI, an din 
ANY PKI, it is up to the relying parties to select the trust anchors 
they recognize.  In a hierarchic system like DNS, the easiest 
approach is to adopt a single TA, the DNS root. But, it is still 
possible for a relying party to do more work and select multiple 
points as TAs. I would expect military organizations in various parts 
of the world to adopt a locally-managed TA store model for DNSSEC, to 
address this concern. However the vast majority of Internet users 
probably are best served by the single TA model.

As for DNSCurve, I agree with the comments that several others have 
made, i.e., it doe snot provide the fundamental security one wants in 
DNS, i.e., an ability to verify the integrity and authenticity of 
records as attested to by authoritative domains, din the face of 
caching.

Steve

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 10 Jun 2009 16:38:08 -0400

Steve,

The sovereign nations that object to US control of the root are
willing to accept the current status quo preciely because they have an
exit option. Should the US defect on its obligations and order ICANN
to drop Cuba or Palestine out of the root or to take any other action
that was considered to be abusive, the countries that objected could
simply direct their local ISPs to redirect all IP traffic to the A
thru M root servers to another set of servers of their choice.

At the moment the ICANN has the theoretical ability to defect, but can
only do so at the cost of becomming irrelevant. The global DNS outside
the US would swiftly pass to the ITU.

With the proposed root arrangement for DNSSEC, this changes. Not only
does the US have effective control, it has perpetual control of any
apparatus that chains to the ICANN root of trust.

This is bad for the US, bad for ICANN and bad for other sovereign
states. First, consider the likely source of a defection, some idiot
member of Congress from Florida grandstanding for votes. Such a move
is going to give the career civil service a fit, particularly the
diplomats who prefer to end rather than begin international crises. I
have spoken to very enior members of this administration on this
topic, they had come to the exact same conclusion themselves.

Now consider ICANN. Let us imagine that they do hold the master root
key. What is then to stop some armed terrorist nut cases laying siege
to the key repository? Their objective might not be to drop a country
out, they might want to insert some irredentist domain of their own.

Ordinary PKIs are not subject to this type of pressure, because they
are not the lynchpin of the global communication system.

While the various splinter-roots may appear to be complete jokes, they
have had one significant result, they have drawn attention to the
issue. In particular very much doubt that the Turkish secret service
are too amused at the whole process given some of their experiences.

On Wed, Jun 10, 2009 at 1:11 PM, Stephen Kent<[email-masked]> wrote:
> Joe,
>
> You have argued that DNSSEC is not viable because it requires that everyone
> adopt IANA as the common root.  I agree that under the current IANA
> management situation many folks may be uncomfortable with IANA as the root.
>  However, in practice, the world has lived with IANA as the root for the
> non-secure version of DNS for a long time, so it's not clear that a
> singly-rooted DNSSEC is not viable based on this one concern.  Moreover,
> DNSSEC is a form of PKI, an din ANY PKI, it is up to the relying parties to
> select the trust anchors they recognize.  In a hierarchic system like DNS,
> the easiest approach is to adopt a single TA, the DNS root. But, it is still
> possible for a relying party to do more work and select multiple points as
> TAs. I would expect military organizations in various parts of the world to
> adopt a locally-managed TA store model for DNSSEC, to address this concern.
> However the vast majority of Internet users probably are best served by the
> single TA model.
>
> As for DNSCurve, I agree with the comments that several others have made,
> i.e., it doe snot provide the fundamental security one wants in DNS, i.e.,
> an ability to verify the integrity and authenticity of records as attested
> to by authoritative domains, din the face of caching.
>
>
> Steve
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf
>

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

---

From: Mark Andrews <[email-masked]>
Date: Thu, 11 Jun 2009 10:41:34 +1000

In message <p06240803c65430cf6e92@[10.10.10.117]>, Stephen Kent writes:
> everyone adopt IANA as the common root.

Which isn't even a requirement.  Alternate root providers just need
to get copy of the root zone with DS records and sign it with their
own DNSKEY records for the root.

ISP's that choose to use alternate roots might get complaints however
from their customers if they are validating the answers using the
trust-anchors provided by IANA.  This however should be seen as a
good thing as the ISP can no longer tamper with the DNS without
being detected.  If a ISP can convince all their customers that the
alternate roots are a good thing then this won't become a issue.

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

---

From: Stephen Kent <[email-masked]>
Date: Thu, 11 Jun 2009 10:13:46 -0400

>alternate roots are a good thing then this won't become a issue.

Fair point, although I think we all want to avoid the sort of 
Balkionization that this suggests.

Steve

---

From: Richard Barnes <[email-masked]>
Date: Thu, 11 Jun 2009 10:28:00 -0400

Phil,

That's a specious argument.  As several others have noted on this list, 
it's perfectly feasible for any relying parties (sovereign nations or 
otherwise) to not use the IANA root, simply by creating their own root. 
  This is a little more complicated than just redirecting IP traffic, 
but not by much.

To quote from Mark's earlier message:

Mark Andrews wrote:
 > Stephen Kent writes:

--Richard

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 10 Jun 2009 21:30:45 -0400

It is possible for people set their own roots, but it is not very
practical to maintain them. And this is going to be particularly
difficult if we ever get DNSSEC deployed in platform distributions and
end-entities are configured to check their own DNS chains up to a
baked-in ICANN root.

It is not a sustainable model. Here is what I propose instead, it is a
variation of ideas Carl Ellison and Phil Zimmerman have proposed in
the past, it is thus entirely unencumbered:

1) There are multiple public signers for the apex zone signing key.
These are moderately serious entities employing trustworthy hardware,
secure facilities etc. They publish a CPS describing their practices.

2) Each relying party selects the subset of apex signers they are
willing to trust and the conditions for accepting a signature. This
may be 3 out of 5 or 4 out of 7 or anything the relying party decides.

3) Applications, Servers, etc. ship with default quorum conditions
configured but these can be over-ridden.

This has a number of interesting effects:

1) We have eliminated the incentive to default, not just placed
controls that make it difficult to default. While an apex signatory
can defect, they cannot profit unless they can persuade others to
collude with them. Relying parties can make this rather unlikely by
choosing apex signers that are entirely unlikely to collude (Cuba,
France and the US).

2) Parties that feel that the US has too much influence in the DNS
have something that they can do to counter that influence. Instead of
sitting on the sidelines and throwing spanners into the works, the
countries concerned about their sovereignty being infringed can start
their own apex signatory authority.

3) The system can be stable over very long periods of years, centuries
even, even if the apex signer authorities are not stable. This makes
it viable for a corporation to be a signer. While it is most unlikely
that Google will disappear in the next 5 years, any company can go
bust over a course of decades, as GM and Chrysler are demonstrating.

The same approach can be extended to support long term repositories of
digital data. So imagine that we wanted to set up a long term
repository of academic journal articles in electronic form. Most
people who propose these things understand the necessity of physical
duplication of the data storage, but not the need for failsafe design
of the management institutions.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 11 Jun 2009 11:00:03 -0400

OK, how do you do that if the ICANN root is baked into your broadband
router? How about a light switch?

Yes in theory I can reverse engineer the code. In practice this is not
practical. In theory the music industry could set up their own
alternative to iTunes, in practice they have no choice but to deal
with Apple.

Most cell phones ship with only a small number of SSL roots and the
end user has no ability to change them.

You can change the signing key, but distributing and embedding the
verification key is a whole different issue. The reason that VeriSign
can charge a premium for certs is because its verification roots are
the most widely embedded.

You may disagree with my arguments here, but you do not have the
standing to call them 'specious'.

On Thu, Jun 11, 2009 at 10:28 AM, Richard Barnes<[email-masked]> wrote:
> Phil,
>
> That's a specious argument.  As several others have noted on this list, it's
> perfectly feasible for any relying parties (sovereign nations or otherwise)
> to not use the IANA root, simply by creating their own root.  This is a
> little more complicated than just redirecting IP traffic, but not by much.
>
>>> everyone

---

From: Mark Andrews <[email-masked]>
Date: Fri, 12 Jun 2009 10:48:31 +1000

In message <[email-masked]>, Phill
> router? How about a light switch?

	Given that the ICANN root servers have a history of changing
	address I would not expect any vendor to not provide a
	mechanism for changing them.  We build in the ICANN root
	servers in our products but we also provide mechanisms to
	change them.

% grep ROOT-SE CHANGES 
2328.   [maint]         Add AAAA addresses for A.ROOT-SERVERS.NET,
                        F.ROOT-SERVERS.NET, H.ROOT-SERVERS.NET,
                        J.ROOT-SERVERS.NET, K.ROOT-SERVERS.NET and
                        M.ROOT-SERVERS.NET.
2255.   [maint]         L.ROOT-SERVERS.NET is now 199.7.83.42.
1567.   [maint]         B.ROOT-SERVERS.NET is now 192.228.79.201.
1397.   [maint]         J.ROOT-SERVERS.NET is now 192.58.128.30.
% 
 
	The same thing will have to be provided for and DNSKEY's
	embedded in software as the expectation is that these will
	change relatively often, much more often than CA certs.

> alternative to iTunes, in practice they have no choice but to deal

	Governments are not private companies.  Governments often do
	things no sane company would do.

---

From: Stephen Kent <[email-masked]>
Date: Thu, 11 Jun 2009 20:35:20 -0400

Phil,

The examples you give about backed-in trust anchors are valid, but 
they point to decisions by vendors to simplify their designs at the 
cost of secruity and functionality. I've been told that it is very 
hard, if not impossible, to permanently remove some vendor-supplied 
TAs in a popular browser.  These are not fundamental results of 
architectural decisions of the sort the IETF makes, but vendor 
choices that lead to possible problems for user.

I think I understand the multi-party, RP-centric threshold approach 
to managing the DNSSEC root that you outlined. But, in a DNSSEC 
environment, IANA performs two roles:
	- it coordinates the info from the gTLDs and ccTLDs and constructs
	  the authoritative root zone file
	- it signs the records of that file

Any scheme that allows multiple entities to "confirm" the content of 
the root zone file also has to include a means for these entities to 
independently acquire and verify the master file data and to create a 
separate, distinct master file if they disagree.  This is a lot more 
complex that what you outlined in your message (from an from an 
administrative vs. crypto perspective). It also raises questions 
about how complex RP software has to be in dealing with multiple sets 
of quasi-authoritative root authorities.  All experience to date 
suggests that RPs fare poorly when trying to deal with much less 
complex trust anchor situations in other PKI environments today.

It is conceivable (under the new administration) that ICANN will stop 
being under the control of the U.S DoC, but it also is not clear that 
such a change would ameliorate the concerns of all governments with 
regard to this issue. I think the set of folks who feel a need to use 
other than the current, proposed model (IANA as the DNSSEC root) are 
a very small minority of the set of public Internet users and thus 
they should bear the burden of dealing with the resulting costs and 
complexity for managing alternative root schemes. I don't think that 
such costs and complexity should be borne by the vast majority of 
Internet users. Its also not clear how long one might spend debating 
the question of whether any single scheme would satisfy all of the 
players who are not comfortable with the current model.

Steve

---

From: David Conrad <[email-masked]>
Date: Thu, 11 Jun 2009 22:32:06 -0400

Hi,

On Jun 11, 2009, at 8:35 PM, Stephen Kent wrote:
> But, in a DNSSEC environment, IANA performs two roles:

Nope.  Just to clarify things:

IANA (well, ICANN as the IANA functions operator) receives and  
validates root zone changes.

VeriSign constructs and publishes the root zone to the root server  
operators.

In the context of DNSSEC, as documented at http://www.icann.org/en/announcements/announcement-2-03jun09-en.htm 
, VeriSign will have operational responsibility for the zone signing  
key and ICANN will manage the key signing process.

Regards,
-drc

---

From: Mark Andrews <[email-masked]>
Date: Fri, 12 Jun 2009 12:34:44 +1000

In message <[email-masked]>, Phill
ip Hallam-Baker writes:
> So we have totally abandoned the idea of doing DNSSEC in the end point clie=
> nt?

	No. Recursive nameserver need to validate the answers
	returned from the DNS for their own uses.  This doesn't
	preclude other applications also validating answers.  Having
	recursive nameserver validate answers is not the end point
	in DNSSEC deployment.  It's just a good first step which
	is good enough is some operational envionments.  There are
	however lots of operational envioronments where this would
	not be good enough and the validation really needs to be
	performed in the application.

	For your light switch example a validating recursive resolver
	is probably all you need.

	For laptops you most probably want to move the validation
	onto the laptop either in the application or by a running
	a validation recursive nameserver on the laptop which may
	or may not use the nameservers in the DHCP response as
	forwarders.  I do this today.

> Trust roots have to be valid for at least a decade to be acceptable to
> the application vendor community.

	That's a unproved assumption.
 
> And even though the current model of network administration is to
> constantly fiddle with everything, I think that is going to have to
> stop.

	Lots companies already use private roots.  Equipment
	manufactures are not going to build equipment that can't
	be used by those markets.

	Mark

---

From: Stephen Kent <[email-masked]>
Date: Fri, 12 Jun 2009 07:14:38 -0400

At 10:32 PM -0400 6/11/09, David Conrad wrote:
>VeriSign constructs and publishes the root zone to the root server operators.
>
>In the context of DNSSEC, as documented at 
>http://www.icann.org/en/announcements/announcement-2-03jun09-en.htm, 
>VeriSign will have operational responsibility for the zone signing 

David,

Thanks for the clarification.  I just wanted to emphasize the two 
distinct functions that IANA performs in the DNSSEC context, without 
getting into the ZSK/KSK details and the current proposed split of 
responsibility between IANA and VeriSign (which is outside the IETF 
DNSSEC architecture, right?).

Steve

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 12 Jun 2009 21:19:45 +0900

Phillip Hallam-Baker wrote:

>>? ? ? ?That's a unproved assumption.

> It is an observation backed by fifteen years of experience and direct
> conversations with the principals for cryptographic security at the
> major platform vendors.

PKI, including DNSSEC, is NOT secure cryptographically, but secure
socially or, in other word, weakly secure, subject to social and
other forms of attacks.

PKI, however, is not so insecure, in a sense that plain old DNS
(specified in 1987) is not so insecure and has been valid for
more than a decade to be acceptable to the application vendor
community.

That is the observed fact.

If the broken security model of bailiwick is thrown away,
plain old DNS is made secure enough.

Moreover, plain old DNS is a lot easier to manage than PKI.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 12 Jun 2009 22:16:29 +0900

Phillip Hallam-Baker wrote:

> These are assertions, not facts.

The fact is that since 1987, DNS has been mostly secure.

> that is what it is designed to do and that is how I define the
> term 'security'.

You did not simply say "security" but said "cryptographic security".

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 13 Jun 2009 08:54:27 +0900

Phillip Hallam-Baker wrote:

> Past history is no guarantee of future performance.

Is your argument applicable to the following statement you just made
yesterday?

: Trust roots have to be valid for at least a decade to be acceptable to
: the application vendor community.

> A pattern we see repeated over and over again is that a new control on
> some form of Internet crime leads to a dramatic short term reduction
> even though the control merely increases the cost of crime, not
> eliminates the capability. This is the displacement effect. The
> criminals attack weaker targets instead. Once the criminals have
> exhausted the supply of easy targets the original targets see a sudden
> increase in the crime rate, often orders of magnitude in a few days.

Note that, given dynamically generated zones, signature generation
mechanisms of DNSSEC is rather weaker targets.

							Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 13 Jun 2009 18:25:12 +0900

Phillip Hallam-Baker wrote:

> Past history is a very bad guarantee that problems will not arise in the future.

So, you mean your statement:

hardly guarantee anything.

> Be liberal in anticipating repeat of past problems,

Indeed.

Unnoticeable cache poisoning by glues is repeated even with
bailiwick and once again with DNSSEC.

> be conservative in
> your expectation that new problems will not arise.

The protection is to make protocols as simple as possible.

The following paper discusses about it to some extent.

http://ftp.csci.csusb.edu/ykarant/courses/f2007/csci530/papers/counterpane-ipsec.pdf

						Masataka Ohta

---

From: Florian Weimer <[email-masked]>
Date: Sat, 13 Jun 2009 16:49:09 +0200

* Joe Baptista:

> DNSCurve encrypts all DNS packets.

Ahem, this part of the protocol has not been specified so far.
Encryption is not mentioned on the dnscurve.org pages, only key
exchange, and even that is not fully disclosed.

---

From: Masataka Ohta <[email-masked]>
Date: Sun, 14 Jun 2009 09:25:56 +0900

Phillip Hallam-Baker wrote:

> It is very clear that at least part of this discussion is due to your
> unfamiliarity with English.

As you said

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

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

Thank you again for demonstrating a perfect manner for a
professional forum.

However, you should consider a possibility that your poetry
skill in English, if any, can not, in this professional forum
not on poetry but on engineering, make up for your lack of
expertise in protocol design.

> Most of us know that the typical business cycle lasts 7-10 years.
> However the geniuses behind 'Long Term Capital Management' only
> reviewed six years of the business cycle ending entirely. When one of
> the principals behind LTM is interviewed on TVfor his opinions on the
> bailout he is invariably tagged as 'Nobel Laureate', and never 'The
> fool who caused the last major fiscal crisis'.

Though you obviously don't know much about LTCM, it is merely that
business model of LTCM has been broken from the beginning, just as
authority model of DNSSEC has been broken from the beginning.

Initial success of LTCM is due to not technical but poetry skill
of people involved, because economy is not very technical.

As for DNSSEC in highly technical world, after years of unsuccessful
experimental deployment, most of the problems of authority model,
all of which was pointed out by me from the beginning, was fixed.

The only remaining problem of DNSSEC is that it is not very secure.

It is not cryptographically but weakly secure, which is the security
of plain old DNS.

> I have fifteen years experience in this business area.

I thought you shun businesses.

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

						Masataka Ohta

---

From: Florian Weimer <[email-masked]>
Date: Sun, 14 Jun 2009 10:44:02 +0200

> router? How about a light switch?

Nowadays, there are software update protocols for broadband routers,
too.

> the most widely embedded.

No, Verisign's pricing is based on branding.  "Verisign" is just the
most valuable brand, so certificates associated with it cost the most.
Verisign also issues certificates under a root called "Equifax", which
are far cheaper but functionally equivalent.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 11 Jun 2009 21:38:14 -0400

So we have totally abandoned the idea of doing DNSSEC in the end point client?

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 11 Jun 2009 21:57:14 -0400

I agree the resources are non-trivial

But it creates a put-up or shut-up point for the non-US objectors to
the sole US controlled root. What it does not do is to address the
state dept concerns that the root is a liability. And the cost of
setting up an apex authority are much less than the cost of fracturing
the root.

Given the complete lack of interest that the DNSSEC community has had
in consultation with deployment stakeholders, the quorate approach
might well be important as a way to co-opt the existing Domain
Validated SSL cert providers to seed a DNSSEC deployment in a DLV
structure.

One of the administrative parts of the puzzle that nobody seems to
have thought out is why the registrars are going to play ball. Or for
that matter what the charge for a DNSSEC zone entry is going to be.

On Thu, Jun 11, 2009 at 8:35 PM, Stephen Kent<[email-masked]> wrote:
> Phil,
> The examples you give about backed-in trust anchors are valid, but they
> point to decisions by vendors to simplify their designs at the cost of
> secruity and functionality. I've been told that it is very hard, if not
> impossible, to permanently remove some vendor-supplied TAs in a popular
> browser.  These are not fundamental results of architectural decisions of
> the sort the IETF makes, but vendor choices that lead to possible problems
> for user.
> I think I understand the multi-party, RP-centric threshold approach to
> managing the DNSSEC root that you outlined. But, in a DNSSEC environment,
> IANA performs two roles:
> Any scheme that allows multiple entities to "confirm" the content of the
> root zone file also has to include a means for these entities to
> separate, distinct master file if they disagree.  This is a lot more complex
> that what you outlined in your message (from an from an administrative vs.
> crypto perspective). It also raises questions about how complex RP software
> has to be in dealing with multiple sets of quasi-authoritative root
> authorities.  All experience to date suggests that RPs fare poorly when
> trying to deal with much less complex trust anchor situations in other PKI
> environments today.
> It is conceivable (under the new administration) that ICANN will stop being
> under the control of the U.S DoC, but it also is not clear that such a
> change would ameliorate the concerns of all governments with regard to this
> issue. I think the set of folks who feel a need to use other than the
> current, proposed model (IANA as the DNSSEC root) are a very small minority
> of the set of public Internet users and thus they should bear the burden of
> dealing with the resulting costs and complexity for managing alternative
> root schemes. I don't think that such costs and complexity should be borne
> by the vast majority of Internet users. Its also not clear how long one
> might spend debating the question of whether any single scheme would satisfy
> all of the players who are not comfortable with the current model.
>
> Steve

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 12 Jun 2009 07:52:11 -0400

Moreover, I note that far from soliciting opinion from these groups,
the DNSEXT working group has done everything it can to drive such folk
away.

Every single time a real world deployment constraint has been raised,
the response of the group has been fingers in ears 'LA-LA-LA NOT
LISTENING'. It took two years of argument before the zone walking
issue was accepted as a legal requirement, it took five to get support
for opt-in.

At each stage in the proceedings, the length of time that the process
has taken is used to avoid considering real world deployment
constraints.

You think that you are finished. All you have done so far is to build
PEM. PEM got to the exact stage that DNSSEC has got to thus far in a
quarter the time. They had a complete set of RFCs specified that
described a scheme that nobody could deploy. Their excuse was that
nobody understood the deployment constraints.

>        be used by those markets.

Manufacturers are quite capable of producing only checklist compliance
for features that have no customer demand.

I talked to analysts from Gartner, Burton and others at RSA this year,
none considered DNSSEC to be a major security issue. They write the
RFPs that drive feature support.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 12 Jun 2009 08:58:20 -0400

PKI is demonstrated to be effective in the reduction and management of
risk, that is what it is designed to do and that is how I define the
term 'security'.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 12 Jun 2009 19:37:18 -0400

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 12 Jun 2009 20:21:49 -0400

Past history is a good indicator of problems that may arise.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 12 Jun 2009 20:26:59 -0400

Or alternatively,

Be liberal in anticipating repeat of past problems, be conservative in
your expectation that new problems will not arise.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 13 Jun 2009 14:51:25 -0400

Looking at past failures is a very good way to predict the possibility
of similar failures in the future. History is a very good guide to
setting a lower bound on risk.

History is a very poor guide to setting a lower bound on risk, not
least because people have a habit of only looking at the past events
that give them good news.

I have fifteen years experience in this business area. I am the only
participant in this debate so far who can claim any direct knowledge
of the business of embedding roots. It is on that basis and on the
basis of direct conversations with my peers in the industry that I
believe that the current DNSSEC specs do not meet the needs of
deployment.

Given that DNSSEC has not achieved deployment in fifteen years and
given that the only deployment momentum that can be seen at the moment
is in the form of 'top-down' edicts from ICANN, Vint Cerf and co, I
think that the onus of proof falls on those who assure us that DNSSEC
does in fact meet deployment requirements.