[TLS] Getting started, clock not set yet

Hal Murray <halmurray+tls@sonic.net> Tue, 09 August 2022 04:40 UTC

Return-Path: <halmurray+tls@sonic.net>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58D2AC15948C for <tls@ietfa.amsl.com>; Mon, 8 Aug 2022 21:40:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f_FalxFwdVNC for <tls@ietfa.amsl.com>; Mon, 8 Aug 2022 21:40:39 -0700 (PDT)
Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08AB2C14F735 for <tls@ietf.org>; Mon, 8 Aug 2022 21:40:39 -0700 (PDT)
Received: from 107-137-68-211.lightspeed.sntcca.sbcglobal.net (107-137-68-211.lightspeed.sntcca.sbcglobal.net [107.137.68.211]) (authenticated bits=0) by c.mail.sonic.net (8.16.1/8.16.1) with ESMTPSA id 2794ebQ0004635 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Mon, 8 Aug 2022 21:40:38 -0700
Received: from hgm (localhost [IPv6:::1]) by 107-137-68-211.lightspeed.sntcca.sbcglobal.net (Postfix) with ESMTP id 8332328C1CA; Mon, 8 Aug 2022 21:40:37 -0700 (PDT)
X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.7.1
To: tls@ietf.org
From: Hal Murray <halmurray+tls@sonic.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 08 Aug 2022 21:40:37 -0700
Message-Id: <20220809044037.8332328C1CA@107-137-68-211.lightspeed.sntcca.sbcglobal.net>
X-Sonic-CAuth: UmFuZG9tSVYvY6CmyRZkzhLkauut9DKIVy6T5iD+SfVjY8xY/065D6gMA3Rkf8OmNurBDFRebK5JIV6cmHHtjk9aBC5x50vSMVA7AFrtk0g=
X-Sonic-ID: C;liMzap0X7RGvaydyR+6Zsg== M;dnlhap0X7RGvaydyR+6Zsg==
X-Sonic-Spam-Details: -1.5/5.0 by cerberusd
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/L-F4jMYuPkek7c4AoFN1Q0jQSG0>
Subject: [TLS] Getting started, clock not set yet
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Aug 2022 04:40:43 -0000

I work on NTP software.  NTS (Network Time Security) uses TLS.

Many security schemes get tangled up with time.  TLS has time limits on 
certificates.  That presents a chicken-egg problem for NTP when getting 
started.

I'm looking for ideas, data, references, whatever?

Is there other work in this area?
Is there any sort of consensus on how close a clock needs to be when checking 
certificates?

At this point, I divide the problem into 3 chunks.

The first case is easy.  I'll call it the RTC case.  Most PCs, laptops, and 
servers have some sort of battery backed clock.  As long as it is close 
enough, everything just works.
  But how close is close enough?
  You need a plan for when the battery dies and such.
    Set the clock from the BIOS.
    ssh in and set the clock.  That requires setting up the ssh keys ahead of 
time.

The second case is something like a Raspberry Pi.  They don't have RTCs.  
Debian has a fake-hwclock module that writes the time to the disk every hour.  
I call this the one year case.  What happens when you leave it on the shelf 
for a year?
  Certificates are generally available with only a 1 year lifetime.  That's 
built into popular browsers so everybody else gets stuck with the decision.
  After a year, nothing works.  After 6 months, half of your servers should 
still work.
  A vendor could setup 2 servers with their certificates 6 months out of phase 
so that 1 will last at least a year.

Note that games and IoT gear sold through retail channels will hit this 
problem if they sit on a shelf for a year.


The really hard case is the 10 year problem.  Consider a spare board sitting 
on the shelf for 10 years.  That's longer than batteries will last for RTCs.  
Phone companies used to work on this time frame.  I think we need to provide 
them guidance.  I've seen two ways.
  One is to manually set the clock somewhere in the replace-the-board process. 
 I'm picturing a USB port where the technician can plug in his laptop.  The 
laptop can set the time.
  The other is to use a certificate with a long lifetime.  Are those available 
or does that turn into a self-signed certificate?

There is also DNSSEC.  I don't know anything about that yet.  For the 1 year 
or 10 year cases, you could "cache" the data in /etc/hosts.  Then you need a 
cron job to keep the cache up to date.

Does this make sense?  Am I on the right track?  ...



-- 
These are my opinions.  I hate spam.