IETF Logo Mail Archive

Re: [Ntp] Antw: [EXT] Re: Quick review of WGLC for status change for draft‑ietf‑ntp‑update‑registries

Harlan Stenn <stenn@nwtime.org> Thu, 11 August 2022 10:22 UTC

Return-Path: <stenn@nwtime.org>
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 8086BC15A734 for <ntp@ietfa.amsl.com>; Thu, 11 Aug 2022 03:22:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.106
X-Spam-Level:
X-Spam-Status: No, score=-1.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RDNS_NONE=0.793, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
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 1g2jKfxN7Q2i for <ntp@ietfa.amsl.com>; Thu, 11 Aug 2022 03:22:37 -0700 (PDT)
Received: from chessie.everett.org (unknown [IPv6:2001:470:1:205::234]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 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 ABCB7C15A721 for <ntp@ietf.org>; Thu, 11 Aug 2022 03:22:37 -0700 (PDT)
Received: from [10.208.75.149] (071-084-168-128.res.spectrum.com [71.84.168.128]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by chessie.everett.org (Postfix) with ESMTPSA id 4M3NCx2kTpzMP49; Thu, 11 Aug 2022 10:22:37 +0000 (UTC)
Message-ID: <944f32df-eb15-2bc1-2f86-0cedd7037f31@nwtime.org>
Date: Thu, 11 Aug 2022 03:22:36 -0700
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.12.0
Content-Language: en-US
To: Miroslav Lichvar <mlichvar@redhat.com>, Martin Burnicki <martin.burnicki=40meinberg.de@dmarc.ietf.org>
Cc: Hal Murray <halmurray@sonic.net>, "ntp@ietf.org" <ntp@ietf.org>
References: <20220809030711.F00DC28C1CA@107-137-68-211.lightspeed.sntcca.sbcglobal.net> <8122203e-ac66-e4d7-5a52-5d053d8fa06a@nwtime.org> <YvIXDS2EkxzI0nTh@localhost> <9d304a6f-5570-0dad-d64d-b8ade71871e3@nwtime.org> <YvIthoUI7HtKpD9E@localhost> <01a9d920-3009-fdc0-07c1-68f5563bf130@meinberg.de> <YvI8RYIUNJvPI96W@localhost>
From: Harlan Stenn <stenn@nwtime.org>
In-Reply-To: <YvI8RYIUNJvPI96W@localhost>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/6hPxoxGKSutfYkTVU-jpk4XE7Bs>
Subject: Re: [Ntp] Antw: [EXT] Re: Quick review of WGLC for status change for draft‑ietf‑ntp‑update‑registries
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, 11 Aug 2022 10:22:41 -0000

On 8/9/2022 3:51 AM, Miroslav Lichvar wrote:
> On Tue, Aug 09, 2022 at 12:39:02PM +0200, Martin Burnicki wrote:
>> Of course you can have a real v4 client use autokey but send a faked v3
>> version, in which case it might get a v3 response with autokey extensions.
>>
>> I've never heard that this caused any problem. On the contrary, the high
>> level of compatibility between v3 and v4 made the slow changeover from v3 to
>> v4 very user-friendly.
> 
> It doesn't cause problems if you use a compatible client and server,
> but it's out of the specification. The client shouldn't send an
> NTPv3 request with extension fields and the server shouldn't accept it
> and respond.

V3 does not have extension fields.

Sure, somebody could make a v3 response with them, but that's out of spec.

Just like somebody can send a v3 or v4 packet and say it's v1.  That 
doesn't make it "true".

> The Windows NTP client and server use 64-byte MACs. They use NTPv3 and
> I think that is ok. There are no extension fields yet which could be
> confused with the MAC. In NTPv4 that would be a problem.

Not in my experience.

>>> That is not possible if we want to make incompatible changes in NTPv5.
>>
>> Yes, that's why I believe the acceptance of v5 will grow very much slower
>> than the acceptance of v4.
> 
> How long it took for NTPv4 to reach a majority of NTP traffic?

The time it takes is independent of the drama involved.

v3 clients talk to v4 servers perfectly well.  This has been 
demonstrated in the real world, and is also well-documented in RFC 5905.

>>> As I understand it, ntpd doesn't support 7822 yet. It is still
>>> responding to unknown extension fields with a crypto NAK.
>>
>> I still don't see why it should not be possible at the server to first try
>> to decode the new EF (chain), and if that fails, try the old format, as I
>> explained in my previous email.
> 
> It depends on the context and it's 100% reliable (e.g. due to expired
> or misconfigured keys). Messages in well-designed protocols should be
> parseable with no context.

What about 99% reliable?  Or 99.9%?  Or even 90%?

-- 
Harlan Stenn <stenn@nwtime.org>
http://networktimefoundation.org - be a member!

v2.23.0 | Report a Bug | By Email