Re: [Ntp] Of Roughtime's algorithm agility, and host attestation

"Patrik Fältström " <paf@frobbit.se> Sat, 27 July 2019 06:32 UTC

Return-Path: <paf@frobbit.se>
X-Original-To: ntp@ietfa.amsl.com
Delivered-To: ntp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E1ED120020 for <ntp@ietfa.amsl.com>; Fri, 26 Jul 2019 23:32:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=frobbit.se
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QHhU9ttwk27r for <ntp@ietfa.amsl.com>; Fri, 26 Jul 2019 23:32:56 -0700 (PDT)
Received: from mail.frobbit.se (mail.frobbit.se [85.30.129.185]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5506120106 for <ntp@ietf.org>; Fri, 26 Jul 2019 23:32:56 -0700 (PDT)
Received: from [192.165.72.241] (unknown [IPv6:2a02:80:3ffc:0:9935:eb62:5781:e78b]) by mail.frobbit.se (Postfix) with ESMTPSA id 42F1F2A111; Sat, 27 Jul 2019 08:32:54 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=frobbit.se; s=mail; t=1564209174; bh=N7dmBYyXFKUrV/Q9cCAB1HPqy3KroQ5nRu9oCep5a5c=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ABLI2gtPB6UAORbE08PE6aM3PRiZpRPopXplaSDRxgx0gckqGSy4IUjCGj4M6lVvb aJF7d49reLfLWlfwVfjCRdrLI8sNZXGjDHJNflGaqI+CjFbq39yFhRVu4aR8jJuB4o KwMw+Lk4ex+CZ9GXlbFzLRNgoJTBoNx+hoEQjd+k=
From: Patrik Fältström <paf@frobbit.se>
To: Watson Ladd <watsonbladd@gmail.com>
Cc: Patrik Fältström <paf=40frobbit.se@dmarc.ietf.org>, "Salz, Rich" <rsalz@akamai.com>, Robert Nagy <rob@deepdivenetworking.com>, NTP WG <ntp@ietf.org>, Thomas Peterson <nosretep.samoht@gmail.com>
Date: Sat, 27 Jul 2019 08:32:52 +0200
X-Mailer: MailMate (1.12.5r5635)
Message-ID: <BA8BDFC0-E3C3-4E68-BCCD-C06BE19ED65E@frobbit.se>
In-Reply-To: <CACsn0cnwUe=dDuyA3QC7ODfYUdHnPZuzuAmNp7S5yG-rmq8Lng@mail.gmail.com>
References: <07725d0b-74ec-ec92-70fe-e27f0c4eee8c@gmail.com> <1564190434519110001_8FF0F819-5F81-41B3-A7F1-B4E97E22E0F7@akamai.com> <3C2EBBE8-3970-4B8C-BFE4-BB7F247EF7C3@deepdivenetworking.com> <12978B33-9014-4DF4-A372-88DBCE4BB167@frobbit.se> <CACsn0cnwUe=dDuyA3QC7ODfYUdHnPZuzuAmNp7S5yG-rmq8Lng@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=_MailMate_AC99D5CE-F149-4BE2-85CA-72889BF8A16A_="; micalg="pgp-sha1"; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/m5c3O4Bl546xeecqO8vjDkdeYI8>
Subject: Re: [Ntp] Of Roughtime's algorithm agility, and host attestation
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <ntp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ntp>, <mailto:ntp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ntp/>
List-Post: <mailto:ntp@ietf.org>
List-Help: <mailto:ntp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ntp>, <mailto:ntp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 27 Jul 2019 06:32:59 -0000

On 27 Jul 2019, at 7:58, Watson Ladd wrote:

> It seems people are misunderstanding the trust relationship here. The goal is to have publically observable, auditable performance and identities tied to that. So it makes very little sense to link these identities to another naming system, but maybe this is a better idea then it seems. In particular public keys really shouldn't change: that could permit the laundering of errors, which we very much don't want.

Ahhh...ok, sorry. I did not write enough words.

I agree with the base idea in what you write here. One should be careful on what one trust. But, one also need to base the trust on something, some root.

This can of course as some have suggested a cert for some time service one trust. Or the root CA of something else. Like root in some other naming system.

My answer was "just" responding to the question whether we should in the case some cert is stored in DNS create a new RRType, which is something I find not necessary as TLSA exists.

   Patrik