[I deleted some of the suggestions. I agree with the ones that are gone] [On 08 Jun, @12:42, Olaf M. Kolkman wrote in "Re: comments on dnsop draft ..."] > > Can it be discontinuous? I.e., only on Tuesdays and Thursdays in May? > > I do not know what the "formal definition" is. > > But I take it to be that even when signatures made with this key > appear with a sig-inception Tuesday 00:00 and sig-expiration Tuesday > 23:59 and signatures with sig-inception Thursday 00:00 and > sig-expiration Thursday 23:59, the Key effectivitiy period would be > Tuesday 00:00 to Thursday 23:49. > > If there is a better way of phrasing this definition as appears now I > will need text.
We already say the doc is not a BCP, if this (or other new stuff)
turns out to be usefull we can always write a /real/ BCP when there is
actual experience with DNSSEC.
> >> # o "Maximum/Minimum Zone TTL"
> > # The maximum or minimum value of the TTLs from the complete set
> > # of RRs in a zone.
> >
> > This has nothing to do with the last number in the SOA RR, right? Right?
> >
>
> Correct you take all the TTL values in the zone and take the minimum
> and the maximum of that set. Is the text that is there now ambiguous?
I think what Ed means is that we do not say anything about the min TTL
specified in the SOA. This slightly changed the def. of Minimum zone
TTL which would become: MIN(min zone TTL, SOA min TTL).
I could be wrong though.
> ----------------------------------------------------------------------
>
> >
> > #3.1 Zone and Key Signing Keys
> > #
> > # The DNSSEC validation protocol does not distinguish between DNSKEYs.
> > # All DNSKEYs can be used during the validation. In practice operators
> >
> > Is that true? Is that because DNSKEYs must have the zone key bit set?
> > I forget how we resolved TKEY stuff the type code roll.
>
> What about:
>
> The DNSSEC validation protocol does not distinguish between DNSKEYs
> with the SEP flag set or cleared. Both DNSKEYs can be used during the
> validation. ...
Yes, better.
> ----------------------------------------------------------------------
>
> >
> > #3.6 Private Key Storage
> > #
> > # It is recommended that, where possible, zone private keys and the
> > # zone file master copy 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,
> >
> > The problem with this recommendation is that a lot of the upper (sensitive)
> > zones have a "response time" pressure that pushes them to use dynamic
> > update.
> > Currently, dynamic update (tools) don't allow the inclusion of signatures,
> > this might have to be fixed. Left in limbo is the recommendation to
> > keep keys entirely off-line.
>
> I understand your observation but I find it difficult to turn this
> into document text. Do you have a suggestion?
I have no suggestion... leave it just as is... or relax the
recommendation a bit?
> ----------------------------------------------------------------------
>
> > # DNSKEY 10 is used to sign all the data of the zone, the zone-
> > # signing key.
> > # pre-roll: DNSKEY 11 is introduced into the key set. Note that no
> > # signatures are generated with this key yet, but this does not
> > # secure against brute force attacks on the public key. The minimum
> > # duration of this pre-roll phase is the time it takes for the data
> > # to propagate to the authoritative servers plus TTL value of the
> > # key set. This equates to two times the Maximum Zone TTL.
> >
> > Aren't all keys required to sign the key set?
>
> Only the keys a DS record points to.
...and then only one key per algorithm per DS set. (IIRC)
> > # time it takes for this zone to propagate to all authoritative
> > # servers plus the Maximum Zone TTL value of any of the data in the
> > # previous version of the zone.
> >
> > Not the maximum TTL, but the TTL of the key set.
>
> You want data that is still cached and signed with signature 10 (as in
> version SOA1 of the key) to expire before you remove key10 from
> SOA2. That timing is set by the TTL of the zone data not the DNSKEY.
>
> > (This could be more
> > complicated as there would have been a TTL of one week yesterday, then
> > shortened to an hour today.)
>
> Agreed... but I think mentioning this would complicate rather than
> clarify.
>
> You could actually also mention that one could take the 'maximum'
> SIGNATURE expiration time of the data at the roll to determine when
> the post-roll should occur. Caches should throw out the data when that
> expiration time occurred. Since that provides you with an absolute time
> to do the rollover that may actually be a good recommendation to give
> too. (also see 4035 section 4.3 "The resolver SHOULD discard the
> entire atomic entry when any of the RRs contained in it expire").
>
> Any opinion from the working group?
I like that. ...if the zone owner wants to be "even more sure" he could
wait until the signatures experiration date has come. Or something
like that.
> > #4.2.1.3 Pros and Cons of the Schemes
> >
> > # Pre-publish-key set rollover: This rollover does not involve signing
> > # the zone data twice. Instead, before the actual rollover, the new
> > # key is published in the key set and thus available for
> > # cryptanalysis attacks. A small disadvantage is that this process
> > # requires four steps. Also the pre-publish scheme involves more
> > # parental work when used for KSK rollovers as explained in
> > # Section 4.2.
> >
> > I don't think that cryptanalysis is possible without a signature to go
> > along with the public key, however, dictionary attacks are possible.
> > (As in "where have I seen this public key before and did I break it?")
>
> The cryptanalysis attack was mentioned in 4.2.1.3, should we remove
> that line?
>
> Your editor needs guidance.
As far as my understanding goes, the public key (in case of RSA) is
just a BIG number, if you prime factor that number, you have the
private key. So publishing the pub key allows cryptoanalysis.
> ----------------------------------------------------------------------
>
> > # The scenario above puts the responsibility for maintaining a valid
> > # chain of trust with the child. It also is based on the premises that
> > # the parent only has one DS RR (per algorithm) per zone. An
> > # alternative mechanism has been considered. Using an established
> > # trust relation, the interaction can be performed in-band, and the
> > # removal of the keys by the child can possibly be signaled by the
> > # parent. In this mechanism there are periods where there are two DS
> > # RRs at the parent. Since at the moment of writing the protocol for
> > # this interaction has not been developed further discussion is out of
> > # scope for this document.
> >
> > Perhaps you should also show the DS set at the parent in the example.
> > Later you have one, but it is for the 2 DS at the parent option.
>
> Ack, proposed diagram:
>
> Parent:
> normal between "roll"
> and "after"
> SOA0 SOA3
> RRSIGpar(SOA0) RRSIGpar(SOA3)
> DS1 DS2
> RRSIGpar(DS) RRSIGpar(DS)
DS1 DS2
> ----------------------------------------------------------------------
> I do get your point though, you would not like to see this document
> being stuffed in your face if you do not meet these
> recommendations. Maybe we can address this in the introduction of the
> text by adding a line to the first paragraph of the Introduction:
>
>
> During workshops and early operational deployment tests, operators
> and system administrators gained experience about operating the DNS
> with security extensions (DNSSEC). This document translates these
> experiences into a set of practices for zone administrators. At the
> time of writing, there exists very little experience with DNSSEC in
> production environments; this document should therefore explicitly
> + not be seen as representing 'Best Current Practices'. The intention of
> + this document is to provide guidance, it should not be used to argue
> + that operators violate best practices when they choose not to follow
> + recommendations herein.
I like that change, see the first lines of this email.
--
grtz,
- Miek
http://www.miek.nl http://www.nlnetlabs.nl
PGP Key ID: 0xB18453A1
fingerprint: 002B B079 0DDA 7D44 2B5C CAB0 C3B7 F943 B184 53A1
signature.asc
Description: Digital signature
