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 [email protected] https://www.ietf.org/mailman/listinfo/dnsop
