On Sat, Aug 13, 2022 at 11:16 PM Hal Murray <halmur...@sonic.net> 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
