Top-replying here, to attempt a high-level suggestion on how to get some close approximation of time, using DNS/DNSSEC exclusively.
(Warning to those with weak stomachs - this is mildly evil stuff.) First, without any assurances on the accuracy of local time, the best that can be achieved regarding bootstrap-to-trust-anchor is consistency validation. Having multiple ways to validate the consistency of answers received over DNSSEC, can create a high degree of confidence in the validity of the root key, but cannot get to 100% (I don't think, anyway). However, once you have a trust anchor (root key) that you have a lot of confidence in, you can then do some cute DNSSEC tricks to get a rough idea of time, and then a better idea of time. First, look at the contents of the RRSIGs for the root. If you believe the RRSIGs, you also necessarily believe that the current time must be within the start/end time of those RRSIGs. That might not be close enough for your needs, but may be enough to further validate the root key. (If it is, validate it before continuing.) Next, consider what needs to happen for TLDs that update very frequently. When they update, their SOA SN needs to change. And, if they are signed zones, the SOA record's RRSIG needs to be generated when this happens. Using the start date/time of such an RRSIG on the SOA for such a zone, should give a pretty good value for the current time, to at least an accuracy of a couple of minutes. This may be good enough for DNSSEC purposes. (If you do use RRSIG timestamps, be sure to validate the RRSIG first before trusting the values on the timestamp!!!) While horribly kludgey and mildly evil, it does get an answer that is reasonably trustworthy, moderately accurate/precise, and only uses DNSSEC. (It borrows the main idea from using GPS for clock as well as position.) Brian On Mon, Jan 31, 2011 at 5:44 PM, John Bashinski <jb...@cisco.com> wrote: > On 2011-01-31 14:32, Joe Abley wrote: > > > Time > ==== > >> 3.1 Initial State >> [...] >> A validator must confirm that its local clock is sufficiently >> accurate before trust anchors can be established, and before >> processing of DNSSEC signatures can proceed. Discussion of timing >> considerations can be found in Section 4. > > How? > > I know I brought it up, but I'm getting a little nervous about using the > home router as the only reference point. Nonetheless, it's a good > paradigmatic case, and I'll go with it for now. You're a home > router. You've just been plugged in, either new from the box or after > being in a closet for a long time. > > > The state of the art in enterprise networks is *unauthenticated* NTP > with internal hosts. The state of the art in consumer is unauthenticated > NTP with a pool on the public Internet. > > This is a huge problem for us with bootstrapping all kinds of crypto > protocols, actually, not just DNSSEC. There's this pervasive assumption > that the time of day is not only known, but known with such certainty > that it can be trusted to ensure the security of systems that are > otherwise engineered to take CPU-aeons to compromise. The problem is > that it's just not an assumption we know how to meet. > > In a lot of cases, we just end up having to assume that keys are valid > from the beginning of time to the end of time. I'd very much like to not > have that be true, but I don't know how to fix it. > > I could imagine a distributed system of digital notaries and time > stampers that at least let you establish that it was "no earlier than" > some particular time, and that also gave you some assurance that some > set of past events had happened in a particular sequence and within > particular time parameters. You could build that with mutually > distrustful "authorities", and use a quorum or something to prevent any > one of them from messing it up. I think that sort of thing is (part of) > what Phillip Hallam-Baker is getting at. But I'm not sure we can deploy > it sanely in time to be useful for this application... and I don't > think you can build *anything* that lets you detect lies about the > time if an attacker controls *all* your communications. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
