On 05.03.24 13:00, openssl-users-request@xxxxxxxxxxx digested:
Date: Mon, 04 Mar 2024 22:22:36 -0800 From: Hal Murray <halmurray+openssl@xxxxxxxxx> Context is the chicken and egg problem of using TLS before a system knows the time. I work on NTP software. NTP uses NTS (Network Time Security) which uses TLS to make sure it is talking to the right servers. I'm trying to figure out how to get started on a system that doesn't know the time yet. (Many low cost systems like the Raspberry Pi don't have a battery backed clock.)
Someone please correct me if I'm getting something wrong, but my memory of this topic's history is as follows:
1. NTP implements "v3" crypto (symmetric keys), which works OK to this day *if* you can handle the roll-out of (<64k different) shared keys.
2. NTP releases "v4" crypto (autokey? Not sure anymore), which gets broken on short notice.
3. NTP releases "v5" crypto (I remember a crypto scheme "inspired by cable TV encryption systems" promising to have clients set themselves up automagically being one of its operation modes, never saw a HowTo that'd have permitted me to actually set up such a beast), which also gets broken a while later.
4. NTP announces that it'll wait and adopt/adapt the crypto standard now being developed for PTP (rather than making another attempt of its own), presumably getting the chicken and the egg slain for good.
5. PTP, *meant* to be communicating between switch port and server NIC (can you say "physical security"?), drags its feet on the crypto topic.
6. NTP adopts NTS, which uses TLS, and thus X.509 certificates with a validity period ... and doesn't address the well-known chicken-and-egg problem at all.
... all this to say that truly solving this problem is *very* hard, if not theoretically impossible. For practical purposes, I guess that shipping installation images / devices / ... with a rather *short*-lived CA cert (to bootstrap stuff, not only NTS but also an update mechanism having the CA cert replaced frequently) and hoping that No Key Material Will Ever Get Leaked™ (and thoroughly wiped from your servers at its end of validity) is about the best you can do.
Kind regards, -- Jochen Bern Systemingenieur Binect GmbH
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
