Re: Practical issues deploying DNSSEC into the home.

[Joe Abley <[e-mail]>]

On 2013-09-10, at 12:58, Michael Richardson <[e-mail]> 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