On 2013-09-11, at 11:43, Phillip Hallam-Baker <hal...@gmail.com> 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
