Subject: Re: IAB statement on the RPKI.

From: "Mr. James W. Laferriere" <[email-masked]>
Date: Fri, 12 Feb 2010 12:44:10 -0900 (AKST)

Hello All,

On Fri, 12 Feb 2010, IAB Chair wrote:
> IAB statement on the RPKI.
>
> = RPKI as a prerequisite for improving the security of the global
>   routing system.
>
> To date, the Internet has operated without a secure means to certify
> the allocation of Internet number resources, particularly Autonomous
> System (AS) numbers and IP addresses. The pending exhaustion of the
> IPv4 address space, coupled with a pressing need to improve the
> security of the global Internet routing system, has given impetus to
> the development of a resource certification infrastructure for the
> Internet. A consistent shared view around the world of which number
> resources are allocated to whom is essential for the reliable
> operation of the Internet as it continues to grow. The IETF Secure
> Inter-domain Routing (SIDR) Working Group (WG) has been working with
> the various stakeholders to specify a Resource Public Key
> Infrastructure (RPKI) system that can be used to certify these
> resource allocations in order to substantially improve the security
> of the routing system.
>
> The IAB considers a properly designed and deployed RPKI to be an
> absolute prerequisite to having a secure global routing system,
> which is in turn a prerequisite to having a reliable worldwide
> Internet. In its absence, there is no formally verifiable
> authoritative source to determine the allocation for any
> Internet number resource.  Consequently, before originating,
> propagating, or accepting an IP address prefix, each routing domain
> must individually assess the consistency of that prefix with
> whatever information can be obtained about actual allocations. This
> loose "routing by rumor" approach provides considerable flexibility
> to each routing domain, but the negative consequences are severe.
> The global routing system is vulnerable to large-scale disruptions
> through both misconfiguration and malice. These vulnerabilities can
> be substantially reduced through the use of an RPKI. Through proper
> design and wide-scale deployment, an RPKI enables network operators
> to generate their routing policies from securely verifiable
> allocation data, providing much higher confidence in the
> authenticity of routing information.
>
> = Technical considerations with respect to the design of the PKI
>
> For any PKI, a certification hierarchy must exist that allows
> parties to ascertain the validity of a given certificate. The SIDR
> architecture uses a certification hierarchy, and relying parties
> must explicitly place trust in the top-level of the hierarchy,
> commonly called a trust anchor. The SIDR architecture and protocols
> have been designed to support a single trust anchor as well as
> multiple trust anchors. The IAB however, is in strong agreement with
> the Number Resource Organization (NRO) (made up of the five
> Regional Internet Registries (RIRs)) regarding the number of trust
> anchors as well as what and whom they represent:
>
> 1. the RPKI should have a single authoritative trust anchor
>
> 2. this trust anchor should be aligned with the registry of the root
>    of the allocation hierarchy
>
> The reasoning is of a technological nature and is as follows. A
> single root for the certification hierarchy significantly reduces
> the risk of two or more parties accidentally (or maliciously)
> issuing conflicting certifications for the same address block,
> because a single authoritative entity at the top-level of the
> allocation hierarchy is authoritative for both (a) the allocation of
> the address block and (b) the cryptographic certification of the
> fact that it did indeed allocate that address block.
>
> Thus, the IAB strongly recommends a single root aligned with the
> root of the address allocation hierarchy (now part of the IANA
> function). Doing so will minimize unnecessary complexity in the
> system, in particular virtually eliminating the possibility of
> resource conflicts in the system, reducing substantially the
> likelihood of errors as the allocation and certificate generation
> can be done together by the same operator.
>

 	I for one do not see the need for a 'Single' point of failure nor a 
placement of another financial gaining point for some large 
company/government or what have you .

 	There are protocols which can be used and some are in discussion which 
would be far better than this particular methodology .

 	The only way this could be even fathomable would be for a World wide 
orginasation to be formed that manages & monitors this AND we all know where 
that will head the minute it gets started .

> = Implementation considerations
>
> The notion of having a certification hierarchy with multiple equally
> trusted roots may be appealing from a social and political perspective
> because of 'fairness' and 'equality' arguments. But that notion
> allows different organizations to make inconsistent and conflicting
> assertions about to whom a particular address block has been
> allocated. In the case of conflicting assertions, the conflict would
> need to be solved by each relying party, requiring each relying party
> to have their own security policy and the associated increased
> complexity. Such an approach does not provide any guarantee that the
> outcome would lead to a globally coherent view of which resources
> have been allocated to whom.
>
> It should be noted that mistakes in and attacks on the allocation
> process are possible, and that sensible caution and fallback plans
> still remain necessary. Therefore, architecturally, the set of trust
> anchors employed by a relying party application remains strictly a
> local matter. In practice relying parties will likely employ local
> policy files (e.g., for local address spaces such as RFC 1918 spaces
> used internally) and trust anchors that reflect local security
> decisions. Therefore the existence of a single root for the
> certification hierarchy does not give that root unilateral control
> over the Internet. Individual network operators choose to trust the
> information given by that root, based on operational experience that
> the information given by that root is trustworthy.  If they find
> it to be untrustworthy, they are free to ignore it and instead
> enforce policy based on what they believe to be more appropriate
> data. The fact that the relying parties choose to trust the root
> only so long as it proves itself to be trustworthy gives the
> organization operating the root a strong incentive to ensure that
> the information they give is accurate and correct, thereby making it
> rare for network operators to have any reason to distrust it.
>
> Mechanisms to support local decisions about trust anchors, while
> still maintaining compatibility with RFC 3779 certificate
> processing, are currently being considered by the SIDR working
> group. This statement is not to be interpreted as in conflict with
> these goals; rather, it is concerned solely with the structure of
> the RPKI certification hierarchy, as represented in the public
> repository system and aligned with the Internet number resource
> allocation hierarchy.
>
> = Concluding remarks
>
> The IAB commends the RIRs for their investment and leadership
> in developing an RPKI system that can be used for digital
> certification of Internet number resources, as well as enabling a
> foundation upon which a secure Internet routing system can be
> developed.

 	May I ask where this statements intent(s) were discussed in an open 
manner on the ietf list ?  I'd very greatly like to review those discussions in 
their entirety .

 		Tia ,  JimL

>
>
> IAB, Jan 27, 2010
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce
>

-- 
+------------------------------------------------------------------+
| James   W.   Laferriere | System    Techniques | Give me VMS     |
| Network&System Engineer | 3237     Holden Road |  Give me Linux  |
| [email-masked] | Fairbanks, AK. 99709 |   only  on  AXP |
+------------------------------------------------------------------+

---

From: SM <[email-masked]>
Date: Sun, 14 Feb 2010 01:54:26 -0800

Hello,
>= RPKI as a prerequisite for improving the security of the global

It would be preposterous of me to disagree with the opinion of the 
learned members of the IAB.

>  have been allocated to whom.

The most important factor in choosing a security mechanism is the 
threat model.  That is, who may be expected to attack what resource, 
using what sorts of mechanisms? (RFC 3631).

What follows is a work of fiction.

     The taller man shut the folder and smiled.  "This is a wonderful
   statement.  Just Perfect."

     "Thank you," said the white-haired man seated across from him.
   "The author is a very good  writer."  He shifted slowly, uncrossing
   his legs.  He leaned forward, causing the leather seat to groan.
   "Along with this afternoon's briefing, this is really going to
   accelerate matters.  You know that, don't you?"

     "Of course," the taller man said.  He put his coffee mug on a small
   table, rose, and walked to the fireplace.  He picked up a poker.
   "Does that scare you?"

    "A little," the white-haired man admitted.

     "Why?" the taller man asked as he threw the folder into the flames".
   It caught fire quickly.  "Our tracks are covered."

     "It is not us I'm worried about.  There will be a price," the
   white-haired man said sadly.

     "We've discussed this before," the taller man said. "The policy
   people will love it."

This is an edited version of the text from Divide and conquer written 
by Jeff Rovin, Tom Clancy and Steve R. Pieczenik.  The quoted text 
should not be considered as an IETF Contribution as the author of 
this message does not control the rights to the material.

Regards,
-sm

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 15 Feb 2010 09:50:59 +0900

SM wrote:

> The most important factor in choosing a security mechanism is the threat 
> model.

Right.

> That is, who may be expected to attack what resource, using what 
> sorts of mechanisms? (RFC 3631).

Perhaps, a threat will be by an ISP trying to advertise someone
else's address range as its own.

However, protections against the threat does not prevent the
ISP advertise the range as someone elses'.

That is, the ISP can attach its own AS number to a legitimate AS
path for the range. Then, the ISP can capture packets destined
to addresses within the range, against which, there is no
protection.

						Masataka Ohta

---

From: SM <[email-masked]>
Date: Mon, 15 Feb 2010 16:01:45 -0800

>else's address range as its own.

Quoting Sandra Murphy [1]:

  "Political and business fears don't have to be rooted in technical
   truth, unfortunately."

At 19:48 14-02-10, Phillip Hallam-Baker wrote:
>I don't think that any member of the IAB would claim that their
>expertise in the PKI field precluded debate.

Your message did not make it to the IETF mailing list.

I am not privy to all the details to argue against an IAB 
statement.  This should not be read as a licence to kill. :-)

>This is not a technical issue, it is a political issue. IANA and ICANN
>have a really, really bad record when it comes to setting up root
>authorities. Any plan that requires their involvement is going to take
>considerably more time and effort than one where their involvement is
>optional.

Any long-term consequence will be of a political nature.  It goes 
beyond the IANA function and ICANN.  The conventional world is used 
to having some form of authority for regulation.  The "routing by 
rumor" approach does not fit that view.  Some considerations may seem 
far-fetched.  I'll leave it as such.

>There are five RIRs, this number is not going to increase in the short
>term. Participation of the RIRs is critical for an authoritative
>system. Participation of ICANN is not.

It's up to the interested parties to work out the details.

>The risk of including ICANN is that misguided or not, there are lots
>of people who have concerns as to the power that the US exercises over
>the Internet through their defacto control of ICANN. One common
>concern is that the US could use such control to ensure that US ISPs
>were favored in the distribution of the remaining IPv4 blocks.

I don't think that the distribution of the remaining IPv4 blocks is 
that much of an issue.

I would not draw parallels between DNS and IDR as the dynamics are 
different.  I don't assume that the goal is always about wrecking 
havoc.  These are classic threats that RPKI can address.

Regards,
-sm

1. http://www.ietf.org/mail-archive/web/sidr/current/msg01099.html

---

From: David Conrad <[email-masked]>
Date: Mon, 15 Feb 2010 16:19:49 -0800

>> IANA and ICANN have a really, really bad record when it comes to setting up root authorities.

Oh? Examples please.

Regards,
-drc

---

From: David Conrad <[email-masked]>
Date: Mon, 15 Feb 2010 16:45:19 -0800

On Feb 15, 2010, at 4:40 PM, Phillip Hallam-Baker wrote:
> PEM (Five years and counting before the project faded away without a
> definitive declaration of failure)
> DNSEC (Ten years and counting)

So, you're blaming IANA and/or ICANN for the failure to deploy both PEM and DNSSEC.

Seriously?

Regards,
-drc

---

From: David Conrad <[email-masked]>
Date: Mon, 15 Feb 2010 18:11:31 -0800

On Feb 15, 2010, at 5:21 PM, Phillip Hallam-Baker wrote:
> It is now generally accepted that PEM was undeployable because the
> single root model is not workable.

And this is the fault of IANA and/or ICANN how?

> ICANN was well aware that the lack of opt-out would prevent deployment
> of DNSSEC in .com as early as 2000.  

Even if "ICANN" was aware (doubtful), do you really think the DNSEXT working group would value ICANN's position more than, say, VeriSign's?

> They had a responsibility to tell
> the IETF that this was a non-negotiable requirement and that failure
> to meet it would mean that ICANN would be unable to deploy DNSSEC.

Do you honestly believe ICANN can dictate to the IETF community (or anybody else with the exception of contracted parties) how to do much of anything?  You have a very odd view of how ICANN works.  

> Ten years later the only part of ICANN that seems to interest them is
> the idea that they will have sole control of the root zone

You are aware, of course, that ICANN isn't even the party that is going to be signing the root zone, right? And how the root KSK is being managed?

Sounds to me like you just want to bash ICANN. This gets boring after a while.

Regards,
-drc

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 16 Feb 2010 14:05:44 +0900

Phillip Hallam-Baker wrote:

> There are two separate functions in the routing layer. There are
> security issues in both cases.

"interdomain routing security", for which SIDR WG was scoped,
is the second one, though its charter is totally confused.

> The second problem is a much harder one to address using PKI. It is
> quite possible that PKI is not the right tool at all.

PKI is not, which means it is confirmed again that IETF, including
IAB, is brain dead.

It's not an issue specific to IANA or ICANN and IPv6 is a better
evidence than PEM or DNSSEC.

						Masataka Ohta

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 16 Feb 2010 07:46:04 +0100

> And this is the fault of IANA and/or ICANN how?

Philip, yes, because people did not think strongly enough on how to create the one single root. Because a single root among other things created a problem for the various business models out there.

For domain names and IP addresses, we already have a root, so that problem does not exist. And that is exactly what IAB states.

   Patrik

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 14 Feb 2010 22:48:49 -0500

On Sun, Feb 14, 2010 at 4:54 AM, SM <[email-masked]> wrote:
> It would be preposterous of me to disagree with the opinion of the learned
> members of the IAB.

The substantive statements being issued in the PKI are going to
consist of a RIR issuing an assertion of the form 'The holder of the
key X has the authority to assign AS numbers to the IP address space Y
through Z'.

The people who hold these views are not stupid, they just hold a
completely different world view. A world view that is not going to be
overturned by rational arguments based on the world view largely
shared by the IAB. And some of those people hold positions of
authority that can pretty much ensure that any ICANN sponsored root
never happens.

In the diplomatic world, you do not accept a position based on 'trust
me'. The original DNS emerged by accident because nobody was looking.
X.500 died because everyone was watching and there was a sufficiently
large number of parties who prefered no system to an unacceptable
system.

As most people here are aware, the Internet has become a forum for
proxy-warfare and symbolic warfare. There will be considerable
opposition even with the changes I propose: certain parties do not
want this system to be secure.

A better alternative to a single root structure would be for each RIR
to cross certify with the other RIRs. This eliminates the objection to
'US dominance', eliminates ICANN as a roadblock and provides for
redundancy.

The security difference between the two scheme is that a single root
system headed by ICANN could in theory prevent 'defection' by a RIR.
In practice this would require a lot more technical mechanism. ICANN
would have to certify each mega-block allocation.

I don't think it is very likely that end entities are going to be
checking the block allocations on every transaction absent an
expectation that the RIRs might defect. But the possibility that they
might will mean that the RIRs will lose authority should they
co-operate with such a scheme.

In conclusion, I strongly recommend that we do not repeat the
disastrous political mistakes of DNSSEC that have blocked deployment
for over a decade and will still continue long after the DNSSEC root
is deployed.

Deployment of infrastructure on this scale requires that we make a
commitment to deployment a higher priority than the realization of a
specific technical architecture.

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

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 14 Feb 2010 23:02:02 -0500

The first function is to map IP address ranges to AS numbers. This is
a global mapping, if an IP address range maps to an AS number in
France the same mapping will be good in Brazil.

The second function is to establish rooting maps for AS numbers,
effectively setting up mappings of the AS numbers to Internet endpoint
networks. This mapping is not global. The best route to London is
going to be very different in France and Brazil.

The upshot is that the first problem maps very cleanly to standard PKI
approaches. You can use X.509 certs with extensions, you could use
SAML assertions, the statements are global and work very well.

The second problem is a much harder one to address using PKI. It is
quite possible that PKI is not the right tool at all. The problem is
that if A, B and C are exchanging routing information and Mallet
introduces a bogus route to A, the message A then sends to B
advertising a better route will genuinely have come from A.

There are certainly ways round this problem, if indeed it really is a
persistent problem. There are non cryptographic controls already in
place to verify route quality. It may be that these are sufficient. It
may be that we can employ an accountability based approach to pinpoint
the introduction of bogus routes.

On Sun, Feb 14, 2010 at 7:50 PM, Masataka Ohta
<[email-masked]> wrote:
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 15 Feb 2010 19:40:29 -0500

They have yet to succeed in setting up a single PKI.

Signing the root of the DNSSEC scheme will not change anything, I
asked for details of the proposed registrar key authentication process
three months ago and I am still waiting. I doubt that they exist.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 15 Feb 2010 19:54:05 -0500

PKI is all politics. A PKI is a political infrastructure.

Saying that politics and business rules are out of scope when you
propose a PKI design is basically saying that you aren't going to look
at any of the issues that are relevant to the design.

Sandra Murphy is right when she says that political and business fears
don't have to be rooted in 'technical truth' (whatever that is). They
do not have to be grounded in any form of reality. They can be
completely and utterly unreasonable. And they can be held by people
who have the ability to totally block any chance of deployment.

'Trust me' is not a convincing argument in this context.

Unless you hadn't noticed, cyber-conflict is now real. Back during the
last US Presidential election I was advised that both campaigns had
been penetrated in attacks originating from a Chinese government
agency. The examples that are making the press are only some of the
attacks taking place. Attacks originating in the US do not get as much
attention.

In this environment it seems rather naive to believe that these
parties can be persuaded to acquiesce to the deployment of a PKI that
requires their participation.

Not changing the political or business relationships of the parties
has to be a criteria in the design of any global information
infrastructure if deployment is going to have a chance of success.

On Mon, Feb 15, 2010 at 7:01 PM, SM <[email-masked]> wrote:
> I am not privy to all the details to argue against an IAB statement.  This
> should not be read as a licence to kill. :-)
>
> Any long-term consequence will be of a political nature.  It goes beyond the
> IANA function and ICANN.  The conventional world is used to having some form
> of authority for regulation.  The "routing by rumor" approach does not fit
> that view.  Some considerations may seem far-fetched.  I'll leave it as
> such.
>
> I don't think that the distribution of the remaining IPv4 blocks is that
> much of an issue.
>
> different.  I don't assume that the goal is always about wrecking havoc.
>  These are classic threats that RPKI can address.
>
> Regards,
> -sm
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 15 Feb 2010 20:21:17 -0500

It is now generally accepted that PEM was undeployable because the
single root model is not workable. Nobody was going to trust IANA as
the ultimate root of trust, nor were they going to trust RSA.

ICANN has accepted responsibility for the DNS infrastructure.
Unfortunately they don't seem to understand what that means for their
interactions with the IETF. At the very least, ICANN needs to be
issuing operational requirements documents that itemize the protocol
support that is required for deployment.

ICANN was well aware that the lack of opt-out would prevent deployment
of DNSSEC in .com as early as 2000. They had a responsibility to tell
the IETF that this was a non-negotiable requirement and that failure
to meet it would mean that ICANN would be unable to deploy DNSSEC.
Instead they insisted that no deviation from the IETF standard was
permissible.

Ten years later the only part of ICANN that seems to interest them is
the idea that they will have sole control of the root zone. The fact
that others are going to filibuster DNSSEC rather than to allow it to
deploy as at present does not seem to have occurred to them. It is
quite possible that what is driving the GOST issue is that the GRU
really has a thing about vanity crypto. But I think it much more
likely that they are going to use it as part of a series of
regulations that effectively require Russian ISPs chain their DNSSEC
off the GRU approved root.

Otherwise the Russian concerns make absolutely no sense. They
certainly understand PKI well enough that control of the root key is a
much bigger deal than the remote possibility that the NSA has tricked
up the made in the US crypto with some backdoor that only the NS has
noticed in the past three decades.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 16 Feb 2010 08:08:20 -0500

No, you think that you have a unitary root.

Actually you have separation of powers. ICANN is not currently in sole
control. There is a marked difference between the ICANN view of its
authority and the RIRs and national TLDs

Removing the ambiguity means a very large change in the ability of
ICANN to enforce its authority. Now it could be that this will be
acceptable to the French, Egyptian, Brazilian ministries etc. But not
objecting to a change in the Internet governance that results in a
major loss of sovereignty would be rather out of character.

---

From: Martin Rex <[email-masked]>
Date: Tue, 16 Feb 2010 19:02:22 +0100 (MET)

> support that is required for deployment.

The real problem is that a lot of people attribute too much
trust of all the wrong kind into a security architecture,
creating a huge pile of flawed assumptions -- that is neither
appealing nor robust, so there is little surpise when it fails
in the marketplace.

DNSsec should _NOT_ do anything besides confirming the assignment/lease
of DNS zones to lessees.  Any kind of trust decision by applications
based on DNS delegation of zones is completely inappropriate.

The signature on a DNS zone is the result of a contract between
the organization that adminstrates a zone to lessees/subscribers for
delegated subdomains, nothing else.  It is a simple technical fact
that the DNS zones are technically organized in a hierarchical fashion
and that administrators of a zone can delegate adminstration of
subdomains to others.  DNSsec will hopefully make the insertion of fake
data into DNS zones more difficult, but it will not make Cybersquatting
or disputes about domain ownership/assignment go away.  DNSsec is
technically still DNS, after all.

Which DNS domains actually belong to specific state, corporate or
private entites is an entirely seperate question, and no application
should ever confuse the authority to delegate DNS domains with authority
to "certify" legal entities (governmental,corporate or private).

If the .com registry leases&delegates the domain "ietf.com" to somebody,
that does not imply that this somebody therefore represents the Internet
Engineering Task Force (IETF). and any kind of assumption within
applications to that effect are fatally flawed.

All of the existing security protocols are using a different trust model
already (like TLS), and I do _not_ think that existing trust models
(independent of how broken the TLS trust model with >100 preconfigured
and completely interchangable trusted roots is) should be piggy-backed
onto, or keyed from DNSsec, ever.

-Martin

---

From: Dmitry Burkov <[email-masked]>
Date: Tue, 16 Feb 2010 21:37:58 +0300

> off the GRU approved root.

I think that it is not a constructive way to discuss this issue  
following some conspiracy theories.
I want to refer you to origin of  this discussion on ietf lists
http://dnssec-deployment.org/pipermail/dnssec-deployment/2009-April/thread.html#2932

and want to remind what was initial reason for us to follow this way and 
to propose GOST as one of standard algorithms for DNSSEC.

As you know we have some national regulation in crypto.
To implement DNSSEC we should
or to use GOST (at this moment) and to comply regulations
or to ignore DNSSEC (no comments)
or try to change national laws (also no comments).
If someone can give us an advice - what to do else - you are welcome.

After series of dicussions and consultations with many participants of 
this list we agreed with recommendations and began this process to move 
forward GOST as one of mandatory standards.

Otherwise - we can't achieve
"the goal is:

(1)  for their zones, e.g. .ru, .su, and any new ones they get, to be 
signed with GOST,

(2) for everyone to be able to validate their signatures, and

(3) for them to be able to validate everyone else's signatures.

For (2), they need to promulgate their algorithms into the standard 
crypto libraries and have an algorithm identifier assigned through IANA. 
  I believe both of these are in progress.

For (3), they simply need to use the standard algorithms in their own 
resolvers, and I believe they will be able to do this comfortably. 
  We're talking about checking, not signing, signatures, not encrypting."

Just a quote from this list.

Dima

---

From: Martin Rex <[email-masked]>
Date: Tue, 16 Feb 2010 20:17:06 +0100 (MET)

> to propose GOST as one of standard algorithms for DNSSEC.

With respect to supporting regionally favoured crypto-algorithm,
the solution should be different.  DNSsec should allow for the
presence of more than one signature (differing in algorithm),
so that Zones can carry both, a mandatory to implement signature
(algorithm) and interoperable world-wide, and one that might
be prefered in particular regions (or legislations) and can
be evaluated in those areas by those who care (or which are
obliged to care).

The obvious benefit is that only those living in regions or
legislations with an extreme bias towards certain crypto algorithms
have to bear the burden of creating and verifying the optional
signatures with that algorithm, while the others can continue
to use the single common and mandatory algorithm.

I don't have a problem if DNS-Zones like ".ru", ".su" include
GOST-based signatures in their Zones.   But to me it looks like
a serious problem if they do _NOT_ include signatures of a
common worldwide algorithm (which can be used by all others
that verify zones from .ru and .su).

(are signatures and DNS KEYs in DNSsec really designed to be
 "highlanders", i.e. there can only be one?)

-Martin

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 17 Feb 2010 07:55:18 +0900

> If someone can give us an advice - what to do else - you are welcome.

Ignore DNSSEC.

Technically, it is poorly designed unnecessarily causing a lot of
technical problems such as large message sizes.

But, the most serious defect of DNSSEC, or PKI in general, is that,
despite a lot of hypes, it is not cryptographically secure.
Social attacks on trusted third parties makes the parties
untrustworthy, which means PKI is merely socially or weakly
secure.

For security of interdomain routing, social security of trust
relationship between ISPs is just enough to which additional
social security by PKI is not helpful.

For security of DNS, social security of trust relationship between
ISPs and between zones are just enough to which additional social
security by PKI is not helpful.

						Masataka Ohta

---

From: Basil Dolmatov <[email-masked]>
Date: Wed, 17 Feb 2010 18:01:16 +0300

> untrustworthy, which means PKI is merely socially or weakly
There are a lot of deficiencies in PKI, but at present time I can see no 
alternative for establishing trust in loosely connected and large 
systems. If there is one, please advise.
> social security by PKI is not helpful.
There are no trust relationships between my ISP and your ISP.
How my ISP can trust routing announce, which I have got over the network 
and which has your ISP mentioned as the origin?

> security by PKI is not helpful.
Same question applies to DNS. My resolver have no trust relationships 
with your server.
How I can trust DNS-answer which I have got over the network?

Unfortunately, Internet 20 years ago and Internet today are two 
significantly different networks.

20 years ago I trusted to nearly all network participants and 
undoubtedly trusted to all network administrators.

Now, the necessity to build the chains of trust is obvious, otherwise 
you will lose a lot. The methods, which are being implemented are 
definitely not ideal (I knew a lot of flaws and weaknesses in systems, 
which are using PKI), but at the same time I do not know anything better.

dol@

---

From: Martin Rex <[email-masked]>
Date: Wed, 17 Feb 2010 19:16:39 +0100 (MET)

> systems. If there is one, please advise.

DNSsec, as far as I can see, does not use a PKI in the traditional
sense.  There are _NO_ persons involved in the process, it is
a pure authorization hierarchy of signing keys, and the distribution of
that keys could be coupled to the lease of DNS domains from registries
but is technically independent.

> and which has your ISP mentioned as the origin?

Current DNS comes without any kind of protection and without
any kind of trust.  Get rid of your trust idea and adopt DNSsec
only for the possibility to add some level of integrity protection
and data origin authentication into the system.

There are going to be so many keys and so many entities, so many
key renewals and so many fully automatic signature operations in
place that it will be impossible to come up with a universal 
set and number of "trusted authorties" that will make the
entire DNS trusted and secure for everyone.

The best you can come up with is to individually manage risks for
specific zones to match individual threat scenarios, and you can do
that completely indepent of how many "roots" there are.

Going for one single root is an arbitrary choice, but it happens
the one that is the easiest to deploy and the one with the
lowest risk of operational problems (interferences among roots
is a problem that can not exist then).

Sensible DNSsec risk management can only work at the level of individual
zones.  It is not going to work with a single or a set of roots alone.
Therefore discussing how many roots there should be and who
should run them is a complete waste of time.

The initial adoption rate of PGP and SSH was never crippled by
discussions of which roots you want to trust.  Otherwise they
would have failed just as badly as S/MIME.

TLS only became popular because the vendors decided to
completely ignore risk management and selection and management
of trusted roots.  The choices are completely arbitrary and
hardly anyone cares about the complete lack of risk management.

When I use my Web-Browser to connect to some bank or online-shop
under protection of SSL/TLS, then I don't have any trust to
that bank or shop, not to their ISP and not to the CA that
issued the cert for the server.

Although the entire architecture is pretty insecure because of
a complete lack of trust in many involved parties, it is far
from being useless.  Would the change from traditional DNS to
DNSsec have a security impact on that scenario?  No, NONE at all.
But it could make the communication infrastructure more robust
against infrastructure attacks.

Managing risks would mean to manually check the server certificate
and compare it to some out-of-band verification information.
Browsers are quite hostile to risk management, because they
don't naturally support concious trust decisions in the
traditional SSH-style, which makes individual risk management
extra painful.

-Martin

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 18 Feb 2010 07:14:02 +0900

> systems. If there is one, please advise.

The problem of PKI is that its security socially depends on a loose
connection of a chain of adjacent CAs.

In other word, PKI, including DNSSEC, is not secure end to end.

As the chain is breakable at component CAs (trusted third parties are
not very trustable), there is no point to work unreasonably hard to
cryptographically strengthen links between adjacent CAs.

So, PKI is useless when there already are loose but reasonable
social security.

> There are no trust relationships between my ISP and your ISP.

Your and my ISPs are loosely connected by a chain of social trust
relationships between adjacent ISPs, which is why we can exchange
packets over the Internet with reasonable security.

> Additional loose connection by a PKI chain does not help.

> and which has your ISP mentioned as the origin?

That should be an argument against PKIs.

How can you trust my CA, which you have got over a network of CAs?

Socially compromising a CA in the network is as easy as socially
compromising an ISP.

> Same question applies to DNS. My resolver have no trust relationships 

Adjacent zones have reasonable social trust relationships between
them, through which network, your resolver and my server are
loosely connected with reasonable security.

If you argue zones are not managed very securely, it means CAs of
PKI, a.k.a. zones of DNSSEC, are not managed very securely.

> How I can trust DNS-answer which I have got over the network?

How can you trust DNSSEC-answer which you have got over a network
of poorly managed CAs (zones)?

> Now, the necessity to build the chains of trust is obvious,

Unless the chains are not already there.

							Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 18 Feb 2010 07:24:15 +0900

Martin Rex wrote:

> sense.  There are _NO_ persons involved in the process,

FYI, zones are operated by people.

I can forge a key of your zone. I can, then, ask a person operating a
parent zone of yours to issue a valid signature over the forged key.

						Masataka Ohta

---

From: Sabahattin Gucukoglu <[email-masked]>
Date: Wed, 17 Feb 2010 23:11:57 +0000

> parent zone of yours to issue a valid signature over the forged key.

Yeah, but at least now we know the difference between the subversion of the "Chain of trust" and some bloke with a packet sniffer.  As soon as the "Integrity" of the "Chain of trust" becomes obviously broken, for whatever reason, it's totally within our power to do what we do now, and ignore it.

The point here is, we now have a way to verify the technical functions we depend on today are working properly.  It isn't about reputation or the trust of any given person or entity, any more than it is now. I can *still* find ingenious ways to bribe or subvert or otherwise make your registrar publish records of my control and design that pertain to your domains, with or without that verification function.  Well, I could if I were sitting at the top with lots of money and nothing else to do.  But when the data we receive is authentic from the intended, authenticated source, we have a chance to assign our own trust policies as we see fit (and it may be, though I doubt it, that I find the bloke with a packet sniffer a more reliable source than ICANN).  The utility of online banking and shopping, as certified by some sort of certification authority about whom we know next to nothing, suggests that we prefer some - any - degree of accountability, and the result of some CA being sloppy has always (and will continue to be) grounds for distrust.  And the same has applied as well to webs of trust, like those of PGP, where some degree of fuzzy logic is applied to make multiple vouches constitute more solid evidence of "Trustworthiness".  Single roots may present problems when there is no other root, but never to the extent of being an unchallenged authority, and certainly not to the degree that the Internet would experience an irreparable divide.  The problems only really show up when people get involved, and that's why certification authorities are so rich.

Cheers,
Sabahattin

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 18 Feb 2010 08:58:25 +0900

> Yeah, but at least now we know the difference between the subversion
> of the "Chain of trust" and some bloke with a packet sniffer.

It merely means that DNS depends on two chains of trust: one with
zones and another with ISPs.

As we know, ISPs are reasonablly trustable.

> The point here is, we now have a way to verify the technical
> functions we depend on today are working properly.

That's pointless.

Indeed, DNSSEC technically verifies keys have valid signatures.

However, DNSSEC does not technically verify the valid signatures
are obtained legitimately.

						Masataka Ohta

---

From: Basil Dolmatov <[email-masked]>
Date: Thu, 18 Feb 2010 09:50:07 +0300

Masataka Ohta пишет:

Basil Dolmatov wrote:

Your and my ISPs are loosely connected by a chain of social trust
relationships between adjacent ISPs, which is why we can exchange
packets over the Internet

Yes.

with reasonable security.

No. Without any security at all.

No garanties of delivery, no origin validation, no path validation, etc.

"social trust relationship" can arrange packet delivery but cannot
arrange any responsibility for proper delivery.

I as have said before the picture you are drawing reflects Internet 20
years ago, when all participants cooperated and worked on the benefit
of the network.

No _not_all_ participants have this paradigm in the network and the
share of those who do not participate in any "social trust
relationships" but simply use the network in the manner they feel good
for achieving their goals (sometimes criminal ones) is increasing
continuously.

With no security at all. Otherwise we would have never heard about
"cache poisoning".

dol@

P.S. Just to mention: I liked Internet 20 years ago much more and a bit
nostalgic about it.

---

From: Basil Dolmatov <[email-masked]>
Date: Thu, 18 Feb 2010 09:59:29 +0300

>> sense.  There are _NO_ persons involved in the process,
I can see some... ;)

Any operation which is placed out-of-band of DNSSec requires some 
trusted manual intervention.

Just for example:

First person - zone administrator who manually creates KSK pair and, 
private part of it in secure place and ensure that no unauthorized use 
of it is probalbe.

Second person - the administrator of upper zone, who receives DS record 
from lower zone, manually ensures that it came from authorized source 
and decides to place it in the zone file.

Lot of persons (all resolvers administrators) - who should manually 
change the root zone KSK, when rollover occurs, manually ensuring 
beforehand that new KSK has came from authorized source.

Yes, the plain X.509 certificates are not used in DNSSec, but the 
overall system design is the PKI-style.

dol@

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 18 Feb 2010 17:10:00 +0900

> No garanties of delivery, no origin validation, no path validation, etc.

Hmmmm, you seemingly do not know anything about reasonable security
over the current Internet such as "return routability", on which
many protocols depend.

> "social trust relationship" can arrange packet delivery but cannot arrange any 
> responsibility for proper delivery.

BGP is the mechanism for ISPs to exchange information on which
ISPs are responsible for proper delivery of packets destined
to which address ranges.

For you, your ISP is, representing the Internet, responsible for the
proper delivery.

> I as have said before the picture you are drawing reflects
> Internet 20 years ago, when all participants cooperated and
> worked on the benefit of the network.

To your surprise, reasonable security by network operators is
not so new. Highly commercial telcos have been offering it for
about 100 years. That is, if you dial my phone number, you can
reasonably expect to reach my phone.

> With no security at all. Otherwise we would have never heard about "cache 
> poisoning".

Cache poisoning is a problem of poor implementations to handle
additional information including glue.

> P.S. Just to mention: I liked Internet 20 years ago much more and a bit 

See above for more than 100 years of history.

							Masataka Ohta

---

From: David Conrad <[email-masked]>
Date: Thu, 18 Feb 2010 09:35:56 -0800

On Feb 18, 2010, at 12:10 AM, Masataka Ohta wrote:
> For you, your ISP is, representing the Internet, responsible for the proper delivery.

Your point?

You are aware, of course, that some ISPs are actively engaging in DNS response modification, right?

> about 100 years.

Ignoring for a second that the Internet isn't the telephony system (intelligence in the network is in different places), there have been MITM attacks against the telephony system.

> additional information including glue.

No.

Cache poisoning is ALSO a result of the fact that the path between source and destination is not protected.

Regards,
-drc

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 19 Feb 2010 04:40:04 +0900

> Ignoring for a second that the Internet isn't the telephony system
> (intelligence in the network is in different places),

OK. You are saying that any network with intermediate intelligence
to modify DNS responses is not a part of the Internet.

I agree with you.

That is, we agree that ISPs in your first statement are not really
ISPs.

Note that it does not affect resemrance of weak security models of
the Internet and the telephone network.

> there have been MITM attacks against the telephony system.

There will be MITM attacks (by a man who operate a CA in the middle
of a CA chain) against DNSSEC. So?

> Cache poisoning is ALSO a result of the fact that the path
> between source and destination is not protected.

OK.

As cache poisoning can occur with poorly implemented DNSSEC
(e.g. with implementations which imprecisely check signatures)
that you should conclude that DNSSEC dose not protect the path
between source and destination.

DNSSEC does not give any protection to the CA path between
source and destination, anyway.

						Masataka Ohta

---

From: David Conrad <[email-masked]>
Date: Thu, 18 Feb 2010 11:51:49 -0800

No.

> That is, we agree that ISPs in your first statement are not really ISPs.

Attempting to redefine the world to meet your odd definitions doesn't seem to be a particularly useful exercise.

> of a CA chain) against DNSSEC. So?

I'm not sure why you are pretending that useful security is binary.

Regards,
-drc

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 19 Feb 2010 05:08:12 +0900

> No.

I'm afraid you have lost your point.

> Attempting to redefine the world to meet your odd definitions
> doesn't seem to be a particularly useful exercise.

So?

> I'm not sure why you are pretending that useful security is binary.

I'm afraid you are saying "DNSSEC or die", while I'm saying
"reasonable security is good enough". Which, do you think,
is binary?

							Masataka Ohta

---

From: Joe Baptista <[email-masked]>
Date: Thu, 18 Feb 2010 22:14:07 -0500

"useful security is binary". thats great stuff. says nothing - means even
less. theres another great term I've seen the Isociety cabal use whenever
their stuck - "it does not scale".

There are better solutions to the DNS security escapades that are simple and
involve no economic cost to the users at large. DNSSEC is not the answer.
DNSSEC is the nightmare. The solution lies with DNScurve -
http://bit.ly/cjmH2n

The Internet already is a security nightmare - why contribute to it with
DNSSEC. Fix the UDP problem once and for all with DNSCurve. Or something
like it.

DNSSEC is old technology 1024 is a juvenile encryption standard. DNSSEC does
not solve the UDP problem. DNSCurve will.

And I remind IETF members that Dr. Bernstein was the first to address the
UDP port problem. DNScurve will take the DNS to the next step. Ensure the
machine you contacted is the machine you want to speak too.

At least members do something. Because the DNSSEC joke must end. We need
solutions to address the problem that don't end up being a make work
project.

cheers
joe baptista

---

From: Martin Rex <[email-masked]>
Date: Fri, 19 Feb 2010 22:42:23 +0100 (MET)

> untrustworthy, which means PKI is merely socially or weakly

DNS has always contained highly dynamic, quickly or already outdated
and non-negligable amounts of incorrect information.  

But the inaccuracies used to be primarily of the out-dated and
accidentally wrong kind, not of the maliciously inaccurate ("fake")
kind.

When DNSsec is used, the data in DNS will continue to be loosely
inaccurate or outdated.  But inserting maliciously inaccurate ("fake")
data will hopefully become more difficult.

Personally, I firmly believe that any assumption that data in the DNS
could be trusted, is fatally flawed.  And that any security architecture
that relies on DNS data being accurate, is fatally broken.

What DNSsec will provide is what is described in rfc-4033 section 3.1
data origin authentication and data integrity protection.

You can get some level of assurance that the successful result from
DNSsec name resolution will provide you an answer from the
entity that has been authorized to administrate a particular zone
and that this data was not modified in transit (network communication)
or at rest (on the nameserver or in caches).

One should *NOT* make any assumptions about the accuracy of that
information in any kind or form.  The information could be
outdated, it could be inaccurate and it could have been
created by subverting the administrative procedures of
the registry -- or e.g. by hacking the database which sources
the nameserver's DNSsec zones.

In order to obtain any level of "trust", you would not only have
to configure the keys for specific zones that you trust,
but also create an out-of-band trust relationship
(person-to-person, audit) of the registry administrating the
relevant DNS-zones you want to trust, their equiment and
adminstrative procedures,
 
*PLUS*

you will need to create an out-of-band trust relationship to
the adminstrator(s) who operate(s) the server(s)/service(s)
for which you want to resolve the names through DNSsec and
their network admins and the operational procedures that they use.

That might be a time-consuming, expensive and error-prone effort
that by itself get outdated, and it scales nowhere considering
the size of the DNS.

At home I'm using ADSL (~3500/500 KBps), get an IP-Address
dynamically assigned by my ISP whenever my DSL-router reconnects.
I'm using it with a flatrate and VoiP, so it's online 24h, but
the connection is dropped at least once per day -- and I *ALWAYS*
get a new IP assigned on re-connect!

I have set up my DSL router to register the IP assigned by the ISP
with dyndns.org (builtin feature of the DSL-router).  But whenever
the connection is dropped, that DNS entry with dyndns.org is
inaccurate until my router re-connects and updates it with the new IP.

Anyone who thinks that information in the DNS could be trusted
is either using a funny definition of trust or has no clue how
DNS is actually used and what kind of data it contains (and
how that data is created and maintained).

There are a few things currently being done that will potentially
no longer work when DNSsec is used.  Currently, some countries seem
to ask ISP for blackholing or "redirecting" (=faking) DNS-requests for
particular sites.  Blackholing in the form of NXDOMAIN may not longer
work, Blackholing by dropping the request may result in clients
walking the list of authoritative Nameservers instead of contining
to pull the ISPs nameserver, and faking will also no longer work
as soon as the relevant zone has DNSsec enabled and the ISP has
no adminstrative control over that zone (the most common case).

Not having read all of the relevant RFCs, I don't know what the
situation will be for companies running with their own DNS universe,
private IPv4 address spaces (10.x.x.x, 192.168.x.x) and potentially
non-official TLD (company.corp).  It probably depends whether
and how these companies have made real-world DNS information
available on their internal networks.

DHCP and DNS dynamic update also appears to create interesting
challenges for the use of DNSsec for involved DNS zones.

-Martin

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 20 Feb 2010 08:58:28 +0900

> data origin authentication and data integrity protection.

That is already offered with plain old DNS with UDP checksum,
cookie and return routability, though UDP checksum is optional
and cookie of message ID is a little bit too short.

> that by itself get outdated, and it scales nowhere considering

Right. So, DNSSEC is no better than plain old DNS.

> inaccurate until my router re-connects and updates it with the new IP.

It partially is a problem of unnecessarilly long TTL, which
means poor administration of related zones. That is, DNS is
not fully responsible for the problem.

However, it is almost certain that the zones will have poor
administration and, thus, poor security even if DNSSEC were
deployed.

						Masataka Ohta

---

From: Martin Rex <[email-masked]>
Date: Sat, 20 Feb 2010 01:20:46 +0100 (MET)

> FYI, zones are operated by people.

That is missing the point.

>From what I've seen, the whole architecture of DNSsec is based
on assertions of keys being authorized to sign keys being authorized
to sign RRs.

The blobs of data that are being used in the signatures look very
similar to "RSASSA-PKCS1-V1_5-SIGN" (PKCS#1 v1.5 signature scheme)
to me.  If you look at rfc-2437 (PKCS#1 v2.0)

http://tools.ietf.org/html/rfc2437

it does _NOT_ use the term "digital signature" anywhere throughout
that document, simply because there are no digital signature
described in that specification.  

"digital signature" is a term that has been picked up and used
by legislators to describe things that are equivalents to
real/natural signatures that represent legal entities,
and where they attach legal liabilities and contractual obligations.

The things used in DNSsec are just "signatures", they are
definitely _NOT_ "digital signatures" in any legal sense.

And btw. the reason why dnssec-gost needs to be a MAY, and why the
IETF _standards_ ought to require all DNSsec-signed zones
to include signatures with a mandatory to implement algorithm
is described in BCP-61, Section 6 as "the Danvers Doctrine":

http://www.rfc-editor.org/bcp/bcp61.txt

http://tools.ietf.org/html/rfc3365#section-6

-Martin