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

[Miek Gieben <miekg@atoom.net>]

[On 25 Aug, @23:51, Michael wrote in "Re: draft-kolkman-dnssec-opera ..."]
>   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 :-)

Well, we already have the "singing zone rollover" :-)

>   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.

yes, but I'm not sure is something of this wording should be put in, although I
like the idea of "garbage keys".

> 
> 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.

the idea is to go from key10 to key11, both ZSKs. The thing is that caches
which do have key 10 but not any data can stil get data from the zone which
is signed with key 10.

after key 10 is timed out, the cache will pick up the keyset with keys
10 and 11. So now key 11 is in play. 

> Also, I think that when you remove KEY10, that you wind up at SOA#2 as well.

When this has happened key 10 can be discarded from the zonefile. So this
is what actually happens. Or are you saying, to go from SOA#0 to SOA#2 simple
discard key 10? But as I tried to explain above will not work. 

> >   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.

it's all about old data which is signed with the old key. We wanted to 
specify some sort of transition from key 10 to key 11.

> 
> >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.

Maybe adding something like this would help?:

If the old key gets compromised the new key is already distributed in the DNS. A
zone administrator is than able to quickly switch to the new key and remove the
compromised key from the zone.

>   The major advantage is that it costs only 1 DNSKEY record, vs
> O(size-of-zone) DNSSIG records.

yes, true, took me a moment to parse this, but you mean that you don't need
to have a double signed zone (which could be really big). 

> >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.

a seperate one? Or be just more verbose in this one?

>   What does it mean to securely notify the parent -- this is a human
> protocol, not necessarily just a network one.

I have no idea what is means, it probably means don't use the DNS.... :)

thanks for your comments,

grtz Miek
#----------------------------------------------------------------------
# To unsubscribe, send a message to <dnsop-request@cafax.se>.