Re: [Ntp] NTP Extensions (was Re: Last Call: <draft-ietf-ntp-using-nts-for-ntp-22.txt> (Network Time Security for the Network Time Protocol) to Proposed Standard)

Watson Ladd <> Wed, 19 February 2020 22:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B1ED912083B for <>; Wed, 19 Feb 2020 14:51:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id U5s5Kki10VLI for <>; Wed, 19 Feb 2020 14:51:00 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::82a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6852E120833 for <>; Wed, 19 Feb 2020 14:51:00 -0800 (PST)
Received: by with SMTP id d9so1495626qte.12 for <>; Wed, 19 Feb 2020 14:51:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=2m50/D1lUbyr0U8sr3MxCTUe/yIA7kd23dJbyAmoRRI=; b=Jkap0mRU6/Hh9vZ2LxGTyfCtUeK2QvQusncdRg1SNQm0KxWFSEDo5OLQFIE1h6/H1z j57Pvl+gwU09hHYq11dx8ezUG0BPmsv0IofoziPdi42GZr3DmdnqO7JosbsjU1FnACMU 6/F77xRsGKcQjEC0pMQUmsqExWnwZ+h1tV71c=
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:content-transfer-encoding; bh=2m50/D1lUbyr0U8sr3MxCTUe/yIA7kd23dJbyAmoRRI=; b=nE5ePLUqiad0met2L1cYOnmG2Kh0pTWmbDtyRJ/vjQTyiXMHGVPGM4vnPhb2Z9RZDC vlVLz6pVhrdiLhpmw+CImQ43P9+vhV0PAq23morBASAS/yD8dkEoqS2G7lG9cSNQxYlZ YQNAFzUVWYB0dvnFk1tRtRP9Bg/fg3KRZni/cU3VMLwAYtQjw8cqCcWJFxRrSG+TNiVN nbtlCkt5HJ7V+U3dZjtOqWHyhC+MlT55AuKQNLX/ir8lUtb9vf8j5FcyN/wYBypFIOH1 69QYS0oe28h69WRIR0Xu2ALElcjHKhVxa7UuC2cbixQtJLirviFTk+SrGWKyMyJFeJQa uyLQ==
X-Gm-Message-State: APjAAAUXfuoU4qDEFbheEC0cIWKbcXbVKFjI41CZNqkNXYs90CD49Qjp mYzP+7shTnfi9UOZorDbur5kTZC+iM2xJ/vFBdJJkw==
X-Google-Smtp-Source: APXvYqx9hSQL8O3Py5LhApYWGR1fOWrXqtA+7DsxhdawINrY7ItDOkuyaarboljw+BaE2etdHla07Fb4XSoqrUr72mY=
X-Received: by 2002:ac8:4c89:: with SMTP id j9mr24436169qtv.29.1582152659362; Wed, 19 Feb 2020 14:50:59 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <> <>
In-Reply-To: <>
From: Watson Ladd <>
Date: Wed, 19 Feb 2020 14:50:48 -0800
Message-ID: <>
To: "Karen O'Donoghue" <>
Cc: NTP WG <>, Harlan Stenn <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [Ntp] NTP Extensions (was Re: Last Call: <draft-ietf-ntp-using-nts-for-ntp-22.txt> (Network Time Security for the Network Time Protocol) to Proposed Standard)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 19 Feb 2020 22:51:03 -0000

On Wed, Feb 19, 2020 at 2:28 PM Karen O'Donoghue <> wrote:
> We have had conversations about this in the past and a couple different plans to move forward, but we have struggled to get final consensus on any of them. As Harlan indicated we had an initial agreement based on early drafts of NTS; however, time moved on, the NTS draft went in a radically different direction that where it started, and those agreements never gained the full consensus of the working group. So, we are where we are now, and we need to figure out how to efficiently and effectively move forward.
> Specifically with regard to the NTS draft...
> We can do two things:
> 1) Quickly come to consensus with the implementers, authors, and working group on an update to the IANA considerations text that we can add between IETF Last Call and the IESG vote.
> 2) Do nothing and let the IANA folks do what they will... (do you really want this to happen?!?)

Looking at the source the numbers are
const EXT_TYPE_UNIQUE_IDENTIFIER: u16 = 0x0104;
const EXT_TYPE_NTS_COOKIE: u16 = 0x0204;
const EXT_TYPE_NTS_AUTHENTICATOR: u16 = 0x0404;
which I think are the ones that came out of conversation with Harlan
according to his email above.

But I'm fine treating these as experimental points and having
different ones in the RFC, although it's slightly less work for me if
we don't do that. In the future I strongly feel we need an
experimental range and need to expect that points outside the range
will be allocated as drafts advance.