. IN DS 19036 8 2 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5

The full DNSKEY representation of the public key will be published shortly after the second ceremony, which is scheduled for July 12, 2010. At this ceremony, the generated key will be installed at the West Coast Key Management Facility in El Segundo, CA. The generated KSK is to be considered provisional until it has been safely installed in both facilities.

Kirei was represented at the key generation ceremony by Jakob Schlyter and Fredrik Ljunggren, both holding the roles as External Witnesses (EW).

Fredrik and Jakob attests that the key ceremony was executed according to the key ceremony script. This PGP signature may be used to verify the DS record’s authenticity.

What is Delegation Signer?

The Delegation Signer (DS) resource record contains a cryptographic hash (“fingerprint”) of the child zone’s Key Signing Key (KSK). When signing this record, a chain of trust is established between the parent and the child zone. By looking up and validating a signed DS record at the parent, a validating resolver can follow the chain of trust from the parent to the child, and continue any secure lookup from the child onward.

Validating Resolvers

As the root zone is signed using the RSA/SHA-256 algorithm, a resolver validating signed responses from the root zone must be able to understand this algorithm. The following most common resolvers are known to support this algorithm in later versions:

• ISC BIND (version 9.6.2 or later)
• Unbound (version 1.4.0 or later)
• Nominum Vantio

But what happens if a resolver that does not implement RSA/SHA-256 tries to validate the signed root? The DNSSEC specification states that keys and signatures by an unsupported algorithm shall be ignored. This implies that signatures made with such an algorithm will simply be ignored by the resolver, and the root zone will be considered unsigned.

Currently configured trust anchors for a TLD with DNSSEC will still function with a signed root, but once a trust anchor for the root is configured – and the TLD DS records are published – they become redundant and may be removed. One could even argue that they should be removed to prevent them from becoming stale when the TLD updates their current KSK.

Expected Deployment Rate

We expect that most of the TLDs that has deployed DNSSEC to submit their DS records to IANA within the near future. How fast the signed root is actually used by validating resolvers is still unknown, but based on feedback from large Internet Service Providers, we anticipate that the trust anchor for the root will be added gradually as updated versions of validating resolvers are being deployed.

Implications on Network Infrastructure

At the time of writing, all the root servers are serving the Deliberately Unvalidatable Root Zone (DURZ). This effectively means that all responses from the root servers already contains the keys and signatures required for DNSSEC validation, but as the keys are blinded the response cannot be validated. When the zone is unblinded (i.e., the real keys are visible) and the trusted anchor is published, the response packet sizes from the root servers does not change. Any harmful effect that would have been a result of the increase in packet size, would have been seen gradually from the point where the DURZ was incrementally rolled out, beginning January, and finally completed in May.

Conclusion

We recommend TLD managers with a signed zone to submit their DS records to IANA, and that they recommend their stakeholders (e.g., Internet Service Providers and Enterprises that validate the TLD responses) to start migration towards using the root trust anchor instead of the TLD trust anchor.

Resolver operators should start evaluating their environment by testing validation using the root trust anchor, reassuring that their resolvers and communication services works as expected with the signed root.

For the last 10 months, we’ve been working on a number of important issues, including:

• Designing the overall system- and security architecture of the signer and key management system based on the requirements from U.S. Department of Commerce, National Telecommunications and Information Administration (DoC/NTIA).
• Drafting the DNSSEC Practice Statement (DPS) for the KSK and ZSK holder (i.e. ICANN and VeriSign, respectively), and publishing of a DPS framework for other registries to benefit from
• Communicating the progress and gather feedback from the community
• Establishing of Trust anchor publication mechanisms
• Increasing transparency and community trust by introduction of the Trusted Community Representatives into the signing process
• Defining physical security controls and requirements for the KSK operators facilities
• Preparation to undergo a SysTrust examination of the Root Zone KSK Operator function
• Work out key ceremonies, testing of the scripts and carry out rehearsals
• Develop deployment plans and interface with the root server operators
• Perform testing of resolver implementations

Kirei is very proud to be part of this landmark project and believe that a signed root is an important step for improving the security of the DNS infrastructure.

For more information about DNSSEC for the Root Zone, please visit the website at http://www.root-dnssec.org/.

In deployment scenarios where you require dynamic updates, or want to use a HSM which requires multiple threads for decent signing performance, OpenDNSSEC version 1.x come short. There are plans for how to address this in version 2.x, but fortunately there are other options until then. When designing OpenDNSSEC I’ve always tried to keep the different modules clearly separated and the interface between them well defined. This is something that recently paid off, when I started out replacing the OpenDNSSEC signer engine with ISC BIND.

By using the OpenDNSSEC key manager, the KASP Enforcer, for managing signing keys and cryptographic parameters and then convert this information into a format that ISC BIND can read, one can replace the original signer engine with BIND. This works for both offline signing (i.e. when the zone is first signed, then loaded into a name server) and for online signing (i.e.when the zone is signed while BIND is running).

My tests with BIND 9.7.0rc2 looks very promising and it looks like this could be a viable alternative for those who are want to sign their dynamically updated zone, but doesn’t want to bother with manual key management.

• Press release

The most common divergence from 3263 seems to be that NAPTR records are not supported, but there are also implementations that do not process multiple SRV records correctly and some that even drops all but one of the SRV records they can find. Even SIP stacks that fully supports 3263 may have problems with redundancy, as the timers used for retransmitting requests in case of timeouts are rather large for unreliable transport protocols like UDP. In such cases it could take a long time (up to 32 seconds) before a second transport and/or destination is tried.

When Kirei was tasked to design a distributed and geographically redundant SIP service for the Swedish emergency services (112), we started to look at what alternatives might be available to provide redundancy for all those broken SIP stacks. When something is on fire or someone is injured, it is usually not the time and place to start arguing about non-compliant SIP implementations –  it’s better to get the work done and connect the call while providing as much redundancy as possible.

What about anycast?

Based on our experience from the world of DNS, we started to look at BGP anycast to provide a redundant SIP service. BGP anycast works by announcing the same network prefix (IP address) at multiple locations and letting the BGP routing system choose the best (i.e., topologically closest) path from the client to the server. As this works very well with DNS, we though it might work for SIP as well.

One large difference between DNS and SIP, when looking at how the protocols are used, is that the length of sessions are very different. A DNS query/response usually takes less than 50 milliseconds, whereas the average emergency call to the Swedish emergency services is about 1-2 minutes and an extended call be last for more than 30 minutes. Given that BGP changes topology from time to time, and that a change in topology might re-route an already existing call from one SIP server to another, we might end up disconnecting established calls as an established call cannot be transferred between servers. Something had to be done to resolve this, if we want to use BGP anycast with SIP.

Even if we cannot use anycast for routing the entire SIP session, we should be able to use it to route the initial signaling. This would not help already established sessions, but it would create better redundancy for session setup from broken SIP stacks. It would also give us faster session setup for well-behaved SIP stacks, since they don’t have to try multiple destinations – just one anycasted destination. A set of unicasted fallback addresses are probably wise to have, but they would only be used in case of failure or problem with the anycasted servers.

SIP Anycast!

To use SIP anycast for the initial signaling only, we need to move the session from anycast to unicast as soon as possible. This means that one must configure the destination SIP user agent so that the contact address used in the reply to the initial INVITE is a unicast address. Also, if there are any proxies in the signaling path, one must also make sure that no SIP record routing includes the anycast address.

In the system we’re looking at currently we have a session border controller (SBC) acting as a back-to-back user agent (B2BUA) between a SIP user agent on some external network and a media gateway behind the SBC. In this case we need to configure the SBC with dual addresses – one anycast address shared between all SBC:s and one unique unicast address per SBC. We also need to configure the SBC so that the contact address returned to the SIP user agent on the external network is always the unicast address, even if that user agent contacted the SBC using its anycast address. Record routing isn’t used in this case, since the SBC looks like a SIP user agent and not a proxy.

A complete session would look something like this:

This means that any subsequent signaling after session setup will be sent to the unicast address and the sessions therefore independent of changes in BGP topology where the anycast address, from the clients point of view, moves from one SIP server to another.

Time will tell if this will help providing redundancy for less featured and broken SIP stacks, but at this point we believe this is our best option.

In the spirit of this, Directive 1999/93/EC of the European Parliament was produced to co-ordinate the legal status of electronic signatures across the European Union (EU). The Directive defines a framework for electronic signatures within the European Community. The extraordinary thing about this Directive is that it identifies the methods, instead of the results, which is a contradiction in the very definition of an EU directive. In the ever-changing world of computing, one can expect the methods and requirements for electronic signing and authentication to change almost constantly.

This Directive, which is mandatory for all of the Member States, has found its way into national legislation. This was the easy part. To actually issue and use these electronic identities has proved to be much harder. What is often overlooked is that the realworld need for electronic signatures is actually marginal. What really matters is to identify people in a safe manner. With identification we can perform the vast majority of all day-to-day business, including the offering and acceptance of contracts enforceable in a court of law – without the need for any legislation of the methods used.

When we write our final will, take out a loan or sell our house, we can still use the old fashioned way of handwriting and witnessing. With basic risk analysis, it is evident that the requirements for everyday identification are very different from those for producing advanced electronic signatures. Unfortunately, our efforts so far have been focused on designing a universal solution to meet the most demanding requirements. The problem we were trying to solve initially stalled because we were aiming too high. The goal of reliable identification has been marginalised in favour of something we do not really need.

The standards

The basic idea behind the X.509 PKI is to have cryptographically sound security mechanisms for authentication, signing and non-repudiation. Every individual entity in the PKI has its own key pairs (public-private), often several pairs for the different operations. For protection of the private keys, there must be ‘secure signature-creation devices’. This usually implies having smart cards and using secure smart card readers. The methods employed are those typically used within a financial institution, the military or even parts of a large private enterprise – where there is very strict control of the complete technical environment coupled with proper education of the end-users and support. However, these methods do not work in our open Internet-based world, where security starts and ends with the endusers – the citizens and their PCs. The resulting complexity leads to services being less attractive to use. Traditional pen and paper is easier and less obstructive than the technology designed to facilitate that very service.

A national perspective

The result of the legislation is that it has actually prevented the adoption of electronic identification instead of promoting it. The failure is evident by looking at what has been achieved so far. After 10 years of intense bureaucracy and tens of millions of Euros, we have still not been able to implement a national eID scheme in Sweden. Even though there is a Swedish national ID card (NIDEL) capable of holding an electronic ID, it is empty. The card is basically a brick! Essentially we are at the same point now as we were a decade ago. It is clear that something is fundamentally wrong.

In the end, it is always a question of resources. What prevents the national eID scheme from being deployed on a large scale is the unreasonably high cost per operation, in relation to the benefit. The high costs preventing the adoption of the solution stem from:

• the technical complexity which calls for extensive end-user education and rollout of special purpose end-user hardware and software
• substantial help desk costs to support end-users
• the tailoring of solutions for the single purpose of citizen-to-authority communication; relatively few operations will ever be made per eID
• the huge legal liabilities associated with the issuing of identities
• the high integration costs for the relying parties
• poor user experience – the security mechanisms are inherently insecure as people make mistakes – cases of fraud will have to be handled appropriately.

A provider of electronic identities will have to transfer all these costs, via the relying parties, to the end-users. The scheme will only be viable if these costs can be recovered from end-users. In the current proposal for a national eID scheme in Sweden the state would perform a co-ordinating function for the authorities by purchasing the services of issuing identities from private corporations. This service is unlikely to be cheap, which would prevent any commercial application. End-users would have to pay for it with higher taxes. In reality, therefore, the practical use of electronic identification will only happen when the tools for supporting it are significantly simplified.

Privacy concerns

Technical complexity is not the only concern with PKI. Even if every single European citizen had his or her own national eID with three individual key pairs, an individual ‘secure signature-creation device’ and the education to handle it, it would be unacceptable to use it for any other purpose than in communicating with financial institutions and authorities, because of the privacy concerns it raises.

The X.509 certificate carries all the information associated with the identity, and is easily copied into a database in every imaginable situation. It can be looked up in directories, it can be eavesdropped or cross-referenced with other databases, and there is no way of selectively hiding information. Engineers have been trying to compensate for these concerns with complicated cryptographic schemes built into the smart cards. But the functions do not fulfil their purpose; if it is not evident for the card-holders how or even if their identities are protected, then the function is not useful. The holders of identity cards must be in control of the mechanisms that allow them to use the identification service in a safe manner. It must be evident what actually happens, what information is revealed, to whom and when. The user must be given a chance to cancel the operation before the information is revealed and, in the case of accepting an agreement or signing, to see what is actually going to be signed or agreed. These safety controls should be fulfilled by any national eID scheme.

The way forward

Fundamentally, there needs to be a costbenefit analysis of eID, where the costs in complexity are compared with the risks we are trying to mitigate, i.e., the benefits of a security mechanism. In some sectors, strong cryptography, legislation and cryptographic signatures are necessary – where there are substantial risks involved that justify the use of this technology, and where the inertia and stability of a strictly controlled environment are advantages rather than deficiencies, such as in the financial sector.

However, in almost every other case, the risks do not in any way justify the costs of the qualified certificates. Given this, it would be better to design an entry-level solution for eID, which is:

• cheaper and suitable for all applications – authorities, commercial and non-profit
• easier to use and deploy
• and allows for protection of our personal data.

A good solution is to build upon the concept of identity providers – a broker of identity information which performs the identification process and relays relevant information to the relying parties. Upon successful identification in a particular context, the identity provider would issue electronic tickets for this specific context, assuring the identity of the holder, and would attach the relevant identity information. There is a unique identifier for each relationship, which cannot be crossreferenced with other relationships.

The identity provider would also be able to collect meta-information related to the subjects, such as if they are the authorised signatory for an organisation, have a medical license or are a student, or even to include a private name space for the corporation where they are currently employed. This system would allow for much greater flexibility than having separate identities for each context, as proposed by others.

Before a successful identification the user would be presented with the information agreed to be released to the relying party. At this point the user would have the option to accept or cancel, which makes it easy to fulfil legislative requirements such as Directive 95/46/EC on the protection of personal data.

Several independent identity providers can interoperate within a federation. The federation would establish policies under which identity providers should issue and handle identities. Identities within the federation would be interoperable and only the data exchange protocols would have to be co-ordinated. Such protocol already exists, e.g., the Security Assertion Markup Language (SAML) version 2, as standardised by the Organisation for the Advancement of Structured Information Standards (OASIS).

The means for users to identify themselves could vary. Different situations may require different assurance levels, which would allow users to select the technical solution that best fits their needs in every situation. National eIDs, in the rare cases they actually exist, could be used as one. Arbitrary security tokens could also be used as long as they comply with the policy for that assurance level within the federation.

This would enable all existing and future technical solutions for identifying ourselves to be deployed, to protect an individual’s identity information and preserve anonymity, while also enforcing legal responsibility for actions taken online. Both the qualified certificates and other means for identification would also be held in the same infrastructure.

Accepting agreements and contracts could be achieved by having a trusted third party, an electronic variant of notarius publicus, signing the document while asserting both parties have accepted the content. The environment provided by the trusted third party would be harder to manipulate than the end-user’s PC, and would also provide a better user experience by presenting the exact contents of the agreement.

Start simple

We should try to start simple and solve the most urgent problems first. Solutions must be designed to meet demands from all sectors and to provide the usability and protection of personal data as needed for everyday use. Basic cost-benefit analysis can identify which technical solutions are feasible and justified. However, it is important to understand that the concept of identity providers is not mutually exclusive with the use of national eID, which would enable us to move forward in a rational way, fulfilling all the requirements for a sound and reliable solution for identification. The certificates in a national eID scheme may be used just as any other reliable means of identification to the identity provider. End-users’ methods for identification are totally transparent to the relying parties, and are therefore irrelevant. The identity provider will supply the proper protection of personal data. Let’s move forward in this rational way.

The idea in this article originally appeared in the ENISA Quarterly Review, 3rd Quarter 2008. www.enisa.europa.eu/eq

The security technique of M-of-N aims to obstruct or prevent individual officials from disregarding stipulated security practices. The technical means of control in using M-of-N are based on the regulation of access to a physically protected signing unit (a security module, HSM), including key storage and manipulation protection, which requires M-of-N officials to be present during key operations. This access control does not normally mean that the key material itself is divided between the officials, it only relates to the security module access.

Even if it is cryptographically possible to share a data set through M-of-N, it is highly impractical, and furthermore makes it possible for a group of collaborating officials to compromise the key material. Division of the key material weakens the confidentiality protection of the private keys, and therefore counteracts the objective to strengthen the trust in them.

Access regulation through M-of-N control is also no appropriate way of delegating (part of) the operational responsibility to other organizations. The operating environment will become too vulnerable, and may suffer serious consequences if the required individuals can’t or won’t turn up, (for whatever political or practical reasons), on short notice to perform the cryptographic operations needed.

In all respects the objective should be a reduction of complexity in root zone administration and management. Organizational, political and technical stability should be the primary objective, and then the trust in it will follow suit.


A common misunderstanding is that the trust in the root key is superior to the confidence in ICANN. In reality, it is the other way around. The trusting parties can choose for themselves who they have confidence in, by pointing their name servers at the ICANN root and configure the trust anchor published by ICANN. The question of who is controlling and performing the signing operations is unimportant as long as the content of the zone is being controlled. The implementation of M-of-N across several organizations will instead increase the risk of introducing uncertainties that in the long run can counteract the objective of preventing a division of the Internet namespace. The trust in the root is also not dependent upon being able to transfer the key material to another organization, since the new organization will still have to use new keys and prove itself reliable in the same way. Having earned people’s trust does not equal to controlling the key material.

We consider there to be no reason for complicating the management of the root zone through involving several different parties in necessary key operations. M-of-N control should only be used within the managing body as a way of strengthening the confidence in the integrity of the root zone.

At the end of the day, trust is a soft value that does not depend solely on this technical means of control.