Re: [DNSOP] WGLC draft-ietf-dnsop-dnssec-key-timing-03.txt until 2012-09-14

[Edward Lewis <[e-mail]>]

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 [phone]

2012...time to reuse those 1984 calendars!