Re: [TLS] Getting started, clock not set yet
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. > 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. Is there a first order difference between NTS using self signed certificates and Roughtime? 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? 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. Again, thanks for your helpful input. -- These are my opinions. I hate spam. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Getting started, clock not set yet
On Sat, Aug 13, 2022 at 11:16 PM Hal Murray 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 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Getting started, clock not set yet
Christian Huitema writes: >For example, the device will get some notion of time from the dates in the >certificates that are provisioned during enrollment. Maybe that's enough to >move from the 10 years scenario to the one year scenario, and then call NTP. >But it would probably be better to spell it out. That's one of several ways I've seen of getting an approximate time, if you get fed a cert with validFrom = X then you know that it's at least time X. A more common one is to use HTTP as NTP and take the time from the "Date:" line. For store-and-forward, you take the message signing time, e.g. the CMS signingTime attribute. One I haven't seen for awhile (thankfully) is to take the time in the TLS server hello, the gmt_unix_time, and use that (I never set that to anything valid so as not to expose the client or server to time-based attacks, problem was that sometimes it looked valid enough that it messed up the other side). In any case there's no need to implement yet another protocol on top of the existing ones, you can make do with what you've got - there are timestamps in so many things that you can typically find one in existing messaging. Peter. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
