On Sun, Aug 14, 2022 at 5:25 PM Hal Murray <halmurray+...@sonic.net> 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
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls