RE: DNSSEC - Signature Only vs the MX/A issue.
Christian Huitema
> host
> discards the bogus DNS info but never gets the DNSSEC validated info.
Actually, if you look at market motivation, there is a case to be made
for focusing on DOS attacks.
Suppose someone is trying to secure a transaction with
"www.example.com". In practice, they will use some form of end-to-end
security, TLS or SSL, as in "https://www.example.com". The end to end
security should provide a proof that they are communicating with the
real "www.example.com".
In these conditions, what is the point of securing the DNS look-up? The
end-to-end verification of the certificate will validate it.
Certificates allow for third party signature, and thus are somewhat
easier to deploy than a strict hierarchical scheme. The verification
will not implicitly validate the mapping of name to address. It will
also protect against routing attacks that might divert the traffic to a
bogus site, an attack not addressed by securing the DNS look-up.
End-to-end security mitigates a spoofing attack and reduces it to a
denial of service attack. If the name to address mapping was wrong, or
unavailable, or if the routing was bogus, the secure transaction will
simply not happen. The focus of DNS security should thus be a protection
against DOS attacks, i.e. ensure that if a record exists, it will be
found.
-- Christian Huitema
--
to unsubscribe send a message to namedroppe...@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>
bert hubert
> In these conditions, what is the point of securing the DNS look-up? The
> end-to-end verification of the certificate will validate it.
Exactly. This is also the reason why we don't have an "ARPSEC" protocol.
Or perhaps we do, but is about as exciting as DNSSEC. I wrote about this on
http://ds9a.nl/secure-dns.html .
Bert
--
http://www.PowerDNS.com Open source, database driven DNS Software
http://netherlabs.nl Open and Closed source services
bert hubert
> so, here's what i told stuart cheshire: if you believe that the web is all
> there is to the internet, or you believe that the approach taken for securing
> https/imaps/smtps is appropriate for all future applications/protocols used
> on the internet, then it's natural that you would think ssl/tls/x509 is all
> we need. i do not think that the ssl/tls/x509 model is futureproof, and so
> i think that we need something else, something more internet-like.
I very much agree with this sentiment. But DNSSEC is not the answer as is
only sends out authenticated small and static messages.
It doesn't to whole transactions.
One cannot rely on DNSSEC for the whole shebang. In theory it could be the
conduit of a web of trust, perhaps that is what you mean?
Which makes the vast amount of effort and brain cycles on it all the more
puzzling. In the vein of your statement regarding the 'king makers' in the
browser that annoint X.509 certificate vendors, perhaps there is something
along those lines happening within DNS?
I honestly don't know (it wouldn't seem likely), but it is unclear to me why
people continue to expend so much time on such a small part of a secure
internet.
Christian Huitema
Well, Stuart and I often disagree, so you might consider that us
agreeing somehow shows something...=20
=20
> so, here's what i told stuart cheshire: if you believe that the web is
> all there is to the internet, or you believe that the approach taken
for
> securing https/imaps/smtps is appropriate for all future
applications/protocols
> used on the internet, then it's natural that you would think
ssl/tls/x509 is
> all we need. i do not think that the ssl/tls/x509 model is
futureproof,
> and so i think that we need something else, something more
internet-like.
I am not so much looking at SSL than at end-to-end security. Name
resolution is one step in the end-to-end process of completing the
transaction. If you are really concerned about the security of the
application, you want to secure the entire process, not just one step.
You may use SSL, secure RTP, IPSEC, or maybe some application specific
solution. The point is, you will use something.
Now, consider the "market for DNS security". Logically, the early
adopters ought to be the most security conscious users. Yet, those
security conscious users are also most likely to deploy end-to-end
security for their application. They are thus not likely to invest in
yet another deployment, and to bear the management cost of yet another
system. They will only do this investment if securing the DNS brings
clear additional benefits, on top of what they already have.
What would be the characteristic of a DNS security system that
complements, rather than replace, end-to-end security? For me, the
obvious answer would be to ensure availability of the DNS service. The
secure DNS should guarantee that, if the relevant name servers are
available and reachable, the name resolution transaction will complete.=20
The best "secure DNS" would be one that provides that guarantee at the
least possible deployment cost.=20
-- Christian Huitema
Masataka Ohta
> so the Secure DNS model is
> end-to-end rather than interior-only.
It is not e2e.
With DNSSEC, zone administrators between you and your peer are
the intelligent intermediate entities subject to all the technical
and social hacking attacks.
E2e security can be enjoyed if and only if you and your peer directly
share secret information without intelligent intermediate entities.
DNSSEC does not provide cryptographic security.
PKI does not provide cryptographic security.
Masataka Ohta
Hallam-Baker, Phillip
Otherwise we end up engaged in hairsplitting debates that have no basis =
in common sense. There is no perfect security, get over it.
DNSSEC provides certain cryptographic controls in certain instances. =
DNSSEC is clearly not necessary to do anything we do today otherwise we =
could not do it.=20
The point is that Internet security is kind of a mess. There is no =
coherent architecture.
The utility in DNSSEC lies in the deployment of the next generation of =
Internet security infrastructure which uses DNS to perform policy =
distribution. Protocols like DKIM and architectures that address the =
issue of deperimeterization.
> -----Original Message-----
> From: owner-nam...@ops.ietf.org=20
> [mailto:owner-nam...@ops.ietf.org] On Behalf Of Masataka Ohta
> Sent: Sunday, December 10, 2006 8:38 PM
> To: Paul Vixie
> Cc: Christian Huitema; Ralph Droms; bert hubert;=20
> namedr...@ops.ietf.org
> Subject: Re: DNSSEC - Signature Only vs the MX/A issue.
>=20
> Paul Vixie wrote:
>=20
> > so the Secure DNS model is
> > end-to-end rather than interior-only.
>=20
> It is not e2e.
>=20
> With DNSSEC, zone administrators between you and your peer=20
> are the intelligent intermediate entities subject to all the=20
> technical and social hacking attacks.
>=20
> E2e security can be enjoyed if and only if you and your peer=20
> directly share secret information without intelligent=20
> intermediate entities.
>=20
> DNSSEC does not provide cryptographic security.
>=20
> PKI does not provide cryptographic security.
>=20
> Masataka Ohta
>=20
>=20
>=20
> --
> to unsubscribe send a message to=20
> namedroppe...@ops.ietf.org with the word 'unsubscribe'=20
> in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/namedroppers/>
>=20
>=20
Masataka Ohta
> If you want to make such statements first state your risk model.
Are you saying it to Paul's statement of "so the Secure DNS model is
end-to-end rather than interior-only."?
Anyway, if you use your risk model, your statements is nothing more
than a fantasy.
I, instead, have been stating the reality that ISPs and zone
administrators are equally (un)trustworthy.
As a result, DNSSEC is NOT cryptographycally secure and is as secure
as plain DNS.
Masataka Ohta
Hallam-Baker, Phillip
risk elimination.
The point you make is not new, Bruce Scheneir made it together with Carl =
Ellison in a paper some years back. He was wrong then and Secrets and =
Lies is essentially explaining why.
Most cases of administrative incompetence will result in a complete loss =
of service. DNSSEC does not add a significant number of new ways to =
screw up and the remedy is exactly the same.=20
The cases where administrative incompetence leads to a security breach =
are not as likely as direct attack and in any case very difficult to =
exploit successfully without inside knowledge that allows for more =
powerful attacks.
DNSSEC is not intended to control against administrator malfeasance.=20
> -----Original Message-----
> From: Masataka Ohta [mailto:mo...@necom830.hpcl.titech.ac.jp]=20
> Sent: Monday, December 11, 2006 7:48 PM
> To: Hallam-Baker, Phillip
> Cc: Paul Vixie; Christian Huitema; Ralph Droms; bert hubert;=20
> namedr...@ops.ietf.org
> Subject: Re: DNSSEC - Signature Only vs the MX/A issue.
>=20
> Hallam-Baker, Phillip wrote:
>=20
> > If you want to make such statements first state your risk model.
>=20
> Are you saying it to Paul's statement of "so the Secure DNS=20
> model is end-to-end rather than interior-only."?
>=20
> Anyway, if you use your risk model, your statements is=20
> nothing more than a fantasy.
>=20
> I, instead, have been stating the reality that ISPs and zone=20
> administrators are equally (un)trustworthy.
>=20
> As a result, DNSSEC is NOT cryptographycally secure and is as=20
> secure as plain DNS.
>=20
> Masataka Ohta
>=20
>=20
>=20
--
Masataka Ohta
> AS I have been saying for over a decade security is risk
> management, not risk elimination.
I fully agree with you that there ain't no such thing as
cryptographical security.
> The point you make is not new, Bruce Scheneir made it together with
> Carl Ellison in a paper some years back. He was wrong then and
> Secrets and Lies is essentially explaining why.
Hugh?
You failed to deny my point that DNSSEC and plain DNS are equally secure.
> Most cases of administrative incompetence will result in a complete
> loss of service. DNSSEC does not add a significant number of new
> ways to screw up and the remedy is exactly the same.
Complex protocols are more complex to implement and operate and,
thus, insecure.
For example, it is a lot more likely that DNSSEC software has
buffer overflow valunerability than plain DNS software.
> The cases where administrative incompetence leads to a security
> breach are not as likely as direct attack and in any case very
> difficult to exploit successfully without inside knowledge that
> allows for more powerful attacks.
I'm not sure what you mean "direct attack" but I understand that
you failed to make a point on the merits of deploying DNSSEC.
Masataka Ohta
bert hubert
> Complex protocols are more complex to implement and operate and,
> thus, insecure.
>
> For example, it is a lot more likely that DNSSEC software has
> buffer overflow valunerability than plain DNS software.
This is not only a lot more likely, but actual fact if we look at most DNS
security advisories of the past few years.
For example, look at SIG Query Processing (CVE-2006-4095), "BIND: Self Check
Failing" (2005-25-01), "BIND: Remote Execution of Code" A/K/A "sigrec",
"OpenSSL buffer overflow", "tsig bug", "sigdiv0 bug", etc, all found on
the fine page http://www.isc.org/index.pl?/sw/bind/bind-security.php
Bert
--
http://www.PowerDNS.com Open source, database driven DNS Software
http://netherlabs.nl Open and Closed source services
--
Hallam-Baker, Phillip
misinterpreting what they said to claim the opposite.
This conversation is closed.=20
> -----Original Message-----
> From: Masataka Ohta [mailto:mo...@necom830.hpcl.titech.ac.jp]=20
> Sent: Tuesday, December 12, 2006 2:20 AM
> To: Hallam-Baker, Phillip
> Cc: Paul Vixie; Christian Huitema; Ralph Droms; bert hubert;=20
> namedr...@ops.ietf.org
> Subject: Re: DNSSEC - Signature Only vs the MX/A issue.
>=20
> Hallam-Baker, Phillip wrote:
>=20
> > AS I have been saying for over a decade security is risk=20
> management,=20
> > not risk elimination.
>=20
> I fully agree with you that there ain't no such thing as=20
> cryptographical security.
>=20
> > The point you make is not new, Bruce Scheneir made it together with=20
> > Carl Ellison in a paper some years back. He was wrong then=20
> and Secrets=20
> > and Lies is essentially explaining why.
>=20
> Hugh?
>=20
> You failed to deny my point that DNSSEC and plain DNS are=20
> equally secure.
>=20
> > Most cases of administrative incompetence will result in a complete=20
> > loss of service. DNSSEC does not add a significant number=20
> of new ways=20
> > to screw up and the remedy is exactly the same.
>=20
> Complex protocols are more complex to implement and operate=20
> and, thus, insecure.
>=20
> For example, it is a lot more likely that DNSSEC software has=20
> buffer overflow valunerability than plain DNS software.
>=20
> > The cases where administrative incompetence leads to a=20
> security breach=20
> > are not as likely as direct attack and in any case very=20
> difficult to=20
> > exploit successfully without inside knowledge that allows for more=20
> > powerful attacks.
>=20
> I'm not sure what you mean "direct attack" but I understand=20
> that you failed to make a point on the merits of deploying DNSSEC.
>=20
> Masataka Ohta
>=20
>=20
>=20
--