On 2013-09-10, at 12:58, Michael Richardson <mcr+ietf@xxxxxxxxxxxx> wrote: >> But I'm still thinking of a scheme involving insecure ntp lookups for >> pool.ntp.org, then using inception times of RRSIGs of TLDs to narrow >> down the current time. Of course, all of that is vulnerable to replay >> attacks. > > I think that the best bet is to just turn off the time part of the DNSSEC > validation until the time is considered sane. That's what we propose, in essence, in draft-jabley-dnsop-validator-bootstrap: 3. Summary of Approach A validator that has no valid trust anchor initialises itself as follows. 3.1. Initial State A validator in its initial state is capable of sending and receiving DNS queries and responses, but is not capable of validating signatures received in responses. 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. 3.2. Trust Anchor Retrieval Once the local clock has been synchronised, a validator may proceed to gather candidate trust anchors for consideration. Discussion of trust anchor retrieval can be found in Section 5. 3.3. Trust Anchor Selection Once a set of candidate trust anchors has been obtained, a validator attempts to find one trust anchor in the set which is appropriate for use. This process involves verification of cryptographic signatures, and is discussed in Section 6. 3.4. Full Operation The validator now has an accurate trust anchor for the root zone, and is capable of validating signatures on responses from the DNS. We specify clock sync before trust anchor retrieval because trust anchors are published in a bundle with date ranges within which they should be considered suitable for use. Clock sync before validation makes sense for reasons already mentioned. Joe