At 23:49 +0200 8/23/12, Peter Koch wrote:
Dear DNSOP WG,
this is to initiate a working group last call (WGLC) for
"DNSSEC Key Timing Considerations"
draft-ietf-dnsop-dnssec-key-timing-03.txt
<http://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-key-timing/>
First, my blanket objection to the draft, which isn't meant to be an
insult to the effort that has gone into it.
The draft is too detailed.
Ok, I get that that is the purpose. And it achieves that, and
probably should be lauded for that and be published for that. But,
as an operator/implementor, the draft doesn't cut to the chase.
I first mentioned this a long time ago, and usually would just let it
drop. But in the last few weeks a senior developer said the same to
me - it's really well detailed, but very complex. He also added that
our design complied with it in a very simplified form. I replied
that that was no accident. ;)
So - I admire this draft, but wish there was a Gerber-ized version.
(Gerber being a brand of baby food.)
To give a concrete example of what I mean by too detailed - Dprp
(propagation delay) is something that can be ignored with the advent
of NOTIFY and IXFR. Theoretically it is there, practically it isn't
there.
Some specific comments:
Section 2.1
# Of three methods, Double-Signature is conceptually the simplest -
# introduce the new key and new signatures, then approximately one TTL
# later remove the old key and old signatures. Pre-Publication is more
Which TTL? The TTL of the DNSKEY set, the TTL that is the largest
value of all the TTLs in the zone, etc.?
Because of that question, I disagree that double signature is the
simplest. (I'm just sayin', that's my opinion.) I think pre-pub is
simpler because I know what TTL is involved (DNSEKEY). For
signatures, the TTL might vary through the set.
Section 2.3
# +------------------+------------------+-----------------------------+
# | ZSK Method | KSK Method | Description |
# +------------------+------------------+-----------------------------+
# | Pre-Publication | (not applicable) | Publish the DNSKEY before |
# | | | the RRSIGs. |
Why is this "not applicable" for KSK? A KSK can be listed before it
is used as one.
Perhaps it isn't "not applicable" but "not realistic/sensible/practical".
# | (not applicable) | Double-DS | Publish DS before the |
# | | | DNSKEY. |
This one is non-sensical for KSK. As an operator, I'd want to test
locally before involving another party.
I guess my notes here reflect that I see this document as helping
operations as opposed to being an analysis of the protocol
engineering.
Section 4.
# The aim of the emergency rollover is to allow the zone to be re-
# signed with a new key as soon as possible. As a key must be in the
# ready state to sign the zone, having at least one additional key (a
# standby key) in this state at all times will minimise delay.
I disagree with that goal. In designing emergency key changes, we
realized the goal is to minimize operational disruption, not minimize
time until a new key is "in place." In some cases, a key "break"
might be a local event, local in the sense of the target name or the
target of the poisoning. With this in mind, the only difference
between a scheduled key change and an emergency key change is whether
it is planned or not (;)) and how much more you pester the parent for
the DS change (if needed).
And the latter sentence might be countered with - having a standby
key is a tradeoff against having smaller responses. (The same old
"time vs. space" tradeoff.) Here, it's a matter of optimizing for
the sunny day or the cloudy day.
Section 6
# The reader is therefore reminded that DNSSEC is, as of date of
# publication, in the early stages of deployment, and best practices
# may further develop over time.
This is true. I wish this would be emphasized in the earlier parts
of the document.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar You can leave a voice message at +1-571-434-5468
2012...time to reuse those 1984 calendars!
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
