Re: [TLS] Getting started, clock not set yet

Hal Murray <halmurray+tls@sonic.net> Sun, 14 August 2022 21:25 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 E73DDC14F724 for <tls@ietfa.amsl.com>; Sun, 14 Aug 2022 14:25:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level:
X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, 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 GKmWTGvYwzxs for <tls@ietfa.amsl.com>; Sun, 14 Aug 2022 14:25:08 -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 9E538C14F721 for <tls@ietf.org>; Sun, 14 Aug 2022 14:25:08 -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 27ELP6IV007424 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Sun, 14 Aug 2022 14:25:07 -0700
Received: from hgm (localhost [IPv6:::1]) by 107-137-68-211.lightspeed.sntcca.sbcglobal.net (Postfix) with ESMTP id A6A1A28C1CA; Sun, 14 Aug 2022 14:25:06 -0700 (PDT)
X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.7.1
To: Kyle Rose <krose@krose.org>
cc: Hal Murray <halmurray+tls@sonic.net>, tls@ietf.org
From: Hal Murray <halmurray+tls@sonic.net>
In-Reply-To: Message from Kyle Rose <krose@krose.org> of "Sun, 14 Aug 2022 09:35:28 -0400." <CAJU8_nWC+GRZFm02trAgB_bmUfkNF9bMfUHenVRNojydzi1NNw@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sun, 14 Aug 2022 14:25:06 -0700
Message-Id: <20220814212506.A6A1A28C1CA@107-137-68-211.lightspeed.sntcca.sbcglobal.net>
X-Sonic-CAuth: UmFuZG9tSVaJQJNvmhjSbhiTPjQkPAgyNwzRV7vfS7q1fdEOvmCa1Z88cDrF5pB/87qMtipi6E44K0clLToLMyqkjVQObUFr0rIri839k3E=
X-Sonic-ID: C;WgV+kRcc7RGH/ydyR+6Zsg== M;bPSpkRcc7RGH/ydyR+6Zsg==
X-Sonic-Spam-Details: -1.5/5.0 by cerberusd
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/QmEtgt4c-wJtQbccwHOHPFS4bbg>
Subject: Re: [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: Sun, 14 Aug 2022 21:25:11 -0000

Thanks.

> It's been a few years, but IIRC my thinking was that the degree of trust
> required in the Roughtime servers' long-term public keys is very low: you're
> trusting them only for one server's assertion of the current time, not for
> general web traffic; and if you ask enough servers, the likelihood of being
> tricked into trusting a bad timestamp is very low even over long time
> periods. 

I've been assuming self-signed certificates with long lifetimes -- one per 
server.

> Such an attack would require both access to a large number of long-term
> private keys whose public keys are embedded in the client attack target, as
> well as the ability to intercept traffic intended for each of these servers
> at whatever moment the client initiates the Roughtime protocol (which
> probably implies a long-term undetected network presence). This is clearly a
> higher bar than simply trusting a web PKI certificate signed some
> indeterminate time ago without respecting the expiration date and without
> being able to update CRLs on startup (which also poses trust anchor turtles
> all the way down).

> In other words, much of the security of the scheme is in the practical
> difficulty of mounting a successful attack even if the keys have been
> compromised. NTS doesn't even attempt to address this kind of attack vector. 

Is there a first order difference between NTS using self signed certificates 
and Roughtime?

There have been semi-endless debates about how many NTP servers to use.  (I 
haven't seen one recently.)  With 3 servers, 2 can outvote 1 bad guy. With 4 
servers, you still have 3 if one is down.  ...  Adding security complicates 
that discussion.  You have to add deliberate malfeasance to the list of things 
that can go wrong.  And things can change over 10 years.

Are there any good papers or web pages discussing the security of TLS?

--------

One quirk on my 10 year problem.  If the boxes are sitting on a shelf, it's at 
least possible to open them up and update firmware.  It would be expensive, 
but it is another branch of the cost-benefit tree.

--------

Again, thanks for your helpful input.


-- 
These are my opinions.  I hate spam.