On 2013-09-11, at 11:43, Phillip Hallam-Baker <hallam(_at_)gmail(_dot_)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