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

From: Peter Koch <[email-masked]>
Date: Thu, 23 Aug 2012 23:49:24 +0200

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

The WGLC will last until Friday, 14 September 2012
owed to return-to-desk season and the length of the draft.

The intent is to request publication of the document as an Informational RFC.

Please review the draft and send comments to this list (pls keep the full file
name of the draft in the "Subject:"). A little guidance for what to look at:

o appropriateness for the target audience
o technical correctness and internal consistency
o consistency with and/or relation to RFC 4641 and its designated
  successor <http://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc4641bis/>

In line with our custom the draft will only progress if it receives
five or more significant(*) reviews and the (rough) consensus is in favour.

(*) Please review thoroughly.  While "yeah, ship it" might be perceived better 
than silence, it is not always helpful to determine consensus.  In this particular 
case, I might take it as an indicator that the draft has received a cursory read.
That is not to express an opinion on the quality of the draft, just a hint
that there should be one bite for everybody. (For completeness sake, the remark
applies to "nay" contributions respectively.)

Finally I would like to confirm that I saw Paul and Matthijs reinforce their 
concerns raised in Vancouver in response to my mail earlier this week.
Looking at <http://tools.ietf.org/wg/dnsop/minutes?item=minutes-84-dnsop.html>
the minutes I follow the mandate to issue the WGLC.  Looking forward to your
contributions.

Best regards,
   Peter (as co-chair and doc shepherd)

---

From: Edward Lewis <[email-masked]>
Date: Fri, 24 Aug 2012 13:54:54 -0400

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

---

From: Matthijs Mekking <[email-masked]>
Date: Mon, 27 Aug 2012 14:48:12 +0200

Hi,

On 08/24/2012 07:54 PM, Edward Lewis wrote:
> First, my blanket objection to the draft, which isn't meant to be
> an insult to the effort that has gone into it.
> 
> 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 ;)

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

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.

> simplest.  (I'm just sayin', that's my opinion.)  I think pre-pub
> is simpler because I know what TTL is involved (DNSEKEY).  For

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

> 
> Section 2.3
> 
> #
> +------------------+------------------+-----------------------------+
>
> 
> #
> +------------------+------------------+-----------------------------+
>
> 
> #   |                  |                  | 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.

> 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.
> 
> #   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.
> 
> 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).
> 
> #   publication, in the early stages of deployment, and best
> practices #   may further develop over time.
>

---

From: Johan Ihrén <[email-masked]>
Date: Thu, 30 Aug 2012 11:23:26 +0200

Hi Ed,

On Aug 24, 2012, at 19:54 , Edward Lewis wrote:

> First, my blanket objection to the draft, which isn't meant to be an insult to the effort that has gone into it.
> 

I agree.

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

While I mostly have to agree I also have to point out that with today's anycast clouds it is more likely than before that one actually may lose contact with a remote site for a while. I know that it happens to us, and while we obviously immediately attempt to rectify the situation the fact remains that our slave server on the dark side of the Moon is not just a NOTIFY+IXFR delayed. Furthermore, the TTL is also part of the propagation delay, and that obviously always remains.

So your claim of "practically it isn't there" is, unfortunately, too strong for me.

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

While I do see your point, I still think it is fair to claim that Double-Signature is CONCEPTUALLY the simplest. I.e. it is simpler to explain Double-Signature to a noob than to explain the other alternatives.

But let's not quibble about language at this stage, you do have a point and we could have been clearer here. Sorry.

> Why is this "not applicable" for KSK?  A KSK can be listed before it is used as one.

The entire raison d'etre for pre-publication that for a ZSK the RRSIGs (that ZSKs generate) and the DNSKEYs (of which the ZSK is a part) don't travel together, and hence may or may not be in the same cache at the same time. 

This, however, does not hold true for KSKs, because the RRSIG generated by the KSK *must* travel together with the KSK and hence pre-publication is meaningless. You just publish the new KSK at the same time that you start using it for generating RRSIGs.

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

Or "pointless".

> This one is non-sensical for KSK.  As an operator, I'd want to test locally before involving another party.

You're assuming that the other party (i.e. the parent) is someone else than yourself. That is not necessarily correct. Another reason may be that while you know that you will be able to publish your new KSK almost instantly, you also know that that lazy-bones of a parent will take a random time between 1h and 2 weeks to add the new DS. So you start with the request to the parent...

I have to disagree that Double-DS is non-sensicalf for a KSK. It is not, although in the common use case of the parent being a well-run TLD then I can see the *parent* being against this method. But that's not the only case I care about.

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

I disagree with your disagreement ;-)

I do agree with the goal of minimizing operational disruption. That's the correct goal. In some cases it may be that the consequence is to basically ignore the problem and just stay with the normal rollover schedule. 

Also, one has to ask whose operations we're talking about ... i.e. there's a difference between minimizing your operational disruption (as the zone owner) and the operational disruption for an ISP doing validation of your data (see nasa.gov vs Comcast).

However, IF you've made the decision not to stay with the schedule, but actually cause an operational disruption and do an emergency rollover THEN you want it to complete as quickly as possible.

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

This is exactly my view also.

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

Sure.

> This is true.  I wish this would be emphasized in the earlier parts of the document.

I agree.

Regards,

Johan