Re: [Ntp] Antwort: Re: Antwort: Re: NTS4UPTP Rev 03 - Formal request for WG adoption (SUPPORT)

Daniel Franke <> Tue, 01 June 2021 20:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 41D893A2700 for <>; Tue, 1 Jun 2021 13:51:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 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_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6fdWBiuiW0BV for <>; Tue, 1 Jun 2021 13:51:21 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::102f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DB0D23A26FF for <>; Tue, 1 Jun 2021 13:51:21 -0700 (PDT)
Received: by with SMTP id k22-20020a17090aef16b0290163512accedso432469pjz.0 for <>; Tue, 01 Jun 2021 13:51:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HBzzcrBAQ+aSaN/WAQ6O69yGsQrF8pBlysMosmfyf14=; b=Vq1OQCDwVKpxsSiqG2KAFaSlxx3UKQyeBJfkBoZd7Ol6aQbgdG8KZGtktx1sAy+fZp R5u7/UOJqS1IEw5QSwbLvuwj+ahcvPRjzUSfQYyEPJznxCwWrqC4gml+sfk91vSDgPzb b71aCJ/Ow6wgyJYXm7d7AeOIHNKRku1nmf2mhyl8sP8MYo1EWIT41nsrh/vWn9N95pjX xG2ElLW035ZE4gT06VFSspVTNy3s2tDsU2wMs5nl/oxB0d2nThBbbx3DUjenOjcnrZe4 d4QqdPzg4jNnH+raxGDlNsVfMxP2gXLoDc2xFChPuvPwcUGOIgFDxtVvKYzfDhpkzejj 8Bcw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HBzzcrBAQ+aSaN/WAQ6O69yGsQrF8pBlysMosmfyf14=; b=pwUK3OM07n76L0Mal39TACsE5J3aq31w4MqKw8x5q/jIsGOMl5o/+/8StpkZ2cHWrh k9jhr/+lTzCEbgT8VdVTTI3z++Xr9uZPPvV+CGlRuNECBGnrXzfqJ4tsR60h0sTcNV+m TS8UCBbJq6QL1dQb4NngjW5dnqTTt4Lce+tDflyUJpSeHorb/lf0AkOqyGIuyRV/0koO YXSavI14IOW1yvrWg13iAkGGoLwGw1v+7zDsE2BBKxx0vihpdgwZB1Kpbx0IMPkVC+4T LsNfCPmjhZTkBiRXPvuSoo6KXM77zAa5oKUV0QCPo0pMRd+KsjJFZlHQZ11KlBFMHpgT M8yA==
X-Gm-Message-State: AOAM530PF43sCOvv+K6d/lvf3bw/CYXcru2C79Up70G1tjL1FD1ik5Po 0LaiC22FdIddEqOPN3RRqHnKg/F5xC6HQeiL58Y=
X-Google-Smtp-Source: ABdhPJzwFfPAcEOMtgg8BZ1T+LmZosG5eOZU4sveAyMZkhbgzHJIM41JEwlIX0sFrh/ZyqVGuHe3Wz8R5VFZeaOkgS8=
X-Received: by 2002:a17:90a:e647:: with SMTP id ep7mr1822194pjb.208.1622580679843; Tue, 01 Jun 2021 13:51:19 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Daniel Franke <>
Date: Tue, 1 Jun 2021 16:51:08 -0400
Message-ID: <>
Cc: NTP WG <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Subject: Re: [Ntp] Antwort: Re: Antwort: Re: NTS4UPTP Rev 03 - Formal request for WG adoption (SUPPORT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 01 Jun 2021 20:51:26 -0000

On Tue, Jun 1, 2021 at 4:49 PM <> wrote:
> I was definitely on that thread, I just didn't register this as a PTP security proposal specifically.
> It seems like this really would work just as well with GPS, or any GNSS, with any of the TESLA-secured modes (such as GPS Chimera and Galileo OS-NMA) instead of PTP.
> Or unsecured GNSS, or a radio clock like the DCF77 broadcast sender.
> It also seems like it would work with something like Roughtime instead of NTS4NTP.
> Personally, I believe this is a really important approach to follow up on.
> I'm just not sure that it is worth the effort to focus on NTS+PTP specifically and market that as a security solution for PTP... but that gut feeling could definitely be off.
> It just feels to me like it might be more interesting and fruitful (long-term) to make this into a generically applicable thing; I would be willing and able to contribute serious amounts of work to such an effort.

You're correct, the general approach of using an imprecise, secure
time source to clamp a precise, insecure one can be applied to many
combinations of the two. But the details of how to commensurate the
two timescales and compute intervals of plausibility would be
different so I'd rather just focus on one particular combination and
note the broader applicability in passing.

Do you want to be my co-author on this? I'll write the first draft.
You should rewrite the section that'll be heavy on IEEE1588-specific
details because I'll probably do a mediocre job with that, and then
you'd be welcome to expand it to cover any additional topics you think
are worth including.