> -----Original Message----- > From: dnsop-boun...@ietf.org [mailto:dnsop-boun...@ietf.org] On Behalf > Of Olaf Kolkman > Sent: Thursday, January 21, 2010 3:42 AM > To: dnsop WG > Subject: Re: [DNSOP] HSMs was Re: I-D Action:draft-ietf-dnsop- > rfc4641bis-01.txt > > > 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. >
I agree, but I am a strong believer in market driven decisions so, yes, encouraging people to make their own decisions is my preference too. However I will say that even using a $5 HSM (in the form of a smartcard) forces certain good IT security practices. The guys that developed this industry have really though through process. May be out of scope but: Trust in the KSK must still be earned through various mechanisms like publicly documented processes, 3rd party auditing, external witnesses, key ceremonies. > > > > 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). > Agreed. Read or in the case of an infrequently used KSK (low number of ZSK rolls) - make use of the key. > 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. > Agree. > Below looks good. Take my suggestion or leave it. It is only a minor point and might be implemented on a secured o/s as well. > > > 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 , or can sign with, > 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 _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
