DNSSEC is almost worthless!

[Thierry Moreau <[e-mail]>]

Dear all:

Some non-participants to the dnsext wg may assess the DNSSEC as a
useless effort to solve a marginal security issue in Internet.
For these persons, there is no reason to participate in dnsext
activities related to DNSSEC.

This message reviews the elements of DNSSEC added value, and then
discusses a condition which may vary the DNSSEC added value
according to the participant perspective. This is relevant to the
discussion of trust anchor key requirements document: if DNSSEC
has only some marginal value, it is justified to put little
effort in coming up with a "rigorous" set of requirements.

First, what does DNSSEC actually do? It provides DNS resolvers
with end-to-end cryptographic assurance about data retrieved from
the DNS. More precisely, it provides
1) a user feedback like a red-yellow-green light besides a domain
name (resp. for bogus-insecure-secure DNSSEC name resolution
status), or a turned-off traffic light (for an indeterminate
DNSSEC status),
2) the same indication as in 1) above, but for a managed
nameserver instead of an end-user system (e.g. bogus name
resolution being logged in a corporate nameserver system),
3) key management support for other security schemes, i.e. secure
applications that would retrieve data (typically public keys of
remote parties in cryptographic protocols) from the secured DNS
and accept the data only if its DNSSEC status is "secure".

Item 1) requires a end-user education, which proved mostly
ineffective for many IT security schemes. Item 1) is thus only
valuable to financial institutions for maintaining the onus of
on-line banking security to the account holders (so the bank can
claim that it offered a "commercial-grade security procedure"
allowing the account holder to protect himself from
phishing/pharming attacks).

Item 2) can assist a corporate IT department to protect its
internal users from bogus data from the Internet DNS, provided
sufficient attention is paid to the operation of the nameservice.

Items 1) and 2) both require adoption of DNSSEC technology at
various stages of the end-to-end process, and a noticeable
penetration rate of DNSSEC. In the meantime, DNSSEC deployment
without genuine value added is deemed to be insufficiently
supported for proper implementation and troubleshooting. Some
comments were made that DNSSEC is just too complex for effective
deployment (e.g. message from Bert Hubert to namedroppers in Feb
2006).

In addition, the end-to-end cryptographic assurance is perhaps
justified mostly because there are too many nameservers operating
with BIND version prior to 8.4 (these are vulnerable to the DNS
cache poisoning attack).

Items 1) and 2) obviously need trust anchor key configuration,
but are not critically dependent on "rigorous" trust anchor
rollover procedures.

Item 3) is not strictly part of the DNSSEC service definition,
but DNSSEC deployment would be instrumental in providing this
novel means of authenticated public key distribution. This item
3) is perhaps the most tangible value from DNSSEC, but it is a
niche application as the cryptographic application protocol usage
is marginal in the first place. I may provide references
supporting the existence of this item 3).

DNSSEC-supported encryption (a by-product of item 3) is certainly
not a welcome development for governmental organizations
concerned with "national security interests". So, from the
perspective of governments, DNSSEC application to public key
distribution would not contribute to DNSSEC value. Many dnsext
active participants work for organizations funded by, or
receiving significant contracts from, the US or OECD governments,
including two editors of
draft-ietf-dnsext-rollover-requirements-00.txt.

The item 3) needs trust anchor key configuration, just like items
1) and 2), but this time "rigorous" trust anchor rollover
procedures would make a difference in the effectiveness of the
"service" (from a security perspective).

My understanding of the ietf dnsext current activities is much
influenced by the marginal value of DNSSEC from items 1) and 2),
and the negative value of item 3) from the perspective of
governments. I don't know to which extent there are dnsext active
participants who see positive value in item 3) to the point of
contributing to the TAK rollover debate.

TAKREM for DNSSEC (draft-moreau-dnsext-sdda-rr-01.txt,
draft-moreau-dnsext-takrem-dns-01.txt) is *both* rigorous *and*
efficient. Efficiency would be beneficial to DNSSEC deployment if
there was value in DNSSEC to justify its deployment in the first
place. About TAKREM rigor, the above suggests that the intrinsic
security properties of TAKREM might appear as *lowering* the
value of DNSSEC for governments.

Regards,

-- 

- Thierry Moreau

CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, Qc
Canada   H2M 2A1

Tel.: [phone]
Fax:  [phone]

web site: http://www.connotech.com
e-mail: [e-mail]


--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>