Re: [DNSOP] WGLC: DNSSEC Trust Anchor Configuration and Maintenance
At 22:30 29/04/2009, Paul Hoffman wrote: At 8:13 PM +0200 4/22/09, Peter Koch wrote: Please review the draft and send comments and/or statements of support or non-support to the WG mailing list. There will be a five reviewer threshold. I support the publication of this document. Some comments: Section 2: Using a DS format is also recommended because it is smaller than the DNSKEY format and is easier to enter manually, either by typing or cutting and pasting. I don't know of anyone who can accurately type Base64 for more than a few bits worth. I agree that cut-and-paste of Base64 for DS is easier than for a DNSKEY. DS has base16 format which is easier than Base64 for typing and visual inspection. Section 3: Priming can occur when the validating resolver starts, but a validating resolver SHOULD defer priming of individual trust anchors until each is first needed for verification. I disagree with this as a SHOULD; may want to is much more appropriate. I see nothing wrong with wanting to get the first round of crypto out of the way at startup. Good point, How about s/SHOULD/MAY want to/ ? Section 3: Following are the steps a validating resolver SHOULD take to prime a configured trust anchor:. What do you propose they do if they don't follow the SHOULD? All four of those steps feel pretty damn required. I have no problem upgrading them all to MUST but we got pushback on that in earlier version: Section 4, Trusted update mechanism: This mechanism is realistically only feasible for updating a small number of trust anchors, such as for the top-level domains. That statement is conjecture unsupported by facts. What is so hard about doing this for a few thousand trust anchors? The queries will be spread over hours (if not weeks). Maybe remove the sentence, or soften it. If vendor X is willing to become a TAR for large number of domains that is fine, I think we assumed (possibly incorrectly) that vendors were not in the TAR business. For example how quickly will Apple be able to push out a new set of TA's to the millions of clients they have? thanks for the comments Olafur ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] WGLC: DNSSEC Trust Anchor Configuration and Maintenance
At 1:48 PM -0400 5/12/09, Olafur Gudmundsson wrote: At 22:30 29/04/2009, Paul Hoffman wrote: At 8:13 PM +0200 4/22/09, Peter Koch wrote: Please review the draft and send comments and/or statements of support or non-support to the WG mailing list. There will be a five reviewer threshold. I support the publication of this document. Some comments: Section 2: Using a DS format is also recommended because it is smaller than the DNSKEY format and is easier to enter manually, either by typing or cutting and pasting. I don't know of anyone who can accurately type Base64 for more than a few bits worth. I agree that cut-and-paste of Base64 for DS is easier than for a DNSKEY. DS has base16 format which is easier than Base64 for typing and visual inspection. The sentence in the doc is specifically about typing. Typing hex may be easier than typing Base64, but it is also more tedious and probably about as error-prone. Section 3: Priming can occur when the validating resolver starts, but a validating resolver SHOULD defer priming of individual trust anchors until each is first needed for verification. I disagree with this as a SHOULD; may want to is much more appropriate. I see nothing wrong with wanting to get the first round of crypto out of the way at startup. Good point, How about s/SHOULD/MAY want to/ ? No, s/SHOULD/may want to/. There is no interoperability or security reason for using 2119-style language here. Section 3: Following are the steps a validating resolver SHOULD take to prime a configured trust anchor:. What do you propose they do if they don't follow the SHOULD? All four of those steps feel pretty damn required. I have no problem upgrading them all to MUST but we got pushback on that in earlier version: Understood. However, if you have this as SHOULD, you need to explain when the reader is allowed to not do one or more of the steps. Leaving it to the reader's imagination is a sure-fire way to have them choose incorrectly. Section 4, Trusted update mechanism: This mechanism is realistically only feasible for updating a small number of trust anchors, such as for the top-level domains. That statement is conjecture unsupported by facts. What is so hard about doing this for a few thousand trust anchors? The queries will be spread over hours (if not weeks). Maybe remove the sentence, or soften it. If vendor X is willing to become a TAR for large number of domains that is fine, I think we assumed (possibly incorrectly) that vendors were not in the TAR business. From the traffic I have seen on the various DNSSEC lists, that is definitely an incorrect assumption. In fact, some people have pushed the notion that distribution of DNSSEC trust anchors by the software vendors is likely to be more stable than other choices. As much as I hate to admit it, that rings true to me. For example how quickly will Apple be able to push out a new set of TA's to the millions of clients they have? Apple can decide that for themselves. They already push out much larger software updates, as do most software vendors. Even a large TAR is probably smaller than many software updates that we all live with today. --Paul Hoffman, Director --VPN Consortium ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] WGLC: DNSSEC Trust Anchor Configuration and Maintenance
At 14:45 22/04/2009, Edward Lewis wrote: At 20:13 +0200 4/22/09, Peter Koch wrote: this is to initiate a working group last call on DNSSEC Trust Anchor Configuration and Maintenance draft-ietf-dnsop-dnssec-trust-anchor-03.txt ending Friday, 2009-05-08, 23:59 UTC. The tools site gives easy access to diffs and such under http://tools.ietf.org/html/draft-ietf-dnsop-dnssec-trust-anchor-03. I keep forgetting this bit of document jockeying - can an Informational use RFC 2119 terms in a normative way? ... #3. Trust Anchor Priming ... # 3. Verify that the DNSKEY RR corresponding to the configured trust # anchor (i.e., the DNSKEY whose hash is configured) appears in the # DNSKEY RRSet and that this DNSKEY RR has the Zone Key Flag # (DNSKEY RDATA bit 7) set. (This bit only indicates that the # DNSKEY is allowed to sign the zone. This DNSKEY may or not be a # zone signing key.) Last sentence? - This DNSKEY might not be a zone a zone signing key.) But I'm not sure what is meant. At first the paragraph reads - make sure the Zone Key Flag is set and later says it may or [may] not be a zone signing key. Do you mean that this key could be a key signing key? We are trying to say that the key can be both KSK and ZSK but does not have to be. How about: this DNSKEY might also be a zone signing key? # 4. Verify that the DNSKEY RRSet is signed by one of the DNSKEYs # found in the previous step, i.e., that there exists a valid RRSIG # (cryptographically and temporally) for the DNSKEY RRSet generated # with the private key corresponding to the DNSKEY found in the # previous step. And here, are you saying that this DNSKEY RR's private companion has to sign the key set for all this to work? In step three you refer to a singular (this) key, in step four it is plural (is signed by one of the). you are right step 3 should be plural as well. ... # For this reason, old trust anchors SHOULD be removed from a # validating resolver's trust anchor list soon after the corresponding # keys are no longer used by the zone, as described in RFC 5011 # [RFC5011]. Recommend that the priming be done often enough to capture revoked DNSKEY RR's - so that the zone doens't have to keep them indefinitely. Well RFC5011 requires you scan at least once a month, and recommends higher frequency, is that sufficient? # 4. Trust Anchor Maintenance # # Trust anchors correspond to zones' key signing keys and these keys do keeping the terminology clean Trust anchors *could* be zone signing keys. Still I think you want this here - SEPs? Is that what is meant? Same as above KSK and ZSK can be one key. There is no requirement that a KSK have the SEP bit set only a recommendation. (RFC 4034: 2.1.1. The Flags Field ... Bit 15 of the Flags field is the Secure Entry Point flag, described in [RFC3757]. If bit 15 has value 1, then the DNSKEY record holds a key intended for use as a secure entry point. This flag is only ) # 5. Security considerations # # This document proposes a standard format for documenting DNSSEC trust # anchors. I didn't see a standard format (a la a zone file). Just use the DS fields. Perhaps I was expecting examples and such. We assumed (possibly incorrectly) that having a reference was sufficient. thanks for your comments Olafur ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] WGLC: DNSSEC Trust Anchor Configuration and Maintenance
On Tue, 12 May 2009, Olafur Gudmundsson wrote: Section 3: Priming can occur when the validating resolver starts, but a validating resolver SHOULD defer priming of individual trust anchors until each is first needed for verification. I disagree with this as a SHOULD; may want to is much more appropriate. I see nothing wrong with wanting to get the first round of crypto out of the way at startup. Good point, How about s/SHOULD/MAY want to/ ? I think that would be COULD then If vendor X is willing to become a TAR for large number of domains that is fine, I think we assumed (possibly incorrectly) that vendors were not in the TAR business. It's a choice of becoming a TAR vendor or outsource to ISC DLV. I still believe the DLV should be used for signed entries in unsigned parents only, and no i don't count the root, as to minimize the dependancy on one DLV Registry. For example how quickly will Apple be able to push out a new set of TA's to the millions of clients they have? I don't think commercial OS vendors have much of a problem here. The opensource vendors, where updates are not a mantatory part of life, might have a harder time. Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] WGLC: DNSSEC Trust Anchor Configuration and Maintenance
On Tue, May 12, 2009 at 04:28:01PM -0400, Paul Wouters wrote: On Tue, 12 May 2009, Olafur Gudmundsson wrote: Section 3: Priming can occur when the validating resolver starts, but a validating resolver SHOULD defer priming of individual trust anchors until each is first needed for verification. I disagree with this as a SHOULD; may want to is much more appropriate. I see nothing wrong with wanting to get the first round of crypto out of the way at startup. Good point, How about s/SHOULD/MAY want to/ ? I think that would be COULD then i think i am going to weigh in on th eother side of the coin here. I'd posit s/SHOULD/SHOULD NOT/ ... Is there any good reason why validation and resolution need to be in lock-step? --bill ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] WGLC: DNSSEC Trust Anchor Configuration and Maintenance
At 14:08 -0400 5/12/09, Olafur Gudmundsson wrote: We are trying to say that the key can be both KSK and ZSK but does not have to be. Oh... How about: this DNSKEY might also be a zone signing key? Yeah. Well RFC5011 requires you scan at least once a month, and recommends higher frequency, is that sufficient? Sure. # 4. Trust Anchor Maintenance ... Same as above KSK and ZSK can be one key. There is no requirement that a KSK have the SEP bit set only a recommendation. But then you should be referring to SEP and not KSK for the most part. I think. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStarYou can leave a voice message at +1-571-434-5468 Getting everything you want is easy if you don't want much. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] WGLC: DNSSEC Trust Anchor Configuration and Maintenance
I'll pass on my comments on the draft. I've removed my comments that were duplicates of those submitted by Ed and Paul W. I'm not an English language expert (even though it is my first and primary language; I just defer to those with better knowledge than I), but I did find the draft well readable and only spotted a few minor typographical nits which makes it a pretty good document in my view. Section 2, Last paragraph -- This text sort of implies implementations can pick which size of a hash they wish to support. I'm not sure that was the intent or not. IMHO, implementations should only allow complete DS record length hashes (which may themselves be truncated versions of the hash algorithm). Implementations SHOULD NOT allow for configuration of hash lengths which are shorter than what the DS length itself specifies. DS lengths are frequently chosen with great care for cryptographic reasons. I wouldn't be happy with an implementation that accepted a 2 byte hash as an acceptable truncated DS record. Section 3, next sentence after step 4 - Doesn't take into account (5011) revoked keys. It's discussed later, but this sentence is incorrect. 5011 REVOKED keys aren't caught as an exception in the above points and specifically prohibit can be used authenticate RRSets at or below the trust anchor. Section 3, next sentence after step 4 - used authenticate - used to authenticate section 4, Trust anchors correspond to zones' key signing keys As has sort of been beat upon already, this isn't the case. TAs can be either ZSKs or KSKs. section 4 - updating that information - update that information section 4 and trust anchor repositories - Section 4 is remiss in not mentioning obtaining keys via a third party trust-anchor-repository. The Trusted update mechanism or Manual configuration should probably explicitly mention keys obtained from TARs because they're looking to be popular. -- In the bathtub of history the truth is harder to hold than the soap, and much more difficult to find. -- Terry Pratchett ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] WGLC: DNSSEC Trust Anchor Configuration and Maintenance
On Thu, 23 Apr 2009, Joe Abley wrote: [ enabling DNSSEC from stale install media that has an old trust anchor ] I don't like the idea of incorporating magic numbers (e.g. nine months) algorithmically when trying to determine suitability of an old trust anchor. I don't like it either, but currently, I don't see how to avoid this. The problem might not be as severe, since when installing a new machine and getting updates, one would think the newly installed machine is not using itself as a resolver, since we only enable dnssec on resolvers now, not on every install (yet). But once every install gets dnssec, one reboot would do it. But perhaps that can be caught with the firstboot feature of Fedora (I'm sure Ubuntu has similar features) But it seems like a bad idea to package trust anchors administered by others with any piece of software, if there's a chance that those trust anchors are going to form a circular dependency in the process of updating them. Circular dependancies are very common in the OS building/shipping model. Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] WGLC: DNSSEC Trust Anchor Configuration and Maintenance
At 8:13 PM +0200 4/22/09, Peter Koch wrote: Please review the draft and send comments and/or statements of support or non-support to the WG mailing list. There will be a five reviewer threshold. I support the publication of this document. Some comments: Section 2: Using a DS format is also recommended because it is smaller than the DNSKEY format and is easier to enter manually, either by typing or cutting and pasting. I don't know of anyone who can accurately type Base64 for more than a few bits worth. I agree that cut-and-paste of Base64 for DS is easier than for a DNSKEY. Section 3: Priming can occur when the validating resolver starts, but a validating resolver SHOULD defer priming of individual trust anchors until each is first needed for verification. I disagree with this as a SHOULD; may want to is much more appropriate. I see nothing wrong with wanting to get the first round of crypto out of the way at startup. Section 3: Following are the steps a validating resolver SHOULD take to prime a configured trust anchor:. What do you propose they do if they don't follow the SHOULD? All four of those steps feel pretty damn required. Section 4, Trusted update mechanism: This mechanism is realistically only feasible for updating a small number of trust anchors, such as for the top-level domains. That statement is conjecture unsupported by facts. What is so hard about doing this for a few thousand trust anchors? The queries will be spread over hours (if not weeks). Maybe remove the sentence, or soften it. --Paul Hoffman, Director --VPN Consortium ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] WGLC: DNSSEC Trust Anchor Configuration and Maintenance
I have read the doc and support it. Some minor comments/suggestions based on Ed's message: Edward Lewis wrote: At 20:13 +0200 4/22/09, Peter Koch wrote: this is to initiate a working group last call on DNSSEC Trust Anchor Configuration and Maintenance draft-ietf-dnsop-dnssec-trust-anchor-03.txt ending Friday, 2009-05-08, 23:59 UTC. The tools site gives easy access to diffs and such under #3. Trust Anchor Priming ... # 3. Verify that the DNSKEY RR corresponding to the configured trust # anchor (i.e., the DNSKEY whose hash is configured) appears in the # DNSKEY RRSet and that this DNSKEY RR has the Zone Key Flag # (DNSKEY RDATA bit 7) set. (This bit only indicates that the # DNSKEY is allowed to sign the zone. This DNSKEY may or not be a # zone signing key.) Last sentence? - This DNSKEY might not be a zone a zone signing key.) But I'm not sure what is meant. At first the paragraph reads - make sure the Zone Key Flag is set and later says it may or [may] not be a zone signing key. I might suggest the last two sentences read: (This bit only indicates that the DNSKEY is allowed to sign zone data. This DNSKEY may or may not be a zone signing key (ZSK) as defined in RFC 4641 [RFC4641]) If the intention was that the trust anchor may be a ZSK or a KSK, but they must have the zone signing bit set either way. Then have RFC 4641 as a ref. Although with RFC4641-bis being worked on, that may quickly become dated... Also, as Paul pointed out, it looks like Paul and I are one person with a long name. :) Scott -- Scott RoseComputer Scientist NIST ph: +1 301-975-8439 scott.r...@nist.gov http://www-x.antd.nist.gov/dnssec http://www.dnsops.gov/ - ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] WGLC: DNSSEC Trust Anchor Configuration and Maintenance
On 22-Apr-2009, at 15:17, Paul Hoffman wrote: Yes. For example, Ubuntu server long term stable releases are only put out every few years. If you pick one of them, you start off with an old image, then *hopefully* update as soon as you install. But, if you just turn on some services, this will be a problem that is quite different than the typical but you might be running unsafe binaries. Perhaps software vendors ought to arrange their own distribution of trust anchors using trust tokens whose lifetimes suit the software. It seems likely that one size will not fit all. For example, Ubuntu might require a package to be retrieved and installed after installation containing current trust anchors before it is possible to turn on validation. That package would presumably be authenticated using a key shipped with the OS whose lifetime is predictable in the context of the OS (e.g. a PGP key whose public portion is shipped on the install media, and hence which might be at least as trustworthy as the the rest of the OS installed from the same bit of plastic). I don't like the idea of incorporating magic numbers (e.g. nine months) algorithmically when trying to determine suitability of an old trust anchor. That seems likely to result in unnecessarily collateral damage in the event of an emergency KSK rollover. I don't ship software, so I don't know how practical this general advice is. But it seems like a bad idea to package trust anchors administered by others with any piece of software, if there's a chance that those trust anchors are going to form a circular dependency in the process of updating them. Joe ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] WGLC: DNSSEC Trust Anchor Configuration and Maintenance
On 22-Apr-2009, at 14:13, Peter Koch wrote: this is to initiate a working group last call on DNSSEC Trust Anchor Configuration and Maintenance draft-ietf-dnsop-dnssec-trust-anchor-03.txt ending Friday, 2009-05-08, 23:59 UTC. The tools site gives easy access to diffs and such under http://tools.ietf.org/html/draft-ietf-dnsop-dnssec-trust-anchor-03. The document is aimed at a status of Informational. Please review the draft and send comments and/or statements of support or non-support to the WG mailing list. There will be a five reviewer threshold. I have read this document and find it well-written and useful. A few somewhat minor improvements occurred to me, notes for which can be found below. I don't think any of them are tremendously substantive, and I think the document would still be accurate and useful if published as-is. I apologise for not reading the document and commenting earlier. I would be happy to suggest text in relation to any of the points below, if that seems useful. In the second paragraph of section 1, there is an assertion that root zone signing is a prerequisite for widespread public DNSSEC deployment. The text goes on to discuss islands of security. I am the last person to suggest that the root should not be signed yesterday, but I think it's possible for there to be widespread DNSSEC deployment without a signed root zone -- you just have more islands of security. I think that paragraph could be tidied up a little to make it clearer that the content that follows is useful without a signed root zone, just as it is useful with a signed root zone. As I read section 2 I found myself expecting to see an example (as someone else here also mentioned). Perhaps this is because of the reference to the root hints file in the preceding section; the analogous advice there gives a presentation format (canonical zone format) while section 2 does not: it only provides guidance as to the type of data that should be used. I think the presentation format should be specified, with an example. Section 4 does not provide guidance about updating a local trust anchor repository (e.g. a text file) based on the results of the trust anchor priming procedure which is described there. This seems like an important step; otherwise restarting a validator which has a really old trust anchor stored on disk might suddenly result in a priming failure, because of a key rollover elsewhere. I think storing updated trust anchors is implied by the text, but never really called out explicitly. I think explicit mention of it would be useful. Given the apparent popularity of the IANA ITAR it might be worth mentioning it as one of the examples of a trusted update mechanism that does not use the DNS for trust anchor retrieval. DLV provides another mechanism for obtaining trust anchors that a validator could use. It seems plausible that DLV could also be mentioned as another kind of DNSSEC In-Band Update mechanism, in addition to 5011. Joe ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] WGLC: DNSSEC Trust Anchor Configuration and Maintenance
At 2:45 PM -0400 4/22/09, Edward Lewis wrote: I keep forgetting this bit of document jockeying - can an Informational use RFC 2119 terms in a normative way? Unfortunately, yes. When I have pointed out that it a semantic layer violation, the response is usually along the lines of oh, you standards pedants are just so cute (sometimes). In other words, there is no problem with us using it here. --Paul Hoffman, Director --VPN Consortium ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] WGLC: DNSSEC Trust Anchor Configuration and Maintenance
On Wed, 22 Apr 2009, Peter Koch wrote: Please review the draft and send comments and/or statements of support or non-support to the WG mailing list. It seems a comma is missing between Scott's name and mine. One issue came up recently with the dnssec-conf package related to Section 4, Trusted update mechanism.. If an OS ships with preloaded trust anchors, and the medium is used over a year after it was created, eg an old CD/DVD copy, it might cause DNS to complete fail due to loading rolled over trust anchors. This DNS failure will prevent it from obtaining an updated trust anchor update if those reside within one of these zones. The question is what to do, or what to recommend. For Fedora/EPEL, I'm leaning towards automatically disabling all trust anchors (which includes DLV) if the package build date is older then 9 months. At the same time, we will commit to releasing at least a new package every 6 months, even if no changes were made and we are just bumping the release number. Upon package update, the resolver is restarted and the same check that disabled the trust anchors before will now accept the new package date, and enable trust anchors again. It might make sense to add a warning about this issue in the RFC? Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] WGLC: DNSSEC Trust Anchor Configuration and Maintenance
At 3:05 PM -0400 4/22/09, Paul Wouters wrote: If an OS ships with preloaded trust anchors, and the medium is used over a year after it was created, eg an old CD/DVD copy, it might cause DNS to complete fail due to loading rolled over trust anchors. This DNS failure will prevent it from obtaining an updated trust anchor update if those reside within one of these zones. The question is what to do, or what to recommend. For Fedora/EPEL, I'm leaning towards automatically disabling all trust anchors (which includes DLV) if the package build date is older then 9 months. At the same time, we will commit to releasing at least a new package every 6 months, even if no changes were made and we are just bumping the release number. Upon package update, the resolver is restarted and the same check that disabled the trust anchors before will now accept the new package date, and enable trust anchors again. It might make sense to add a warning about this issue in the RFC? Yes. For example, Ubuntu server long term stable releases are only put out every few years. If you pick one of them, you start off with an old image, then *hopefully* update as soon as you install. But, if you just turn on some services, this will be a problem that is quite different than the typical but you might be running unsafe binaries. --Paul Hoffman, Director --VPN Consortium ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
