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

2022-08-15 Thread Kyle Rose
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

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

2022-08-15 Thread Salz, Rich
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 sing

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

2022-08-15 Thread Peter Gutmann
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 par

[TLS] TLS ECDSA nonce reuse attack?

2022-08-15 Thread Robert Moskowitz
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 librar