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.
- [Ntp] Protocol and Security Enhancements for the … David Mills
- [Ntp] Antw: [EXT] Protocol and Security Enhanceme… Ulrich Windl
- Re: [Ntp] Protocol and Security Enhancements for … Miroslav Lichvar
- Re: [Ntp] Protocol and Security Enhancements for … David L. Mills
- Re: [Ntp] Protocol and Security Enhancements for … Miroslav Lichvar
- Re: [Ntp] DDoS meets NTP Hal Murray
- [Ntp] DDoS meets NTP Hal Murray
- Re: [Ntp] DDoS meets NTP Daniel Franke
- Re: [Ntp] DDoS meets NTP Daniel Franke
- Re: [Ntp] DDoS meets NTP Danny Mayer
- [Ntp] Antw: [EXT] Re: DDoS meets NTP Ulrich Windl
- Re: [Ntp] DDoS meets NTP Miroslav Lichvar
- Re: [Ntp] [EXT] Re: DDoS meets NTP Daniel Franke
- Re: [Ntp] Protocol and Security Enhancements for … James Browning
- Re: [Ntp] Protocol and Security Enhancements for … David Mills