Subject: [xmpp] Fwd: Re: IAB statement on the RPKI.

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 19 Feb 2010 15:50:25 -0700

Re _xmpp-delegate, ome insightful comments about what DNSSEC does and
does not accomplish from a thread on the main IETF list...

-------- Original Message --------
Subject: Re: IAB statement on the RPKI.
Date: Fri, 19 Feb 2010 22:42:23 +0100 (MET)
From: Martin Rex <[email-masked]>
Reply-To: [email-masked]
To: [email-masked] (Masataka Ohta)
CC: [email-masked]

Masataka Ohta wrote:
> 
> 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.

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
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Jehan Pagès <[email-masked]>
Date: Mon, 22 Feb 2010 00:57:27 +0900

Hi,

On Sat, Feb 20, 2010 at 7:50 AM, Peter Saint-Andre <[email-masked]> wrote:
>[skip]

Ok so DNS is still not accurate with DNSSEC (not so astonishing
anyway. The inaccuracy/out-of-date issue is logical with the DNS
global system and probably it will never change).

This part is not "too bad" as long as we could assume that at least
the DNS does not direct your domain to a malevolent server. On this
point this person seems to say that DNSSEC can be more or less
trusted, but they don't seem convinced that much («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.»). So
considering that the _xmpp-delegate proposition clearly breaks the
identity protection of TLS if DNS information cannot be trusted (as a
server will be able to present another identity than the requested
domain and still be considered, wrongly, perfectly secured in this
proposition, as long as it is in the DNS), this is not in favor of
_xmpp-delegate here, even with DNSSEC.

Moreover this person also points out another interesting point which I
wondered as well: for people looking for simplicity (so clearly one of
the targets of the potential _xmpp-delegate users here: they don't
want to bother about certificates and hosting their own server, etc.),
this may not be that simple... I mean not if you want safety as well:

«

»

Indeed as you would now move the identity issue (saying "who"/which
domain is allowed to serve your service) to the DNS part, you need to
build trust with the DNS service as well (the DNS will have not only a
redirection role, but also a big security role) which can be
complicated. Plus, you lose the flexibility of taking care yourself of
security.

Yeah, as for now, I am really not convinced that _xmpp-delegate is a great idea.
Bye.

Jehan