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

[Matthijs Mekking <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

On 08/24/2012 07:54 PM, Edward Lewis wrote:
> 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.)

Talking about complexity, finding the most Gerber-ized version of this
document might be a NP-complete problem ;)

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

I'll make it worse. In this case it's the largest value of all TTLs in
a range of *previous versions* of the zones. Suppose that largest
value has been lowered in the latest version of the zone, we still
need to take into account that the predecessor data is cached for that
large amount of time.

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

Simplest here I guess refers to shortest, or, the least steps involved.

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

But it has no use to publish a KSK DNSKEY before its accompanying
signature: When there is a DS record, the KSK that is referred to
should also sign the DNSKEY RRset. When there is not yet a DS record,
it should not be introduced until the KSK and its accompanying
signature have been propagated to the caches.

> 
> Perhaps it isn't "not applicable" but "not
> realistic/sensible/practical".

Not sensible would be the most sensible here :).


Best regards,
  Matthijs

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJQO2yMAAoJEA8yVCPsQCW5KWYIAIp4ehruQAQAEFZ1bMaEMem5
CbJRLmJ7SZyQwhj8YiI9OUKY9uEvlvSyL9WhovlUyutQZJVqMQ/MKvFilJQ6vk1w
PBtnbPxODqIDNPbiV9/r6/2dBHSNgMTzo1wBvtMZ9dEuY6lWdl+t4yd71Wm/C8LH
xmSYmeMSE6+EnKx4hE15MO0DB3nDmDaFZ0GscUVMxtbQFT0v9njSy7AV/BUn0nqX
E2mZ+n4KMaV5+kjgdFnJ9rXm1ozx6hXibtYCqAEHVHEWT9CuEqc/z7nMqiZYZbqR
ujGJeSdg6Ll87Z6kiPScIK2Kjl6fe0LdydtSHQJiFirA7erc7WTPi9V1LbJx6Uw=
=XTeC
-----END PGP SIGNATURE-----