IETF Logo Mail Archive

Re: [Ntp] NTS IANA request

"Salz, Rich" <rsalz@akamai.com> Thu, 06 June 2019 17:06 UTC

Return-Path: <rsalz@akamai.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 928D112006B for <ntp@ietfa.amsl.com>; Thu, 6 Jun 2019 10:06:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.71
X-Spam-Level:
X-Spam-Status: No, score=-2.71 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_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 vX1QoYoRTfkH for <ntp@ietfa.amsl.com>; Thu, 6 Jun 2019 10:06:55 -0700 (PDT)
Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 3D5A0120044 for <ntp@ietf.org>; Thu, 6 Jun 2019 10:06:55 -0700 (PDT)
Received: from pps.filterd (m0122333.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x56H2Fiq018022; Thu, 6 Jun 2019 18:06:54 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=RDLzd7Jtpwa45XK8ieidWcZbPjrzkxHufwNt0POQ1LE=; b=jwOG9wPUshnGBVrOOZBdK+2/9CArh/TxszY9C3RUb3PjIQ7Ku1yv/SURjttztvq5FfHE dnbOCBwLCw/qvYZi4lwOmKwYIKv3Fy6xRXjKn5vBZZ5USauF0Fbm9v3wxLA6X2rc7F1M ABU4VrMZuo47bBiQ0MDv5oAMp77KAm6BqWjUG9bSUQjtqaPIol8tGZ90L8ejzSa89aVA b/0EBEFx34v16WiGLnM7CUu1aC2T1RJbDu8INOcP7AJz9elMDOS+I9rKMD4HyIh8yp7/ TGWdU/I8VY+5NFWyoX+fD9rSefr2nbZOU6glxJKFKDJElJ0E2OQrQe0DPQQW/ehjAth2 xw==
Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19] (may be forged)) by mx0a-00190b01.pphosted.com with ESMTP id 2sy3nx0p2u-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 06 Jun 2019 18:06:54 +0100
Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x56H2nGn011846; Thu, 6 Jun 2019 13:06:52 -0400
Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint2.akamai.com with ESMTP id 2sumpxrmge-7 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 06 Jun 2019 13:06:52 -0400
Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag3mb1.msg.corp.akamai.com (172.27.123.60) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 6 Jun 2019 13:05:38 -0400
Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 6 Jun 2019 13:05:37 -0400
Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([::1]) by usma1ex-dag1mb3.msg.corp.akamai.com ([fe80::9049:d725:bf4b:d545%18]) with mapi id 15.00.1473.003; Thu, 6 Jun 2019 13:05:37 -0400
From: "Salz, Rich" <rsalz@akamai.com>
To: Daniel Franke <dfoxfranke@gmail.com>
CC: "ntp@ietf.org" <ntp@ietf.org>, "Gary E. Miller" <gem@rellim.com>
Thread-Topic: [Ntp] NTS IANA request
Thread-Index: AQHVG8LZ0GUXehnsGkKTml19uPDH4KaN5XwAgAAYU4CAAL1oAIAAY2IA//++AIA=
Date: Thu, 06 Jun 2019 17:05:37 +0000
Message-ID: <C8E4189E-E3A1-4926-AF0F-93BE9C7255C8@akamai.com>
References: <CAN2QdAH9Uh_wYSEizgYTjd4Q6VFQT+tvH8dnbPgKKc59+vEfng@mail.gmail.com> <a123d81b-4994-9e35-58eb-6845cf439f91@nwtime.org> <20190605164753.6e71fcaa@rellim.com> <03055E77-EB42-494E-A231-039C4603E256@akamai.com> <CAJm83bDYZ+vcwkhFEf2YCAVwKcSm7rEgbuB0Wwsvm5XVVAMjuQ@mail.gmail.com>
In-Reply-To: <CAJm83bDYZ+vcwkhFEf2YCAVwKcSm7rEgbuB0Wwsvm5XVVAMjuQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.1a.0.190530
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.36.104]
Content-Type: text/plain; charset="utf-8"
Content-ID: <4D6CE5CA534E8A4EB3D6978A707882AD@akamai.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-06-06_12:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=949 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1906060115
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-06-06_12:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=984 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1906060115
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/0pcCTx5mNHPXxcK1Yxgu34gNGOo>
Subject: Re: [Ntp] NTS IANA request
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: Thu, 06 Jun 2019 17:06:57 -0000

>    I'm strongly opposed to modifying NTS-KE to involve sending a STARTTLS
    as a first step of the handshake. I don't want to make a breaking
    change to a protocol that's passed WGLC and has four interoperating
    implementations in order to accommodate a protocol that has never been
    implemented and whose specification consists of three vague sentences
    in an unadopted and expired I-D.

I wasn't strongly advocating either mechanism, just trying to explain how things could share a port if that's what we wanted to do.

For the record, since I see no definition of NTP/TLS, I am in favor of assigning 123/TCP to NTS.

v2.23.0 | Report a Bug | By Email