Subject: Re: [Ntp] Antw: [EXT] Re: Splitting the Roughtime draft?

From: Warner Losh <[email-masked]>
Date: Mon, 1 Feb 2021 14:40:21 -0700

On Mon, Feb 1, 2021 at 12:29 AM Ulrich Windl <
[email-masked]> wrote:

> >>> Hal Murray <[email-masked]> schrieb am 31.01.2021 um 10:06 in
> Nachricht <[email-masked]>:
>
> > [email-masked] said:
> >> I think we need to be very clear about the fact that all trust in
> Roughtime
> >> is rooted in the long‑term keys and that they are expected to be valid
> for
> a
> >> very long time indeed.
> >
> > How long is "very long"?
>
> The "industry standard" seems to be 10 years for that, while "long"
> nowadays
> is probably only two years...
>

Consumer grade stuff is like 1-2 years. But deployed, embedded gear still
needs 5-10 years depending on the segment it is in. You don't want to climb
a lot of telephone poles to redeploy every couple of years, for example...

Warner

> >
> > I've been trying to figure out how to use Roughtime to get NTS off the
> > ground
> > when the time isn't known/trusted yet.  If it needs long term keys, is
> there
>
> >
> > any advantage to long‑term Roughtime keys as compared to trusted
> certificates
> >
> > with a long lifetime?
> >
> > ‑‑
> > These are my opinions.  I hate spam.
> >
> >
> >
> > _______________________________________________
> > ntp mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/ntp
>
>
>
> _______________________________________________
> ntp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ntp
>

---

From: "Ulrich Windl" <[email-masked]>
Date: Tue, 02 Feb 2021 08:18:16 +0100

>>> Warner Losh <[email-masked]> schrieb am 01.02.2021 um 22:40 in Nachricht
> a lot of telephone poles to redeploy every couple of years, for example...

If you have to climb up telephone poles to replace keys, you have a different
problem ;-)

---

From: Warner Losh <[email-masked]>
Date: Tue, 2 Feb 2021 05:41:14 -0700

> If you have to climb up telephone poles to replace keys, you have a

Just pointing out the diversity of deployment... there are many other
embedded example with long life not on telephone poles...

Warner

---

From: Magnus Danielson <[email-masked]>
Date: Tue, 2 Feb 2021 13:50:45 +0100

Hi,

On 2021-02-01 22:40, Warner Losh wrote:
>
>
> On Mon, Feb 1, 2021 at 12:29 AM Ulrich Windl
> <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     >>> Hal Murray <[email-masked]
>     <mailto:[email-masked]>> schrieb am 31.01.2021 um 10:06 in
>     Nachricht
>     <[email-masked]
>     <mailto:[email-masked]>>:
>
>     > [email-masked] <mailto:[email-masked]> said:
>     >> is rooted in the long‑term keys and that they are expected to
>     be valid for
>     a
>     >> very long time indeed.
>     >
>     > How long is "very long"?
>
>     The "industry standard" seems to be 10 years for that, while
>     "long" nowadays
> Consumer grade stuff is like 1-2 years. But deployed, embedded gear
> still needs 5-10 years depending on the segment it is in. You don't
> want to climb a lot of telephone poles to redeploy every couple of
> years, for example...

Actual Consumer grade stuff is longer, much longer than the vendors of
it think. For many operator purposes systems can survive 15-20 years,
easily.

It's hard to set such life-spans. Some systems have much longer
life-spans, but then upgrades occurs. What we should focus on is to make
it long enough so that a upgrade over the net can occur, even if that
occurs over a low enough rate. Re-keying over the air is the way to go
long-term. Then you have the problem with long storage times, and ways
to upgrade them with keys, and override if they gone over the time.

Requirements is starting to emerge on this, and I have been pushing for
it, but it takes time before you can rely on it in such system designs.
So we will have to push both sides.

Cheers,
Magnus

---

From: "Ulrich Windl" <[email-masked]>
Date: Wed, 03 Feb 2021 08:21:42 +0100

>>> Magnus Danielson <[email-masked]> schrieb am 02.02.2021 um 13:50 in
> it think. For many operator purposes systems can survive 15-20 years,

In the times of Windows 10? They want you to install a new version every four
months it seems. That's the new industry standard.
Or Android phones: If you get two years of updates you are lucky. They expect
you to buy a new device every year.
Yes, systems can survive longer: I have an old Cherry keyboard that is over 30
years old, and it's in a better state than the HP keyboard that is just a bit
over one year old. Unfortunately you cannot buy good hardware any more, and for
the typical consumer software you get typically one update (if at all), and
bugs even when reported aren't fixed in years. Still they want you to buy a new
version annually.
What really amazes me is: What hard and software would one use for a flight to
Mars when the warranty is over before you reach Mars. Or even for cars: The car
I drive is over 25 years old (would you change your spouse every 10 years?)),
and it still works, but I found out the last year I could set the clock to was
2020. So the manufacturer didn't expect it to last that long. Well recently
they do their best that it won't happen.
Aren't we all very pleased about expiring certificates used to sign Java
applets? Recently I was examining a PC that was part of some measurement
equipment (around three years old): The software (CentOS 7) didn't see any
update for more than three years, inside it's running Windows 7 in a VM, and
there are OpenVPN certificates that will expire in two years...

Regards,
Ulrich

> life-spans, but then upgrades occurs. What we should focus on is to make

What about 10-year old GPS receivers: Do they handle the week-rollover
correctly, and did the manufacturers provide firmware updates? Guess.. they are
telling you your hardware model is obsolete...