Re: [DNSOP] Practical issues deploying DNSSEC into the home.

[Joe Abley <[e-mail]>]

On 2013-09-11, at 11:43, Phillip Hallam-Baker <[e-mail]> wrote:

> OK lets consider the trust requirements here.
> 
> 1. We only need to know the current time to an accuracy of 1 hour.

[RRSIG expiration times are specified with a granularity of a second, right?

I appreciate that most people are generous with signature inception and expiration times in order to facilitate clock skew on validators, but I think "1 hour" needs some qualification.]

> 2. The current time is a matter of convention rather than a natural property. It is therefore impossible to determine the time without reference to at least one trusted party.
> 
> 2a) A trusted party that asserts that the current time is set to a date in the future can perform a denial of service attack on a relying party but one that is easily detected.
> 
> 2b) It is a simple matter for the trusted party to provide a signed assertion that the current time is after the Date-Time X. The hard part is ensuring that the relying party can access an up to date version of the current time assertion.
> 
> 2c) DNSSEC already provides an abundance of such assertions. If the signatures on the .com zone are claiming a date in the future then the whole viability of DNSSEC collapses. 
> 
> 3) A relying party thus requires a demonstration that is secure against a replay attack from one or more trusted parties to be assured that the time assertion presented is current but this need not necessarily be the same as the source of the signed time assertion itself.
> 
> 4) In the case of DNSSEC the window of vulnerability is actually fairly small since rewinding the time to a date in the past only helps an attacker if they had compromised the system on that date.

[or if they had intercepted, stored and replayed a signed response at a later time when the current response would be different]

> The real design decision is who you decide you are going to rely on for (3). TLS is proof against replay attack due to the exchange of nonces. 

I think that's deeper than where we are right now. Before we consider mechanisms for gauging the accuracy of a local clock, we need consensus on the general approach, e.g. the state machine implied by draft-jabley-dnsop-validator-bootstrap or something different but analogous.


Joe