Re: [TLS] Getting started, clock not set yet
On Sun, Aug 14, 2022 at 5:25 PM Hal Murray 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
Re: [TLS] Getting started, clock not set yet
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. Kyle’s right. Roughtime increases the amount of work the attacker has to do by saying they must compromise multiple machines. That’s different from a single long-term key. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Getting started, clock not set yet
Kyle Rose writes: >Expired CAs are definitely a problem for PKI participation after such a >delay, but probably one that is dwarfed by the near certain existence of >known vulnerabilities in firmware that hasn't been updated in 10 years. So >it's probably best they remain air-gapped and don't participate in active >networked systems until they've been updated, which would then include new CA >certificates. Getting a bit off-track, but the ones I've encountered won't be updated, typically because there's no way to do so and/or because the software is written to a higher standard than the usual Internet-facing stuff. One common defence, although it's not really intended as such, is that there's nothing there to attack, everything is hardcoded and fixed and does just barely enough to communicate with the other side, so there's very little attack surface. >Consequently, I would not recommend any device interact with the web without >being able to establish that server certificates have not expired. Sure, but that's web use. For SCADA use you don't care (or check) whether the certificates have expired or not because that's the difference between "things work" and "things don't work": "When PLCs’ certificates expire, they just disappear off the network. Plus, 99 percent of the industrial world has no idea what a certificate is, so how do they troubleshoot the problem at 2am?" (from "Control Systems Security from the Front Lines"). I would assume this extends to lots of non-SCADA cases as well: If you want things to work, you don't check for cert expiry. Or revocation. >>Ignoring CA billing-cycle^H^H^Hexpiry dates > >You repeatedly bring up this point, but you do realize that one of the people >you're arguing with was instrumental in the establishment of a mechanism for >provisioning *free* web PKI certificates, right? The cost of procuring signed >certificates is no longer an obstacle to participating in the web PKI. Sure, and I pointed out that it was a thing for commercial CAs. In any case though I wasn't commenting on that but on why a 1-year expiration period is used, because the alternative was to point out that tying a supposed security parameter to the earth's (approximate) orbital period seems a bit paleolithic [0]. And in that case I think we should take a less geocentric view of certificate expiry and instead use the orbital period of the largest planet in the solar system, Jupiter, over 300 times the size of the earth so it's got to be more significant. Giving certificates an expiry time of 12 years to match Jupiter's orbital period should be enough to cover most use cases (extending this to Pluto, and whether it should actually be Pluto or stop at full planets like Neptune, is left as an open discussion point). Peter. [0] Based on nature-worship dating back to the Old Stone Age, I don't know whether they knew the earth's orbital period back then or not but I believe it was well known by the Bronze Age. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] TLS ECDSA nonce reuse attack?
I contact pointed me to the following: https://medium.com/asecuritysite-when-bob-met-alice/the-state-of-tls-ecdsa-nonce-reuse-1489ab86e488 The article is unclear if this is a TLS 1.2 and/or 1.3 problem. It does claim that 1.3 does not fix all problems with TLS. It also seems this is a libraries implementation problem. Lack of care in nonce selection. So I do need to get back to the person that is wanting to know, and I have come up empty in any other information on this problem. Thanks! Bob ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
