Re: [DNSOP] HSMs was Re: I-D Action:draft-ietf-dnsop-rfc4641bis-01.txt

[Olaf Kolkman <[e-mail]>]

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 <[e-mail]>
	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 <[e-mail]>


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 <[e-mail]>
	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 <[e-mail]>

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