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

[Kyle Rose <[e-mail]>]

On Sun, Aug 14, 2022 at 5:25 PM Hal Murray <[e-mail]> wrote:

> Thanks.
>
> > 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.
>
> I've been assuming self-signed certificates with long lifetimes -- one per
> server.
>

It's a testament to how certificate infrastructure has evolved that one
year is now considered "long lived". :-) I was responding to an earlier
hypothetical about a device sitting on a shelf for ten years, and trying to
figure out how one could bootstrap the PKI after that time without explicit
intervention. I'm starting to think I was trying too hard to address a
(possibly contrived) edge case that really deserves a simpler solution:
manual re-bootstrapping.

> 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.
>
> Is there a first order difference between NTS using self signed
> certificates
> and Roughtime?
>

Miroslav's answer is probably the right one: Roughtime gives you the
ability not only to detect bad timestamps but to prove it to others. Upon
reflection, that doesn't seem especially useful in this context because
you're already talking about devices that have appeared out of nowhere
after a long period of inactivity.

There have been semi-endless debates about how many NTP servers to use.  (I
> haven't seen one recently.)  With 3 servers, 2 can outvote 1 bad guy. With
> 4
> servers, you still have 3 if one is down.  ...  Adding security
> complicates
> that discussion.  You have to add deliberate malfeasance to the list of
> things
> that can go wrong.  And things can change over 10 years.
>
> Are there any good papers or web pages discussing the security of TLS?
>

Did you mean NTP here? The security of TLS has been discussed far and wide.
:-)

One quirk on my 10 year problem.  If the boxes are sitting on a shelf, it's
> at
> least possible to open them up and update firmware.  It would be
> expensive,
> but it is another branch of the cost-benefit tree.
>

And this was my first bit of advice to Peter: if it's out of service that
long, it probably has known vulnerabilities, so you should probably upgrade
the firmware before reattaching it to a network or it's likely to get
pwn3d. That firmware update would come with updated CAs, and a notion of
the current time (to bootstrap the first TLS handshakes, after which
trusted sources can provide updated timestamps) if the device has no RTC of
its own.

I wish I had some more context for this area of embedded devices. For
example:

 * Why is an RTC more expensive (along whatever axis you choose) than a NIC
(wifi or ethernet)?
 * What classes of devices would reasonably sit on a shelf for ten years
and subsequently prove useful without being updated?
 * If it's been sitting on a shelf for ten years, why is reattaching it to
the network easy, while plugging it into an upgrade klosk first and *then*
reattaching it to the network is hard?

After this thread, I'm now trying to figure out why this whole endeavor
isn't contrived.

Kyle