DNS authentication vulnerable to cache poisening

July 22nd, 2008
    Affects Windows, Unix/Linux, Juniper and Cisco products. This was first mentioned around July 7. But now we have a full discussion about responsible disclosure.
    Why does this vulnerability matter and why should it be out into the open?
    To make our DNS system more secure against such and other types of attacks for sure and because seucrity through obscurity is just plain dumb.

What is the technical issue

Vulnerable DNS software may be tricked into supplying incorrect IP addresses for requested hostnames. This could allow an attacker to redirect internet traffic to a possibly malicious website.

In practice this could work if an attacker manages to flood a DNS server with multiple requests for domain names. One example might be www.CyTRAP00001.com, www.CyTRAP00002.com and so on. Since the name server may not have seen these requests before it proceeds to query a root server for the name server that handles lookups for domains ending in .com. In turn, the attacker proceeds by using the information to send fraudulent lookup information to the DNS server and make it appear as if it came from the authoritative .com name server. Unfortunately, once enough requests have been issued, one of these spoofed requests could just match and the IP address for a requested domain will be falsified.

How new is this?

The issue is not that new since a first alert has been issued around July 8-10 by some alerting services not providing many details.

Note the description section of SecPod ID: 10109 Multiple Vendor DNS Spoofing Vulnerability This advisory alludes to the critical element of bogus additional RRs. To our best knowledge it appears to be the only one that mentioned that problem.

What is the discussion right now - someone posting code

The question now is when a full description will be provided by someone posting working code? The exploit code has been available in certain circles for some time now. By posting the vulnerability and making the details available, responsible security engineers would then have the possibility to check if the problem exists regarding their systems and DNS handling.

Security advisories like the one below we got this morning are of little help because they do not provide a full description:

AL-2008.0080 — [Win][UNIX/Linux][Juniper][Cisco] — Multiple DNS implementations vulnerable to cache poisoning

Neither do the solutions suggested take care of the problem described in the above advisory

The underlying premise of all the discussions is that we have to keep the details under wraps until Dan Kaminsky can present his findings at the Black Hat conference. Naturally, some researchers have posted some thoughts about this issue including a possible exploit of this vulnerability:
On Dan’s request for “no speculation please”

However, keeping information like a DNS spoofing vulnerability under wraps, while the bad guys know the details already is neither responsible disclosure nor helping in better protecting the internet. It actually increases our risks while helping Dan Kaminsky and Black Hat to get publicity. Is this ethical and responsible behavior?

Please check out:
follow Infosec on Twitter CyTRAP Labs - advisory - Versatel, Vivendi and Tele2 - vulnerability fixed DNSSEC - will the Trust Anchor Repository (TAR) make a different
be the first to know - subscribe DNSSEC - a global effort that experiences difficulties on the road to success 2 disclosure when a zero-day exploit is in progress

Technorati , , , , ,

Related Posts:

  1. IPv6 deployment 10 years after - is there a disaster in the making?
  2. DNSSEC - a global effort that experiences difficulties on the road to success
  3. Research that matters - Microsoft’s CAPTCHA approach is insecure
  4. proprietary encryption schemes are a bad idea
  5. Microsoft predicts rise of service interruptions with datacenters

EMail This Post | Print This Post

del.icio.us:DNS authentication vulnerable to cache poisening  digg:DNS authentication vulnerable to cache poisening  spurl:DNS authentication vulnerable to cache poisening  wists:DNS authentication vulnerable to cache poisening  simpy:DNS authentication vulnerable to cache poisening  newsvine:DNS authentication vulnerable to cache poisening  blinklist:DNS authentication vulnerable to cache poisening  furl:DNS authentication vulnerable to cache poisening  reddit:DNS authentication vulnerable to cache poisening  fark:DNS authentication vulnerable to cache poisening  blogmarks:DNS authentication vulnerable to cache poisening  Y!:DNS authentication vulnerable to cache poisening  smarking:DNS authentication vulnerable to cache poisening  magnolia:DNS authentication vulnerable to cache poisening  segnalo:DNS authentication vulnerable to cache poisening

InfoSec and Twitter - ropes to know #2

July 15th, 2008

Twitter - a sort of micro-blogging or SMS messaging that allows one to reach many people quickly, is becoming ever more popular.

Regulation is clear, firms must be able to produce digital files. Now a U.S. Member Congress is using Twitter. Will Congress or the elected officials be able to produce tweets on Twitter in a case of e-discovery or will the judge throw the book at them?

What about the risk against your corporation’s reputation and brand coming from these social networks and social media? What about threats and vulnerabilities?

We tell you what you should watch out for in this post.

A while back we did this

InfoSec and Twitter - ropes to know #1

In the above post amongst other things we pointed out that:

    As we explore this wonderful world of cyberspace, we must beware that that whatever we say, write or sing about is being recorded.

This does, of course, also apply to your workforce or colleagues using Twitter at work or from home. Just in case you thought it does not apply, usage numbers are growing rapidly in the U.S. and Europe, as well as Japan.
2008-07-08 - Twitter growth continues despite outages

The above graph from a firm called Hitwise shows that Twitter usage is growing. This growth happens despite the several outages Twitter has had during the last 10 weeks and will likely continue to have in the next few months.

What does this mean for compliance

Federal Rules of Civil Procedure render electronic communications­from both defendants named in a lawsuit and third parties who may have information pertaining to the case ­admissible in court.

Imagine the case where a subpoena said,

    ‘Here are the 60 named plaintiffs in these lawsuits. For those 60 plaintiffs, give us their tweets or Twitter messages during the course of the meeting or workday’.

Such a request might be approved by the court. Unfortunately, this raises a lot of privacy concerns that one does not necessarily must deal with if the company is just trying to get the things from the people involved in the lawsuit.
Text messages, tweets (140 character messages people send using Twitter) are likely viewed the same way as other forms of digital communication, such as e-mail.

Unfortunately, we also have to beware that whatever we say is recorded. In turn, when your employer is being called by the court to produce something, it is incumbent on you to produce it.

Case study - U.S. Congress using Twitter

This is a no starter if not a no brainer. People will use it from their private smartphone , iPhone and so on during the workday and when off work. Talking about work as well as private matters.

A very legalese debate is happening in the US Senate over the use of Twitter and QIK by senators:

Is the House going to limit the free speech of its own members?

U.S. Rep. Michael Capuano, Chairman of the Congressional Commission on Mailing Standards, is aware that using Twitter to reach one’s constitutency means taking advantage of the social media. In fact, U.S. Congressmen John Culberson (R-TX) is using Twitter and QIK these two similar types of message tools for communicating freely with the public. Naturally, by being the first he is racking up all the positive public image points that entails making him even better known, something that might come in handy during re-election time.

One could suggest that all congressmen should emulate this behavior. Naturally, this would require change of some existing House rules that actually forbid members of Congress from posting “official communications” on other sites (webpages, Twitter, and so on).

What does it mean for the U.S. Congress and the European Parliament?

For an elected politician, may it be a minister, senator, member of the European Parliament or an EC Commissioner such as Viviane Reding who loves to Twitter, maybe :-) , sending out tweets to followers - such as one’s constituents - can keep them informed about the latest developments happening on the floor (e.g., how a bill is doing).

Nopnetheless, some legal barriers may have to be removed in some countries to allow elected officials to use social media effectively for the benefit of their constituents.

Also,e-discovery requires that you are able to produce evidence during the discovery process such as e-mails. I am just waiting for the first judge to ask for evidence regarding accused parties’ tweets on Twitter. What will happen if they cannot be produced?
What is your take on this issue?

Please check out:
follow Infosec on Twitter be the first to know - subscribe Early Warning System - what works and how Twitter and Facebook can help
follow Congressmen Culberson on Twitter
Warren Buffet - ropes to skip - c-level blogs - FAQ Regulation that matters - e-discovery in Intel litigation

Technorati , , , , , ,

Related Posts:

  1. DNS authentication vulnerable to cache poisening
  2. EU telecoms market - European Parliament - what it means for InfoSec
  3. IPv6 deployment 10 years after - is there a disaster in the making?
  4. ENISA - white paper about USB sticks
  5. DNSSEC - a global effort that experiences difficulties on the road to success

EMail This Post | Print This Post

del.icio.us:InfoSec and Twitter - ropes to know #2  digg:InfoSec and Twitter - ropes to know #2  spurl:InfoSec and Twitter - ropes to know #2  wists:InfoSec and Twitter - ropes to know #2  simpy:InfoSec and Twitter - ropes to know #2  newsvine:InfoSec and Twitter - ropes to know #2  blinklist:InfoSec and Twitter - ropes to know #2  furl:InfoSec and Twitter - ropes to know #2  reddit:InfoSec and Twitter - ropes to know #2  fark:InfoSec and Twitter - ropes to know #2  blogmarks:InfoSec and Twitter - ropes to know #2  Y!:InfoSec and Twitter - ropes to know #2  smarking:InfoSec and Twitter - ropes to know #2  magnolia:InfoSec and Twitter - ropes to know #2  segnalo:InfoSec and Twitter - ropes to know #2

EU telecoms market - European Parliament - what it means for InfoSec

July 9th, 2008
    Two of the European Parliament’s committees have watered down proposed EC legislation regarding Europe’s telecoms markets.

    The proposed changes have implications for telecoms regulators administering legislation and assuring compliance regarding resilience of public ecommunication networks and what telcos can and cannot do (e.g., data security breach, mobile number portability, etc.).

Some time back we informed our Twitter followers what happened on 2008-07-07, the day two of the European Parliament’s committees, namely:

- Industry, Research and Energy Committee (ITRE) and the
- Internal Market and Consumer Protection Committee (IMCO)

voted on the European Commission’s proposals to reform the EU Telecom rules. Check out the link here:

Important here is that Industry Committee also approved a report by Pilar del Castillo (EPP-ED, ES), which proposes setting up a Body of European Regulators in Telecommunications (BERT), composed of the 27 national regulatory authorities, as an alternative to the European Electronic Communications Market Authority (EECMA) advocated by the Commission.

What it means for InfoSec

The compromise proposal put forward by the ITRE Committee, Catherine Trautmann and Pillar del Castillo Vera as well as the IMCO Committee, Malcolm Harbour for the draft framework directive was accepted. This brings in a few changes and 30 amendments. Several things are of interest to people in InfoSec

a) ENISA’s mandate is being extended until 2012 - if this means that the agency will exist beyond or move in the meantime from Crete somewhere else is not known at this time. However, some members felt that a move might have to be considered as well to a more central location to improve accessibility of ENISA and its human capital to Member States and regulators.

b) The EC had proposed some stringent rules regarding data loss and data security breaches. These would have required telcos and internet service providers to meet stringent guidelines and to inform consumers in case privacy of data would have been breached. This proposed part of the legislation was watered down by the committee, something that is really unfortunate.
c) BERT was suggested as an alternative mechanism to EECMA. How such a body will be effective in its daily operations is, however, very questionable. Members of Parliament discussing the EC proposal failed to go into any detail how this would work out in practice (how will compliance be checked, enforced or best practices evolve to make BERT effective)

Tidbit

Even though the final view of the European Parliament will only be known once the Plenary has voted on the Commission proposal – 2008-09-03 is to be the day - the votes in ITRE and IMCO are important steps towards shaping the final legislative texts to be adopted by the European Parliament and the Council.

Also check out this:

2008-07-08 - European Parliament - press release: Telecoms package: EU-wide spectrum management for full benefits of wireless services
Votes by the two Committees - European Parliament - Telecoms package: EU-wide spectrum management for full benefits of wireless services
the wrong way - online privacy and social networks EU telecoms market - European Parliament - what it means for InfoSec


Technorati , , , , , , , , , ,

Related Posts:

  1. DNS authentication vulnerable to cache poisening
  2. InfoSec and Twitter - ropes to know #2
  3. IPv6 deployment 10 years after - is there a disaster in the making?
  4. ENISA - white paper about USB sticks
  5. DNSSEC - a global effort that experiences difficulties on the road to success

EMail This Post | Print This Post

del.icio.us:EU telecoms market - European Parliament - what it means for InfoSec  digg:EU telecoms market - European Parliament - what it means for InfoSec  spurl:EU telecoms market - European Parliament - what it means for InfoSec  wists:EU telecoms market - European Parliament - what it means for InfoSec  simpy:EU telecoms market - European Parliament - what it means for InfoSec  newsvine:EU telecoms market - European Parliament - what it means for InfoSec  blinklist:EU telecoms market - European Parliament - what it means for InfoSec  furl:EU telecoms market - European Parliament - what it means for InfoSec  reddit:EU telecoms market - European Parliament - what it means for InfoSec  fark:EU telecoms market - European Parliament - what it means for InfoSec  blogmarks:EU telecoms market - European Parliament - what it means for InfoSec  Y!:EU telecoms market - European Parliament - what it means for InfoSec  smarking:EU telecoms market - European Parliament - what it means for InfoSec  magnolia:EU telecoms market - European Parliament - what it means for InfoSec  segnalo:EU telecoms market - European Parliament - what it means for InfoSec

IPv6 deployment 10 years after - is there a disaster in the making?

June 26th, 2008
    NOT, however, we will run out of IPv4 address space by mid or late 2010. What we should wonder about is why the IPv6 is taking so long when we can see the writing on the wall. What is holding us back?Just consider the InfoSec improvements it offers compared to IPv4.

IPSec is mandated in IPv6 and consists of a set of cryptographic protocols that provide for securing data communication and key exchange. IPSec uses two wire-level protocols:

    1) Authentication Header (AH) that provides for authentication and data integrity;

    2) Encapsulating Security Payload (ESP) which provides for authentication, data integrity, and confidentiality In IPv6 networks both the AH header and the ESP header are defined as extension headers.
    Moreover, IPSec provides for a third suite of protocols for protocol negotiation and key exchange management known as the :
    3) Internet Key Exchange (IKE) that provides the initial functionality needed to establish and negotiating security parameters between endpoints - it also keeps track of this information to guarantee that communication continues to be secure up to the end point.

However, the uptake of this protocol has been slow if not a crawl to be precise. Large parts of your network, unless you have been remiss in performing routine periodic upgrades, are already IPv6 capable. Windows XP and Vista, MAC OS X as well as Unix support IPv6 as do most router vendors.

As the graphic to the right illustrates, deployment of IPv6 has been slow (see presentation slides where the graphic to the left was taken from - p. 47 here):

Huston, G., & Michaelson, G. (May 5-9, 2008). Measuring IPv6 deployment. Presentation slides for Rip 56 conference that was held in Berlin - available online here.

The U.S. Office of Management and Budget has ordered agencies to convert their network backbones to IPv6 by June 30, 2008.

IPv6 does not have to be fully operational by that date.

Nevertheless, network backbones must be ready to pass IPv6 traffic and support IPv6 addresses. U.S. federal government agencies are expected to verify this new capability through testing activities. Of course this means that procurement must assure that hardware and software are compatible with IPv6.

In fact, a closed, controlled environment in which to acquire IPv6 experience before phasing in interaction with IPv4 seems to be a viable strategy for some Internet Service Providers (ISPs) before tackling the issues of IPv4/IPv6 interoperability. It allows them to begin tackling the hard problem of transparently providing public Internet services over IPv6 in a controlled environment, before the roll-out to end-users. During the 2008 Olympics, the surveillance system at athletic venues will run over IPv6.

Europe and IPv6

At a recent conference in Brussels (May 30, 2008), Commissioner Reding advised businesses in the EU to get ready for changes, setting a target of getting 25 per cent of EU industry, public authorities and households to use IPv6 by 2010, see here:

IPv6: Enabling the Information Society

That might be a bit late considering that IANA may allocate its last IPv4 /8 to an RIR sometime in November or December of 2010. Considering the way we are going right now this might happen even sooner than that:

Predictive model about the exhaustion date for the IANA unallocated pool of IPv4 addresses

If 25% of Europe’s businesses use IPv6 by 2010, how will the internal market cope? Many agencies and businesses will not be able to get new IP addresses. One wonders if these plans by the European Union will save us from going over the brink. Stay tuned.

Tidbit

A successful IPv6 implementation means that users should have no idea whether the services they are using are being delivered over IPv4 or IPv6. While this is great in theory, it also removes the incentive for providers to offer IPv6 faster, since some customers cannot see the benefits they gain (e.g., better security) by using IPv6 supported services.

Technorati , , , , , , , ,

Related Posts:

  1. DNS authentication vulnerable to cache poisening
  2. InfoSec and Twitter - ropes to know #2
  3. ENISA - white paper about USB sticks
  4. DNSSEC - a global effort that experiences difficulties on the road to success
  5. DNSSEC - will the Trust Anchor Repository (TAR) make a difference?

EMail This Post | Print This Post

del.icio.us:IPv6 deployment 10 years after - is there a disaster in the making?  digg:IPv6 deployment 10 years after - is there a disaster in the making?  spurl:IPv6 deployment 10 years after - is there a disaster in the making?  wists:IPv6 deployment 10 years after - is there a disaster in the making?  simpy:IPv6 deployment 10 years after - is there a disaster in the making?  newsvine:IPv6 deployment 10 years after - is there a disaster in the making?  blinklist:IPv6 deployment 10 years after - is there a disaster in the making?  furl:IPv6 deployment 10 years after - is there a disaster in the making?  reddit:IPv6 deployment 10 years after - is there a disaster in the making?  fark:IPv6 deployment 10 years after - is there a disaster in the making?  blogmarks:IPv6 deployment 10 years after - is there a disaster in the making?  Y!:IPv6 deployment 10 years after - is there a disaster in the making?  smarking:IPv6 deployment 10 years after - is there a disaster in the making?  magnolia:IPv6 deployment 10 years after - is there a disaster in the making?  segnalo:IPv6 deployment 10 years after - is there a disaster in the making?

ENISA - white paper about USB sticks

June 25th, 2008
    Twitter can sometimes be wonderful to spread information fast.For instance, last week we provided you with information about an important study by ENISA regarding flash drives.

    We tell you more below.

Here are the three tweets we sent about this study.
InfoSec InfoSec @WhitePapers European Network and Information Security Agency (ENISA) 2008-06-19 report ==> advises companies on 12 threats from #ENISA 1

InfoSec InfoSec from @WhitePapers -ENISA …accidental loss or theft of confidential corporate data on unsecured USB flash drives what can you do #ENISA 2

InfoSec InfoSec @WhitePapers thanks - ENISA link works now - report bottom of page http://tinyurl.com/682dql 19 recommendations on what do #ENISA 3

What it means for you

Stay informed and if you are a Twitter user, follow InfoSec we will bring more things your way such as this one that went out today:

    2008-04-19_142646_normalInfoSec: We not only need to use statistics correctly—we need to use them wisely as well. When doing metrics with security issues or … Nr.1

Care to leave a comment below, how do you see it? Progress, failure, difficulties please share.

Additional resources about DNSSEC - check it out:
InfoSec InfoSec - follow us on Twitter sign up to our alerts about zero-day exploits and newsletters here
NIST Domain Name System Security (NSSEC Project
Internet Governance Project - search for DNSSEC material

W

Technorati , , , , , , , , ,

Related Posts:

  1. EU telecoms market - European Parliament - what it means for InfoSec
  2. DNSSEC - will the Trust Anchor Repository (TAR) make a difference?
  3. freelancers - data back-up saves the day
  4. InfoSec and risk management - any differences between home users and micro enterprises?
  5. risk assessment and management - ENISA - report on visualisation and overview of process models

EMail This Post | Print This Post

del.icio.us:ENISA - white paper about USB sticks  digg:ENISA - white paper about USB sticks  spurl:ENISA - white paper about USB sticks  wists:ENISA - white paper about USB sticks  simpy:ENISA - white paper about USB sticks  newsvine:ENISA - white paper about USB sticks  blinklist:ENISA - white paper about USB sticks  furl:ENISA - white paper about USB sticks  reddit:ENISA - white paper about USB sticks  fark:ENISA - white paper about USB sticks  blogmarks:ENISA - white paper about USB sticks  Y!:ENISA - white paper about USB sticks  smarking:ENISA - white paper about USB sticks  magnolia:ENISA - white paper about USB sticks  segnalo:ENISA - white paper about USB sticks

DNSSEC - a global effort that experiences difficulties on the road to success

June 24th, 2008
    DNSSEC is supposed to be deployed rapidly and help improve security.
    DNSSEC is part of a global effort to deploy new security measures that will help the DNS perform as people expect it in a trustworthy manner
    However, deplyoment is slow and DNSSEC scalability is questioned by some experts and operators.
    Find out - read on we tell you the story.

Recently we discussed:

DNSSEC - will the Trust Anchor Repository (TAR) make a difference?

Already during 2006 we pointed out that DNSSEC (click on this link - choose Login as Guest - click on this linke again and you get access to some definitions) deplyoment was slow even though NISST had offered an extensive deployment guide:

July 2006 - NIST and CyTRAP Labs - recommendations for better implementation of DNSSEC

Domain Name System Security Extensions (DNSSEC) intends to ensure that that Domain Name requests are digitally signed and authenticated. This works as a defence against forged DNS data, a product of various kinds of attacks. For instance, an example is such as DNS cache poisoning. The latter enables an attacker to maybe trick unsuspecting survers into visiting a bogus website that poses as the real website of a bank.

Naturally, there are some politics behind the idea as outlined here:

The Politics of DNSSEC: The Light Begins to Dawn at IETF

The problem of trust can be described in two ways:

1) How do we know that CyTRAP.eu is is managed by the owner of the CyTRAP.eu domain?

2) As well, do we know that the owner of the CyTRAP.eu domain is CyTRAP Labs?

Current standard certificates attempt to resolve the challenge posed by problem A.

Problem B is now left to what some call “extended validation” certificates. In addition, in some scenarios problem B does not exist because the domain name is the identity that one cares about.

To illustrate, if I send e-mail to I may not care about who owns the domain yahoo.dk except that I want the e-mail to reach yahoo.dk and not a bogus site.

A DNSSEC PKI also addresses only problem A. It does so more directly, however, because the ownership of the domain as well as one’s ability to sign DNS records are tightly connected.

One has to find a way to authenticate domain ownership independently whereby one usually relies on domain registration information. Unfortunately, one can subvert this authentication process.

Some risks with a DNSSEC PKI

Usually, the public signing key for a domain is established as part of the registration process. Thereafter it is managed via interaction with the registrar. In this case one can undermine the validity of signed zone data by proceeding by compromising:

1. the domain’s signing key;
2. of an ancestor zone’s signing key;
3. of the domain owner’s registrar account; and
4. of whatever mechanism registrars use to submit public keys to the TLD registries for signing.

The domain signing key can be kept off line, thereby protecting it against some compromising efforts by malicious people. Nevertheless, compromising the signing key is higher, since it may allow a successful attacker to go ahead and issue many certificates.

Point 2 has a similar impact, since if any of the private key of one of the certified authorities (CAs) is being compromised, false certificates can be issued. And while the DNSSEC approach lowers the risk becuase there are fewer keys that must be proteteced, the risk remains.

Point 3 means that since current validation is founded on domain registration data, an attacker compromising the registrar account has a scary impact.

Point 4 might be limited if the Trust Anchor Repository (TAR) approach is rolled out extensively and proofs its scalability and workability in practice.

Interesting Links

Please click on the link, choose option Guest Login - click on this link again and you get access to the extensive material offered in CyTRAP Labs’ glossaries explanations for geeks and other inquiring minds

DNS hierarchy

DNS Spain’s central domain registry - Esnic offline

DNS amplification attacks

DNSSEC - Domain Name System (DNS) Security Extensions - DNSSEC


Care to leave a comment below, how do you see it? Progress, failure, difficulties please share.

Additional resources about DNSSEC - check it out:
CyTRAP Labs’ glossaries explanations for geeks and other inquiring minds - click on this link - choose Login as a Guest - click on this link again and you get access to the edxtensive material offered in
sign up to our alerts about zero-day exploits and newsletters here
NIST Domain Name System Security (NSSEC Project
Internet Governance Project - search for DNSSEC material

Technorati , , , , , , , , ,

Related Posts:

  1. DNS authentication vulnerable to cache poisening
  2. InfoSec and Twitter - ropes to know #2
  3. ENISA - white paper about USB sticks
  4. DNSSEC - will the Trust Anchor Repository (TAR) make a difference?
  5. BBC Click Online fails IT security 101 with story about Facebook

EMail This Post | Print This Post

del.icio.us:DNSSEC - a global effort that experiences difficulties on the road to success  digg:DNSSEC - a global effort that experiences difficulties on the road to success  spurl:DNSSEC - a global effort that experiences difficulties on the road to success  wists:DNSSEC - a global effort that experiences difficulties on the road to success  simpy:DNSSEC - a global effort that experiences difficulties on the road to success  newsvine:DNSSEC - a global effort that experiences difficulties on the road to success  blinklist:DNSSEC - a global effort that experiences difficulties on the road to success  furl:DNSSEC - a global effort that experiences difficulties on the road to success  reddit:DNSSEC - a global effort that experiences difficulties on the road to success  fark:DNSSEC - a global effort that experiences difficulties on the road to success  blogmarks:DNSSEC - a global effort that experiences difficulties on the road to success  Y!:DNSSEC - a global effort that experiences difficulties on the road to success  smarking:DNSSEC - a global effort that experiences difficulties on the road to success  magnolia:DNSSEC - a global effort that experiences difficulties on the road to success  segnalo:DNSSEC - a global effort that experiences difficulties on the road to success

DNSSEC - will the Trust Anchor Repository (TAR) make a difference?

June 20th, 2008
    … In making a large portion of the global Internet shift to the DNS root trust anchor that the US government intends to continue to oversee. This will support secure DNS resolution, however, at what price. Could it mean a further entrenchment of US national security interests in the current DNS structure? If so, how can this be avoided in the interest of the global user community?

Just so we are on the same page, DNSSEC is a public/private key system. This means that the owner of a DNS zone has:

- a private key and
- a public key.

Using the private key to digitally sign a zone will allow anyone with the zone’s public key to verify that data is authentic.

Accordingly, one must be careful with one’s private key since if an attacker can intercept it, the entire zone is compromised.

SCALABILITY

DNSSEC relies on a public/private key system, and that type of system typically does NOT scale well - Internet-wide.

DNSSEC - Domain Name System (DNS) Security Extensions - DNSSEC

Recently, some people have began to discuss what can be done to improve the situation and last year this report was published

VeriSign’s DNS expert, Dr. Phillip Hallam-Baker’s comments on the IETF list - 2007-08-30


The above contribution describes the political implications of signing the root using DNSSEC. The author also called for sharing the signing authority.

The Politics of DNSSEC: The Light Begins to Dawn at IETF

The legitimate opinion that DNSSEC is *just* digital signatures on DNS entries should be supported by more precise procedural guidance on deployment at the root. If it is that easy to apply the technology in a policy-deprived way, I wonder who can tell me how to work it properly.

One response has been coming from the idea of using a Trust Anchor Repository or DNSSEC-TAR for short. A paper was published this month explaining the challenges in a bit more detail:

A Trust Anchor Repository (TAR) refers to the concept of a DNS resource record store that contains secure entry point keys - here called trust anchors - for one or more zones. In turn, the TAR provides the means for a DNS validating resolver to fetch Trust Anchor information for a number of zones in some reliable manner without having to manage this information locally.

The reason for having a TAR in the first place is that since we have deployed DNSSEC in an ad-hoc manner, we need to connect the many what some call ‘islands of trust’ (e.g., Sweden .SE) in the largely unsecured DNS world.

For instance, the .COM, the root zone remains unsigned for various economic and politcal reasons. As well, various actors interested in getting DNSSEC deployed widely have pushed for the TAR option.

Nevertheless, the above report including the post about the report below raise a few questions about the practicability of this approach:

Will a Global TAR make DNSSEC stick?


Care to leave a comment below, how do you see it? Progress, failure, difficulties please share.

Additional resources about DNSSEC - check it out:
InfoSec InfoSec - follow us on Twitter sign up to our alerts about zero-day exploits and newsletters here
NIST Domain Name System Security (NSSEC Project
Internet Governance Project - search for DNSSEC material

What we released on Twiter today - white paper ENISA:

Technorati , , , , , , , , ,

Related Posts:

  1. DNS authentication vulnerable to cache poisening
  2. IPv6 deployment 10 years after - is there a disaster in the making?
  3. ENISA - white paper about USB sticks
  4. DNSSEC - a global effort that experiences difficulties on the road to success
  5. InfoSec and risk management - any differences between home users and micro enterprises?

EMail This Post | Print This Post

del.icio.us:DNSSEC - will the Trust Anchor Repository (TAR) make a difference?  digg:DNSSEC - will the Trust Anchor Repository (TAR) make a difference?  spurl:DNSSEC - will the Trust Anchor Repository (TAR) make a difference?  wists:DNSSEC - will the Trust Anchor Repository (TAR) make a difference?  simpy:DNSSEC - will the Trust Anchor Repository (TAR) make a difference?  newsvine:DNSSEC - will the Trust Anchor Repository (TAR) make a difference?  blinklist:DNSSEC - will the Trust Anchor Repository (TAR) make a difference?  furl:DNSSEC - will the Trust Anchor Repository (TAR) make a difference?  reddit:DNSSEC - will the Trust Anchor Repository (TAR) make a difference?  fark:DNSSEC - will the Trust Anchor Repository (TAR) make a difference?