Fredrik,
On 19/06/2011 12:22 PM, Fredrik Ljunggren wrote:
On 2011-06-17, at 13:31, Olafur Gudmundsson wrote:
Few nits and questions below:
a) DP and DSP should be included in the Definitions section 2, even though the
abbreviations are are defined in section 1.2
Alternatively spell out in section 3.1. and 3.2 titles what DP and DPS are.
Makes perfect sense. I prefer spelling it out in the section headers to keep
the document from growing even further.
Good
b) The document for all practical purposes is about the process until a zone
has been signed/resigned. There is almost no discussion about the operation of
the signed zone is this intentional or an omission ?
(the exceptions are the key rollover sections 4.5.4+5)
The document is intended to cover all security-related aspects and topics
(including operational) which is impacted by the introduction DNSSEC in a zone.
So in this context, technical operation of the signed zone is covered in the
key-rollover sections (6.4, 6.5), in the signing/re-signing section (6.6) and
the verification of the data to be signed (6.7, 6.8). From a
business-operational perspective, contingency and disaster-recovery planning is
covered in 4.5 and 4.6. For key management life-cycle operations (such as
generation of new keys and possibly also distribution, backup and destruction),
should be covered in sections 5.1 and 5.3.
Are other aspects to operations which you think should be included in the
document? (Or do you think the scope is too narrow?)
I think the document needs to be clearer as to what is NOT covered in a
DSP.
It is fine for the document to say that it only covers: (in section 1.3)
"As to DNS operational aspects of the zone, Normal DNS operation is
outside the scope of this document but best DNS operational practices
are expected".
(as this is a product of the dnsop WG you need to say that or some
readers may have expectations as how to set up name-servers).
Having said that does the document need to spell out how to recover if
the signing infrastructure fails?
c) Section 4.6.9 should not limit itself to TTL's to types it should cover all
types in the zone as the Maximum TTL in the zone impacts how fast keys can be
added/removed from DNSKEY set.
Good point, you are absolutely right. SOA expire and negative caching is also
part of the equation.
d) Section 4.6.8 does not indicate what the purpose of this test is.
I think the purpose is to prevent bad data from showing up in the DNS.
Yes. It currently reads:
This subsection addresses the controls around the verification of the
resource records in order to validate and authenticate the data to be
signed.
Should we clarify in that? Suggestions?
What I want to know is, how does a failure in the signing system, show up?
1) updates to be blocked i.e. zone will stop processing updates.
2) New versions of zone will not show up on schedule
3) bad data will be published but will be replaced as soon as possible?
4) something else.
as this may affect Service level agreements having this spelled out is a
good thing.
f) There needs to be section (4.6.x) for zones that use NSEC3 as to the policy
for changing NSEC3 parameters as this is similar to a ZSK roll-over.
The intention is to have this in 6.2. But I see that there are no mentions of
policy for changing of NSEC3-parameters in 4.6.2 of the draft. I'm thinking of
adding a sentence to the text in 4.6.2 instead of creating a new subsection?
That is fine,
Questions:
c) should the DPS have a section describing if/when/how a zone (i.e. the one
covered by the DPS) goes to unsigned?
There has been discussions about this among the authors, but so far we've
agreed on that such procedure is a DR-procedure and may be described in 4.5.
I agree this frequently is a Disaster Recovery, but this may also be a
policy decision.
In particular for a tld. having DS removed is estimated to take 2 days,
flushing the DS takes another day, DNSKEY may still trusted by resolvers
for the DNSKEY TTL.
Thus in the case of loss of zone signing the DS must be removed 3 days +
DNSKEY TTL before the first signature in the zone expires.
If the zone is going to bring up a new signing system (with new keys) is
the zone going be dual signed until old keys are flushed from the system.
d) Should the DPS have a section describing the zone's policy as how to perform
an algorithm rollover ?
what I'm in particular looking for is in particular how long the zone expects
to be signed by both algorithms.
I'm thinking that whatever forces a zone to change the algorithm is an
unexpected event which has many dependencies to unknown factors (such as
resolver implementations, new algorithms .. ), which is really hard to plan
ahead for in such detail.
Still does not cover if/how long the zone is going to be dual signed.
As to the planning for algorithm rollover.
The DSP may say
"before any algorithm rollover a new DSP will be published x months
before the event"
or "in case of introduction of new algorithm in the zone the zone will
be dual signed for x days"
or "zone will NEVER roll algorithm only go to longer keys"
or "zone will change from NSEC3 to NSEC 6 months after x% of the zone
has DS records"
Algorithm rollover is the scariest part of DNSSEC operation,
Although, the emergency case (where a algorithm has been fundamentally broken)
should be covered in 4.5.3 (Entity private key compromise procedures).
I think there are two different cases, that need to be covered, key
compromised and algorithm compromised.
The first one is important the second one is not a big deal as
DNSSEC is only one of many security systems that will be affected and
slow and deliberate process in this case is better for everyone than
quick over-reaction.
Thus the document should focus on the first case, by recommending that
the zone publish a time-line for algorithm rollover and include a
policy as how long the zone is going to be dual-signed.
Olafur
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
