Re: [Ntp] Antwort: Re: Antwort: Why Roughtime?

Daniel Franke <dfoxfranke@gmail.com> Mon, 18 December 2023 17:32 UTC

Return-Path: <dfoxfranke@gmail.com>
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 E2050C14F61D for <ntp@ietfa.amsl.com>; Mon, 18 Dec 2023 09:32:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.104
X-Spam-Level:
X-Spam-Status: No, score=-2.104 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, 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, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 e5jaQh8ab8EN for <ntp@ietfa.amsl.com>; Mon, 18 Dec 2023 09:32:18 -0800 (PST)
Received: from mail-oa1-x30.google.com (mail-oa1-x30.google.com [IPv6:2001:4860:4864:20::30]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C33AC14F615 for <ntp@ietf.org>; Mon, 18 Dec 2023 09:32:18 -0800 (PST)
Received: by mail-oa1-x30.google.com with SMTP id 586e51a60fabf-203ba1328d1so940524fac.0 for <ntp@ietf.org>; Mon, 18 Dec 2023 09:32:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1702920737; x=1703525537; darn=ietf.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=yh1XyrG0yCP+2/hdayB5poCcv7fGMGa+6726VAylJFo=; b=kC3XjInUwxN3Cbc+LM2RJtKtM10diEGk2HkZCpkMS3H7YFjCEulu13/TDpXrEJfsHC JJdDunWyvVkRMT6wrY1PoSEkIBW30YdET1h1V8iRUGF1BTpITGC/G0K3VmOHx005/6Gz qb3fizi7GXqLoYkVeBOuqtXDQ163esjn/0U0cdEXE+OQ70emdZrWHJQp6a7XFB7wvLe9 THQSjWD/81fJvJK+1PXeP9ExFTCbwQGXRz0i+FqeOz0aBEI5AUhKXy857POWOJsfF1xZ wcHk5hSJlcsnvSkWA6BZf0RDIYTuOO91w71vBjbEFuPveWGnKXIswqG3ijvG9/8ahLq4 59JA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702920737; x=1703525537; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=yh1XyrG0yCP+2/hdayB5poCcv7fGMGa+6726VAylJFo=; b=IR6ErclQH+Gbz7FeNg5ZMO1Zw9BfqhY9XXTfmp5d3bou8mo/Jb9d85DISnh34CmaXF Vd+YzlbokKyV/oK4oem6TOEi2p71p3ffhVzrLwCGweAEtZI5HBnTYYg5LuUwlBYZscLO OTEJjRzKOwFlcVLYTMqweq7l0AwADwpN79FN6M+NooPiiGaIiuZwybpm/1tDUbIjhEMT AePp3zdix60DoOuDhSPgAPsmVln9QMAegAjbX1tPiLMCQXhsL6bs3zTFxhnxJNGZ/3cc MGnuIafZyLnFghxYwzW8KFtpVsaOafkP3CggaEk7XiZI4TBmx+SiQINJoexg9i7OBwEP ejug==
X-Gm-Message-State: AOJu0Ywq5QT6Y+09j2oOQm6JnIcUBwM0xB1h59z6SnLfhgtxNZQembbV 9wDq91WXuw/rHnn2gr7uTuGHWGZDcA3Di1akeIE=
X-Google-Smtp-Source: AGHT+IHbvVmns5W7Fu4njYuRLjZixkl52XrNIWf4/bUGh1uHij99z2CKM1WJo+ulh9GJ5p7HG5eThezYQfhA5oyTnek=
X-Received: by 2002:a05:6871:7a2:b0:1fa:db9b:4080 with SMTP id o34-20020a05687107a200b001fadb9b4080mr15127686oap.22.1702920737305; Mon, 18 Dec 2023 09:32:17 -0800 (PST)
MIME-Version: 1.0
References: <20231217043500.99D6128C1C3@107-137-68-211.lightspeed.sntcca.sbcglobal.net> <OFD134C0BA.CC9AC877-ONC1258A89.0029CB64-C1258A89.002CCA3E@ptb.de> <CABrd9SSeQvpSY1JiJn3Nh9FsMFOo1Djk8nR9DoQ1EfRRdOyv7w@mail.gmail.com> <OF98298486.58B10BFD-ONC1258A89.00579D8E-C1258A89.005AE12C@ptb.de> <CACsn0c=UNN7Sz6YeboT6UrmiQ1G0heQHsLSdB+_gopT3AOThhg@mail.gmail.com>
In-Reply-To: <CACsn0c=UNN7Sz6YeboT6UrmiQ1G0heQHsLSdB+_gopT3AOThhg@mail.gmail.com>
From: Daniel Franke <dfoxfranke@gmail.com>
Date: Mon, 18 Dec 2023 12:32:06 -0500
Message-ID: <CAJm83bBg-GPA6+a7hQ6-2SPR=0yTS7vWoidEvKQFVpt5DFHd8w@mail.gmail.com>
To: Watson Ladd <watsonbladd@gmail.com>
Cc: kristof.teichel=40ptb.de@dmarc.ietf.org, Ben Laurie <benl=40google.com@dmarc.ietf.org>, ntp@ietf.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/MBmUo-eeWpbE7VJv5YmRe7mQWXU>
Subject: Re: [Ntp] Antwort: Re: Antwort: Why Roughtime?
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Network Time Protocol <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: Mon, 18 Dec 2023 17:32:19 -0000

+1: Roughtime needs to be its own thing. Trying to implement it as an
NTP extension is just going to be a complete mess.

On Mon, Dec 18, 2023 at 12:24 PM Watson Ladd <watsonbladd@gmail.com> wrote:
>
> On Mon, Dec 18, 2023 at 8:33 AM <kristof.teichel=40ptb.de@dmarc.ietf.org> wrote:
> >
> > Hey Ben, all,
> >
> > It's not, I think, so much that we missed it (Martin and I, can't speak for Hal - although he does mention the feature explicitly).
> > I think it's more that we don't believe it's as useful as others seem to think (honestly, I think this is explicitly talked about in our mail from June, too):
> >
> > I've never heard a user express that they want to be able to get false time and then report it.
> > I have heard users express that they want to get correct time.
> > Those two goals are not the same, and the logical chain leading from the former to the latter (where I'm supposed to believe someone is trustworthy from the fact that I don't currently have a report at hand about misbehavior from them) just seems far-fetched to me.
>
> I never heard users express that they wanted to catch misbhaving CAs:
> they wanted properly behaving ones. But to make them behave properly
> we created CT logs, so that instances of CA misbehavior couldn't be
> hidden. And those CT logs get monitored to ensure trustworthiness via
> similar mechanisms to Roughtime, even though most users of CT logs
> don't directly interact with those mechanisms.
>
> Likewise the possibility of detection raises the stakes for
> misbehaving servers, even if most users won't.
> >
> > And this is just exacerbated by putting it next to Roughtime's other most-advertised feature: use in bootstrapping phase.
> > If a device has just booted up and has close to zero knowledge, I think it extra unreasonable to rely on malfeasance reports that the device may simply never have gotten.
>
> Devices don't rely directly on reports, just as in the WebPKI browsers
> don't look at the contents of MDSP mechanically. However, without
> reporting vendors have no way to reevaluate the trust relationships.
> Even if this reevaluation is not instant it still limits the impact of
> a compromise.
>
> >
> > Lastly, if malfeasance reporting IS deemed an important feature by someone, I again agree with Hal that it could be put into any protocol (e.g. NTP, with an extra extension field).
> > It is definitely Roughtime's more complex feature, but it would also not be terribly much to ask of other protocols IMO.
>
> How would you put it in? Signing the response takes significantly
> longer than you want in NTS. Having a long term identity runs at cross
> purposes to relying on the WebPKI. I'm not opposed to possible
> integration but I think the security models and synchronization goals
> are pretty opposed.
>
> Sincerely,
> Watson Ladd
>
> --
> Astra mortemque praestare gradatim
>
> _______________________________________________
> ntp mailing list
> ntp@ietf.org
> https://www.ietf.org/mailman/listinfo/ntp