IETF Logo Mail Archive

Re: [Ntp] I-D Action: draft-ietf-ntp-update-registries-09.txt

Hal Murray <halmurray@sonic.net> Thu, 07 December 2023 08:24 UTC

Return-Path: <halmurray@sonic.net>
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 0BB14C137366; Thu, 7 Dec 2023 00:24:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Level:
X-Spam-Status: No, score=-2.106 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, 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=sonic.net
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 aYB5e73j8BNB; Thu, 7 Dec 2023 00:24:46 -0800 (PST)
Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (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 D7257C14F75F; Thu, 7 Dec 2023 00:24:45 -0800 (PST)
Received: from 107-137-68-211.lightspeed.sntcca.sbcglobal.net (104-182-38-69.lightspeed.sntcca.sbcglobal.net [104.182.38.69]) (authenticated bits=0) by c.mail.sonic.net (8.16.1/8.16.1) with ESMTPSA id 3B78OhXk011871 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Thu, 7 Dec 2023 00:24:43 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sonic.net; s=net23; t=1701937485; bh=sTdCYbd5Js2OpXVEhCTj+bGC5eUBgYS3adRGdyAx2j4=; h=To:From:Subject:Mime-Version:Date:Message-Id:From:Subject; b=3DlMDtbuobWgBBUPQXIb9Z57qP+IJrs/ZY2PDw+iyZdaVfBs/6rVgTPC8HG06a5LZ Ff+7yun2FqRtmBWVxhNR+Y32GSxx6O/KDahDMEujSh20OJO+HXhIR/xvSYLncS48v1 cOFZwr71ouI2ikRkXLrMEG+lYZS4Eb2+WtoswXgoIMQqtD1SMZ6wMVxdSbmsZvgOyd v6MWpqkFSu/fV/a4ZxDP87WwFGaaitzzzJVeUmbeDDIdr68nsJBtKEJpyLb82Jlb/a W5UJAbBd26sUwluwktTwKOtpQqGIHw+ARbpsGuGHATfOzrE88aII3t+s5nyJWKGT97 MkL1Zbggs0U/w==
Received: from hgm (localhost [IPv6:::1]) by 107-137-68-211.lightspeed.sntcca.sbcglobal.net (Postfix) with ESMTP id 8C0B728C1C3; Thu, 7 Dec 2023 00:24:43 -0800 (PST)
X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.8
To: "Windl, Ulrich" <u.windl@ukr.de>
cc: "Salz, Rich" <rsalz=40akamai.com@dmarc.ietf.org>, Hal Murray <halmurray@sonic.net>, "ntp@ietf.org" <ntp@ietf.org>
From: Hal Murray <halmurray@sonic.net>
In-Reply-To: Message from "Windl, Ulrich" <u.windl@ukr.de> of "Thu, 07 Dec 2023 07:10:23 +0000." <f519a82b72f943188cd02935c983d576@ukr.de>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 07 Dec 2023 00:24:43 -0800
Message-Id: <20231207082443.8C0B728C1C3@107-137-68-211.lightspeed.sntcca.sbcglobal.net>
X-Sonic-CAuth: UmFuZG9tSVZ9nxscjenPPYBQdIsHD6JDWxEXOxxvr1566Z55yEiXxUt+MCs8PQltt0GVzY2FRdvenePTlIZN5hb1fxYj7tOTodTWd413bKY=
X-Sonic-ID: C;/KjyEtqU7hGm8S5nR+6Zsg== M;7swJE9qU7hGm8S5nR+6Zsg==
X-Sonic-Spam-Details: -1.5/5.0 by cerberusd
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/Kz5PSC7VUxHHdodzrk-h7CB9xjU>
Subject: Re: [Ntp] I-D Action: draft-ietf-ntp-update-registries-09.txt
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: Thu, 07 Dec 2023 08:24:50 -0000

Ulrich Windl said:
>       In NTPv4, one or more extension fields can be inserted after the
>       header and before the MAC, which is always present when an
>       extension field is present." 

I believe that's a bug in RFC 7822.



I think there is another one, section 7.5.1.1

> If the extension field requires a MAC, the extension field specification MUST
> define the algorithm to be used to create the MAC and the length of the MAC
> thus created. An extension field MAY allow for the use of more than one
> algorithm, in which case the information about which algorithm was used MUST
> be included in the extension field itself.

In modern practice, there is no need for the algorithm on the wire.  When you are setting up a shared key, in addition to the keyid and key itself, you have to agree on the algorithm.


-- 
These are my opinions.  I hate spam.

v2.39.1 | Report a Bug | By Email | System Status