Re: API for Certificate checking without date checks

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




Consider roughtime, arriving Real Soon Now (tm) from the NTP WG


From: openssl-users <openssl-users-bounces@xxxxxxxxxxx> on behalf of Jochen Bern <Jochen.Bern@xxxxxxxxx>
Sent: Tuesday, March 5, 2024 5:27 AM
To: openssl-users@xxxxxxxxxxx
Subject: Re: API for Certificate checking without date checks
 
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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux