Hi Hal, Thank You for the reply. See inline.
>> [I'm answering your questions, not commenting on the text in the draft.] >> >> I think this needs some clarification. Because, AFAIK NTP and NTS does >> not require the client to have prior knowledge of the time either, right? > > NTP works fine without any prior knowledge of time. It is not secure. > > NTS uses TLS. TLS uses certificates. Certificates have not-before and > not-after > times. > > NTS as currently deployed piggybacks on the web certificate infrastructure. > Standard software update procedres keep the root certificates up to date. > > Certificates from Lets Encrypt have 90 day lifetimes. I think you get a year > or > two if you pay for certificates. I've heard that there is work to reduce > lifetimes. > I'm not familiar with the details. I think the idea is to automate updating > certificates so updating one is not a hassle, then we can phase in shorter > lifetimes which will reduce the damage if a private key gets compromised. > > My nasty case for getting time without any prior knowledge of time is a spare > gizmo that has been sitting on the shelf for a dozen years. > > NTS could get started without knowing time if we use self signed certificates > with a long lifetime. But then we have to distribute their public keys. (as > well > as run long lifetime servers.) > > Roughtime has long lifetime keys. If it gets packaged cleanly, people using > NTS > won't have to worry about getting started without knowing the time and > people running NTS servers won't have to worry about self signed > certificates. > > Note that in addition to long lifetime keys/certificates, you also need long > lifetime IP Addresses. DNSSEC needs time. Thanks for the explanation. Perhaps adding a couple of sentences on the NTS usage of TLS and certificates (read: requires time awareness) could be useful? --------- >> It does provide proof that the response was issued after the server >> received the request, but AFAIU it does not provide any proof >> regarding when the timestamp was issued. > >The timestamp came from the server. You have to trust the server. >(If not, why are you using it?) Section 3.2. talks about servers that, due to server error or intentional malfeasance, sends an error value. The signing does not prevent that, and the only way to detect it is by comparing responses from multiple servers (as described in Section 3.2). But, if you use a single server (Section 3.1), the signing won't detect a server error or intentional malfeasance, will it? Regards, Christer _______________________________________________ Gen-art mailing list -- [email protected] To unsubscribe send an email to [email protected]
