Re: draft-kolkman-dnssec-operational-practices-00.txt

[Michael Richardson <mcr@sandelman.ottawa.on.ca>]

-----BEGIN PGP SIGNED MESSAGE-----


>>>>> "Olaf" == Olaf M Kolkman <olaf@ripe.net> writes:
    Olaf> draft-kolkman-dnssec-operational-practices-00.txt is now in the I-D
    Olaf> repository.

    Olaf> Does the working group want to accept this document as a working
    Olaf> group item?

  Yes, I think it should.

  I still would like to introduce some kind of term, like "dieletric constant
of DNSSEC" or some such to explain "propogation" of SIGs through caches :-)

  Some initial comments/thoughts:

>   o  "Key publication period"
>
>         The period for which the public part of the key is published in
>         the DNS.  The public part of the key can be published in the
>         DNS while it has not yet been used to sign data As soon as a
>         public key is published a brute force attack can be attempted
>         to recover the private key.  Publishing the public key in
>         advance (and not signing any data with it) does not guard
>         against this attack.

  One interesting "defense" against this would be to publish multiple
keys. Some of them could be total garbage. Since there is no signed data,
you'd have to brute force all them to figure out which one signed the data.

  But, in any case, if you believe that the key can be brute forced during
any low multiple of the "key publication period", then the period is probably
too short, or the keys too small.

re: 3.3.1.1 A double signature zone-signing key rollover

I don't think that at SOA#1, you have to resign with key 10. Maybe you
  have to sign the DNSKEY11, but that's it.
Also, I think that when you remove KEY10, that you wind up at SOA#2 as well.

>   Note that in this example we assumed that the zone did not get
>   modified during the rollover.  New data can be introduced in the zone
>   as long as it is signed with both keys.

  Is it strictly necessary to sign with a new key?

  At SOA#1, the trusted path is via KEY11. Since the new record, and
the DNSSIG record on the new data can't have been cached yet (since they
don't exist yet!), so signing with the old key is kind of irrelevant, I
think.

>3.3.1.2 Pre-publish keyset rollover
>
>   This section shows how to perform a ZSK key without the need to sign
>   all the data in ones zone twice.  We recommend this method because it
>   has certain advantages in the case of key compromises.  A small
>   "HOWTO" for this kind of rollover can be found in Appendix B.

  It would be good to explain this.
  The major advantage is that it costs only 1 DNSKEY record, vs
O(size-of-zone) DNSSIG records.

>4.1 KSK compromise
>
>   When the KSK has been compromised the parent must be notified as soon
>   as possible and in a secure means.  The keyset of the zone SHOULD

  I believe that we should have a BCP for this part.
  What does it mean to securely notify the parent -- this is a human
protocol, not necessarily just a network one.

]      Out and about in Ottawa.    hmmm... beer.                |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian/notebook using, kernel hacking, security guy");  [

  
  




-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Finger me for keys - custom hacks make this fully PGP2 compat

iQCVAwUBP0qE04qHRg3pndX9AQGEtQQA8Ko/3w6HpVWWB8P5yapGNlqvf3Pj1zqD
tUgZHU7NipO3G/cFFSYPwXswcHUPhljB4U6Txusx/ar5OrPXH0eawOSmAW85gO9r
qz3v7082WPxvM/o4QA4hpX9daYhTIJKg4yHBuEoDxeLZ3ZHJu5wvU4CIFt02IWmR
UlcqAf2VNkM=
=6g4n
-----END PGP SIGNATURE-----
#----------------------------------------------------------------------
# To unsubscribe, send a message to <dnsop-request@cafax.se>.