Re: [TLS] Getting started, clock not set yet

[Kyle Rose <[e-mail]>]

On Sat, Aug 13, 2022 at 11:16 PM Hal Murray <[e-mail]> wrote:

> > IIRC, this is one of the main arguments for advancing Roughtime:
>
> I took a look at draft 06.  I don't see how it helps.  Am I missing
> something?
>
> Here is the key section:
>
> 6.4 Validity of Response
>   A client MUST check the following properties when it receives a
>   response. We assume the long-term server public key is known to the
>   client through other means.
>
> If I can distribute valid long-term keys, I can use them to sign the
> certificates for NTS-KE servers and don't need Roughtime to get started.
>

It's been a few years, but IIRC my thinking was that the degree of trust
required in the Roughtime servers' long-term public keys is very low:
you're trusting them only for one server's assertion of the current time,
not for general web traffic; and if you ask enough servers, the likelihood
of being tricked into trusting a bad timestamp is very low even over long
time periods.

Such an attack would require both access to a large number of long-term
private keys whose public keys are embedded in the client attack target, as
well as the ability to intercept traffic intended for each of these servers
at whatever moment the client initiates the Roughtime protocol (which
probably implies a long-term undetected network presence). This is clearly
a higher bar than simply trusting a web PKI certificate signed some
indeterminate time ago without respecting the expiration date and without
being able to update CRLs on startup (which also poses trust anchor turtles
all the way down).

In other words, much of the security of the scheme is in the practical
difficulty of mounting a successful attack even if the keys have been
compromised. NTS doesn't even attempt to address this kind of attack vector.

Kyle