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)

Karen O'Donoghue <odonoghue@isoc.org> Wed, 19 February 2020 22:28 UTC

Return-Path: <odonoghue@isoc.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 4A670120816 for <ntp@ietfa.amsl.com>; Wed, 19 Feb 2020 14:28:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isoc.org
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 VVMum-z4N8Lr for <ntp@ietfa.amsl.com>; Wed, 19 Feb 2020 14:28:43 -0800 (PST)
Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-eopbgr750084.outbound.protection.outlook.com [40.107.75.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 512F712029C for <ntp@ietf.org>; Wed, 19 Feb 2020 14:28:43 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JKdFGfmWIDMlJwKQcPDwXO2hYeRQ9QnXgHTQ0pSEhNdMRZyS1CbHgAVmpob5W68uC9zxuiSpchoBVbddUG+PT59Bhvc3GWRzeFj2uzuvix0j5qZ+FAgloYlMMIPC4mY85uzYLltpwmsZnn6HXAmYdpooHFFq4q4h66opW4HuENzDnAn6FSWwFIswxYpRv2/UcjKJXTDOZJ75UGvaMqR/B+IBLMYBB4LPVC7tgCVlFaSFEIWPSGbtLGFdIaqLcWiTi3/vBLy2VyGjI8pFwWsIBaicLO7AALY7ZehjtBDMkJTwI7RFcuQA3vgcdv96IDZbQUaoi5eRuGh73wFXAUV4uQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=80LIaOys3ceYM9+Es1Lak1alsY4sR00CZnsScW52hpA=; b=oJiu9Fj+eO+zGSKZLWOYohAJ/p+t8/geHdcJgWVpJZXZNyev5y1DOxDArahpYaIuE1lv5z/Nh7xwDmmitB2UFGuJDyMuJF3edP1jdV7+ywjLl+2ycari9XlF3/ffiJD9ksQjSUHR3eJswCVV7Zlttwa5+h5E5A4Fg128SXOF4qGLSiYQMe9xGm9MNin0M//DJ92vCXzwcVaTeI2mXLPKp9qP2cEyfMFGcb8V/+YqxeHqw7yKWOtBZx9uijhBRIqxPwZKAnft+LPqeSKwZpf46B8h3H32K4dpa5AK3QlUdUceMcjXmU2DHKrwgMN+4M5HWn9gXJE53Xxf/tnw/vmo+g==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=isoc.org; dmarc=pass action=none header.from=isoc.org; dkim=pass header.d=isoc.org; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isoc.org; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=80LIaOys3ceYM9+Es1Lak1alsY4sR00CZnsScW52hpA=; b=G1ow046Y6U1LOdibe8QdjIHBZFXFhSmMPRMP8IAuo2Y6XuYNKIAjdlbSXonHJ5RTe7xIkDogqUE6fBTfcobGwbIG2byvBLLTZThSYvsqw93kgsYnrtH4Iu0XDEbtUVwnYVh0ZlqUNbyX1+ieFcB2zcSC98rsGl3r3KPSOeFV7Qw=
Received: from DM5PR06MB3018.namprd06.prod.outlook.com (10.168.193.23) by DM5PR06MB2538.namprd06.prod.outlook.com (10.168.177.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2729.23; Wed, 19 Feb 2020 22:28:40 +0000
Received: from DM5PR06MB3018.namprd06.prod.outlook.com ([fe80::e8ad:b2bc:a48b:7b8]) by DM5PR06MB3018.namprd06.prod.outlook.com ([fe80::e8ad:b2bc:a48b:7b8%11]) with mapi id 15.20.2729.032; Wed, 19 Feb 2020 22:28:40 +0000
From: Karen O'Donoghue <odonoghue@isoc.org>
To: NTP WG <ntp@ietf.org>
CC: Watson Ladd <watson=40cloudflare.com@dmarc.ietf.org>, Harlan Stenn <stenn@nwtime.org>
Thread-Topic: [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)
Thread-Index: AQHV52xHFA31IVQBTESYPmdjcmambKgjENKA//+0YgA=
Date: Wed, 19 Feb 2020 22:28:40 +0000
Message-ID: <5B0C617A-F4E4-42B1-AAA6-C7585567EB97@isoc.org>
References: <20200219084813.E4C6840605C@ip-64-139-1-69.sjc.megapath.net> <F9A58B4B-25A7-4652-8963-6849DE359C5A@kaloom.com> <1582136379878.71291@akamai.com> <2acb8507-c0b5-a370-d6ab-564398ae9602@nwtime.org> <CAN2QdAEfBx_DRnqFNs+paBBPijaYfL0m0tqBS2k47q96sbe2RA@mail.gmail.com>
In-Reply-To: <CAN2QdAEfBx_DRnqFNs+paBBPijaYfL0m0tqBS2k47q96sbe2RA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=odonoghue@isoc.org;
x-originating-ip: [173.44.72.18]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 161fbf66-9f23-4324-8e5e-08d7b58b1246
x-ms-traffictypediagnostic: DM5PR06MB2538:
x-microsoft-antispam-prvs: <DM5PR06MB25386948F76701453D9E677BC2100@DM5PR06MB2538.namprd06.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0318501FAE
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(136003)(39850400004)(396003)(376002)(346002)(189003)(199004)(5660300002)(91956017)(66946007)(53546011)(76116006)(36756003)(2906002)(6506007)(2616005)(186003)(54906003)(316002)(66476007)(66556008)(66446008)(26005)(64756008)(6512007)(33656002)(81166006)(4326008)(8936002)(86362001)(15650500001)(6916009)(81156014)(6486002)(966005)(478600001)(71200400001)(8676002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR06MB2538; H:DM5PR06MB3018.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: isoc.org does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 49t1bGtSXlQLap55d7Kqtv04yetARSZzjDti8SBfggWukTJrcOAox3HhJ7Oew8ctScGedlyxsHOwXFMedxdA0cFCeVAHUrx6q/OwFRJz5IL2gvlJzistmfNHP7oUUE5fh+Yay71QQyT/7heqOBHrpwtBDkrUvHq69UnccJ0GPUYRF/ophFLvvtfibDcwmQQHsW316eo+UYt5oYB6C7hpwmonCviCLtZdL/pQmRpc2GBmdEbtE/WuiWBgTkRKD+Qj3zcdPZ55Z6q91QKJhAg16t8ASozutTeQJp2D5ROrqJmPu4sllI9j0ZyzBeP45zvDhJbf6Ai+BdK096Z9kzMfiSKeIXWiRoUZME7+OQLIOwLV9i42a7ZZvCO8zkFd2rpjT9ecMsI6HkQnj3QjwhgHomjyaRLmppv18yvkEUzPvfiM56CfCqX3B1zfHwoNvaB82gIa/K5wm/+wxgsM26//OTWd7DvIMxHMmHRBqe0LPzK6YuGKE4D3VVyfv6t+PHTDyq8SoDgJPmrRaZzO7AtsGw==
x-ms-exchange-antispam-messagedata: c8mcyqyLmtgsAhiwFV7kz9+Hnd8K1HCNXLenb93Y8TknIJMZuBymfoda4WWswZlRgifQU5dmIPJsgsKsZ92EjKX4Oy3A7bnH7zZHSQJdb6CnaWXcqA+q2OySSGYSEjadUTMy6cpQ3IrbC96qlh8Iiw==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <E9C69BEB44834E4CA61143F39C9BD197@namprd06.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: isoc.org
X-MS-Exchange-CrossTenant-Network-Message-Id: 161fbf66-9f23-4324-8e5e-08d7b58b1246
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Feb 2020 22:28:40.6060 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 3TnYnkmGFdAs9u6hnVjBRDO0zxMAMnwZ6jWADXf5w+xQP2b2PB++uqnuGi+PQhN+rdmYx2+pe86OHXFkL88vYw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR06MB2538
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/2apG_SiWD5QgPIslUO8XunR-ZPE>
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-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: Wed, 19 Feb 2020 22:28:48 -0000

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?!?)

Longer term... we could still work on a consensus document that provides additional guidance for the whole EF registry assignment discussion. I welcome such submissions and a reasonable discussion around them... 

Please let's try to work together to resolve this quickly. I'm not responding any one individual here as much as the topic... 

Karen

On 2/19/20, 4:59 PM, "ntp on behalf of Watson Ladd" <ntp-bounces@ietf.org on behalf of watson=40cloudflare.com@dmarc.ietf.org> wrote:

    On Wed, Feb 19, 2020 at 1:33 PM Harlan Stenn <stenn@nwtime.org> wrote:
    >
    > Except that we did discuss this, years ago, and there was a meeting with
    > me and Karen and I forget who else where we specifically said that
    > 0xnn04 was already allocated for NTS.  I've long been saying we need a
    > way to make progress with EF proposals that does not cause collisions
    > between inplementations and avoids flag days.  Furthermore, I told Karen
    > that the NTP Project was using 0xNN0[5-9] for other proposals and that
    > with no progress on changing the way the NTP Extension Field IANA
    > registry was being managed, that 1) the NTP Project has a chalkboard
    > that we're using for this purpose, and 2) if anybody wants to work on an
    > EF they should just let me know.
    
    The way to achieve this is to make an experimental/private use range
    for the registry. The registry is currently IETF review, which is
    annoying: it's big enough to be Specification Required unless
    proposals take large chunks of the range. It's not impossible to
    change this with WG consensus.
    
    As for avoiding flag days, early drafts are going to evolve, breaking
    backwards compatibility anyway. I've always emphasized that we are
    going to have breaking changes in our NTP service until the draft
    stabilizes, I don't see how we can get any sort of experimental
    deployment unless we're willing to break the toys. (And no, they don't
    get to keep the pieces). One solution, copying from the TLS WG, is to
    have draft version numbers in the ordinary version negotiation
    mechanism, but that's not as suitable for an extension field.
    
    We discussed a potential early allocation request at the virtual
    interim that would give us plenty of time to have implementations
    ready before RFC. There is no reason we can't all have implementations
    and deployments supporting the final RFC version and numbers when they
    come out.
    
    Sincerely,
    Watson
    
    _______________________________________________
    ntp mailing list
    ntp@ietf.org
    https://www.ietf.org/mailman/listinfo/ntp