Re: [Ntp] Protocol and Security Enhancements for the Network Time Protocol (NTP)

James Browning <jamesb.fe80@gmail.com> Tue, 27 April 2021 15:01 UTC

Return-Path: <jamesb.fe80@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 C2D6D3A0E81 for <ntp@ietfa.amsl.com>; Tue, 27 Apr 2021 08:01:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.848
X-Spam-Level:
X-Spam-Status: No, score=-1.848 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_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IuRPjpXkeLRQ for <ntp@ietfa.amsl.com>; Tue, 27 Apr 2021 08:01:48 -0700 (PDT)
Received: from mail-yb1-xb2e.google.com (mail-yb1-xb2e.google.com [IPv6:2607:f8b0:4864:20::b2e]) (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 37FE23A0E82 for <ntp@ietf.org>; Tue, 27 Apr 2021 08:01:48 -0700 (PDT)
Received: by mail-yb1-xb2e.google.com with SMTP id i4so32150976ybe.2 for <ntp@ietf.org>; Tue, 27 Apr 2021 08:01:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zC09GyPXlLBeOvH0gVgHKWGGqmE63nTIDeMDw45AIqo=; b=jRM+UpiONcz6t94iS//4S2xEG3fjFJsA0+Rpr1WZSBvmJy3hW2VOcguR0KNHGcI13m hg4aDJ+R9ZUHOi/JbGzLDBLlnUsQoIKj29Jo3lrvKSRYJcri+RsAwkRB1/dx4W1x4OyO o3c4rT8k9ZuYM4OEZjNzigl87dIp5IFaWweVfJhjjE5fpF5ymHbEJpk5CkjI524oC+w+ oUkll22kmC9f3R0zoRMGSMg9O0CXGM99p9e84HWCIkjw9Y0s/m1pjHxGhv9/DWPxTXho NQ4u1Dnv0+BkPPC8IvD+8c29Kja7346UooCpeKkt6MCdmPu0u04pXQ06lftgzcqKldsK XEBQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zC09GyPXlLBeOvH0gVgHKWGGqmE63nTIDeMDw45AIqo=; b=VyQ03zvRL13xdhjOhkW7q0bvJHw1j+ARO6gSkQJHHKjPdjDa6AeQ6qj5etCZD2PrhO vf3M9GrCBQbnND1lJMfDTnPDTS+8RcS3hz0yRzNkonfpYwcP5zaN1OTDyS6w93DnkM1Y bCmNTuGgMt0xkHEQSYbhdcgU4q+hx5ncQ7448bKqadoKNSD44ixVh4V9S4dsgHrYNLN9 oSsaa1dJRQRwfLyXcVpsjbao9s1WYtbNAXRV7T44t0FIw7XEQpKMFaqjZtoBgjaKTPXw KADY8tI1DEMrh/zml0/PqYEPFdqGxgX5joIUAVX9MM4K8rtKL6r3lqXBr2VWDm6FcUgC IwAA==
X-Gm-Message-State: AOAM5312rrVMHBXKBmcNE0kbivVm40/bi2LIX7l0YOtGrSGP2+bC0U6K 4jrPmg6n5EOJT1iMh0C4UDWTlFOFAuQmBJGnlUwuLnuRKlj4
X-Google-Smtp-Source: ABdhPJyEKex15hRHxyUkDWi4HaAKo6NwFeQizYPAG5f+Df/HTWiO+QUByBZzCqHUCM4MiwK2VmKL6h1G7BGtkDsOb5E=
X-Received: by 2002:a25:b44d:: with SMTP id c13mr33282082ybg.86.1619535706259; Tue, 27 Apr 2021 08:01:46 -0700 (PDT)
MIME-Version: 1.0
References: <61c01bcb-0f07-27e0-f809-1bee2aa31f71@Udel.edu>
In-Reply-To: <61c01bcb-0f07-27e0-f809-1bee2aa31f71@Udel.edu>
From: James Browning <jamesb.fe80@gmail.com>
Date: Tue, 27 Apr 2021 08:00:00 -0700
Message-ID: <CAFTY+dBwFywJX24zqEkP5uEP9sR2bjwhvO41tVXCyTewZ_92VQ@mail.gmail.com>
To: NTP WG <ntp@ietf.org>
Cc: David Mills <Mills@udel.edu>, James Browning <jamesb.fe80@gmail.com>
Content-Type: multipart/alternative; boundary="00000000000079051a05c0f58ac6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/MKDSGKIzwUU_jzOPM5xeBI3dkrc>
Subject: Re: [Ntp] Protocol and Security Enhancements for the Network Time Protocol (NTP)
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: Tue, 27 Apr 2021 15:01:50 -0000

Many weeks late and totally lacking funds here are some comments I made
while reading through the autokey3 document  and mostly not understanding
it. Also, I am clear as mud.

= begin dump =

pre didn't I hear some apocryphal thing about Asimov actually hating the
three laws a going out of his way to try and prove they were flawed and got
annoyed that people associated them with him.

2.1 Is fragmentation and consequences eeevil or just annoying...
    reserve type/length? zero for legacy crap mac please not. shove into an
extension.
    Ah, no critical bits no errors...
    a type 3 instead of just request/response the dogleg...

2.2 no server persistent state you say...
    it does not shove persistent bits of the state info into the keys
list...

2.3 interesting choices using RSA and SHA[23] in 256-bit modes isn't RSA256
kind of weak sauce though.

3.2 usually DNS and PKI are available.
    what onwire proto tests? association keys?

3.6 root nodes not singular, or ntp-tree not network initially
    topology changes due to hosts getting their act together (only early?

4.  re-order 'format, private key, and onwire' to 'format, onwire, private
key'
    Ah, checking the signing before checking the contents.

4.1 see 2.1 remarks for snark about legacy MAC crap

4.2 thought it was 1-65535? I thought key 0 was reserved as a not a key?
    invasion from foreign nationals?
    append to 4
    expire autokeys after N time unused >35minutes probably
    expire autokeys after O longer time even if used >1week
    I don't think there is a SHA160

4.3 should it be earlier than the current outstanding packet unless P-random

433 totally unrelated top NTS I am sure

4.4 ensure? Yes, I am sure I noticed that thing from autokey in your notes
I never read.

4.5 it is so easy to create and set new variables in compiled code.
    Also not well explained to me, but I are dum

451 what is skew again? expressed differently, please

452 compiled code, not script
453 sigh "

461 wordy and clear as mud to me

462 protected by mac not 'NAC', and I think annoyingly many rounds.

463 gethostname, not gethostbyaddr which is so wrong and deprecated. not
even partially qualified, pool unfriendly?

465 reject anything more than panic in the future and less than 2**(poll-1)
in the future.

5.3 the rub is that the lack of saved state really means the state is
pushed to mismanaged global state space

5.4 memory resources are scarce? maybe associate bloom filters for each
step and reset them periodically

5.5 no mention of people using the IERS leap file?

a.1 not just the globe random() function I suppose a Mersenne twister prng
is too hard. urban dogfights?

a.7 so much wrong... MRU by default starts at 37 entries and increases by
37/38 entries to a maximum of 9532ish. which can/should be adjusted in the
config file. furthermore, at 3000 distinct peers per second, the MRU list
starts growing in about a quarter of a second (not tens of seconds) and a
reasonable MRU size will be at least 3,072,000 which would chew up a
whopping 300MB of ram.

b3 shitting on NTS will not make autokey3 grow and may well have to
opposite influence.