In trying to get a reasonable version 2 out of the door before Anaheim I am trying to identify and where possibly close open issues.
As a reminder: http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/ has the open issues listed and a per issue highlight of their history. This thread, about the use of HSMs, is captured in http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/HSMs the content of that page is replicated below. I believe I captured the gist of the discussion in a modified version of paragraph 3.6 (see below). The first two paragraphs are not modified, the text starting with "The ideal situation" has been. I welcome editorial comments off-list. If the chair believes the current text captures consensus I will move this issue to the closed issues list. --Olaf $Id: cryptography_flawed 14 2009-02-09 18:54:12Z olaf $ 20100121 The use of HSMs Shane Kerr/Ed Lewis Added: 21 jan 2010 http://www.ietf.org/mail-archive/web/dnsop/current/msg07190.html and http://www.ietf.org/mail-archive/web/dnsop/current/msg07193.html The recommendation to use a HSM is far to strong. Arguments of fate sharing and operational overhead are being made on the list. Discussion: From: Shane Kerr <sh...@ca.afilias.info> Subject: Re: [DNSOP] I-D Action:draft-ietf-dnsop-rfc4641bis-01.txt Date: April 21, 2009 1:03:58 PM GMT+02:00 Cc: dnsop WG <dnsop@ietf.org> I believe the key of the thread is captured in the following quotes: Stephane Bortzmeyer wrote: > > But the risk for the key is not only people modifying it, it is simply > people *reading* it (a concern which also exists for the database but > is much less important). > > I have no practical experience with HSMs but, in my mind, the > interesting thing is that they guarantee noone will read the key > without an authorization (that's quite unlike the database where you > certainly prefer a few unauthorized looks to a complete loss). This is the key point IMHO. AIUI, the attack vector that HSM are designed to protect is that someone makes a copy of your key signing material without you knowing about it. Once they do that, they can spoof replies until such time as you roll your key. If an unauthorized person modifies the contents of the database backing your zone, you may or may not know about it, but an observant customer will at least notice that the data has changed. So the two are not totally equivalent. Having said that, I agree that HSM hysteria is a bit overblown, and that the actual DNSSEC signing is very, very unlikely to be the weakest link in DNS security in any organization. Resolution: Following the suggestion from: From: Peter Koch <p...@denic.de> Subject: Re: [DNSOP] HSMs was Re: I-D Action:draft-ietf-dnsop-rfc4641bis-01.txt Date: April 27, 2009 1:19:45 PM GMT+02:00 To: IETF DNSOP WG <dnsop@ietf.org> I rewrote the text to highlight the economic tradeoff, the relevant part of section 3.6 is copied below. 3.6. Private Key Storage It is recommended that, where possible, zone private keys and the zone file master copy that is to be signed be kept and used in off- line, non-network-connected, physically secure machines only. Periodically, an application can be run to add authentication to a zone by adding RRSIG and NSEC RRs. Then the augmented file can be transferred. When relying on dynamic update to manage a signed zone [11], be aware that at least one private key of the zone will have to reside on the master server. This key is only as secure as the amount of exposure the server receives to unknown clients and the security of the host. Although not mandatory, one could administer the DNS in the following way. The master that processes the dynamic updates is unavailable from generic hosts on the Internet, it is not listed in the NS RRSet, although its name appears in the SOA RRs MNAME field. The nameservers in the NS RRSet are able to receive zone updates through NOTIFY, IXFR, AXFR, or an out-of-band distribution mechanism. This approach is known as the "hidden master" setup. The ideal situation is to have a one-way information flow to the network to avoid the possibility of tampering from the network. Keeping the zone master file on-line on the network and simply cycling it through an off-line signer does not do this. The on-line version could still be tampered with if the host it resides on is compromised. For maximum security, the master copy of the zone file should be off-net and should not be updated based on an unsecured network mediated communication. The ideal situation may not be achievable because of economic tradeoffs between risks and costs. For instance, keeping a zone file off-line is not practical and will increase the costs of operating a DNS zone. So in practice the machines on which zone files are maintained will be connected to a network. Operators are advised to take security measures to shield unauthorized access to the master copy in order to prevent modification of DNS data before its signed. Similarly the choice for storing a private key in a Cryptographic Hardware Security Module (HSM) will be influenced by tradeoff a tradeoff between various concerns: o The risks that an unauthorized person has unnoticed read-access to the private key o The remaining window of opportunity for the attacker. o The economic impact of the possible attacks (for a TLD that impact will in most cases be higher than for an individual users). o The costs of rolling the (compromised) keys: whereby the costs of roling a ZSK is lowest and the costs of rolling a KSK that is in wide use as a trust anchor is highest o The costs of buying and maintaining an HSM. For dynamically updated secured zones [11], both the master copy and the private key that is used to update signatures on updated RRs will need to be on-line. ________________________________________________________ Olaf M. Kolkman NLnet Labs Science Park 140, http://www.nlnetlabs.nl/ 1098 XG Amsterdam
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop