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

[Johan Ihrén <[e-mail]>]

Hi Ed,

On Aug 24, 2012, at 19:54 , 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.

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.

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

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.

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

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

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

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

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.

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

I agree.

Regards,

Johan