Re: [DNSOP] WGLC draft-ietf-dnsop-dnssec-key-timing-03.txt until 2012-09-14
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
Re: [DNSOP] draft-ietf-dnsop-dnssec-key-timing
On Aug 20, 2012, at 17:33 , Paul Hoffman wrote: On Aug 20, 2012, at 6:19 AM, Peter Koch p...@denic.de wrote: Andrew, In the archives since the meeting, I observe some comments at http://www.ietf.org/mail-archive/web/dnsop/current/msg09783.html. But I do not observe the announcement of a WGLC. I am wondering when we might expect that call. both chairs have taken advantage of the season at least a bit. One of the chairs has recused himself being a co-editor, so this is the document shepherd. Issuing the WGLC involves reviewing the draft as well as the recent discussion to generate framing questions. In this particular case, several members of the WG, some of which I remember having been in favour of WGLC during the Vancouver meeting, had expressed support for a major change to the draft suggested by Matthijs Mekking on July 24 http://www.ietf.org/mail-archive/web/dnsop/current/msg09767.html That would basically mean folding significant parts of 'keytiming bis' into the current 'key timing' draft. That was my (probably biased) memory as well. My current reading of the sense of the WG is that we move to WGLC with -03, declaring the July 24 suggestion out of scope for this document and keep momentum for 'dnssec bis'. That's one way to do it. A better one would be to start WG LC on key-timing with an explicit question to the WG about folding in the keytiming-bis changes. That way, the WG would know the status of both, and we would would possibly produce just one document. The operations community would be better off with just one document, if this WG can do that. Not to question the abilities of the WG, but I still have to ask whether (in your opinion) the operations community would be better off with a single document that may be finished around Christmas Eve 2020 or rather live with multiple docs that are published somewhat sooner than that. Having more than one requires them to know the RFC numbers for all the documents for which they are possibly interested. Other WGs have problems with developers having to know about three RFCs for a protocol; it seems odd to think that us having a dozen documents for operators is a good idea. Long documents are not a problem if they are reasonably well organized with truly parallel sections. So, on principle I have to disagree with this. Multiple documents are a method of abstraction and organization, just like directories, or, for that matter, dividing your source into multiple files. If it is really a problem to have to refer to more than on RFC, then I think we made a huge error many years ago when we gave RFCs a number. We should have gone for The RFC For The Internet (yet to be published) and meanwhile kept the Internet running on various versions of expired drafts. Tongue-in-cheek and no offence intended ;-) Regards, Johan ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-dnssec-key-timing
On 2012-08-30 9:40 AM, Johan Ihrén wrote: On Aug 20, 2012, at 17:33 , Paul Hoffman wrote: On Aug 20, 2012, at 6:19 AM, Peter Koch p...@denic.de wrote: My current reading of the sense of the WG is that we move to WGLC with -03, declaring the July 24 suggestion out of scope for this document and keep momentum for 'dnssec bis'. dnssec-bis was delegated signer. dnssec-ter was type code roll. we're on dnssec-nextgen now. That's one way to do it. A better one would be to start WG LC on key-timing with an explicit question to the WG about folding in the keytiming-bis changes. That way, the WG would know the status of both, and we would would possibly produce just one document. The operations community would be better off with just one document, if this WG can do that. Not to question the abilities of the WG, but I still have to ask whether (in your opinion) the operations community would be better off with a single document that may be finished around Christmas Eve 2020 or rather live with multiple docs that are published somewhat sooner than that. while i agree with these sentiments i have a broader concern. ietf's mantra is good engineering. if we know now that keytiming has flaws, and we are only considering publishing it because we know our own record shows that reaching consensus for keytiming-bis will take a long time, then it's an implicit indictment (by us) of our own record and habits. we should have a better reason for publishing two documents, like new ideas occurred to us after the first one was beyond reach of our pen, or they have different topics. paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-dnssec-key-timing
On Aug 30, 2012, at 9:45 AM, Paul Vixie p...@redbarn.org wrote: On 2012-08-30 9:40 AM, Johan Ihrén wrote: Not to question the abilities of the WG, but I still have to ask whether (in your opinion) the operations community would be better off with a single document that may be finished around Christmas Eve 2020 or rather live with multiple docs that are published somewhat sooner than that. while i agree with these sentiments i have a broader concern. ietf's mantra is good engineering. if we know now that keytiming has flaws, and we are only considering publishing it because we know our own record shows that reaching consensus for keytiming-bis will take a long time, then it's an implicit indictment (by us) of our own record and habits. we should have a better reason for publishing two documents, like new ideas occurred to us after the first one was beyond reach of our pen, or they have different topics. A big +1. An operator who wants to know how to do rollovers will not know *or care* why they followed IETF guidance that was overturned or even clarified soon after. The reasons that the base document got delayed so horribly do not matter any more: what matters is what the WG and its leadership are willing to do today to help operators in the near future. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-dnssec-key-timing
On 2012-08-30, at 13:11, Paul Hoffman paul.hoff...@vpnc.org wrote: On Aug 30, 2012, at 9:45 AM, Paul Vixie p...@redbarn.org wrote: On 2012-08-30 9:40 AM, Johan Ihrén wrote: Not to question the abilities of the WG, but I still have to ask whether (in your opinion) the operations community would be better off with a single document that may be finished around Christmas Eve 2020 or rather live with multiple docs that are published somewhat sooner than that. while i agree with these sentiments i have a broader concern. ietf's mantra is good engineering. if we know now that keytiming has flaws, and we are only considering publishing it because we know our own record shows that reaching consensus for keytiming-bis will take a long time, then it's an implicit indictment (by us) of our own record and habits. we should have a better reason for publishing two documents, like new ideas occurred to us after the first one was beyond reach of our pen, or they have different topics. A big +1. An operator who wants to know how to do rollovers will not know *or care* why they followed IETF guidance that was overturned or even clarified soon after. I suspect an increasing proportion of operators doing DNSSEC do not care how to do rollovers, in fact. They care that the software they're using to manage keys and sign things is doing the right thing. The pragmatic long-term view is, I think, that this document doesn't give advice to operators so much as advice for those implementing DNSSEC signers. I am not suggesting that operators don't care what happens under the hood, or that vendors don't care about operators. But I think the inference that this is advice to heed before you dive in and perform rollovers by hand is short-sighted. The focus ought to be advice that can be converted easily into good code. I am not a developer of DNS software, and hence don't feel well-placed to review the draft from that perspective. However, my feeling (based on words absorbed inadvertently from people who are developers) is that the document would better serve that perspective if it presented robust state machines and algorithms for arbitrary rollovers. As an operator I would very much like trustworthy tools that could take my desire (say) to roll a KSK from an N-bit alg-A key to an M-bit alg-B key and show me the timing constraints for that rollover to be completed, so I can plan the exercise, accommodate any expected delay in DS publication in parent zones, keep my relying parties informed, and hopefully have robots execute the actual zone changes for me. Working all that out by hand (and making the zone changes manually) based on the advice in dnssec-key-timing is error-prone. Joe smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-dnssec-key-timing
On Aug 30, 2012, at 10:57 AM, Joe Abley joe.ab...@icann.org wrote: I suspect an increasing proportion of operators doing DNSSEC do not care how to do rollovers, in fact. They care that the software they're using to manage keys and sign things is doing the right thing. Good point, yes. The pragmatic long-term view is, I think, that this document doesn't give advice to operators so much as advice for those implementing DNSSEC signers. Yes and no. Many of the aforementioned operators are probably going to be asked are you sure that the software you are using follows the specifications and those operators are going to look for the vendor's checkmark next to the right RFC number. If so, this argues strongly for fewer RFCs for the checkmarks to match to. I am not suggesting that operators don't care what happens under the hood, or that vendors don't care about operators. But I think the inference that this is advice to heed before you dive in and perform rollovers by hand is short-sighted. The focus ought to be advice that can be converted easily into good code. Yes. Here, good should also mean code whose logs can be followed by someone who hasn't read the RFC, if needed. I am not a developer of DNS software, and hence don't feel well-placed to review the draft from that perspective. However, my feeling (based on words absorbed inadvertently from people who are developers) is that the document would better serve that perspective if it presented robust state machines and algorithms for arbitrary rollovers. As an operator I would very much like trustworthy tools that could take my desire (say) to roll a KSK from an N-bit alg-A key to an M-bit alg-B key and show me the timing constraints for that rollover to be completed, so I can plan the exercise, accommodate any expected delay in DS publication in parent zones, keep my relying parties informed, and hopefully have robots execute the actual zone changes for me. Working all that out by hand (and making the zone changes manually) based on the advice in dnssec-key-timing is error-prone. Yes. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-dnssec-key-timing
Paul Vixie p...@redbarn.org wrote: while i agree with these sentiments i have a broader concern. ietf's mantra is good engineering. if we know now that keytiming has flaws, and we are only considering publishing it because we know our own record shows that reaching consensus for keytiming-bis will take a long time, then it's an implicit indictment (by us) of our own record and habits. But I thought the flaws discussed in this thread were in terms of presentation rather than engineering. (I haven't reviewed the document yet.) As far as I can tell DNSSEC implementations and deployment are still in a somewhat exploratory phase wrt key management, so it is reasonable to expect it to take a long time to work out how to simplify the document in a sensible way. I expect it to go along with good implementations of canned rollover procedures. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
