On 2010-10-04, at 12:53, Tony Finch wrote: > On Mon, 4 Oct 2010, Joe Abley wrote: >> On 2010-10-04, at 11:33, Tony Finch wrote: >>> On Mon, 4 Oct 2010, Joe Abley wrote: >>>> >>>> I have not heard a clear description of a problem yet >>> >>> How can a system that missed a TA rollover bootstrap its DNSSEC validator? >> >> The same way that it bootstraps itself at day zero. > > I expect that validators will ship with an initial TA built in (e.g. as > BIND does for DLV) which means the two scenarios are very different.
We've talked to DNS vendors and although I don't want to foreshadow their timelines for making code or strategies available, I can tell you that there is work underway to accommodate 5011 rollover, 5011 rollover with a client that is disconnected over the transition window, and day-zero trust anchor bootstrap. No show-stoppers have been identified in the conversations I have seen. No doubt the vendors concerned will describe their approach when they are ready. > Even if the validator does not ship with an initial TA, there is still a > big difference between no TA and a broken TA, so the validator still has > to be able to work out if the breakage is benign or malicious. > > It would be nice to see some evidence that other people are thinking about > this problem seriously and in detail rather than brushing off my questions > :-/ I think some of your questions are best directed towards vendors. I think some of your observations (those that relate to root KSK management in general, as described in the DPS) would have been good to hear before July, during the design process. The DPS is not written in concrete, but at the same time we are not about to make radical changes in a split second now that the key is in production. We are being audited against the current DPS, as-published. I think also that there is some sense that the trust-anchor document is intended as a starting point for a working group design exercise, which is not the case. This is an informational document describing an existing service, and is being published in the interests of having a stable specification in a sensible place for vendors to code against. We are not seeking working group adoption; our goal is an AD-sponsored, individual submission. Hence the review here is really in the interests of document quality and clarity of the specification (something that many reviewers have helped us with already, and which I expect will result in a better document). Really, I'm not trying to brush off your questions, but given the context above it's difficult to give you the kind of answers you seem to want. Joe _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
