From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Tue Aug 1 00:39:13 2017 Return-Path: X-Original-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 869EB132A7A for ; Tue, 1 Aug 2017 00:39:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 wHtTROBJtH6E for ; Tue, 1 Aug 2017 00:39:12 -0700 (PDT) Received: from lists.ntp.org (psp3.ntp.org [185.140.48.241]) by ietfa.amsl.com (Postfix) with ESMTP id CD18B132A78 for ; Tue, 1 Aug 2017 00:39:09 -0700 (PDT) Received: from lists.ntp.org (unknown [127.0.0.235]) by lists.ntp.org (Postfix) with ESMTP id 1EBE786DBB5 for ; Tue, 1 Aug 2017 07:39:09 +0000 (UTC) X-Original-To: ntpwg@lists.ntp.org Delivered-To: ntpwg@lists.ntp.org Received: from mail1.ntp.org (fortinet.ntp.org [10.224.90.254]) by lists.ntp.org (Postfix) with ESMTP id 8E89F86DAB4 for ; Tue, 1 Aug 2017 07:39:05 +0000 (UTC) Received: from mx1.redhat.com ([209.132.183.28]) by mail1.ntp.org with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1dcRlZ-000Jb2-UG for ntpwg@lists.ntp.org; Tue, 01 Aug 2017 07:39:05 +0000 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 99E287CDF5; Tue, 1 Aug 2017 07:38:56 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 99E287CDF5 Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=mlichvar@redhat.com Received: from localhost (unknown [10.43.2.117]) by smtp.corp.redhat.com (Postfix) with ESMTPS id A3DC967C91; Tue, 1 Aug 2017 07:38:55 +0000 (UTC) Date: Tue, 1 Aug 2017 09:38:54 +0200 From: Miroslav Lichvar To: Daniel Franke Message-ID: <20170801073854.GB2346@localhost> References: <707deca2-9037-c9fc-69bc-71ee80cb4c97@nwtime.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.0 (2017-02-23) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Tue, 01 Aug 2017 07:38:56 +0000 (UTC) X-SA-Exim-Connect-IP: 209.132.183.28 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: mlichvar@redhat.com X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Subject: Re: [ntpwg] NTS: DTLS and symmetric mode X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.24 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: ntpwg Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Sender: "ntpwg" On Mon, Jul 31, 2017 at 02:59:30PM -0400, Daniel Franke wrote: > On 7/31/17, Harlan Stenn wrote: > > Is DTLS well-suited for symmetric associations, which require mutual > > authentication? > > Yes. DTLS supports mutual authentication through the use of client > certificates or pre-shared keys. That will work nicely for an active-passive association, but I'm still not sure about active-active associations. You said the source port of a DTLS client is supposed to be random. How will an active peer know that an incoming connection corresponds to a peer it has already connected to or it's trying to connect to? With symmetric keys/autokey it was possible to have multiple associations with the same IP address (e.g. multiple machines behind NAT). I think a bigger problem with NTP over DTLS might be that timing messages are sent on a different port than 123 and are encrypted. This makes it incompatible with existing HW/configuration and future NTP extensions. Here is the list of issues I posted previously (with no response) [1]: - no stateless passive mode - problematic pairing of DTLS sessions - requires timestamping of messages on a new port - won't work with HW which can timestamp only packets on port 123 (or 319) - will require changes in QoS classification on routers/switches - won't work with future NTP extensions for delay corrections in routers/switches [1] http://lists.ntp.org/pipermail/ntpwg/2017-June/003307.html -- Miroslav Lichvar _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Tue Aug 1 08:04:59 2017 Return-Path: X-Original-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1AFB132197 for ; Tue, 1 Aug 2017 08:04:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 0sm_ecZ4J4i3 for ; Tue, 1 Aug 2017 08:04:56 -0700 (PDT) Received: from lists.ntp.org (psp3.ntp.org [185.140.48.241]) by ietfa.amsl.com (Postfix) with ESMTP id 682571321A6 for ; Tue, 1 Aug 2017 08:04:55 -0700 (PDT) Received: from lists.ntp.org (unknown [127.0.0.235]) by lists.ntp.org (Postfix) with ESMTP id C73E986DB62 for ; Tue, 1 Aug 2017 15:04:54 +0000 (UTC) X-Original-To: ntpwg@lists.ntp.org Delivered-To: ntpwg@lists.ntp.org Received: from mail1.ntp.org (fortinet.ntp.org [10.224.90.254]) by lists.ntp.org (Postfix) with ESMTP id 0832986DAB4; Tue, 1 Aug 2017 15:04:47 +0000 (UTC) Received: from mx1.bs.ptb.de ([192.53.103.120]) by mail1.ntp.org with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1dcYir-000DO3-Nx; Tue, 01 Aug 2017 15:04:47 +0000 Received: from smtp-hub.bs.ptb.de (smtpint01.bs.ptb.de [141.25.87.32]) by mx1.bs.ptb.de with ESMTP id v71F4ZOt002389-v71F4ZOv002389 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 1 Aug 2017 17:04:35 +0200 Received: from rose.bs.ptb.de (rose.bs.ptb.de [141.25.85.201]) by smtp-hub.bs.ptb.de (Postfix) with ESMTPS id 18F0252508E; Tue, 1 Aug 2017 17:04:34 +0200 (CEST) In-Reply-To: <20170801073854.GB2346@localhost> References: <707deca2-9037-c9fc-69bc-71ee80cb4c97@nwtime.org> <20170801073854.GB2346@localhost> To: Miroslav Lichvar MIME-Version: 1.0 Message-ID: From: dieter.sibold@ptb.de Date: Tue, 1 Aug 2017 17:04:32 +0200 X-SA-Exim-Connect-IP: 192.53.103.120 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org, ntpwg-bounces+dieter.sibold=ptb.de@lists.ntp.org X-SA-Exim-Mail-From: dieter.sibold@ptb.de X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Subject: [ntpwg] Antwort: Re: NTS: DTLS and symmetric mode X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.24 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: ntpwg , ntpwg Content-Type: multipart/mixed; boundary="===============5248941860103280414==" Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Sender: "ntpwg" This is an S/MIME signed message. --===============5248941860103280414== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha-256; boundary=-------z50291_boundary_sign This is an S/MIME signed message. ---------z50291_boundary_sign Content-Type: multipart/alternative; boundary="=_alternative 0052D03CC125816F_=" Dies ist eine mehrteilige Nachricht im MIME-Format. --=_alternative 0052D03CC125816F_= Content-Type: text/plain; charset="US-ASCII" Hi Miroslav, see my comments below. "ntpwg" schrieb am 01.08.2017 09:38:54: > Von: Miroslav Lichvar > An: Daniel Franke > Kopie: ntpwg > Datum: 01.08.2017 09:39 > Betreff: Re: [ntpwg] NTS: DTLS and symmetric mode > Gesendet von: "ntpwg" > > On Mon, Jul 31, 2017 at 02:59:30PM -0400, Daniel Franke wrote: > > On 7/31/17, Harlan Stenn wrote: > > > Is DTLS well-suited for symmetric associations, which require mutual > > > authentication? > > > > Yes. DTLS supports mutual authentication through the use of client > > certificates or pre-shared keys. > > That will work nicely for an active-passive association, but I'm still > not sure about active-active associations. You said the source port of > a DTLS client is supposed to be random. How will an active peer know > that an incoming connection corresponds to a peer it has already > connected to or it's trying to connect to? With symmetric keys/autokey > it was possible to have multiple associations with the same IP address > (e.g. multiple machines behind NAT). > > I think a bigger problem with NTP over DTLS might be that timing > messages are sent on a different port than 123 and are encrypted. This > makes it incompatible with existing HW/configuration and future NTP > extensions. > > Here is the list of issues I posted previously (with no response) [1]: > > - no stateless passive mode > - problematic pairing of DTLS sessions Daniel considered this question. He provided a discussion in Sec. 4 of the current NTS draft (version -09). > - requires timestamping of messages on a new port I don't understand the issue of this. > - won't work with HW which can timestamp only packets on port 123 > (or 319) Yes, but the vast majority of NTP servers and clients don't use HW based time stamping. Also note, that HW based time stamping is going to be difficult for mode 3 and 4 packets also. This packets are protected by NTS extension fields and HW time stamping NICs are not able to calculate the NTS AEAD information (at least currently). > - will require changes in QoS classification on routers/switches Yes, this is true. > - won't work with future NTP extensions for delay corrections in > routers/switches That is probably true. But I don't see the use case for this. Typically you apply symmetric mode in a closed environment. If you require the additional accuracy of delay corrections in router/switches you would apply PTP which already provide these features. > > [1] http://lists.ntp.org/pipermail/ntpwg/2017-June/003307.html > > -- > Miroslav Lichvar > _______________________________________________ > ntpwg mailing list > ntpwg@lists.ntp.org > http://lists.ntp.org/listinfo/ntpwg --=_alternative 0052D03CC125816F_= Content-Type: text/html; charset="US-ASCII" Hi Miroslav,

see my comments below.

"ntpwg" <ntpwg-bounces+dieter.sibold=ptb.de@lists.ntp.org> schrieb am 01.08.2017 09:38:54:

> Von: Miroslav Lichvar <mlichvar@redhat.com>
> An: Daniel Franke <dfoxfranke@gmail.com>
> Kopie: ntpwg <ntpwg@lists.ntp.org>
> Datum: 01.08.2017 09:39
> Betreff: Re: [ntpwg] NTS: DTLS and symmetric mode
> Gesendet von: "ntpwg" <ntpwg-bounces+dieter.sibold=ptb.de@lists.ntp.org>
>
> On Mon, Jul 31, 2017 at 02:59:30PM -0400, Daniel Franke wrote:
> > On 7/31/17, Harlan Stenn <stenn@nwtime.org> wrote:
> > > Is DTLS well-suited for symmetric associations, which require mutual
> > > authentication?
> >
> > Yes. DTLS supports mutual authentication through the use of client
> > certificates or pre-shared keys.
>
> That will work nicely for an active-passive association, but I'm still
> not sure about active-active associations. You said the source port of
> a DTLS client is supposed to be random. How will an active peer know
> that an incoming connection corresponds to a peer it has already
> connected to or it's trying to connect to? With symmetric keys/autokey
> it was possible to have multiple associations with the same IP address
> (e.g. multiple machines behind NAT).
>
> I think a bigger problem with NTP over DTLS might be that timing
> messages are sent on a different port than 123 and are encrypted. This
> makes it incompatible with existing HW/configuration and future NTP
> extensions.
>
> Here is the list of issues I posted previously (with no response) [1]:
>
> - no stateless passive mode
> - problematic pairing of DTLS sessions
Daniel considered this question. He provided a discussion in Sec. 4 of the current NTS draft (version -09).

> - requires timestamping of messages on a new port
I don't understand the issue of this.

>   - won't work with HW which can timestamp only packets on port 123
>     (or 319)
Yes, but the vast majority of NTP servers and clients don't use HW based time stamping. Also note, that HW based time stamping is going to be difficult for mode 3 and 4 packets also. This packets are protected by NTS extension fields and HW time stamping NICs are not able to calculate the NTS AEAD information (at least currently).

>   - will require changes in QoS classification on routers/switches
Yes, this is true.

> - won't work with future NTP extensions for delay corrections in
>   routers/switches
That is probably true. But I don't see the use case for this. Typically you apply symmetric mode in a closed environment. If you require the additional accuracy of delay corrections in router/switches you would apply PTP which already provide these features.

>
> [1] http://lists.ntp.org/pipermail/ntpwg/2017-June/003307.html
>
> --
> Miroslav Lichvar
> _______________________________________________
> ntpwg mailing list
> ntpwg@lists.ntp.org
> http://lists.ntp.org/listinfo/ntpwg
 --=_alternative 0052D03CC125816F_=-- ---------z50291_boundary_sign Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIIp0gIBATEPMA0GCWCGSAFlAwQCAQUAMAsGCSqGSIb3DQEHAaCCJsYw ggOfMIICh6ADAgECAgEmMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNE ZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYD VQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw05OTA3MDkxMjExMDBaFw0xOTA3MDky MzU5MDBaMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYD VQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJv b3QgQ0EgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKsLozXgiykUsRSFrzwQ5Dlv NV1Krt3qYY2VSfRvZKMaYGakqUAihNnUpeV4kw5oAa25TVw6ztO4qEJA38+juoJZapIbrBya2ggr JSf5aSNH8eDrLHqb9RMC0H40fMKePABZq/XaDPUyPCusUNrWw96DlMqoDJkyDghIVltq+9rhWFgB SV9yQTwVBgGOXa2quJO0zZ7rp+hqLVI02zrvXHVR2tvzMfnucZgyxFQVRAz5m1Xtrd8YCKCjhopJ 7lMFjxlM1d5YeZvSahxCq8XVp89oD5bk4WGYdmHIkXzWPgDikVCH4Z0K5q2X0h3GOn3LvNoDNNWO WwH1age3FrZuSn8CAwEAAaNCMEAwHQYDVR0OBBYEFDHDeRu69VPXF+CJei0XbAqzK50zMA8GA1Ud EwQIMAYBAf8CAQUwDgYDVR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBBQUAA4IBAQCUZFmtOWTnKesT /lrDixNXyAQk8HR3wGDjZ/vpiaaDv5aCfG7Uwz3vnoBuuym0mHqxO1TrORdHfhqOC/wfMVkxBLLO F/Msx2I2VeIi2IlVtJhIqmT61hw22ER4WlojOleX9XowT66fakxLK46gA+M+4KnU0nvSs6jicjyt nv+AWeSbRbT2O7DNORmYMuXqIWGQ5DEhjjSx9y81SoUQ2ueKNyG+WWPg8oWIMVPUVBSFcHn0LgZ3 J3UvH7iK+f7Futg25IPs52W3v2Na80avgZQ31EGM1iPWHs/1aBtEY6Jauqc1WaHlcAWbDiNXmZQK bbo5YyiGkvMYhNj70c8FVmRXMIIDnzCCAoegAwIBAgIBJjANBgkqhkiG9w0BAQUFADBxMQswCQYD VQQGEwJERTEcMBoGA1UEChMTRGV1dHNjaGUgVGVsZWtvbSBBRzEfMB0GA1UECxMWVC1UZWxlU2Vj IFRydXN0IENlbnRlcjEjMCEGA1UEAxMaRGV1dHNjaGUgVGVsZWtvbSBSb290IENBIDIwHhcNOTkw NzA5MTIxMTAwWhcNMTkwNzA5MjM1OTAwWjBxMQswCQYDVQQGEwJERTEcMBoGA1UEChMTRGV1dHNj aGUgVGVsZWtvbSBBRzEfMB0GA1UECxMWVC1UZWxlU2VjIFRydXN0IENlbnRlcjEjMCEGA1UEAxMa RGV1dHNjaGUgVGVsZWtvbSBSb290IENBIDIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCrC6M14IspFLEUha88EOQ5bzVdSq7d6mGNlUn0b2SjGmBmpKlAIoTZ1KXleJMOaAGtuU1cOs7T uKhCQN/Po7qCWWqSG6wcmtoIKyUn+WkjR/Hg6yx6m/UTAtB+NHzCnjwAWav12gz1MjwrrFDa1sPe g5TKqAyZMg4ISFZbavva4VhYAUlfckE8FQYBjl2tqriTtM2e66foai1SNNs671x1Udrb8zH57nGY MsRUFUQM+ZtV7a3fGAigo4aKSe5TBY8ZTNXeWHmb0mocQqvF1afPaA+W5OFhmHZhyJF81j4A4pFQ h+GdCuatl9Idxjp9y7zaAzTVjlsB9WoHtxa2bkp/AgMBAAGjQjBAMB0GA1UdDgQWBBQxw3kbuvVT 1xfgiXotF2wKsyudMzAPBgNVHRMECDAGAQH/AgEFMA4GA1UdDwEB/wQEAwIBBjANBgkqhkiG9w0B AQUFAAOCAQEAlGRZrTlk5ynrE/5aw4sTV8gEJPB0d8Bg42f76Ymmg7+Wgnxu1MM9756AbrsptJh6 sTtU6zkXR34ajgv8HzFZMQSyzhfzLMdiNlXiItiJVbSYSKpk+tYcNthEeFpaIzpXl/V6ME+un2pM SyuOoAPjPuCp1NJ70rOo4nI8rZ7/gFnkm0W09juwzTkZmDLl6iFhkOQxIY40sfcvNUqFENrnijch vllj4PKFiDFT1FQUhXB59C4Gdyd1Lx+4ivn+xbrYNuSD7Odlt79jWvNGr4GUN9RBjNYj1h7P9Wgb RGOiWrqnNVmh5XAFmw4jV5mUCm26OWMohpLzGITY+9HPBVZkVzCCBNUwggO9oAMCAQICCFBOxvU9 EbRkMA0GCSqGSIb3DQEBCwUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNEZXV0c2NoZSBUZWxl a29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYDVQQDExpEZXV0c2No ZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0xNDA3MjIxMjA4MjZaFw0xOTA3MDkyMzU5MDBaMFoxCzAJ BgNVBAYTAkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQD ExtERk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U1wBblSJ01CDrNI/W7MAxBAuZgeKmFNJSoCgjhIt0 iQReW+DieMF4yxbLKDU5ey2QRdDtoAB6fL9KDhsAw4bpXCsxEXsM84IkQ4wcOItqaACa7txPeKvS xhObdq3u3ibo7wGvdA/BCaL2a869080UME/15eOkyGKbghoDJzANAmVgTe3RCSMqljVYJ9N2xnG2 kB3E7f81hn1vM7PbD8URwoqDoZRdQWvY0hD1TP3KUazZve+Sg7va64sWVlZDz+HVEz2mHycwzUlU 28kTNJpxdcVs6qcLmPkhnSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjggGGMIIBgjAOBgNVHQ8BAf8E BAMCAQYwHQYDVR0OBBYEFEm3xs/oPR9/6kR7Eyn38QpwPt5kMB8GA1UdIwQYMBaAFDHDeRu69VPX F+CJei0XbAqzK50zMBIGA1UdEwEB/wQIMAYBAf8CAQIwYgYDVR0gBFswWTARBg8rBgEEAYGtIYIs AQEEAgIwEQYPKwYBBAGBrSGCLAEBBAMAMBEGDysGAQQBga0hgiwBAQQDATAPBg0rBgEEAYGtIYIs AQEEMA0GCysGAQQBga0hgiweMD4GA1UdHwQ3MDUwM6AxoC+GLWh0dHA6Ly9wa2kwMzM2LnRlbGVz ZWMuZGUvcmwvRFRfUk9PVF9DQV8yLmNybDB4BggrBgEFBQcBAQRsMGowLAYIKwYBBQUHMAGGIGh0 dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMDoGCCsGAQUFBzAChi5odHRwOi8vcGtpMDMz Ni50ZWxlc2VjLmRlL2NydC9EVF9ST09UX0NBXzIuY2VyMA0GCSqGSIb3DQEBCwUAA4IBAQBjICj9 nCGGcr45Rlk5MiW8qQGbDczKfUGchm0KbiyzE1l1sTOSG2EnFv/DstU1gvuEKgFJvWa7Zi+ywgZd bj9u4wFaW8pDY1yVtuExpx/VB19N5mWCTjL5w3x6S81NXHTuIfJ1AuxSPtLJatOQI25JZzW+f01W pOzML8+3oZeocj7JvEDWWqQIPda8gsO3tzKOsSyOam23NQIZz/U5RFhjpyQAELC7/E6vbi84u6VX ST/YblBvLJeW3B1GmmWJz67M8uXZn1OzPqEvkqnYC8aEHwTG6x7on321e6UC8STFJGMRNMxakyAq eYg6JUKQqWU7fIbTEhUjKfws2sw5W1QXMIIE1TCCA72gAwIBAgIIUE7G9T0RtGQwDQYJKoZIhvcN AQELBQAwcTELMAkGA1UEBhMCREUxHDAaBgNVBAoTE0RldXRzY2hlIFRlbGVrb20gQUcxHzAdBgNV BAsTFlQtVGVsZVNlYyBUcnVzdCBDZW50ZXIxIzAhBgNVBAMTGkRldXRzY2hlIFRlbGVrb20gUm9v dCBDQSAyMB4XDTE0MDcyMjEyMDgyNloXDTE5MDcwOTIzNTkwMFowWjELMAkGA1UEBhMCREUxEzAR BgNVBAoTCkRGTi1WZXJlaW4xEDAOBgNVBAsTB0RGTi1QS0kxJDAiBgNVBAMTG0RGTi1WZXJlaW4g UENBIEdsb2JhbCAtIEcwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOmbw2eF+Q2u 9Y1Uw5ZQNT1i6W5M7ZTXAFuVInTUIOs0j9bswDEEC5mB4qYU0lKgKCOEi3SJBF5b4OJ4wXjLFsso NTl7LZBF0O2gAHp8v0oOGwDDhulcKzERewzzgiRDjBw4i2poAJru3E94q9LGE5t2re7eJujvAa90 D8EJovZrzr3TzRQwT/Xl46TIYpuCGgMnMA0CZWBN7dEJIyqWNVgn03bGcbaQHcTt/zWGfW8zs9sP xRHCioOhlF1Ba9jSEPVM/cpRrNm975KDu9rrixZWVkPP4dUTPaYfJzDNSVTbyRM0mnF1xWzqpwuY +SGdJ68+ozk5SGqMrcmZ+8MS8r0CAwEAAaOCAYYwggGCMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4E FgQUSbfGz+g9H3/qRHsTKffxCnA+3mQwHwYDVR0jBBgwFoAUMcN5G7r1U9cX4Il6LRdsCrMrnTMw EgYDVR0TAQH/BAgwBgEB/wIBAjBiBgNVHSAEWzBZMBEGDysGAQQBga0hgiwBAQQCAjARBg8rBgEE AYGtIYIsAQEEAwAwEQYPKwYBBAGBrSGCLAEBBAMBMA8GDSsGAQQBga0hgiwBAQQwDQYLKwYBBAGB rSGCLB4wPgYDVR0fBDcwNTAzoDGgL4YtaHR0cDovL3BraTAzMzYudGVsZXNlYy5kZS9ybC9EVF9S T09UX0NBXzIuY3JsMHgGCCsGAQUFBwEBBGwwajAsBggrBgEFBQcwAYYgaHR0cDovL29jc3AwMzM2 LnRlbGVzZWMuZGUvb2NzcHIwOgYIKwYBBQUHMAKGLmh0dHA6Ly9wa2kwMzM2LnRlbGVzZWMuZGUv Y3J0L0RUX1JPT1RfQ0FfMi5jZXIwDQYJKoZIhvcNAQELBQADggEBAGMgKP2cIYZyvjlGWTkyJbyp AZsNzMp9QZyGbQpuLLMTWXWxM5IbYScW/8Oy1TWC+4QqAUm9ZrtmL7LCBl1uP27jAVpbykNjXJW2 4TGnH9UHX03mZYJOMvnDfHpLzU1cdO4h8nUC7FI+0slq05AjbklnNb5/TVak7Mwvz7ehl6hyPsm8 QNZapAg91ryCw7e3Mo6xLI5qbbc1AhnP9TlEWGOnJAAQsLv8Tq9uLzi7pVdJP9huUG8sl5bcHUaa ZYnPrszy5dmfU7M+oS+SqdgLxoQfBMbrHuiffbV7pQLxJMUkYxE0zFqTICp5iDolQpCpZTt8htMS FSMp/CzazDlbVBcwggU9MIIEJaADAgECAgcXr/adVkv+MA0GCSqGSIb3DQEBCwUAMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtE Rk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwHhcNMTQwNjA1MTQwNTAyWhcNMTkwNzA5MjM1OTAw WjBpMQswCQYDVQQGEwJERTEuMCwGA1UEChMlUGh5c2lrYWxpc2NoLVRlY2huaXNjaGUgQnVuZGVz YW5zdGFsdDEPMA0GA1UEAxMGUFRCIENBMRkwFwYJKoZIhvcNAQkBFgpwa2lAcHRiLmRlMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvArCgzkqw2LMAYuU38VJTgyGBC+Pp+uvw52LmtI6 MEMiFr0xY6SEzYcDG3z5NSohZisdnL7bu8Ee7MFD3TZX1jVBie//UNAJqXbHnUzE8hbJYCR5ydb9 WqIzoT5PzG07qJWblbidcrZVcCQEef9V1CaRyfXuqiSTOgibqODLP98N7jMIImz2ipUgMdoGyOgS h/qds5SM6CUgwMeuJ42QpYNot9ri1IKAweyhIIa3TANsu56scy+Fc2+XWOfsuImeeLcaiu6HJPk6 X55QT+kWaAoQf6qJyJXv8b/n6l1nmTIU2AY2B5EnO/rIT+DW+MJy77/HO+7rtwaznuntXMgytwID AQABo4IB9zCCAfMwEgYDVR0TAQH/BAgwBgEB/wIBATAOBgNVHQ8BAf8EBAMCAQYwEQYDVR0gBAow CDAGBgRVHSAAMB0GA1UdDgQWBBTEgNBuKBVoMVrscF94juEwQzjqNDAfBgNVHSMEGDAWgBRJt8bP 6D0ff+pEexMp9/EKcD7eZDAVBgNVHREEDjAMgQpwa2lAcHRiLmRlMIGIBgNVHR8EgYAwfjA9oDug OYY3aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY3JsL2NhY3JsLmNy bDA9oDugOYY3aHR0cDovL2NkcDIucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY3JsL2Nh Y3JsLmNybDCB1wYIKwYBBQUHAQEEgcowgccwMwYIKwYBBQUHMAGGJ2h0dHA6Ly9vY3NwLnBjYS5k Zm4uZGUvT0NTUC1TZXJ2ZXIvT0NTUDBHBggrBgEFBQcwAoY7aHR0cDovL2NkcDEucGNhLmRmbi5k ZS9nbG9iYWwtcm9vdC1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwRwYIKwYBBQUHMAKGO2h0dHA6 Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MA0G CSqGSIb3DQEBCwUAA4IBAQCo3hebMpEocLPJTOlDMAmSzpxK3SA1ftaQqodbMncOi9WkeICQlmIv rQxGCq8Be/6hKtIrbFOhRtSzQi870glJRj7dhZaHC+WOgT5tP5Nkgwpgl4k4pQDXPPrwmaI6cSYD a/LpprQzBNjEQMdQqkeanpD0WU9U1pOPFIMfIrxh2cy8mBpIAMuZqMHbMyPNDZk/YN4r3b2DcBrQ wL/tHerp6Vc7n9WqO+3cm7Fa4AxL9q2KeItyYe0Cws2KZNz4IuiMjQAclNL0PhTEqIzkD/EiK6Ag 1qcH7o3ktpmakvL2RzSZA71irCfONRgh/+ixfuMu6YA5uzyA8SYfwyFQcABdMIIFPTCCBCWgAwIB AgIHF6/2nVZL/jANBgkqhkiG9w0BAQsFADBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZOLVZl cmVpbjEQMA4GA1UECxMHREZOLVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xvYmFsIC0g RzAxMB4XDTE0MDYwNTE0MDUwMloXDTE5MDcwOTIzNTkwMFowaTELMAkGA1UEBhMCREUxLjAsBgNV BAoTJVBoeXNpa2FsaXNjaC1UZWNobmlzY2hlIEJ1bmRlc2Fuc3RhbHQxDzANBgNVBAMTBlBUQiBD QTEZMBcGCSqGSIb3DQEJARYKcGtpQHB0Yi5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALwKwoM5KsNizAGLlN/FSU4MhgQvj6frr8Odi5rSOjBDIha9MWOkhM2HAxt8+TUqIWYrHZy+ 27vBHuzBQ902V9Y1QYnv/1DQCal2x51MxPIWyWAkecnW/VqiM6E+T8xtO6iVm5W4nXK2VXAkBHn/ VdQmkcn17qokkzoIm6jgyz/fDe4zCCJs9oqVIDHaBsjoEof6nbOUjOglIMDHrieNkKWDaLfa4tSC gMHsoSCGt0wDbLuerHMvhXNvl1jn7LiJnni3GoruhyT5Ol+eUE/pFmgKEH+qiciV7/G/5+pdZ5ky FNgGNgeRJzv6yE/g1vjCcu+/xzvu67cGs57p7VzIMrcCAwEAAaOCAfcwggHzMBIGA1UdEwEB/wQI MAYBAf8CAQEwDgYDVR0PAQH/BAQDAgEGMBEGA1UdIAQKMAgwBgYEVR0gADAdBgNVHQ4EFgQUxIDQ bigVaDFa7HBfeI7hMEM46jQwHwYDVR0jBBgwFoAUSbfGz+g9H3/qRHsTKffxCnA+3mQwFQYDVR0R BA4wDIEKcGtpQHB0Yi5kZTCBiAYDVR0fBIGAMH4wPaA7oDmGN2h0dHA6Ly9jZHAxLnBjYS5kZm4u ZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NybC9jYWNybC5jcmwwPaA7oDmGN2h0dHA6Ly9jZHAyLnBj YS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NybC9jYWNybC5jcmwwgdcGCCsGAQUFBwEBBIHK MIHHMDMGCCsGAQUFBzABhidodHRwOi8vb2NzcC5wY2EuZGZuLmRlL09DU1AtU2VydmVyL09DU1Aw RwYIKwYBBQUHMAKGO2h0dHA6Ly9jZHAxLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2Nh Y2VydC9jYWNlcnQuY3J0MEcGCCsGAQUFBzAChjtodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2dsb2Jh bC1yb290LWNhL3B1Yi9jYWNlcnQvY2FjZXJ0LmNydDANBgkqhkiG9w0BAQsFAAOCAQEAqN4XmzKR KHCzyUzpQzAJks6cSt0gNX7WkKqHWzJ3DovVpHiAkJZiL60MRgqvAXv+oSrSK2xToUbUs0IvO9IJ SUY+3YWWhwvljoE+bT+TZIMKYJeJOKUA1zz68JmiOnEmA2vy6aa0MwTYxEDHUKpHmp6Q9FlPVNaT jxSDHyK8YdnMvJgaSADLmajB2zMjzQ2ZP2DeK929g3Aa0MC/7R3q6elXO5/Vqjvt3JuxWuAMS/at iniLcmHtAsLNimTc+CLojI0AHJTS9D4UxKiM5A/xIiugINanB+6N5LaZmpLy9kc0mQO9YqwnzjUY If/osX7jLumAObs8gPEmH8MhUHAAXTCCBaIwggSKoAMCAQICDBxmO6qdufc5yhZ6iDANBgkqhkiG 9w0BAQsFADBpMQswCQYDVQQGEwJERTEuMCwGA1UEChMlUGh5c2lrYWxpc2NoLVRlY2huaXNjaGUg QnVuZGVzYW5zdGFsdDEPMA0GA1UEAxMGUFRCIENBMRkwFwYJKoZIhvcNAQkBFgpwa2lAcHRiLmRl MB4XDTE2MTIwNjEzMzMxNFoXDTE5MDcwOTIzNTkwMFowaDELMAkGA1UEBhMCREUxLjAsBgNVBAoM JVBoeXNpa2FsaXNjaC1UZWNobmlzY2hlIEJ1bmRlc2Fuc3RhbHQxDTALBgNVBAsMBFEuNDIxGjAY BgNVBAMMEURyLiBEaWV0ZXIgU2lib2xkMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA +AOQrmrEQ2k8s9su/TVvmdF46YbL2MuF6OvnrjjKaJIkBvchop87cCwv80aZEbmU3as54egQEMGn NFkp1fF4bics4TJdEpND116l+jbi5DCtA3hHP/spV1aQZBDc/BDkm1Nl5WYKh/DxN6sUhZxorbb4 Y0nmSxnK2ctIwuF4Qdibsw7GE2YLvWF4tlzSCGbDjSy2agSn1wYHMsC+tAcFflcMXF2sDMZHkYuq 5IHwng8GBQFhsldYl1fk2sB2/hVRLYU205qaj13H94WjfDLuB22sT17XPJ2U/9tuFN/sxAPR0/N4 y4/IgMnOaP30VU0FMmULd7qJg0WST5D5kwgMhwIDAQABo4ICSTCCAkUwQAYDVR0gBDkwNzARBg8r BgEEAYGtIYIsAQEEAwUwEQYPKwYBBAGBrSGCLAIBBAMBMA8GDSsGAQQBga0hgiwBAQQwCQYDVR0T BAIwADAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1Ud DgQWBBQHn42zKDpvJi1bsJ4OVk2A9liUFjAfBgNVHSMEGDAWgBTEgNBuKBVoMVrscF94juEwQzjq NDBEBgNVHREEPTA7gRRkaWV0ZXIuc2lib2xkQHB0Yi5kZaAjBgorBgEEAYI3FAIDoBUME3NpYm9s ZDAxQHBhZC5wdGIuZGUwdwYDVR0fBHAwbjA1oDOgMYYvaHR0cDovL2NkcDEucGNhLmRmbi5kZS9w dGItY2EvcHViL2NybC9jYWNybC5jcmwwNaAzoDGGL2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvcHRi LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIHHBggrBgEFBQcBAQSBujCBtzAzBggrBgEFBQcwAYYnaHR0 cDovL29jc3AucGNhLmRmbi5kZS9PQ1NQLVNlcnZlci9PQ1NQMD8GCCsGAQUFBzAChjNodHRwOi8v Y2RwMS5wY2EuZGZuLmRlL3B0Yi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwPwYIKwYBBQUHMAKG M2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvcHRiLWNhL3B1Yi9jYWNlcnQvY2FjZXJ0LmNydDANBgkq hkiG9w0BAQsFAAOCAQEADaSfgrrQZx9eiQrCK7kgJMpLstro5OgIcWSpW4i4AQ1wEwyDUrdB1XWK GjA8/KwExSBP9a+dcdW+ACjX7TyURQPLqRTOkoPc9dafRx327mV4K8PE8z7fg5l2ittYNs0nXlOB QevRbYYP4XUOMYohFWfHpDwEg3ExmoArb2HaQCzKhq/2VcIIXTwaN6AVr2NVKEuH3qwpgOUSlJJ1 5ORb6TD4p1G2W6XT3jk3tOa8nRaOkI5hqpPvLfbPEibn+Bfqm6GWqpXfQ6NLAvWYcI8ltSKgdnCw Rmqdh1Ba/KWGdm41PDtQIx58vgbZGfN5GKJrp+OwS5D+/e/r296qoKUBRDCCBaIwggSKoAMCAQIC DBxmO6qdufc5yhZ6iDANBgkqhkiG9w0BAQsFADBpMQswCQYDVQQGEwJERTEuMCwGA1UEChMlUGh5 c2lrYWxpc2NoLVRlY2huaXNjaGUgQnVuZGVzYW5zdGFsdDEPMA0GA1UEAxMGUFRCIENBMRkwFwYJ KoZIhvcNAQkBFgpwa2lAcHRiLmRlMB4XDTE2MTIwNjEzMzMxNFoXDTE5MDcwOTIzNTkwMFowaDEL MAkGA1UEBhMCREUxLjAsBgNVBAoMJVBoeXNpa2FsaXNjaC1UZWNobmlzY2hlIEJ1bmRlc2Fuc3Rh bHQxDTALBgNVBAsMBFEuNDIxGjAYBgNVBAMMEURyLiBEaWV0ZXIgU2lib2xkMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA+AOQrmrEQ2k8s9su/TVvmdF46YbL2MuF6OvnrjjKaJIkBvch op87cCwv80aZEbmU3as54egQEMGnNFkp1fF4bics4TJdEpND116l+jbi5DCtA3hHP/spV1aQZBDc /BDkm1Nl5WYKh/DxN6sUhZxorbb4Y0nmSxnK2ctIwuF4Qdibsw7GE2YLvWF4tlzSCGbDjSy2agSn 1wYHMsC+tAcFflcMXF2sDMZHkYuq5IHwng8GBQFhsldYl1fk2sB2/hVRLYU205qaj13H94WjfDLu B22sT17XPJ2U/9tuFN/sxAPR0/N4y4/IgMnOaP30VU0FMmULd7qJg0WST5D5kwgMhwIDAQABo4IC STCCAkUwQAYDVR0gBDkwNzARBg8rBgEEAYGtIYIsAQEEAwUwEQYPKwYBBAGBrSGCLAIBBAMBMA8G DSsGAQQBga0hgiwBAQQwCQYDVR0TBAIwADAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYB BQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQHn42zKDpvJi1bsJ4OVk2A9liUFjAfBgNVHSMEGDAW gBTEgNBuKBVoMVrscF94juEwQzjqNDBEBgNVHREEPTA7gRRkaWV0ZXIuc2lib2xkQHB0Yi5kZaAj BgorBgEEAYI3FAIDoBUME3NpYm9sZDAxQHBhZC5wdGIuZGUwdwYDVR0fBHAwbjA1oDOgMYYvaHR0 cDovL2NkcDEucGNhLmRmbi5kZS9wdGItY2EvcHViL2NybC9jYWNybC5jcmwwNaAzoDGGL2h0dHA6 Ly9jZHAyLnBjYS5kZm4uZGUvcHRiLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIHHBggrBgEFBQcBAQSB ujCBtzAzBggrBgEFBQcwAYYnaHR0cDovL29jc3AucGNhLmRmbi5kZS9PQ1NQLVNlcnZlci9PQ1NQ MD8GCCsGAQUFBzAChjNodHRwOi8vY2RwMS5wY2EuZGZuLmRlL3B0Yi1jYS9wdWIvY2FjZXJ0L2Nh Y2VydC5jcnQwPwYIKwYBBQUHMAKGM2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvcHRiLWNhL3B1Yi9j YWNlcnQvY2FjZXJ0LmNydDANBgkqhkiG9w0BAQsFAAOCAQEADaSfgrrQZx9eiQrCK7kgJMpLstro 5OgIcWSpW4i4AQ1wEwyDUrdB1XWKGjA8/KwExSBP9a+dcdW+ACjX7TyURQPLqRTOkoPc9dafRx32 7mV4K8PE8z7fg5l2ittYNs0nXlOBQevRbYYP4XUOMYohFWfHpDwEg3ExmoArb2HaQCzKhq/2VcII XTwaN6AVr2NVKEuH3qwpgOUSlJJ15ORb6TD4p1G2W6XT3jk3tOa8nRaOkI5hqpPvLfbPEibn+Bfq m6GWqpXfQ6NLAvWYcI8ltSKgdnCwRmqdh1Ba/KWGdm41PDtQIx58vgbZGfN5GKJrp+OwS5D+/e/r 296qoKUBRDGCAuMwggLfAgEBMHkwaTELMAkGA1UEBhMCREUxLjAsBgNVBAoTJVBoeXNpa2FsaXNj aC1UZWNobmlzY2hlIEJ1bmRlc2Fuc3RhbHQxDzANBgNVBAMTBlBUQiBDQTEZMBcGCSqGSIb3DQEJ ARYKcGtpQHB0Yi5kZQIMHGY7qp259znKFnqIMA0GCWCGSAFlAwQCAQUAoIIBOzAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzA4MDExNTA0MzNaMC8GCSqGSIb3DQEJ BDEiBCDfx2n1EsnNZO40K4AF+dkhADLkFhY9X3OMo/+y3OV//DBDBgkqhkiG9w0BCQ8xNjA0MAcG BSsOAwIdMA4GCCqGSIb3DQMCAgIAgDAKBggqhkiG9w0DBzANBggqhkiG9w0DAgIBKDCBigYLKoZI hvcNAQkQAgsxe6B5MGkxCzAJBgNVBAYTAkRFMS4wLAYDVQQKEyVQaHlzaWthbGlzY2gtVGVjaG5p c2NoZSBCdW5kZXNhbnN0YWx0MQ8wDQYDVQQDEwZQVEIgQ0ExGTAXBgkqhkiG9w0BCQEWCnBraUBw dGIuZGUCDBxmO6qdufc5yhZ6iDANBgkqhkiG9w0BAQEFAASCAQBSd80hhjs9w+zXvtEw/6r5JQuA ipXW5lKorR5CwD3uMFiowv3SiuixHxw8BC7umpgWWtAfY8+GkTZ/SSKIKvu9xBAAZeU6SImzvgTv B4Fo8ccSoZZ3BByeIglnG+1sP0xR4QzSTQmLuFD/gyLw4jl7rGmNSSvpdxA3YC0h+dcIEU0dMA2X JabKegE9LxxVX869Urjsap9m7TCFYjJa1Wim01pMKrBhr+m2qXr4VWinwVn1yQylWqz4H/ymapBC WeIiNxIGDJqckkjJ+/893+fzODi2ikeFdow4LzEVBUTCvCFloSt/RI8OYZOIag7UyuDO/x/s1PSM 96I8OpJfl29hAAAAAA== ---------z50291_boundary_sign-- --===============5248941860103280414== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg --===============5248941860103280414==-- From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Thu Aug 3 01:56:29 2017 Return-Path: X-Original-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7807F12F24E for ; Thu, 3 Aug 2017 01:56:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 Ny0rfP9kV7GT for ; Thu, 3 Aug 2017 01:56:27 -0700 (PDT) Received: from lists.ntp.org (psp3.ntp.org [185.140.48.241]) by ietfa.amsl.com (Postfix) with ESMTP id BCE62126CC4 for ; Thu, 3 Aug 2017 01:56:27 -0700 (PDT) Received: from lists.ntp.org (unknown [127.0.0.235]) by lists.ntp.org (Postfix) with ESMTP id 04BE386DB75 for ; Thu, 3 Aug 2017 08:56:27 +0000 (UTC) X-Original-To: ntpwg@lists.ntp.org Delivered-To: ntpwg@lists.ntp.org Received: from mail1.ntp.org (fortinet.ntp.org [10.224.90.254]) by lists.ntp.org (Postfix) with ESMTP id C9CEB86DAB4 for ; Thu, 3 Aug 2017 08:56:22 +0000 (UTC) Received: from mx1.redhat.com ([209.132.183.28]) by mail1.ntp.org with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1ddBvS-0002QZ-FM for ntpwg@lists.ntp.org; Thu, 03 Aug 2017 08:56:22 +0000 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 287643680F; Thu, 3 Aug 2017 08:56:13 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 287643680F Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=mlichvar@redhat.com Received: from localhost (unknown [10.43.2.117]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 3BB6F7F801; Thu, 3 Aug 2017 08:56:11 +0000 (UTC) Date: Thu, 3 Aug 2017 10:56:10 +0200 From: Miroslav Lichvar To: dieter.sibold@ptb.de Message-ID: <20170803085610.GE1206@localhost> References: <707deca2-9037-c9fc-69bc-71ee80cb4c97@nwtime.org> <20170801073854.GB2346@localhost> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.0 (2017-02-23) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Thu, 03 Aug 2017 08:56:13 +0000 (UTC) X-SA-Exim-Connect-IP: 209.132.183.28 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: mlichvar@redhat.com X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Subject: Re: [ntpwg] Antwort: Re: NTS: DTLS and symmetric mode X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.24 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: ntpwg Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Sender: "ntpwg" On Tue, Aug 01, 2017 at 05:04:32PM +0200, dieter.sibold@ptb.de wrote: > > Von: Miroslav Lichvar > > Here is the list of issues I posted previously (with no response) [1]: > > > > - no stateless passive mode > > - problematic pairing of DTLS sessions > Daniel considered this question. He provided a discussion in Sec. 4 of the > current NTS draft (version -09). That clarifies some of the issues we discussed before, but it seems to me it still assumes there can be only one NTS peer per IP address. That wasn't the case with older authentication mechanisms (symmetric key, autokey). > > - won't work with HW which can timestamp only packets on port 123 > > (or 319) > Yes, but the vast majority of NTP servers and clients don't use HW based > time stamping. Also note, that HW based time stamping is going to be > difficult for mode 3 and 4 packets also. This packets are protected by NTS > extension fields and HW time stamping NICs are not able to calculate the > NTS AEAD information (at least currently). HW doesn't need to know about NTS, it can still be a SW implementation of NTP+NTS. The problem is with receiving packets. Some HW can provide timestamps for all received packets, but apparently in some designs that would have a significant impact on performance, so there is a filter to limit timestamps to PTP/NTP packets. I think there is at least one which can be configured to timestamps packets on UDP port 123 or 319, but not other ports. > > - won't work with future NTP extensions for delay corrections in > > routers/switches > That is probably true. But I don't see the use case for this. Typically > you apply symmetric mode in a closed environment. If you require the > additional accuracy of delay corrections in router/switches you would > apply PTP which already provide these features. PTP doesn't have NTS :). Authentication is not the only reason why people may want to prefer NTP over PTP in local networks. Anyway, do we know if anyone is actually interested in implementing this NTP over DTLS symmetric mode? I'm wondering if it wouldn't be better to leave it out of the draft and focus on that later if there is interest. It doesn't specify NTS for broadcast mode either (which of course would be much more difficult to do). -- Miroslav Lichvar _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Tue Aug 8 08:43:54 2017 Return-Path: X-Original-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C31A132474 for ; Tue, 8 Aug 2017 08:43:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.47 X-Spam-Level: X-Spam-Status: No, score=-1.47 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.428, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 BeYAWiQVWO50 for ; Tue, 8 Aug 2017 08:43:50 -0700 (PDT) Received: from lists.ntp.org (psp3.ntp.org [185.140.48.241]) by ietfa.amsl.com (Postfix) with ESMTP id 3995E132726 for ; Tue, 8 Aug 2017 08:43:50 -0700 (PDT) Received: from lists.ntp.org (unknown [127.0.0.235]) by lists.ntp.org (Postfix) with ESMTP id 67D6686DB6B for ; Tue, 8 Aug 2017 15:43:49 +0000 (UTC) X-Original-To: ntpwg@lists.ntp.org Delivered-To: ntpwg@lists.ntp.org Received: from mail1.ntp.org (fortinet.ntp.org [10.224.90.254]) by lists.ntp.org (Postfix) with ESMTP id 5AE4C86DABE for ; Tue, 8 Aug 2017 15:43:44 +0000 (UTC) Received: from mx1.bs.ptb.de ([192.53.103.120]) by mail1.ntp.org with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1df6fJ-000DHT-Ad for ntpwg@lists.ntp.org; Tue, 08 Aug 2017 15:43:44 +0000 Received: from smtp-hub.bs.ptb.de (smtpint01.bs.ptb.de [141.25.87.32]) by mx1.bs.ptb.de with ESMTP id v78FhSrT011774-v78FhSrV011774 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 8 Aug 2017 17:43:28 +0200 Received: from rose.bs.ptb.de (rose.bs.ptb.de [141.25.85.201]) by smtp-hub.bs.ptb.de (Postfix) with ESMTPS id 1ABC1529178 for ; Tue, 8 Aug 2017 17:43:28 +0200 (CEST) To: ntpwg MIME-Version: 1.0 Message-ID: From: dieter.sibold@ptb.de Date: Tue, 8 Aug 2017 17:43:26 +0200 X-SA-Exim-Connect-IP: 192.53.103.120 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: dieter.sibold@ptb.de X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Subject: [ntpwg] IETF99: Minutes from the NTP/TICTOC wg session X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.24 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============8262353146846299097==" Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Sender: "ntpwg" This is an S/MIME signed message. --===============8262353146846299097== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha-256; boundary=-------z10255_boundary_sign This is an S/MIME signed message. ---------z10255_boundary_sign Content-Type: multipart/alternative; boundary="=_alternative 00566035C1258176_=" Dies ist eine mehrteilige Nachricht im MIME-Format. --=_alternative 00566035C1258176_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Hello all. you may find the minutes from the IETF99 NTP/TICTOC wg session at: https://datatracker.ietf.org/doc/minutes-99-ntp/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D NTP/TICTOC Joint Meeting July 18th, 2017, 9:30-12:00 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D NTP WG Chairs: Karen O'Donoghue, Dieter Sibold TICTOC WG Chairs: Karen O'Donoghue, Yaakov Stein (absent) Note taker: Tal Mizrahi CHAIR SLIDES ------------ Presenter: Karen O'Donoghue Slides: https://www.ietf.org/proceedings/99/slides/slides-99-ntp-agenda-and-note-we= ll-00.pd Summary: - Karen presented the new note well. - NTP Mode 6 draft (draft-ietf-ntp-mode-6-cmds) is ready for WG last call. No questions of comments. NTP WORKING GROUP =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D NETWORK TIME SECURITY (NTS) --------------------------- Presenter: Daniel Franke No slides presented. Draft: https://datatracker.ietf.org/doc/html/draft-ietf-ntp-using-nts-for-ntp Summary: - Addressed all the pending comments. - The authors believe the document is ready for WG last call. Discussion: - Karen: How many people have read the updated document? - Very few hands raised. - Harlan: Dave Mills has raised a concern about the lack of text about symmetric mode. DTLS will not necessarily work with symmetric mode. - Franke: we will look into this and respond. - Karen: we can proceed to WG last call, and address this during WG last call. We will start a 3-week WG last call next week. - Karen: the NTP mailing list should be move to the IETF servers. MESSAGE AUTHENTICATION CODE FOR THE NETWORK TIME PROTOCOL --------------------------------------------------------- Presenter: Aanchal Malhotra No slides presented. Draft: https://datatracker.ietf.org/doc/html/draft-ietf-ntp-mac Summary: - Algorithm agility is supported with NTP via the ntp.keys file which allows to specify the adopted MAC algorithm - A section regarding test vectors are added. - Some more minor changes. Discussion: - Karen: looks like it is ready for WG last call. It will start this week. NTP CLIENT DATA MINIMIZATION ---------------------------- Presenter: Daniel Franke Draft: https://datatracker.ietf.org/doc/html/draft-ietf-ntp-data-minimization Summary: - There were some non-technical comments that we do not know how to address, and we are looking for another editor who will help us tackle these comments. Discussion: - Aanchal: what does it mean to have another editor. - Karen: the editor will be added to the author list. - Suresh: these kind of personal issues are not very common. It is not necessarily required to have a new editor. The WG chairs can just take the decision how to proceed. - Harlan: Dave argues that the document is not necessary, since it is very similar to SNTP. There may be an error in the document; the received timestamp gets sent back is data leakage, but that is not necessarily true. - Franke: the document needs to be published, just to have a statement regarding the privacy and security issues. - Aanchal: the document is necessary to emphasize the reasons for data minimization. NTP BCP ------- Presenter: Dieter Sibold Slides: https://www.ietf.org/proceedings/99/slides/slides-99-ntp-network-time-proto= col-best-current-practices-00.pdf Draft: https://tools.ietf.org/html/draft-ietf-ntp-bcp-05 Summary: - A few relatively small editorial changes. Discussion: - Karen: the document is ready to be sent to the IESG. A YANG DATA MODEL FOR NTP ------------------------- No presenter Draft: https://datatracker.ietf.org/doc/html/draft-ietf-ntp-yangwu-ntp-ntp-cfg Discussion: - Karen: In the next interim meeting we will talk about WG last call. - Harlan: no one has implemented it yet. It should not be difficult, but still important. GUIDELINES FOR DEFINING PACKET TIMESTAMP FORMATS ------------------------------------------------ Presenter: Tal Mizrahi Slides: https://www.ietf.org/proceedings/99/slides/slides-99-ntp-guidelines-for-def= ining-packet-timestamp-formats-00.pdf draft: https://datatracker.ietf.org/doc/html/draft-mizrahi-intarea-packet-timestam= ps Summary Discussion Tal: as for suggestion of the right working group for this draft Daniel: this draft should also consider correct handling of the leapsecond Yokoov: suggests to place the draft to the TICTOC working group Suresh: recommends the NTP or TICTOC working group for this draft Dieter: ask if the control field can also contain information about the uncertainty associated with the timestamp. Tal: this should be possible. The control field already has a field called precision that might be used for this purpose Fabini: NNN TICTOC WORKING GROUP =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D TICTOC WG STATUS ---------------- Presenter: Karen O'Donoghue Slides: https://www.ietf.org/proceedings/99/slides/slides-99-ntp-agenda-and-note-we= ll-00.pdf Summary: - The IEEE 1588 MIB was finally published as an RFC ? RFC 8173! - Awaiting author update on the Enterprise Profile draft. YANG DATA MODEL FOR IEEE 1588V2 ------------------------------- Presenter: Yuanlong Jiang Slides: https://www.ietf.org/proceedings/99/slides/slides-99-ntp-yang-data-model-fo= r-ieee-1588v2-00.pdf Draft: https://tools.ietf.org/html/draft-ietf-tictoc-1588v2-yang-05 Summary: - The authors are looking for more feedback. - The authors would like to ask the WG whether the draft is ready for last call. Discussion: - Karen: it looks like we are ready for WG last call. - Karen: we will inform the IEEE 1588 working group about the last call. - Suresh: we talked in Berlin about whether this work should be published as an RFC first, or sent to the IEEE 1588 first. - Karen: the IEEE 1588 working group does not intend to publish a YANG model in the upcoming standard edition. We will publish an RFC, and in the future it can be used as a basis for the YANG model of the IEEE 1588 standard. GENERAL DISCUSSION ------------------ - Suresh: looking forward, we need to think about the future of the working group, charter and name. - Karen: we have been considering a joint working group for a while now. - Suresh: we can postpone the mailing list migration until we decide about the working group. - Karen: we can stay after the meeting and think about a draft charter. - Daniel: there are other WGs named TIME and DIME. - Yaakov: the ACE working group deals with matters related to time. - Renzo Navas: in ACE working group we will need to address problems related to time synchronization. It may fit a general time-related working group. - Tal: it would be great if in the future we could have at least one slide for each draft that is being presented. Adjourned at 10:30 ------------------------------------- Dr. Dieter Sibold Physikalisch-Technische Bundesanstalt Q.42 - Serversysteme und Datenhaltung QM-Verantwortlicher der Stelle IT Bundesallee 100=20 D-38116 Braunschweig Tel: +49-531-592-84 20 E-Mail: dieter.sibold@ptb.de --=_alternative 00566035C1258176_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable


Hello all.

you may find the minutes from the IE= TF99 NTP/TICTOC wg session at:
https://datatracker.ietf.org/doc/minu= tes-99-ntp/

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
NTP/TICTOC Joint Meeting
July 18th, 2017, 9:30-12:00
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

NTP WG Chairs: Karen O'Donoghue, Dieter Sibold
TICTOC WG Chairs: Karen O'Donoghue, Ya= akov Stein (absent)
Note taker: Tal Mizrahi



CHAIR SLIDES
------------


Presenter: Karen O'Donoghue Slides:
http= s://www.ietf.org/proceedings/99/slides/slides-99-ntp-agenda-and-note-well-0= 0.pd


Summary:

-   Karen presented the new note well.
-   NTP Mode 6 draft (draft-ietf-= ntp-mode-6-cmds) is ready for WG last
    call. No questions of co= mments.



NTP WORKING GROUP
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D


NETWORK TIME SECURITY (NTS)
---------------------------

Presenter: Daniel Franke
No slides presented.
Draft:
https://datatrack= er.ietf.org/doc/html/draft-ietf-ntp-using-nts-for-ntp


Summary:

-   Addressed all the pending com= ments.
-   The authors believe the docum= ent is ready for WG last call.


Discussion:

-   Karen: How many people have r= ead the updated document?
-   Very few hands raised.
-   Harlan: Dave Mills has raised a concern about the lack of text about
    symmetric mode. DTLS will not necessarily work with symmetric mode.
-   Franke: we will look into this and respond.
-   Karen: we can proceed to WG l= ast call, and address this during WG
    last call. We will start a 3-week WG last call next week.
-   Karen: the NTP mailing list s= hould be move to the IETF servers.



MESSAGE AUTHENTICATION CODE FOR THE NE= TWORK TIME PROTOCOL
--------------------------------------= -------------------

Presenter: Aanchal Malhotra
No slides presented.
Draft: https://datatracker.ietf.org/doc/html/draft-ietf-ntp-mac


Summary:

-   Algorithm agility is supported with NTP via the ntp.keys file which
    allows to specify the ad= opted MAC algorithm
-   A section regarding test vect= ors are added.
-   Some more minor changes.


Discussion:

-   Karen: looks like it is ready for WG last call. It will start this
    week.



NTP CLIENT DATA MINIMIZATION
----------------------------

Presenter: Daniel Franke
Draft:
https://datatrack= er.ietf.org/doc/html/draft-ietf-ntp-data-minimization


Summary:

-   There were some non-technical comments that we do not know how to
    address, and we are look= ing for another editor who will help us
    tackle these comments.


Discussion:

-   Aanchal: what does it mean to have another editor.
-   Karen: the editor will be add= ed to the author list.
-   Suresh: these kind of personal issues are not very common. It is not
    necessarily required to have a new editor. The WG chairs can just
    take the decision how to proceed.
-   Harlan: Dave argues that the document is not necessary, since it is
    very similar to SNTP. Th= ere may be an error in the document; the
    received timestamp gets sent back is data leakage, but that is not
    necessarily true.
-   Franke: the document needs to be published, just to have a statement
    regarding the privacy and security issues.
-   Aanchal: the document is nece= ssary to emphasize the reasons for data
    minimization.



NTP BCP
-------

Presenter: Dieter Sibold
Slides:
https://www.ietf.org/proceedings/99/slides/slides-99-n= tp-network-time-protocol-best-current-practices-00.pdf
Draft: https://tools.ietf.org/html/draft-ietf-ntp-bcp-05


Summary:

-   A few relatively small editor= ial changes.


Discussion:

-   Karen: the document is ready to be sent to the IESG.



A YANG DATA MODEL FOR NTP
-------------------------

No presenter
Draft:
https://datatrac= ker.ietf.org/doc/html/draft-ietf-ntp-yangwu-ntp-ntp-cfg


Discussion:

-   Karen: In the next interim me= eting we will talk about WG last call.
-   Harlan: no one has implemented it yet. It should not be difficult,
    but still important.



GUIDELINES FOR DEFINING PACKET TIMESTA= MP FORMATS
--------------------------------------= ----------

Presenter: Tal Mizrahi Slides:
https://www.ietf.org/proceedings/99/slides/slides= -99-ntp-guidelines-for-defining-packet-timestamp-formats-00.pdf
draft:
https://da= tatracker.ietf.org/doc/html/draft-mizrahi-intarea-packet-timestamps<= /a>


Summary


Discussion

Tal: as for suggestion of the right wo= rking group for this draft Daniel:
this draft should also consider correct handling of the leapsecond
Yokoov: suggests to place the draft to the TICTOC working group Suresh:
recommends the NTP or TICTOC working g= roup for this draft Dieter: ask if
the control field can also contain inf= ormation about the uncertainty
associated with the timestamp. Tal: th= is should be possible. The control
field already has a field called preci= sion that might be used for this
purpose Fabini: NNN



TICTOC WORKING GROUP
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D


TICTOC WG STATUS
----------------

Presenter: Karen O'Donoghue
Slides:
htt= ps://www.ietf.org/proceedings/99/slides/slides-99-ntp-agenda-and-note-well-= 00.pdf


Summary:

-   The IEEE 1588 MIB was finally published as an RFC – RFC 8173!
-   Awaiting author update on the Enterprise Profile draft.



YANG DATA MODEL FOR IEEE 1588V2
-------------------------------

Presenter: Yuanlong Jiang
Slides:
https://www.ietf.org/proceedings/99/slides/slides-99-ntp-yang-data-= model-for-ieee-1588v2-00.pdf
Draft: https://tools.ietf.org/html/draft-ietf-tictoc-1588v2-ya= ng-05


Summary:

-   The authors are looking for m= ore feedback.
-   The authors would like to ask the WG whether the draft is ready for
    last call.


Discussion:

-   Karen: it looks like we are r= eady for WG last call.
-   Karen: we will inform the IEEE 1588 working group about the last
    call.
-   Suresh: we talked in Berlin a= bout whether this work should be
    published as an RFC firs= t, or sent to the IEEE 1588 first.
-   Karen: the IEEE 1588 working group does not intend to publish a YANG
    model in the upcoming st= andard edition. We will publish an RFC, and
    in the future it can be used as a basis for the YANG model of the
    IEEE 1588 standard.



GENERAL DISCUSSION
------------------

-   Suresh: looking forward, we n= eed to think about the future of the
    working group, charter a= nd name.
-   Karen: we have been consideri= ng a joint working group for a while
    now.
-   Suresh: we can postpone the m= ailing list migration until we decide
    about the working group.=
-   Karen: we can stay after the meeting and think about a draft
    charter.
-   Daniel: there are other WGs n= amed TIME and DIME.
-   Yaakov: the ACE working group deals with matters related to time.
-   Renzo Navas: in ACE working g= roup we will need to address problems
    related to time synchron= ization. It may fit a general time-related
    working group.
-   Tal: it would be great if in the future we could have at least one
    slide for each draft that is being presented.

Adjourned at 10:30


-------------------------------------
Dr. Dieter Sibold
Physikalisch-Technische Bundesanstalt
Q.42 - Serversysteme und Datenhaltung
QM-Verantwortlicher der Stelle IT
Bundesallee 100
D-38116 Braunschweig
Tel:    +49-531-592-84 20
E-Mail: dieter.sibold@ptb.de
--=_alternative 00566035C1258176_=-- ---------z10255_boundary_sign Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIIp0gIBATEPMA0GCWCGSAFlAwQCAQUAMAsGCSqGSIb3DQEHAaCCJsYw ggOfMIICh6ADAgECAgEmMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNE ZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYD VQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw05OTA3MDkxMjExMDBaFw0xOTA3MDky MzU5MDBaMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYD VQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJv b3QgQ0EgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKsLozXgiykUsRSFrzwQ5Dlv NV1Krt3qYY2VSfRvZKMaYGakqUAihNnUpeV4kw5oAa25TVw6ztO4qEJA38+juoJZapIbrBya2ggr JSf5aSNH8eDrLHqb9RMC0H40fMKePABZq/XaDPUyPCusUNrWw96DlMqoDJkyDghIVltq+9rhWFgB SV9yQTwVBgGOXa2quJO0zZ7rp+hqLVI02zrvXHVR2tvzMfnucZgyxFQVRAz5m1Xtrd8YCKCjhopJ 7lMFjxlM1d5YeZvSahxCq8XVp89oD5bk4WGYdmHIkXzWPgDikVCH4Z0K5q2X0h3GOn3LvNoDNNWO WwH1age3FrZuSn8CAwEAAaNCMEAwHQYDVR0OBBYEFDHDeRu69VPXF+CJei0XbAqzK50zMA8GA1Ud EwQIMAYBAf8CAQUwDgYDVR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBBQUAA4IBAQCUZFmtOWTnKesT /lrDixNXyAQk8HR3wGDjZ/vpiaaDv5aCfG7Uwz3vnoBuuym0mHqxO1TrORdHfhqOC/wfMVkxBLLO F/Msx2I2VeIi2IlVtJhIqmT61hw22ER4WlojOleX9XowT66fakxLK46gA+M+4KnU0nvSs6jicjyt nv+AWeSbRbT2O7DNORmYMuXqIWGQ5DEhjjSx9y81SoUQ2ueKNyG+WWPg8oWIMVPUVBSFcHn0LgZ3 J3UvH7iK+f7Futg25IPs52W3v2Na80avgZQ31EGM1iPWHs/1aBtEY6Jauqc1WaHlcAWbDiNXmZQK bbo5YyiGkvMYhNj70c8FVmRXMIIDnzCCAoegAwIBAgIBJjANBgkqhkiG9w0BAQUFADBxMQswCQYD VQQGEwJERTEcMBoGA1UEChMTRGV1dHNjaGUgVGVsZWtvbSBBRzEfMB0GA1UECxMWVC1UZWxlU2Vj IFRydXN0IENlbnRlcjEjMCEGA1UEAxMaRGV1dHNjaGUgVGVsZWtvbSBSb290IENBIDIwHhcNOTkw NzA5MTIxMTAwWhcNMTkwNzA5MjM1OTAwWjBxMQswCQYDVQQGEwJERTEcMBoGA1UEChMTRGV1dHNj aGUgVGVsZWtvbSBBRzEfMB0GA1UECxMWVC1UZWxlU2VjIFRydXN0IENlbnRlcjEjMCEGA1UEAxMa RGV1dHNjaGUgVGVsZWtvbSBSb290IENBIDIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCrC6M14IspFLEUha88EOQ5bzVdSq7d6mGNlUn0b2SjGmBmpKlAIoTZ1KXleJMOaAGtuU1cOs7T uKhCQN/Po7qCWWqSG6wcmtoIKyUn+WkjR/Hg6yx6m/UTAtB+NHzCnjwAWav12gz1MjwrrFDa1sPe g5TKqAyZMg4ISFZbavva4VhYAUlfckE8FQYBjl2tqriTtM2e66foai1SNNs671x1Udrb8zH57nGY MsRUFUQM+ZtV7a3fGAigo4aKSe5TBY8ZTNXeWHmb0mocQqvF1afPaA+W5OFhmHZhyJF81j4A4pFQ h+GdCuatl9Idxjp9y7zaAzTVjlsB9WoHtxa2bkp/AgMBAAGjQjBAMB0GA1UdDgQWBBQxw3kbuvVT 1xfgiXotF2wKsyudMzAPBgNVHRMECDAGAQH/AgEFMA4GA1UdDwEB/wQEAwIBBjANBgkqhkiG9w0B AQUFAAOCAQEAlGRZrTlk5ynrE/5aw4sTV8gEJPB0d8Bg42f76Ymmg7+Wgnxu1MM9756AbrsptJh6 sTtU6zkXR34ajgv8HzFZMQSyzhfzLMdiNlXiItiJVbSYSKpk+tYcNthEeFpaIzpXl/V6ME+un2pM SyuOoAPjPuCp1NJ70rOo4nI8rZ7/gFnkm0W09juwzTkZmDLl6iFhkOQxIY40sfcvNUqFENrnijch vllj4PKFiDFT1FQUhXB59C4Gdyd1Lx+4ivn+xbrYNuSD7Odlt79jWvNGr4GUN9RBjNYj1h7P9Wgb RGOiWrqnNVmh5XAFmw4jV5mUCm26OWMohpLzGITY+9HPBVZkVzCCBNUwggO9oAMCAQICCFBOxvU9 EbRkMA0GCSqGSIb3DQEBCwUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNEZXV0c2NoZSBUZWxl a29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYDVQQDExpEZXV0c2No ZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0xNDA3MjIxMjA4MjZaFw0xOTA3MDkyMzU5MDBaMFoxCzAJ BgNVBAYTAkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQD ExtERk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U1wBblSJ01CDrNI/W7MAxBAuZgeKmFNJSoCgjhIt0 iQReW+DieMF4yxbLKDU5ey2QRdDtoAB6fL9KDhsAw4bpXCsxEXsM84IkQ4wcOItqaACa7txPeKvS xhObdq3u3ibo7wGvdA/BCaL2a869080UME/15eOkyGKbghoDJzANAmVgTe3RCSMqljVYJ9N2xnG2 kB3E7f81hn1vM7PbD8URwoqDoZRdQWvY0hD1TP3KUazZve+Sg7va64sWVlZDz+HVEz2mHycwzUlU 28kTNJpxdcVs6qcLmPkhnSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjggGGMIIBgjAOBgNVHQ8BAf8E BAMCAQYwHQYDVR0OBBYEFEm3xs/oPR9/6kR7Eyn38QpwPt5kMB8GA1UdIwQYMBaAFDHDeRu69VPX F+CJei0XbAqzK50zMBIGA1UdEwEB/wQIMAYBAf8CAQIwYgYDVR0gBFswWTARBg8rBgEEAYGtIYIs AQEEAgIwEQYPKwYBBAGBrSGCLAEBBAMAMBEGDysGAQQBga0hgiwBAQQDATAPBg0rBgEEAYGtIYIs AQEEMA0GCysGAQQBga0hgiweMD4GA1UdHwQ3MDUwM6AxoC+GLWh0dHA6Ly9wa2kwMzM2LnRlbGVz ZWMuZGUvcmwvRFRfUk9PVF9DQV8yLmNybDB4BggrBgEFBQcBAQRsMGowLAYIKwYBBQUHMAGGIGh0 dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMDoGCCsGAQUFBzAChi5odHRwOi8vcGtpMDMz Ni50ZWxlc2VjLmRlL2NydC9EVF9ST09UX0NBXzIuY2VyMA0GCSqGSIb3DQEBCwUAA4IBAQBjICj9 nCGGcr45Rlk5MiW8qQGbDczKfUGchm0KbiyzE1l1sTOSG2EnFv/DstU1gvuEKgFJvWa7Zi+ywgZd bj9u4wFaW8pDY1yVtuExpx/VB19N5mWCTjL5w3x6S81NXHTuIfJ1AuxSPtLJatOQI25JZzW+f01W pOzML8+3oZeocj7JvEDWWqQIPda8gsO3tzKOsSyOam23NQIZz/U5RFhjpyQAELC7/E6vbi84u6VX ST/YblBvLJeW3B1GmmWJz67M8uXZn1OzPqEvkqnYC8aEHwTG6x7on321e6UC8STFJGMRNMxakyAq eYg6JUKQqWU7fIbTEhUjKfws2sw5W1QXMIIE1TCCA72gAwIBAgIIUE7G9T0RtGQwDQYJKoZIhvcN AQELBQAwcTELMAkGA1UEBhMCREUxHDAaBgNVBAoTE0RldXRzY2hlIFRlbGVrb20gQUcxHzAdBgNV BAsTFlQtVGVsZVNlYyBUcnVzdCBDZW50ZXIxIzAhBgNVBAMTGkRldXRzY2hlIFRlbGVrb20gUm9v dCBDQSAyMB4XDTE0MDcyMjEyMDgyNloXDTE5MDcwOTIzNTkwMFowWjELMAkGA1UEBhMCREUxEzAR BgNVBAoTCkRGTi1WZXJlaW4xEDAOBgNVBAsTB0RGTi1QS0kxJDAiBgNVBAMTG0RGTi1WZXJlaW4g UENBIEdsb2JhbCAtIEcwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOmbw2eF+Q2u 9Y1Uw5ZQNT1i6W5M7ZTXAFuVInTUIOs0j9bswDEEC5mB4qYU0lKgKCOEi3SJBF5b4OJ4wXjLFsso NTl7LZBF0O2gAHp8v0oOGwDDhulcKzERewzzgiRDjBw4i2poAJru3E94q9LGE5t2re7eJujvAa90 D8EJovZrzr3TzRQwT/Xl46TIYpuCGgMnMA0CZWBN7dEJIyqWNVgn03bGcbaQHcTt/zWGfW8zs9sP xRHCioOhlF1Ba9jSEPVM/cpRrNm975KDu9rrixZWVkPP4dUTPaYfJzDNSVTbyRM0mnF1xWzqpwuY +SGdJ68+ozk5SGqMrcmZ+8MS8r0CAwEAAaOCAYYwggGCMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4E FgQUSbfGz+g9H3/qRHsTKffxCnA+3mQwHwYDVR0jBBgwFoAUMcN5G7r1U9cX4Il6LRdsCrMrnTMw EgYDVR0TAQH/BAgwBgEB/wIBAjBiBgNVHSAEWzBZMBEGDysGAQQBga0hgiwBAQQCAjARBg8rBgEE AYGtIYIsAQEEAwAwEQYPKwYBBAGBrSGCLAEBBAMBMA8GDSsGAQQBga0hgiwBAQQwDQYLKwYBBAGB rSGCLB4wPgYDVR0fBDcwNTAzoDGgL4YtaHR0cDovL3BraTAzMzYudGVsZXNlYy5kZS9ybC9EVF9S T09UX0NBXzIuY3JsMHgGCCsGAQUFBwEBBGwwajAsBggrBgEFBQcwAYYgaHR0cDovL29jc3AwMzM2 LnRlbGVzZWMuZGUvb2NzcHIwOgYIKwYBBQUHMAKGLmh0dHA6Ly9wa2kwMzM2LnRlbGVzZWMuZGUv Y3J0L0RUX1JPT1RfQ0FfMi5jZXIwDQYJKoZIhvcNAQELBQADggEBAGMgKP2cIYZyvjlGWTkyJbyp AZsNzMp9QZyGbQpuLLMTWXWxM5IbYScW/8Oy1TWC+4QqAUm9ZrtmL7LCBl1uP27jAVpbykNjXJW2 4TGnH9UHX03mZYJOMvnDfHpLzU1cdO4h8nUC7FI+0slq05AjbklnNb5/TVak7Mwvz7ehl6hyPsm8 QNZapAg91ryCw7e3Mo6xLI5qbbc1AhnP9TlEWGOnJAAQsLv8Tq9uLzi7pVdJP9huUG8sl5bcHUaa ZYnPrszy5dmfU7M+oS+SqdgLxoQfBMbrHuiffbV7pQLxJMUkYxE0zFqTICp5iDolQpCpZTt8htMS FSMp/CzazDlbVBcwggU9MIIEJaADAgECAgcXr/adVkv+MA0GCSqGSIb3DQEBCwUAMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtE Rk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwHhcNMTQwNjA1MTQwNTAyWhcNMTkwNzA5MjM1OTAw WjBpMQswCQYDVQQGEwJERTEuMCwGA1UEChMlUGh5c2lrYWxpc2NoLVRlY2huaXNjaGUgQnVuZGVz YW5zdGFsdDEPMA0GA1UEAxMGUFRCIENBMRkwFwYJKoZIhvcNAQkBFgpwa2lAcHRiLmRlMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvArCgzkqw2LMAYuU38VJTgyGBC+Pp+uvw52LmtI6 MEMiFr0xY6SEzYcDG3z5NSohZisdnL7bu8Ee7MFD3TZX1jVBie//UNAJqXbHnUzE8hbJYCR5ydb9 WqIzoT5PzG07qJWblbidcrZVcCQEef9V1CaRyfXuqiSTOgibqODLP98N7jMIImz2ipUgMdoGyOgS h/qds5SM6CUgwMeuJ42QpYNot9ri1IKAweyhIIa3TANsu56scy+Fc2+XWOfsuImeeLcaiu6HJPk6 X55QT+kWaAoQf6qJyJXv8b/n6l1nmTIU2AY2B5EnO/rIT+DW+MJy77/HO+7rtwaznuntXMgytwID AQABo4IB9zCCAfMwEgYDVR0TAQH/BAgwBgEB/wIBATAOBgNVHQ8BAf8EBAMCAQYwEQYDVR0gBAow CDAGBgRVHSAAMB0GA1UdDgQWBBTEgNBuKBVoMVrscF94juEwQzjqNDAfBgNVHSMEGDAWgBRJt8bP 6D0ff+pEexMp9/EKcD7eZDAVBgNVHREEDjAMgQpwa2lAcHRiLmRlMIGIBgNVHR8EgYAwfjA9oDug OYY3aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY3JsL2NhY3JsLmNy bDA9oDugOYY3aHR0cDovL2NkcDIucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY3JsL2Nh Y3JsLmNybDCB1wYIKwYBBQUHAQEEgcowgccwMwYIKwYBBQUHMAGGJ2h0dHA6Ly9vY3NwLnBjYS5k Zm4uZGUvT0NTUC1TZXJ2ZXIvT0NTUDBHBggrBgEFBQcwAoY7aHR0cDovL2NkcDEucGNhLmRmbi5k ZS9nbG9iYWwtcm9vdC1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwRwYIKwYBBQUHMAKGO2h0dHA6 Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MA0G CSqGSIb3DQEBCwUAA4IBAQCo3hebMpEocLPJTOlDMAmSzpxK3SA1ftaQqodbMncOi9WkeICQlmIv rQxGCq8Be/6hKtIrbFOhRtSzQi870glJRj7dhZaHC+WOgT5tP5Nkgwpgl4k4pQDXPPrwmaI6cSYD a/LpprQzBNjEQMdQqkeanpD0WU9U1pOPFIMfIrxh2cy8mBpIAMuZqMHbMyPNDZk/YN4r3b2DcBrQ wL/tHerp6Vc7n9WqO+3cm7Fa4AxL9q2KeItyYe0Cws2KZNz4IuiMjQAclNL0PhTEqIzkD/EiK6Ag 1qcH7o3ktpmakvL2RzSZA71irCfONRgh/+ixfuMu6YA5uzyA8SYfwyFQcABdMIIFPTCCBCWgAwIB AgIHF6/2nVZL/jANBgkqhkiG9w0BAQsFADBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZOLVZl cmVpbjEQMA4GA1UECxMHREZOLVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xvYmFsIC0g RzAxMB4XDTE0MDYwNTE0MDUwMloXDTE5MDcwOTIzNTkwMFowaTELMAkGA1UEBhMCREUxLjAsBgNV BAoTJVBoeXNpa2FsaXNjaC1UZWNobmlzY2hlIEJ1bmRlc2Fuc3RhbHQxDzANBgNVBAMTBlBUQiBD QTEZMBcGCSqGSIb3DQEJARYKcGtpQHB0Yi5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALwKwoM5KsNizAGLlN/FSU4MhgQvj6frr8Odi5rSOjBDIha9MWOkhM2HAxt8+TUqIWYrHZy+ 27vBHuzBQ902V9Y1QYnv/1DQCal2x51MxPIWyWAkecnW/VqiM6E+T8xtO6iVm5W4nXK2VXAkBHn/ VdQmkcn17qokkzoIm6jgyz/fDe4zCCJs9oqVIDHaBsjoEof6nbOUjOglIMDHrieNkKWDaLfa4tSC gMHsoSCGt0wDbLuerHMvhXNvl1jn7LiJnni3GoruhyT5Ol+eUE/pFmgKEH+qiciV7/G/5+pdZ5ky FNgGNgeRJzv6yE/g1vjCcu+/xzvu67cGs57p7VzIMrcCAwEAAaOCAfcwggHzMBIGA1UdEwEB/wQI MAYBAf8CAQEwDgYDVR0PAQH/BAQDAgEGMBEGA1UdIAQKMAgwBgYEVR0gADAdBgNVHQ4EFgQUxIDQ bigVaDFa7HBfeI7hMEM46jQwHwYDVR0jBBgwFoAUSbfGz+g9H3/qRHsTKffxCnA+3mQwFQYDVR0R BA4wDIEKcGtpQHB0Yi5kZTCBiAYDVR0fBIGAMH4wPaA7oDmGN2h0dHA6Ly9jZHAxLnBjYS5kZm4u ZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NybC9jYWNybC5jcmwwPaA7oDmGN2h0dHA6Ly9jZHAyLnBj YS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NybC9jYWNybC5jcmwwgdcGCCsGAQUFBwEBBIHK MIHHMDMGCCsGAQUFBzABhidodHRwOi8vb2NzcC5wY2EuZGZuLmRlL09DU1AtU2VydmVyL09DU1Aw RwYIKwYBBQUHMAKGO2h0dHA6Ly9jZHAxLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2Nh Y2VydC9jYWNlcnQuY3J0MEcGCCsGAQUFBzAChjtodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2dsb2Jh bC1yb290LWNhL3B1Yi9jYWNlcnQvY2FjZXJ0LmNydDANBgkqhkiG9w0BAQsFAAOCAQEAqN4XmzKR KHCzyUzpQzAJks6cSt0gNX7WkKqHWzJ3DovVpHiAkJZiL60MRgqvAXv+oSrSK2xToUbUs0IvO9IJ SUY+3YWWhwvljoE+bT+TZIMKYJeJOKUA1zz68JmiOnEmA2vy6aa0MwTYxEDHUKpHmp6Q9FlPVNaT jxSDHyK8YdnMvJgaSADLmajB2zMjzQ2ZP2DeK929g3Aa0MC/7R3q6elXO5/Vqjvt3JuxWuAMS/at iniLcmHtAsLNimTc+CLojI0AHJTS9D4UxKiM5A/xIiugINanB+6N5LaZmpLy9kc0mQO9YqwnzjUY If/osX7jLumAObs8gPEmH8MhUHAAXTCCBaIwggSKoAMCAQICDBxmO6qdufc5yhZ6iDANBgkqhkiG 9w0BAQsFADBpMQswCQYDVQQGEwJERTEuMCwGA1UEChMlUGh5c2lrYWxpc2NoLVRlY2huaXNjaGUg QnVuZGVzYW5zdGFsdDEPMA0GA1UEAxMGUFRCIENBMRkwFwYJKoZIhvcNAQkBFgpwa2lAcHRiLmRl MB4XDTE2MTIwNjEzMzMxNFoXDTE5MDcwOTIzNTkwMFowaDELMAkGA1UEBhMCREUxLjAsBgNVBAoM JVBoeXNpa2FsaXNjaC1UZWNobmlzY2hlIEJ1bmRlc2Fuc3RhbHQxDTALBgNVBAsMBFEuNDIxGjAY BgNVBAMMEURyLiBEaWV0ZXIgU2lib2xkMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA +AOQrmrEQ2k8s9su/TVvmdF46YbL2MuF6OvnrjjKaJIkBvchop87cCwv80aZEbmU3as54egQEMGn NFkp1fF4bics4TJdEpND116l+jbi5DCtA3hHP/spV1aQZBDc/BDkm1Nl5WYKh/DxN6sUhZxorbb4 Y0nmSxnK2ctIwuF4Qdibsw7GE2YLvWF4tlzSCGbDjSy2agSn1wYHMsC+tAcFflcMXF2sDMZHkYuq 5IHwng8GBQFhsldYl1fk2sB2/hVRLYU205qaj13H94WjfDLuB22sT17XPJ2U/9tuFN/sxAPR0/N4 y4/IgMnOaP30VU0FMmULd7qJg0WST5D5kwgMhwIDAQABo4ICSTCCAkUwQAYDVR0gBDkwNzARBg8r BgEEAYGtIYIsAQEEAwUwEQYPKwYBBAGBrSGCLAIBBAMBMA8GDSsGAQQBga0hgiwBAQQwCQYDVR0T BAIwADAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1Ud DgQWBBQHn42zKDpvJi1bsJ4OVk2A9liUFjAfBgNVHSMEGDAWgBTEgNBuKBVoMVrscF94juEwQzjq NDBEBgNVHREEPTA7gRRkaWV0ZXIuc2lib2xkQHB0Yi5kZaAjBgorBgEEAYI3FAIDoBUME3NpYm9s ZDAxQHBhZC5wdGIuZGUwdwYDVR0fBHAwbjA1oDOgMYYvaHR0cDovL2NkcDEucGNhLmRmbi5kZS9w dGItY2EvcHViL2NybC9jYWNybC5jcmwwNaAzoDGGL2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvcHRi LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIHHBggrBgEFBQcBAQSBujCBtzAzBggrBgEFBQcwAYYnaHR0 cDovL29jc3AucGNhLmRmbi5kZS9PQ1NQLVNlcnZlci9PQ1NQMD8GCCsGAQUFBzAChjNodHRwOi8v Y2RwMS5wY2EuZGZuLmRlL3B0Yi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwPwYIKwYBBQUHMAKG M2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvcHRiLWNhL3B1Yi9jYWNlcnQvY2FjZXJ0LmNydDANBgkq hkiG9w0BAQsFAAOCAQEADaSfgrrQZx9eiQrCK7kgJMpLstro5OgIcWSpW4i4AQ1wEwyDUrdB1XWK GjA8/KwExSBP9a+dcdW+ACjX7TyURQPLqRTOkoPc9dafRx327mV4K8PE8z7fg5l2ittYNs0nXlOB QevRbYYP4XUOMYohFWfHpDwEg3ExmoArb2HaQCzKhq/2VcIIXTwaN6AVr2NVKEuH3qwpgOUSlJJ1 5ORb6TD4p1G2W6XT3jk3tOa8nRaOkI5hqpPvLfbPEibn+Bfqm6GWqpXfQ6NLAvWYcI8ltSKgdnCw Rmqdh1Ba/KWGdm41PDtQIx58vgbZGfN5GKJrp+OwS5D+/e/r296qoKUBRDCCBaIwggSKoAMCAQIC DBxmO6qdufc5yhZ6iDANBgkqhkiG9w0BAQsFADBpMQswCQYDVQQGEwJERTEuMCwGA1UEChMlUGh5 c2lrYWxpc2NoLVRlY2huaXNjaGUgQnVuZGVzYW5zdGFsdDEPMA0GA1UEAxMGUFRCIENBMRkwFwYJ KoZIhvcNAQkBFgpwa2lAcHRiLmRlMB4XDTE2MTIwNjEzMzMxNFoXDTE5MDcwOTIzNTkwMFowaDEL MAkGA1UEBhMCREUxLjAsBgNVBAoMJVBoeXNpa2FsaXNjaC1UZWNobmlzY2hlIEJ1bmRlc2Fuc3Rh bHQxDTALBgNVBAsMBFEuNDIxGjAYBgNVBAMMEURyLiBEaWV0ZXIgU2lib2xkMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA+AOQrmrEQ2k8s9su/TVvmdF46YbL2MuF6OvnrjjKaJIkBvch op87cCwv80aZEbmU3as54egQEMGnNFkp1fF4bics4TJdEpND116l+jbi5DCtA3hHP/spV1aQZBDc /BDkm1Nl5WYKh/DxN6sUhZxorbb4Y0nmSxnK2ctIwuF4Qdibsw7GE2YLvWF4tlzSCGbDjSy2agSn 1wYHMsC+tAcFflcMXF2sDMZHkYuq5IHwng8GBQFhsldYl1fk2sB2/hVRLYU205qaj13H94WjfDLu B22sT17XPJ2U/9tuFN/sxAPR0/N4y4/IgMnOaP30VU0FMmULd7qJg0WST5D5kwgMhwIDAQABo4IC STCCAkUwQAYDVR0gBDkwNzARBg8rBgEEAYGtIYIsAQEEAwUwEQYPKwYBBAGBrSGCLAIBBAMBMA8G DSsGAQQBga0hgiwBAQQwCQYDVR0TBAIwADAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYB BQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQHn42zKDpvJi1bsJ4OVk2A9liUFjAfBgNVHSMEGDAW gBTEgNBuKBVoMVrscF94juEwQzjqNDBEBgNVHREEPTA7gRRkaWV0ZXIuc2lib2xkQHB0Yi5kZaAj BgorBgEEAYI3FAIDoBUME3NpYm9sZDAxQHBhZC5wdGIuZGUwdwYDVR0fBHAwbjA1oDOgMYYvaHR0 cDovL2NkcDEucGNhLmRmbi5kZS9wdGItY2EvcHViL2NybC9jYWNybC5jcmwwNaAzoDGGL2h0dHA6 Ly9jZHAyLnBjYS5kZm4uZGUvcHRiLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIHHBggrBgEFBQcBAQSB ujCBtzAzBggrBgEFBQcwAYYnaHR0cDovL29jc3AucGNhLmRmbi5kZS9PQ1NQLVNlcnZlci9PQ1NQ MD8GCCsGAQUFBzAChjNodHRwOi8vY2RwMS5wY2EuZGZuLmRlL3B0Yi1jYS9wdWIvY2FjZXJ0L2Nh Y2VydC5jcnQwPwYIKwYBBQUHMAKGM2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvcHRiLWNhL3B1Yi9j YWNlcnQvY2FjZXJ0LmNydDANBgkqhkiG9w0BAQsFAAOCAQEADaSfgrrQZx9eiQrCK7kgJMpLstro 5OgIcWSpW4i4AQ1wEwyDUrdB1XWKGjA8/KwExSBP9a+dcdW+ACjX7TyURQPLqRTOkoPc9dafRx32 7mV4K8PE8z7fg5l2ittYNs0nXlOBQevRbYYP4XUOMYohFWfHpDwEg3ExmoArb2HaQCzKhq/2VcII XTwaN6AVr2NVKEuH3qwpgOUSlJJ15ORb6TD4p1G2W6XT3jk3tOa8nRaOkI5hqpPvLfbPEibn+Bfq m6GWqpXfQ6NLAvWYcI8ltSKgdnCwRmqdh1Ba/KWGdm41PDtQIx58vgbZGfN5GKJrp+OwS5D+/e/r 296qoKUBRDGCAuMwggLfAgEBMHkwaTELMAkGA1UEBhMCREUxLjAsBgNVBAoTJVBoeXNpa2FsaXNj aC1UZWNobmlzY2hlIEJ1bmRlc2Fuc3RhbHQxDzANBgNVBAMTBlBUQiBDQTEZMBcGCSqGSIb3DQEJ ARYKcGtpQHB0Yi5kZQIMHGY7qp259znKFnqIMA0GCWCGSAFlAwQCAQUAoIIBOzAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzA4MDgxNTQzMjdaMC8GCSqGSIb3DQEJ BDEiBCAB8E2x/2go6lje37YEd+T42WpkIhIc66A7UXvnNmSQezBDBgkqhkiG9w0BCQ8xNjA0MAcG BSsOAwIdMA4GCCqGSIb3DQMCAgIAgDAKBggqhkiG9w0DBzANBggqhkiG9w0DAgIBKDCBigYLKoZI hvcNAQkQAgsxe6B5MGkxCzAJBgNVBAYTAkRFMS4wLAYDVQQKEyVQaHlzaWthbGlzY2gtVGVjaG5p c2NoZSBCdW5kZXNhbnN0YWx0MQ8wDQYDVQQDEwZQVEIgQ0ExGTAXBgkqhkiG9w0BCQEWCnBraUBw dGIuZGUCDBxmO6qdufc5yhZ6iDANBgkqhkiG9w0BAQEFAASCAQC0hoL06awpDrN49GBZCgLba7rw XLdlD8g5sGbbbscieC5zDWZpUpZXpKBwRbgDnI1Fs/GhIGEpUrMd+r6Ss1b2HRBnyx4TfBNnMFtF 73r2DpoC0YwpT/MAJKDR2BOb5nVJdo4mZDrsTpCRt2fCniaZqBHKcqZ1mLKxlUT0mH1/0APJAuY4 am28VsUS5YEpgMQM5XJTn5ItouwPrIcN9ngNvqkrJrvPODDMPNPjVjMEV+8yyxf/FGqUtqCXUxeo MwkNnw7OcYwFtFeUkNY3o/+ivuPh9yOKahVGaCLBxlSrSgZbxnrjRqk3i0XOzHovlbB3C1k5LD7e V7KVBxQSZXFvAAAAAA== ---------z10255_boundary_sign-- --===============8262353146846299097== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg --===============8262353146846299097==-- From nobody Tue Aug 8 09:35:21 2017 Return-Path: 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 3B193132622 for ; Tue, 8 Aug 2017 09:35:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.8 X-Spam-Level: X-Spam-Status: No, score=-4.8 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, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 LNBkbqouOpbJ for ; Tue, 8 Aug 2017 09:35:17 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0077.outbound.protection.outlook.com [104.47.42.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2561E13261D for ; Tue, 8 Aug 2017 09:35:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isoc.org; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=lDub5IQE8PxDmysL7hKSNqgdDf/HLfmzX4N128xnUHM=; b=R36wEpFTNp8EluArFnjZW/1FCchTsFOvNWZ6z49LncDjmByAnQvSwxQk9n4ya83jFIWR5qNQeuX2S/Y8fATwTd/bAq2DNA99eqY0Ng7wm/2A6RSqcwaCrWotiRrIIdVchaLyDnEE12dCgvWPj8JgY/WZEK4CO5trHrIS1Zu8DeE= Received: from CY4PR06MB2456.namprd06.prod.outlook.com (10.169.186.136) by CY4PR06MB2456.namprd06.prod.outlook.com (10.169.186.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1320.16; Tue, 8 Aug 2017 16:35:15 +0000 Received: from CY4PR06MB2456.namprd06.prod.outlook.com ([10.169.186.136]) by CY4PR06MB2456.namprd06.prod.outlook.com ([10.169.186.136]) with mapi id 15.01.1320.018; Tue, 8 Aug 2017 16:35:14 +0000 From: Karen O'Donoghue To: "ntp@ietf.org" Thread-Topic: test message to ntp@ietf.org mailing list Thread-Index: AQHTEGRPOGwbPb5qeEuMQmbtJY0mSQ== Date: Tue, 8 Aug 2017 16:35:14 +0000 Message-ID: <8E4F5E91-2AB1-412B-B55D-2DC5D7067F84@isoc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=odonoghue@isoc.org; x-originating-ip: [24.245.108.20] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR06MB2456; 6:lnQC+6dQwknWo91afCE9CNcto3oyepKWCB+EaEDV0xjQKjcYWEvGEVztT1mhV635W2/SP9COuFnfuZMq9VBIJQgS2rfxTmROILZSfatxYR4LqB2AwW7Y6v3Fp1RBfcOzcZ1bU1OoYMU+mJCVxnPhEPQM+es4YUXmQ447jr6EK7ikiY1NACbCxhKs3AU3KOu8i3g9AUvXVDNN+/3ejDYtZsMIDnB3F/LicSLZOXYCd8/7wLVTaXSqAXGLsLdc8qorO966Hhc5r/AboUbzLQAZ/+OcFwsILS9VkzG7sPNzs3VGwoHYmQP088rfv27m9+JetLxakE6PGf06AbmQyyzeJA==; 5:5dn4ldE1vlDQtpvlYaOgYgE+03PiPW7T3g094qakqj+m3k/3kKKMRkElCEjV1R+35kjvaWJTE8T4hjvQJRXrJMTGB1QRXk1tAt+104UtbJjj5T1NdwsrSa1r71p02PLYGgpR7hqA5yAMUXxA3VgYAA==; 24:SdN5O89k29+jg6r6cAiVqPOTSNKT3zLZG/1e+JO7qJ5F+D4OCVFkakwwLR/3LEcQBpHC1c7FZiW++2umX0xwUFgd0oXV1/zjhX68mzyx9HE=; 7:OzJVz5+5vq6IcQ+7tq7/k0cYXKfqxYVTEV4fZPQFkdEBrEibg09CGx6cTU9FfFuwafJvbitR5gadJMOwwKtVQR0iF4NW+hsv8ys4tx5ty757KaVVMGdRryI8/uK8NFutDJbx0iTSkN1vCkGGsJeZFjYvNqQ4GW46GBcfCMDXO/Ak5hW2Vd6QecfjxCVGW8WA+rlL3yPDNAwyx7mhJzmSaxpuG0LkYCEF0/ItgQn/tyc= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 16baddaf-4584-46f4-7abe-08d4de7b7282 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603031)(49563074)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY4PR06MB2456; x-ms-traffictypediagnostic: CY4PR06MB2456: x-exchange-antispam-report-test: UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(102415395)(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(6041248)(20161123560025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123562025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR06MB2456; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR06MB2456; x-forefront-prvs: 03932714EB x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39840400002)(39400400002)(39410400002)(39450400003)(52294003)(199003)(189002)(102836003)(2501003)(6506006)(3660700001)(2906002)(99286003)(38730400002)(3280700002)(36756003)(81156014)(8676002)(81166006)(6512007)(50986999)(1730700003)(8936002)(33656002)(53936002)(54356999)(99936001)(66066001)(6486002)(101416001)(14454004)(77096006)(25786009)(6436002)(15650500001)(110136004)(478600001)(106356001)(189998001)(82746002)(86362001)(7736002)(2351001)(105586002)(5640700003)(305945005)(5660300001)(83716003)(68736007)(97736004)(558084003)(3846002)(6116002)(6916009)(2900100001)(223123001)(222073002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR06MB2456; H:CY4PR06MB2456.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: isoc.org does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; boundary="Apple-Mail=_34481424-97D8-4022-84A2-1882155A2500"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Aug 2017 16:35:14.7548 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR06MB2456 Archived-At: Subject: [Ntp] test message to ntp@ietf.org mailing list X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Aug 2017 16:35:19 -0000 --Apple-Mail=_34481424-97D8-4022-84A2-1882155A2500 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This is a test message to the ntp@ietf.org mailing list. The = subscription lists of ntpwg@elists.ntp.org and ntp@ietf.org have been = merged. There is a chance you will get duplicate messages during a short = transition period.=20 Regards, Karen --Apple-Mail=_34481424-97D8-4022-84A2-1882155A2500 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRfTCCBXQw ggRcoAMCAQICECdm7lbrSfOOq9dwovyE3iIwDQYJKoZIhvcNAQEMBQAwbzELMAkGA1UEBhMCU0Ux FDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0 d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wMDA1MzAxMDQ4Mzha Fw0yMDA1MzAxMDQ4MzhaMIGFMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDErMCkGA1UE AxMiQ09NT0RPIFJTQSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCCAiIwDQYJKoZIhvcNAQEBBQAD ggIPADCCAgoCggIBAJHoVJLSClaxrA0k3cXPRGd0mSs3o30jcABxvFPfxPoqEo9LfxBWvZ9wcrdh f8lLDxenPeOwBGHu/xGXx/SGPgr6Plz5k+Y0etkUa+ecs4Wggnp2r3GQ1+z9DfqcbPrfsIL0FH75 vsSmL09/mX+1/GdDcr0MANaJ62ss0+2PmBwUq37l42782KjkkiTaQ2tiuFX96sG8bLaL8w6NmuSb bGmZ+HhIMEXVreENPEVg/DKWUSe8Z8PKLrZr6kbHxyCgsR9l3kgIuqROqfKDRjeE6+jMgUhDZ05y KptcvUwbKIpcInu0q5jZ7uBRg8MJRk5tPpn6lRfafDNXQTyNUe0LtlyvLGMa31fIP7zpXcSbr0WZ 4qNaJLS6qVY9z2+q/0lYvvCo//S4rek3+7q49As6+ehDQh6J2ITLE/HZu+GJYLiMKFasFB2cCudx 688O3T2plqFIvTz3r7UNIkzAEYHsVjv206LiW7eyBCJSlYCTaeiOTGXxkQMtcHQC6otnFSlpUgK7 199QalVGv6CjKGF/cNDDoqosIapHziicBkV2v4IYJ7TVrrTLUOZr9EyGcTDppt8WhuDY/0Dd+9BC iH+jMzouXB5BEYFjzhhxayvspoq3MVw6akfgw3lZ1iAar/JqmKpyvFdK0kuduxD8sExB5e0dPV4o nZzMv7NR2qdH5YRTAgMBAAGjgfQwgfEwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBow HQYDVR0OBBYEFLuvfgI9+qbxPISOre44mOzZMjLUMA4GA1UdDwEB/wQEAwIBhjAPBgNVHRMBAf8E BTADAQH/MBEGA1UdIAQKMAgwBgYEVR0gADBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vY3JsLnVz ZXJ0cnVzdC5jb20vQWRkVHJ1c3RFeHRlcm5hbENBUm9vdC5jcmwwNQYIKwYBBQUHAQEEKTAnMCUG CCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBDAUAA4IBAQBk v4PxX5qF0M24oSlXDeha99HpPvJ2BG7xUnC7Hjz/TQ10asyBgiXTw6AqXUz1uouhbcRUCXXH4ycO XYR5N0ATd/W0rBzQO6sXEtbvNBh+K+l506tXRQyvKPrQ2+VQlYi734VXaX2S2FLKc4G/HPPmuG5m EQWzHpQtf5GVklnxTM6jkXFMfEcMOwsZ9qGxbIY+XKrELoLL+QeWukhNkPKUyKlzousGeyOd3qLz TVWfemFFmBhox15AayP1eXrvjLVri7dvRvR78T1LBNiTgFla4EEkHbKPFWBYR9vvbkb9FfXZX5qz 29i45ECzzZc5roW7HY683Ieb0abv8TtvEDhvMIIF5jCCA86gAwIBAgIQapvhODv/K2ufAdXZuKdS VjANBgkqhkiG9w0BAQwFADCBhTELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxKzApBgNV BAMTIkNPTU9ETyBSU0EgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTMwMTEwMDAwMDAwWhcN MjgwMTA5MjM1OTU5WjCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3Rl cjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMT NENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+s55XrCh2dUAWxzgDmNPGGHYhUPMleQtMtaDR fTpYPpynMS6n9jR22YRq2tA9NEjk6vW7rN/5sYFLIP1of3l0NKZ6fLWfF2VgJ5cijKYy/qlAckY1 wgOkUMgzKlWlVJGyK+UlNEQ1/5ErCsHq9x9aU/x1KwTdF/LCrT03Rl/FwFrf1XTCwa2QZYL55AqL PikFlgqOtzk06kb2qvGlnHJvijjI03BOrNpo+kZGpcHsgyO1/u1OZTaOo8wvEU17VVeP1cHWse9t GKTDyUGg2hJZjrqck39UIm/nKbpDSZ0JsMoIw/JtOOg0JC56VzQgBo7ictReTQE5LFLG3yQK+xS1 AgMBAAGjggE8MIIBODAfBgNVHSMEGDAWgBS7r34CPfqm8TyEjq3uOJjs2TIy1DAdBgNVHQ4EFgQU gq9sjPjF/pZhfOgfPStxSF7Ei8AwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8CAQAw EQYDVR0gBAowCDAGBgRVHSAAMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9jcmwuY29tb2RvY2Eu Y29tL0NPTU9ET1JTQUNlcnRpZmljYXRpb25BdXRob3JpdHkuY3JsMHEGCCsGAQUFBwEBBGUwYzA7 BggrBgEFBQcwAoYvaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQWRkVHJ1c3RDQS5j cnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTANBgkqhkiG9w0BAQwFAAOC AgEAeFyygSg0TzzuX1bOn5dW7I+iaxf28/ZJCAbU2C81zd9A/tNx4+jsQgwRGiHjZrAYayZrrm78 hOx7aEpkfNPQIHGG6Fvq3EzWf/Lvx7/hk6zSPwIal9v5IkDcZoFD7f3iT7PdkHJY9B51csvU50rx pEg1OyOT8fk2zvvPBuM4qQNqbGWlnhMpIMwpWZT89RY0wpJO+2V6eXEGGHsROs3njeP9DqqqAJaB a4wBeKOdGCWn1/Jp2oY6dyNmNppI4ZNMUH4Tam85S1j6E95u4+1Nuru84OrMIzqvISE2HN/56ebT OWlcrurffade2022O/tUU1gb4jfWCcyvB8czm12FgX/y/lRjmDbEA08QJNB2729Y+io1IYO3ztve BdvUCIYZojTq/OCR6MvnzS6X72HP0PRLRTiOSEmIDsS5N5w/8IW1Hva5hEFy6fDAfd9yI+O+IMMA j1KcL/Zo9jzJ16HO5m60ttl1Enk8MQkz/W3JlHaeI5iKFn4UJu1/cP2YHXYPiWf2JyBzsLBrGk1I I+3yL8aorYew6CQvdVifC3HtwlSam9V1niiCfOBe2C12TdKGu05LWIA3ZkFcWJGaNXOZ6Ggyh/Tq vXG5v7zmEVDNXFnHn9tFpMpOUvxhcsjycBtH0dZ0WrNw6gH+HF8TIhCnH3+zzWuDN0Rk6h9KVkfK ehIwggYXMIIE/6ADAgECAhEA7Elya+2wI8I16FTKprg5BDANBgkqhkiG9w0BAQsFADCBlzELMAkG A1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEa MBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1 dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTcwNjA3MDAwMDAwWhcNMjAwNjA2 MjM1OTU5WjCCAR4xCzAJBgNVBAYTAlVTMQ4wDAYDVQQREwUyMDE5MDELMAkGA1UECBMCVkExDzAN BgNVBAcTBlJlc3RvbjESMBAGA1UECRMJU3VpdGUgMjAxMRswGQYDVQQJExIxNzc1IFdpZWhsZSBB dmVudWUxGTAXBgNVBAoTEEludGVybmV0IFNvY2lldHkxNjA0BgNVBAsTLUlzc3VlZCB0aHJvdWdo IEludGVybmV0IFNvY2lldHkgRS1QS0kgTWFuYWdlcjEfMB0GA1UECxMWQ29ycG9yYXRlIFNlY3Vy ZSBFbWFpbDEZMBcGA1UEAxMQS2FyZW4gTydEb25vZ2h1ZTEhMB8GCSqGSIb3DQEJARYSb2Rvbm9n aHVlQGlzb2Mub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7RfFC2KgsSYrq1AF 0u+vPdsqXg2DLWUqba3l2oDr/W2g4yXt6JJeuc7n3Nss5Z272/wH1cnrBY0tnPM6Z2yCaY1euw8V t9eypIL40D2e4rfPWI5SI9fTuyk4U92zgqr2rpAdTuWHHZkfrsYinFUEjHU5+uneV4C04aa/6qod 68P716eYjv393TtcJRsUjSO0qBSPqFgUhZlJmonw6typ4AXvFPaplKIdbFM35dl1vegImSY6MhVm bBDmKtmGY757uyey58ajDERhyJeXf/v+3j2fbCzeqLt+vl9udzAacwqXtgTs0k7jYAcyUe9/ozoO 4zM0MqAXDO/950/ImCeliwIDAQABo4IB0jCCAc4wHwYDVR0jBBgwFoAUgq9sjPjF/pZhfOgfPStx SF7Ei8AwHQYDVR0OBBYEFKR0et8nNsxrI1af4b9X2xoCB/vxMA4GA1UdDwEB/wQEAwIFoDAMBgNV HRMBAf8EAjAAMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjBGBgNVHSAEPzA9MDsGDCsG AQQBsjEBAgEDBTArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBa BgNVHR8EUzBRME+gTaBLhklodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDbGllbnRB dXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGLBggrBgEFBQcBAQR/MH0wVQYIKwYB BQUHMAKGSWh0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNsaWVudEF1dGhlbnRpY2F0 aW9uYW5kU2VjdXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2Nh LmNvbTAdBgNVHREEFjAUgRJvZG9ub2dodWVAaXNvYy5vcmcwDQYJKoZIhvcNAQELBQADggEBAINn IsHOSDVgom6/Jf6qBKrbdPS3YDVLfubt0Vw8bz1Rjhn4ebRdi2TVDnH5E+eSxtxo6f00qC5D6IxQ g7tqyqiKPyrAOwGwG9iohcGaR4rPD1okqiclq+y/5BPGe2Lqd1sQs57PEzlav4BKzcRkHCU+U8KW Ib13t9TcSNZjxZxvWgPchCWMIJB4hBEpeNcsVV2BGEagGRAzFyf36CWiP0XlY5TAhbTXQYubjD8Y E95GoQoCsiHo6BmTz5Zi7VCDTw9Zhxn0shiZO4GcwxbaUNQL7Iqp6JzFRrBGRt+QZMdQoaQ/N44N tTpnfxp/4QKOnpB88yCgROCdqZCSZ4+WUzwxggO6MIIDtgIBATCBrTCBlzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0 aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQDsSXJr7bAjwjXoVMqmuDkEMAkGBSsOAwIaBQCgggHh MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE3MDgwODE2MzUyM1ow IwYJKoZIhvcNAQkEMRYEFAvcuRgPIch3nNoszv8D5C+4n2T9MIG+BgkrBgEEAYI3EAQxgbAwga0w gZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1Nh bGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEA7Elya+2wI8I16FTKprg5 BDCBwAYLKoZIhvcNAQkQAgsxgbCgga0wgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVk MT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVt YWlsIENBAhEA7Elya+2wI8I16FTKprg5BDANBgkqhkiG9w0BAQEFAASCAQCcr8oJaf3CqQorRxqf pqgnpRgaaHFfegUfYsgD1HJ87mvlJ/zG8Tccbelad7pOeXTwsTW9dN0KoV4RhyB42mirsJ0HP+4/ /Th7tyQnkgNKyn2zG8k7EvvguIWrtMdCg5T5QcVj2pDV0nOwWwjMgxA+7/pBwRJpyM5+3o4mTue+ FsrwYdn/G9l2D/unBEIWfI8PwNopTfDWZ3mganerT8q8YDLrPkUfqUan1FrQc6L/KaeNAc/Q8MOR 3yVi45KzUboTaWKkaho+cpYnKDs8vHP1SnPXF7RQ/yNcHeK53MAeTOFYfHYhX3gnseKGn3HhmKbj APxxOrMMbIqUEBcbxJUEAAAAAAAA --Apple-Mail=_34481424-97D8-4022-84A2-1882155A2500-- From ntp-bounces@ietf.org Tue Aug 8 09:35:21 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C03F13264F; Tue, 8 Aug 2017 09:35:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1502210121; bh=EZ1TMH1EZML5ygeKfEwi7TF6XFiKt5AHRgFXOMwk1F0=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=trhHqIm4UavtMPFylSRfLa2qCK7UB3qZK0L9JQVv9qvKG1O4znRctCjBIDCdFLKg0 qEiotop9RVbaf9i0qcgM+nxE5jYVLGKB+DZd9QX06u09gAXkHejbIocAs+0zgK7Jmq y3eTlbWr2shveZIu1meaGmjYseI3wn29Nhy+LQZs= 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 3B193132622 for ; Tue, 8 Aug 2017 09:35:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.8 X-Spam-Level: X-Spam-Status: No, score=-4.8 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, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 LNBkbqouOpbJ for ; Tue, 8 Aug 2017 09:35:17 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0077.outbound.protection.outlook.com [104.47.42.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2561E13261D for ; Tue, 8 Aug 2017 09:35:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isoc.org; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=lDub5IQE8PxDmysL7hKSNqgdDf/HLfmzX4N128xnUHM=; b=R36wEpFTNp8EluArFnjZW/1FCchTsFOvNWZ6z49LncDjmByAnQvSwxQk9n4ya83jFIWR5qNQeuX2S/Y8fATwTd/bAq2DNA99eqY0Ng7wm/2A6RSqcwaCrWotiRrIIdVchaLyDnEE12dCgvWPj8JgY/WZEK4CO5trHrIS1Zu8DeE= Received: from CY4PR06MB2456.namprd06.prod.outlook.com (10.169.186.136) by CY4PR06MB2456.namprd06.prod.outlook.com (10.169.186.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1320.16; Tue, 8 Aug 2017 16:35:15 +0000 Received: from CY4PR06MB2456.namprd06.prod.outlook.com ([10.169.186.136]) by CY4PR06MB2456.namprd06.prod.outlook.com ([10.169.186.136]) with mapi id 15.01.1320.018; Tue, 8 Aug 2017 16:35:14 +0000 From: Karen O'Donoghue To: "ntp@ietf.org" Thread-Topic: test message to ntp@ietf.org mailing list Thread-Index: AQHTEGRPOGwbPb5qeEuMQmbtJY0mSQ== Date: Tue, 8 Aug 2017 16:35:14 +0000 Message-ID: <8E4F5E91-2AB1-412B-B55D-2DC5D7067F84@isoc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=odonoghue@isoc.org; x-originating-ip: [24.245.108.20] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR06MB2456; 6:lnQC+6dQwknWo91afCE9CNcto3oyepKWCB+EaEDV0xjQKjcYWEvGEVztT1mhV635W2/SP9COuFnfuZMq9VBIJQgS2rfxTmROILZSfatxYR4LqB2AwW7Y6v3Fp1RBfcOzcZ1bU1OoYMU+mJCVxnPhEPQM+es4YUXmQ447jr6EK7ikiY1NACbCxhKs3AU3KOu8i3g9AUvXVDNN+/3ejDYtZsMIDnB3F/LicSLZOXYCd8/7wLVTaXSqAXGLsLdc8qorO966Hhc5r/AboUbzLQAZ/+OcFwsILS9VkzG7sPNzs3VGwoHYmQP088rfv27m9+JetLxakE6PGf06AbmQyyzeJA==; 5:5dn4ldE1vlDQtpvlYaOgYgE+03PiPW7T3g094qakqj+m3k/3kKKMRkElCEjV1R+35kjvaWJTE8T4hjvQJRXrJMTGB1QRXk1tAt+104UtbJjj5T1NdwsrSa1r71p02PLYGgpR7hqA5yAMUXxA3VgYAA==; 24:SdN5O89k29+jg6r6cAiVqPOTSNKT3zLZG/1e+JO7qJ5F+D4OCVFkakwwLR/3LEcQBpHC1c7FZiW++2umX0xwUFgd0oXV1/zjhX68mzyx9HE=; 7:OzJVz5+5vq6IcQ+7tq7/k0cYXKfqxYVTEV4fZPQFkdEBrEibg09CGx6cTU9FfFuwafJvbitR5gadJMOwwKtVQR0iF4NW+hsv8ys4tx5ty757KaVVMGdRryI8/uK8NFutDJbx0iTSkN1vCkGGsJeZFjYvNqQ4GW46GBcfCMDXO/Ak5hW2Vd6QecfjxCVGW8WA+rlL3yPDNAwyx7mhJzmSaxpuG0LkYCEF0/ItgQn/tyc= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 16baddaf-4584-46f4-7abe-08d4de7b7282 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603031)(49563074)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY4PR06MB2456; x-ms-traffictypediagnostic: CY4PR06MB2456: x-exchange-antispam-report-test: UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(102415395)(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(6041248)(20161123560025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123562025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR06MB2456; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR06MB2456; x-forefront-prvs: 03932714EB x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39840400002)(39400400002)(39410400002)(39450400003)(52294003)(199003)(189002)(102836003)(2501003)(6506006)(3660700001)(2906002)(99286003)(38730400002)(3280700002)(36756003)(81156014)(8676002)(81166006)(6512007)(50986999)(1730700003)(8936002)(33656002)(53936002)(54356999)(99936001)(66066001)(6486002)(101416001)(14454004)(77096006)(25786009)(6436002)(15650500001)(110136004)(478600001)(106356001)(189998001)(82746002)(86362001)(7736002)(2351001)(105586002)(5640700003)(305945005)(5660300001)(83716003)(68736007)(97736004)(558084003)(3846002)(6116002)(6916009)(2900100001)(223123001)(222073002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR06MB2456; H:CY4PR06MB2456.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: isoc.org does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Aug 2017 16:35:14.7548 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR06MB2456 Archived-At: Subject: [Ntp] test message to ntp@ietf.org mailing list X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============7768154432969221616==" Errors-To: ntp-bounces@ietf.org Sender: "ntp" --===============7768154432969221616== Content-Language: en-US Content-Type: multipart/signed; boundary="Apple-Mail=_34481424-97D8-4022-84A2-1882155A2500"; protocol="application/pkcs7-signature"; micalg=sha1 --Apple-Mail=_34481424-97D8-4022-84A2-1882155A2500 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This is a test message to the ntp@ietf.org mailing list. The = subscription lists of ntpwg@elists.ntp.org and ntp@ietf.org have been = merged. There is a chance you will get duplicate messages during a short = transition period.=20 Regards, Karen --Apple-Mail=_34481424-97D8-4022-84A2-1882155A2500 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRfTCCBXQw ggRcoAMCAQICECdm7lbrSfOOq9dwovyE3iIwDQYJKoZIhvcNAQEMBQAwbzELMAkGA1UEBhMCU0Ux FDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0 d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wMDA1MzAxMDQ4Mzha Fw0yMDA1MzAxMDQ4MzhaMIGFMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDErMCkGA1UE AxMiQ09NT0RPIFJTQSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCCAiIwDQYJKoZIhvcNAQEBBQAD ggIPADCCAgoCggIBAJHoVJLSClaxrA0k3cXPRGd0mSs3o30jcABxvFPfxPoqEo9LfxBWvZ9wcrdh f8lLDxenPeOwBGHu/xGXx/SGPgr6Plz5k+Y0etkUa+ecs4Wggnp2r3GQ1+z9DfqcbPrfsIL0FH75 vsSmL09/mX+1/GdDcr0MANaJ62ss0+2PmBwUq37l42782KjkkiTaQ2tiuFX96sG8bLaL8w6NmuSb bGmZ+HhIMEXVreENPEVg/DKWUSe8Z8PKLrZr6kbHxyCgsR9l3kgIuqROqfKDRjeE6+jMgUhDZ05y KptcvUwbKIpcInu0q5jZ7uBRg8MJRk5tPpn6lRfafDNXQTyNUe0LtlyvLGMa31fIP7zpXcSbr0WZ 4qNaJLS6qVY9z2+q/0lYvvCo//S4rek3+7q49As6+ehDQh6J2ITLE/HZu+GJYLiMKFasFB2cCudx 688O3T2plqFIvTz3r7UNIkzAEYHsVjv206LiW7eyBCJSlYCTaeiOTGXxkQMtcHQC6otnFSlpUgK7 199QalVGv6CjKGF/cNDDoqosIapHziicBkV2v4IYJ7TVrrTLUOZr9EyGcTDppt8WhuDY/0Dd+9BC iH+jMzouXB5BEYFjzhhxayvspoq3MVw6akfgw3lZ1iAar/JqmKpyvFdK0kuduxD8sExB5e0dPV4o nZzMv7NR2qdH5YRTAgMBAAGjgfQwgfEwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBow HQYDVR0OBBYEFLuvfgI9+qbxPISOre44mOzZMjLUMA4GA1UdDwEB/wQEAwIBhjAPBgNVHRMBAf8E BTADAQH/MBEGA1UdIAQKMAgwBgYEVR0gADBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vY3JsLnVz ZXJ0cnVzdC5jb20vQWRkVHJ1c3RFeHRlcm5hbENBUm9vdC5jcmwwNQYIKwYBBQUHAQEEKTAnMCUG CCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBDAUAA4IBAQBk v4PxX5qF0M24oSlXDeha99HpPvJ2BG7xUnC7Hjz/TQ10asyBgiXTw6AqXUz1uouhbcRUCXXH4ycO XYR5N0ATd/W0rBzQO6sXEtbvNBh+K+l506tXRQyvKPrQ2+VQlYi734VXaX2S2FLKc4G/HPPmuG5m EQWzHpQtf5GVklnxTM6jkXFMfEcMOwsZ9qGxbIY+XKrELoLL+QeWukhNkPKUyKlzousGeyOd3qLz TVWfemFFmBhox15AayP1eXrvjLVri7dvRvR78T1LBNiTgFla4EEkHbKPFWBYR9vvbkb9FfXZX5qz 29i45ECzzZc5roW7HY683Ieb0abv8TtvEDhvMIIF5jCCA86gAwIBAgIQapvhODv/K2ufAdXZuKdS VjANBgkqhkiG9w0BAQwFADCBhTELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxKzApBgNV BAMTIkNPTU9ETyBSU0EgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTMwMTEwMDAwMDAwWhcN MjgwMTA5MjM1OTU5WjCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3Rl cjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMT NENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+s55XrCh2dUAWxzgDmNPGGHYhUPMleQtMtaDR fTpYPpynMS6n9jR22YRq2tA9NEjk6vW7rN/5sYFLIP1of3l0NKZ6fLWfF2VgJ5cijKYy/qlAckY1 wgOkUMgzKlWlVJGyK+UlNEQ1/5ErCsHq9x9aU/x1KwTdF/LCrT03Rl/FwFrf1XTCwa2QZYL55AqL PikFlgqOtzk06kb2qvGlnHJvijjI03BOrNpo+kZGpcHsgyO1/u1OZTaOo8wvEU17VVeP1cHWse9t GKTDyUGg2hJZjrqck39UIm/nKbpDSZ0JsMoIw/JtOOg0JC56VzQgBo7ictReTQE5LFLG3yQK+xS1 AgMBAAGjggE8MIIBODAfBgNVHSMEGDAWgBS7r34CPfqm8TyEjq3uOJjs2TIy1DAdBgNVHQ4EFgQU gq9sjPjF/pZhfOgfPStxSF7Ei8AwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8CAQAw EQYDVR0gBAowCDAGBgRVHSAAMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9jcmwuY29tb2RvY2Eu Y29tL0NPTU9ET1JTQUNlcnRpZmljYXRpb25BdXRob3JpdHkuY3JsMHEGCCsGAQUFBwEBBGUwYzA7 BggrBgEFBQcwAoYvaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQWRkVHJ1c3RDQS5j cnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTANBgkqhkiG9w0BAQwFAAOC AgEAeFyygSg0TzzuX1bOn5dW7I+iaxf28/ZJCAbU2C81zd9A/tNx4+jsQgwRGiHjZrAYayZrrm78 hOx7aEpkfNPQIHGG6Fvq3EzWf/Lvx7/hk6zSPwIal9v5IkDcZoFD7f3iT7PdkHJY9B51csvU50rx pEg1OyOT8fk2zvvPBuM4qQNqbGWlnhMpIMwpWZT89RY0wpJO+2V6eXEGGHsROs3njeP9DqqqAJaB a4wBeKOdGCWn1/Jp2oY6dyNmNppI4ZNMUH4Tam85S1j6E95u4+1Nuru84OrMIzqvISE2HN/56ebT OWlcrurffade2022O/tUU1gb4jfWCcyvB8czm12FgX/y/lRjmDbEA08QJNB2729Y+io1IYO3ztve BdvUCIYZojTq/OCR6MvnzS6X72HP0PRLRTiOSEmIDsS5N5w/8IW1Hva5hEFy6fDAfd9yI+O+IMMA j1KcL/Zo9jzJ16HO5m60ttl1Enk8MQkz/W3JlHaeI5iKFn4UJu1/cP2YHXYPiWf2JyBzsLBrGk1I I+3yL8aorYew6CQvdVifC3HtwlSam9V1niiCfOBe2C12TdKGu05LWIA3ZkFcWJGaNXOZ6Ggyh/Tq vXG5v7zmEVDNXFnHn9tFpMpOUvxhcsjycBtH0dZ0WrNw6gH+HF8TIhCnH3+zzWuDN0Rk6h9KVkfK ehIwggYXMIIE/6ADAgECAhEA7Elya+2wI8I16FTKprg5BDANBgkqhkiG9w0BAQsFADCBlzELMAkG A1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEa MBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1 dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTcwNjA3MDAwMDAwWhcNMjAwNjA2 MjM1OTU5WjCCAR4xCzAJBgNVBAYTAlVTMQ4wDAYDVQQREwUyMDE5MDELMAkGA1UECBMCVkExDzAN BgNVBAcTBlJlc3RvbjESMBAGA1UECRMJU3VpdGUgMjAxMRswGQYDVQQJExIxNzc1IFdpZWhsZSBB dmVudWUxGTAXBgNVBAoTEEludGVybmV0IFNvY2lldHkxNjA0BgNVBAsTLUlzc3VlZCB0aHJvdWdo IEludGVybmV0IFNvY2lldHkgRS1QS0kgTWFuYWdlcjEfMB0GA1UECxMWQ29ycG9yYXRlIFNlY3Vy ZSBFbWFpbDEZMBcGA1UEAxMQS2FyZW4gTydEb25vZ2h1ZTEhMB8GCSqGSIb3DQEJARYSb2Rvbm9n aHVlQGlzb2Mub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7RfFC2KgsSYrq1AF 0u+vPdsqXg2DLWUqba3l2oDr/W2g4yXt6JJeuc7n3Nss5Z272/wH1cnrBY0tnPM6Z2yCaY1euw8V t9eypIL40D2e4rfPWI5SI9fTuyk4U92zgqr2rpAdTuWHHZkfrsYinFUEjHU5+uneV4C04aa/6qod 68P716eYjv393TtcJRsUjSO0qBSPqFgUhZlJmonw6typ4AXvFPaplKIdbFM35dl1vegImSY6MhVm bBDmKtmGY757uyey58ajDERhyJeXf/v+3j2fbCzeqLt+vl9udzAacwqXtgTs0k7jYAcyUe9/ozoO 4zM0MqAXDO/950/ImCeliwIDAQABo4IB0jCCAc4wHwYDVR0jBBgwFoAUgq9sjPjF/pZhfOgfPStx SF7Ei8AwHQYDVR0OBBYEFKR0et8nNsxrI1af4b9X2xoCB/vxMA4GA1UdDwEB/wQEAwIFoDAMBgNV HRMBAf8EAjAAMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjBGBgNVHSAEPzA9MDsGDCsG AQQBsjEBAgEDBTArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBa BgNVHR8EUzBRME+gTaBLhklodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDbGllbnRB dXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGLBggrBgEFBQcBAQR/MH0wVQYIKwYB BQUHMAKGSWh0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNsaWVudEF1dGhlbnRpY2F0 aW9uYW5kU2VjdXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2Nh LmNvbTAdBgNVHREEFjAUgRJvZG9ub2dodWVAaXNvYy5vcmcwDQYJKoZIhvcNAQELBQADggEBAINn IsHOSDVgom6/Jf6qBKrbdPS3YDVLfubt0Vw8bz1Rjhn4ebRdi2TVDnH5E+eSxtxo6f00qC5D6IxQ g7tqyqiKPyrAOwGwG9iohcGaR4rPD1okqiclq+y/5BPGe2Lqd1sQs57PEzlav4BKzcRkHCU+U8KW Ib13t9TcSNZjxZxvWgPchCWMIJB4hBEpeNcsVV2BGEagGRAzFyf36CWiP0XlY5TAhbTXQYubjD8Y E95GoQoCsiHo6BmTz5Zi7VCDTw9Zhxn0shiZO4GcwxbaUNQL7Iqp6JzFRrBGRt+QZMdQoaQ/N44N tTpnfxp/4QKOnpB88yCgROCdqZCSZ4+WUzwxggO6MIIDtgIBATCBrTCBlzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0 aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQDsSXJr7bAjwjXoVMqmuDkEMAkGBSsOAwIaBQCgggHh MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE3MDgwODE2MzUyM1ow IwYJKoZIhvcNAQkEMRYEFAvcuRgPIch3nNoszv8D5C+4n2T9MIG+BgkrBgEEAYI3EAQxgbAwga0w gZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1Nh bGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEA7Elya+2wI8I16FTKprg5 BDCBwAYLKoZIhvcNAQkQAgsxgbCgga0wgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVk MT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVt YWlsIENBAhEA7Elya+2wI8I16FTKprg5BDANBgkqhkiG9w0BAQEFAASCAQCcr8oJaf3CqQorRxqf pqgnpRgaaHFfegUfYsgD1HJ87mvlJ/zG8Tccbelad7pOeXTwsTW9dN0KoV4RhyB42mirsJ0HP+4/ /Th7tyQnkgNKyn2zG8k7EvvguIWrtMdCg5T5QcVj2pDV0nOwWwjMgxA+7/pBwRJpyM5+3o4mTue+ FsrwYdn/G9l2D/unBEIWfI8PwNopTfDWZ3mganerT8q8YDLrPkUfqUan1FrQc6L/KaeNAc/Q8MOR 3yVi45KzUboTaWKkaho+cpYnKDs8vHP1SnPXF7RQ/yNcHeK53MAeTOFYfHYhX3gnseKGn3HhmKbj APxxOrMMbIqUEBcbxJUEAAAAAAAA --Apple-Mail=_34481424-97D8-4022-84A2-1882155A2500-- --===============7768154432969221616== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp --===============7768154432969221616==-- From nobody Tue Aug 8 21:41:30 2017 Return-Path: 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 592E4124B18; Tue, 8 Aug 2017 21:41:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham 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 ZwW5JzhHUYnq; Tue, 8 Aug 2017 21:41:27 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0059.outbound.protection.outlook.com [104.47.41.59]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10137120227; Tue, 8 Aug 2017 21:41:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isoc.org; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=E6rieNTK7owDK6oIUrbs9o++SbtPlko8N2N+mbTco+0=; b=1F750X7JWBpSdfdS8or/yIl3s7d9Ow4cs0CmL9cVUSNOKp3kMMK0Nlu/jZvGJqc36/rgY2f9pHGOHaRn+s9xRljRVR8AWeIuo8h+1LfS4IO4E1hZWmM6yxaFRylyIcp6w7IKUv0p5bQ6J+sYdm07qvyw7ulXHGwhVGbYxNtsMMY= Received: from CY4PR06MB2456.namprd06.prod.outlook.com (10.169.186.136) by CY4PR06MB2453.namprd06.prod.outlook.com (10.169.185.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1320.16; Wed, 9 Aug 2017 04:41:25 +0000 Received: from CY4PR06MB2456.namprd06.prod.outlook.com ([10.169.186.136]) by CY4PR06MB2456.namprd06.prod.outlook.com ([10.169.186.136]) with mapi id 15.01.1320.018; Wed, 9 Aug 2017 04:41:25 +0000 From: Karen O'Donoghue To: "ntp@ietf.org" CC: "tictoc@ietf.org" Thread-Topic: WGLC for draft-ietf-ntp-using-nts-for-ntp Thread-Index: AQHTEMnCM2s3Nc34m0O8jzUH1rPjTg== Date: Wed, 9 Aug 2017 04:41:25 +0000 Message-ID: <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> 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: [24.245.108.20] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR06MB2453; 6:UYP1m4x0PJa1Ln7fPgc610YZGyYceDJHjvFwhtBL6V90/ip+yapMKxih1bjvlqhxuPRIUr7DPqgxZZqIFgGyNTeCbtWzjyXn7pj8ykmS+HYERSA/7nmdDqTdXr4DjHJStdux6pPqqgTKRd6t32PIuZxcpTydDtFQU/EIW1sRdtGnE3NC5F2kxjzwIAYFsQVozOB/MsKiASXpqZwXI0HuKc3IugirC+8+1tRDWzj5mdMXwGTIZRDfo9lg3+4mcn0TsoEaPYOkdKaqtxxi0w0PNy4c7lsrKiwXN6ANSInlDbkoc59LMRibZ2YznFrZ8pCJAtf3111AwckTaSwf3yfQzQ==; 5:wPmQKHB05avhykCbWmhexZpGsmsf9Pm9MdC7Tm+KiNGsKvuQ/AlzM0aDcPO7Q58Ie9l1lGlJ2+dbx8ZAJSfTiZX5DECSpd1DDJhLRLYk0lCaopMoi9x9OKxLmMIu0WBWwQ7MJ87xiv/j6JIKUbMqrw==; 24:dqrW0kiUBnsM29KDBvGyWNTo1OTOdEZJerzSVZW9Aj6sCDMkOcoq7EZewlWWQEXKTo/qb4g7sG2kz4h3bU1psKOqdRXyEVToDWsk4MJfnS0=; 7:s5yq3TkUeM0gOagrCgTZc5fWJTjZOnnG+oSK/qAv6IqWWr4O6/kl9Y7Hru/+nmQlfWQCpb9seAmT2Kqig+ge+JAdNIRSTHqALMxznmX6xowJvxnpLlTAonQ70NxPWUrAWvT0DVzqLTcBbKIj/VQbzR1QQmghryrfHnomT0QiFYsMoVfBSBLRO1dKvnv97LrDEeyHp1snErytnOO/A7mhwarrv5qed+nTL0sNTOEKmaw= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 988901fc-245d-44c4-80a7-08d4dee0e4b1 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY4PR06MB2453; x-ms-traffictypediagnostic: CY4PR06MB2453: x-exchange-antispam-report-test: UriScan:(120809045254105)(192374486261705)(100405760836317); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(93006095)(93001095)(100000703101)(100105400095)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123555025)(20161123564025)(20161123562025)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR06MB2453; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR06MB2453; x-forefront-prvs: 0394259C80 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39400400002)(39450400003)(39410400002)(39830400002)(189002)(199003)(3280700002)(81166006)(6116002)(68736007)(106356001)(230783001)(478600001)(2501003)(50986999)(101416001)(6436002)(5660300001)(54356999)(99286003)(14454004)(2900100001)(450100002)(97736004)(82746002)(305945005)(3846002)(102836003)(966005)(66066001)(25786009)(189998001)(6916009)(3660700001)(105586002)(4326008)(7736002)(53936002)(81156014)(2351001)(2906002)(110136004)(36756003)(6506006)(6512007)(1730700003)(5640700003)(6306002)(8676002)(33656002)(77096006)(83716003)(8936002)(38730400002)(6486002)(86362001); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR06MB2453; H:CY4PR06MB2456.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: isoc.org does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <0B8DA16F51715641A0342C081BDB1260@namprd06.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Aug 2017 04:41:25.6336 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR06MB2453 Archived-At: Subject: [Ntp] WGLC for draft-ietf-ntp-using-nts-for-ntp X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Aug 2017 04:41:29 -0000 Rm9sa3MsDQoNClRoaXMgYmVnaW5zIGEgdGhyZWUgd2VlayB3b3JraW5nIGdyb3VwIGxhc3QgY2Fs bCAoV0dMQykgZm9yICJOZXR3b3JrIFRpbWUgU2VjdXJpdHkgZm9yIHRoZSBOZXR3b3JrIFRpbWUg UHJvdG9jb2zigJ0uDQoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWll dGYtbnRwLXVzaW5nLW50cy1mb3ItbnRwLw0KDQpQbGVhc2UgcmV2aWV3IGFuZCBwcm92aWRlIGNv bW1lbnRzIHRvIHRoZSBtYWlsaW5nIGxpc3QgYnkgbm8gbGF0ZXIgdGhhbiAzMSBBdWd1c3QgMjAx Ny4gRWFybGllciBjb21tZW50cyBhbmQgZGlzY3Vzc2lvbiB3b3VsZCBiZSBhcHByZWNpYXRlZC4g UGxlYXNlIG5vdGUgdGhhdCB0aGUgY2hhaXJzIHdpbGwgYmUgdXNpbmcgdGhpcyBXR0xDIHRvIGRl dGVybWluZSBjb25zZW5zdXMgdG8gbW92ZSB0aGlzIGRvY3VtZW50IGZvcndhcmQgdG8gdGhlIElF U0cuIA0KDQpBbHNvLCBhcyBhIHJlbWluZGVyLCB3ZSBoYXZlIG1pZ3JhdGVkIHRoZSB3b3JraW5n IGdyb3VwIG1haWxpbmcgbGlzdCB0byBJRVRGIGluZnJhc3RydWN0dXJlLiBQbGVhc2UgcmVzcG9u ZCB0byBudHBAaWV0Zi5vcmcuIF0NCg0KUmVnYXJkcywNCkthcmVuIGFuZCBEaWV0ZXI= From ntp-bounces@ietf.org Tue Aug 8 21:41:31 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DBE6D124B18; Tue, 8 Aug 2017 21:41:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1502253690; bh=xEjtoa5Us8wB9u1AAH/kmP2Xg4yaH0TUqsqRbjAVvio=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Cc; b=DEqYuUMpM6bh8R12UVomxmbCMUl0ix4UnSXLt+kA3GedEc1fcxL7GtBNclzdiAzq/ XCq2i9S2E3EV+ci8/gJZEyzzj2OOYKE2NXUStyINjPf1X8zU6k1ozeAW6w1qY88xX9 cQ1IVE5pO4DPBGJdoRfbS9qxaUPTiKAShWK9Bcb0= 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 592E4124B18; Tue, 8 Aug 2017 21:41:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham 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 ZwW5JzhHUYnq; Tue, 8 Aug 2017 21:41:27 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0059.outbound.protection.outlook.com [104.47.41.59]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10137120227; Tue, 8 Aug 2017 21:41:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isoc.org; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=E6rieNTK7owDK6oIUrbs9o++SbtPlko8N2N+mbTco+0=; b=1F750X7JWBpSdfdS8or/yIl3s7d9Ow4cs0CmL9cVUSNOKp3kMMK0Nlu/jZvGJqc36/rgY2f9pHGOHaRn+s9xRljRVR8AWeIuo8h+1LfS4IO4E1hZWmM6yxaFRylyIcp6w7IKUv0p5bQ6J+sYdm07qvyw7ulXHGwhVGbYxNtsMMY= Received: from CY4PR06MB2456.namprd06.prod.outlook.com (10.169.186.136) by CY4PR06MB2453.namprd06.prod.outlook.com (10.169.185.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1320.16; Wed, 9 Aug 2017 04:41:25 +0000 Received: from CY4PR06MB2456.namprd06.prod.outlook.com ([10.169.186.136]) by CY4PR06MB2456.namprd06.prod.outlook.com ([10.169.186.136]) with mapi id 15.01.1320.018; Wed, 9 Aug 2017 04:41:25 +0000 From: Karen O'Donoghue To: "ntp@ietf.org" Thread-Topic: WGLC for draft-ietf-ntp-using-nts-for-ntp Thread-Index: AQHTEMnCM2s3Nc34m0O8jzUH1rPjTg== Date: Wed, 9 Aug 2017 04:41:25 +0000 Message-ID: <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> 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: [24.245.108.20] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR06MB2453; 6:UYP1m4x0PJa1Ln7fPgc610YZGyYceDJHjvFwhtBL6V90/ip+yapMKxih1bjvlqhxuPRIUr7DPqgxZZqIFgGyNTeCbtWzjyXn7pj8ykmS+HYERSA/7nmdDqTdXr4DjHJStdux6pPqqgTKRd6t32PIuZxcpTydDtFQU/EIW1sRdtGnE3NC5F2kxjzwIAYFsQVozOB/MsKiASXpqZwXI0HuKc3IugirC+8+1tRDWzj5mdMXwGTIZRDfo9lg3+4mcn0TsoEaPYOkdKaqtxxi0w0PNy4c7lsrKiwXN6ANSInlDbkoc59LMRibZ2YznFrZ8pCJAtf3111AwckTaSwf3yfQzQ==; 5:wPmQKHB05avhykCbWmhexZpGsmsf9Pm9MdC7Tm+KiNGsKvuQ/AlzM0aDcPO7Q58Ie9l1lGlJ2+dbx8ZAJSfTiZX5DECSpd1DDJhLRLYk0lCaopMoi9x9OKxLmMIu0WBWwQ7MJ87xiv/j6JIKUbMqrw==; 24:dqrW0kiUBnsM29KDBvGyWNTo1OTOdEZJerzSVZW9Aj6sCDMkOcoq7EZewlWWQEXKTo/qb4g7sG2kz4h3bU1psKOqdRXyEVToDWsk4MJfnS0=; 7:s5yq3TkUeM0gOagrCgTZc5fWJTjZOnnG+oSK/qAv6IqWWr4O6/kl9Y7Hru/+nmQlfWQCpb9seAmT2Kqig+ge+JAdNIRSTHqALMxznmX6xowJvxnpLlTAonQ70NxPWUrAWvT0DVzqLTcBbKIj/VQbzR1QQmghryrfHnomT0QiFYsMoVfBSBLRO1dKvnv97LrDEeyHp1snErytnOO/A7mhwarrv5qed+nTL0sNTOEKmaw= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 988901fc-245d-44c4-80a7-08d4dee0e4b1 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY4PR06MB2453; x-ms-traffictypediagnostic: CY4PR06MB2453: x-exchange-antispam-report-test: UriScan:(120809045254105)(192374486261705)(100405760836317); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(93006095)(93001095)(100000703101)(100105400095)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123555025)(20161123564025)(20161123562025)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR06MB2453; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR06MB2453; x-forefront-prvs: 0394259C80 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39400400002)(39450400003)(39410400002)(39830400002)(189002)(199003)(3280700002)(81166006)(6116002)(68736007)(106356001)(230783001)(478600001)(2501003)(50986999)(101416001)(6436002)(5660300001)(54356999)(99286003)(14454004)(2900100001)(450100002)(97736004)(82746002)(305945005)(3846002)(102836003)(966005)(66066001)(25786009)(189998001)(6916009)(3660700001)(105586002)(4326008)(7736002)(53936002)(81156014)(2351001)(2906002)(110136004)(36756003)(6506006)(6512007)(1730700003)(5640700003)(6306002)(8676002)(33656002)(77096006)(83716003)(8936002)(38730400002)(6486002)(86362001); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR06MB2453; H:CY4PR06MB2456.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: isoc.org does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: <0B8DA16F51715641A0342C081BDB1260@namprd06.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Aug 2017 04:41:25.6336 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR06MB2453 Archived-At: Subject: [Ntp] WGLC for draft-ietf-ntp-using-nts-for-ntp X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "tictoc@ietf.org" Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Errors-To: ntp-bounces@ietf.org Sender: "ntp" Rm9sa3MsDQoNClRoaXMgYmVnaW5zIGEgdGhyZWUgd2VlayB3b3JraW5nIGdyb3VwIGxhc3QgY2Fs bCAoV0dMQykgZm9yICJOZXR3b3JrIFRpbWUgU2VjdXJpdHkgZm9yIHRoZSBOZXR3b3JrIFRpbWUg UHJvdG9jb2zigJ0uDQoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWll dGYtbnRwLXVzaW5nLW50cy1mb3ItbnRwLw0KDQpQbGVhc2UgcmV2aWV3IGFuZCBwcm92aWRlIGNv bW1lbnRzIHRvIHRoZSBtYWlsaW5nIGxpc3QgYnkgbm8gbGF0ZXIgdGhhbiAzMSBBdWd1c3QgMjAx Ny4gRWFybGllciBjb21tZW50cyBhbmQgZGlzY3Vzc2lvbiB3b3VsZCBiZSBhcHByZWNpYXRlZC4g UGxlYXNlIG5vdGUgdGhhdCB0aGUgY2hhaXJzIHdpbGwgYmUgdXNpbmcgdGhpcyBXR0xDIHRvIGRl dGVybWluZSBjb25zZW5zdXMgdG8gbW92ZSB0aGlzIGRvY3VtZW50IGZvcndhcmQgdG8gdGhlIElF U0cuIA0KDQpBbHNvLCBhcyBhIHJlbWluZGVyLCB3ZSBoYXZlIG1pZ3JhdGVkIHRoZSB3b3JraW5n IGdyb3VwIG1haWxpbmcgbGlzdCB0byBJRVRGIGluZnJhc3RydWN0dXJlLiBQbGVhc2UgcmVzcG9u ZCB0byBudHBAaWV0Zi5vcmcuIF0NCg0KUmVnYXJkcywNCkthcmVuIGFuZCBEaWV0ZXIKX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbnRwIG1haWxpbmcgbGlz dApudHBAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9udHAK From ntp-bounces@ietf.org Tue Aug 8 21:53:50 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 809E4131D33; Tue, 8 Aug 2017 21:53:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1502254430; bh=RkwpoK1Y9UH1UhVzS3IvzL5PQIrmSmDIG5QGsph2w90=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Cc; b=aUeq6Z0v0vxl7K4ex+FibjnpUQsNtFh6kTF/r3HvrwyFSxcQGYM8yBhnJ1GoDt5n3 55Ihp5Qf86RqLyN0C3rixHDKDbjLTXpnyHtqjvbrUbq0sLHdJQWfhf5e9/EmBCohvK wHHrpa2UkRrmmh/c3lAlH4L3VdJalZFo+3M7tl0Q= 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 F3791128C9C; Tue, 8 Aug 2017 21:53:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham 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 baCDOV_z_30w; Tue, 8 Aug 2017 21:53:45 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0066.outbound.protection.outlook.com [104.47.41.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8039F120727; Tue, 8 Aug 2017 21:53:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isoc.org; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=2cuRHVxiCFmbsOMPjksGdjAh0bHCFrVfNjKSgi80ZyM=; b=DZK7fWJ06NMJQs6bHvFciXLI3i8TNm4bUEiUscMGMFvS4dTV8JMI3fCjyD9BfnKSeUflqYI7nJVaqpFQF4x4A6wlpCqZeWXTn9FWs+VBWjCkNab+nhq16pFHcwTFd2KibMHAzfL9IrP9OLfXTIdmCrOiygVDR2fp7axsrQW26EE= Received: from CY4PR06MB2456.namprd06.prod.outlook.com (10.169.186.136) by CY4PR06MB2454.namprd06.prod.outlook.com (10.169.185.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1320.16; Wed, 9 Aug 2017 04:53:43 +0000 Received: from CY4PR06MB2456.namprd06.prod.outlook.com ([10.169.186.136]) by CY4PR06MB2456.namprd06.prod.outlook.com ([10.169.186.136]) with mapi id 15.01.1320.018; Wed, 9 Aug 2017 04:53:43 +0000 From: Karen O'Donoghue To: "ntp@ietf.org" Thread-Topic: WGLC for draft-ietf-ntp-mac Thread-Index: AQHTEMt6dgTCyuPEXEODOT5Gsnqn3Q== Date: Wed, 9 Aug 2017 04:53:43 +0000 Message-ID: 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: [24.245.108.20] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR06MB2454; 6:dZcsWZPu95Y8iWnRZUDEwF2MZ3LPrp4s875uX4fe1U1JBb+MHGt2mWQSj68PZHmO50CNmHJZlTrhZSkKs+8Rpp78trVWKXN3aQ9CXvWVXIlkk2WocvP6BNdKt0F2MBXqRLiCuughCnPCOSvuLBQdSdkQYuYQdFJlNs6A58bl6jJt06bdLW3Y5q6hT1XGO8kQZzlkEpIMPISbWHBgjEWUqBVM9TVex3sLCXyu1n1XWPhSjHhjNAfN28YoUmc3D7j0N/U2+y1EfnXw5Guwa3nc9NID5P34I8Z5rXGsQ0wSS0W02xDx9agKKciUj+ev16nX81O+GUjjqbCINchpbJFACw==; 5:RrWjgnnIxAT9YfMh5R2Zc2vgLbq2V9EcCZ6euU2gfLFxLc05/a+daCVou6KDSygKzJqZA4+cLPARLfM6OtzAtOphReXX/Z32uykRfP1gYbCVGf4eslmq4RltcRX4gR2baJ7sIzzLHw1XlYhFVwHtuQ==; 24:f7XLl7EwnKiVMerVmjBB6gqUdW2mC9otF3b9dZYJj/YX5/jk/FCYo+z5sONuR7xj2VCYZyQmKHo6o+H695YF/R516TQhQ1JmgeHUwoFRJts=; 7:lhNmIZCKy6jpwrDc57P9VnGW37tUgb1KC7dz9p5phWzDzU05giDTOzo4mdG6CICr2l3ebVK9JZI04bXZs2NJ2SYbnX1SQp6TitGILafihv0FfhC7yrWbbxD6mk2ojgizmN8a7dC4EbzVUwWNExwVZUAGG7vsl4lgNHARPFBYu6Er265QoN1/EtcISM8x9bXx7TSEqXgVhkVIwqlkktT+JJ3oJ4srRlsqobpFutpxvho= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 3bfe296c-0643-4b05-e70f-08d4dee29cc0 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY4PR06MB2454; x-ms-traffictypediagnostic: CY4PR06MB2454: x-exchange-antispam-report-test: UriScan:(120809045254105)(100405760836317); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(93006095)(93001095)(3002001)(10201501046)(6041248)(20161123560025)(20161123562025)(20161123564025)(20161123555025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR06MB2454; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR06MB2454; x-forefront-prvs: 0394259C80 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39830400002)(39450400003)(39410400002)(39400400002)(189002)(199003)(102836003)(4326008)(2906002)(14454004)(2900100001)(6486002)(450100002)(6506006)(77096006)(110136004)(606006)(66066001)(38730400002)(36756003)(82746002)(230783001)(2501003)(106356001)(966005)(105586002)(6916009)(2351001)(83716003)(53936002)(5660300001)(236005)(99286003)(7736002)(68736007)(6306002)(86362001)(33656002)(54896002)(97736004)(3280700002)(8936002)(81156014)(3846002)(6512007)(25786009)(8676002)(1730700003)(6116002)(54356999)(5640700003)(50986999)(189998001)(6436002)(3660700001)(101416001)(81166006)(478600001); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR06MB2454; H:CY4PR06MB2456.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: isoc.org does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Aug 2017 04:53:43.9164 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR06MB2454 Archived-At: Subject: [Ntp] WGLC for draft-ietf-ntp-mac X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "tictoc@ietf.org" Content-Type: multipart/mixed; boundary="===============7706817494456558886==" Errors-To: ntp-bounces@ietf.org Sender: "ntp" --===============7706817494456558886== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_CF57EAFE31F04ADDA2091802DB6CA643isocorg_" --_000_CF57EAFE31F04ADDA2091802DB6CA643isocorg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, This begins a three week working group last call (WGLC) for "Message Authen= tication Code for the Network Time Protocol" https://datatracker.ietf.org/doc/draft-ietf-ntp-mac/ Please review and provide comments to the mailing list by no later than 31 = August 2017. Earlier comments and discussion would be appreciated. Please n= ote that the chairs will be using this WGLC to determine consensus to move = this document forward to the IESG. Also, as a reminder, we have migrated the working group mailing list to IET= F infrastructure. Please respond to ntp@ietf.org. Regards, Karen and Dieter --_000_CF57EAFE31F04ADDA2091802DB6CA643isocorg_ Content-Type: text/html; charset="us-ascii" Content-ID: <53CCFAA21331EA44AAAFBC01245FC248@namprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable Folks,

This begins a three week working group last call (WGLC) for "Message A= uthentication Code for the Network Time Protocol"
https://datatracker.ietf.org/doc/draft-ietf-ntp-mac/

Please review and provide comments to the mailing list by no later than 31 = August 2017. Earlier comments and discussion would be appreciated. Please n= ote that the chairs will be using this WGLC to determine consensus to move = this document forward to the IESG. 

Also, as a reminder, we have migrated the working group mailing list to IET= F infrastructure. Please respond to ntp@ietf.org. 

Regards,
Karen and Dieter
--_000_CF57EAFE31F04ADDA2091802DB6CA643isocorg_-- --===============7706817494456558886== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp --===============7706817494456558886==-- From nobody Tue Aug 8 21:53:56 2017 Return-Path: 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 F3791128C9C; Tue, 8 Aug 2017 21:53:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham 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 baCDOV_z_30w; Tue, 8 Aug 2017 21:53:45 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0066.outbound.protection.outlook.com [104.47.41.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8039F120727; Tue, 8 Aug 2017 21:53:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isoc.org; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=2cuRHVxiCFmbsOMPjksGdjAh0bHCFrVfNjKSgi80ZyM=; b=DZK7fWJ06NMJQs6bHvFciXLI3i8TNm4bUEiUscMGMFvS4dTV8JMI3fCjyD9BfnKSeUflqYI7nJVaqpFQF4x4A6wlpCqZeWXTn9FWs+VBWjCkNab+nhq16pFHcwTFd2KibMHAzfL9IrP9OLfXTIdmCrOiygVDR2fp7axsrQW26EE= Received: from CY4PR06MB2456.namprd06.prod.outlook.com (10.169.186.136) by CY4PR06MB2454.namprd06.prod.outlook.com (10.169.185.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1320.16; Wed, 9 Aug 2017 04:53:43 +0000 Received: from CY4PR06MB2456.namprd06.prod.outlook.com ([10.169.186.136]) by CY4PR06MB2456.namprd06.prod.outlook.com ([10.169.186.136]) with mapi id 15.01.1320.018; Wed, 9 Aug 2017 04:53:43 +0000 From: Karen O'Donoghue To: "ntp@ietf.org" CC: "tictoc@ietf.org" Thread-Topic: WGLC for draft-ietf-ntp-mac Thread-Index: AQHTEMt6dgTCyuPEXEODOT5Gsnqn3Q== Date: Wed, 9 Aug 2017 04:53:43 +0000 Message-ID: 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: [24.245.108.20] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR06MB2454; 6:dZcsWZPu95Y8iWnRZUDEwF2MZ3LPrp4s875uX4fe1U1JBb+MHGt2mWQSj68PZHmO50CNmHJZlTrhZSkKs+8Rpp78trVWKXN3aQ9CXvWVXIlkk2WocvP6BNdKt0F2MBXqRLiCuughCnPCOSvuLBQdSdkQYuYQdFJlNs6A58bl6jJt06bdLW3Y5q6hT1XGO8kQZzlkEpIMPISbWHBgjEWUqBVM9TVex3sLCXyu1n1XWPhSjHhjNAfN28YoUmc3D7j0N/U2+y1EfnXw5Guwa3nc9NID5P34I8Z5rXGsQ0wSS0W02xDx9agKKciUj+ev16nX81O+GUjjqbCINchpbJFACw==; 5:RrWjgnnIxAT9YfMh5R2Zc2vgLbq2V9EcCZ6euU2gfLFxLc05/a+daCVou6KDSygKzJqZA4+cLPARLfM6OtzAtOphReXX/Z32uykRfP1gYbCVGf4eslmq4RltcRX4gR2baJ7sIzzLHw1XlYhFVwHtuQ==; 24:f7XLl7EwnKiVMerVmjBB6gqUdW2mC9otF3b9dZYJj/YX5/jk/FCYo+z5sONuR7xj2VCYZyQmKHo6o+H695YF/R516TQhQ1JmgeHUwoFRJts=; 7:lhNmIZCKy6jpwrDc57P9VnGW37tUgb1KC7dz9p5phWzDzU05giDTOzo4mdG6CICr2l3ebVK9JZI04bXZs2NJ2SYbnX1SQp6TitGILafihv0FfhC7yrWbbxD6mk2ojgizmN8a7dC4EbzVUwWNExwVZUAGG7vsl4lgNHARPFBYu6Er265QoN1/EtcISM8x9bXx7TSEqXgVhkVIwqlkktT+JJ3oJ4srRlsqobpFutpxvho= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 3bfe296c-0643-4b05-e70f-08d4dee29cc0 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY4PR06MB2454; x-ms-traffictypediagnostic: CY4PR06MB2454: x-exchange-antispam-report-test: UriScan:(120809045254105)(100405760836317); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(93006095)(93001095)(3002001)(10201501046)(6041248)(20161123560025)(20161123562025)(20161123564025)(20161123555025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR06MB2454; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR06MB2454; x-forefront-prvs: 0394259C80 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39830400002)(39450400003)(39410400002)(39400400002)(189002)(199003)(102836003)(4326008)(2906002)(14454004)(2900100001)(6486002)(450100002)(6506006)(77096006)(110136004)(606006)(66066001)(38730400002)(36756003)(82746002)(230783001)(2501003)(106356001)(966005)(105586002)(6916009)(2351001)(83716003)(53936002)(5660300001)(236005)(99286003)(7736002)(68736007)(6306002)(86362001)(33656002)(54896002)(97736004)(3280700002)(8936002)(81156014)(3846002)(6512007)(25786009)(8676002)(1730700003)(6116002)(54356999)(5640700003)(50986999)(189998001)(6436002)(3660700001)(101416001)(81166006)(478600001); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR06MB2454; H:CY4PR06MB2456.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: isoc.org does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CF57EAFE31F04ADDA2091802DB6CA643isocorg_" MIME-Version: 1.0 X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Aug 2017 04:53:43.9164 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR06MB2454 Archived-At: Subject: [Ntp] WGLC for draft-ietf-ntp-mac X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Aug 2017 04:53:48 -0000 --_000_CF57EAFE31F04ADDA2091802DB6CA643isocorg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, This begins a three week working group last call (WGLC) for "Message Authen= tication Code for the Network Time Protocol" https://datatracker.ietf.org/doc/draft-ietf-ntp-mac/ Please review and provide comments to the mailing list by no later than 31 = August 2017. Earlier comments and discussion would be appreciated. Please n= ote that the chairs will be using this WGLC to determine consensus to move = this document forward to the IESG. Also, as a reminder, we have migrated the working group mailing list to IET= F infrastructure. Please respond to ntp@ietf.org. Regards, Karen and Dieter --_000_CF57EAFE31F04ADDA2091802DB6CA643isocorg_ Content-Type: text/html; charset="us-ascii" Content-ID: <53CCFAA21331EA44AAAFBC01245FC248@namprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable Folks,

This begins a three week working group last call (WGLC) for "Message A= uthentication Code for the Network Time Protocol"
https://datatracker.ietf.org/doc/draft-ietf-ntp-mac/

Please review and provide comments to the mailing list by no later than 31 = August 2017. Earlier comments and discussion would be appreciated. Please n= ote that the chairs will be using this WGLC to determine consensus to move = this document forward to the IESG. 

Also, as a reminder, we have migrated the working group mailing list to IET= F infrastructure. Please respond to ntp@ietf.org. 

Regards,
Karen and Dieter
--_000_CF57EAFE31F04ADDA2091802DB6CA643isocorg_-- From nobody Thu Aug 10 16:29:24 2017 Return-Path: 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 B6F391326E1 for ; Thu, 10 Aug 2017 16:29:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=libertysys.com.au 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 6Vr2dkIJRcf3 for ; Thu, 10 Aug 2017 16:29:22 -0700 (PDT) Received: from mail.libertysys.com.au (ppp178-79.static.internode.on.net [150.101.178.79]) (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 EB51A126BFD for ; Thu, 10 Aug 2017 16:29:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.libertysys.com.au (Postfix) with ESMTP id F035D92489 for ; Fri, 11 Aug 2017 09:29:18 +1000 (AEST) X-Virus-Scanned: Debian amavisd-new at mail2.gear.dyndns.org Received: from mail.libertysys.com.au ([127.0.0.1]) by localhost (mail.gear.dyndns.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LBh_owwgwJkO for ; Fri, 11 Aug 2017 09:29:12 +1000 (AEST) Received: from [172.22.64.102] (eber-home.gear.dyndns.org [172.22.64.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.libertysys.com.au (Postfix) with ESMTPSA id 202C19207F for ; Fri, 11 Aug 2017 09:29:12 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=libertysys.com.au; s=2016; t=1502407752; bh=xVUblCFwRR/w0NQixZlag+FdB50tG5FLZBZpdjUAbIA=; h=Subject:To:References:From:Date:In-Reply-To; b=CSemL7D3soW8UmlvPe1ZBKVMkKXFhctlbYfo5rj5CPlC+xSlJgKddiVXWvuaOi/Cs 7zqxQhEgWraQzg7rLPKMMknrzwtj2LFgt2PAX1QTJaQ3CGem8QLX2+zs35RkVDKkr3 TMFS6E5EvrRN+3cVSOmOqExAZyOMdfw9JmxC5IXI= To: ntp@ietf.org References: From: Paul Gear Message-ID: <9d4f0475-89f7-d4c7-a8aa-787678c0a0e2@libertysys.com.au> Date: Fri, 11 Aug 2017 09:29:11 +1000 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Content-Language: en-AU Archived-At: Subject: Re: [Ntp] WGLC for draft-ietf-ntp-mac X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Aug 2017 23:29:24 -0000 On 09/08/17 14:53, Karen O'Donoghue wrote: > Folks, > > This begins a three week working group last call (WGLC) for "Message > Authentication Code for the Network Time Protocol" > https://datatracker.ietf.org/doc/draft-ietf-ntp-mac/ > > Please review and provide comments to the mailing list by no later > than 31 August 2017. Earlier comments and discussion would be > appreciated. Please note that the chairs will be using this WGLC to > determine consensus to move this document forward to the IESG. Hi everyone, (Apologies in advance if this isn't an appropriate forum for these questions - please redirect me if this is the case.) I'm trying to get a handle on this draft so I can intelligently answer questions about it next month at AusNOG, and I'm wondering if someone can comment on the on-the-wire implications for NTP implementations. As I understand it, there are no proposed changes to the protocol's wire format under this draft, rather a simple substitution of the 128-bit MD5 field for a 128-bit AES-CMAC field. How then would an implementation distinguish between MACs in the two formats? Is there an implicit assumption that if this draft is accepted, it will be rolled into a new protocol version specification for NTPv5, in which case any NTPv4 packet would be MD5, and any NTPv5 packet would be AES-CMAC? As a secondary issue, are there any working implementations of this change, and if so any benchmarks showing the effect (if any) of the change? Thanks, Paul From ntp-bounces@ietf.org Thu Aug 10 16:29:25 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C05C1326E1; Thu, 10 Aug 2017 16:29:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1502407765; bh=JskdArV6MLngeJpIurBgJ9/aPSW+1cWUiAPuOjbC6Y0=; h=To:References:From:Date:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe; b=tj1hUgt2h+R9gL9f/bExBKbcGzPPpEqO7buAxLHE/GP0gSwfkEHQ2lvQRjFOIuIMO +yjXKLccNbcxvo1z42ErOkQYEJydxOEiTWo52Ti7g/yrlW4OZHDSmSAGqkrstriMbK rOyESlb9wi2DczSXWEmEPNVkIiTYfC7XPKelOWv4= 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 B6F391326E1 for ; Thu, 10 Aug 2017 16:29:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=libertysys.com.au 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 6Vr2dkIJRcf3 for ; Thu, 10 Aug 2017 16:29:22 -0700 (PDT) Received: from mail.libertysys.com.au (ppp178-79.static.internode.on.net [150.101.178.79]) (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 EB51A126BFD for ; Thu, 10 Aug 2017 16:29:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.libertysys.com.au (Postfix) with ESMTP id F035D92489 for ; Fri, 11 Aug 2017 09:29:18 +1000 (AEST) X-Virus-Scanned: Debian amavisd-new at mail2.gear.dyndns.org Received: from mail.libertysys.com.au ([127.0.0.1]) by localhost (mail.gear.dyndns.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LBh_owwgwJkO for ; Fri, 11 Aug 2017 09:29:12 +1000 (AEST) Received: from [172.22.64.102] (eber-home.gear.dyndns.org [172.22.64.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.libertysys.com.au (Postfix) with ESMTPSA id 202C19207F for ; Fri, 11 Aug 2017 09:29:12 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=libertysys.com.au; s=2016; t=1502407752; bh=xVUblCFwRR/w0NQixZlag+FdB50tG5FLZBZpdjUAbIA=; h=Subject:To:References:From:Date:In-Reply-To; b=CSemL7D3soW8UmlvPe1ZBKVMkKXFhctlbYfo5rj5CPlC+xSlJgKddiVXWvuaOi/Cs 7zqxQhEgWraQzg7rLPKMMknrzwtj2LFgt2PAX1QTJaQ3CGem8QLX2+zs35RkVDKkr3 TMFS6E5EvrRN+3cVSOmOqExAZyOMdfw9JmxC5IXI= To: ntp@ietf.org References: From: Paul Gear Message-ID: <9d4f0475-89f7-d4c7-a8aa-787678c0a0e2@libertysys.com.au> Date: Fri, 11 Aug 2017 09:29:11 +1000 MIME-Version: 1.0 In-Reply-To: Content-Language: en-AU Archived-At: Subject: Re: [Ntp] WGLC for draft-ietf-ntp-mac X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ntp-bounces@ietf.org Sender: "ntp" On 09/08/17 14:53, Karen O'Donoghue wrote: > Folks, > > This begins a three week working group last call (WGLC) for "Message > Authentication Code for the Network Time Protocol" > https://datatracker.ietf.org/doc/draft-ietf-ntp-mac/ > > Please review and provide comments to the mailing list by no later > than 31 August 2017. Earlier comments and discussion would be > appreciated. Please note that the chairs will be using this WGLC to > determine consensus to move this document forward to the IESG. Hi everyone, (Apologies in advance if this isn't an appropriate forum for these questions - please redirect me if this is the case.) I'm trying to get a handle on this draft so I can intelligently answer questions about it next month at AusNOG, and I'm wondering if someone can comment on the on-the-wire implications for NTP implementations. As I understand it, there are no proposed changes to the protocol's wire format under this draft, rather a simple substitution of the 128-bit MD5 field for a 128-bit AES-CMAC field. How then would an implementation distinguish between MACs in the two formats? Is there an implicit assumption that if this draft is accepted, it will be rolled into a new protocol version specification for NTPv5, in which case any NTPv4 packet would be MD5, and any NTPv5 packet would be AES-CMAC? As a secondary issue, are there any working implementations of this change, and if so any benchmarks showing the effect (if any) of the change? Thanks, Paul _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp From ntp-bounces@ietf.org Thu Aug 10 16:50:08 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E73471326D2; Thu, 10 Aug 2017 16:50:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1502409008; bh=t1ETcVfmm95uY/akLDGWoeWlBcOdYCu7csT+T83OOzc=; h=To:References:From:Date:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe; b=f8JKW3IoKiG4kbYAUkHnHBgI2IZ7iRfROmbae8zLQdi1ly5qDKobAvvLS8W7UotOk XEo3G7AUdzxziDTgLACmoOSKo6Vx3MD4aEKcwJxOMFR8FP30WwFbjkGPWof0ssBfZp Nsfh+Vbyu7W5lXMr6n+DNre19u5Iph62OBRtTl+g= 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 DA16B1324B4 for ; Thu, 10 Aug 2017 16:49:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 ha-mDlV71yR8 for ; Thu, 10 Aug 2017 16:49:53 -0700 (PDT) Received: from chessie.everett.org (chessie.everett.org [66.220.13.234]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B45481326C8 for ; Thu, 10 Aug 2017 16:49:53 -0700 (PDT) Received: from [10.66.3.3] (96-41-166-181.dhcp.mdfd.or.charter.com [96.41.166.181]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by chessie.everett.org (Postfix) with ESMTPSA id 29FDCB989; Thu, 10 Aug 2017 23:49:53 +0000 (UTC) To: ntp@ietf.org References: <9d4f0475-89f7-d4c7-a8aa-787678c0a0e2@libertysys.com.au> From: Harlan Stenn Message-ID: <0ec0a23b-7c1e-84c9-850e-8837f1e8a191@nwtime.org> Date: Thu, 10 Aug 2017 16:49:53 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <9d4f0475-89f7-d4c7-a8aa-787678c0a0e2@libertysys.com.au> Archived-At: Subject: Re: [Ntp] WGLC for draft-ietf-ntp-mac X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ntp-bounces@ietf.org Sender: "ntp" On 8/10/2017 4:29 PM, Paul Gear wrote: > On 09/08/17 14:53, Karen O'Donoghue wrote: >> Folks, >> >> This begins a three week working group last call (WGLC) for "Message >> Authentication Code for the Network Time Protocol" >> https://datatracker.ietf.org/doc/draft-ietf-ntp-mac/ >> >> Please review and provide comments to the mailing list by no later >> than 31 August 2017. Earlier comments and discussion would be >> appreciated. Please note that the chairs will be using this WGLC to >> determine consensus to move this document forward to the IESG. > > Hi everyone, > > (Apologies in advance if this isn't an appropriate forum for these > questions - please redirect me if this is the case.) > > I'm trying to get a handle on this draft so I can intelligently answer > questions about it next month at AusNOG, and I'm wondering if someone > can comment on the on-the-wire implications for NTP implementations. As > I understand it, there are no proposed changes to the protocol's wire > format under this draft, rather a simple substitution of the 128-bit MD5 > field for a 128-bit AES-CMAC field. There are no protocol changes. What changed is that we want to deprecate MD5 as the default algorithm for MAC hashes, and replace it with AES-128-CMAC. The MAC includes a "key id", and the key ID maps to 2 pieces of information: the algorithm, and the key. > How then would an implementation distinguish between MACs in the two > formats? The implementation looks up the keyID and sees what hash algorithm is used for that keyID. > Is there an implicit assumption that if this draft is > accepted, it will be rolled into a new protocol version specification > for NTPv5, in which case any NTPv4 packet would be MD5, and any NTPv5 > packet would be AES-CMAC? No. This is still NTPv4, and folks are free to use whatever MAC hashing algorithms are supported by both sides of the association. > As a secondary issue, are there any working implementations of this > change, and if so any benchmarks showing the effect (if any) of the change? I believe some initial performance testing was done on the algorithms, and that Sharon and Aanchal published these in their proposal. The NTP Project is getting ready to release our implementation of it. -- Harlan Stenn, Network Time Foundation http://nwtime.org - be a Member! _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp From nobody Thu Aug 10 16:50:08 2017 Return-Path: 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 DA16B1324B4 for ; Thu, 10 Aug 2017 16:49:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 ha-mDlV71yR8 for ; Thu, 10 Aug 2017 16:49:53 -0700 (PDT) Received: from chessie.everett.org (chessie.everett.org [66.220.13.234]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B45481326C8 for ; Thu, 10 Aug 2017 16:49:53 -0700 (PDT) Received: from [10.66.3.3] (96-41-166-181.dhcp.mdfd.or.charter.com [96.41.166.181]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by chessie.everett.org (Postfix) with ESMTPSA id 29FDCB989; Thu, 10 Aug 2017 23:49:53 +0000 (UTC) To: ntp@ietf.org References: <9d4f0475-89f7-d4c7-a8aa-787678c0a0e2@libertysys.com.au> From: Harlan Stenn Message-ID: <0ec0a23b-7c1e-84c9-850e-8837f1e8a191@nwtime.org> Date: Thu, 10 Aug 2017 16:49:53 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <9d4f0475-89f7-d4c7-a8aa-787678c0a0e2@libertysys.com.au> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ntp] WGLC for draft-ietf-ntp-mac X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Aug 2017 23:49:56 -0000 On 8/10/2017 4:29 PM, Paul Gear wrote: > On 09/08/17 14:53, Karen O'Donoghue wrote: >> Folks, >> >> This begins a three week working group last call (WGLC) for "Message >> Authentication Code for the Network Time Protocol" >> https://datatracker.ietf.org/doc/draft-ietf-ntp-mac/ >> >> Please review and provide comments to the mailing list by no later >> than 31 August 2017. Earlier comments and discussion would be >> appreciated. Please note that the chairs will be using this WGLC to >> determine consensus to move this document forward to the IESG. > > Hi everyone, > > (Apologies in advance if this isn't an appropriate forum for these > questions - please redirect me if this is the case.) > > I'm trying to get a handle on this draft so I can intelligently answer > questions about it next month at AusNOG, and I'm wondering if someone > can comment on the on-the-wire implications for NTP implementations. As > I understand it, there are no proposed changes to the protocol's wire > format under this draft, rather a simple substitution of the 128-bit MD5 > field for a 128-bit AES-CMAC field. There are no protocol changes. What changed is that we want to deprecate MD5 as the default algorithm for MAC hashes, and replace it with AES-128-CMAC. The MAC includes a "key id", and the key ID maps to 2 pieces of information: the algorithm, and the key. > How then would an implementation distinguish between MACs in the two > formats? The implementation looks up the keyID and sees what hash algorithm is used for that keyID. > Is there an implicit assumption that if this draft is > accepted, it will be rolled into a new protocol version specification > for NTPv5, in which case any NTPv4 packet would be MD5, and any NTPv5 > packet would be AES-CMAC? No. This is still NTPv4, and folks are free to use whatever MAC hashing algorithms are supported by both sides of the association. > As a secondary issue, are there any working implementations of this > change, and if so any benchmarks showing the effect (if any) of the change? I believe some initial performance testing was done on the algorithms, and that Sharon and Aanchal published these in their proposal. The NTP Project is getting ready to release our implementation of it. -- Harlan Stenn, Network Time Foundation http://nwtime.org - be a Member! From ntp-bounces@ietf.org Fri Aug 11 02:35:01 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 750FE132518; Fri, 11 Aug 2017 02:35:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1502444101; bh=P93u+E2Vcg4cYusle+YufAHbfMuHygmgToV5CjlHsDM=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=d+jgECXIT/gKX5gkyJV0CW6iai/Ovw6L+HNfst1l09XuARFiJeLzzsihG+W8Ak2GP +pIhOCAgg7jDlgS6HwqkTs6JxzILF3aONflmUEO+i7WrpUlOl1WkE0ix8wXLRFu+bw 4BzqGLdmqGdi7xZdqkBEbfoRlkJSzIOCkhs8pVEo= 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 81C461324A8 for ; Fri, 11 Aug 2017 02:34:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sonia.de 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 fe7fY8I2AFjo for ; Fri, 11 Aug 2017 02:34:56 -0700 (PDT) Received: from mailgate1.sonia.de (mailgate1.sonia.de [141.41.1.242]) (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 18AAC132488 for ; Fri, 11 Aug 2017 02:34:56 -0700 (PDT) Received: from mailgate1.sonia.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 7940E15876 for ; Fri, 11 Aug 2017 11:34:54 +0200 (CEST) Received: from mail.sonia.de (mail.sonia.de [141.41.8.70]) by mailgate1.sonia.de (Postfix) with ESMTP id 610EA15870 for ; Fri, 11 Aug 2017 11:34:54 +0200 (CEST) MIME-version: 1.0 Received: from ostfalia.de ([141.41.8.70]) by mail.sonia.de (Oracle Communications Messaging Server 7.0.5.37.0 64bit (built Jan 25 2016)) with ESMTPA id <0OUI00HFHLA6RU30@mail.sonia.de> for ntp@ietf.org; Fri, 11 Aug 2017 11:34:54 +0200 (CEST) Received: from [141.41.8.91] (Forwarded-For: 141.41.8.91) by mail.sonia.de (mshttpd); Fri, 11 Aug 2017 11:34:54 +0200 From: Martin Langer To: ntp@ietf.org Message-id: <70a0c971b2978.598d965e@ostfalia.de> Date: Fri, 11 Aug 2017 11:34:54 +0200 X-Mailer: Oracle Communications Messenger Express 7.0.5.37.0 64bit (built Jan 25 2016) Content-language: de X-Accept-Language: de Priority: normal DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sonia.de; h=mime-version:content-type:from:to:message-id:date:subject; s=20140129; bh=rJMcg9q1rQLEQAHzu+aKXlMwV4wbdISBCedltdlWJek=; b=Mszci/qz6/6DDZD/sYI/ltqWJMRLSATbPtXJawVGWaVp98cG5h5gG7JxFDrIuYqhhIbF1/oxQ/DmBbTHGamxWypBs4cUpanb/kbeTTsNXEkmSYnmt52RWmuhAteB814PVF/xo14mttTqgm5dRXDA+wuNMI9+WcuF+/S1CM37qjg= Archived-At: Subject: [Ntp] some comments on the NTS4NTP-Draft09 X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============6979419572004254437==" Errors-To: ntp-bounces@ietf.org Sender: "ntp" This is a multi-part message in MIME format. --===============6979419572004254437== Content-type: multipart/alternative; boundary="Boundary_(ID_rM1s1mbl5mZ15Cv8kGSDmw)" Content-language: de This is a multi-part message in MIME format. --Boundary_(ID_rM1s1mbl5mZ15Cv8kGSDmw) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Content-disposition: inline Hi all, At first, I wanted to tell you briefly that the new NTS implementation will start next week. I have some points/comments on the NTS4NTP-Draft09 that I wanted to mention in this way. Therefore, the content is primarily directed at Daniel Franke. In advance, I'm in Japan for the next 3 weeks and will probably not be able to respond to comments or emails. I ask for understanding. ================================================================================= NTS4NTP-Draft09 ================================================================================= 1. confusing term "ntp/4" ============================================================ page 10 (chapter 5.1.5, 2nd section): ----------------------------------------- [...] If the NTS Next Protocol Negotiation record offers "ntp/4",this record MUST be included exactly once. [...] page 11 (chapter 5.1.5, 4th section): ----------------------------------------- [...] and the server accepts the "ntp/4" protocol in its NTS Next Protocol Negotiation record [...] page 11 (chapter 6.1, 1st section): ----------------------------------------- [...] Following a successful run of the NTS-KE protocol wherein "ntp/4" is selected as a Next Protocol [...] remark: ----------------------------------------- "ntp/4" is the same term as in the TLS ALPN extension (see: page 18, chapter 8): [...] IANA is requested to allocate the following two entries in the Application-Layer Protocol Negotation (ALPN) Protocol IDs registry: [...] Protocol: Network Time Protocol, version 4 Identification Sequence: 0x6E 0x74 0x70 0x2F 0x34 ("ntp/4") [...] But the NTS Next Protocol Negotiation record contains IDs (e.g. 0x00 for 'Network Time Protocol version 4'; see table at page 21) and not the term 'ntp/4'. This can confusing some readers. 2. Network Byte Order / Host Byte Order ============================================================ page 8 (chapter 5, 5th section): ----------------------------------------- [...] Record Type: A 15-bit integer in network byte order (from most-to-least significant, its bits are record bits 7-1 and then 15-8). [...] remark: ----------------------------------------- Why 7-1 and then 15-8? Are we use the Little Endian format for the 'Record Type' only or for the whole record? Why we don't use Big Endian? 3. general comment ============================================================ page 12 (chapter 6.1, 2nd section): ----------------------------------------- [...] The per-association context value SHALL consist of the following five octets: The first two octets SHALL be zero.[...] remark: ----------- My first thought was: why? At first it was a magic number for me. The solution is here: chapter 5.2: [...] and MUST begin with the two-octet Protocol ID which was negotiated as a Next Protocol. [...] I think this should be mentioned again or referenced to the corresponding table (chapter 8). 4. general comment ============================================================ page 13 (chapter 6.5, 2nd section): ----------------------------------------- [...] This length requirement serves to ensure that the response will not be larger than the request, in order to improve timekeeping precision and [...] remark: ----------- Does it really improve the timekeeping? I think the idea is to reduce the asymmetry if the request and response message have the same size. But client and server may have different performance and therefore the processing speed per NTP Package is different too. ...it's just a thought 5. alternative proposal ============================================================ page 20 (chapter 8, 1st section): ----------------------------------------- [...] Type Number (REQUIRED): An integer in the range 0-32767 inclusive [...] better?: ----------- [...] Type Number (REQUIRED): An 15 bit integer in the range 0-32767 inclusive [...] ....not 16 bit, because we use a critical bit in our records (first bit) 6. some problems with 'The NTS Authenticator and Encrypted Extensions extension' (page 14, chapter 6.6) ============================================================ field description: ----------------------------------------- 'Nonce lenght': We should mention that the value is to be interpreted as 'unsigned int'. 'Nonce': At first I had some trouble to understand where the nonce comes from and which length we use. Now I know it, but maybe we should add some more information to this field. perhaps from these: [...] Nonce: a nonce as required by the negotiated AEAD Algorithm. [...] to these: [...] Nonce: a new generated nonce whose length and format is determined by the negotiated AEAD algorithm (RFC 5116, chapter 3.2). [...] 'Chipertext': Some readers (students in my team) had difficulties to understand this field. All of them thought, that this field contains an encrypted version of the whole NTP package. And this is wrong. I think the problem is this line: [...] authentication tag in addition to the actual ciphertext. [...]. Well, if readers do not know exactly how AEAD works, then this leads to strong understanding problems at this point, since the terms 'authentication tag' and 'ciphertext' seem not known. I think we should add a reference (RFC 5116 --> AEAD) or some information about this terms ('authentication tag' is like a MAC and 'ciphertext' contains optional Extension Fields and can be absent if no Extension Fields are encrypted.). Maybe confuses the field name 'Chipertext' too. 'Padding:' This line: [...] so that implementations can unambiguously delimit the end of the ciphertext from the start of the padding [...] can be difficult to. In the beginning I did not know how this should work. We should say that implementations can read the last octet of this extension content, to find out how big the padding is. Furthermore we should change this line: [...] requirement that (in the absence of a legacy MAC) extensions have a total length in octets (including the four octets for the type and length fields) [...] in this: [...] requirement that (in the absence of a legacy MAC) NTP extensions have a total length in octets (including the four octets for the type and length fields) [...] -------------------------------- [...] P: The plaintext SHALL consist of all (if any) extensions to be encrypted. [...] Which format? Typical NTPv4 Extension Fields or another format? We should define that. We should also mention that only this content is encrypted (not the content of parameter 'A'). If we don't want encrypt anything (default case), then this parameter is empty. ============================================================ Please let me know if you have problems to understand my *english*. Best regards, Martin --Boundary_(ID_rM1s1mbl5mZ15Cv8kGSDmw) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable Content-disposition: inline Hi all=2C=3Cbr /=3E=3Cbr /=3EAt first=2C I wanted to tell you briefly th= at the new NTS = implementation will start next week=2E I have some points/comments on th= e = NTS4NTP-Draft09 that I wanted to mention in this way=2E Therefore=2C the= = content is primarily directed at Daniel Franke=2E=3Cbr /=3EIn advance=2C= I=27m in = Japan for the next 3 weeks and will probably not be able to respond to = comments or emails=2E I ask for understanding=2E=3Cbr /=3E=3Cbr /=3E=3Cb= r /=3E=3Cbr /=3E=3Cdiv=3E=3Cwbr=3E=3C/wbr=3E=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3Cwbr=3E=3C= /wbr=3E=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3Cwbr=3E=3C/wbr=3E=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3Cbr /=3ENTS4NTP-Draft09=3Cbr /=3E=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3Cwbr=3E=3C/wbr=3E=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3Cwbr=3E=3C/wbr=3E=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3Cbr /=3E=3Cbr= /=3E=3Cbr /=3E1=2E confusing term =26quot=3Bntp/4=26quot=3B=3Cbr /=3E=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3Cwbr=3E=3C/wbr=3E=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3Cbr /=3E=3Cbr /=3Ep= age 10 (chapter 5=2E1=2E5=2C 2nd section)=3A=3Cbr /=3E------------------= ------------=3Cwbr=3E=3C/wbr=3E-----------=3Cbr /=3E=5B=2E=2E=2E=5D If t= he NTS Next Protocol Negotiation record offers =26quot=3Bntp/4=26quot=3B= =2Cthis record MUST be included exactly once=2E =5B=2E=2E=2E=5D=3Cbr /=3E= =3Cbr /=3E=3Cbr /=3Epage 11 (chapter 5=2E1=2E5=2C 4th section)=3A=3Cbr /= =3E------------------------------=3Cwbr=3E=3C/wbr=3E-----------=3Cbr /=3E= =5B=2E=2E=2E=5D and the server accepts the =26quot=3Bntp/4=26quot=3B pro= tocol in its NTS Next Protocol Negotiation record =5B=2E=2E=2E=5D=3Cbr /= =3E=3Cbr /=3E=3Cbr /=3Epage 11 (chapter 6=2E1=2C 1st section)=3A=3Cbr /=3E= ------------------------------=3Cwbr=3E=3C/wbr=3E-----------=3Cbr /=3E=5B= =2E=2E=2E=5D Following a successful run of the NTS-KE protocol wherein =26= quot=3Bntp/4=26quot=3B is selected as a Next Protocol =5B=2E=2E=2E=5D=3C= br /=3E=3Cbr /=3E=3Cbr /=3Eremark=3A=3Cbr /=3E--------------------------= ----=3Cwbr=3E=3C/wbr=3E-----------=3Cbr /=3E=26quot=3Bntp/4=26quot=3B is= the same term as in the TLS ALPN extension (see=3A page 18=2C chapter 8= )=3A=3Cbr /=3E=3Cbr /=3E=5B=2E=2E=2E=5D IANA is requested to allocate the following two entries in the = Application-Layer Protocol Negotation (ALPN) Protocol IDs registry=3A = =5B=2E=2E=2E=5D Protocol=3A Network Time Protocol=2C version 4=C2=A0=C2=A0= Identification = Sequence=3A 0x6E 0x74 0x70 0x2F 0x34 (=26quot=3Bntp/4=26quot=3B) =5B=2E=2E= =2E=5D=3Cbr /=3E=3Cbr /=3EBut the NTS = Next Protocol Negotiation record contains IDs (e=2Eg=2E 0x00 for =27Netw= ork = Time Protocol version 4=27=3B see table at page 21) and not the term = =27ntp/4=27=2E This can confusing some readers=2E=3Cbr /=3E=3Cbr /=3E=3C= br /=3E=3Cbr /=3E=3Cbr /=3E=3Cbr /=3E2=2E Network Byte Order / Host Byte= Order=3Cbr /=3E=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3Cwbr=3E=3C/wbr=3E=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3C= br /=3E=3Cbr /=3Epage 8 (chapter 5=2C 5th section)=3A=3Cbr /=3E---------= ---------------------=3Cwbr=3E=3C/wbr=3E-----------=3Cbr /=3E=5B=2E=2E=2E= =5D Record Type=3A A 15-bit integer in network byte order (from most-to-lea= st significant=2C its bits are record bits 7-1 and then 15-8)=2E =5B=2E=2E= =2E=5D=3Cbr /=3E=3Cbr /=3E=3Cbr /=3Eremark=3A=3Cbr /=3E-----------------= -------------=3Cwbr=3E=3C/wbr=3E----------- =3Cbr /=3EWhy 7-1 and then 15-8=3F Are we use the Little Endian format for the =27Rec= ord = Type=27 only or for the whole record=3F Why we don=27t use Big Endian=3F= =3Cbr /=3E=3Cbr /=3E=3Cbr /=3E=3Cbr /=3E=3Cbr /=3E=3Cbr /=3E=3Cbr /=3E3=2E= general comment=3Cbr /=3E=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3Cwbr=3E=3C/wbr=3E=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3Cbr /=3E=3Cbr /=3Epage 12 (chapter 6=2E1=2C 2nd section)=3A=3Cbr= /=3E------------------------------=3Cwbr=3E=3C/wbr=3E-----------=3Cbr /= =3E=5B=2E=2E=2E=5D The per-association context value SHALL consist of th= e following five octets=3A The first two octets SHALL be zero=2E=5B=2E=2E= =2E=5D=3Cbr /=3E=3Cbr /=3E=3Cbr /=3Eremark=3A=3Cbr /=3E----------- =3Cbr= /=3EMy first thought was=3A why=3F At first it was a magic number for m= e=2E The solution is here=3A chapter 5=2E2=3A =3Cbr /=3E=5B=2E=2E=2E=5D = and MUST begin with the two-octet Protocol ID which was negotiated as a = Next Protocol=2E =5B=2E=2E=2E=5D=3Cbr /=3E=3Cbr /=3EI think this should = be mentioned again or referenced to the corresponding table (chapter 8)=2E= =3Cbr /=3E=3Cbr /=3E=3Cbr /=3E=3Cbr /=3E=3Cbr /=3E=3Cbr /=3E4=2E general= comment=3Cbr /=3E=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3Cwbr=3E=3C/wbr=3E=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3Cbr /=3E=3Cbr /=3Epage 13 (chapter 6=2E5=2C 2nd section)=3A=3Cbr /=3E-= -----------------------------=3Cwbr=3E=3C/wbr=3E-----------=3Cbr /=3E=5B= =2E=2E=2E=5D This length requirement serves to ensure that the response will not be = larger than the request=2C in order to improve timekeeping precision and= = =5B=2E=2E=2E=5D=3Cbr /=3E=3Cbr /=3E=3Cbr /=3Eremark=3A=3Cbr /=3E--------= --- =3Cbr /=3EDoes it really improve the = timekeeping=3F I think the idea is to reduce the asymmetry if the reques= t = and response message have the same size=2E =3Cbr /=3EBut client and serv= er may = have different performance and therefore the processing speed per NTP = Package is different too=2E=C2=A0 =2E=2E=2Eit=27s just a thought=3Cbr /=3E= =3Cbr /=3E=3Cbr /=3E=3Cbr /=3E=3Cbr /=3E=3Cbr /=3E5=2E alternative propo= sal=3Cbr /=3E=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3Cwbr=3E=3C/wbr=3E=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3Cbr = /=3E=3Cbr /=3Epage 20 (chapter 8=2C 1st section)=3A=3Cbr /=3E-----------= -------------------=3Cwbr=3E=3C/wbr=3E-----------=3Cbr /=3E=5B=2E=2E=2E=5D= Type Number (REQUIRED)=3A An integer in the range 0-32767 inclusive =5B= =2E=2E=2E=5D=3Cbr /=3E=3Cbr /=3E=3Cbr /=3Ebetter=3F=3A=3Cbr /=3E--------= --- =3Cbr /=3E=5B=2E=2E=2E=5D Type Number (REQUIRED)=3A An =3Cb=3E15 bit= =3C/b=3E integer in the range 0-32767 inclusive =5B=2E=2E=2E=5D=3Cbr /=3E= =3Cbr /=3E=2E=2E=2E=2Enot 16 bit=2C because we use a critical bit in our= records (first bit)=3Cbr /=3E=3Cbr /=3E=3Cbr /=3E=3Cbr /=3E=3Cbr /=3E=3C= br /=3E=3Cbr /=3E6=2E some problems with =27The NTS Authenticator and En= crypted Extensions extension=27 (page 14=2C chapter 6=2E6)=3Cbr /=3E=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3Cwbr=3E=3C/wbr=3E=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3Cbr /=3E=3Cbr /=3Efiel= d description=3A=3Cbr /=3E------------------------------=3Cwbr=3E=3C/wbr= =3E-----------=3Cbr /=3E=27Nonce lenght=27=3A We should mention that the= value is to be interpreted as =27unsigned int=27=2E=3Cbr /=3E=3Cbr /=3E= =27Nonce=27=3A At first I had some trouble to understand where the nonce comes from = and which length we use=2E Now I know it=2C but maybe we should add some= = more information to this field=2E=3Cbr /=3Eperhaps from these=3A=C2=A0=C2= =A0 =5B=2E=2E=2E=5D Nonce=3A a = nonce as required by the negotiated AEAD Algorithm=2E =5B=2E=2E=2E=5D=C2= =A0=C2=A0 to these=3A=C2=A0=C2=A0 = =5B=2E=2E=2E=5D Nonce=3A a new generated nonce whose length and format i= s determined by the negotiated AEAD algorithm (RFC 5116=2C chapter 3=2E2)=2E =5B=2E=2E= =2E=5D=3Cbr /=3E=3Cbr /=3E=3Cbr /=3E=27Chipertext=27=3A Some readers (students in my team) had difficulties to understand this = field=2E All of them thought=2C that this field contains an encrypted = version of the whole NTP package=2E And this is wrong=2E I think the pro= blem is this line=3A =5B=2E=2E=2E=5D authentication tag in addition to the a= ctual = ciphertext=2E =5B=2E=2E=2E=5D=2E Well=2C if readers do not know exactly = how AEAD works=2C = then this leads to strong understanding problems at this point=2C since = the terms =27authentication tag=27 and =27ciphertext=27 seem not known=2E= I think = we should add a reference (RFC 5116 --=26gt=3B AEAD) or some information= = about this terms (=27authentication tag=27 is like a MAC and =27cipherte= xt=27 = contains optional Extension Fields and can be absent if no Extension = Fields are encrypted=2E)=2E Maybe confuses the field name =27Chipertext=27= too=2E=3Cbr /=3E=3Cbr /=3E=3Cbr /=3E=27Padding=3A=27=C2=A0 This line=3A =5B=2E=2E=2E=5D so that implementations can unambiguously = delimit the = end of the ciphertext from the start of the padding =5B=2E=2E=2E=5D can = be = difficult to=2E In the beginning I did not know how this should work=2E = We = should say that implementations can read the last octet of this = extension content=2C to find out how big the padding is=2E=3Cbr /=3E=3Cb= r /=3EFurthermore we should change this line=3A=3Cbr /=3E=5B=2E=2E=2E=5D= requirement that (in the absence of a legacy MAC) extensions have a = total length in octets (including the four octets for the type and = length fields)=C2=A0 =5B=2E=2E=2E=5D=3Cbr /=3E=3Cbr /=3Ein this=3A=3Cbr = /=3E=5B=2E=2E=2E=5D requirement that (in the absence of a legacy MAC) =3C= b=3ENTP=3C/b=3E extensions have a total length in octets (including the = four octets for the type and length fields) =5B=2E=2E=2E=5D=3Cbr /=3E=3C= br /=3E=3Cbr /=3E------------------------------=3Cwbr=3E=3C/wbr=3E--=3Cb= r /=3E=3Cbr /=3E=5B=2E=2E=2E=5D P=3A The plaintext SHALL consist of all = (if any) extensions to be encrypted=2E =5B=2E=2E=2E=5D =3Cbr /=3E=3Cbr /= =3EWhich format=3F Typical NTPv4 Extension Fields or another format=3F We should= = define that=2E We should also mention that only this content is encrypte= d = (not the content of parameter =27A=27)=2E =3Cbr /=3EIf we don=27t want e= ncrypt anything (default case)=2C then this parameter is empty=2E=3Cbr /= =3E=3Cbr /=3E=3Cbr /=3E=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3Cwbr=3E=3C/wbr=3E=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3Cbr /=3E=3Cbr /=3EPlease let me know if you have problems to unders= tand my *english*=2E=3Cbr /=3E=3Cbr /=3E=3Cbr /=3EBest regards=2C=3Cbr /= =3EMartin=3C/div=3E --Boundary_(ID_rM1s1mbl5mZ15Cv8kGSDmw)-- --===============6979419572004254437== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp --===============6979419572004254437==-- From nobody Fri Aug 11 02:35:02 2017 Return-Path: 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 81C461324A8 for ; Fri, 11 Aug 2017 02:34:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sonia.de 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 fe7fY8I2AFjo for ; Fri, 11 Aug 2017 02:34:56 -0700 (PDT) Received: from mailgate1.sonia.de (mailgate1.sonia.de [141.41.1.242]) (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 18AAC132488 for ; Fri, 11 Aug 2017 02:34:56 -0700 (PDT) Received: from mailgate1.sonia.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 7940E15876 for ; Fri, 11 Aug 2017 11:34:54 +0200 (CEST) Received: from mail.sonia.de (mail.sonia.de [141.41.8.70]) by mailgate1.sonia.de (Postfix) with ESMTP id 610EA15870 for ; Fri, 11 Aug 2017 11:34:54 +0200 (CEST) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_rM1s1mbl5mZ15Cv8kGSDmw)" Received: from ostfalia.de ([141.41.8.70]) by mail.sonia.de (Oracle Communications Messaging Server 7.0.5.37.0 64bit (built Jan 25 2016)) with ESMTPA id <0OUI00HFHLA6RU30@mail.sonia.de> for ntp@ietf.org; Fri, 11 Aug 2017 11:34:54 +0200 (CEST) Received: from [141.41.8.91] (Forwarded-For: 141.41.8.91) by mail.sonia.de (mshttpd); Fri, 11 Aug 2017 11:34:54 +0200 From: Martin Langer To: ntp@ietf.org Message-id: <70a0c971b2978.598d965e@ostfalia.de> Date: Fri, 11 Aug 2017 11:34:54 +0200 X-Mailer: Oracle Communications Messenger Express 7.0.5.37.0 64bit (built Jan 25 2016) Content-language: de X-Accept-Language: de Priority: normal DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sonia.de; h=mime-version:content-type:from:to:message-id:date:subject; s=20140129; bh=rJMcg9q1rQLEQAHzu+aKXlMwV4wbdISBCedltdlWJek=; b=Mszci/qz6/6DDZD/sYI/ltqWJMRLSATbPtXJawVGWaVp98cG5h5gG7JxFDrIuYqhhIbF1/oxQ/DmBbTHGamxWypBs4cUpanb/kbeTTsNXEkmSYnmt52RWmuhAteB814PVF/xo14mttTqgm5dRXDA+wuNMI9+WcuF+/S1CM37qjg= Archived-At: Subject: [Ntp] some comments on the NTS4NTP-Draft09 X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Aug 2017 09:34:59 -0000 This is a multi-part message in MIME format. --Boundary_(ID_rM1s1mbl5mZ15Cv8kGSDmw) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Content-disposition: inline Hi all, At first, I wanted to tell you briefly that the new NTS implementation will start next week. I have some points/comments on the NTS4NTP-Draft09 that I wanted to mention in this way. Therefore, the content is primarily directed at Daniel Franke. In advance, I'm in Japan for the next 3 weeks and will probably not be able to respond to comments or emails. I ask for understanding. ================================================================================= NTS4NTP-Draft09 ================================================================================= 1. confusing term "ntp/4" ============================================================ page 10 (chapter 5.1.5, 2nd section): ----------------------------------------- [...] If the NTS Next Protocol Negotiation record offers "ntp/4",this record MUST be included exactly once. [...] page 11 (chapter 5.1.5, 4th section): ----------------------------------------- [...] and the server accepts the "ntp/4" protocol in its NTS Next Protocol Negotiation record [...] page 11 (chapter 6.1, 1st section): ----------------------------------------- [...] Following a successful run of the NTS-KE protocol wherein "ntp/4" is selected as a Next Protocol [...] remark: ----------------------------------------- "ntp/4" is the same term as in the TLS ALPN extension (see: page 18, chapter 8): [...] IANA is requested to allocate the following two entries in the Application-Layer Protocol Negotation (ALPN) Protocol IDs registry: [...] Protocol: Network Time Protocol, version 4 Identification Sequence: 0x6E 0x74 0x70 0x2F 0x34 ("ntp/4") [...] But the NTS Next Protocol Negotiation record contains IDs (e.g. 0x00 for 'Network Time Protocol version 4'; see table at page 21) and not the term 'ntp/4'. This can confusing some readers. 2. Network Byte Order / Host Byte Order ============================================================ page 8 (chapter 5, 5th section): ----------------------------------------- [...] Record Type: A 15-bit integer in network byte order (from most-to-least significant, its bits are record bits 7-1 and then 15-8). [...] remark: ----------------------------------------- Why 7-1 and then 15-8? Are we use the Little Endian format for the 'Record Type' only or for the whole record? Why we don't use Big Endian? 3. general comment ============================================================ page 12 (chapter 6.1, 2nd section): ----------------------------------------- [...] The per-association context value SHALL consist of the following five octets: The first two octets SHALL be zero.[...] remark: ----------- My first thought was: why? At first it was a magic number for me. The solution is here: chapter 5.2: [...] and MUST begin with the two-octet Protocol ID which was negotiated as a Next Protocol. [...] I think this should be mentioned again or referenced to the corresponding table (chapter 8). 4. general comment ============================================================ page 13 (chapter 6.5, 2nd section): ----------------------------------------- [...] This length requirement serves to ensure that the response will not be larger than the request, in order to improve timekeeping precision and [...] remark: ----------- Does it really improve the timekeeping? I think the idea is to reduce the asymmetry if the request and response message have the same size. But client and server may have different performance and therefore the processing speed per NTP Package is different too. ...it's just a thought 5. alternative proposal ============================================================ page 20 (chapter 8, 1st section): ----------------------------------------- [...] Type Number (REQUIRED): An integer in the range 0-32767 inclusive [...] better?: ----------- [...] Type Number (REQUIRED): An 15 bit integer in the range 0-32767 inclusive [...] ....not 16 bit, because we use a critical bit in our records (first bit) 6. some problems with 'The NTS Authenticator and Encrypted Extensions extension' (page 14, chapter 6.6) ============================================================ field description: ----------------------------------------- 'Nonce lenght': We should mention that the value is to be interpreted as 'unsigned int'. 'Nonce': At first I had some trouble to understand where the nonce comes from and which length we use. Now I know it, but maybe we should add some more information to this field. perhaps from these: [...] Nonce: a nonce as required by the negotiated AEAD Algorithm. [...] to these: [...] Nonce: a new generated nonce whose length and format is determined by the negotiated AEAD algorithm (RFC 5116, chapter 3.2). [...] 'Chipertext': Some readers (students in my team) had difficulties to understand this field. All of them thought, that this field contains an encrypted version of the whole NTP package. And this is wrong. I think the problem is this line: [...] authentication tag in addition to the actual ciphertext. [...]. Well, if readers do not know exactly how AEAD works, then this leads to strong understanding problems at this point, since the terms 'authentication tag' and 'ciphertext' seem not known. I think we should add a reference (RFC 5116 --> AEAD) or some information about this terms ('authentication tag' is like a MAC and 'ciphertext' contains optional Extension Fields and can be absent if no Extension Fields are encrypted.). Maybe confuses the field name 'Chipertext' too. 'Padding:' This line: [...] so that implementations can unambiguously delimit the end of the ciphertext from the start of the padding [...] can be difficult to. In the beginning I did not know how this should work. We should say that implementations can read the last octet of this extension content, to find out how big the padding is. Furthermore we should change this line: [...] requirement that (in the absence of a legacy MAC) extensions have a total length in octets (including the four octets for the type and length fields) [...] in this: [...] requirement that (in the absence of a legacy MAC) NTP extensions have a total length in octets (including the four octets for the type and length fields) [...] -------------------------------- [...] P: The plaintext SHALL consist of all (if any) extensions to be encrypted. [...] Which format? Typical NTPv4 Extension Fields or another format? We should define that. We should also mention that only this content is encrypted (not the content of parameter 'A'). If we don't want encrypt anything (default case), then this parameter is empty. ============================================================ Please let me know if you have problems to understand my *english*. Best regards, Martin --Boundary_(ID_rM1s1mbl5mZ15Cv8kGSDmw) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable Content-disposition: inline Hi all=2C=3Cbr /=3E=3Cbr /=3EAt first=2C I wanted to tell you briefly th= at the new NTS = implementation will start next week=2E I have some points/comments on th= e = NTS4NTP-Draft09 that I wanted to mention in this way=2E Therefore=2C the= = content is primarily directed at Daniel Franke=2E=3Cbr /=3EIn advance=2C= I=27m in = Japan for the next 3 weeks and will probably not be able to respond to = comments or emails=2E I ask for understanding=2E=3Cbr /=3E=3Cbr /=3E=3Cb= r /=3E=3Cbr /=3E=3Cdiv=3E=3Cwbr=3E=3C/wbr=3E=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3Cwbr=3E=3C= /wbr=3E=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3Cwbr=3E=3C/wbr=3E=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3Cbr /=3ENTS4NTP-Draft09=3Cbr /=3E=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3Cwbr=3E=3C/wbr=3E=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3Cwbr=3E=3C/wbr=3E=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3Cbr /=3E=3Cbr= /=3E=3Cbr /=3E1=2E confusing term =26quot=3Bntp/4=26quot=3B=3Cbr /=3E=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3Cwbr=3E=3C/wbr=3E=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3Cbr /=3E=3Cbr /=3Ep= age 10 (chapter 5=2E1=2E5=2C 2nd section)=3A=3Cbr /=3E------------------= ------------=3Cwbr=3E=3C/wbr=3E-----------=3Cbr /=3E=5B=2E=2E=2E=5D If t= he NTS Next Protocol Negotiation record offers =26quot=3Bntp/4=26quot=3B= =2Cthis record MUST be included exactly once=2E =5B=2E=2E=2E=5D=3Cbr /=3E= =3Cbr /=3E=3Cbr /=3Epage 11 (chapter 5=2E1=2E5=2C 4th section)=3A=3Cbr /= =3E------------------------------=3Cwbr=3E=3C/wbr=3E-----------=3Cbr /=3E= =5B=2E=2E=2E=5D and the server accepts the =26quot=3Bntp/4=26quot=3B pro= tocol in its NTS Next Protocol Negotiation record =5B=2E=2E=2E=5D=3Cbr /= =3E=3Cbr /=3E=3Cbr /=3Epage 11 (chapter 6=2E1=2C 1st section)=3A=3Cbr /=3E= ------------------------------=3Cwbr=3E=3C/wbr=3E-----------=3Cbr /=3E=5B= =2E=2E=2E=5D Following a successful run of the NTS-KE protocol wherein =26= quot=3Bntp/4=26quot=3B is selected as a Next Protocol =5B=2E=2E=2E=5D=3C= br /=3E=3Cbr /=3E=3Cbr /=3Eremark=3A=3Cbr /=3E--------------------------= ----=3Cwbr=3E=3C/wbr=3E-----------=3Cbr /=3E=26quot=3Bntp/4=26quot=3B is= the same term as in the TLS ALPN extension (see=3A page 18=2C chapter 8= )=3A=3Cbr /=3E=3Cbr /=3E=5B=2E=2E=2E=5D IANA is requested to allocate the following two entries in the = Application-Layer Protocol Negotation (ALPN) Protocol IDs registry=3A = =5B=2E=2E=2E=5D Protocol=3A Network Time Protocol=2C version 4=C2=A0=C2=A0= Identification = Sequence=3A 0x6E 0x74 0x70 0x2F 0x34 (=26quot=3Bntp/4=26quot=3B) =5B=2E=2E= =2E=5D=3Cbr /=3E=3Cbr /=3EBut the NTS = Next Protocol Negotiation record contains IDs (e=2Eg=2E 0x00 for =27Netw= ork = Time Protocol version 4=27=3B see table at page 21) and not the term = =27ntp/4=27=2E This can confusing some readers=2E=3Cbr /=3E=3Cbr /=3E=3C= br /=3E=3Cbr /=3E=3Cbr /=3E=3Cbr /=3E2=2E Network Byte Order / Host Byte= Order=3Cbr /=3E=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3Cwbr=3E=3C/wbr=3E=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3C= br /=3E=3Cbr /=3Epage 8 (chapter 5=2C 5th section)=3A=3Cbr /=3E---------= ---------------------=3Cwbr=3E=3C/wbr=3E-----------=3Cbr /=3E=5B=2E=2E=2E= =5D Record Type=3A A 15-bit integer in network byte order (from most-to-lea= st significant=2C its bits are record bits 7-1 and then 15-8)=2E =5B=2E=2E= =2E=5D=3Cbr /=3E=3Cbr /=3E=3Cbr /=3Eremark=3A=3Cbr /=3E-----------------= -------------=3Cwbr=3E=3C/wbr=3E----------- =3Cbr /=3EWhy 7-1 and then 15-8=3F Are we use the Little Endian format for the =27Rec= ord = Type=27 only or for the whole record=3F Why we don=27t use Big Endian=3F= =3Cbr /=3E=3Cbr /=3E=3Cbr /=3E=3Cbr /=3E=3Cbr /=3E=3Cbr /=3E=3Cbr /=3E3=2E= general comment=3Cbr /=3E=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3Cwbr=3E=3C/wbr=3E=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3Cbr /=3E=3Cbr /=3Epage 12 (chapter 6=2E1=2C 2nd section)=3A=3Cbr= /=3E------------------------------=3Cwbr=3E=3C/wbr=3E-----------=3Cbr /= =3E=5B=2E=2E=2E=5D The per-association context value SHALL consist of th= e following five octets=3A The first two octets SHALL be zero=2E=5B=2E=2E= =2E=5D=3Cbr /=3E=3Cbr /=3E=3Cbr /=3Eremark=3A=3Cbr /=3E----------- =3Cbr= /=3EMy first thought was=3A why=3F At first it was a magic number for m= e=2E The solution is here=3A chapter 5=2E2=3A =3Cbr /=3E=5B=2E=2E=2E=5D = and MUST begin with the two-octet Protocol ID which was negotiated as a = Next Protocol=2E =5B=2E=2E=2E=5D=3Cbr /=3E=3Cbr /=3EI think this should = be mentioned again or referenced to the corresponding table (chapter 8)=2E= =3Cbr /=3E=3Cbr /=3E=3Cbr /=3E=3Cbr /=3E=3Cbr /=3E=3Cbr /=3E4=2E general= comment=3Cbr /=3E=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3Cwbr=3E=3C/wbr=3E=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3Cbr /=3E=3Cbr /=3Epage 13 (chapter 6=2E5=2C 2nd section)=3A=3Cbr /=3E-= -----------------------------=3Cwbr=3E=3C/wbr=3E-----------=3Cbr /=3E=5B= =2E=2E=2E=5D This length requirement serves to ensure that the response will not be = larger than the request=2C in order to improve timekeeping precision and= = =5B=2E=2E=2E=5D=3Cbr /=3E=3Cbr /=3E=3Cbr /=3Eremark=3A=3Cbr /=3E--------= --- =3Cbr /=3EDoes it really improve the = timekeeping=3F I think the idea is to reduce the asymmetry if the reques= t = and response message have the same size=2E =3Cbr /=3EBut client and serv= er may = have different performance and therefore the processing speed per NTP = Package is different too=2E=C2=A0 =2E=2E=2Eit=27s just a thought=3Cbr /=3E= =3Cbr /=3E=3Cbr /=3E=3Cbr /=3E=3Cbr /=3E=3Cbr /=3E5=2E alternative propo= sal=3Cbr /=3E=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3Cwbr=3E=3C/wbr=3E=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3Cbr = /=3E=3Cbr /=3Epage 20 (chapter 8=2C 1st section)=3A=3Cbr /=3E-----------= -------------------=3Cwbr=3E=3C/wbr=3E-----------=3Cbr /=3E=5B=2E=2E=2E=5D= Type Number (REQUIRED)=3A An integer in the range 0-32767 inclusive =5B= =2E=2E=2E=5D=3Cbr /=3E=3Cbr /=3E=3Cbr /=3Ebetter=3F=3A=3Cbr /=3E--------= --- =3Cbr /=3E=5B=2E=2E=2E=5D Type Number (REQUIRED)=3A An =3Cb=3E15 bit= =3C/b=3E integer in the range 0-32767 inclusive =5B=2E=2E=2E=5D=3Cbr /=3E= =3Cbr /=3E=2E=2E=2E=2Enot 16 bit=2C because we use a critical bit in our= records (first bit)=3Cbr /=3E=3Cbr /=3E=3Cbr /=3E=3Cbr /=3E=3Cbr /=3E=3C= br /=3E=3Cbr /=3E6=2E some problems with =27The NTS Authenticator and En= crypted Extensions extension=27 (page 14=2C chapter 6=2E6)=3Cbr /=3E=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3Cwbr=3E=3C/wbr=3E=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3Cbr /=3E=3Cbr /=3Efiel= d description=3A=3Cbr /=3E------------------------------=3Cwbr=3E=3C/wbr= =3E-----------=3Cbr /=3E=27Nonce lenght=27=3A We should mention that the= value is to be interpreted as =27unsigned int=27=2E=3Cbr /=3E=3Cbr /=3E= =27Nonce=27=3A At first I had some trouble to understand where the nonce comes from = and which length we use=2E Now I know it=2C but maybe we should add some= = more information to this field=2E=3Cbr /=3Eperhaps from these=3A=C2=A0=C2= =A0 =5B=2E=2E=2E=5D Nonce=3A a = nonce as required by the negotiated AEAD Algorithm=2E =5B=2E=2E=2E=5D=C2= =A0=C2=A0 to these=3A=C2=A0=C2=A0 = =5B=2E=2E=2E=5D Nonce=3A a new generated nonce whose length and format i= s determined by the negotiated AEAD algorithm (RFC 5116=2C chapter 3=2E2)=2E =5B=2E=2E= =2E=5D=3Cbr /=3E=3Cbr /=3E=3Cbr /=3E=27Chipertext=27=3A Some readers (students in my team) had difficulties to understand this = field=2E All of them thought=2C that this field contains an encrypted = version of the whole NTP package=2E And this is wrong=2E I think the pro= blem is this line=3A =5B=2E=2E=2E=5D authentication tag in addition to the a= ctual = ciphertext=2E =5B=2E=2E=2E=5D=2E Well=2C if readers do not know exactly = how AEAD works=2C = then this leads to strong understanding problems at this point=2C since = the terms =27authentication tag=27 and =27ciphertext=27 seem not known=2E= I think = we should add a reference (RFC 5116 --=26gt=3B AEAD) or some information= = about this terms (=27authentication tag=27 is like a MAC and =27cipherte= xt=27 = contains optional Extension Fields and can be absent if no Extension = Fields are encrypted=2E)=2E Maybe confuses the field name =27Chipertext=27= too=2E=3Cbr /=3E=3Cbr /=3E=3Cbr /=3E=27Padding=3A=27=C2=A0 This line=3A =5B=2E=2E=2E=5D so that implementations can unambiguously = delimit the = end of the ciphertext from the start of the padding =5B=2E=2E=2E=5D can = be = difficult to=2E In the beginning I did not know how this should work=2E = We = should say that implementations can read the last octet of this = extension content=2C to find out how big the padding is=2E=3Cbr /=3E=3Cb= r /=3EFurthermore we should change this line=3A=3Cbr /=3E=5B=2E=2E=2E=5D= requirement that (in the absence of a legacy MAC) extensions have a = total length in octets (including the four octets for the type and = length fields)=C2=A0 =5B=2E=2E=2E=5D=3Cbr /=3E=3Cbr /=3Ein this=3A=3Cbr = /=3E=5B=2E=2E=2E=5D requirement that (in the absence of a legacy MAC) =3C= b=3ENTP=3C/b=3E extensions have a total length in octets (including the = four octets for the type and length fields) =5B=2E=2E=2E=5D=3Cbr /=3E=3C= br /=3E=3Cbr /=3E------------------------------=3Cwbr=3E=3C/wbr=3E--=3Cb= r /=3E=3Cbr /=3E=5B=2E=2E=2E=5D P=3A The plaintext SHALL consist of all = (if any) extensions to be encrypted=2E =5B=2E=2E=2E=5D =3Cbr /=3E=3Cbr /= =3EWhich format=3F Typical NTPv4 Extension Fields or another format=3F We should= = define that=2E We should also mention that only this content is encrypte= d = (not the content of parameter =27A=27)=2E =3Cbr /=3EIf we don=27t want e= ncrypt anything (default case)=2C then this parameter is empty=2E=3Cbr /= =3E=3Cbr /=3E=3Cbr /=3E=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3Cwbr=3E=3C/wbr=3E=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3Cbr /=3E=3Cbr /=3EPlease let me know if you have problems to unders= tand my *english*=2E=3Cbr /=3E=3Cbr /=3E=3Cbr /=3EBest regards=2C=3Cbr /= =3EMartin=3C/div=3E --Boundary_(ID_rM1s1mbl5mZ15Cv8kGSDmw)-- From ntp-bounces@ietf.org Sun Aug 13 00:34:38 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BCED1324A3; Sun, 13 Aug 2017 00:34:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1502609678; bh=wfL/CIzVV0QdPGXVEjSpfZSkZidv4UkrPHFS4wnjfkU=; h=In-Reply-To:References:From:Date:To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc; b=HVxSJ7Thr5srCv4/1mdMMtMaJGVbqtIPclRtDzvtPHcQ09vdLiSWbUfVHXFlF6LRL Mk3CX9e2tvh4IHiktHGFKPrxq5hSotMGPMaxiJqheEvc4iQ8AiahLsyrcxAlCuR5iM 9cAb8+d/ffBYKDTr6zsbveavptuzUcORwcS5eEUc= 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 56EA513284F; Sun, 13 Aug 2017 00:34:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 FOnRdsJsURyX; Sun, 13 Aug 2017 00:34:33 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (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 EE933132842; Sun, 13 Aug 2017 00:34:32 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id f15so21234839wmg.1; Sun, 13 Aug 2017 00:34:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=OnqJSex9/9B51Y5MqQFawoXt12zJBmPj2pJxH1ljsmg=; b=fi8a9e5iO3RZ64GRTqgg5gc2xJhGde5aZYI9HaxZZOaZU9mYBcOfcO0O//NyLsJr7/ XDoz4J8iiGYDMyyxQnbnqNFclMGwmFt71tEeu22zWXm0cm0Ud1pLJwYN+CRN/+scHviI 8hvKbZFbyFNnzGlIKbT7y5A+oWZSYdD5ISUP0D4zqKf1SR6D9qEgxPTtlp5k33n3VQIH 5dqzFDvAf6fHdAfeqhphscX7tWZvFku623msv96uqy9zewwg/b2vQzevHCvwMhXeFarg 7hs8hD+/U0FGI2UcmUrplBrYhTqv+jPqJ4EY5rzq9SEppukLpaCdd5RF6HNVVn1M2Af9 9C2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=OnqJSex9/9B51Y5MqQFawoXt12zJBmPj2pJxH1ljsmg=; b=NQf3XJBCEXbCitq0H7CUBzuR4RtpY1t+gjdINJ3flAXk8Idd3DqZsQvO1dBF7CdBiR rgPEypQGsfLC58sl9WB728elVWcaZa/5U+0YWMwPJj8bF7yJklOhlWf0P8Lqky/vIa28 pCkpBmqbg9NCnNxAOBTnROceN1tpeWXgRB6k44kyzqVXxUadZEImyTXiBwVRUR99y78a d5UJAlwio/Na1JfS49Fe2QfdurWBMHhZKPfLlc3nIL2pqJ169QM6WAkUJhhpT6w5K+8j +Q7+3gSQGPRpTsBXZ4QGQVk9idrGJZOfyJJ7yNlzHoiQ5/q9l9mwMBIEAS6+C782LQB7 j0sA== X-Gm-Message-State: AHYfb5htNdu3vud4+g2JPHwNhDrQDsdZ2VMmmDHeYcbS/I48o/TY6tzV D2CD0tN/4uO4vk+7DR+979aHh/J5Wwy1 X-Received: by 10.80.162.133 with SMTP id 5mr20898381edm.116.1502609671562; Sun, 13 Aug 2017 00:34:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.240.210 with HTTP; Sun, 13 Aug 2017 00:34:31 -0700 (PDT) In-Reply-To: References: From: Tal Mizrahi Date: Sun, 13 Aug 2017 10:34:31 +0300 Message-ID: To: "Karen O'Donoghue" Archived-At: Subject: Re: [Ntp] [TICTOC] WGLC for draft-ietf-ntp-mac X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "ntp@ietf.org" , "tictoc@ietf.org" Content-Type: multipart/mixed; boundary="===============6514446292184657630==" Errors-To: ntp-bounces@ietf.org Sender: "ntp" --===============6514446292184657630== Content-Type: multipart/alternative; boundary="94eb2c0d98f2b5ab6105569d93f8" --94eb2c0d98f2b5ab6105569d93f8 Content-Type: text/plain; charset="UTF-8" Hi, I believe this draft is clear and well-written. A couple of major comments should probably be addressed before proceeding. Major comments: - This may have been discussed before, but still I am not sure what the answer is: it seems to make sense to define this new MAC as a dedicated extension field. Any reason not to do that? Since this draft deprecates the previous MD5-based MAC, there are no backward compatibility considerations. - To allow algorithm agility, I would suggest to add a field that specifies the algorithm + a corresponding IANA registry. Less major comments: - Missing security considerations section. - Missing IANA considerations section. - "any extension fields that are present" => "every extension fields that is present". Thanks, Tal. On Wed, Aug 9, 2017 at 7:53 AM, Karen O'Donoghue wrote: > Folks, > > This begins a three week working group last call (WGLC) for "Message > Authentication Code for the Network Time Protocol" > https://datatracker.ietf.org/doc/draft-ietf-ntp-mac/ > > Please review and provide comments to the mailing list by no later than 31 > August 2017. Earlier comments and discussion would be appreciated. Please > note that the chairs will be using this WGLC to determine consensus to move > this document forward to the IESG. > > Also, as a reminder, we have migrated the working group mailing list to > IETF infrastructure. Please respond to ntp@ietf.org. > > Regards, > Karen and Dieter > > _______________________________________________ > TICTOC mailing list > TICTOC@ietf.org > https://www.ietf.org/mailman/listinfo/tictoc > > --94eb2c0d98f2b5ab6105569d93f8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I believe this draft is clear and w= ell-written. A couple of major comments should probably be addressed before= proceeding.

Major comments:
- This may = have been discussed before, but still I am not sure what the answer is: it = seems to make sense to define this new MAC as a dedicated extension field. = Any reason not to do that? Since this draft deprecates the previous MD5-bas= ed MAC, there are no backward compatibility considerations.
- To = allow algorithm agility, I would suggest to add a field that specifies the = algorithm + a corresponding IANA registry.

Less ma= jor comments:
- Missing security considerations section.
- Missing IANA considerations section.
- "any extension fi= elds that are present" =3D> "every extension fields that is pr= esent".

Thanks,
Tal.

=


On Wed, Aug 9, 2017 at 7:53 AM, Karen O'Donoghue <odonoghue= @isoc.org> wrote:
Folks,

This begins a three week working group last call (WGLC) for "Message A= uthentication Code for the Network Time Protocol"
https://datatracker.ietf.org/doc/draft-ietf-ntp-mac/

Please review and provide comments to the mailing list by no later than 31 = August 2017. Earlier comments and discussion would be appreciated. Please n= ote that the chairs will be using this WGLC to determine consensus to move = this document forward to the IESG.=C2=A0

Also, as a reminder, we have migrated the working group mailing list to IET= F infrastructure. Please respond to=C2=A0ntp@ietf.org.=C2=A0

Regards,
Karen and Dieter

_______________________________________________
TICTOC mailing list
TICTOC@ietf.org
https://www.ietf.org/mailman/listinfo/tictoc

--94eb2c0d98f2b5ab6105569d93f8-- --===============6514446292184657630== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp --===============6514446292184657630==-- From nobody Sun Aug 13 00:34:44 2017 Return-Path: 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 56EA513284F; Sun, 13 Aug 2017 00:34:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 FOnRdsJsURyX; Sun, 13 Aug 2017 00:34:33 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (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 EE933132842; Sun, 13 Aug 2017 00:34:32 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id f15so21234839wmg.1; Sun, 13 Aug 2017 00:34:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=OnqJSex9/9B51Y5MqQFawoXt12zJBmPj2pJxH1ljsmg=; b=fi8a9e5iO3RZ64GRTqgg5gc2xJhGde5aZYI9HaxZZOaZU9mYBcOfcO0O//NyLsJr7/ XDoz4J8iiGYDMyyxQnbnqNFclMGwmFt71tEeu22zWXm0cm0Ud1pLJwYN+CRN/+scHviI 8hvKbZFbyFNnzGlIKbT7y5A+oWZSYdD5ISUP0D4zqKf1SR6D9qEgxPTtlp5k33n3VQIH 5dqzFDvAf6fHdAfeqhphscX7tWZvFku623msv96uqy9zewwg/b2vQzevHCvwMhXeFarg 7hs8hD+/U0FGI2UcmUrplBrYhTqv+jPqJ4EY5rzq9SEppukLpaCdd5RF6HNVVn1M2Af9 9C2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=OnqJSex9/9B51Y5MqQFawoXt12zJBmPj2pJxH1ljsmg=; b=NQf3XJBCEXbCitq0H7CUBzuR4RtpY1t+gjdINJ3flAXk8Idd3DqZsQvO1dBF7CdBiR rgPEypQGsfLC58sl9WB728elVWcaZa/5U+0YWMwPJj8bF7yJklOhlWf0P8Lqky/vIa28 pCkpBmqbg9NCnNxAOBTnROceN1tpeWXgRB6k44kyzqVXxUadZEImyTXiBwVRUR99y78a d5UJAlwio/Na1JfS49Fe2QfdurWBMHhZKPfLlc3nIL2pqJ169QM6WAkUJhhpT6w5K+8j +Q7+3gSQGPRpTsBXZ4QGQVk9idrGJZOfyJJ7yNlzHoiQ5/q9l9mwMBIEAS6+C782LQB7 j0sA== X-Gm-Message-State: AHYfb5htNdu3vud4+g2JPHwNhDrQDsdZ2VMmmDHeYcbS/I48o/TY6tzV D2CD0tN/4uO4vk+7DR+979aHh/J5Wwy1 X-Received: by 10.80.162.133 with SMTP id 5mr20898381edm.116.1502609671562; Sun, 13 Aug 2017 00:34:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.240.210 with HTTP; Sun, 13 Aug 2017 00:34:31 -0700 (PDT) In-Reply-To: References: From: Tal Mizrahi Date: Sun, 13 Aug 2017 10:34:31 +0300 Message-ID: To: "Karen O'Donoghue" Cc: "ntp@ietf.org" , "tictoc@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c0d98f2b5ab6105569d93f8" Archived-At: Subject: Re: [Ntp] [TICTOC] WGLC for draft-ietf-ntp-mac X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Aug 2017 07:34:35 -0000 --94eb2c0d98f2b5ab6105569d93f8 Content-Type: text/plain; charset="UTF-8" Hi, I believe this draft is clear and well-written. A couple of major comments should probably be addressed before proceeding. Major comments: - This may have been discussed before, but still I am not sure what the answer is: it seems to make sense to define this new MAC as a dedicated extension field. Any reason not to do that? Since this draft deprecates the previous MD5-based MAC, there are no backward compatibility considerations. - To allow algorithm agility, I would suggest to add a field that specifies the algorithm + a corresponding IANA registry. Less major comments: - Missing security considerations section. - Missing IANA considerations section. - "any extension fields that are present" => "every extension fields that is present". Thanks, Tal. On Wed, Aug 9, 2017 at 7:53 AM, Karen O'Donoghue wrote: > Folks, > > This begins a three week working group last call (WGLC) for "Message > Authentication Code for the Network Time Protocol" > https://datatracker.ietf.org/doc/draft-ietf-ntp-mac/ > > Please review and provide comments to the mailing list by no later than 31 > August 2017. Earlier comments and discussion would be appreciated. Please > note that the chairs will be using this WGLC to determine consensus to move > this document forward to the IESG. > > Also, as a reminder, we have migrated the working group mailing list to > IETF infrastructure. Please respond to ntp@ietf.org. > > Regards, > Karen and Dieter > > _______________________________________________ > TICTOC mailing list > TICTOC@ietf.org > https://www.ietf.org/mailman/listinfo/tictoc > > --94eb2c0d98f2b5ab6105569d93f8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I believe this draft is clear and w= ell-written. A couple of major comments should probably be addressed before= proceeding.

Major comments:
- This may = have been discussed before, but still I am not sure what the answer is: it = seems to make sense to define this new MAC as a dedicated extension field. = Any reason not to do that? Since this draft deprecates the previous MD5-bas= ed MAC, there are no backward compatibility considerations.
- To = allow algorithm agility, I would suggest to add a field that specifies the = algorithm + a corresponding IANA registry.

Less ma= jor comments:
- Missing security considerations section.
- Missing IANA considerations section.
- "any extension fi= elds that are present" =3D> "every extension fields that is pr= esent".

Thanks,
Tal.

=


On Wed, Aug 9, 2017 at 7:53 AM, Karen O'Donoghue <odonoghue= @isoc.org> wrote:
Folks,

This begins a three week working group last call (WGLC) for "Message A= uthentication Code for the Network Time Protocol"
https://datatracker.ietf.org/doc/draft-ietf-ntp-mac/

Please review and provide comments to the mailing list by no later than 31 = August 2017. Earlier comments and discussion would be appreciated. Please n= ote that the chairs will be using this WGLC to determine consensus to move = this document forward to the IESG.=C2=A0

Also, as a reminder, we have migrated the working group mailing list to IET= F infrastructure. Please respond to=C2=A0ntp@ietf.org.=C2=A0

Regards,
Karen and Dieter

_______________________________________________
TICTOC mailing list
TICTOC@ietf.org
https://www.ietf.org/mailman/listinfo/tictoc

--94eb2c0d98f2b5ab6105569d93f8-- From nobody Sun Aug 20 19:41:16 2017 Return-Path: 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 461E413233D for ; Sun, 20 Aug 2017 19:41:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 vXsp2BPqnH0J for ; Sun, 20 Aug 2017 19:41:05 -0700 (PDT) Received: from chessie.everett.org (chessie.everett.org [IPv6:2001:470:1:205::234]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99B11132334 for ; Sun, 20 Aug 2017 19:41:05 -0700 (PDT) Received: from [10.66.3.3] (96-41-166-181.dhcp.mdfd.or.charter.com [96.41.166.181]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by chessie.everett.org (Postfix) with ESMTPSA id 2F0D6B869; Mon, 21 Aug 2017 02:41:05 +0000 (UTC) To: ntp@ietf.org From: Harlan Stenn Message-ID: Date: Sun, 20 Aug 2017 19:41:06 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------3C4BF6836A7A9E69A9AB312E" Content-Language: en-US Archived-At: Subject: [Ntp] NTS/Updated Autokey X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Aug 2017 02:41:11 -0000 This is a multi-part message in MIME format. --------------3C4BF6836A7A9E69A9AB312E Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Dave has been working on an evaluation of the NTS proposal. We've been discussing this document in our internal NTS implementation meetings, and Dieter asked me to send this to the WG mailing list. Dave updated the document after my last go-round, so I just took his new version and integrated his changes with the ones we made. I'll be working on my WGLC comments separately. -- Harlan Stenn, Network Time Foundation http://nwtime.org - be a Member! --------------3C4BF6836A7A9E69A9AB312E Content-Type: text/plain; charset=UTF-8; name="Autokey-20170815.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Autokey-20170815.txt" 77u/RW5naW5lZXJpbmcgYW5kIFNlY3VyaXR5IGZvciB0aGUgTmV0d29yayBUaW1lIFByb3Rv Y29sIChOVFApDQpEYXZpZCBMLiBNaWxscw0KMTUgQXVndXN0LCAyMDE3DQoNCg0KQWJzdHJh Y3QNCg0KDQpUaGlzIGRvY3VtZW50IGV4cGxvcmVzIHRoZSBzZWN1cml0eSBhcmNoaXRlY3R1 cmUgYW5kIHByb3RvY29scyBmb3IgdGhlIG5ldHdvcmsgdGltZSBwcm90b2NvbCBOVFAuICBJ dCBwcm9wb3NlcyBhIHNldCBvZiBlbmdpbmVlcmluZyBwcmluY2lwbGVzIGJhc2VkIG9uIFJG QzU5MDUsIGFsb25nIHdpdGggYSByZWRlc2lnbiBvZiB0aGUgQXV0b2tleSBzY2hlbWUgZGVz Y3JpYmVkIGluIFJGQzU5MDYuDQoNCg0KVGhlIG5ldyBwcm90b2NvbCBpcyBtb3JlIHJlc2lz dGFudCB0byBwcm90b2NvbCBlcnJvcnMgYW5kIGtleSByZXBsYWNlbWVudC4gVGhlIHByb3Rv Y29sIGludm9sdmVzIHZhcmlvdXMgYWdyZWVtZW50IGFuZCBzaWduYXR1cmUgYWxnb3JpdGht cyBsZWFkaW5nIHRvIGEgc2VjdXJlIG1lYW5zIGZvciBwcm90ZWN0aW5nIE5UUCBmcm9tIHdp cmV0YXAgYW5kIG1pZGRsZW1hbiBhdHRhY2suIFRoZSBuZXcgcHJvdG9jb2wgaGFzIHR3byBh ZHZhbnRhZ2VzOiBhIGNvbXBhY3Qgc2lnbmF0dXJlIHRyYWlsIHRoYXQgYXZvaWRzIGEgY2Vy dGlmaWNhdGUgY2FjaGUgYW5kIGEgaGFzaCBzY2hlbWUgdGhhdCB3b3JrcyBmb3IgYWxsIHBh Y2tldHMsIGluY2x1ZGluZyB0aGUgaGFuZHNoYWtlIHBhY2tldHMuDQoNCg0KMS4gSW50cm9k dWN0aW9uDQoNCg0KUmVjZW50IGludGVybmV0IGRyYWZ0cyBbbGlzdF0gaGF2ZSBkZXNjcmli ZWQg4oCcTmV0d29yayBUaW1lIFNlY3VyaXR54oCdIChOVFMpLCBhIHNlY3VyaXR5IGFyY2hp dGVjdHVyZSBtb2RlbCB0b2dldGhlciB3aXRoIGl0cyBhcHBsaWNhdGlvbiB0byBOVFAuIFRo aXMgbW9kZWwsIHdoaWxlIHRlY2huaWNhbGx5IHNvdW5kLCBoYXMgc2lnbmlmaWNhbnQgcHJv YmxlbXMgd2l0aCB0aGUgY3VycmVudCBOVFAgYXJjaGl0ZWN0dXJlIG1vZGVsIGFzIGRlc2Ny aWJlZCBpbiBSRkM1OTA1LiBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBob3cgYW5kIHdoeSB0 aGUgdHdvIGFyY2hpdGVjdHVyZSBtb2RlbHMgZGlmZmVyIGFuZCBob3cgY2VydGFpbiBjaGFu Z2VzIG1pZ2h0IG1pdGlnYXRlIHRoZSBwcm9ibGVtcyB3aXRoIHRoZSBOVFMgbW9kZWwuDQoN Cg0KT25lIG9mIHRoZSBtb3N0IGltcG9ydGFudCBpc3N1ZXMgZHVyaW5nIHRoZSB0d28gZGVj YWRlcyBvZiBOVFAgc2VjdXJpdHkgZGV2ZWxvcG1lbnQgaGFzIGJlZW4gdG8gZGVzaWduIHRo ZSBzZWN1cml0eSBtZWFucyBhcyBhbiBpbnRlZ3JhdGVkIHN5c3RlbS4gVGhpcyBpbnZvbHZl cyBjYXJlZnVsIGNvbnNpZGVyYXRpb24gb24gdGltZW91dHMsIHByb3RvY29sIHJlc3RhcnRz IGFuZCBlcnJvciByZWNvdmVyeS4gRXZlcnl0aGluZyBkZXBlbmRzIG9uIGV2ZXJ5dGhpbmcg ZWxzZSwgYW5kIGEgdGlueSBjaGFuZ2UgbWF5IGhhdmUgdW5pbnRlbmRlZCBjb25zZXF1ZW5j ZXMuDQoNCg0KVGhpcyBkb2N1bWVudCBhdHRlbXB0cyB0byBjb250aW51ZSB0aGUgZXZvbHV0 aW9uIG9mIHRoZSBOVFAgc2VjdXJpdHkgbW9kZWwuIEl0IG1heSBiZSB0aGF0IGxlc3NvbnMg aW4gdGhpcyBkb2N1bWVudCBhcmUgbm90IHVzZWZ1bCB0byB0aGUgTlRQIG5ldHdvcmtpbmcg Y29tbXVuaXR5LCBidXQgaW4gYW55IGNhc2UgdGhleSBjYW4gYmUgdXNlZnVsIGFzIGEgc2Fu aXR5IGNoZWNrLg0KDQoNCkluIGFkZGl0aW9uLCB0aGUgQXV0b2tleSBwdWJsaWMga2V5IHNl Y3VyaXR5IHNjaGVtZSBkZXNjcmliZWQgaW4gUkZDNTkwNiB3YXMgZGVzaWduZWQgYW5kIGlt cGxlbWVudGVkIG92ZXIgdHdlbnR5IHllYXJzIGFnby4gVGltZSBhbmQgTW9vcmUncyBsYXcg aGF2ZSBjYXVnaHQgdXAgdG8gaXQuIEJhY2sgdGhlbiwgaXQgdG9vayBvdmVyIG9uZSBzZWNv bmQgdG8gY2FsY3VsYXRlIGEgcHVibGljIGtleSBzaWduYXR1cmUuIFRvZGF5LCBpdCB0YWtl cyBvbmx5IGEgbWlsbGlzZWNvbmQgb3IgdHdvLg0KDQoNClRoaXMgZG9jdW1lbnQgb3V0bGlu ZXMgYSBwcm9wb3NlZCByZXBsYWNlbWVudCBmb3IgQXV0b2tleS4gVGhlIHNjaGVtZSBwcm9w b3NlZCBoZXJlIGlzIGJhc2VkIG9uIHRoZSBEaWZmaWUtSGVsbG1hbiBhZ3JlZW1lbnQgYWxn b3JpdGhtLCB3aGljaCByZXN1bHRzIGluIGFuIGVjb25vbWljYWwgaW1wbGVtZW50YXRpb24g YW5kIGxvdyBydW5uaW5nIHRpbWUuIFRoaXMgZG9jdW1lbnQgc3VnZ2VzdHMgYSB2YXJpYW50 IG9mIHRoaXMgYWxnb3JpdGhtIHBvcHVsYXJseSBrbm93biBhcyB0aGUgU3RhdGlvbi10by1T dGF0aW9uIFByb3RvY29sLg0KDQoNCkF1dG9rZXkgaW4gaXRzIHByZXNlbnQgZm9ybSBpcyBh biBvcHRpb25hbCBmZWF0dXJlIG9mIHRoZSByZWZlcmVuY2UgaW1wbGVtZW50YXRpb24uIElu IGZhY3QsIHRoZSBzaWduaWZpY2FudCBwcm9wb3NlZCBjaGFuZ2VzIGluIHRoaXMgZG9jdW1l bnQgYXJlIHRvIHRoZSBwdWJsaWMga2V5IGxheWVyLiBUaGUgb3RoZXIgcHJvdG9jb2wgbGF5 ZXJzIGluIHRoZSBkZXNpZ24sIGluY2x1ZGluZyB0aGUgZm9ybWF0LCBzeW1tZXRyaWMga2V5 IGFuZCBvbi13aXJlIGxheWVycywgYXJlIHN1YnN0YW50aWFsbHkgdW5jaGFuZ2VkLiBUaGUg c2NoZW1lIGFwcGVhcnMgYXMgYW4gYWdyZWVtZW50IGFsZ29yaXRobSBwYXJhc2l0aWMgb24g dGhlIG9uLXdpcmUgbGF5ZXIuIEl0IGRpc2FwcGVhcnMgd2hlbiBpdHMgZnVuY3Rpb24gaXMg YWNjb21wbGlzaGVkLg0KDQoNClRoaXMgZG9jdW1lbnQgZGlzY3Vzc2VzIGVuZ2luZWVyaW5n IGlzc3VlcyBpbXBvcnRhbnQgdG8gdGhlIHNlY3VyaXR5IGRlc2lnbi4gSXQgZG9lcyBub3Qg ZGlzY3VzcyBwYWNrZXQgZm9ybWF0cywgY3VycmVudCBhbmQgcHJvcG9zZWQgTlRQIGV4dGVu c2lvbiBmaWVsZCBmb3JtYXRzLCBvciBzdXBwb3J0aW5nIGtleSBnZW5lcmF0aW9uIG9yIGRp c3RyaWJ1dGlvbi4NCg0KDQpGb3IgdGhlIHB1cnBvc2VzIG9mIHRoaXMgZG9jdW1lbnQsIGEg cHJvdG9jb2wgZGF0YSB1bml0IChQRFUpIGlzIGFuIE5UUCBleHRlbnNpb24gZmllbGQsIHNv bWV0aW1lcyBjYWxsZWQgYSBtZXNzYWdlLiBPbmUgb3IgbW9yZSBtZXNzYWdlcyBjYW4gYmUg YXBwZW5kZWQgdG8gYW4gTlRQIHBhY2tldCBoZWFkZXIuIEVhY2ggbWVzc2FnZSBjb25zaXN0 cyBvZiBhIGZ1bmN0aW9uIG9jdGV0LCBtb2RpZmllciBvY3RldCwgdHdvIG9jdGV0cyBvZiBk YXRhIGxlbmd0aCwgYW5kIHRoZW4gdGhlIGRhdGEgaXRzZWxmLCB6ZXJvIHBhZGRlZCB0byBh IGZvdXItb2N0ZXQgYm91bmRhcnkuICBJdCBpcyBjb252ZW5pZW50IHRvIHJlc3RyaWN0IHRo ZSBtYXhpbXVtIGRhdGEgbGVuZ3RoIHRvIHNvbWUgcmVhc29uYWJsZSB2YWx1ZSBpbiB0aGUg b3JkZXIgb2YgMzIgdG8gNjQgb2N0ZXRzLiBPbmx5IG9uZSBwYWNrZXQgaW4gdGhlIHByb3Rv Y29sIGRlc2NyaWJlZCBoZXJlIGhhcyBtb3JlIHRoYW4gb25lIG1lc3NhZ2UgYW5kIHRoYXQg b25lIGhhcyB0d28gbWVzc2FnZXMuDQoNCg0KT3JkaW5hcmlseSwgdGhlIGZ1bmN0aW9uIG9j dGV0IGZvciBib3RoIHRoZSByZXF1ZXN0IGFuZCByZXNwb25zZSBtZXNzYWdlcyBpcyB0aGUg c2FtZTsgYSBiaXQgaXMgYWxsb2NhdGVkIGluIHRoZSBmdW5jdGlvbiBvY3RldCB0byBzZXJ2 ZSBhcyBhIHJlc3BvbnNlIGluZGljYXRvci4gIEl0IGlzIHNldCB0byB6ZXJvIGZvciBhIHJl cXVlc3QgbWVzc2FnZSBhbmQgb25lIGZvciB0aGUgYXNzb2NpYXRlZCByZXNwb25zZSBtZXNz YWdlLiBNdWx0aXBsZSBtZXNzYWdlcyBjYW4gYmUgc3BsaXQgb3ZlciBtdWx0aXBsZSBOVFAg cGFja2V0cyBhcyBuZWNlc3NhcnksIGR1ZSB0byBwYWNrZXQgbGVuZ3RoIHJlc3RyaWN0aW9u cy4gTXVsdGlwbGUgcmVzcG9uc2VzIGNhbiBiZSBhc3NvY2lhdGVkIHdpdGggYSBzaW5nbGUg cmVxdWVzdC4NCg0KDQpBbiBleGNoYW5nZSBpcyBhIHZvbGxleSBjb25zaXN0aW5nIG9mIGEg c2luZ2xlIHJlcXVlc3QgbWVzc2FnZSB0byBhIGhvc3QgZm9sbG93ZWQgYnkgb25lIG9yIG1v cmUgcmVzcG9uc2UgbWVzc2FnZXMgZnJvbSB0aGF0IGhvc3QuIEluIGdlbmVyYWwsIGVhY2gg ZXhjaGFuZ2UgcGVyZm9ybXMgYSBzaW5nbGUgZnVuY3Rpb24gaW5kZXBlbmRlbnQgb2Ygb3Ro ZXIgZXhjaGFuZ2VzLg0KDQoNCjIuIEJhY2t3YXJkIENvbXBhdGliaWxpdHkNCg0KDQpJdCBp cyBpbXBvcnRhbnQgdGhhdCB0aGUgY3VycmVudCBjcnlwdG9ncmFwaGljIGtleXMgbW9kZWwg YW5kIE5UUCBtb2RlcyAtIGluY2x1ZGluZyBjbGllbnQgc2VydmVyLCBzeW1tZXRyaWMsIGJy b2FkY2FzdC9tdWx0aWNhc3QvbWFueWNhc3QgYW5kIGludGVybGVhdmUgbW9kZXMgLSBiZSBw cmVzZXJ2ZWQuIFRoZSBleGlzdGluZyBzeW1tZXRyaWMga2V5IGRlc2lnbiAtIGluY2x1ZGlu ZyB0aGUga2V5cyB0YWJsZSBmaWxlLCBtZXNzYWdlIGF1dGhlbnRpY2F0aW9uIGNvZGUgKE1B QykgZm9ybWF0IGFuZCBzZWxlY3Rpb24gb2YgaGFzaCBhbGdvcml0aG0gLSBzaG91bGQgYWxz byBiZSByZXRhaW5lZC4gSXQgaXMgbm90IG5lY2Vzc2FyeSB0byBwcmVzZXJ2ZSB0aGUgY3Vy cmVudCBBdXRva2V5IHNjaGVtZSBpdHNlbGYsIGFsdGhvdWdoIHNvbWUgZWxlbWVudHMgb2Yg dGhpcyBzY2hlbWUgcmVtYWluIGluIHRoaXMgcHJvcG9zYWwuDQoNCg0KMy4gSW5mcmFzdHJ1 Y3R1cmUNCg0KDQpUaGUgZnVuZGFtZW50YWwgcHJpbmNpcGxlIGluIHRoZSBOVFAgZW5naW5l ZXJpbmcgZGVzaWduIGlzIHRoYXQgbm8gZXhwbGljaXQgaW5mcmFzdHJ1Y3R1cmUgb3RoZXIg dGhhbiB0aGUgYmFzZSBuZXR3b3JrIGlzIGFzc3VtZWQuIFRoaXMgbWVhbnMgdGhhdCBuZWl0 aGVyIEROUyBub3IgY2VydGlmaWNhdGUgbWFuYWdlbWVudCBpbmZyYXN0cnVjdHVyZSBpcyBh dmFpbGFibGUuIFNpbmNlIGNlcnRpZmljYXRlcyBjYW5ub3QgYmUgYXV0aGVudGljYXRlZCBi eSBvdXRzaWRlIG1lYW5zLCB0aGVyZSBpcyBhIHBvc3NpYmlsaXR5IG9mIGEgbWlkZGxlbWFu IGF0dGFjayB3aGVyZSB0aGUgYXR0YWNrZXIgaW5qZWN0cyBpdHMgY2VydGlmaWNhdGUgb24g dGhlIHRyYWlsIGxlYWRpbmcgdG8gdGhlIGNlcnRpZmljYXRlIGF1dGhvcml0eS4NCg0KDQpJ biB0aGUgb3JpZ2luYWwgQXV0b2tleSBkZXNpZ24gdGhlcmUgd2VyZSBvcHRpb25hbCBtZWFu cyB0byB2ZXJpZnkgdGhlIGNlcnRpZmljYXRlIHRyYWlsIHVzaW5nIHRoZSBpZGVudGl0eSBl eGNoYW5nZS4gVGhpcyBleGNoYW5nZSBpcyBubyBsb25nZXIgbmVlZGVkLCBzaW5jZSBrZXkg emVybywgZGVzY3JpYmVkIGJlbG93IGluIHRoZSAiTGF5ZXJlZCBNb2RlbCIgc2VjdGlvbiwg cGVyZm9ybXMgYSBzaW1pbGFyIGZ1bmN0aW9uLg0KDQoNCjQuIERpdmVyc2l0eQ0KDQoNCklu IHRoZSBjdXJyZW50IE5UUCBhcmNoaXRlY3R1cmUsIHRoZSB0aW1lIGFuZCBzZWN1cml0eSBv cGVyYXRpb25zIHByb2NlZWQgaW5kZXBlbmRlbnRseSBhbmQgc2ltdWx0YW5lb3VzbHkgZm9y IGVhY2ggYXNzb2NpYXRpb24sIGFzIGRlc2NyaWJlZCBiZWxvdy4gU2VjdXJpdHkgZm9yIGFs bCBhc3NvY2lhdGlvbnMgaXMgbWFuYWdlZCBzZXBhcmF0ZWx5LiBBbiBhc3NvY2lhdGlvbiBo YXMgdmFsaWQgdGltZSB3aGVuIHRoZSBkaXNwZXJzaW9uIGhhcyBmYWxsZW4gYmVsb3cgdGhl IHRocmVzaG9sZC4gVGhlIHNlY3VyaXR5IGlzIHZhbGlkIHdoZW4gdGhlIGZpcnN0IHNpZ25h dHVyZSBpcyB2ZXJpZmllZC4gQW4gYXNzb2NpYXRpb24gaXMgdmFsaWQgd2hlbiBib3RoIHRo ZSB0aW1lIGFuZCBzZWN1cml0eSBhcmUgdmFsaWQuDQoNCg0KVGhlIGFzc29jaWF0aW9ucyBh cmUgc2VsZWN0ZWQgYnkgdGhlIEJ5emFudGluZSwgaW50ZXJzZWN0aW9uIGFuZCBjbHVzdGVy aW5nIGFsZ29yaXRobXMuIEl0IGRvZXMgbm90IHNlZW0gZmVhc2libGUgdG8gImxvb3NlbHkg c3luY2hyb25pemUiIHRoZSBzeXN0ZW0gY2xvY2sgd2l0aCB0aGlzIGRlc2lnbiwgc2luY2Ug b25seSBhZnRlciB0aGVzZSBhbGdvcml0aG1zIGhhdmUgY29tcGxldGVkIGlzIHRoZSBzeXN0 ZW0gY2xvY2sgZWxpZ2libGUgdG8gYmUgc3luY2hyb25pemVkLg0KDQoNCjUuIFR3by1XYXkg SXNzdWVzDQoNCg0KSW4gYnJvYWRjYXN0IG1vZGUsIGEgdHdvLXdheSBwYXRoIGJldHdlZW4g dGhlIGJyb2FkY2FzdCBzZXJ2ZXIgYW5kIGNsaWVudCBpcyBuZWNlc3NhcnkgdG8gY29tcHV0 ZSB0aGUgcm91bmQtdHJpcCBkZWxheS4gSG93ZXZlciwgaW4gc29tZSBzdXBwb3J0ZWQgY29u ZmlndXJhdGlvbnMgYSByZXR1cm4gcGF0aCBpcyBub3QgYXZhaWxhYmxlIHNvIHRoZSByb3Vu ZC10cmlwIGRlbGF5IGNhbm5vdCBiZSBjb21wdXRlZCBhbmQgbXVzdCBiZSBlc3RpbWF0ZWQu IEl0IGlzIG5vdCB0aGVuIHBvc3NpYmxlIHRvIHJldHJpZXZlIGFueSBzZXJ2ZXIgZGF0YSBv dGhlciB0aGFuIHRoZSBicm9hZGNhc3QgcGFja2V0IGl0c2VsZi4gVGhlIHJlZmVyZW5jZSBp bXBsZW1lbnRhdGlvbiBzdXBwb3J0cyBib3RoIGEgb25lLXdheSBhbmQgdHdvLXdheSBkZXNp Z24gdXNpbmcgYW4gb3B0aW9uYWwgY2xpZW50IHNlcnZlciBleGNoYW5nZSB0byBjb21wdXRl IHRoZSByb3VuZC10cmlwIGRlbGF5IGZvbGxvd2VkIGJ5IG9uZS13YXkgYnJvYWRjYXN0IHBh Y2tldHMuDQoNCg0KNi4gQWNjZXNzIENvbnRyb2wNCg0KDQpUaGUgY3VycmVudCByZWZlcmVu Y2UgaW1wbGVtZW50YXRpb24gaW5jbHVkZXMgYWNjZXNzIGNvbnRyb2xzIGluIHRoZSBmb3Jt IG9mIGJpdCBwZXJtaXNzaW9ucyBhbmQgcmF0ZSBtYW5hZ2VtZW50IHBhcmFtZXRlcnMuIFRo ZXJlIGlzIG5vIG5lZWQgZm9yIGFkZGl0aW9uYWwgYWNjZXNzIGNvbnRyb2wgZnVuY3Rpb24g aW4gdGhlIGNyeXB0b2dyYXBoaWMgYWxnb3JpdGhtcy4gT3RoZXIgcHVibGljIGtleSBzY2hl bWVzIG1heSB3aXNoIHRvIHVzZSBhbiBhY2Nlc3MgZXhjaGFuZ2UgcHJvdmlkaW5nIGEgc2Vz c2lvbiBrZXkgZm9yIHRoZSBkdXJhdGlvbiBvZiB0aGUgcHJvdG9jb2wsIGFsdGhvdWdoIHRo ZSBvbi13aXJlIHByb3RvY29sIGxheWVyIHByb3ZpZGVzIGEgc2ltaWxhciBmdW5jdGlvbi4N Cg0KDQpSYXRlIG1hbmFnZW1lbnQgaXNzdWVzIGFyZSBhIGNyaXRpY2FsIGNvbnNpZGVyYXRp b24gaW4gdGhlIHNlY3VyaXR5IHByb3RvY29sIGRlc2lnbi4gRm9yIGV4YW1wbGUsIE5JU1Qg c2VydmVycyBwcm9jZXNzZXMgb3ZlciAyNDAsMDAwIE5UUCBwYWNrZXRzIHBlciBzZWNvbmQs IG9uIGF2ZXJhZ2UuICBBcyBvZiBKdW5lIG9mIDIwMTcsIHRoYXTigJlzIG1vcmUgdGhhbiAy MSBiaWxsaW9uIE5UUCByZXF1ZXN0cyBwZXIgZGF5LiBBcyBsZWFybmVkIGZyb20gZXhwZXJp ZW5jZSwgdGhlIHByaW1hcnkgY29uc3VtZXIgb2YgQ1BVIGN5Y2xlcyBpcyB0aGUgcGVyIHBh Y2tldCBvdmVyaGVhZCwgd2l0aCBlYWNoIHBhY2tldCByZXF1aXJpbmcgdGhvdXNhbmRzIG9m IENQVSBpbnN0cnVjdGlvbnMgdG8gcHJvY2Vzcy4gVGhpcyBvdmVyaGVhZCBpcyBzdWJzdGFu dGlhbGx5IGluZGVwZW5kZW50IG9mIHBhY2tldCBsZW5ndGggb3IgbnVtYmVyIG9mIGV4dGVu c2lvbiBmaWVsZHMuDQoNCg0KVGhlIGN1cnJlbnQgcmVmZXJlbmNlIGltcGxlbWVudGF0aW9u IGxpbWl0cyB0aGUgbWluaW11bSBwYWNrZXQgaGVhZHdheSBhbmQgbWluaW11bSBhdmVyYWdl IGhlYWR3YXkgdG8gY29uZmlndXJlZCB2YWx1ZXMuIENsaWVudHMgdGhhdCB2aW9sYXRlIHRo ZXNlIGxpbWl0cyBhcmUgZGVuaWVkIHNlcnZpY2UuIEZvciBleGFtcGxlLCBhdCBOSVNULCBh IHNpZ25pZmljYW50IG1pbm9yaXR5IG9mIGNsaWVudHMgcm91dGluZWx5IHZpb2xhdGUgdGhl IG1pbmltdW0gaGVhZHdheSByZXF1aXJlbWVudCBvZiB0d28gc2Vjb25kcyBhbmQgc28gYXJl IGRpc2NhcmRlZC4gQW4gb3B0aW9uYWwga2lzcyBvJyBkZWF0aCAoS29EKSBpcyBhdmFpbGFi bGUgdG8gcXVlbmNoIGNvbXBsaWFudCBjbGllbnRzLg0KDQoNClRoZSByYXRlIG1hbmFnZW1l bnQgcGFyYW1ldGVycyBhcHBseSBib3RoIHRvIHRoZSBOVFAgcGFja2V0IGZsb3dzLCBhcyB3 ZWxsIGFzIHRoZSBzZWN1cml0eSBmdW5jdGlvbi4gQXMgdGhpcyBmdW5jdGlvbiBvZnRlbiBp bnZvbHZlcyBtdWx0aXBsZSBwYWNrZXRzLCB0aGlzIG1heSByZXN1bHQgaW4gZXhjZXNzaXZl IGFjcXVpc2l0aW9uIHRpbWVzLiBUaGUgbWVhbnMgZGVzY3JpYmVkIGJlbG93IHByb3ZpZGUg YSB3YXkgdG8gbWluaW1pemUgdGhlIG51bWJlciBvZiBwYWNrZXRzIHRvIGNvbXBsZXRlIHRo ZSBwcm90b2NvbC4NCg0KDQo3LiBOVFAgU2VjdXJlIE5ldHdvcmsgRW5naW5lZXJpbmcgUHJp bmNpcGxlcw0KDQoNCkFuIE5UUCBzZWN1cmUgbmV0d29yayBjb25zaXN0cyBvZiBhbiBhY3lj bGljLCB1bmRpcmVjdGVkIGdyYXBoIG9yZ2FuaXplZCBhcyBhIHRyZWUgd2l0aCBub2RlcyBk ZXNjZW5kaW5nIGZyb20gdGhlIHJvb3Qgbm9kZS4gVGhlIG5vZGVzIGNvcnJlc3BvbmQgdG8g dGhlIE5UUCBob3N0cyBhbmQgdGhlIGVkZ2VzIGNvcnJlc3BvbmQgdG8gdGhlIG5ldHdvcmsg cGF0aHMgYmV0d2VlbiB0aGVtLiBUaGUgbmV0d29yayBwYXRocyBpbmNsdWRlIG9uZSBvciBt b3JlIHBoeXNpY2FsIGxpbmtzLCBpbnRlcmNvbm5lY3RlZCBieSByb3V0ZXJzIGFuZCBmaXJl d2FsbHMuIE5vdGUgdGhhdCB0aGUgbmV0d29yayB0b3BvbG9neSBjYW4gY2hhbmdlIGZyb20g dGltZSB0byB0aW1lIGR1ZSB0byBob3N0IG9yIG5ldHdvcmsgcGF0aCBmYWlsdXJlcy4NCg0K DQpGb3IgdGhlIHB1cnBvc2VzIG9mIG5ldHdvcmsgc2VjdXJpdHksIGVhY2ggaG9zdCBjYW4g Y29tbXVuaWNhdGUgZGlyZWN0bHkgb25seSB3aXRoIHRoZSBuZXh0IHVwc3RyZWFtIGhvc3Qg YW5kIG5leHQgZG93bnN0cmVhbSBob3N0LiBBIGhvc3QgY2FuIG9wZXJhdGUgYXMgZWl0aGVy IGEgY2xpZW50IG9yIHNlcnZlciwgb3IgYXMgYm90aCBhdCB0aGUgc2FtZSB0aW1lLg0KDQoN CkVhY2ggaG9zdCBuZWVkcyBhIHNldCBvZiBwdWJsaWMgYW5kIHByaXZhdGUga2V5cywgYW5k IG9uZSBvciBtb3JlIGNlcnRpZmljYXRlcy4gRWFjaCBzaWduZWQgY2VydGlmaWNhdGUgY29u ZmlybXMgYXV0aGVudGljaXR5IG9mIGl0cyBwdWJsaWMga2V5LiAgUHVibGljL3ByaXZhdGUg a2V5cyBhbmQgaG9zdCBjZXJ0aWZpY2F0ZXMgYXJlIGdlbmVyYXRlZCBpbmRpdmlkdWFsbHkg YnkgZWFjaCBob3N0Lg0KDQoNClRoZSBnb2FsIG9mIHRoZSBzZWN1cml0eSBzY2hlbWUgaXMg dG8gYXV0aGVudGljYXRlIGVhY2ggc2VydmVyIHRvIHRoZSBuZXh0IGRvd25zdHJlYW0gY2xp ZW50IHVzaW5nIG9uZSBvciBtb3JlIGNlcnRpZmljYXRlcy4gVGhlIHJlY3Vyc2l2ZSBzY2hl bWUgZXZvbHZlcyBhcyBmb2xsb3dzOiBJbiB0aGUgYmFzaXMgc3RlcCwgdGhlIHJvb3Qgc2Vy dmVyIGhvc3QgaXMgZGVzaWduYXRlZCBhdXRoZW50aWMgYnkgc29tZSBtZWFucyBleHRlcm5h bCB0byB0aGUgbmV0d29yay4gSW4gdGhlIGluZHVjdGl2ZSBzdGVwLCBlYWNoIGNsaWVudCBo b3N0IGluIHRoZSBuZXR3b3JrIHNlcGFyYXRlbHkgcmVxdWVzdHMgaXRzIGltbWVkaWF0ZSBh c2NlbmRpbmcgc2VydmVyIGhvc3QgdG8gc2lnbiBpdHMgY2xpZW50IGhvc3QgY2VydGlmaWNh dGUuIElmIHRoZSBzZXJ2ZXIgaG9zdCBpcyBhdXRoZW50aWMsIHRoZSBjbGllbnQgaG9zdCBp cyBkZXNpZ25hdGVkIGF1dGhlbnRpYy4gSWYgdGhlIHNlcnZlciBob3N0IGlzIG5vdCBhdXRo ZW50aWMsIHRoZSByZXF1ZXN0IGlzIGlnbm9yZWQgYW5kIHRoZSBjbGllbnQgcmVxdWVzdCBp cyByZXBlYXRlZCBhZnRlciB0aW1lb3V0LiBJbiB0aGlzIGZhc2hpb24sIGV2ZW50dWFsbHkg YWxsIGNsaWVudCBjZXJ0aWZpY2F0ZXMgYXJlIHNpZ25lZCBhbmQgZGVzaWduYXRlZCBhdXRo ZW50aWMuIFRodXMsIGF1dGhlbnRpY2l0eSBmbG93cyBpbiBzdGVwcyBmcm9tIHRoZSByb290 IGhvc3QsIGFzIGEgY2VydGlmaWNhdGUgYXV0aG9yaXR5LCB0byBlYWNoIGRvd25zdHJlYW0g aG9zdCBpbiB0aGUgbmV0d29yay4NCg0KDQpPbmNlIGdlbmVyYXRlZCwgY2VydGlmaWNhdGVz IGhhdmUgYSBzcGVjaWZpYyBhc3NpZ25lZCBsaWZldGltZS4gU29tZSB0aW1lIGJlZm9yZSBl eHBpcmF0aW9uIG9mIHRoZSBsaWZldGltZSwgYSBuZXcgY2VydGlmaWNhdGUgbXVzdCBiZSBn ZW5lcmF0ZWQgd2l0aCBhIG5ldyBsaWZldGltZS4gVGhpcyBkb2VzIG5vdCBhZmZlY3QgdGhl IGF1dGhlbnRpY2l0eSBvciBvdGhlciBwYXJhbWV0ZXJzIG9mIHRoZSBjZXJ0aWZpY2F0ZS4g T24gdGhlIG90aGVyIGhhbmQsIGEgbmV3IHNldCBvZiBwdWJsaWMvcHJpdmF0ZSBrZXlzIHJl cXVpcmUgdGhlIGNlcnRpZmljYXRlIHRvIGJlIHJlZ2VuZXJhdGVkIGFuZCBpdHMgcHVibGlj IGtleSB0byBiZSByZXNpZ25lZCBieSB0aGUgc2VydmVyLiBUaGUgc2NoZW1lIHRvIGRvIHRo aXMsIGFzIGRlc2NyaWJlZCBiZWxvdywgaXMgc3RyYWlnaHRmb3J3YXJkIGJ1dCBpbnRyaWNh dGUuDQpBIGhvc3QgaXMgY29uc2lkZXJlZCBwcm92aXNpb25hbGx5IGF1dGhlbnRpYyB3aGVu IHRoZSBzaGFyZWQgaGFzaCBrZXkgc2lnbmF0dXJlcyBoYXZlIGJlZW4gdmVyaWZpZWQuIFRo ZSBob3N0IGlzIGNvbnNpZGVyZWQgZnVsbHkgYXV0aGVudGljIHdoZW4gaXRzIGNlcnRpZmlj YXRlIGhhcyBiZWVuIHNpZ25lZCBieSB0aGUgbmV4dCBhc2NlbmRpbmcgaG9zdCBvbiB0aGUg dHJhaWwgdG8gdGhlIGNlcnRpZmljYXRlIGF1dGhvcml0eSBob3N0Lg0KDQoNClRoZSBjZXJ0 aWZpY2F0ZSB0cmFpbCBpcyB0aHVzIGNvbnN0cnVjdGVkIHN0ZXAgYnkgc3RlcCBhcyBlYWNo IHNpZ25hdHVyZSBpcyBidWlsdCBvciB2ZXJpZmllZC4gRWFjaCBzdGVwIGludm9sdmVzIGEg c2lnbiBleGNoYW5nZSwgYXMgZGVzY3JpYmVkIGxhdGVyLiBBc3N1bWluZyB0aGUgaG9zdCB0 aW1lIGlzIGNvcnJlY3QsIHRoZSB0cmFpbCBuZWVkcyB0byBiZSB2ZXJpZmllZCBvbmx5IG9u Y2UuDQoNCg0KTm90ZSB0aGF0IHRoaXMgbW9kZWwgZG9lcyBub3QgY29uc3RydWN0IHRoZSBj ZXJ0aWZpY2F0ZSB0cmFpbCBpbiBlYWNoIGNsaWVudCBob3N0LiBJbiBmb3JtZXIgZGVzaWdu cywgdGhpcyB3YXMgYWNoaWV2ZWQgdXNpbmcgYSBwZXJzaXN0ZW50IGNhY2hlIHdoaWNoIGhh ZCB0byBiZSB1cGRhdGVkIG9uIGEgcmVndWxhciBiYXNpcy4gSG93ZXZlciwgYm90aCB0aGUg Y3VycmVudCBhbmQgcHJvcG9zZWQgbW9kZWxzIGFyZSB2dWxuZXJhYmxlIHRvIG1pZGRsZW1h biBhdHRhY2suIFRoZSBvcmlnaW5hbCBzb2x1dGlvbiBmb3IgdGhpcyBwcm9ibGVtIHdhcyB0 aGUgU2Nobm9yciAoSUZGKSBpZGVudGl0eSBzY2hlbWUgZGVzY3JpYmVkIGluIFJGQzU5MDYu IFRoZSBzY2hlbWUgcHJvcG9zZWQgaW4gdGhpcyBkb2N1bWVudCByZXBsYWNlcyB0aGUgSUZG IHNjaGVtZSB3aGlsZSBwZXJmb3JtaW5nIHRoZSBzYW1lIGZ1bmN0aW9uLCBhcyBkZXNjcmli ZWQgYmVsb3cuDQoNCg0KOC4gTGF5ZXJlZCBNb2RlbA0KDQoNClRoZSBzZWN1cml0eSBtb2Rl bCBpbiB0aGUgZ2VuZXJpYyByZWZlcmVuY2UgaW1wbGVtZW50YXRpb24gUkZDNTkwNSBjYW4g YmUgc3VtbWFyaXplZCBhcyBhIGZvdXItbGF5ZXIgbW9kZWwsIGRlc2NyaWJlZCBiZWxvdy4g Tm90ZSB0aGF0IHRoZSBwcm90b2NvbCBtZXNzYWdlcyBoaXRjaGhpa2Ugb24gdGhlIE5UUCBw YWNrZXQgaGVhZGVycyBhcyB0cmFuc21pdHRlZC4gTm90ZSBhbHNvIHRoYXQgdGhlIHBhY2tl dCBwb2xsIGludGVydmFsIGR1cmluZyB0aGUgc2VjdXJpdHkgZGFuY2UgY2FuIGJlIHJlZHVj ZWQgY29uc2lzdGVudCB3aXRoIHRoZSByYXRlIGxpbWl0cy4NCg0KDQo4LjEgRm9ybWF0IExh eWVyDQoNCg0KV2hlbiBhbiBOVFAgcGFja2V0IGFycml2ZXMsIHRoZSBmaXJzdCBsYXllciB2 ZXJpZmllcyB0aGUgcGFja2V0IGZvcm1hdC4gSW4gcGFydGljdWxhciwgdGhlIHBhY2tldCBo ZWFkZXIgYW5kIGV4dGVuc2lvbiBmaWVsZCBsZW5ndGhzLCBpZiBwcmVzZW50LiBFeHRlbnNp b24gZmllbGRzIGFyZSBub3QgcHJvY2Vzc2VkIGF0IHRoaXMgdGltZS4gVGhlIGZvcm1hdCBz Y2FuIHJlc3VsdHMgaW4gYSBwb2ludGVyIGp1c3QgYmVmb3JlIHRoZSBtZXNzYWdlIGF1dGhl bnRpY2F0aW9uIGNvZGUgKE1BQykuIFRoaXMgZGVzaWduYXRlcyB0aGUgdXBwZXIgbGltaXQg b2YgdGhlIGhhc2ggY29tcHV0YXRpb24uIEluIGNhc2Ugb2YgZm9ybWF0IGVycm9yLCB0aGUg cGFja2V0IGlzIGRpc2NhcmRlZCB3aXRoIG5vIGZ1cnRoZXIgYWN0aW9uLg0KDQoNCjguMiBT eW1tZXRyaWMgS2V5IExheWVyDQoNCg0KVGhlIHNlY29uZCBsYXllciB2ZXJpZmllcyBwYWNr ZXQgZGF0YSBjb250ZW50LiBJbiB0aGUgTlRQIGdlbmVyaWMgc2VjdXJpdHkgbW9kZWwsIE5U UCBwYWNrZXRzIGFyZSBjb25zaWRlcmVkIHB1YmxpYyB2YWx1ZXMgc28gdGhleSBhcmUgbm90 IGVuY3J5cHRlZC4gSG93ZXZlciwgaSx0IGlzIHZpdGFsIHRoYXQgdGhlIHBhY2tldCBiZSB1 bmRhbWFnZWQgaW4gdHJhbnNpdCBhbmQgdGhlIHBhY2tldCBvcmRlciBiZSBwcmVzZXJ2ZWQu IFRob3VnaCB0aGUgcHJvdG9jb2wgaXMgcXVpdGUgcmVzaXN0YW50IHRvIHBhY2tldCBsb3Nz LCByZXRyYW5zbWlzc2lvbnMgaGF2ZSBsaXR0bGUgdXNlLg0KDQoNCkludGVncml0eSBpcyBw cm90ZWN0ZWQgYnkgYSBtZXNzYWdlIGF1dGhlbnRpY2F0aW9uIGNvZGUgTUFDLCB3aGljaCBp cyB1c2VkIGZvciBhbGwgcGFja2V0cy4gVGhlIE1BQyBpcyBvcmRpbmFyaWx5IGNvbnN0cnVj dGVkIGFuZCB2ZXJpZmllZCB1c2luZyBhIGhhc2gga2V5IHNoYXJlZCBieSB0aGUgY2xpZW50 IGFuZCBzZXJ2ZXIuIFRoZSBoYXNoIGtleSBpcyBhc3N1bWVkIHByaXZhdGUgYW5kIHVucHJl ZGljdGFibGUgZm9yIGVhY2ggYXNzb2NpYXRpb24uDQoNCg0KSWYgYSBzaGFyZWQgaGFzaCBr ZXkgaXMgbm90IGF2YWlsYWJsZSwgc3VjaCBhcyBkdXJpbmcgdGhlIGFncmVlbWVudCBwcm9j ZXNzIGl0c2VsZiwgdGhlIGV4aXN0ZW5jZSBvZiBhbiBpbXBsaWNpdCBoYXNoIGtleSB6ZXJv IGlzIGFzc3VtZWQuIFRoZSB2YWx1ZSBvZiBoYXNoIGtleSB6ZXJvIGNvdWxkIGJlIGEgcmFu ZG9tIG51bWJlciBrbm93biBvbmx5IHRvIHZlcmlmaWVkIGFuZCB0cnVzdGVkIGhvc3RzIGlu IHRoZSBOVFAgbmV0d29yay4gSGFzaCBrZXkgemVybyBjb3VsZCBiZSBhbnkgbXV0dWFsbHkg YWdyZWVkIHVwb24gc3ltbWV0cmljIGtleS4gIFRoZSBkZXNpZ24gaW50ZW50IGlzIHRvIHZl cmlmeSB0aGlzIG51bWJlciBhcyB3ZWxsIGFzIGRldGVjdCBlcnJvcnMsIHJhdGhlciB0aGFu IHByb3RlY3QgYWdhaW5zdCBtaWRkbGVtYW4gYXR0YWNrLiBCeSBwcm90b2NvbCBydWxlLCBp ZiBhIG1lc3NhZ2UgcmVxdWVzdCB1c2VzIGhhc2gga2V5IHplcm8sIHRoZSBtZXNzYWdlIHJl c3BvbnNlIGFsc28gdXNlcyBoYXNoIGtleSB6ZXJvLg0KDQoNCkJ5IHNwZWNpZmljYXRpb24s IGEgc2VjdXJlIHNlcnZlciBjYW4gd29yayB3aXRoIG9yIHdpdGhvdXQgYSBNQUMuIFdpdGhv dXQgYSBNQUMsIGEgcGFja2V0IGlzIHVuY29uZGl0aW9uYWxseSBhY2NlcHRlZDsgd2l0aCBh IE1BQyAsIGEgcGFja2V0IGlzIGFjY2VwdGVkIG9ubHkgaWYgdmVyaWZpZWQgYnkgc2VjdXJl IG1lYW5zLiBBIGNvbmZpZ3VyYXRpb24gYml0IGNhbiBiZSB1c2VkIHRvIGRpc2NhcmQgcGFj a2V0cyB3aXRob3V0IGEgTUFDLg0KDQoNCkluIGNhc2Ugb2YgaGFzaCBmYWlsdXJlLCB0aGUg cGFja2V0IGlzIGRpc2NhcmRlZCBhbmQgYSBjcnlwdG8tTkFLIG1lc3NhZ2UgaXMgcmV0dXJu ZWQgdG8gdGhlIHNlbmRlci4gVGhlIGNyeXB0by1OQUsgY29uc2lzdHMgb2YgYSBmb3VyIG9j dGV0IGV4dGVuc2lvbiBmaWVsZCBjb250YWluaW5nIGFuIG9wdGlvbmFsIGVycm9yIGNvZGUu IEEgY3J5cHRvLU5BSyBwYWNrZXQgaXMgYWx3YXlzIHNlbnQgd2l0aCBrZXkgemVyby4gVGhl IGNyeXB0by1OQUsgb3JkaW5hcmlseSByZXN1bHRzIGluIGEgcmVuZWdvdGlhdGlvbiBvZiB0 aGUgc2hhcmVkIGhhc2gga2V5LCBhcyBkZXNjcmliZWQgYmVsb3cuIEluIGNhc2Ugb2YgYnJv YWRjYXN0IG1vZGUsIGEgZGlmZmVyZW50IHN0cmF0ZWd5IGlzIHVzZWQsIGFzIGRlc2NyaWJl ZCBiZWxvdy4NCg0KDQpJZiB0aGUgaGFzaCBzaXplIGlzIHRvbyBsYXJnZSwgaXQgY2FuIGNv bXByb21pc2UgdGltaW5nIGFjY3VyYWN5OyBpZiB0b28gc21hbGwsIGl0IGNhbiBjb21wcm9t aXNlIHNlY3VyaXR5LiBBIG5hdHVyYWwgY2hvaWNlIGlzIDE2MCBiaXRzIG9yIDIwIG9jdGV0 cywgYXMgaW4gdGhlIGN1cnJlbnQgcmVmZXJlbmNlIGltcGxlbWVudGF0aW9uLiBBbiBhdHRy YWN0aXZlIHN0cmF0ZWd5IGlzIHRoZSB1c2Ugb2YgZWxsaXB0aWMtY3VydmUgdmVyc2lvbnMg b2YgdGhlIGFncmVlbWVudCBhbmQgc2lnbmF0dXJlIGFsZ29yaXRobXMuIFVzaW5nIHRoZXNl IGFsZ29yaXRobXMsIGEgMTYwLWJpdCBoYXNoIHNpemUgaXMgZXF1aXZhbGVudCB0byBhIDEw MjQtYml0IGhhc2ggc2l6ZSB1c2luZyB0aGUgdHJhZGl0aW9uYWwgYWxnb3JpdGhtcy4NCg0K DQpJbiB0aGUgaGlzdG9yaWMgcmVmZXJlbmNlIGltcGxlbWVudGF0aW9uLCBhIE1BQyBpcyBp bmRpY2F0ZWQgYXMgdGhlIGxhc3QgYmxvY2sgYWZ0ZXIgYWxsIGV4dGVuc2lvbiBmaWVsZHMg aW4gdGhlIHBhY2tldC4gVGhlIGJsb2NrIGxlbmd0aCBpcyB0cmFkaXRpb25hbGx5IG5vIGdy ZWF0ZXIgdGhhbiAyNCBvY3RldHMgLSBmb3VyIG9jdGV0cyBmb3IgdGhlIGtleSBJRCBwbHVz IDIwIG9jdGV0cyBmb3IgdGhlIGhhc2guIEZvciBzeW1tZXRyaWMga2V5cywgdGhlIGhpZ2gt b3JkZXIgdHdvIG9jdGV0cyBvZiB0aGUga2V5IElEIGFyZSB6ZXJvIGFuZCB0aGUgbG93LW9y ZGVyIHR3byBvY3RldHMgYXJlIHRoZSBlbnRyeSBudW1iZXIgaW4gdGhlIGtleXMgZmlsZS4g VGhpcyBmb3JtYXQgaXMgbmVjZXNzYXJ5IG9ubHkgZm9yIGJhY2t3YXJkIGNvbXBhdGliaWxp dHkgd2l0aCB0aGUgc3ltbWV0cmljIGtleSBmaWxlLg0KDQoNCkl0IGlzIG5vdCBnZW5lcmFs bHkgdXNlZnVsIHRvIHByb3ZpZGUgbGFyZ2VyIGhhc2ggc2l6ZXMuIEZvciBleGFtcGxlLCB0 aGUgU0hBMTYwIGhhc2ggYWxnb3JpdGhtIGlzIGEgMjAtb2N0ZXQgdHJ1bmNhdGVkIHZlcnNp b24gb2YgU0hBMjU2LiBPdGhlciBoYXNoIGFsZ29yaXRobXMgY2FuIGJlIHRydW5jYXRlZCBh cyB3ZWxsLg0KDQoNCkluIHRoZSByZWZlcmVuY2UgaW1wbGVtZW50YXRpb24sIHRoZSBoYXNo IGFsZ29yaXRobSBjYW4gYmUgc3BlY2lmaWVkIGZvciBlYWNoIGtleSBudW1iZXIgaW4gdGhl IGtleXMgZmlsZS4gSW4gcHJpbmNpcGxlLCBrZXkgemVybyBjYW4gYmUgYXNzaWduZWQgaW4g dGhlIGtleXMgZmlsZSBhcyB3ZWxsLCBwcm92aWRpbmcgYW4gaW5kZXBlbmRlbnQgY2hvaWNl IG9mIGhhc2ggYWxnb3JpdGhtLg0KDQoNClRoZSBPcGVuU1NMIGxpYnJhcnkgaW5jbHVkZXMg anVzdCBhYm91dCBldmVyeSBoYXNoIGFsZ29yaXRobSBsaWtlbHkgdG8gYmUgaW1hZ2luZWQu IFdoaWxlIGhpc3RvcmljYWxseSBhbWJpZ3VvdXMsIHRoZSBJbnRlcm5hdGlvbmFsIFRyYWRl IGluIEFybXMgUmVndWxhdGlvbnMgKElUQVIpIHByb2hpYml0cyBleHBvcnQgb2YgdGhlIE9w ZW5TU0wgbGlicmFyeSwgc28gb25seSB0aGUgTUQ1IGhhc2ggYWxnb3JpdGhtIGlzIGluY2x1 ZGVkIGluIHRoZSByZWZlcmVuY2UgZGlzdHJpYnV0aW9uLiBBbHRlcm5hdGl2ZWx5LCB0aGUg T3BlblNTTCBsaWJyYXJ5IGNhbiBiZSBpbXBvcnRlZCBmcm9tIGZvcmVpZ24gb3IgZG9tZXN0 aWMgc291cmNlcywgYWx0aG91Z2ggZ2VuZXJhdGVkIGJpbmFyaWVzIG1heSBub3QgYmUgZXhw b3J0ZWQgZnJvbSB0aGUgVVMuLg0KDQoNCkFsdGVybmF0ZWx5IG9yIGluIGFkZGl0aW9uLCBh IGhhc2ggb2YgYXJiaXRyYXJ5IHNpemUgY2FuIGJlIGltcGxlbWVudGVkIHVzaW5nIGFuIGV4 dGVuc2lvbiBmaWVsZC4gSW4gdGhpcyBjYXNlLCB0aGUgbGVuZ3RoIG9jdGV0cyBpbiB0aGUg a2V5IElEIHdpbGwgYmUgbm9uemVybyBhbmQgdGhlIG1vZGlmaWVyIG9jdGV0IHVzZWQgYXMg dGhlIGtleSBudW1iZXIuIFRoZSBoYXNoIGlzIGNvbXB1dGVkIGZyb20gdGhlIGJlZ2lubmlu ZyBvZiB0aGUgcGFja2V0IHRvIHRoZSBiZWdpbm5pbmcgb2YgdGhlIE1BQy4gT3JkaW5hcmls eSwgdGhlIE1BQyBpcyB0aGUgbGFzdCBleHRlbnNpb24gZmllbGQgaW4gdGhlIHBhY2tldCwg YnV0IGFkZGl0aW9uYWwgZXh0ZW5zaW9uIGZpZWxkcyBiZXlvbmQgdGhlIE1BQyBhcmUgcG9z c2libGUsIHRob3VnaCBub3QgaW5jbHVkZWQgaW4gdGhlIGhhc2ggY29tcHV0YXRpb24uDQog DQo4LjMgT24td2lyZSBQcm90b2NvbCBMYXllcg0KDQoNClRoZSBwdXJwb3NlIG9mIHRoZSB0 aGlyZCBsYXllciBpcyB0byB2ZXJpZnkgcHJvdG9jb2wgb3BlcmF0aW9ucyBjb25zaXN0ZW50 IHdpdGggdGhlIG9uLXdpcmUgcHJvdG9jb2wuIFRoZSBwcm90b2NvbCBkaXNjYXJkcyBib2d1 cyBhbmQgZHVwbGljYXRlIHBhY2tldHMgYXMgd2VsbCBhcyBtaW5pbWl6ZXMgZGlzcnVwdGlv bnMgZHVlIHRvIHByb3RvY29sIHJlc3RhcnRzIGFuZCBkcm9wcGVkIHBhY2tldHMuIFRoZSBv cGVyYXRpb25zIGFyZSBjb250cm9sbGVkIGJ5IHR3byB0aW1lc3RhbXBzOiB0aGUgdHJhbnNt aXQgdGltZXN0YW1wIHNhdmVkIGluIHRoZSBjbGllbnQgc3RhdGUgdmFyaWFibGVzIGFuZCB0 aGUgb3JpZ2luIHRpbWVzdGFtcCBpbiB0aGUgc2VydmVyIHBhY2tldCBoZWFkZXIuIFRoZSBj b21wYXJpc29uIG9mIHRoZXNlIHR3byB0aW1lc3RhbXBzIGlzIGNhbGxlZCB0aGUgbG9vcGJh Y2sgdGVzdC4gVGhlIHRyYW5zbWl0IHRpbWVzdGFtcCBmdW5jdGlvbnMgYXMgYSBub25jZSB0 byB2ZXJpZnkgdGhhdCB0aGUgcmVzcG9uc2UgY29ycmVzcG9uZHMgdG8gdGhlIG9yaWdpbmFs IHJlcXVlc3QuIFRoZSB0cmFuc21pdCB0aW1lc3RhbXAgYWxzbyBzZXJ2ZXMgdG8gZGlzY2Fy ZCByZXBsYXlzIG9mIHRoZSBtb3N0IHJlY2VudCByZXNwb25zZS4NCg0KDQpVcG9uIGZhaWx1 cmUgb2YgZWl0aGVyIHRlc3QsIHRoZSBwYWNrZXQgaXMgZGlzY2FyZGVkIHdpdGggbm8gZnVy dGhlciBhY3Rpb24uIEluIG9yZGVyIHRvIHJlZHVjZSByb3VuZG9mZiBlcnJvcnMgYW5kIGlt cHJvdmUgc2VjdXJpdHksIHRoZSBsb3cgb3JkZXIgbm9uc2lnbmlmaWNhbnQgYml0cyBvZiB0 aGUgdGltZXN0YW1wIGFyZSByZXBsYWNlZCBieSBhIHJhbmRvbSBiaXQgc3RyaW5nLiBUaGUg dHJhbnNtaXQgdGltZXN0YW1wIG1pZ2h0IG5vdCBiZSBjb25zaWRlcmVkIHN1ZmZpY2llbnRs eSByYW5kb20gYXMgYSBub25jZS4gSG93ZXZlciwgdGhlIHRpbWVzdGFtcHMgYXJlIGFsd2F5 cyBpbmNyZWFzaW5nLCBldmVuIGlmIGJ5IGEgc21hbGwgYW1vdW50LCBhbmQgdGhlIHRpbWVz dGFtcHMgYXJlIG5ldmVyIHByZWRpY3RhYmxlLiBUaGVyZWZvcmUsIGluIHRoaXMgcHJvcG9z YWwsIHRyYW5zbWl0IHRpbWVzdGFtcHMgYXJlIGNvbnNpZGVyZWQgdmFsaWQgbm9uY2VzLg0K DQoNCkFuIGltcG9ydGFudCBmdW5jdGlvbiBvZiB0aGUgb24td2lyZSBsYXllciBpcyBjb2xs ZWN0aW9uIG9mIHBhY2tldCB0aW1lc3RhbXBzLCBib3RoIGlucHV0IGFuZCBvdXRwdXQuIFRo ZXJlIGFyZSB0aHJlZSBraW5kcyBvZiB0aW1lc3RhbXBzLCBpbiBvcmRlciBvZiBpbmNyZWFz aW5nIGFjY3VyYWN5OiBzb2Z0c3RhbXBzLCBkcml2ZXN0YW1wcyBhbmQgaGFyZHN0YW1wcy4g VGhlc2UgYXJlIGRldGVybWluZWQgYnkgcmVhZGluZyB0aGUgc3lzdGVtIGNsb2NrIGF0IHNw ZWNpZmllZCBwcm90b2NvbCBldmVudHMuIFNvZnRzdGFtcHMgYXJlIGRldGVybWluZWQgd2hl biBhIHBhY2tldCBpcyByZW1vdmVkIGZyb20gdGhlIGlucHV0IHF1ZXVlIGFuZCB3aGVuIGEg cGFja2V0IGlzIGFkZGVkIHRvIHRoZSBvdXRwdXQgcXVldWUuIERyaXZlc3RhbXBzIGFyZSBk ZXRlcm1pbmVkIGF0IHRoZSB0aW1lIG9mIHRoZSBkZXZpY2UgaW50ZXJydXB0IGF0IHRoZSBl bmQgb2YgdGhlIHBhY2tldC4gVGhleSBhcmUgdXNlZCBieSB0aGUgcmVmZXJlbmNlIGltcGxl bWVudGF0aW9uIGFuZCBpbiBwYXJ0aWN1bGFyIHRoZSBpbnRlcmxlYXZlIHByb3RvY29sLiBI YXJkc3RhbXBzIGFyZSBpbnN0YW50aWF0ZWQgYXQgc3BlY2lmaWMgZXZlbnRzIGRldGVybWlu ZWQgYnkgc3BlY2lhbGl6ZWQgaW50ZXJmYWNlIGhhcmR3YXJlLiBUaGV5IGFyZSBub3QgdXNl ZCBpbiB0aGUgY3VycmVudCByZWZlcmVuY2UgaW1wbGVtZW50YXRpb24uDQoNCg0KRHJpdmVz dGFtcHMgYXJlIHRoZSBtYWluIGRldGVybWluYW50IG9mIHRpbWVrZWVwaW5nIGFjY3VyYWN5 LiBUaGV5IG11c3QgYmUgY29sbGVjdGVkIGF0IHRoZSBkZXZpY2UgbGF5ZXIgYW5kIHBhc3Nl ZCB1cHdhcmQgaW4gdGhlIGlucHV0IHBhY2tldCBidWZmZXIgb3IgYXQgdGhlIGVuZCBvZiB0 aGUgb3V0cHV0IG9wZXJhdGlvbi4gVGhpcyBjYW4gY29tcGxpY2F0ZSB0aGUgc2VjdXJpdHkg cHJvdG9jb2wsIGVzcGVjaWFsbHkgaWYgdXNpbmcgYSBwcmVwYWNrYWdlZCBpbXBsZW1lbnRh dGlvbi4NCg0KDQo4LjQgUHVibGljIEtleSBMYXllcg0KDQoNClRoZSBmb3VydGggbGF5ZXIg Y29uc3RydWN0cyBhbmQgYXV0aGVudGljYXRlcyB0aGUgc2hhcmVkIGhhc2gga2V5IGFuZCBj ZXJ0aWZpY2F0ZSB0cmFpbCB0byB0aGUgY2VydGlmaWNhdGUgYXV0aG9yaXR5IGhvc3QuIFRo ZSBiYXNpYyBwcm90b2NvbCBkYW5jZSBiZWdpbnMgd2l0aCBhIHBhcmFtZXRlciBleGNoYW5n ZSBmb2xsb3dlZCBieSBhIGNvb2tpZSBleGNoYW5nZSBhbmQgc2lnbiBleGNoYW5nZSwgYXMg cmVxdWlyZWQuIFRoZXNlIGV4Y2hhbmdlcyBwZXJmb3JtIGEgZnVuY3Rpb24gc2ltaWxhciB0 byB0aGUgVExTIGFuZCBEVExTIGhhbmRzaGFrZS4NCg0KDQpJdCBpcyBpbXBvcnRhbnQgdG8g bWluaW1pemUgdGhlIG51bWJlciBvZiBleGNoYW5nZXMgaW4gb3JkZXIgdG8gbWluaW1pemUg dGhlIGxhdGVuY3kgdG8gYWNxdWlyZSB0aGUgdGltZSBhbmQgYXV0aGVudGljYXRlIHRoZSBz ZXJ2ZXIuIE9yZGluYXJpbHksIHRoZSB0aW1lIGlzIGFjcXVpcmVkIHdpdGhpbiBzaXggTlRQ IHJvdW5kcyBhdCB0aGUgcmF0ZSBvZiBvbmUgcm91bmQgZXZlcnkgdHdvIHNlY29uZHMuIFRo ZSBhdXRoZW50aWNhdGlvbiBkYW5jZSBpcyBwaWdneWJhY2tlZCBvbiB0aGVzZSByb3VuZHMu IFdpdGggdGhlIHByb3RvY29sIG91dGxpbmVkIGluIHRoaXMgcHJvcG9zYWwsIGF1dGhlbnRp Y2l0eSBjYW4gYmUgY29uZmlybWVkIHdpdGhpbiBmb3VyIHJvdW5kcy4NCg0KDQpUaGUgcGFy YW1ldGVyIGV4Y2hhbmdlIGluY2x1ZGVzIHRoZSBzdWJqZWN0IG5hbWUgb24gdGhlIGhvc3Qg Y2VydGlmaWNhdGUsIGFzIHdlbGwgYXMgdGhlIHNlbGVjdGVkIGFsZ29yaXRobSBhbmQgb3Ro ZXIgcGFyYW1ldGVycy4gVGhlIGNvb2tpZSBleGNoYW5nZSBkZXZlbG9wcyBhbmQgdmVyaWZp ZXMgdGhlIHNoYXJlZCBoYXNoIGtleSBhbmQgc2lnbmF0dXJlLiBUaGUgcGFyYW1ldGVyIGFu ZCBjb29raWUgZXhjaGFuZ2VzIGFyZSBzZW50IHdpdGggYSBzaGFyZWQgaGFzaCBrZXkgemVy by4gVGhlIHNpZ24gZXhjaGFuZ2UgY29uc3RydWN0cyBvciB2ZXJpZmllcyB0aGUgcHVibGlj IGtleSBzaWduYXR1cmUgb24gdGhlIGhvc3QgY2VydGlmaWNhdGUuIFRoZSBhZ3JlZWQgaGFz aCBrZXkgZGV2ZWxvcGVkIGR1cmluZyB0aGUgY29va2llIGV4Y2hhbmdlIGlzIHVzZWQgZm9y IHRoZSBzaWduIGV4Y2hhbmdlIGFuZCBzdWJzZXF1ZW50IE5UUCBwYWNrZXRzLg0KDQoNClRo ZSBjZXJ0aWZpY2F0ZSBhdXRob3JpdHkgaG9zdCBpcyBkZXNpZ25hdGVkIGVpdGhlciBhcyBh IHNlbGYtc2lnbmVkIGNlcnRpZmljYXRlIG9yIGJ5IGFuIGlkZW50aWZpZXIgaW4gdGhlIHg1 MDl2MyBleHRlbnNpb24gZmllbGQuIEhvc3QgY2VydGlmaWNhdGVzIGFyZSBleGNoYW5nZWQg dXNpbmcgdGhlIGNlcnRpZmljYXRlIGV4Y2hhbmdlLCB3aXRoIG5ldyBjZXJ0aWZpY2F0ZXMg cmVwbGFjaW5nIG9sZCBvbmVzIHdpdGggdGhlIHNhbWUgc3ViamVjdCBhbmQgaXNzdWVyIG5h bWVzLg0KDQoNCkJ5IGRlZmF1bHQsIHRoZSBzdWJqZWN0IG5hbWUgb24gdGhlIGNlcnRpZmlj YXRlIGlzIHRoZSBzdHJpbmcgcmV0dXJuZWQgYnkgdGhlIFVuaXggZ2V0aG9zdGJ5bmFtZSBs aWJyYXJ5IHJvdXRpbmUuIFRoZSBzdWJqZWN0IG5hbWUgb24gdGhlIGNlcnRpZmljYXRlIGF1 dGhvcml0eSBpcyBpbnRlcnByZXRlZCBhcyB0aGUgZ3JvdXAgbmFtZSBhc3NvY2lhdGVkIHdp dGggdGhlIHBhcnRpY3VsYXIgdHJhaWwgYW5kIGlzIHVzZWZ1bCBpbiB0aGUgaWRlbnRpdHkg ZXhjaGFuZ2Ugb3IgZXF1aXZhbGVudCBzY2hlbWUuDQoNCg0KVGhlIGNlcnRpZmljYXRlIHRy YWlsIGlzIGNvbnN0cnVjdGVkIHN0ZXAgYnkgc3RlcCBmb3IgZWFjaCBhc3NvY2lhdGlvbiwg d2l0aCB0aGUgaXNzdWVyIG5hbWUgcmVwbGFjaW5nIHRoZSBzdWJqZWN0IG5hbWUgYXQgZWFj aCBzdGVwLiBOb3RlIHRoYXQgZWFjaCBzdGVwIGludm9sdmVzIGEgc2luZ2xlIHNpZ25hdHVy ZSwgc28gZG9lcyBub3QgY29uc3RydWN0IHRoZSBlbnRpcmUgdHJhaWwuDQoNCg0KT25jZSB0 aGUgY2VydGlmaWNhdGUgdHJhaWwgaGFzIGJlZW4gdmVyaWZpZWQsIGl0IGlzIG5vdCBuZWNl c3NhcnkgdG8gZG8gaXQgYWdhaW4sIHVubGVzcyBhIGNlcnRpZmljYXRlIGlzIHJldm9rZWQg b3IgcmVhY2hlcyBhZHZhbmNlZCBhZ2UuIE5vdGUgdGhhdCBlYWNoIGFzc29jaWF0aW9uIG1p Z2h0IGhhdmUgZGlmZmVyZW50IGlzc3VlciBhbmQgc3ViamVjdCBuYW1lcy4NCg0KDQpBcyBw YXJ0IG9mIHRoZSBpbml0aWFsaXphdGlvbiBwcm9jZXNzLCBhIHNlbGYtc2lnbmVkIGhvc3Qg Y2VydGlmaWNhdGUgaXMgZ2VuZXJhdGVkIGZvciB1c2UgYnkgZWFjaCBhc3NvY2lhdGlvbi4g SWYgdGhlIGhvc3QgY2VydGlmaWNhdGUgaGFzIG5vdCBiZWVuIHNpZ25lZCBieSB0aGUgc2Vy dmVyIGZvciBlYWNoIGFzc29jaWF0aW9uLCB0aGUgaG9zdCBjZXJ0aWZpY2F0ZSBpcyBwcm92 aWRlZCB0byBlYWNoIGFzc29jaWF0aW9uIHNlcnZlciBmb3Igc2lnbmF0dXJlLiBUaGlzIGlz IGNhbGxlZCB0aGUgc2lnbiBleGNoYW5nZSBhbmQgbmVlZHMgdG8gYmUgZG9uZSBvbmx5IG9u Y2UgZm9yIGVhY2ggYXNzb2NpYXRpb24uIE5vdGUgdGhhdCB0aGUgbmV4dCBkb3duc3RyZWFt IGhvc3QgaGFzIHRoZSBjaG9pY2Ugb2Ygc2lnbmVkIGNlcnRpZmljYXRlcywgYnV0IHRoZXkg YXJlIGFsbCBlcXVpdmFsZW50Lg0KDQoNCk9uY2UgdGhlIGNlcnRpZmljYXRlIHRyYWlsIHNp Z25hdHVyZXMgaGF2ZSBiZWVuIHZlcmlmaWVkLCB0aGUgaG9zdCBjZXJ0aWZpY2F0ZSBpcyBj b25zaWRlcmVkIGF1dGhlbnRpYywgdW5sZXNzIGEgY2VydGlmaWNhdGUgaGFzIGJlZW4gY2hh bmdlZC4gVGhlIHJlY292ZXJ5IHNjaGVtZSB0byB1cGRhdGUgdGhlIGNlcnRpZmljYXRlIHRy YWlsIGNvdWxkIGJlIHRlZGlvdXMsIGFzIGRlc2NyaWJlZCBiZWxvdy4gTm90ZSB0aGF0IHRo ZXJlIGFyZSBubyBwcm92aXNpb25zIGluIHRoZSBzZWN1cml0eSBzY2hlbWUgdG8gcmV2b2tl IGEgY2VydGlmaWNhdGUsIHNvIHRoaXMgbXVzdCBiZSBkb25lIGJ5IGV4dGVybmFsIG1lYW5z Lg0KDQoNCkluIHRoZSBmb2xsb3dpbmcsIHRoZSBob3N0IGNlcnRpZmljYXRlIGJlbG9uZ3Mg dG8gdGhlIGhvc3QgY29udGFpbmluZyB0aGUgcHVibGljL3ByaXZhdGUga2V5cywgd2hpbGUg YSBzZXJ2ZXIgY2VydGlmaWNhdGUgYmVsb25ncyB0byBlYWNoIGFzc29jaWF0aW9uIHNlcGFy YXRlbHkuIE9uY2UgdGhlIGNvb2tpZSBleGNoYW5nZSBoYXMgY29tcGxldGVkLCB0aGUgc2hh cmVkIGhhc2gga2V5IGNhbiBiZSB1c2VkIGZvciBhdXRoZW50aWNhdGlvbiBvZiBhbGwgc3Vi c2VxdWVudCBwYWNrZXRzLg0KDQoNCkZvciB0aGlzIHB1cnBvc2UsIHRoZSBjb29raWUgZXhj aGFuZ2UgaXMgc3BsaXQgaW50byB0d28gcGhhc2VzOiB0aGUgYWdyZWVtZW50IHBoYXNlLCB3 aGljaCBkZXZlbG9wcyB0aGUgc2hhcmVkIGhhc2gga2V5LCBhbmQgdGhlIGF1dGhlbnRpY2F0 aW9uIHBoYXNlLCB3aGljaCBhdXRoZW50aWNhdGVzIHRoZSBoYXNoIGtleS4gVGhlIGNlcnRp ZmljYXRlIGV4Y2hhbmdlIG9idGFpbnMgdGhlIHNlcnZlciBjZXJ0aWZpY2F0ZSBhZnRlciB0 aGUgYWdyZWVtZW50IHBoYXNlIGFuZCBiZWZvcmUgdGhlIGF1dGhlbnRpY2F0aW9uIHBoYXNl LiAgIE9yZGluYXJpbHksIHRoZSBjZXJ0aWZpY2F0ZSBleGNoYW5nZSBuZWVkcyB0byBiZSBk b25lDQpvbmx5IG9uY2UsIHVubGVzcyB0aGUgY2VydGlmaWNhdGUgaXMgY2hhbmdlZC4gIEVh Y2ggcGhhc2UgaXMgcmVwcmVzZW50ZWQgYnkgYW4gZXhjaGFuZ2Ugb2YgdGhlIHNhbWUgbmFt ZS4NCg0KDQpJbiBzeW1tZXRyaWMgbW9kZSB0aGUgYWdyZWVtZW50IHBoYXNlIHVzZXMgdGhl IGNsYXNzaWMgRGlmZmllLUhlbGxtYW4gYWxnb3JpdGhtLiBJbiBjbGllbnQvc2VydmVyIG1v ZGUgdGhlIGtleSBpcyBhIGNvb2tpZSwgYXMgZGVzY3JpYmVkIGJlbG93LiBJbiB0aGlzIHBo YXNlIGFuZCB0aGUgcGFyYW1ldGVyIGV4Y2hhbmdlLCB0aGUgZXhjaGFuZ2UgdXNlcyBrZXkg emVybywgYXMgZGVzY3JpYmVkIGFib3ZlLiBUaGUgYXV0aGVudGljYXRpb24gcGhhc2UgY29u c2lzdHMgb2YgYW4gZXhjaGFuZ2Ugb2YgaGFzaCBrZXkgc2lnbmF0dXJlcy4NCg0KDQpUaGUg YXNzb2NpYXRpb24gaXMgY29uc2lkZXJlZCBwcm92aXNpb25hbGx5IGF1dGhlbnRpYyBmb2xs b3dpbmcgdGhlIGF1dGhlbnRpY2F0aW9uIHBoYXNlIG9mIHRoZSBjb29raWUgZXhjaGFuZ2Uu IFRoZSBzaWduYXR1cmUgdHJhaWwgaXMgYXVnbWVudGVkIGluIHRoZSBzaWduIGV4Y2hhbmdl LiBJZiBzdWNjZXNzZnVsLCB0aGUgY2VydGlmaWNhdGUgdHJhaWwgaXMgZXh0ZW5kZWQgYnkg b25lIHN0ZXA7IGlmIG5vdCwgdGhlIGFzc29jaWF0aW9uIHRyaWVzIGFnYWluIGFmdGVyIHRp bWVvdXQuDQoNCg0KVGhlIHNlcXVlbmNlIG9mIG1lc3NhZ2VzIGluIHRoZSBwcm90b2NvbCBk YW5jZSBjYW4gYmVzdCBiZSBtYW5hZ2VkIGJ5IGFwcHJvcHJpYXRlIHN0YXRlIHRyYW5zaXRp b24gdGFibGVzLiBUaGVzZSBkYW5jZXMgYXJlIHNpbWlsYXIsIGJ1dCBub3QgaWRlbnRpY2Fs LCB0byB0aGUgb25lcyB1c2VkIGZvciBzaW1pbGFyIHB1cnBvc2VzIGluIHRoZSBSRkM1OTA2 IEF1dG9rZXkgaW1wbGVtZW50YXRpb24gYW5kIHRoZSBOVFMgcHJvcG9zYWxzLg0KDQoNCkEg c3VidGxlIGRpZmZlcmVuY2UgYmV0d2VlbiB0aGlzIHByb3Bvc2FsIGFuZCB0aGUgTlRTIHBy b3Bvc2FscyBpcyBob3cgdG8gaW50ZXJwcmV0IHRoZSBwYXJhbWV0ZXIgZXhjaGFuZ2UgZGF0 YS4gVGhlIGludGVudCBpcyB0aGF0IGVhY2ggcGVlci9jbGllbnQgaGFzIGEgcHJpdmF0ZSB2 ZWN0b3Igb2YgY29tcG9uZW50cywgYW5kIGVhY2ggcGVlci9zZXJ2ZXIgaGFzIGEgc2ltaWxh ciB2ZWN0b3Igb2YgY29tcG9uZW50cy4gVGhlIHBhcmFtZXRlciBleGNoYW5nZSBhcHBlbmRz IHRoZSB2ZWN0b3Igb2Ygb25lIHBhcnRpY2lwYW50IHRvIHRoZSB2ZWN0b3Igb2YgdGhlIG90 aGVyIHBhcnRpY2lwYW50LiBUaGVuLCB0aGUgd29ya2luZyB2ZWN0b3IgaXMgZGVyaXZlZCBp biBlYWNoIHBhcnRpY2lwYW50IGJ5IHRoZSBzYW1lIGFsZ29yaXRobS4gVGhlIHJlc3VsdCBh cHBsaWVzIHRvIGJvdGggc3ltbWV0cmljIGFuZCBjbGllbnQvc2VydmVyIG1vZGVzLCBhbHRo b3VnaCB0aGUgcmVzdWx0cyBhcmUgbm90IHNhdmVkIGluIHNlcnZlciBtb2RlLiBBIHZlY3Rv ciBjb21wb25lbnQgY29uc2lzdHMgb2YgdHVwbGVzIG9mIHJhbmsvbmlkIHZhbHVlcyBvciBh bnl0aGluZyBlbHNlIHRoYXQgY2FuIGJlIHJlcHJlc2VudGVkIGluIEFTTi4xIGVuY29kaW5n Lg0KDQoNClRoZSBjaG9pY2Ugb2YgZGFuY2UgaXMgZGV0ZXJtaW5lZCBieSB0aGUgTlRQIG1v ZGU6IGNsaWVudC9zZXJ2ZXIsIHN5bW1ldHJpYyBvciAgYnJvYWRjYXN0LiBUaGUgYWJvdmUg c2VxdWVuY2Ugb2YgZXhjaGFuZ2VzIGlzIGlkZW50aWNhbCBmb3IgY2xpZW50IGFuZCBzeW1t ZXRyaWMgbW9kZXMsIGFzIHdlbGwgYXMgb3B0aW9uYWwgYnJvYWRjYXN0IGRlbGF5IG1lYXN1 cmVtZW50LCBpZiB1c2VkLiBOb3RlIHRoYXQgdGhlIHNpZ25hdHVyZSBzY2hlbWUgaXMgZGVm aW5lZCBvbiBlYWNoIGNlcnRpZmljYXRlLiBPdGhlcndpc2UsIHRoZSBhZ3JlZW1lbnQsIGhh c2gsIHNpZ25hdHVyZSBhbmQgZW5jcnlwdGlvbiBhbGdvcml0aG0gaWRlbnRpZmllcnMgZGVm YXVsdCBhcyBpbiB0aGUgcGFyYW1ldGVyIGV4Y2hhbmdlLg0KDQoNCkEgc3VidGxlIGNvbXBs aWNhdGlvbiBpcyBob3cgdG8gdmFsaWRhdGUgdGhlIGxpZmV0aW1lIG9mIHRoZSBjZXJ0aWZp Y2F0ZXMgYWxvbmcgdGhlIHRyYWlsIHRvIHRoZSBjZXJ0aWZpY2F0ZSBhdXRob3JpdHkuIFRo ZSBsaWZldGltZSBvZiB0aGUgc3ViamVjdCBjZXJ0aWZpY2F0ZSBpbnRlcnNlY3RlZCB3aXRo IHRoZSBsaWZldGltZSBvZiB0aGUgaXNzdWVyIGNlcnRpZmljYXRlIG1pZ2h0IG9yIG1pZ2h0 IG5vdCBiZSBlbXB0eS4gSG93ZXZlciwgdGhlIGxpZmV0aW1lIG9mIHRoZSBzZXJ2ZXIgY2Vy dGlmaWNhdGUgbXVzdCBjb250YWluIHRoZSBjdXJyZW50IHZhbGlkIHRpbWUuDQoNCg0KVGhl IG9ydGhvZG94IHdheSBpcyB0byB3YWl0IHVudGlsIHRoZSBhc3NvY2lhdGlvbiB0aW1lIGlz IHZhbGlkLCB0aGVuIGNvbXBhcmUgdGhlIHZhbGlkIHRpbWUgd2l0aCB0aGUgY2VydGlmaWNh dGUgbGlmZXRpbWUuIEEgZGlzY3JlcGFuY3kgcmVzdWx0cyBpbiBhIHByb3RvY29sIHJlc3Rh cnQuIE5vdGUgdGhhdCBhIG5ldyByZWdlbmVyYXRlZCBjZXJ0aWZpY2F0ZSBtaWdodCByZXF1 aXJlIGEgbmV3IGdlbmVyYXRpb24gb2YgaXRzIGlzc3Vlci4gVGhlIGltcGxpY2F0aW9ucyBt YXkgYmUgdGVkaW91cy4NCg0KDQpUaGUgZGFuY2VzIGludm9sdmUgYSBiYWxhbmNlIGJldHdl ZW4gZm9ybWFsIGF1dGhlbnRpY2F0aW9uIGFuZCBkdXJhdGlvbiBvZiB0aGUgcHJvdG9jb2wu IEZvciBpbnN0YW5jZSwgdGhlIGNvb2tpZSBleGNoYW5nZSBjb25maXJtcyB0aGF0IHRoZSBo YXNoIGtleSBpcyB2YWxpZCwgYnV0IGRvZXMgbm90IG5lY2Vzc2FyaWx5IGNvbmZpcm0gdGhh dCB0aGUgY2VydGlmaWNhdGUgdHJhaWwgaXMgdmFsaWQuIEEgc3VjY2Vzc2Z1bCBzaWduYXR1 cmUgb2YgdGhlIGhvc3QgY2VydGlmaWNhdGUgY29uZmlybXMgdGhhdCB0aGUgaG9zdCBjZXJ0 aWZpY2F0ZSBpcyB2YWxpZC4gVGhlcmUgaXMgYW4gaW50ZXJ2YWwgYmV0d2VlbiB2YWxpZGF0 aW9uIG9mIHRoZSBzaGFyZWQgaGFzaCBrZXkgYW5kIHZhbGlkYXRpb24gb2YgdGhlIGNlcnRp ZmljYXRlIHRyYWlsIGJ1dCB0aGUgdGltZSBpbmZvcm1hdGlvbiBtYXkgb3IgbWF5IG5vdCBi ZSBjb3JyZWN0Lg0KDQoNCk5vdGUgdGhhdCBlYWNoIGNvbXBsZXRpb24gb2YgdGhlIGRhbmNl IHJlc3VsdHMgaW4gYSBuZXcgc2hhcmVkIGhhc2gga2V5IHVucmVsYXRlZCB0byB0aGUgbGFz dCBzaGFyZWQgaGFzaCBrZXkuIEluIHRoaXMgc2Vuc2UsIHRoZSBwcm90b2NvbCBoYXMgcGVy ZmVjdCBmb3J3YXJkIHNlY3JlY3kuDQoNCg0KV2Ugd2lsbCBub3cgZGVzY3JpYmUgdGhlIGRh bmNlcyBmb3IgU3ltbWV0cmljLCBDbGllbnQvU2VydmVyLCBhbmQgQnJvYWRjYXN0IE1vZGVz Lg0KDQoNCjguNC4xIFN5bW1ldHJpYyBNb2RlDQoNCg0KVGhlIGdvYWwgb2YgdGhpcyBkYW5j ZSBpcyB0byBpbnN0YWxsIGlkZW50aWNhbCBzaGFyZWQgaGFzaCBrZXlzIGluIGJvdGggcGVl cnMuIFRoZSBkYW5jZSBjYW4gYmUgc3RhcnRlZCBieSBlaXRoZXIgcGVlci4gUGVlcnMgQWxp Y2UgYW5kIEJvYiB1c2UgbGFyZ2UgcHJpbWUgcCBhcyBtb2R1bHVzIGFuZCBwcmltaXRpdmUg cm9vdCBnIGFzIGdlbmVyYXRvci4gQSBzbWFsbCB2YWx1ZSBmb3IgZywgdHlwaWNhbGx5IDIs IGlzIG9mdGVuIHVzZWQuDQoNCg0KSW4gdGhlIGFncmVlbWVudCBwaGFzZSwgQWxpY2Ugc2Vu ZHMgaGVyIHB1YmxpYyBESCBrZXkgdG8gQm9iIGluIGFuIGV4dGVuc2lvbiBmaWVsZCBvZiBh IHJlcXVlc3QgbWVzc2FnZS4gQm9iIGNvbnN0cnVjdHMgaGlzIHB1YmxpYyBESCBrZXkgYW5k IHNlbmRzIGl0IHRvIEFsaWNlIGluIGFuIGV4dGVuc2lvbiBmaWVsZCBvZiBhIHJlc3BvbnNl IG1lc3NhZ2UuIEJvdGggQWxpY2UgYW5kIEJvYiB0aGVuIGNvbnN0cnVjdCB0aGUgc2hhcmVk IGhhc2gga2V5IGZvciB1c2UgbGF0ZXIuDQoNCg0KSW4gdGhlIGF1dGhlbnRpY2F0aW9uIHBo YXNlLCBBbGljZSBzZW5kcyBoZXIgc2lnbmF0dXJlIG9mIHRoZSBzaGFyZWQgaGFzaCBrZXkg dG8gQm9iLiBCb2IgdmVyaWZpZXMgdGhlIHNpZ25hdHVyZSwgdGhlbiBzZW5kcyBoaXMgc2ln bmF0dXJlIG9mIHRoZSBzaGFyZWQgaGFzaCBrZXkgdG8gQWxpY2UuIEFsaWNlIHZlcmlmaWVz IGhpcyBzaWduYXR1cmUuIEZhaWx1cmUgdG8gdmFsaWRhdGUgZWl0aGVyIHNpZ25hdHVyZSBy ZXN1bHRzIGluIGEgY3J5cHRvLU5BSyBhbmQgcHJvdG9jb2wgcmVzdGFydC4NCg0KDQpUaGUg c2hhcmVkIGtleSBjb25zdHJ1Y3RlZCBieSBBbGljZSBhbmQgQm9iIGlzIHVzZWQgYXMgdGhl IGhhc2gga2V5IGluIHN1YnNlcXVlbnQgbWVzc2FnZXMuIFRoZSBwdWJsaWMgYW5kIHByaXZh dGUgREgga2V5cyBhcmUgZXhwdW5nZWQgYWZ0ZXIgdXNlOyB0aGV5IGFyZSB1c2VkIG9ubHkg b25jZS4NCg0KDQo4LjQuMiBDbGllbnQvU2VydmVyIE1vZGUNCg0KDQpUaGUgZ29hbCBpbiB0 aGlzIGRhbmNlIGlzIHRvIGluc3RhbGwgYSBzZXJ2ZXIgY29va2llIHVzZWQgaW4gdGhlIGNs aWVudCBhcyB0aGUgaGFzaCBrZXkuIFRoZSBkYW5jZSBpcyBzdGFydGVkIGJ5IHRoZSBjbGll bnQuIFRoZSBjb29raWUgY2FuIGJlIHJlZ2VuZXJhdGVkIGJ5IHRoZSBzZXJ2ZXIgdXBvbiBh cnJpdmFsIG9mIGEgY2xpZW50IHBhY2tldC4gVGhlIGNvb2tpZSBleGNoYW5nZSBpcyBzaW1p bGFyIHRvIHRoZSBjb29raWUgZXhjaGFuZ2UgcHJvcG9zZWQgaW4gdGhlIE5UUyBkb2N1bWVu dHMsIGV4Y2VwdCB0aGF0IHRoZSBwcm9wb3NlZCBjb29raWUgZXhjaGFuZ2UgaXMgcHJvdGVj dGVkIGJ5IGtleSB6ZXJvIGFuZCB0aGUgb24td2lyZSBwcm90b2NvbCBsYXllci4NCg0KDQpJ biB0aGUgYWdyZWVtZW50IHBoYXNlLCBjbGllbnQgQWxpY2Ugc2VuZHMgaGVyIHB1YmxpYyBE SCBrZXkgdG8gc2VydmVyIEJvYi4gQm9iIHRoZW4gc2VuZHMgaGlzIHB1YmxpYyBESCBrZXkg dG8gQWxpY2UuIEJvdGggQWxpY2UgYW5kIEJvYiBjb25zdHJ1Y3QgdGhlIHNoYXJlZCBrZXkg YXMgZGVzY3JpYmVkIGFib3ZlLiBBbGljZSBhbmQgQm9iIHVzZSB0aGUgc2hhcmVkIGtleSBh cyB0aGUgZW5jcnlwdGlvbiBrZXkgdXNlZCBsYXRlci4NCg0KDQpUaGUgY29va2llIGlzIHRo ZSBoYXNoIG9mIHRoZSBjbGllbnQgSVAgYWRkcmVzc2VzIGNvbmNhdGVuYXRlZCB3aXRoIGEg c2VydmVyIHNlY3JldCBrZXkgdXNpbmcgdGhlIHNlbGVjdGVkIGhhc2ggYWxnb3JpdGhtLiBU aGUgc2VydmVyIHNlY3JldCBrZXkgaXMgYSByYW5kb20gbnVtYmVyIHJlZ2VuZXJhdGVkIGFi b3V0IG9uY2UgcGVyIGRheS4gQm9iIGVuY3J5cHRzIHRoZSBjb29raWUgdXNpbmcgdGhlIGFi b3ZlIGtleSBhbmQgc2VuZHMgaXQgaW4gdGhlIHNhbWUgcmVzcG9uc2UgYXMgdGhlIERIIHB1 YmxpYyBrZXkgYWJvdmUuDQoNCg0KVGhlIGF1dGhlbnRpY2F0aW9uIHBoYXNlIHVzZXMgdGhl IHNhbWUgc2lnbmF0dXJlcyBhcyBpbiBzeW1tZXRyaWMgbW9kZS4gQXMgYW4gb3B0aW9uYWwg ZW1iZWxsaXNobWVudCwgaWYgdGhlIHNlcnZlciBoYXMgdGhlIHB1YmxpYyBjZXJ0aWZpY2F0 ZSBvZiB0aGUgY2xpZW50LCB0aGlzIGF1dGhlbnRpY2F0ZXMgdGhlIGNsaWVudCB0byB0aGUg c2VydmVyIGFzIHdlbGwuDQoNCg0KQXMgYW4gb3B0aW9uYWwgZmVhdHVyZSwgYSBub25jZSBj YW4gYmUgY29uY2F0ZW5hdGVkIHdpdGggdGhlIGNvb2tpZSBhbmQgdGhlDQp3b3JraW5nIGNv b2tpZSBhcyB0aGUgaGFzaCBvZiB0aGUgcmVzdWx0LiAgVGhlIG5vbmNlIGNhbiBiZSBkZXRl cm1pbmVkIGJ5IHRoZQ0KdHJhbnNtaXQgdGltZXN0YW1wIG9yIHRoZSBrZXkgaWQgZmllbGQg b2YgdGhlIE1BQy4gIE90aGVyIHNjaGVtZXMgY2FuIGJlDQpkZXZpc2VkLg0KDQoNCjguNC4z IEJyb2FkY2FzdCBNb2RlDQoNCg0KVGhlIG9yaWdpbmFsIEF1dG9rZXkgcHJvdG9jb2wgd2Fz IGJhc2VkIG9uIHRoZSBhc3N1bXB0aW9uIHRoYXQgdGhlIGNyeXB0b2dyYXBoaWMgYWxnb3Jp dGhtcyB3ZXJlIHZlcnkgc2xvdyBhbmQgdnVsbmVyYWJsZSB0byBhIGZsb29kaW5nIGF0dGFj ay4gSW4gZmFjdCwgdGhlIERpZmZpZS1IZWxsbWFuIGFncmVlbWVudCB0b29rIG92ZXIgMTAg c2Vjb25kcyBvbiBhIFN1biBJUEMuIEFzIGN1cnJlbnQgbWFjaGluZXMgYW5kIGFsZ29yaXRo bXMgYXJlIG11Y2ggZmFzdGVyLCBpdCBpcyBjb252ZW5pZW50IGZvciB0aGUgc2VydmVyIHRv IGNvbXB1dGUgdGhlIHNpZ25hdHVyZSBvZiB0aGUgTlRQIGhlYWRlciBpbiBhbiBleHRlbnNp b24gZmllbGQgYW5kIGZvciB0aGUgY2xpZW50IHRvIHZlcmlmeSB0aGUgc2lnbmF0dXJlIHVz aW5nIHRoZSBwdWJsaWMga2V5IG9uIHRoZSBzZXJ2ZXIgY2VydGlmaWNhdGUuIFRoZSBzZXJ2 ZXIgY2VydGlmaWNhdGUgbXVzdCBiZSBpbnN0YWxsZWQgYmVmb3JlaGFuZCBpbiBlYWNoIGNs aWVudC4gVGhpcyBpcyBub3QgYSB0cml2aWFsIHJlcXVpcmVtZW50OyB0aGUgY2VydGlmaWNh dGUgdHJhaWwgbXVzdCBiZSBjb25zdHJ1Y3RlZCBzZXBhcmF0ZWx5Lg0KDQoNCldoZW4gdHdv IG9yIG1vcmUgYnJvYWRjYXN0IGNsaWVudCBhc3NvY2lhdGlvbnMgYXJlIGluIHRoZSBzYW1l IGhvc3QsIGl0IGlzIGNvbnZlbmllbnQgdG8gaW5jbHVkZSB0aGUgY2VydGlmaWNhdGUgbmFt ZSBpbiBhbiBleHRlbnNpb24gZmllbGQgb2YgdGhlIGJyb2FkY2FzdCBwYWNrZXQuICBUaGlz IHNlbGVjdHMgdGhlIHNlcnZlciBjZXJ0aWZpY2F0ZSBhbmQgdGh1cyB0aGUgY29ycmVjdCBz aWduYXR1cmUga2V5Lg0KDQoNCkEgY29tbW9uIHByb2JsZW0gaW4gdGhpcyBhbmQgb3RoZXIg YnJvYWRjYXN0IHNjaGVtZXMgaXMgdnVsbmVyYWJpbGl0eSB0byBjb3BpZXMgb2Ygb2xkLCBv ciBwZXJoYXBzIHZlcnkgb2xkLCBtZXNzYWdlcy4gVGhlIHByb3Bvc2VkIHNvbHV0aW9uIGlz IHRvIHVzZSB0aGUgdHJhbnNtaXQgdGltZXN0YW1wIGFzIGEgc2VxdWVuY2UgbnVtYmVyIGFu ZCBvcmRlcmluZyBmdW5jdGlvbi4gQW4gb2xkIGR1cGxpY2F0ZSBpcyByZWNvZ25pemVkIGJ5 IGEgdHJhbnNtaXQgdGltZXN0YW1wIG9sZGVyIHRoYW4gdGhlIG1vc3QgcmVjZW50IHRyYW5z bWl0IHRpbWVzdGFtcC4gT25jZSB0aGUgZmlyc3QgcGFja2V0IGlzIHJlY2VpdmVkLCB0aGUg YnJvYWRjYXN0IGNsaWVudCBpZ25vcmVzIGFsbCBicm9hZGNhc3QgcGFja2V0cyB3aXRoIGFu IGVhcmxpZXIgdHJhbnNtaXQgdGltZXN0YW1wLiBUaGlzIGRlc2lnbiB3b3JrcyBldmVuIGlm IHRoZSBicm9hZGNhc3Qgc2VydmVyIGlzIHJlc3RhcnRlZC4gSWYgYSBicm9hZGNhc3QgY2xp ZW50IGlzIHJlc3RhcnRlZCwgdGhlcmUgbWlnaHQgYmUgc29tZSBzcHVyaW91cyBvbGQgZHVw bGljYXRlcyBiZWZvcmUgdGhlIGZpcnN0IG5ldyBtZXNzYWdlLiBJZiB0aGUgbW9zdCByZWNl bnQgdHJhbnNtaXQgdGltZXN0YW1wIGlzIHByZXNlcnZlZCBiZXR3ZWVuIHJlc3RhcnRzLCB0 aGVzZSBvbGQgZHVwbGljYXRlcyBhcmUgc3VwcHJlc3NlZC4NCg0KDQo5LiBFcnJvciBSZWNv dmVyeQ0KDQoNCk9uZSBvZiB0aGUgZmlyc3QgdGhpbmdzIGEgc3VzcGljaW91cyBjcnlwdG9n cmFwaGVyIGxvb2tzIGF0IGlzIHRoZSBzaXplIG9mIHRoZSBiaXQgc3RyaW5ncyB1c2VkIGlu IHRoZSBhdXRoZW50aWNhdGlvbiBzY2hlbWUuIEEgYnJ1dGUgZm9yY2UgYXR0YWNrIG9uIHRo ZSBzaGFyZWQgaGFzaCBrZXkgbWlnaHQgbm90IHdvcmsgaW4gYWxsIGNhc2VzLiBDb25zaWRl ciB0aGUgbnVtYmVyIGsgb2Ygc3B1cmlvdXMga2V5cyB0aGF0IGNvcnJlY3RseSBkZWNyeXB0 IGEgY2lwaGVydGV4dCBvZiBuIHN5bWJvbHMuIFRoZSBudW1iZXIgayBnZW5lcmFsbHkgZGVj cmVhc2VzIGFzIG4gaW5jcmVhc2VzLiBUaGUgbnVtYmVyIG9mIHN5bWJvbHMgbiB3aGVyZSBr IGRlY3JlYXNlcyB0byBvbmUgaXMgY2FsbGVkIHRoZSB1bmljaXR5IGRpc3RhbmNlLiBJZiB0 aGUgcGFja2V0IGxlbmd0aCBpcyBsZXNzIHRoYW4gdGhlIHVuaWNpdHkgZGlzdGFuY2UsIHRo aXMgbWVhbnMgdGhhdCBhIGtleSB0aGF0IGNvcnJlY3RseSBkZWNyeXB0cyBhIGNpcGhlcnRl eHQgeCBtYXkgbm90IGNvcnJlY3RseSBkZWNyeXB0IGEgY2lwaGVydGV4dCBvdGhlciB0aGFu IHguDQoNCg0KVGhlIHVzdWFsIHJlc3BvbnNlIHRvIGEgaGFzaCBvciBzaWduYXR1cmUgZmFp bHVyZSBpbiBzeW1tZXRyaWMgYW5kIHNlcnZlciBtb2RlcyBpcyB0byBzZW5kIGEgY3J5cHRv LU5BSyBhbmQgZGlzY2FyZCB0aGUgcGFja2V0LiBUaGUgY3J5cHRvLU5BSyBpcyBub3QgdXNl ZCBpbiBjbGllbnQgb3IgYnJvYWRjYXN0IG1vZGVzLg0KDQoNCklmIHRoZSBjcnlwdG8tTkFL IHJlc3VsdHMgZnJvbSBhIGhhc2ggZmFpbHVyZSwgb25seSB0aGUgYWdyZWVtZW50IHBoYXNl IG9mIHRoZSBjb29raWUgZXhjaGFuZ2UgaXMgbmVjZXNzYXJ5LiBJZiB0aGUgY3J5cHRvLU5B SyByZXN1bHRzIGZyb20gYSBzaWduYXR1cmUgZmFpbHVyZSwgdGhlIHByb3RvY29sIGlzIHJl c3RhcnRlZC4NCg0KDQpBbGwgbWVzc2FnZXMsIGluY2x1ZGluZyB0aGUgY3J5cHRvLU5BSywg YXJlIHZhbGlkYXRlZCBieSB0aGUgbG9vcGJhY2sgdGVzdCBvZiB0aGUgb24td2lyZSBwcm90 b2NvbC4gSW4gYWRkaXRpb24sIGFsbCBtZXNzYWdlcyBhZnRlciB0aGUgYWdyZWVtZW50IHBo YXNlIG9mIHRoZSBjb29raWUgZXhjaGFuZ2UgYXJlIHByb3RlY3RlZCBieSB0aGUgYWdyZWVk IGhhc2gga2V5IGFuZCBoYXNoIGFsZ29yaXRobS4NCg0KDQpUaGVyZSBpcyBhIHdpZGUgc3Bl Y3RydW0gb2YgcG9zc2libGUgaG9zdGlsZSBwcm9iZXMgb24gdGhlIE5UUCBpbXBsZW1lbnRh dGlvbiBpdHNlbGYuIE9uZSBvZiB0aGVzZSBpcyBzaW1wbHkgdG8gYW1wdXRhdGUgdGhlIGNy eXB0b2dyYXBoaWMgZGF0YSBmcm9tIGEgdHJhbnNtaXR0ZWQgcGFja2V0LiBBbiBpbW1hdHVy ZSBpbXBsZW1lbnRhdGlvbiBtaWdodCBhc3N1bWUgdGhhdCB0aGUgTlRQIGRlc2lnbiBwZXJt aXRzIGJvdGggc2VjdXJlIGFuZCB1bnNlY3VyZSBvcGVyYXRpb25zIHRvIGJlIHNhbmN0aW9u ZWQuIFN1Y2ggYW4gZXJyb3IgaW52aXRlcyBhIG1pZGRsZW1hbiB0byBzaWduaWZpY2FudGx5 IGFsdGVyIHRoZSByZWNlaXZlIGFuZCB0cmFuc21pdCB0aW1lc3RhbXBzIG9uIHRoZSBOVFAg cGFja2V0LCByZXN1bHRpbmcgaW4gYW55IG9mIHRoZSBhY3Rpb25zIGRlc2NyaWJlZCBiZWxv dy4NCg0KDQpBIHByb3RvY29sIHJlc3RhcnQgaXMgaW5pdGlhdGVkIHVwb24gcmVjZWlwdCBv ZiBhIHZhbGlkIGNyeXB0by1OQUsgaW4gcmVzcG9uc2UgdG8gYSBzaWduYXR1cmUgZmFpbHVy ZSBvciBwcm90b2NvbCBlcnJvci4gQSBjcnlwdG8tTkFLIHJlc3VsdGluZyBmcm9tIGEgaGFz aCBmYWlsdXJlIG9yZGluYXJpbHkgcmVzdWx0cyBpbiBvbmx5IGEgY29va2llIGV4Y2hhbmdl LiANCg0KDQpJbiBzeW1tZXRyaWMgbW9kZSBlYWNoIHJlc3RhcnQgcmVzdWx0cyBpbiBhIGRp ZmZlcmVudCBzaGFyZWQgaGFzaCBrZXkuIEluIGNsaWVudC9zZXJ2ZXIgbW9kZSwgdGhlIHNo YXJlZCBoYXNoIGtleSBpcyBjaGFuZ2VkIG9ubHkgd2hlbiB0aGUgc2VydmVyIHNlY3JldCB2 YWx1ZSBvciB0aGUgYWJvdmUgbm9uY2UgaXMgY2hhbmdlZC4NCg0KDQpUaGUgcmVzdGFydCB0 aGVuIGRlbGF5cyBhIHRpbWUgaW50ZXJ2YWwgcmFuZG9taXplZCBvdmVyIHRoZSBwb2xsIGlu dGVydmFsLCB0aGVuIHNlbmRzIGEgcGFyYW1ldGVyIGV4Y2hhbmdlIGFuZCBjb250aW51ZXMg dGhlIGRhbmNlLg0KDQoNClRoaXMgZGVzaWduIHByb3ZpZGVzIGNvcnJlY3QgcmVjb3Zlcnkg aW4gY2FzZSBvZiBwdWJsaWMga2V5IGNoYW5nZXMgYW5kIHNlcnZlciBzZWNyZXQga2V5IHVw ZGF0ZXMuIFdoaWxlIHRoaXMgc2NoZW1lIGludml0ZXMgYSB0ZXJyb3Jpc3QgdG8gZGlzcnVw dCB0aGUgcHJvdG9jb2wgYnkgaW5qZWN0aW5nIGEgYm9ndXMgcGFyYW1ldGVyIGV4Y2hhbmdl IGluIHRoZSBtaWRkbGUgb2Ygb3JkaW5hcnkgb3BlcmF0aW9ucywgdGhlIGNob2ljZSBvZiBr ZXkgemVybyBwcm90ZWN0cyB0aGUgaGFuZHNoYWtlIGZyb20gZm9yZWlnbiBuZXR3b3JrcyB3 aXRob3V0IGtub3dsZWRnZSBvZiB0aGUga2V5IHplcm8gdmFsdWUuIFRoZSByZXN1bHQgbWF5 IG5vdCBiZSBhIHZ1bG5lcmFiaWxpdHksIGJ1dCBpbiBhbnkgY2FzZSByZXByZXNlbnRzIGEg ZGVuaWFsIG9mIHNlcnZpY2UgYXR0YWNrLg0KDQoNClRoZSByYW5kb20gZGVsYXkgYXQgcmVz dGFydCBpcyBkZXNpZ25lZCB0byBtaW5pbWl6ZSBjb2xsaXNpb25zIGluIHN5bW1ldHJpYyBt b2RlLiBBIHNpbXBsZSBhbGdvcml0aG0gaXMgdXNlZCBpbiB0aGUgcmVmZXJlbmNlIGltcGxl bWVudGF0aW9uIHRvIHNsZXcgdGhlIHBhY2tldHMgb2Ygb25lIHBlZXIgdG8gYmUgdHJhbnNt aXR0ZWQgbmVhciB0aGUgbWlkcG9pbnQgb2YgdGhlIG90aGVyIHBlZXLigJlzIHBvbGwgaW50 ZXJ2YWwuDQoNCg0KSWYgYSB0aW1lb3V0IG9jY3VycyBiZWZvcmUgcmVjZWl2aW5nIGEgcmVz cG9uc2UgdG8gYSBwcmV2aW91cyByZXF1ZXN0LCB0aGUgcmVxdWVzdCBpcyBzZW50IGFnYWlu IHdpdGggbmV3IHN0YXRlIHZhcmlhYmxlcyBpbiB0aGUgbmV4dCBOVFAgcGFja2V0LiAgQSBy ZXNwb25zZSB3aXRob3V0IGEgcHJldmlvdXMgbWF0Y2hpbmcgcmVxdWVzdCBpcyBkaXNjYXJk ZWQuIElmIGEgcmVxdWVzdCBpcyByZWNlaXZlZCBiZWZvcmUgdGhlIHJlc3BvbnNlIHRvIGEg cHJldmlvdXMgcmVxdWVzdCwgdGhlIHJlc3VsdCBpcyBhIHByb3RvY29sIGVycm9yLiBJZiBh IHNpZ24gcmVxdWVzdCBpcyByZWNlaXZlZCBiZWZvcmUgdGhlIGNlcnRpZmljYXRlIGV4Y2hh bmdlLCB0aGUgcmVxdWVzdCBpcyBpZ25vcmVkLg0KDQoNCk9uY2UgdGhlIHByb3RvY29sIGRh bmNlcyBoYXZlIGxlZnQgdGhlIHN0YWdlLCB0aGUgcmVzdWx0IGlzIGEgc2hhcmVkIGhhc2gg a2V5LiBUaGUgaGFzaCBrZXkgaXMgdXNlZCB0byBjb25zdHJ1Y3QgdGhlIGhhc2ggZm9yIHRo ZSBNQUMuIFRoZSBrZXkgSUQgaXMgY29kZWQgdG8gZGlzdGluZ3Vpc2ggYWdyZWVkIGtleXMg ZnJvbSB0YWJsZSBrZXlzLiBUaGUgY3J5cHRvZ3JhcGhpYyBzdHJlbmd0aCBkZXBlbmRzIG9u IHRoZSBzaXplIG9mIHRoZSBoYXNoIGFuZCB0aGUgaGFzaCBhbGdvcml0aG07IG90aGVyd2lz ZSwgdGhlIHN0cmVuZ3RoIG9mIHRoZSBhZ3JlZWQga2V5IGFuZCB0YWJsZSBrZXkgYXJlIHRo ZSBzYW1lLg0KDQoNCldoaWxlIGl0IGlzIGNyeXB0b2dyYXBoaWNhbGx5IGhhcmQgdG8gbWFz cXVlcmFkZSBhcyBhIHZhbGlkIHBlZXIsIGNsaWVudCBvciBzZXJ2ZXIsIGEgY2xldmVyIG1p ZGRsZW1hbiBjYW4gc2ltcGx5IGNoYW5nZSBhIHBhY2tldCB0byBpbnRlbnRpb25hbGx5IGNh dXNlIGEgY3J5cHRvLU5BSyBhbmQgZXZlbnR1YWxseSBhIHByb3RvY29sIHJlc3RhcnQuIERv bmUgb2Z0ZW4gZW5vdWdoLCB0aGUgcmVzdWx0IHJlcHJlc2VudHMgYSBkZW5pYWwgb2Ygc2Vy dmljZSBhdHRhY2suDQoNCg0KVGhlIHByb3RvY29sIGRhbmNlIGlzIHByb3RlY3RlZCBpbiBw YXJ0IGJ5IHRoZSBvbi13aXJlIHByb3RvY29sIGxheWVyIGFuZCBieSB0aGUgc2hhcmVkIGhh c2gga2V5LiBUaGUgcGFyYW1ldGVyIHJlcXVlc3QgaW5jbHVkZXMgdGhlIHN1YmplY3QgbmFt ZSBvZiB0aGUgaG9zdCBjZXJ0aWZpY2F0ZTsgdGhlIHBhcmFtZXRlciByZXNwb25zZSBpbmNs dWRlcyB0aGUgc3ViamVjdCBuYW1lIG9mIHRoZSBzZXJ2ZXIgY2VydGlmaWNhdGUuIFRoZXNl IG5hbWVzIGNhbiBiZSB2ZXJpZmllZCBieSB0aGUgY2xpZW50IGFzc29jaWF0aW9uLg0KDQoN ClRoZSBmaXJzdCBjZXJ0aWZpY2F0ZSBleGNoYW5nZSByZXZlYWxzIHRoZSBzZXJ2ZXIgY2Vy dGlmaWNhdGUgdXNlZCB0byB2YWxpZGF0ZSB0aGUgY29va2llIGV4Y2hhbmdlLiBUaHVzLCBh IGhvc3RpbGUgaW50cnVkZXIgY2Fubm90IHRvc3MgZmFrZSB2YWx1ZXMgd2l0aCBlZmZlY3Qg b24gdGhlIHN0YXRlIG9mIHRoZSByZWNpcGllbnQuIEF0dGFja3Mgb24gdGhlIHBhcmFtZXRl ciBhbmQgY29va2llIGV4Y2hhbmdlcyBhcmUgZGVmbGVjdGVkIGJ5IGtleSB6ZXJvLCBidXQg YXJlIG1pdGlnYXRlZCBieSB0aGUgb24td2lyZSBsYXllcjsgcGFja2V0cyB3aXRoIGxvb3Bi YWNrIGVycm9ycyBhcmUgaWdub3JlZC4gVGh1cywgdGhlIG1vc3QgbGlrZWx5IHJlc3VsdCBv ZiBhIG1pZGRsZW1hbiBpbnZhc2lvbiBpcyBhIHJlc3RhcnQsIHJhdGhlciB0aGFuIGEgZmFs c2UgYWdyZWVtZW50Lg0KDQoNCkEgc2lnbmlmaWNhbnQgZGlzcnVwdGlvbiBpcyBsaWtlbHkg d2hlbiBhIG5ldyBwdWJsaWMvcHJpdmF0ZSBrZXkgYW5kIGNlcnRpZmljYXRlIGFyZSBnZW5l cmF0ZWQgaW4gdGhlIG1pZGRsZSBvZiB0aGUgY2VydGlmaWNhdGUgdHJhaWwuIFRoaXMgcmVx dWlyZXMgcmVjb21wdXRpbmcgdGhlIG5ldyBjZXJ0aWZpY2F0ZSBzaWduYXR1cmUgaW4gdGhl IGltbWVkaWF0ZSB1cHN0cmVhbSBob3N0IGFuZCBhbGwgaW1tZWRpYXRlIGRvd25zdHJlYW0g aG9zdHMuDQoNCg0KSW4gYnJvYWRjYXN0IG1vZGUsIHRoZSBtb3N0IHBvcHVsYXIgYXR0YWNr IGlzIHRvIHJlcGVhdCBvbGQgdmFsaWQgbWVzc2FnZXMuIE9yZGluYXJpbHksIHRoZXNlIGFy ZSBzdXBwcmVzc2VkIGJ5IHRoZSB0cmFuc21pdCB0aW1lc3RhbXAgYXMgZGVzY3JpYmVkIGFi b3ZlLiBIb3dldmVyLCBwcm90b2NvbCByZXN0YXJ0cyBhbmQgbG9zdCBwYWNrZXRzIG1pZ2h0 IHJlc3VsdCBpbiBtaXNvcmRlcmVkIG1lc3NhZ2VzLiBUaGUgZW5saWdodGVuZWQgcmVzcG9u c2UgaXMgdG8gcnVuIGEgdGltZW91dCB1cG9uIHJlY2VpdmluZyBhIHZhbGlkIG1lc3NhZ2Ug YW5kIHRlcm1pbmF0ZSBpdCB1cG9uIHJlY2VpdmluZyBhIG1lc3NhZ2Ugd2l0aCBhIGxhdGVy IHRpbWVzdGFtcC4gTm90ZSB0aGF0IGEgdGVycm9yaXN0IGNhbm5vdCBjb25zdHJ1Y3QgYSB2 YWxpZCBtZXNzYWdlLCBhcyBpdCBjYW5ub3QgY29uc3RydWN0IGEgdmFsaWQgc2lnbmF0dXJl Lg0KDQoNCk9mIHRoZSB0aHJlYXQgc2NlbmFyaW9zLCBhIGRpc3RyaWJ1dGVkIGRlbmlhbCBv ZiBzZXJ2aWNlIGF0dGFjayBpcyB0aGUgbW9zdCBkaXNydXB0aXZlLiAgVGhpcyBzY2VuYXJp byBjYW4gYmUgY3JlYXRlZCB3aGVuIGEgbGFyZ2UgbnVtYmVyIG9mIGF0dGFja2VycyBjb29w ZXJhdGUgdG8gc2VuZCBhIHN0cmVhbSBvZiBwYWNrZXRzIHRvIHZpY3RpbSBzZXJ2ZXIgYXQg aGlnaCByYXRlLg0KDQoNCk9uZSBzb2x1dGlvbiB1c2VzIHRoZSBtb3N0IHJlY2VudGx5IHVz ZWQgKE1SVSkgbGlzdCB1c2VkIGJ5IHRoZSByYXRlIG1hbmFnZW1lbnQgZnVuY3Rpb24uICBF YWNoIGVudHJ5IGluY2x1ZGVzIHRoZSBjbGllbnQgYWRkcmVzcywgcHJvY2VzcyB0aW1lIG9m IGFycml2YWwgYW5kIHJlbGF0ZWQgaW5mb3JtYXRpb24uICBUaGUgbGlzdCBpcyBvcmRlcmVk IGJ5IGluY3JlYXNpbmcgcHJvY2VzcyB0aW1lIG9mIGFycml2YWwgd2l0aCBkdXBsaWNhdGUg SVAgYWRkcmVzc2VzIHN1cHByZXNzZWQuICBBIEREb1MgYXR0YWNrIGlzIHNpZ25hbGxlZCB3 aGVuIHRoZSBsaXN0IGZpbGxzIHVwIGFuZCBvdmVyZmxvd3MuICBPbiBvdmVyZmxvdywgbmV3 IHBhY2tldHMgYXJlIGRpc2NhcmRlZCBhdCBhIHJhdGUgY29uc2lzdGVudCB3aXRoIHRoZSBv dmVyZmxvdyByYXRlLg0KDQoNCkluIHRoZSBwcm90b2NvbCBkZXNjcmliZWQgaW4gdGhpcyBk b2N1bWVudCwgYW4gYW1wbGlmaWNhdGlvbiBoYXphcmQgaXMgd2hlbiBhIHNtYWxsIHJlcXVl c3QgbWVzc2FnZSByZXN1bHRzIGluIGEgbGFyZ2UgcmVzcG9uc2UgbWVzc2FnZS4gIFRoaXMg aXMgYXZvaWRlZCBpbiB0aGUgTlRTIHByb3Bvc2FsIGJ5IGluY2x1ZGluZyBhIGR1bW15IHBs YWNlaG9sZGVyIGluIHRoZSByZXF1ZXN0LCBzbyB0aGF0IHRoZSByZXNwb25zZSBoYXMgdGhl IHNhbWUgbGVuZ3RoIGFzIHRoZSByZXF1ZXN0LiAgVGhpcyBpcyBjb25zaWRlcmVkIGEgd2Fz dGUgb2YgbmV0d29yayByZXNvdXJjZXMgYW5kIHVubmVjZXNzYXJ5IGluIHRoZSBwcm90b2Nv bCBwcm9wb3NlIGhlcmUuICBXaXRoIHRoZSBwcm9wb3NlZCBleGNoYW5nZXMgaW4gdGhpcyBk b2N1bWVudCwgdGhlcmUgYXJlIG5vIGluc3RhbmNlcyBvZiBzaWduaWZpY2FudCBkaWZmZXJl bmNlcyBiZXR3ZWVuIHRoZSBsZW5ndGhzIG9mIHJlcXVlc3QgYW5kIHJlc3BvbnNlDQptZXNz YWdlcywgZXhjZXB0IGZvciB0aGUgY29va2llIHJlc3BvbnNlIG1lc3NhZ2UgYXMgZGVzY3Jp YmVkIHByZXZpb3VzbHkuDQoNCg0KQWxzbyBub3RlICB0aGF0IHRoZSBvcmlnaW5hbCBsaWJy YXJ5IHByb2dyYW0gdXNlZCB0byBnZW5lcmF0ZSBrZXlzIGFuZCBjZXJ0aWZpY2F0ZSBhcHBs aWNhdGlvbnMgY29udGludWVzIHRvIHdvcmsgd2l0aCB0aGUgcHJvcG9zZWQgc2NoZW1lLiAg QSBzaWduaWZpY2FudCBjaGFsbGVuZ2UgaXMgdG8gbWluaW1pemUgdGhlIGNvbXBsZXhpdHkg b2YgdGhlIGNvbmZpZ3VyYXRpb24gZWZmb3J0Lg0KDQoNCjkuMSBEYXRhIE1pbmltaXphdGlv bg0KDQoNCltDb250ZW50IHRvIGJlIGFkZGVkXQ0KDQoNCjkuMiBERG9TIENvbnNpZGVyYXRp b25zDQoNCg0KW0NvbnRlbnQgdG8gYmUgYWRkZWRdDQoNCg0KMTAuIEhhY2tlciBPcHBvcnR1 bml0aWVzDQoNCg0KQ29uc2lkZXIgd2hlbiBhIHNlcnZlciB1cGRhdGUgaGFzIHBhc3NlZCBh bGwgZm9ybXMgb2YgY3J5cHRvZ3JhcGhpYyBhbmQgcHJvdG9jb2wgZGVmZW5zZXMuIEEgY3Jp dGljYWwgcXVlc3Rpb24gaXMgd2hlbiB0aGUgc2VydmVyIHRpbWUgaXMgaW50ZW50aW9uYWxs eSBkaXNydXB0ZWQgaW4gb3JkZXIgdG8gZGVzdGFiaWxpemUgdGhlIGNsaWVudCBjbG9jay4g VGhlcmUgYXJlIHNldmVyYWwgbXV0dWFsbHkgZXhjbHVzaXZlIGhhY2tlciBvcHBvcnR1bml0 aWVzIGRlc2NyaWJlZCBiZWxvdy4NCg0KDQoxMC4xIFN0b3AgQXR0YWNrDQoNCg0KSW4gYSBz dG9wIGF0dGFjaywgdGhlIHNlcnZlciBzaW1wbHkgc3RvcHMgb3BlcmF0aW5nLiBUaGUgcmVz dWx0IGlzIHRoYXQgdGhlIGNsaWVudCBjbG9jayBjb250aW51ZXMgYXQgaXRzIGludHJpbnNp YyB0aW1lIGFuZCBmcmVxdWVuY3kuIElmIHRoZSBmcmVxdWVuY3kgaXMgZmFyIGZyb20gbm9t aW5hbCwgdGhlIGNsaWVudCBjbG9jayBlcnJvciB3aWxsIGdyb3cgd2l0aG91dCBib3VuZC4N Cg0KDQoxMC4yIFBhbmljIEF0dGFjaw0KDQoNCkluIGEgcGFuaWMgYXR0YWNrLCB0aGUgc2Vy dmVyIGNsb2NrIG9mZnNldCBpcyBncmVhdGVyIHRoYW4gdGhlIHBhbmljIHRocmVzaG9sZCwg dXN1YWxseSA5MDAgc2Vjb25kcy4gSW4gdGhpcyBzY2VuYXJpbyB0aGUgY2xpZW50IGNsb2Nr IGlzIHN0ZXBwZWQgdG8gc29tZSBsYXJnZSBvZmZzZXQgZ3JlYXRlciB0aGFuIHRoZSBwYW5p YyB0aHJlc2hvbGQuIElmIGl0IGlzIHRoZSBmaXJzdCB1cGRhdGUsIHRoZSBjbGllbnQgY2xv Y2sgaXMgc3RlcHBlZCB0byB0aGUgYXBwYXJlbnQgdGltZSBhbmQgb3BlcmF0aW9uIGNvbnRp bnVlcyB3aXRoIHRoaXMgdGltZS4gVGhpcyBpcyBvZnRlbiB0aGUgY2FzZSBhdCBjbGllbnQg c3RhcnR1cCB3aXRoIG5vIHJlYWwgdGltZSBjbG9jayBoYXJkd2FyZS4gSWYgaXQgaXMgbm90 IHRoZSBmaXJzdCB1cGRhdGUsIHRoZSBjbGllbnQgc3RvcHMgdGhlIE5UUCBwcm9ncmFtIHdp dGggYSBsb2cgZW50cnkgYW5kIG9wZXJhdG9yIHdhcm5pbmcuIElmIHRoaXMgaGFwcGVucywg dGhlIGluZXhwZXJpZW5jZWQgb3BlcmF0b3Igc2ltcGx5IHJlc3RhcnRzIHRoZSBwcm9ncmFt IGFuZCB0aGUgZXZpbCBzdGVwIG9jY3VycyBhbnl3YXkuIFRoaXMgY2FuIGRlc3RhYmlsaXpl IHRoZSBjbGllbnQgYXBwbGljYXRpb25zIGluIG1hc3NpdmUgd2F5cy4NCg0KDQoxMC4zIFN0 ZXAgQXR0YWNrDQoNCg0KSW4gYSBzdGVwIGF0dGFjaywgdGhlIGNsaWVudCBjbG9jayBpcyBz dGVwcGVkIGxlc3MgdGhhbiB0aGUgcGFuaWMgdGhyZXNob2xkLCBidXQgZ3JlYXRlciB0aGFu IHRoZSBzdGVwIHRocmVzaG9sZCwgdXN1YWxseSAxMjggbWlsbGlzZWNvbmRzLiBUaGUgc2Vy dmVyIGNvbnRpbnVlcyBpbiB0aGlzIHdheSBmb3IgdGhlIHN0ZXBvdXQgdGhyZXNob2xkLCB1 c3VhbGx5IDkwMCBzZWNvbmRzLiBBZnRlciB0aGlzLCB0aGUgbmV4dCB1cGRhdGUgd2lsbCBz dGVwIHRoZSBjbGllbnQgY2xvY2sgYnkgdGhlIHNlcnZlciB1cGRhdGUuIFRoZSBjbGV2ZXIg dGVycm9yaXN0IGNhbiByZXBlYXQgdGhpcyB3aXRoIGRpZmZlcmVudCBvZmZzZXRzLCBjYXVz aW5nIHRoZSBjbGllbnQgY2xvY2sgdG8gb3NjaWxsYXRlIHdpbGRseS4NCg0KDQoxMC40IFN3 aXNoIEF0dGFjaw0KDQoNCkluIGEgc3dpc2ggYXR0YWNrLCB0aGUgc2VydmVyIHVzZXMgb2Zm c2V0cyBsZXNzIHRoYW4gdGhlIHN0ZXAgdGhyZXNob2xkIGJ1dCBhZGRzIG9yIHN1YnRyYWN0 cyBpbmNyZWFzaW5nIG9mZnNldHMuIFRoZSBjbG9jayBldmVudHVhbGx5IHJlYWNoZXMgYW5k IGhvbGRzIGF0IHRoZSBtYXhpbXVtIGZyZXF1ZW5jeSwgY3VycmVudGx5IDUwMCBwYXJ0cyBw ZXIgbWlsbGlvbi4NCg0KDQoxMS4gSW1wbGVtZW50YXRpb24gU3VnZ2VzdGlvbnMNCg0KDQpK dWRnaW5nIGZyb20gZGV2ZWxvcG1lbnQgZXhwZXJpZW5jZSwgdGlua2VyaW5nIHdpdGggcHJv dG9jb2wgZGVzaWduIGNhbiBiZSB0ZWRpb3VzLiBUaGUgZGFuY2VzIGludGVyYWN0IHdpdGgg dGhlIHRpbWVvdXQgYW5kIHJhdGUgbWFuYWdlbWVudCBmdW5jdGlvbnMsIHdoaWxlIGV4Y2hh bmdlcyBtYXkgZWl0aGVyIHRpbWVvdXQgb3IgcmVzdWx0IGluIGVycm9yLiBDdXJyZW50IGFu ZCB1c2VmdWwgZmVhdHVyZXMgb2YgdGhlIHJlZmVyZW5jZSBpbXBsZW1lbnRhdGlvbg0KbWF5 IGJlIGxvc3QgaW4gYSBuZXcgaW1wbGVtZW50YXRpb24uIFRoZSBlZmZlY3RpdmUgYXBwcm9h Y2ggbWF5IGJlIHRvIGV2aXNjZXJhdGUgdGhlIGN1cnJlbnQgQXV0b2tleSBwcm92aXNpb25z IGluIHRoZSByZWZlcmVuY2UgaW1wbGVtZW50YXRpb24gYW5kIHJlcGxhY2Ugd2l0aCB0aGUg YWJvdmUgZGVzaWduLiBUaGlzIG1heSBub3QgYmUgYXMgZGlmZmljdWx0IGFzIGl0IHNlZW1z LiBUaGUgZmlyc3Qgc3RlcCBpcyB0byByZW1vdmUgYWxsIGV4dGVuc2lvbiBmaWVsZCByZWZl cmVuY2VzIHRvIGFzc29jaWF0aW9uIElELCB0aW1lc3RhbXBzIGFuZCBmaWxlc3RhbXBzLiBO b3RlIHRoYXQgdGhlIHByb2dyZXNzaW9uIG9mIGV4Y2hhbmdlcyBpcyBub3QgY2hhbmdlZC4g VGhlIG5leHQgc3RlcCBpcyB0byBpbXBsZW1lbnQgdGhlIGNvb2tpZSBhbmQgREggYWdyZWVt ZW50IGFsZ29yaXRobXMgYXMgZGVzY3JpYmVkIGFib3ZlLiBUaGUgZmluYWwgc3RlcCBpcyB0 byByZW1vdmUgYWxsIHJlZmVyZW5jZXMgdG8gdGhlIFNLRVkgc2NoZW1lIGFuZCByZXBsYWNl IHdpdGggdGhlIHNpZ25hdHVyZSBzY2hlbWUgYXMgZGVzY3JpYmVkLg0KDQoNCjEyLiBBbHRl cm5hdGl2ZSBNb2RlbHMNCg0KDQpBcyBhbiBhc2lkZSwgQVNOLjEgZW5jb2Rpbmcgb2YgZXh0 ZW5zaW9uIGZpZWxkcyBpcyBwcm9iYWJseSBub3QgYSBnb29kIGlkZWEuIEhvd2V2ZXIsIEFT Ti4xIGlzIGFwcHJvcHJpYXRlIGZvciBwYXJhbWV0ZXIgZGF0YS4gQWxsIG90aGVyIGV4dGVu c2lvbiBmaWVsZHMgdXNlIG9ubHkgb3BhcXVlIG9jdGV0IHN0cmluZ3MuIEV2ZW4gQVNOLjEg ZW5jb2RlZCBkYXRhLCBzdWNoIGFzIGNlcnRpZmljYXRlcywgYXJlIHRyYW5zbWl0dGVkIGFz IGZsYXQgb3BhcXVlIGJpdCBzdHJpbmdzLg0KDQoNClRMUy9UQ1AsIERUTFMvVURQIG9yIGNv bWJpbmF0aW9ucyBvZiB0aGVzZSBtaWdodCBiZSBhIGdvb2QgYWx0ZXJuYXRlIGFwcHJvYWNo LiBUaGUgbW90aXZhdGlvbiBmb3IgdGhpcyBhcHByb2FjaCBpcyB0byB1c2UgZXhpc3Rpbmcg cHVibGljIHNlY3VyaXR5IHNjaGVtZXMgdG8gYXV0aGVudGljYXRlIE5UUCBwYWNrZXRzLiBU aGlzIGFwcHJvYWNoIHJlcXVpcmVzIGEgcHVibGljIHNvZnR3YXJlIHByb3RvY29sIHN0YWNr IG9yIGxpYnJhcnkuIEJlc2lkZXMgZm9ybWluZyBhbiBhZGRpdGlvbmFsIHRhcmdldCBmb3Ig aG9zdGlsZSBhdHRhY2ssIHRoZSB0aW1lIGFuZCByZXNvdXJjZXMgcmVxdWlyZWQgbWF5IGJl IGJ1cmRlbnNvbWUgYW5kIHJlc3VsdCBpbiBzaWduaWZpY2FudCBsb3NzIG9mIHRpbWVrZWVw aW5nIGFjY3VyYWN5Lg0KDQoNCkluIHRoZSBjYXNlIG9mIFRMUy9UQ1AsIHRoZSBUQ1AgcHJv dG9jb2wgZGVzaWduIGlzIGF0IG9kZHMgd2l0aCB0aGUgTlRQIGRhdGFncmFtIHN0cnVjdHVy ZSBhbmQgcmF0ZSBtYW5hZ2VtZW50IHByaW5jaXBsZXMuIEluIGFkZGl0aW9uLCBUQ1AgcmVx dWlyZXMgYSBmb3JtYXQgbGF5ZXIgdGhhdCBpZGVudGlmaWVzIHBhY2tldCBib3VuZGFyaWVz Lg0KDQoNCldoaWxlIFRDUCBwcm92aWRlcyByZWxpYWJsZSBkZWxpdmVyeSwgcmV0cmFuc21p c3Npb25zIHJlbmRlciBOVFAgdGltZXN0YW1wcyBlc3NlbnRpYWxseSB1c2VsZXNzLiBUaGUg TlRQIHBhY2tldCByYXRlIGxpbWl0IG1vZGVsIGlzIGF0IG9kZHMgd2l0aCB0aGUgVENQIGFy Y2hpdGVjdHVyZSwgd2hlcmUgdGhlIHJlc291cmNlcyB0byBjb25zZXJ2ZSBhcmUgYnVmZmVy cyBhbmQgZGF0YSBmbG93IG1hbmFnZW1lbnQuDQoNCg0KVGhlIFRDUCBtb2RlbCByZXF1aXJl cyBib3RoIHNlcnZlciBhbmQgY2xpZW50IHRvIG1haW50YWluIHByb3RvY29sIHN0YXRlLCB3 aGljaCBpcyBub3QgcHJhY3RpY2FsIGluIGEgc3RhdGVsZXNzIHNlcnZlciBhcmNoaXRlY3R1 cmUuIEl0IGFsc28gcmVxdWlyZXMgY29weWluZyBOVFAgcGFja2V0cyB0byBpbnRlcm5hbCBi dWZmZXJzIGFuZCB0aGVuIGNvcHlpbmcgZGF0YSBmcm9tIHRoZXNlIGJ1ZmZlcnMgdG8gTlRQ IG1lc3NhZ2VzLiBUaGUgb3ZlcmhlYWQgaW4gdGhlc2UgYWN0aW9ucyB3b3VsZCBvdmVyd2hl bG0gYSBwcm9jZXNzb3IgZmFjZWQgd2l0aCBhIHN3YXJtIG9mIDMwMDAgTlRQIHBhY2tldHMg cGVyIHNlY29uZC4gRmluYWxseSwgdGhlIFRMUy9UQ1AgcHJvdG9jb2wgb3ZlcmhlYWQgcmVx dWlyZXMgdXAgdG8gc2V2ZW4gY29udHJvbCBwYWNrZXRzIGluIGFkZGl0aW9uIHRvIHRoZSBk YW5jZSBwYWNrZXRzLCB3aGlsZSBvYmV5aW5nIHRoZSByYXRlIGNvbnN0cmFpbnRzLiBUaGUg aW5ldml0YWJsZSBjb25jbHVzaW9uIGlzIHRoYXQgYW55IHNlY3VyaXR5IG1vZGVsIGJhc2Vk IG9uIFRDUCBpcyBpbmFwcHJvcHJpYXRlIGZvciBkaXJlY3QgdXNlIGJ5IE5UUC4gW0RJU0NV U1NdDQoNCg0KRFRMUy9VRFAgYXQgZmlyc3QgZ2xhbmNlIHNlZW1zIGEgbXVjaCBiZXR0ZXIg c2VjdXJpdHkgcHJvdG9jb2wgZm9yIE5UUCB0aGFuIFRMUy9UQ1AgZHVlIHRvIGl0cyBpbnRy aW5zaWMgc3RydWN0dXJlIGJhc2VkIG9uIGRhdGFncmFtIHByaW5jaXBsZXMuIEhvd2V2ZXIs IGluIHRoaXMgcHJvdG9jb2wsIHRoZSBiYXNpYyBOVFAgaGVhZGVyIGFuZCBleHRlbnNpb24g ZmllbGRzIGFyZSBlbWJlZGRlZCBpbiB0aGUgRFRMUy9VRFAgcmVjb3JkIHByb3RvY29sLCB3 aGljaCByZXF1aXJlcyBjb3B5aW5nLCBhcyBpbiBUTFMvVENQLiBUaGlzIHJlc3VsdHMgaW4g Y29uc2lkZXJhYmxlIG92ZXJoZWFkIGFuZCBsb3NzIG9mIHRpbWVzdGFtcCBhY2N1cmFjeS4N Cg0KDQpUaGUgaGFuZHNoYWtlIHByb3RvY29sIGlzIG5vdCB3ZWxsIHByb3RlY3RlZCwgYnV0 IHRoZSBrZXkgemVybyBzY2hlbWUgY291bGQgcmVzb2x2ZSB0aGlzIHByb2JsZW0uIEhvd2V2 ZXIsIHRoZSByZWNvcmQgcHJvdG9jb2wgY291bGQgYmUgYXZvaWRlZCBpZiB0aGUgSS9PIGJ1 ZmZlciBjb250YWlucyB0aGUgY29tcGxldGUgcGFja2V0IC0gTlRQIGhlYWRlciwgUERVcyBh bmQgTUFDLiBUaGlzIGlzIGFuIGV4YW1wbGUgb2YgdGhlICJjb3B5IG9ubHkgb25jZSIgcHJp bmNpcGxlLCB3aGljaCBpcyBhZG9wdGVkIGluIHRoZSBhYm92ZSBwcm9wb3NhbCBhcyB3ZWxs Lg0KDQoNCkl0IHdvdWxkIGJlIGEgc2hvd3N0b3BwZXIgcHJvYmxlbSBpZiBEVExTL1VEUCB3 YXMgbGltaXRlZCB0byBjbGllbnQvc2VydmVyIG1vZGUuIFRoaXMgZG9jdW1lbnQgaXMgY2Fy ZWZ1bGx5IGNyYWZ0ZWQgdG8gaW5jbHVkZSBzeW1tZXRyaWMgbW9kZS4gSW4gcHJpbmNpcGxl LCB0aGUgb25seSBkaWZmZXJlbmNlIGJldHdlZW4gdGhlc2UgbW9kZXMgaXMgaW4gdGhlIGFn cmVlbWVudCBwaGFzZSBvZiB0aGUgY29va2llIGV4Y2hhbmdlLiBUaGUgbmVlZCB0byBhc3Nl bWJsZSBEVExTIGhlYWRlcnMgYW5kIHRyYWlsZXJzLCBhbmQgTlRQIHBhY2tldHMgaW4gcmVj b3JkcyBtYXkgcmVxdWlyZSBjb3B5aW5nIGRhdGEgaW4gYnVmZmVycywgcmVzdWx0aW5nIGlu IGZ1cnRoZXIgb3ZlcmhlYWQuIFRoZSBEVExTL1VEUCBoYW5kc2hha2UgcHJvdG9jb2wgY291 bGQgYmUgdXNlZCB3aXRob3V0IHRoZSByZWNvcmQgbGF5ZXIuDQoNCg0KRm9yIHRoZSBiZXN0 IGFjY3VyYWN5LCB0aGUgb24td2lyZSB0aW1lc3RhbXBzIHNob3VsZCBiZSBpbXBsZW1lbnRl ZCBhcyBjbG9zZSBhcyBwb3NzaWJsZSB0byB0aGUgZW5kIG9mIHBhY2tldCBoYXJkd2FyZSBp bnRlcnJ1cHQuIFRoZSByZWZlcmVuY2UgaW1wbGVtZW50YXRpb24gZG9lcyB0aGlzIGJ5IGFu IGludHJpY2F0ZSBzY2hlbWUgaW52b2x2aW5nIHRoZSBVbml4IGludGVycnVwdCBxdWV1ZSBh bmQgcmVjb3JkaW5nIG9mIHRoZSB0aW1lc3RhbXAgaW4gdGhlIGlucHV0IHBhY2tldCBidWZm ZXIuIEluIHRoZSBEVExTL1VEUCBtb2RlbCwgdGhlIGJ1ZmZlciBpcyB0aGVuIHBhc3NlZCB0 byB0aGUgRFRMUy9VRFAgcmVjb3JkIHByb3RvY29sLCB3aGljaCBtaWdodCBub3QgcHJlc2Vy dmUgdGhlIHRpbWVzdGFtcC4gVGhpcyB3b3VsZCBiZSBwb3NzaWJsZSBvbmx5IHdpdGggY29u c2lkZXJhYmxlIG1vZGlmaWNhdGlvbnMgdG8gdGhlIERUTFMvVURQIHB1YmxpYyBzb2Z0d2Fy ZSBkaXN0cmlidXRpb24uDQoNCg0KVG8gY29udGludWUgc3VwcG9ydCBmb3IgdGhlIG5vbi1h dXRoZW50aWNhdGVkIHByb3RvY29sIGFuZCB0aGUgYXV0aGVudGljYXRlZCBrZXlzIGZpbGUg bW9kZWwsIHRoZSBOVFAgcG9ydCBtdXN0IGJlIDEyMyBhcyByZXF1aXJlZCBmb3IgaGlzdG9y aWMgb3BlcmF0aW9ucy4gVGhlcmVmb3JlLCBhIG5ldyBEVExTL1VEUCBzZWN1cml0eSBwcm90 b2NvbCBtdXN0IGJlIHN1cHBvcnRlZCBvbiBhIGRpZmZlcmVudCBwb3J0LiBbRElTQ1VTU10N Cg0KDQpUaGUgdXNlIG9mIERUTFMgb24gYSBwb3J0IG90aGVyIHRoYW4gMTIzIGNhbiBzdXBw b3J0IHNlZ21lbnRhdGlvbiBhbmQgcmVhc3NlbWJseSBmb3IgdGhlIGhhbmRzaGFrZSBwcm90 b2NvbCBidXQgcmVzdWx0IGluIHVzZWxlc3MgdGltZXN0YW1wcy4gVGhlIHJlYWwga2lsbGVy IGluIGEgRFRMUy9VRFAgZGVzaWduIGlzIHdoYXQgdG8gZG8gYWJvdXQgZnJhZ21lbnRhdGlv biBhbmQgcmVhc3NlbWJseS4gQXBwYXJlbnRseSwgdGhlIGN1cnJlbnQgc2VjdXJpdHkgaW5m cmFzdHJ1Y3R1cmUgcmVxdWlyZXMgY2VydGlmaWNhdGVzIG9mIG92ZXIgNTAwMCBvY3RldHMs IHdoaWNoIHJlcXVpcmUgbXVsdGlwbGUgZnJhZ21lbnRzIG5vdCBncmVhdGVyIHRoYW4gdGhl IDE1MDAtb2N0ZXQgTVRVLiBEVExTL1VEUCBzb2x2ZXMgdGhpcyBwcm9ibGVtIGJ5IGZyYWdt ZW50YXRpb24gYW5kIHJlYXNzZW1ibHkgYnV0IHJlc3VsdHMgaW4gdW5hY2NlcHRhYmxlIGxv c3Mgb2YgdGltZWtlZXBpbmcgYWNjdXJhY3kuIFRoZSBtb3N0IGVmZmVjdGl2ZSBzb2x1dGlv biBpcyB0byByZXF1aXJlIGNlcnRpZmljYXRlcyB0byBiZSBsZXNzIHRoYW4gdGhlIE1UVSBv ZiAxNTAwIG9jdGV0cy4gSXQgaXMgbm90IGNsZWFyIHdoeSBzdWNoIGxhcmdlIHBhY2tldHMg YXJlIHJlcXVpcmVkIGJ1dCB0aGUgc2ltcGxlIG9ic2VydmF0aW9uIGlzIHRoYXQgY2VydGlm aWNhdGVzIGZvciBOVFAgc2VjdXJpdHkgbmVlZCBub3QgYmUgYXMgcm9idXN0IGFzIG5lZWRl ZCBmb3Igd2ViIGJyb3dzaW5nLg0KDQoNCjEzLiBQYXJ0aW5nIFNob3RzDQoNCg0KV2l0aCBy ZXNwZWN0IHRvIHRoZSBOVFAgbW9kZWwgaW4gUkZDNTkwNSwgdGhlIHByb3Bvc2VkIHByb3Rv Y29sIGluIHRoZSBOVFMgYW5kIE5UUCBkb2N1bWVudHMgc2VlbSBhdCBvZGRzLiBUaGUgTlRT IHNjaGVtZSBtYWtlcyBubyBkaXN0aW5jdGlvbiBiZXR3ZWVuIGNsaWVudC9zZXJ2ZXIgYW5k IHN5bW1ldHJpYyBtb2RlcywgYXMgc3ltbWV0cmljIG1vZGUgZG9lcyBpbmRlZWQgaGF2ZSBz dGF0ZS4gVGhlIHByb3Bvc2VkIE5UUyBicm9hZGNhc3Qgc2NoZW1lIHJlcXVpcmVzIGEgdHdv LXdheSBtZXNzYWdlIHBhdGgsIHdoaWNoIGlzIG5vdCBhIHJlcXVpcmVtZW50IGluIHRoZSBO VFAgbW9kZWwuIFdoaWxlIHRoZSBwcm9wb3NlZCBOVFMgc2NoZW1lIGNvdWxkIGJlIGEgY29u ZmlndXJhdGlvbiBvcHRpb24sIHRoZSBwcm9wb3NlZCBzY2hlbWUgaW4gdGhpcyBkb2N1bWVu dCBpcyBhIG5lY2Vzc2l0eSBmb3IgdGhlIG9uZS13YXkgY29uZmlndXJhdGlvbi4NCg0KDQpP biB0aGUgb3RoZXIgaGFuZCwgdGhlIHByb3Bvc2VkIE5UUyBzY2hlbWUgc2VlbXMgd2hvbGx5 IGFwcHJvcHJpYXRlIGZvciBhbiBhcHBsaWNhdGlvbiBzdWNoIGFzIHRoZSBJUCBUSU1FIG9y IFNOVFAgcHJvdG9jb2wsIHdoZXJlIHRoZXJlIGlzIG5vIG9uLXdpcmUgcHJvdG9jb2wgbGF5 ZXIuIFdpdGggTlRQLCB0aGlzIGxheWVyIGF2b2lkcyB0aGUgbmVlZCBmb3IgZXhwbGljaXQg bm9uY2UgYW5kIHNlc3Npb24ga2V5cy4NCg0KDQpUaGVyZSBhcmUgc29tZSB3YXJ0cyBpbiB0 aGUgcmVmZXJlbmNlIGltcGxlbWVudGF0aW9uIGFuZCBwcm9wb3NlZCBwdWJsaWMga2V5IHNj aGVtZXMuIFRoZXJlIG1pZ2h0IGJlIG90aGVyIHdheXMgdG8gdmFsaWRhdGUgdGhlIGNlcnRp ZmljYXRlIHRyYWlsIG90aGVyIHRoYW4gdGhlIElGRiB6ZXJvLWtub3dsZWRnZSBzY2hlbWUu DQoNCg0KQXMgaW4gYWxsIGNyeXB0b2dyYXBoaWMgc2NoZW1lcywgcHJvdmlzaW9ucyBtdXN0 IGJlIG1hZGUgdG8gcmVmcmVzaCB0aGUga2V5IG1hdGVyaWFsLiBBcyBzdWdnZXN0ZWQgYWJv dmUsIHRoZSBzZWNyZXQga2V5IG9mIHRoZSBzZXJ2ZXIgc2hvdWxkIGJlIHJlZnJlc2hlZCBh Ym91dCBvbmNlIHBlciBkYXkuIEZvciBtb3JlIGRpc3J1cHRpb24gZHVlIHRvIGNlcnRpZmlj YXRlIHVwZGF0ZXMsIHRoZSBwcmVzZW50IGRlc2lnbiBkb2VzIHRoaXMgYnkgc2h1dHRpbmcg ZG93biBhbmQNCnRoZW4gcmVzdGFydGluZyBhbGwgYXNzb2NpYXRpb25zIG9uY2UgcGVyIHdl ZWsuIE1vcmUgc29waGlzdGljYXRlZCBzY2hlbWVzIG1pZ2h0IGJlIGRldmlzZWQuDQoNCg0K T2NjYXNpb25hbCBjb2xsaXNpb25zIHdvdWxkIGJlIGV4cGVjdGVkIGluIHN5bW1ldHJpYyBt b2RlLiBUaGlzIHdvdWxkIGhhcHBlbiB3aGVuIGJvdGggcGVlcnMgc3RhcnQgdGhlIHByb3Rv Y29sIGF0IHRoZSBzYW1lIHRpbWUuIFRoaXMgY2FuIGJlIGF2b2lkZWQgdXNpbmcgYSByYW5k b20gZGVsYXkgYXQgYXNzb2NpYXRpb24gc3RhcnR1cCwgYXMgZGVzY3JpYmVkIHByZXZpb3Vz bHkgaW4gdGhpcyBkb2N1bWVudC4NCg0KDQpJYnVyc3QgaGFzIGJlZW4gZGlzY291cmFnZWQg aW4gc3ltbWV0cmljIG1vZGUsIGJlY2F1c2Ugb2YgdGhlIGluY3JlYXNlZCByaXNrIG9mIGNv bGxpc2lvbnMgaWYgYm90aCBzaWRlcyBhcmUgbm90IHJlYWR5LiAgU3ltbWV0cmljIG1vZGUg aWJ1cnN0IHNob3VsZCBiZSBzYWZlIGFzIGxvbmcgYXMgaXQgaXMgb25seSBpbml0aWF0ZWQg YWZ0ZXIgdGhlIG90aGVyIHNpZGUgaGFzIHJlc3BvbmRlZCB0byBhbiBhY3RpdmUtbW9kZSBy ZXF1ZXN0Lg0KDQoNCldoaWxlIG5vdCBleHBsb3JlZCwgdGhlIHByb3RvY29sIG1pZ2h0IG5v dCBlc3RhYmxpc2ggYSBwcm9wZXIgaGFuZHNoYWtlIG9uIHRoZSBmaXJzdCB0cnkuICBIb3dl dmVyIGl0IHNob3VsZCBiZWNvbWUgc3RhYmlsaXplZCBhZnRlciBhdCBtb3N0IGEgZmV3IHJl c3RhcnRzLiBBIHNpbXVsYXRpb24gZXhlcmNpc2UsIGFzIGluIHByZXZpb3VzIGRvY3VtZW50 cywgY291bGQgcmVzb2x2ZSB0aGVzZSBpc3N1ZXMu --------------3C4BF6836A7A9E69A9AB312E-- From ntp-bounces@ietf.org Sun Aug 20 19:41:16 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B7C0132360; Sun, 20 Aug 2017 19:41:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1503283276; bh=MmuVvNlhM+mX+fzRtU7j8fq3a1OYNDnJyk5KUctAPHQ=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=aG8zYE8e25pIh6MkH3KuqKQSH2EPXZkXOuXTAIB3QTbkQLvdX+dxDTmA9bFuA3yZ+ 2Wj1xNXQS1WggZxxZRPNOx3Sc8087OxkFAn4gLZwF4E86bPlyUM3mYSp8VzAGK5wcB gy0j8dEBj1lJd4Ikg0wBDv55pkc2PTYt46GJT5K4= 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 461E413233D for ; Sun, 20 Aug 2017 19:41:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 vXsp2BPqnH0J for ; Sun, 20 Aug 2017 19:41:05 -0700 (PDT) Received: from chessie.everett.org (chessie.everett.org [IPv6:2001:470:1:205::234]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99B11132334 for ; Sun, 20 Aug 2017 19:41:05 -0700 (PDT) Received: from [10.66.3.3] (96-41-166-181.dhcp.mdfd.or.charter.com [96.41.166.181]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by chessie.everett.org (Postfix) with ESMTPSA id 2F0D6B869; Mon, 21 Aug 2017 02:41:05 +0000 (UTC) To: ntp@ietf.org From: Harlan Stenn Message-ID: Date: Sun, 20 Aug 2017 19:41:06 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------3C4BF6836A7A9E69A9AB312E" Content-Language: en-US Archived-At: Subject: [Ntp] NTS/Updated Autokey X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ntp-bounces@ietf.org Sender: "ntp" This is a multi-part message in MIME format. --------------3C4BF6836A7A9E69A9AB312E Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Dave has been working on an evaluation of the NTS proposal. We've been discussing this document in our internal NTS implementation meetings, and Dieter asked me to send this to the WG mailing list. Dave updated the document after my last go-round, so I just took his new version and integrated his changes with the ones we made. I'll be working on my WGLC comments separately. -- Harlan Stenn, Network Time Foundation http://nwtime.org - be a Member! --------------3C4BF6836A7A9E69A9AB312E Content-Type: text/plain; charset=UTF-8; name="Autokey-20170815.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Autokey-20170815.txt" 77u/RW5naW5lZXJpbmcgYW5kIFNlY3VyaXR5IGZvciB0aGUgTmV0d29yayBUaW1lIFByb3Rv Y29sIChOVFApDQpEYXZpZCBMLiBNaWxscw0KMTUgQXVndXN0LCAyMDE3DQoNCg0KQWJzdHJh Y3QNCg0KDQpUaGlzIGRvY3VtZW50IGV4cGxvcmVzIHRoZSBzZWN1cml0eSBhcmNoaXRlY3R1 cmUgYW5kIHByb3RvY29scyBmb3IgdGhlIG5ldHdvcmsgdGltZSBwcm90b2NvbCBOVFAuICBJ dCBwcm9wb3NlcyBhIHNldCBvZiBlbmdpbmVlcmluZyBwcmluY2lwbGVzIGJhc2VkIG9uIFJG QzU5MDUsIGFsb25nIHdpdGggYSByZWRlc2lnbiBvZiB0aGUgQXV0b2tleSBzY2hlbWUgZGVz Y3JpYmVkIGluIFJGQzU5MDYuDQoNCg0KVGhlIG5ldyBwcm90b2NvbCBpcyBtb3JlIHJlc2lz dGFudCB0byBwcm90b2NvbCBlcnJvcnMgYW5kIGtleSByZXBsYWNlbWVudC4gVGhlIHByb3Rv Y29sIGludm9sdmVzIHZhcmlvdXMgYWdyZWVtZW50IGFuZCBzaWduYXR1cmUgYWxnb3JpdGht cyBsZWFkaW5nIHRvIGEgc2VjdXJlIG1lYW5zIGZvciBwcm90ZWN0aW5nIE5UUCBmcm9tIHdp cmV0YXAgYW5kIG1pZGRsZW1hbiBhdHRhY2suIFRoZSBuZXcgcHJvdG9jb2wgaGFzIHR3byBh ZHZhbnRhZ2VzOiBhIGNvbXBhY3Qgc2lnbmF0dXJlIHRyYWlsIHRoYXQgYXZvaWRzIGEgY2Vy dGlmaWNhdGUgY2FjaGUgYW5kIGEgaGFzaCBzY2hlbWUgdGhhdCB3b3JrcyBmb3IgYWxsIHBh Y2tldHMsIGluY2x1ZGluZyB0aGUgaGFuZHNoYWtlIHBhY2tldHMuDQoNCg0KMS4gSW50cm9k dWN0aW9uDQoNCg0KUmVjZW50IGludGVybmV0IGRyYWZ0cyBbbGlzdF0gaGF2ZSBkZXNjcmli ZWQg4oCcTmV0d29yayBUaW1lIFNlY3VyaXR54oCdIChOVFMpLCBhIHNlY3VyaXR5IGFyY2hp dGVjdHVyZSBtb2RlbCB0b2dldGhlciB3aXRoIGl0cyBhcHBsaWNhdGlvbiB0byBOVFAuIFRo aXMgbW9kZWwsIHdoaWxlIHRlY2huaWNhbGx5IHNvdW5kLCBoYXMgc2lnbmlmaWNhbnQgcHJv YmxlbXMgd2l0aCB0aGUgY3VycmVudCBOVFAgYXJjaGl0ZWN0dXJlIG1vZGVsIGFzIGRlc2Ny aWJlZCBpbiBSRkM1OTA1LiBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBob3cgYW5kIHdoeSB0 aGUgdHdvIGFyY2hpdGVjdHVyZSBtb2RlbHMgZGlmZmVyIGFuZCBob3cgY2VydGFpbiBjaGFu Z2VzIG1pZ2h0IG1pdGlnYXRlIHRoZSBwcm9ibGVtcyB3aXRoIHRoZSBOVFMgbW9kZWwuDQoN Cg0KT25lIG9mIHRoZSBtb3N0IGltcG9ydGFudCBpc3N1ZXMgZHVyaW5nIHRoZSB0d28gZGVj YWRlcyBvZiBOVFAgc2VjdXJpdHkgZGV2ZWxvcG1lbnQgaGFzIGJlZW4gdG8gZGVzaWduIHRo ZSBzZWN1cml0eSBtZWFucyBhcyBhbiBpbnRlZ3JhdGVkIHN5c3RlbS4gVGhpcyBpbnZvbHZl cyBjYXJlZnVsIGNvbnNpZGVyYXRpb24gb24gdGltZW91dHMsIHByb3RvY29sIHJlc3RhcnRz IGFuZCBlcnJvciByZWNvdmVyeS4gRXZlcnl0aGluZyBkZXBlbmRzIG9uIGV2ZXJ5dGhpbmcg ZWxzZSwgYW5kIGEgdGlueSBjaGFuZ2UgbWF5IGhhdmUgdW5pbnRlbmRlZCBjb25zZXF1ZW5j ZXMuDQoNCg0KVGhpcyBkb2N1bWVudCBhdHRlbXB0cyB0byBjb250aW51ZSB0aGUgZXZvbHV0 aW9uIG9mIHRoZSBOVFAgc2VjdXJpdHkgbW9kZWwuIEl0IG1heSBiZSB0aGF0IGxlc3NvbnMg aW4gdGhpcyBkb2N1bWVudCBhcmUgbm90IHVzZWZ1bCB0byB0aGUgTlRQIG5ldHdvcmtpbmcg Y29tbXVuaXR5LCBidXQgaW4gYW55IGNhc2UgdGhleSBjYW4gYmUgdXNlZnVsIGFzIGEgc2Fu aXR5IGNoZWNrLg0KDQoNCkluIGFkZGl0aW9uLCB0aGUgQXV0b2tleSBwdWJsaWMga2V5IHNl Y3VyaXR5IHNjaGVtZSBkZXNjcmliZWQgaW4gUkZDNTkwNiB3YXMgZGVzaWduZWQgYW5kIGlt cGxlbWVudGVkIG92ZXIgdHdlbnR5IHllYXJzIGFnby4gVGltZSBhbmQgTW9vcmUncyBsYXcg aGF2ZSBjYXVnaHQgdXAgdG8gaXQuIEJhY2sgdGhlbiwgaXQgdG9vayBvdmVyIG9uZSBzZWNv bmQgdG8gY2FsY3VsYXRlIGEgcHVibGljIGtleSBzaWduYXR1cmUuIFRvZGF5LCBpdCB0YWtl cyBvbmx5IGEgbWlsbGlzZWNvbmQgb3IgdHdvLg0KDQoNClRoaXMgZG9jdW1lbnQgb3V0bGlu ZXMgYSBwcm9wb3NlZCByZXBsYWNlbWVudCBmb3IgQXV0b2tleS4gVGhlIHNjaGVtZSBwcm9w b3NlZCBoZXJlIGlzIGJhc2VkIG9uIHRoZSBEaWZmaWUtSGVsbG1hbiBhZ3JlZW1lbnQgYWxn b3JpdGhtLCB3aGljaCByZXN1bHRzIGluIGFuIGVjb25vbWljYWwgaW1wbGVtZW50YXRpb24g YW5kIGxvdyBydW5uaW5nIHRpbWUuIFRoaXMgZG9jdW1lbnQgc3VnZ2VzdHMgYSB2YXJpYW50 IG9mIHRoaXMgYWxnb3JpdGhtIHBvcHVsYXJseSBrbm93biBhcyB0aGUgU3RhdGlvbi10by1T dGF0aW9uIFByb3RvY29sLg0KDQoNCkF1dG9rZXkgaW4gaXRzIHByZXNlbnQgZm9ybSBpcyBh biBvcHRpb25hbCBmZWF0dXJlIG9mIHRoZSByZWZlcmVuY2UgaW1wbGVtZW50YXRpb24uIElu IGZhY3QsIHRoZSBzaWduaWZpY2FudCBwcm9wb3NlZCBjaGFuZ2VzIGluIHRoaXMgZG9jdW1l bnQgYXJlIHRvIHRoZSBwdWJsaWMga2V5IGxheWVyLiBUaGUgb3RoZXIgcHJvdG9jb2wgbGF5 ZXJzIGluIHRoZSBkZXNpZ24sIGluY2x1ZGluZyB0aGUgZm9ybWF0LCBzeW1tZXRyaWMga2V5 IGFuZCBvbi13aXJlIGxheWVycywgYXJlIHN1YnN0YW50aWFsbHkgdW5jaGFuZ2VkLiBUaGUg c2NoZW1lIGFwcGVhcnMgYXMgYW4gYWdyZWVtZW50IGFsZ29yaXRobSBwYXJhc2l0aWMgb24g dGhlIG9uLXdpcmUgbGF5ZXIuIEl0IGRpc2FwcGVhcnMgd2hlbiBpdHMgZnVuY3Rpb24gaXMg YWNjb21wbGlzaGVkLg0KDQoNClRoaXMgZG9jdW1lbnQgZGlzY3Vzc2VzIGVuZ2luZWVyaW5n IGlzc3VlcyBpbXBvcnRhbnQgdG8gdGhlIHNlY3VyaXR5IGRlc2lnbi4gSXQgZG9lcyBub3Qg ZGlzY3VzcyBwYWNrZXQgZm9ybWF0cywgY3VycmVudCBhbmQgcHJvcG9zZWQgTlRQIGV4dGVu c2lvbiBmaWVsZCBmb3JtYXRzLCBvciBzdXBwb3J0aW5nIGtleSBnZW5lcmF0aW9uIG9yIGRp c3RyaWJ1dGlvbi4NCg0KDQpGb3IgdGhlIHB1cnBvc2VzIG9mIHRoaXMgZG9jdW1lbnQsIGEg cHJvdG9jb2wgZGF0YSB1bml0IChQRFUpIGlzIGFuIE5UUCBleHRlbnNpb24gZmllbGQsIHNv bWV0aW1lcyBjYWxsZWQgYSBtZXNzYWdlLiBPbmUgb3IgbW9yZSBtZXNzYWdlcyBjYW4gYmUg YXBwZW5kZWQgdG8gYW4gTlRQIHBhY2tldCBoZWFkZXIuIEVhY2ggbWVzc2FnZSBjb25zaXN0 cyBvZiBhIGZ1bmN0aW9uIG9jdGV0LCBtb2RpZmllciBvY3RldCwgdHdvIG9jdGV0cyBvZiBk YXRhIGxlbmd0aCwgYW5kIHRoZW4gdGhlIGRhdGEgaXRzZWxmLCB6ZXJvIHBhZGRlZCB0byBh IGZvdXItb2N0ZXQgYm91bmRhcnkuICBJdCBpcyBjb252ZW5pZW50IHRvIHJlc3RyaWN0IHRo ZSBtYXhpbXVtIGRhdGEgbGVuZ3RoIHRvIHNvbWUgcmVhc29uYWJsZSB2YWx1ZSBpbiB0aGUg b3JkZXIgb2YgMzIgdG8gNjQgb2N0ZXRzLiBPbmx5IG9uZSBwYWNrZXQgaW4gdGhlIHByb3Rv Y29sIGRlc2NyaWJlZCBoZXJlIGhhcyBtb3JlIHRoYW4gb25lIG1lc3NhZ2UgYW5kIHRoYXQg b25lIGhhcyB0d28gbWVzc2FnZXMuDQoNCg0KT3JkaW5hcmlseSwgdGhlIGZ1bmN0aW9uIG9j dGV0IGZvciBib3RoIHRoZSByZXF1ZXN0IGFuZCByZXNwb25zZSBtZXNzYWdlcyBpcyB0aGUg c2FtZTsgYSBiaXQgaXMgYWxsb2NhdGVkIGluIHRoZSBmdW5jdGlvbiBvY3RldCB0byBzZXJ2 ZSBhcyBhIHJlc3BvbnNlIGluZGljYXRvci4gIEl0IGlzIHNldCB0byB6ZXJvIGZvciBhIHJl cXVlc3QgbWVzc2FnZSBhbmQgb25lIGZvciB0aGUgYXNzb2NpYXRlZCByZXNwb25zZSBtZXNz YWdlLiBNdWx0aXBsZSBtZXNzYWdlcyBjYW4gYmUgc3BsaXQgb3ZlciBtdWx0aXBsZSBOVFAg cGFja2V0cyBhcyBuZWNlc3NhcnksIGR1ZSB0byBwYWNrZXQgbGVuZ3RoIHJlc3RyaWN0aW9u cy4gTXVsdGlwbGUgcmVzcG9uc2VzIGNhbiBiZSBhc3NvY2lhdGVkIHdpdGggYSBzaW5nbGUg cmVxdWVzdC4NCg0KDQpBbiBleGNoYW5nZSBpcyBhIHZvbGxleSBjb25zaXN0aW5nIG9mIGEg c2luZ2xlIHJlcXVlc3QgbWVzc2FnZSB0byBhIGhvc3QgZm9sbG93ZWQgYnkgb25lIG9yIG1v cmUgcmVzcG9uc2UgbWVzc2FnZXMgZnJvbSB0aGF0IGhvc3QuIEluIGdlbmVyYWwsIGVhY2gg ZXhjaGFuZ2UgcGVyZm9ybXMgYSBzaW5nbGUgZnVuY3Rpb24gaW5kZXBlbmRlbnQgb2Ygb3Ro ZXIgZXhjaGFuZ2VzLg0KDQoNCjIuIEJhY2t3YXJkIENvbXBhdGliaWxpdHkNCg0KDQpJdCBp cyBpbXBvcnRhbnQgdGhhdCB0aGUgY3VycmVudCBjcnlwdG9ncmFwaGljIGtleXMgbW9kZWwg YW5kIE5UUCBtb2RlcyAtIGluY2x1ZGluZyBjbGllbnQgc2VydmVyLCBzeW1tZXRyaWMsIGJy b2FkY2FzdC9tdWx0aWNhc3QvbWFueWNhc3QgYW5kIGludGVybGVhdmUgbW9kZXMgLSBiZSBw cmVzZXJ2ZWQuIFRoZSBleGlzdGluZyBzeW1tZXRyaWMga2V5IGRlc2lnbiAtIGluY2x1ZGlu ZyB0aGUga2V5cyB0YWJsZSBmaWxlLCBtZXNzYWdlIGF1dGhlbnRpY2F0aW9uIGNvZGUgKE1B QykgZm9ybWF0IGFuZCBzZWxlY3Rpb24gb2YgaGFzaCBhbGdvcml0aG0gLSBzaG91bGQgYWxz byBiZSByZXRhaW5lZC4gSXQgaXMgbm90IG5lY2Vzc2FyeSB0byBwcmVzZXJ2ZSB0aGUgY3Vy cmVudCBBdXRva2V5IHNjaGVtZSBpdHNlbGYsIGFsdGhvdWdoIHNvbWUgZWxlbWVudHMgb2Yg dGhpcyBzY2hlbWUgcmVtYWluIGluIHRoaXMgcHJvcG9zYWwuDQoNCg0KMy4gSW5mcmFzdHJ1 Y3R1cmUNCg0KDQpUaGUgZnVuZGFtZW50YWwgcHJpbmNpcGxlIGluIHRoZSBOVFAgZW5naW5l ZXJpbmcgZGVzaWduIGlzIHRoYXQgbm8gZXhwbGljaXQgaW5mcmFzdHJ1Y3R1cmUgb3RoZXIg dGhhbiB0aGUgYmFzZSBuZXR3b3JrIGlzIGFzc3VtZWQuIFRoaXMgbWVhbnMgdGhhdCBuZWl0 aGVyIEROUyBub3IgY2VydGlmaWNhdGUgbWFuYWdlbWVudCBpbmZyYXN0cnVjdHVyZSBpcyBh dmFpbGFibGUuIFNpbmNlIGNlcnRpZmljYXRlcyBjYW5ub3QgYmUgYXV0aGVudGljYXRlZCBi eSBvdXRzaWRlIG1lYW5zLCB0aGVyZSBpcyBhIHBvc3NpYmlsaXR5IG9mIGEgbWlkZGxlbWFu IGF0dGFjayB3aGVyZSB0aGUgYXR0YWNrZXIgaW5qZWN0cyBpdHMgY2VydGlmaWNhdGUgb24g dGhlIHRyYWlsIGxlYWRpbmcgdG8gdGhlIGNlcnRpZmljYXRlIGF1dGhvcml0eS4NCg0KDQpJ biB0aGUgb3JpZ2luYWwgQXV0b2tleSBkZXNpZ24gdGhlcmUgd2VyZSBvcHRpb25hbCBtZWFu cyB0byB2ZXJpZnkgdGhlIGNlcnRpZmljYXRlIHRyYWlsIHVzaW5nIHRoZSBpZGVudGl0eSBl eGNoYW5nZS4gVGhpcyBleGNoYW5nZSBpcyBubyBsb25nZXIgbmVlZGVkLCBzaW5jZSBrZXkg emVybywgZGVzY3JpYmVkIGJlbG93IGluIHRoZSAiTGF5ZXJlZCBNb2RlbCIgc2VjdGlvbiwg cGVyZm9ybXMgYSBzaW1pbGFyIGZ1bmN0aW9uLg0KDQoNCjQuIERpdmVyc2l0eQ0KDQoNCklu IHRoZSBjdXJyZW50IE5UUCBhcmNoaXRlY3R1cmUsIHRoZSB0aW1lIGFuZCBzZWN1cml0eSBv cGVyYXRpb25zIHByb2NlZWQgaW5kZXBlbmRlbnRseSBhbmQgc2ltdWx0YW5lb3VzbHkgZm9y IGVhY2ggYXNzb2NpYXRpb24sIGFzIGRlc2NyaWJlZCBiZWxvdy4gU2VjdXJpdHkgZm9yIGFs bCBhc3NvY2lhdGlvbnMgaXMgbWFuYWdlZCBzZXBhcmF0ZWx5LiBBbiBhc3NvY2lhdGlvbiBo YXMgdmFsaWQgdGltZSB3aGVuIHRoZSBkaXNwZXJzaW9uIGhhcyBmYWxsZW4gYmVsb3cgdGhl IHRocmVzaG9sZC4gVGhlIHNlY3VyaXR5IGlzIHZhbGlkIHdoZW4gdGhlIGZpcnN0IHNpZ25h dHVyZSBpcyB2ZXJpZmllZC4gQW4gYXNzb2NpYXRpb24gaXMgdmFsaWQgd2hlbiBib3RoIHRo ZSB0aW1lIGFuZCBzZWN1cml0eSBhcmUgdmFsaWQuDQoNCg0KVGhlIGFzc29jaWF0aW9ucyBh cmUgc2VsZWN0ZWQgYnkgdGhlIEJ5emFudGluZSwgaW50ZXJzZWN0aW9uIGFuZCBjbHVzdGVy aW5nIGFsZ29yaXRobXMuIEl0IGRvZXMgbm90IHNlZW0gZmVhc2libGUgdG8gImxvb3NlbHkg c3luY2hyb25pemUiIHRoZSBzeXN0ZW0gY2xvY2sgd2l0aCB0aGlzIGRlc2lnbiwgc2luY2Ug b25seSBhZnRlciB0aGVzZSBhbGdvcml0aG1zIGhhdmUgY29tcGxldGVkIGlzIHRoZSBzeXN0 ZW0gY2xvY2sgZWxpZ2libGUgdG8gYmUgc3luY2hyb25pemVkLg0KDQoNCjUuIFR3by1XYXkg SXNzdWVzDQoNCg0KSW4gYnJvYWRjYXN0IG1vZGUsIGEgdHdvLXdheSBwYXRoIGJldHdlZW4g dGhlIGJyb2FkY2FzdCBzZXJ2ZXIgYW5kIGNsaWVudCBpcyBuZWNlc3NhcnkgdG8gY29tcHV0 ZSB0aGUgcm91bmQtdHJpcCBkZWxheS4gSG93ZXZlciwgaW4gc29tZSBzdXBwb3J0ZWQgY29u ZmlndXJhdGlvbnMgYSByZXR1cm4gcGF0aCBpcyBub3QgYXZhaWxhYmxlIHNvIHRoZSByb3Vu ZC10cmlwIGRlbGF5IGNhbm5vdCBiZSBjb21wdXRlZCBhbmQgbXVzdCBiZSBlc3RpbWF0ZWQu IEl0IGlzIG5vdCB0aGVuIHBvc3NpYmxlIHRvIHJldHJpZXZlIGFueSBzZXJ2ZXIgZGF0YSBv dGhlciB0aGFuIHRoZSBicm9hZGNhc3QgcGFja2V0IGl0c2VsZi4gVGhlIHJlZmVyZW5jZSBp bXBsZW1lbnRhdGlvbiBzdXBwb3J0cyBib3RoIGEgb25lLXdheSBhbmQgdHdvLXdheSBkZXNp Z24gdXNpbmcgYW4gb3B0aW9uYWwgY2xpZW50IHNlcnZlciBleGNoYW5nZSB0byBjb21wdXRl IHRoZSByb3VuZC10cmlwIGRlbGF5IGZvbGxvd2VkIGJ5IG9uZS13YXkgYnJvYWRjYXN0IHBh Y2tldHMuDQoNCg0KNi4gQWNjZXNzIENvbnRyb2wNCg0KDQpUaGUgY3VycmVudCByZWZlcmVu Y2UgaW1wbGVtZW50YXRpb24gaW5jbHVkZXMgYWNjZXNzIGNvbnRyb2xzIGluIHRoZSBmb3Jt IG9mIGJpdCBwZXJtaXNzaW9ucyBhbmQgcmF0ZSBtYW5hZ2VtZW50IHBhcmFtZXRlcnMuIFRo ZXJlIGlzIG5vIG5lZWQgZm9yIGFkZGl0aW9uYWwgYWNjZXNzIGNvbnRyb2wgZnVuY3Rpb24g aW4gdGhlIGNyeXB0b2dyYXBoaWMgYWxnb3JpdGhtcy4gT3RoZXIgcHVibGljIGtleSBzY2hl bWVzIG1heSB3aXNoIHRvIHVzZSBhbiBhY2Nlc3MgZXhjaGFuZ2UgcHJvdmlkaW5nIGEgc2Vz c2lvbiBrZXkgZm9yIHRoZSBkdXJhdGlvbiBvZiB0aGUgcHJvdG9jb2wsIGFsdGhvdWdoIHRo ZSBvbi13aXJlIHByb3RvY29sIGxheWVyIHByb3ZpZGVzIGEgc2ltaWxhciBmdW5jdGlvbi4N Cg0KDQpSYXRlIG1hbmFnZW1lbnQgaXNzdWVzIGFyZSBhIGNyaXRpY2FsIGNvbnNpZGVyYXRp b24gaW4gdGhlIHNlY3VyaXR5IHByb3RvY29sIGRlc2lnbi4gRm9yIGV4YW1wbGUsIE5JU1Qg c2VydmVycyBwcm9jZXNzZXMgb3ZlciAyNDAsMDAwIE5UUCBwYWNrZXRzIHBlciBzZWNvbmQs IG9uIGF2ZXJhZ2UuICBBcyBvZiBKdW5lIG9mIDIwMTcsIHRoYXTigJlzIG1vcmUgdGhhbiAy MSBiaWxsaW9uIE5UUCByZXF1ZXN0cyBwZXIgZGF5LiBBcyBsZWFybmVkIGZyb20gZXhwZXJp ZW5jZSwgdGhlIHByaW1hcnkgY29uc3VtZXIgb2YgQ1BVIGN5Y2xlcyBpcyB0aGUgcGVyIHBh Y2tldCBvdmVyaGVhZCwgd2l0aCBlYWNoIHBhY2tldCByZXF1aXJpbmcgdGhvdXNhbmRzIG9m IENQVSBpbnN0cnVjdGlvbnMgdG8gcHJvY2Vzcy4gVGhpcyBvdmVyaGVhZCBpcyBzdWJzdGFu dGlhbGx5IGluZGVwZW5kZW50IG9mIHBhY2tldCBsZW5ndGggb3IgbnVtYmVyIG9mIGV4dGVu c2lvbiBmaWVsZHMuDQoNCg0KVGhlIGN1cnJlbnQgcmVmZXJlbmNlIGltcGxlbWVudGF0aW9u IGxpbWl0cyB0aGUgbWluaW11bSBwYWNrZXQgaGVhZHdheSBhbmQgbWluaW11bSBhdmVyYWdl IGhlYWR3YXkgdG8gY29uZmlndXJlZCB2YWx1ZXMuIENsaWVudHMgdGhhdCB2aW9sYXRlIHRo ZXNlIGxpbWl0cyBhcmUgZGVuaWVkIHNlcnZpY2UuIEZvciBleGFtcGxlLCBhdCBOSVNULCBh IHNpZ25pZmljYW50IG1pbm9yaXR5IG9mIGNsaWVudHMgcm91dGluZWx5IHZpb2xhdGUgdGhl IG1pbmltdW0gaGVhZHdheSByZXF1aXJlbWVudCBvZiB0d28gc2Vjb25kcyBhbmQgc28gYXJl IGRpc2NhcmRlZC4gQW4gb3B0aW9uYWwga2lzcyBvJyBkZWF0aCAoS29EKSBpcyBhdmFpbGFi bGUgdG8gcXVlbmNoIGNvbXBsaWFudCBjbGllbnRzLg0KDQoNClRoZSByYXRlIG1hbmFnZW1l bnQgcGFyYW1ldGVycyBhcHBseSBib3RoIHRvIHRoZSBOVFAgcGFja2V0IGZsb3dzLCBhcyB3 ZWxsIGFzIHRoZSBzZWN1cml0eSBmdW5jdGlvbi4gQXMgdGhpcyBmdW5jdGlvbiBvZnRlbiBp bnZvbHZlcyBtdWx0aXBsZSBwYWNrZXRzLCB0aGlzIG1heSByZXN1bHQgaW4gZXhjZXNzaXZl IGFjcXVpc2l0aW9uIHRpbWVzLiBUaGUgbWVhbnMgZGVzY3JpYmVkIGJlbG93IHByb3ZpZGUg YSB3YXkgdG8gbWluaW1pemUgdGhlIG51bWJlciBvZiBwYWNrZXRzIHRvIGNvbXBsZXRlIHRo ZSBwcm90b2NvbC4NCg0KDQo3LiBOVFAgU2VjdXJlIE5ldHdvcmsgRW5naW5lZXJpbmcgUHJp bmNpcGxlcw0KDQoNCkFuIE5UUCBzZWN1cmUgbmV0d29yayBjb25zaXN0cyBvZiBhbiBhY3lj bGljLCB1bmRpcmVjdGVkIGdyYXBoIG9yZ2FuaXplZCBhcyBhIHRyZWUgd2l0aCBub2RlcyBk ZXNjZW5kaW5nIGZyb20gdGhlIHJvb3Qgbm9kZS4gVGhlIG5vZGVzIGNvcnJlc3BvbmQgdG8g dGhlIE5UUCBob3N0cyBhbmQgdGhlIGVkZ2VzIGNvcnJlc3BvbmQgdG8gdGhlIG5ldHdvcmsg cGF0aHMgYmV0d2VlbiB0aGVtLiBUaGUgbmV0d29yayBwYXRocyBpbmNsdWRlIG9uZSBvciBt b3JlIHBoeXNpY2FsIGxpbmtzLCBpbnRlcmNvbm5lY3RlZCBieSByb3V0ZXJzIGFuZCBmaXJl d2FsbHMuIE5vdGUgdGhhdCB0aGUgbmV0d29yayB0b3BvbG9neSBjYW4gY2hhbmdlIGZyb20g dGltZSB0byB0aW1lIGR1ZSB0byBob3N0IG9yIG5ldHdvcmsgcGF0aCBmYWlsdXJlcy4NCg0K DQpGb3IgdGhlIHB1cnBvc2VzIG9mIG5ldHdvcmsgc2VjdXJpdHksIGVhY2ggaG9zdCBjYW4g Y29tbXVuaWNhdGUgZGlyZWN0bHkgb25seSB3aXRoIHRoZSBuZXh0IHVwc3RyZWFtIGhvc3Qg YW5kIG5leHQgZG93bnN0cmVhbSBob3N0LiBBIGhvc3QgY2FuIG9wZXJhdGUgYXMgZWl0aGVy IGEgY2xpZW50IG9yIHNlcnZlciwgb3IgYXMgYm90aCBhdCB0aGUgc2FtZSB0aW1lLg0KDQoN CkVhY2ggaG9zdCBuZWVkcyBhIHNldCBvZiBwdWJsaWMgYW5kIHByaXZhdGUga2V5cywgYW5k IG9uZSBvciBtb3JlIGNlcnRpZmljYXRlcy4gRWFjaCBzaWduZWQgY2VydGlmaWNhdGUgY29u ZmlybXMgYXV0aGVudGljaXR5IG9mIGl0cyBwdWJsaWMga2V5LiAgUHVibGljL3ByaXZhdGUg a2V5cyBhbmQgaG9zdCBjZXJ0aWZpY2F0ZXMgYXJlIGdlbmVyYXRlZCBpbmRpdmlkdWFsbHkg YnkgZWFjaCBob3N0Lg0KDQoNClRoZSBnb2FsIG9mIHRoZSBzZWN1cml0eSBzY2hlbWUgaXMg dG8gYXV0aGVudGljYXRlIGVhY2ggc2VydmVyIHRvIHRoZSBuZXh0IGRvd25zdHJlYW0gY2xp ZW50IHVzaW5nIG9uZSBvciBtb3JlIGNlcnRpZmljYXRlcy4gVGhlIHJlY3Vyc2l2ZSBzY2hl bWUgZXZvbHZlcyBhcyBmb2xsb3dzOiBJbiB0aGUgYmFzaXMgc3RlcCwgdGhlIHJvb3Qgc2Vy dmVyIGhvc3QgaXMgZGVzaWduYXRlZCBhdXRoZW50aWMgYnkgc29tZSBtZWFucyBleHRlcm5h bCB0byB0aGUgbmV0d29yay4gSW4gdGhlIGluZHVjdGl2ZSBzdGVwLCBlYWNoIGNsaWVudCBo b3N0IGluIHRoZSBuZXR3b3JrIHNlcGFyYXRlbHkgcmVxdWVzdHMgaXRzIGltbWVkaWF0ZSBh c2NlbmRpbmcgc2VydmVyIGhvc3QgdG8gc2lnbiBpdHMgY2xpZW50IGhvc3QgY2VydGlmaWNh dGUuIElmIHRoZSBzZXJ2ZXIgaG9zdCBpcyBhdXRoZW50aWMsIHRoZSBjbGllbnQgaG9zdCBp cyBkZXNpZ25hdGVkIGF1dGhlbnRpYy4gSWYgdGhlIHNlcnZlciBob3N0IGlzIG5vdCBhdXRo ZW50aWMsIHRoZSByZXF1ZXN0IGlzIGlnbm9yZWQgYW5kIHRoZSBjbGllbnQgcmVxdWVzdCBp cyByZXBlYXRlZCBhZnRlciB0aW1lb3V0LiBJbiB0aGlzIGZhc2hpb24sIGV2ZW50dWFsbHkg YWxsIGNsaWVudCBjZXJ0aWZpY2F0ZXMgYXJlIHNpZ25lZCBhbmQgZGVzaWduYXRlZCBhdXRo ZW50aWMuIFRodXMsIGF1dGhlbnRpY2l0eSBmbG93cyBpbiBzdGVwcyBmcm9tIHRoZSByb290 IGhvc3QsIGFzIGEgY2VydGlmaWNhdGUgYXV0aG9yaXR5LCB0byBlYWNoIGRvd25zdHJlYW0g aG9zdCBpbiB0aGUgbmV0d29yay4NCg0KDQpPbmNlIGdlbmVyYXRlZCwgY2VydGlmaWNhdGVz IGhhdmUgYSBzcGVjaWZpYyBhc3NpZ25lZCBsaWZldGltZS4gU29tZSB0aW1lIGJlZm9yZSBl eHBpcmF0aW9uIG9mIHRoZSBsaWZldGltZSwgYSBuZXcgY2VydGlmaWNhdGUgbXVzdCBiZSBn ZW5lcmF0ZWQgd2l0aCBhIG5ldyBsaWZldGltZS4gVGhpcyBkb2VzIG5vdCBhZmZlY3QgdGhl IGF1dGhlbnRpY2l0eSBvciBvdGhlciBwYXJhbWV0ZXJzIG9mIHRoZSBjZXJ0aWZpY2F0ZS4g T24gdGhlIG90aGVyIGhhbmQsIGEgbmV3IHNldCBvZiBwdWJsaWMvcHJpdmF0ZSBrZXlzIHJl cXVpcmUgdGhlIGNlcnRpZmljYXRlIHRvIGJlIHJlZ2VuZXJhdGVkIGFuZCBpdHMgcHVibGlj IGtleSB0byBiZSByZXNpZ25lZCBieSB0aGUgc2VydmVyLiBUaGUgc2NoZW1lIHRvIGRvIHRo aXMsIGFzIGRlc2NyaWJlZCBiZWxvdywgaXMgc3RyYWlnaHRmb3J3YXJkIGJ1dCBpbnRyaWNh dGUuDQpBIGhvc3QgaXMgY29uc2lkZXJlZCBwcm92aXNpb25hbGx5IGF1dGhlbnRpYyB3aGVu IHRoZSBzaGFyZWQgaGFzaCBrZXkgc2lnbmF0dXJlcyBoYXZlIGJlZW4gdmVyaWZpZWQuIFRo ZSBob3N0IGlzIGNvbnNpZGVyZWQgZnVsbHkgYXV0aGVudGljIHdoZW4gaXRzIGNlcnRpZmlj YXRlIGhhcyBiZWVuIHNpZ25lZCBieSB0aGUgbmV4dCBhc2NlbmRpbmcgaG9zdCBvbiB0aGUg dHJhaWwgdG8gdGhlIGNlcnRpZmljYXRlIGF1dGhvcml0eSBob3N0Lg0KDQoNClRoZSBjZXJ0 aWZpY2F0ZSB0cmFpbCBpcyB0aHVzIGNvbnN0cnVjdGVkIHN0ZXAgYnkgc3RlcCBhcyBlYWNo IHNpZ25hdHVyZSBpcyBidWlsdCBvciB2ZXJpZmllZC4gRWFjaCBzdGVwIGludm9sdmVzIGEg c2lnbiBleGNoYW5nZSwgYXMgZGVzY3JpYmVkIGxhdGVyLiBBc3N1bWluZyB0aGUgaG9zdCB0 aW1lIGlzIGNvcnJlY3QsIHRoZSB0cmFpbCBuZWVkcyB0byBiZSB2ZXJpZmllZCBvbmx5IG9u Y2UuDQoNCg0KTm90ZSB0aGF0IHRoaXMgbW9kZWwgZG9lcyBub3QgY29uc3RydWN0IHRoZSBj ZXJ0aWZpY2F0ZSB0cmFpbCBpbiBlYWNoIGNsaWVudCBob3N0LiBJbiBmb3JtZXIgZGVzaWdu cywgdGhpcyB3YXMgYWNoaWV2ZWQgdXNpbmcgYSBwZXJzaXN0ZW50IGNhY2hlIHdoaWNoIGhh ZCB0byBiZSB1cGRhdGVkIG9uIGEgcmVndWxhciBiYXNpcy4gSG93ZXZlciwgYm90aCB0aGUg Y3VycmVudCBhbmQgcHJvcG9zZWQgbW9kZWxzIGFyZSB2dWxuZXJhYmxlIHRvIG1pZGRsZW1h biBhdHRhY2suIFRoZSBvcmlnaW5hbCBzb2x1dGlvbiBmb3IgdGhpcyBwcm9ibGVtIHdhcyB0 aGUgU2Nobm9yciAoSUZGKSBpZGVudGl0eSBzY2hlbWUgZGVzY3JpYmVkIGluIFJGQzU5MDYu IFRoZSBzY2hlbWUgcHJvcG9zZWQgaW4gdGhpcyBkb2N1bWVudCByZXBsYWNlcyB0aGUgSUZG IHNjaGVtZSB3aGlsZSBwZXJmb3JtaW5nIHRoZSBzYW1lIGZ1bmN0aW9uLCBhcyBkZXNjcmli ZWQgYmVsb3cuDQoNCg0KOC4gTGF5ZXJlZCBNb2RlbA0KDQoNClRoZSBzZWN1cml0eSBtb2Rl bCBpbiB0aGUgZ2VuZXJpYyByZWZlcmVuY2UgaW1wbGVtZW50YXRpb24gUkZDNTkwNSBjYW4g YmUgc3VtbWFyaXplZCBhcyBhIGZvdXItbGF5ZXIgbW9kZWwsIGRlc2NyaWJlZCBiZWxvdy4g Tm90ZSB0aGF0IHRoZSBwcm90b2NvbCBtZXNzYWdlcyBoaXRjaGhpa2Ugb24gdGhlIE5UUCBw YWNrZXQgaGVhZGVycyBhcyB0cmFuc21pdHRlZC4gTm90ZSBhbHNvIHRoYXQgdGhlIHBhY2tl dCBwb2xsIGludGVydmFsIGR1cmluZyB0aGUgc2VjdXJpdHkgZGFuY2UgY2FuIGJlIHJlZHVj ZWQgY29uc2lzdGVudCB3aXRoIHRoZSByYXRlIGxpbWl0cy4NCg0KDQo4LjEgRm9ybWF0IExh eWVyDQoNCg0KV2hlbiBhbiBOVFAgcGFja2V0IGFycml2ZXMsIHRoZSBmaXJzdCBsYXllciB2 ZXJpZmllcyB0aGUgcGFja2V0IGZvcm1hdC4gSW4gcGFydGljdWxhciwgdGhlIHBhY2tldCBo ZWFkZXIgYW5kIGV4dGVuc2lvbiBmaWVsZCBsZW5ndGhzLCBpZiBwcmVzZW50LiBFeHRlbnNp b24gZmllbGRzIGFyZSBub3QgcHJvY2Vzc2VkIGF0IHRoaXMgdGltZS4gVGhlIGZvcm1hdCBz Y2FuIHJlc3VsdHMgaW4gYSBwb2ludGVyIGp1c3QgYmVmb3JlIHRoZSBtZXNzYWdlIGF1dGhl bnRpY2F0aW9uIGNvZGUgKE1BQykuIFRoaXMgZGVzaWduYXRlcyB0aGUgdXBwZXIgbGltaXQg b2YgdGhlIGhhc2ggY29tcHV0YXRpb24uIEluIGNhc2Ugb2YgZm9ybWF0IGVycm9yLCB0aGUg cGFja2V0IGlzIGRpc2NhcmRlZCB3aXRoIG5vIGZ1cnRoZXIgYWN0aW9uLg0KDQoNCjguMiBT eW1tZXRyaWMgS2V5IExheWVyDQoNCg0KVGhlIHNlY29uZCBsYXllciB2ZXJpZmllcyBwYWNr ZXQgZGF0YSBjb250ZW50LiBJbiB0aGUgTlRQIGdlbmVyaWMgc2VjdXJpdHkgbW9kZWwsIE5U UCBwYWNrZXRzIGFyZSBjb25zaWRlcmVkIHB1YmxpYyB2YWx1ZXMgc28gdGhleSBhcmUgbm90 IGVuY3J5cHRlZC4gSG93ZXZlciwgaSx0IGlzIHZpdGFsIHRoYXQgdGhlIHBhY2tldCBiZSB1 bmRhbWFnZWQgaW4gdHJhbnNpdCBhbmQgdGhlIHBhY2tldCBvcmRlciBiZSBwcmVzZXJ2ZWQu IFRob3VnaCB0aGUgcHJvdG9jb2wgaXMgcXVpdGUgcmVzaXN0YW50IHRvIHBhY2tldCBsb3Nz LCByZXRyYW5zbWlzc2lvbnMgaGF2ZSBsaXR0bGUgdXNlLg0KDQoNCkludGVncml0eSBpcyBw cm90ZWN0ZWQgYnkgYSBtZXNzYWdlIGF1dGhlbnRpY2F0aW9uIGNvZGUgTUFDLCB3aGljaCBp cyB1c2VkIGZvciBhbGwgcGFja2V0cy4gVGhlIE1BQyBpcyBvcmRpbmFyaWx5IGNvbnN0cnVj dGVkIGFuZCB2ZXJpZmllZCB1c2luZyBhIGhhc2gga2V5IHNoYXJlZCBieSB0aGUgY2xpZW50 IGFuZCBzZXJ2ZXIuIFRoZSBoYXNoIGtleSBpcyBhc3N1bWVkIHByaXZhdGUgYW5kIHVucHJl ZGljdGFibGUgZm9yIGVhY2ggYXNzb2NpYXRpb24uDQoNCg0KSWYgYSBzaGFyZWQgaGFzaCBr ZXkgaXMgbm90IGF2YWlsYWJsZSwgc3VjaCBhcyBkdXJpbmcgdGhlIGFncmVlbWVudCBwcm9j ZXNzIGl0c2VsZiwgdGhlIGV4aXN0ZW5jZSBvZiBhbiBpbXBsaWNpdCBoYXNoIGtleSB6ZXJv IGlzIGFzc3VtZWQuIFRoZSB2YWx1ZSBvZiBoYXNoIGtleSB6ZXJvIGNvdWxkIGJlIGEgcmFu ZG9tIG51bWJlciBrbm93biBvbmx5IHRvIHZlcmlmaWVkIGFuZCB0cnVzdGVkIGhvc3RzIGlu IHRoZSBOVFAgbmV0d29yay4gSGFzaCBrZXkgemVybyBjb3VsZCBiZSBhbnkgbXV0dWFsbHkg YWdyZWVkIHVwb24gc3ltbWV0cmljIGtleS4gIFRoZSBkZXNpZ24gaW50ZW50IGlzIHRvIHZl cmlmeSB0aGlzIG51bWJlciBhcyB3ZWxsIGFzIGRldGVjdCBlcnJvcnMsIHJhdGhlciB0aGFu IHByb3RlY3QgYWdhaW5zdCBtaWRkbGVtYW4gYXR0YWNrLiBCeSBwcm90b2NvbCBydWxlLCBp ZiBhIG1lc3NhZ2UgcmVxdWVzdCB1c2VzIGhhc2gga2V5IHplcm8sIHRoZSBtZXNzYWdlIHJl c3BvbnNlIGFsc28gdXNlcyBoYXNoIGtleSB6ZXJvLg0KDQoNCkJ5IHNwZWNpZmljYXRpb24s IGEgc2VjdXJlIHNlcnZlciBjYW4gd29yayB3aXRoIG9yIHdpdGhvdXQgYSBNQUMuIFdpdGhv dXQgYSBNQUMsIGEgcGFja2V0IGlzIHVuY29uZGl0aW9uYWxseSBhY2NlcHRlZDsgd2l0aCBh IE1BQyAsIGEgcGFja2V0IGlzIGFjY2VwdGVkIG9ubHkgaWYgdmVyaWZpZWQgYnkgc2VjdXJl IG1lYW5zLiBBIGNvbmZpZ3VyYXRpb24gYml0IGNhbiBiZSB1c2VkIHRvIGRpc2NhcmQgcGFj a2V0cyB3aXRob3V0IGEgTUFDLg0KDQoNCkluIGNhc2Ugb2YgaGFzaCBmYWlsdXJlLCB0aGUg cGFja2V0IGlzIGRpc2NhcmRlZCBhbmQgYSBjcnlwdG8tTkFLIG1lc3NhZ2UgaXMgcmV0dXJu ZWQgdG8gdGhlIHNlbmRlci4gVGhlIGNyeXB0by1OQUsgY29uc2lzdHMgb2YgYSBmb3VyIG9j dGV0IGV4dGVuc2lvbiBmaWVsZCBjb250YWluaW5nIGFuIG9wdGlvbmFsIGVycm9yIGNvZGUu IEEgY3J5cHRvLU5BSyBwYWNrZXQgaXMgYWx3YXlzIHNlbnQgd2l0aCBrZXkgemVyby4gVGhl IGNyeXB0by1OQUsgb3JkaW5hcmlseSByZXN1bHRzIGluIGEgcmVuZWdvdGlhdGlvbiBvZiB0 aGUgc2hhcmVkIGhhc2gga2V5LCBhcyBkZXNjcmliZWQgYmVsb3cuIEluIGNhc2Ugb2YgYnJv YWRjYXN0IG1vZGUsIGEgZGlmZmVyZW50IHN0cmF0ZWd5IGlzIHVzZWQsIGFzIGRlc2NyaWJl ZCBiZWxvdy4NCg0KDQpJZiB0aGUgaGFzaCBzaXplIGlzIHRvbyBsYXJnZSwgaXQgY2FuIGNv bXByb21pc2UgdGltaW5nIGFjY3VyYWN5OyBpZiB0b28gc21hbGwsIGl0IGNhbiBjb21wcm9t aXNlIHNlY3VyaXR5LiBBIG5hdHVyYWwgY2hvaWNlIGlzIDE2MCBiaXRzIG9yIDIwIG9jdGV0 cywgYXMgaW4gdGhlIGN1cnJlbnQgcmVmZXJlbmNlIGltcGxlbWVudGF0aW9uLiBBbiBhdHRy YWN0aXZlIHN0cmF0ZWd5IGlzIHRoZSB1c2Ugb2YgZWxsaXB0aWMtY3VydmUgdmVyc2lvbnMg b2YgdGhlIGFncmVlbWVudCBhbmQgc2lnbmF0dXJlIGFsZ29yaXRobXMuIFVzaW5nIHRoZXNl IGFsZ29yaXRobXMsIGEgMTYwLWJpdCBoYXNoIHNpemUgaXMgZXF1aXZhbGVudCB0byBhIDEw MjQtYml0IGhhc2ggc2l6ZSB1c2luZyB0aGUgdHJhZGl0aW9uYWwgYWxnb3JpdGhtcy4NCg0K DQpJbiB0aGUgaGlzdG9yaWMgcmVmZXJlbmNlIGltcGxlbWVudGF0aW9uLCBhIE1BQyBpcyBp bmRpY2F0ZWQgYXMgdGhlIGxhc3QgYmxvY2sgYWZ0ZXIgYWxsIGV4dGVuc2lvbiBmaWVsZHMg aW4gdGhlIHBhY2tldC4gVGhlIGJsb2NrIGxlbmd0aCBpcyB0cmFkaXRpb25hbGx5IG5vIGdy ZWF0ZXIgdGhhbiAyNCBvY3RldHMgLSBmb3VyIG9jdGV0cyBmb3IgdGhlIGtleSBJRCBwbHVz IDIwIG9jdGV0cyBmb3IgdGhlIGhhc2guIEZvciBzeW1tZXRyaWMga2V5cywgdGhlIGhpZ2gt b3JkZXIgdHdvIG9jdGV0cyBvZiB0aGUga2V5IElEIGFyZSB6ZXJvIGFuZCB0aGUgbG93LW9y ZGVyIHR3byBvY3RldHMgYXJlIHRoZSBlbnRyeSBudW1iZXIgaW4gdGhlIGtleXMgZmlsZS4g VGhpcyBmb3JtYXQgaXMgbmVjZXNzYXJ5IG9ubHkgZm9yIGJhY2t3YXJkIGNvbXBhdGliaWxp dHkgd2l0aCB0aGUgc3ltbWV0cmljIGtleSBmaWxlLg0KDQoNCkl0IGlzIG5vdCBnZW5lcmFs bHkgdXNlZnVsIHRvIHByb3ZpZGUgbGFyZ2VyIGhhc2ggc2l6ZXMuIEZvciBleGFtcGxlLCB0 aGUgU0hBMTYwIGhhc2ggYWxnb3JpdGhtIGlzIGEgMjAtb2N0ZXQgdHJ1bmNhdGVkIHZlcnNp b24gb2YgU0hBMjU2LiBPdGhlciBoYXNoIGFsZ29yaXRobXMgY2FuIGJlIHRydW5jYXRlZCBh cyB3ZWxsLg0KDQoNCkluIHRoZSByZWZlcmVuY2UgaW1wbGVtZW50YXRpb24sIHRoZSBoYXNo IGFsZ29yaXRobSBjYW4gYmUgc3BlY2lmaWVkIGZvciBlYWNoIGtleSBudW1iZXIgaW4gdGhl IGtleXMgZmlsZS4gSW4gcHJpbmNpcGxlLCBrZXkgemVybyBjYW4gYmUgYXNzaWduZWQgaW4g dGhlIGtleXMgZmlsZSBhcyB3ZWxsLCBwcm92aWRpbmcgYW4gaW5kZXBlbmRlbnQgY2hvaWNl IG9mIGhhc2ggYWxnb3JpdGhtLg0KDQoNClRoZSBPcGVuU1NMIGxpYnJhcnkgaW5jbHVkZXMg anVzdCBhYm91dCBldmVyeSBoYXNoIGFsZ29yaXRobSBsaWtlbHkgdG8gYmUgaW1hZ2luZWQu IFdoaWxlIGhpc3RvcmljYWxseSBhbWJpZ3VvdXMsIHRoZSBJbnRlcm5hdGlvbmFsIFRyYWRl IGluIEFybXMgUmVndWxhdGlvbnMgKElUQVIpIHByb2hpYml0cyBleHBvcnQgb2YgdGhlIE9w ZW5TU0wgbGlicmFyeSwgc28gb25seSB0aGUgTUQ1IGhhc2ggYWxnb3JpdGhtIGlzIGluY2x1 ZGVkIGluIHRoZSByZWZlcmVuY2UgZGlzdHJpYnV0aW9uLiBBbHRlcm5hdGl2ZWx5LCB0aGUg T3BlblNTTCBsaWJyYXJ5IGNhbiBiZSBpbXBvcnRlZCBmcm9tIGZvcmVpZ24gb3IgZG9tZXN0 aWMgc291cmNlcywgYWx0aG91Z2ggZ2VuZXJhdGVkIGJpbmFyaWVzIG1heSBub3QgYmUgZXhw b3J0ZWQgZnJvbSB0aGUgVVMuLg0KDQoNCkFsdGVybmF0ZWx5IG9yIGluIGFkZGl0aW9uLCBh IGhhc2ggb2YgYXJiaXRyYXJ5IHNpemUgY2FuIGJlIGltcGxlbWVudGVkIHVzaW5nIGFuIGV4 dGVuc2lvbiBmaWVsZC4gSW4gdGhpcyBjYXNlLCB0aGUgbGVuZ3RoIG9jdGV0cyBpbiB0aGUg a2V5IElEIHdpbGwgYmUgbm9uemVybyBhbmQgdGhlIG1vZGlmaWVyIG9jdGV0IHVzZWQgYXMg dGhlIGtleSBudW1iZXIuIFRoZSBoYXNoIGlzIGNvbXB1dGVkIGZyb20gdGhlIGJlZ2lubmlu ZyBvZiB0aGUgcGFja2V0IHRvIHRoZSBiZWdpbm5pbmcgb2YgdGhlIE1BQy4gT3JkaW5hcmls eSwgdGhlIE1BQyBpcyB0aGUgbGFzdCBleHRlbnNpb24gZmllbGQgaW4gdGhlIHBhY2tldCwg YnV0IGFkZGl0aW9uYWwgZXh0ZW5zaW9uIGZpZWxkcyBiZXlvbmQgdGhlIE1BQyBhcmUgcG9z c2libGUsIHRob3VnaCBub3QgaW5jbHVkZWQgaW4gdGhlIGhhc2ggY29tcHV0YXRpb24uDQog DQo4LjMgT24td2lyZSBQcm90b2NvbCBMYXllcg0KDQoNClRoZSBwdXJwb3NlIG9mIHRoZSB0 aGlyZCBsYXllciBpcyB0byB2ZXJpZnkgcHJvdG9jb2wgb3BlcmF0aW9ucyBjb25zaXN0ZW50 IHdpdGggdGhlIG9uLXdpcmUgcHJvdG9jb2wuIFRoZSBwcm90b2NvbCBkaXNjYXJkcyBib2d1 cyBhbmQgZHVwbGljYXRlIHBhY2tldHMgYXMgd2VsbCBhcyBtaW5pbWl6ZXMgZGlzcnVwdGlv bnMgZHVlIHRvIHByb3RvY29sIHJlc3RhcnRzIGFuZCBkcm9wcGVkIHBhY2tldHMuIFRoZSBv cGVyYXRpb25zIGFyZSBjb250cm9sbGVkIGJ5IHR3byB0aW1lc3RhbXBzOiB0aGUgdHJhbnNt aXQgdGltZXN0YW1wIHNhdmVkIGluIHRoZSBjbGllbnQgc3RhdGUgdmFyaWFibGVzIGFuZCB0 aGUgb3JpZ2luIHRpbWVzdGFtcCBpbiB0aGUgc2VydmVyIHBhY2tldCBoZWFkZXIuIFRoZSBj b21wYXJpc29uIG9mIHRoZXNlIHR3byB0aW1lc3RhbXBzIGlzIGNhbGxlZCB0aGUgbG9vcGJh Y2sgdGVzdC4gVGhlIHRyYW5zbWl0IHRpbWVzdGFtcCBmdW5jdGlvbnMgYXMgYSBub25jZSB0 byB2ZXJpZnkgdGhhdCB0aGUgcmVzcG9uc2UgY29ycmVzcG9uZHMgdG8gdGhlIG9yaWdpbmFs IHJlcXVlc3QuIFRoZSB0cmFuc21pdCB0aW1lc3RhbXAgYWxzbyBzZXJ2ZXMgdG8gZGlzY2Fy ZCByZXBsYXlzIG9mIHRoZSBtb3N0IHJlY2VudCByZXNwb25zZS4NCg0KDQpVcG9uIGZhaWx1 cmUgb2YgZWl0aGVyIHRlc3QsIHRoZSBwYWNrZXQgaXMgZGlzY2FyZGVkIHdpdGggbm8gZnVy dGhlciBhY3Rpb24uIEluIG9yZGVyIHRvIHJlZHVjZSByb3VuZG9mZiBlcnJvcnMgYW5kIGlt cHJvdmUgc2VjdXJpdHksIHRoZSBsb3cgb3JkZXIgbm9uc2lnbmlmaWNhbnQgYml0cyBvZiB0 aGUgdGltZXN0YW1wIGFyZSByZXBsYWNlZCBieSBhIHJhbmRvbSBiaXQgc3RyaW5nLiBUaGUg dHJhbnNtaXQgdGltZXN0YW1wIG1pZ2h0IG5vdCBiZSBjb25zaWRlcmVkIHN1ZmZpY2llbnRs eSByYW5kb20gYXMgYSBub25jZS4gSG93ZXZlciwgdGhlIHRpbWVzdGFtcHMgYXJlIGFsd2F5 cyBpbmNyZWFzaW5nLCBldmVuIGlmIGJ5IGEgc21hbGwgYW1vdW50LCBhbmQgdGhlIHRpbWVz dGFtcHMgYXJlIG5ldmVyIHByZWRpY3RhYmxlLiBUaGVyZWZvcmUsIGluIHRoaXMgcHJvcG9z YWwsIHRyYW5zbWl0IHRpbWVzdGFtcHMgYXJlIGNvbnNpZGVyZWQgdmFsaWQgbm9uY2VzLg0K DQoNCkFuIGltcG9ydGFudCBmdW5jdGlvbiBvZiB0aGUgb24td2lyZSBsYXllciBpcyBjb2xs ZWN0aW9uIG9mIHBhY2tldCB0aW1lc3RhbXBzLCBib3RoIGlucHV0IGFuZCBvdXRwdXQuIFRo ZXJlIGFyZSB0aHJlZSBraW5kcyBvZiB0aW1lc3RhbXBzLCBpbiBvcmRlciBvZiBpbmNyZWFz aW5nIGFjY3VyYWN5OiBzb2Z0c3RhbXBzLCBkcml2ZXN0YW1wcyBhbmQgaGFyZHN0YW1wcy4g VGhlc2UgYXJlIGRldGVybWluZWQgYnkgcmVhZGluZyB0aGUgc3lzdGVtIGNsb2NrIGF0IHNw ZWNpZmllZCBwcm90b2NvbCBldmVudHMuIFNvZnRzdGFtcHMgYXJlIGRldGVybWluZWQgd2hl biBhIHBhY2tldCBpcyByZW1vdmVkIGZyb20gdGhlIGlucHV0IHF1ZXVlIGFuZCB3aGVuIGEg cGFja2V0IGlzIGFkZGVkIHRvIHRoZSBvdXRwdXQgcXVldWUuIERyaXZlc3RhbXBzIGFyZSBk ZXRlcm1pbmVkIGF0IHRoZSB0aW1lIG9mIHRoZSBkZXZpY2UgaW50ZXJydXB0IGF0IHRoZSBl bmQgb2YgdGhlIHBhY2tldC4gVGhleSBhcmUgdXNlZCBieSB0aGUgcmVmZXJlbmNlIGltcGxl bWVudGF0aW9uIGFuZCBpbiBwYXJ0aWN1bGFyIHRoZSBpbnRlcmxlYXZlIHByb3RvY29sLiBI YXJkc3RhbXBzIGFyZSBpbnN0YW50aWF0ZWQgYXQgc3BlY2lmaWMgZXZlbnRzIGRldGVybWlu ZWQgYnkgc3BlY2lhbGl6ZWQgaW50ZXJmYWNlIGhhcmR3YXJlLiBUaGV5IGFyZSBub3QgdXNl ZCBpbiB0aGUgY3VycmVudCByZWZlcmVuY2UgaW1wbGVtZW50YXRpb24uDQoNCg0KRHJpdmVz dGFtcHMgYXJlIHRoZSBtYWluIGRldGVybWluYW50IG9mIHRpbWVrZWVwaW5nIGFjY3VyYWN5 LiBUaGV5IG11c3QgYmUgY29sbGVjdGVkIGF0IHRoZSBkZXZpY2UgbGF5ZXIgYW5kIHBhc3Nl ZCB1cHdhcmQgaW4gdGhlIGlucHV0IHBhY2tldCBidWZmZXIgb3IgYXQgdGhlIGVuZCBvZiB0 aGUgb3V0cHV0IG9wZXJhdGlvbi4gVGhpcyBjYW4gY29tcGxpY2F0ZSB0aGUgc2VjdXJpdHkg cHJvdG9jb2wsIGVzcGVjaWFsbHkgaWYgdXNpbmcgYSBwcmVwYWNrYWdlZCBpbXBsZW1lbnRh dGlvbi4NCg0KDQo4LjQgUHVibGljIEtleSBMYXllcg0KDQoNClRoZSBmb3VydGggbGF5ZXIg Y29uc3RydWN0cyBhbmQgYXV0aGVudGljYXRlcyB0aGUgc2hhcmVkIGhhc2gga2V5IGFuZCBj ZXJ0aWZpY2F0ZSB0cmFpbCB0byB0aGUgY2VydGlmaWNhdGUgYXV0aG9yaXR5IGhvc3QuIFRo ZSBiYXNpYyBwcm90b2NvbCBkYW5jZSBiZWdpbnMgd2l0aCBhIHBhcmFtZXRlciBleGNoYW5n ZSBmb2xsb3dlZCBieSBhIGNvb2tpZSBleGNoYW5nZSBhbmQgc2lnbiBleGNoYW5nZSwgYXMg cmVxdWlyZWQuIFRoZXNlIGV4Y2hhbmdlcyBwZXJmb3JtIGEgZnVuY3Rpb24gc2ltaWxhciB0 byB0aGUgVExTIGFuZCBEVExTIGhhbmRzaGFrZS4NCg0KDQpJdCBpcyBpbXBvcnRhbnQgdG8g bWluaW1pemUgdGhlIG51bWJlciBvZiBleGNoYW5nZXMgaW4gb3JkZXIgdG8gbWluaW1pemUg dGhlIGxhdGVuY3kgdG8gYWNxdWlyZSB0aGUgdGltZSBhbmQgYXV0aGVudGljYXRlIHRoZSBz ZXJ2ZXIuIE9yZGluYXJpbHksIHRoZSB0aW1lIGlzIGFjcXVpcmVkIHdpdGhpbiBzaXggTlRQ IHJvdW5kcyBhdCB0aGUgcmF0ZSBvZiBvbmUgcm91bmQgZXZlcnkgdHdvIHNlY29uZHMuIFRo ZSBhdXRoZW50aWNhdGlvbiBkYW5jZSBpcyBwaWdneWJhY2tlZCBvbiB0aGVzZSByb3VuZHMu IFdpdGggdGhlIHByb3RvY29sIG91dGxpbmVkIGluIHRoaXMgcHJvcG9zYWwsIGF1dGhlbnRp Y2l0eSBjYW4gYmUgY29uZmlybWVkIHdpdGhpbiBmb3VyIHJvdW5kcy4NCg0KDQpUaGUgcGFy YW1ldGVyIGV4Y2hhbmdlIGluY2x1ZGVzIHRoZSBzdWJqZWN0IG5hbWUgb24gdGhlIGhvc3Qg Y2VydGlmaWNhdGUsIGFzIHdlbGwgYXMgdGhlIHNlbGVjdGVkIGFsZ29yaXRobSBhbmQgb3Ro ZXIgcGFyYW1ldGVycy4gVGhlIGNvb2tpZSBleGNoYW5nZSBkZXZlbG9wcyBhbmQgdmVyaWZp ZXMgdGhlIHNoYXJlZCBoYXNoIGtleSBhbmQgc2lnbmF0dXJlLiBUaGUgcGFyYW1ldGVyIGFu ZCBjb29raWUgZXhjaGFuZ2VzIGFyZSBzZW50IHdpdGggYSBzaGFyZWQgaGFzaCBrZXkgemVy by4gVGhlIHNpZ24gZXhjaGFuZ2UgY29uc3RydWN0cyBvciB2ZXJpZmllcyB0aGUgcHVibGlj IGtleSBzaWduYXR1cmUgb24gdGhlIGhvc3QgY2VydGlmaWNhdGUuIFRoZSBhZ3JlZWQgaGFz aCBrZXkgZGV2ZWxvcGVkIGR1cmluZyB0aGUgY29va2llIGV4Y2hhbmdlIGlzIHVzZWQgZm9y IHRoZSBzaWduIGV4Y2hhbmdlIGFuZCBzdWJzZXF1ZW50IE5UUCBwYWNrZXRzLg0KDQoNClRo ZSBjZXJ0aWZpY2F0ZSBhdXRob3JpdHkgaG9zdCBpcyBkZXNpZ25hdGVkIGVpdGhlciBhcyBh IHNlbGYtc2lnbmVkIGNlcnRpZmljYXRlIG9yIGJ5IGFuIGlkZW50aWZpZXIgaW4gdGhlIHg1 MDl2MyBleHRlbnNpb24gZmllbGQuIEhvc3QgY2VydGlmaWNhdGVzIGFyZSBleGNoYW5nZWQg dXNpbmcgdGhlIGNlcnRpZmljYXRlIGV4Y2hhbmdlLCB3aXRoIG5ldyBjZXJ0aWZpY2F0ZXMg cmVwbGFjaW5nIG9sZCBvbmVzIHdpdGggdGhlIHNhbWUgc3ViamVjdCBhbmQgaXNzdWVyIG5h bWVzLg0KDQoNCkJ5IGRlZmF1bHQsIHRoZSBzdWJqZWN0IG5hbWUgb24gdGhlIGNlcnRpZmlj YXRlIGlzIHRoZSBzdHJpbmcgcmV0dXJuZWQgYnkgdGhlIFVuaXggZ2V0aG9zdGJ5bmFtZSBs aWJyYXJ5IHJvdXRpbmUuIFRoZSBzdWJqZWN0IG5hbWUgb24gdGhlIGNlcnRpZmljYXRlIGF1 dGhvcml0eSBpcyBpbnRlcnByZXRlZCBhcyB0aGUgZ3JvdXAgbmFtZSBhc3NvY2lhdGVkIHdp dGggdGhlIHBhcnRpY3VsYXIgdHJhaWwgYW5kIGlzIHVzZWZ1bCBpbiB0aGUgaWRlbnRpdHkg ZXhjaGFuZ2Ugb3IgZXF1aXZhbGVudCBzY2hlbWUuDQoNCg0KVGhlIGNlcnRpZmljYXRlIHRy YWlsIGlzIGNvbnN0cnVjdGVkIHN0ZXAgYnkgc3RlcCBmb3IgZWFjaCBhc3NvY2lhdGlvbiwg d2l0aCB0aGUgaXNzdWVyIG5hbWUgcmVwbGFjaW5nIHRoZSBzdWJqZWN0IG5hbWUgYXQgZWFj aCBzdGVwLiBOb3RlIHRoYXQgZWFjaCBzdGVwIGludm9sdmVzIGEgc2luZ2xlIHNpZ25hdHVy ZSwgc28gZG9lcyBub3QgY29uc3RydWN0IHRoZSBlbnRpcmUgdHJhaWwuDQoNCg0KT25jZSB0 aGUgY2VydGlmaWNhdGUgdHJhaWwgaGFzIGJlZW4gdmVyaWZpZWQsIGl0IGlzIG5vdCBuZWNl c3NhcnkgdG8gZG8gaXQgYWdhaW4sIHVubGVzcyBhIGNlcnRpZmljYXRlIGlzIHJldm9rZWQg b3IgcmVhY2hlcyBhZHZhbmNlZCBhZ2UuIE5vdGUgdGhhdCBlYWNoIGFzc29jaWF0aW9uIG1p Z2h0IGhhdmUgZGlmZmVyZW50IGlzc3VlciBhbmQgc3ViamVjdCBuYW1lcy4NCg0KDQpBcyBw YXJ0IG9mIHRoZSBpbml0aWFsaXphdGlvbiBwcm9jZXNzLCBhIHNlbGYtc2lnbmVkIGhvc3Qg Y2VydGlmaWNhdGUgaXMgZ2VuZXJhdGVkIGZvciB1c2UgYnkgZWFjaCBhc3NvY2lhdGlvbi4g SWYgdGhlIGhvc3QgY2VydGlmaWNhdGUgaGFzIG5vdCBiZWVuIHNpZ25lZCBieSB0aGUgc2Vy dmVyIGZvciBlYWNoIGFzc29jaWF0aW9uLCB0aGUgaG9zdCBjZXJ0aWZpY2F0ZSBpcyBwcm92 aWRlZCB0byBlYWNoIGFzc29jaWF0aW9uIHNlcnZlciBmb3Igc2lnbmF0dXJlLiBUaGlzIGlz IGNhbGxlZCB0aGUgc2lnbiBleGNoYW5nZSBhbmQgbmVlZHMgdG8gYmUgZG9uZSBvbmx5IG9u Y2UgZm9yIGVhY2ggYXNzb2NpYXRpb24uIE5vdGUgdGhhdCB0aGUgbmV4dCBkb3duc3RyZWFt IGhvc3QgaGFzIHRoZSBjaG9pY2Ugb2Ygc2lnbmVkIGNlcnRpZmljYXRlcywgYnV0IHRoZXkg YXJlIGFsbCBlcXVpdmFsZW50Lg0KDQoNCk9uY2UgdGhlIGNlcnRpZmljYXRlIHRyYWlsIHNp Z25hdHVyZXMgaGF2ZSBiZWVuIHZlcmlmaWVkLCB0aGUgaG9zdCBjZXJ0aWZpY2F0ZSBpcyBj b25zaWRlcmVkIGF1dGhlbnRpYywgdW5sZXNzIGEgY2VydGlmaWNhdGUgaGFzIGJlZW4gY2hh bmdlZC4gVGhlIHJlY292ZXJ5IHNjaGVtZSB0byB1cGRhdGUgdGhlIGNlcnRpZmljYXRlIHRy YWlsIGNvdWxkIGJlIHRlZGlvdXMsIGFzIGRlc2NyaWJlZCBiZWxvdy4gTm90ZSB0aGF0IHRo ZXJlIGFyZSBubyBwcm92aXNpb25zIGluIHRoZSBzZWN1cml0eSBzY2hlbWUgdG8gcmV2b2tl IGEgY2VydGlmaWNhdGUsIHNvIHRoaXMgbXVzdCBiZSBkb25lIGJ5IGV4dGVybmFsIG1lYW5z Lg0KDQoNCkluIHRoZSBmb2xsb3dpbmcsIHRoZSBob3N0IGNlcnRpZmljYXRlIGJlbG9uZ3Mg dG8gdGhlIGhvc3QgY29udGFpbmluZyB0aGUgcHVibGljL3ByaXZhdGUga2V5cywgd2hpbGUg YSBzZXJ2ZXIgY2VydGlmaWNhdGUgYmVsb25ncyB0byBlYWNoIGFzc29jaWF0aW9uIHNlcGFy YXRlbHkuIE9uY2UgdGhlIGNvb2tpZSBleGNoYW5nZSBoYXMgY29tcGxldGVkLCB0aGUgc2hh cmVkIGhhc2gga2V5IGNhbiBiZSB1c2VkIGZvciBhdXRoZW50aWNhdGlvbiBvZiBhbGwgc3Vi c2VxdWVudCBwYWNrZXRzLg0KDQoNCkZvciB0aGlzIHB1cnBvc2UsIHRoZSBjb29raWUgZXhj aGFuZ2UgaXMgc3BsaXQgaW50byB0d28gcGhhc2VzOiB0aGUgYWdyZWVtZW50IHBoYXNlLCB3 aGljaCBkZXZlbG9wcyB0aGUgc2hhcmVkIGhhc2gga2V5LCBhbmQgdGhlIGF1dGhlbnRpY2F0 aW9uIHBoYXNlLCB3aGljaCBhdXRoZW50aWNhdGVzIHRoZSBoYXNoIGtleS4gVGhlIGNlcnRp ZmljYXRlIGV4Y2hhbmdlIG9idGFpbnMgdGhlIHNlcnZlciBjZXJ0aWZpY2F0ZSBhZnRlciB0 aGUgYWdyZWVtZW50IHBoYXNlIGFuZCBiZWZvcmUgdGhlIGF1dGhlbnRpY2F0aW9uIHBoYXNl LiAgIE9yZGluYXJpbHksIHRoZSBjZXJ0aWZpY2F0ZSBleGNoYW5nZSBuZWVkcyB0byBiZSBk b25lDQpvbmx5IG9uY2UsIHVubGVzcyB0aGUgY2VydGlmaWNhdGUgaXMgY2hhbmdlZC4gIEVh Y2ggcGhhc2UgaXMgcmVwcmVzZW50ZWQgYnkgYW4gZXhjaGFuZ2Ugb2YgdGhlIHNhbWUgbmFt ZS4NCg0KDQpJbiBzeW1tZXRyaWMgbW9kZSB0aGUgYWdyZWVtZW50IHBoYXNlIHVzZXMgdGhl IGNsYXNzaWMgRGlmZmllLUhlbGxtYW4gYWxnb3JpdGhtLiBJbiBjbGllbnQvc2VydmVyIG1v ZGUgdGhlIGtleSBpcyBhIGNvb2tpZSwgYXMgZGVzY3JpYmVkIGJlbG93LiBJbiB0aGlzIHBo YXNlIGFuZCB0aGUgcGFyYW1ldGVyIGV4Y2hhbmdlLCB0aGUgZXhjaGFuZ2UgdXNlcyBrZXkg emVybywgYXMgZGVzY3JpYmVkIGFib3ZlLiBUaGUgYXV0aGVudGljYXRpb24gcGhhc2UgY29u c2lzdHMgb2YgYW4gZXhjaGFuZ2Ugb2YgaGFzaCBrZXkgc2lnbmF0dXJlcy4NCg0KDQpUaGUg YXNzb2NpYXRpb24gaXMgY29uc2lkZXJlZCBwcm92aXNpb25hbGx5IGF1dGhlbnRpYyBmb2xs b3dpbmcgdGhlIGF1dGhlbnRpY2F0aW9uIHBoYXNlIG9mIHRoZSBjb29raWUgZXhjaGFuZ2Uu IFRoZSBzaWduYXR1cmUgdHJhaWwgaXMgYXVnbWVudGVkIGluIHRoZSBzaWduIGV4Y2hhbmdl LiBJZiBzdWNjZXNzZnVsLCB0aGUgY2VydGlmaWNhdGUgdHJhaWwgaXMgZXh0ZW5kZWQgYnkg b25lIHN0ZXA7IGlmIG5vdCwgdGhlIGFzc29jaWF0aW9uIHRyaWVzIGFnYWluIGFmdGVyIHRp bWVvdXQuDQoNCg0KVGhlIHNlcXVlbmNlIG9mIG1lc3NhZ2VzIGluIHRoZSBwcm90b2NvbCBk YW5jZSBjYW4gYmVzdCBiZSBtYW5hZ2VkIGJ5IGFwcHJvcHJpYXRlIHN0YXRlIHRyYW5zaXRp b24gdGFibGVzLiBUaGVzZSBkYW5jZXMgYXJlIHNpbWlsYXIsIGJ1dCBub3QgaWRlbnRpY2Fs LCB0byB0aGUgb25lcyB1c2VkIGZvciBzaW1pbGFyIHB1cnBvc2VzIGluIHRoZSBSRkM1OTA2 IEF1dG9rZXkgaW1wbGVtZW50YXRpb24gYW5kIHRoZSBOVFMgcHJvcG9zYWxzLg0KDQoNCkEg c3VidGxlIGRpZmZlcmVuY2UgYmV0d2VlbiB0aGlzIHByb3Bvc2FsIGFuZCB0aGUgTlRTIHBy b3Bvc2FscyBpcyBob3cgdG8gaW50ZXJwcmV0IHRoZSBwYXJhbWV0ZXIgZXhjaGFuZ2UgZGF0 YS4gVGhlIGludGVudCBpcyB0aGF0IGVhY2ggcGVlci9jbGllbnQgaGFzIGEgcHJpdmF0ZSB2 ZWN0b3Igb2YgY29tcG9uZW50cywgYW5kIGVhY2ggcGVlci9zZXJ2ZXIgaGFzIGEgc2ltaWxh ciB2ZWN0b3Igb2YgY29tcG9uZW50cy4gVGhlIHBhcmFtZXRlciBleGNoYW5nZSBhcHBlbmRz IHRoZSB2ZWN0b3Igb2Ygb25lIHBhcnRpY2lwYW50IHRvIHRoZSB2ZWN0b3Igb2YgdGhlIG90 aGVyIHBhcnRpY2lwYW50LiBUaGVuLCB0aGUgd29ya2luZyB2ZWN0b3IgaXMgZGVyaXZlZCBp biBlYWNoIHBhcnRpY2lwYW50IGJ5IHRoZSBzYW1lIGFsZ29yaXRobS4gVGhlIHJlc3VsdCBh cHBsaWVzIHRvIGJvdGggc3ltbWV0cmljIGFuZCBjbGllbnQvc2VydmVyIG1vZGVzLCBhbHRo b3VnaCB0aGUgcmVzdWx0cyBhcmUgbm90IHNhdmVkIGluIHNlcnZlciBtb2RlLiBBIHZlY3Rv ciBjb21wb25lbnQgY29uc2lzdHMgb2YgdHVwbGVzIG9mIHJhbmsvbmlkIHZhbHVlcyBvciBh bnl0aGluZyBlbHNlIHRoYXQgY2FuIGJlIHJlcHJlc2VudGVkIGluIEFTTi4xIGVuY29kaW5n Lg0KDQoNClRoZSBjaG9pY2Ugb2YgZGFuY2UgaXMgZGV0ZXJtaW5lZCBieSB0aGUgTlRQIG1v ZGU6IGNsaWVudC9zZXJ2ZXIsIHN5bW1ldHJpYyBvciAgYnJvYWRjYXN0LiBUaGUgYWJvdmUg c2VxdWVuY2Ugb2YgZXhjaGFuZ2VzIGlzIGlkZW50aWNhbCBmb3IgY2xpZW50IGFuZCBzeW1t ZXRyaWMgbW9kZXMsIGFzIHdlbGwgYXMgb3B0aW9uYWwgYnJvYWRjYXN0IGRlbGF5IG1lYXN1 cmVtZW50LCBpZiB1c2VkLiBOb3RlIHRoYXQgdGhlIHNpZ25hdHVyZSBzY2hlbWUgaXMgZGVm aW5lZCBvbiBlYWNoIGNlcnRpZmljYXRlLiBPdGhlcndpc2UsIHRoZSBhZ3JlZW1lbnQsIGhh c2gsIHNpZ25hdHVyZSBhbmQgZW5jcnlwdGlvbiBhbGdvcml0aG0gaWRlbnRpZmllcnMgZGVm YXVsdCBhcyBpbiB0aGUgcGFyYW1ldGVyIGV4Y2hhbmdlLg0KDQoNCkEgc3VidGxlIGNvbXBs aWNhdGlvbiBpcyBob3cgdG8gdmFsaWRhdGUgdGhlIGxpZmV0aW1lIG9mIHRoZSBjZXJ0aWZp Y2F0ZXMgYWxvbmcgdGhlIHRyYWlsIHRvIHRoZSBjZXJ0aWZpY2F0ZSBhdXRob3JpdHkuIFRo ZSBsaWZldGltZSBvZiB0aGUgc3ViamVjdCBjZXJ0aWZpY2F0ZSBpbnRlcnNlY3RlZCB3aXRo IHRoZSBsaWZldGltZSBvZiB0aGUgaXNzdWVyIGNlcnRpZmljYXRlIG1pZ2h0IG9yIG1pZ2h0 IG5vdCBiZSBlbXB0eS4gSG93ZXZlciwgdGhlIGxpZmV0aW1lIG9mIHRoZSBzZXJ2ZXIgY2Vy dGlmaWNhdGUgbXVzdCBjb250YWluIHRoZSBjdXJyZW50IHZhbGlkIHRpbWUuDQoNCg0KVGhl IG9ydGhvZG94IHdheSBpcyB0byB3YWl0IHVudGlsIHRoZSBhc3NvY2lhdGlvbiB0aW1lIGlz IHZhbGlkLCB0aGVuIGNvbXBhcmUgdGhlIHZhbGlkIHRpbWUgd2l0aCB0aGUgY2VydGlmaWNh dGUgbGlmZXRpbWUuIEEgZGlzY3JlcGFuY3kgcmVzdWx0cyBpbiBhIHByb3RvY29sIHJlc3Rh cnQuIE5vdGUgdGhhdCBhIG5ldyByZWdlbmVyYXRlZCBjZXJ0aWZpY2F0ZSBtaWdodCByZXF1 aXJlIGEgbmV3IGdlbmVyYXRpb24gb2YgaXRzIGlzc3Vlci4gVGhlIGltcGxpY2F0aW9ucyBt YXkgYmUgdGVkaW91cy4NCg0KDQpUaGUgZGFuY2VzIGludm9sdmUgYSBiYWxhbmNlIGJldHdl ZW4gZm9ybWFsIGF1dGhlbnRpY2F0aW9uIGFuZCBkdXJhdGlvbiBvZiB0aGUgcHJvdG9jb2wu IEZvciBpbnN0YW5jZSwgdGhlIGNvb2tpZSBleGNoYW5nZSBjb25maXJtcyB0aGF0IHRoZSBo YXNoIGtleSBpcyB2YWxpZCwgYnV0IGRvZXMgbm90IG5lY2Vzc2FyaWx5IGNvbmZpcm0gdGhh dCB0aGUgY2VydGlmaWNhdGUgdHJhaWwgaXMgdmFsaWQuIEEgc3VjY2Vzc2Z1bCBzaWduYXR1 cmUgb2YgdGhlIGhvc3QgY2VydGlmaWNhdGUgY29uZmlybXMgdGhhdCB0aGUgaG9zdCBjZXJ0 aWZpY2F0ZSBpcyB2YWxpZC4gVGhlcmUgaXMgYW4gaW50ZXJ2YWwgYmV0d2VlbiB2YWxpZGF0 aW9uIG9mIHRoZSBzaGFyZWQgaGFzaCBrZXkgYW5kIHZhbGlkYXRpb24gb2YgdGhlIGNlcnRp ZmljYXRlIHRyYWlsIGJ1dCB0aGUgdGltZSBpbmZvcm1hdGlvbiBtYXkgb3IgbWF5IG5vdCBi ZSBjb3JyZWN0Lg0KDQoNCk5vdGUgdGhhdCBlYWNoIGNvbXBsZXRpb24gb2YgdGhlIGRhbmNl IHJlc3VsdHMgaW4gYSBuZXcgc2hhcmVkIGhhc2gga2V5IHVucmVsYXRlZCB0byB0aGUgbGFz dCBzaGFyZWQgaGFzaCBrZXkuIEluIHRoaXMgc2Vuc2UsIHRoZSBwcm90b2NvbCBoYXMgcGVy ZmVjdCBmb3J3YXJkIHNlY3JlY3kuDQoNCg0KV2Ugd2lsbCBub3cgZGVzY3JpYmUgdGhlIGRh bmNlcyBmb3IgU3ltbWV0cmljLCBDbGllbnQvU2VydmVyLCBhbmQgQnJvYWRjYXN0IE1vZGVz Lg0KDQoNCjguNC4xIFN5bW1ldHJpYyBNb2RlDQoNCg0KVGhlIGdvYWwgb2YgdGhpcyBkYW5j ZSBpcyB0byBpbnN0YWxsIGlkZW50aWNhbCBzaGFyZWQgaGFzaCBrZXlzIGluIGJvdGggcGVl cnMuIFRoZSBkYW5jZSBjYW4gYmUgc3RhcnRlZCBieSBlaXRoZXIgcGVlci4gUGVlcnMgQWxp Y2UgYW5kIEJvYiB1c2UgbGFyZ2UgcHJpbWUgcCBhcyBtb2R1bHVzIGFuZCBwcmltaXRpdmUg cm9vdCBnIGFzIGdlbmVyYXRvci4gQSBzbWFsbCB2YWx1ZSBmb3IgZywgdHlwaWNhbGx5IDIs IGlzIG9mdGVuIHVzZWQuDQoNCg0KSW4gdGhlIGFncmVlbWVudCBwaGFzZSwgQWxpY2Ugc2Vu ZHMgaGVyIHB1YmxpYyBESCBrZXkgdG8gQm9iIGluIGFuIGV4dGVuc2lvbiBmaWVsZCBvZiBh IHJlcXVlc3QgbWVzc2FnZS4gQm9iIGNvbnN0cnVjdHMgaGlzIHB1YmxpYyBESCBrZXkgYW5k IHNlbmRzIGl0IHRvIEFsaWNlIGluIGFuIGV4dGVuc2lvbiBmaWVsZCBvZiBhIHJlc3BvbnNl IG1lc3NhZ2UuIEJvdGggQWxpY2UgYW5kIEJvYiB0aGVuIGNvbnN0cnVjdCB0aGUgc2hhcmVk IGhhc2gga2V5IGZvciB1c2UgbGF0ZXIuDQoNCg0KSW4gdGhlIGF1dGhlbnRpY2F0aW9uIHBo YXNlLCBBbGljZSBzZW5kcyBoZXIgc2lnbmF0dXJlIG9mIHRoZSBzaGFyZWQgaGFzaCBrZXkg dG8gQm9iLiBCb2IgdmVyaWZpZXMgdGhlIHNpZ25hdHVyZSwgdGhlbiBzZW5kcyBoaXMgc2ln bmF0dXJlIG9mIHRoZSBzaGFyZWQgaGFzaCBrZXkgdG8gQWxpY2UuIEFsaWNlIHZlcmlmaWVz IGhpcyBzaWduYXR1cmUuIEZhaWx1cmUgdG8gdmFsaWRhdGUgZWl0aGVyIHNpZ25hdHVyZSBy ZXN1bHRzIGluIGEgY3J5cHRvLU5BSyBhbmQgcHJvdG9jb2wgcmVzdGFydC4NCg0KDQpUaGUg c2hhcmVkIGtleSBjb25zdHJ1Y3RlZCBieSBBbGljZSBhbmQgQm9iIGlzIHVzZWQgYXMgdGhl IGhhc2gga2V5IGluIHN1YnNlcXVlbnQgbWVzc2FnZXMuIFRoZSBwdWJsaWMgYW5kIHByaXZh dGUgREgga2V5cyBhcmUgZXhwdW5nZWQgYWZ0ZXIgdXNlOyB0aGV5IGFyZSB1c2VkIG9ubHkg b25jZS4NCg0KDQo4LjQuMiBDbGllbnQvU2VydmVyIE1vZGUNCg0KDQpUaGUgZ29hbCBpbiB0 aGlzIGRhbmNlIGlzIHRvIGluc3RhbGwgYSBzZXJ2ZXIgY29va2llIHVzZWQgaW4gdGhlIGNs aWVudCBhcyB0aGUgaGFzaCBrZXkuIFRoZSBkYW5jZSBpcyBzdGFydGVkIGJ5IHRoZSBjbGll bnQuIFRoZSBjb29raWUgY2FuIGJlIHJlZ2VuZXJhdGVkIGJ5IHRoZSBzZXJ2ZXIgdXBvbiBh cnJpdmFsIG9mIGEgY2xpZW50IHBhY2tldC4gVGhlIGNvb2tpZSBleGNoYW5nZSBpcyBzaW1p bGFyIHRvIHRoZSBjb29raWUgZXhjaGFuZ2UgcHJvcG9zZWQgaW4gdGhlIE5UUyBkb2N1bWVu dHMsIGV4Y2VwdCB0aGF0IHRoZSBwcm9wb3NlZCBjb29raWUgZXhjaGFuZ2UgaXMgcHJvdGVj dGVkIGJ5IGtleSB6ZXJvIGFuZCB0aGUgb24td2lyZSBwcm90b2NvbCBsYXllci4NCg0KDQpJ biB0aGUgYWdyZWVtZW50IHBoYXNlLCBjbGllbnQgQWxpY2Ugc2VuZHMgaGVyIHB1YmxpYyBE SCBrZXkgdG8gc2VydmVyIEJvYi4gQm9iIHRoZW4gc2VuZHMgaGlzIHB1YmxpYyBESCBrZXkg dG8gQWxpY2UuIEJvdGggQWxpY2UgYW5kIEJvYiBjb25zdHJ1Y3QgdGhlIHNoYXJlZCBrZXkg YXMgZGVzY3JpYmVkIGFib3ZlLiBBbGljZSBhbmQgQm9iIHVzZSB0aGUgc2hhcmVkIGtleSBh cyB0aGUgZW5jcnlwdGlvbiBrZXkgdXNlZCBsYXRlci4NCg0KDQpUaGUgY29va2llIGlzIHRo ZSBoYXNoIG9mIHRoZSBjbGllbnQgSVAgYWRkcmVzc2VzIGNvbmNhdGVuYXRlZCB3aXRoIGEg c2VydmVyIHNlY3JldCBrZXkgdXNpbmcgdGhlIHNlbGVjdGVkIGhhc2ggYWxnb3JpdGhtLiBU aGUgc2VydmVyIHNlY3JldCBrZXkgaXMgYSByYW5kb20gbnVtYmVyIHJlZ2VuZXJhdGVkIGFi b3V0IG9uY2UgcGVyIGRheS4gQm9iIGVuY3J5cHRzIHRoZSBjb29raWUgdXNpbmcgdGhlIGFi b3ZlIGtleSBhbmQgc2VuZHMgaXQgaW4gdGhlIHNhbWUgcmVzcG9uc2UgYXMgdGhlIERIIHB1 YmxpYyBrZXkgYWJvdmUuDQoNCg0KVGhlIGF1dGhlbnRpY2F0aW9uIHBoYXNlIHVzZXMgdGhl IHNhbWUgc2lnbmF0dXJlcyBhcyBpbiBzeW1tZXRyaWMgbW9kZS4gQXMgYW4gb3B0aW9uYWwg ZW1iZWxsaXNobWVudCwgaWYgdGhlIHNlcnZlciBoYXMgdGhlIHB1YmxpYyBjZXJ0aWZpY2F0 ZSBvZiB0aGUgY2xpZW50LCB0aGlzIGF1dGhlbnRpY2F0ZXMgdGhlIGNsaWVudCB0byB0aGUg c2VydmVyIGFzIHdlbGwuDQoNCg0KQXMgYW4gb3B0aW9uYWwgZmVhdHVyZSwgYSBub25jZSBj YW4gYmUgY29uY2F0ZW5hdGVkIHdpdGggdGhlIGNvb2tpZSBhbmQgdGhlDQp3b3JraW5nIGNv b2tpZSBhcyB0aGUgaGFzaCBvZiB0aGUgcmVzdWx0LiAgVGhlIG5vbmNlIGNhbiBiZSBkZXRl cm1pbmVkIGJ5IHRoZQ0KdHJhbnNtaXQgdGltZXN0YW1wIG9yIHRoZSBrZXkgaWQgZmllbGQg b2YgdGhlIE1BQy4gIE90aGVyIHNjaGVtZXMgY2FuIGJlDQpkZXZpc2VkLg0KDQoNCjguNC4z IEJyb2FkY2FzdCBNb2RlDQoNCg0KVGhlIG9yaWdpbmFsIEF1dG9rZXkgcHJvdG9jb2wgd2Fz IGJhc2VkIG9uIHRoZSBhc3N1bXB0aW9uIHRoYXQgdGhlIGNyeXB0b2dyYXBoaWMgYWxnb3Jp dGhtcyB3ZXJlIHZlcnkgc2xvdyBhbmQgdnVsbmVyYWJsZSB0byBhIGZsb29kaW5nIGF0dGFj ay4gSW4gZmFjdCwgdGhlIERpZmZpZS1IZWxsbWFuIGFncmVlbWVudCB0b29rIG92ZXIgMTAg c2Vjb25kcyBvbiBhIFN1biBJUEMuIEFzIGN1cnJlbnQgbWFjaGluZXMgYW5kIGFsZ29yaXRo bXMgYXJlIG11Y2ggZmFzdGVyLCBpdCBpcyBjb252ZW5pZW50IGZvciB0aGUgc2VydmVyIHRv IGNvbXB1dGUgdGhlIHNpZ25hdHVyZSBvZiB0aGUgTlRQIGhlYWRlciBpbiBhbiBleHRlbnNp b24gZmllbGQgYW5kIGZvciB0aGUgY2xpZW50IHRvIHZlcmlmeSB0aGUgc2lnbmF0dXJlIHVz aW5nIHRoZSBwdWJsaWMga2V5IG9uIHRoZSBzZXJ2ZXIgY2VydGlmaWNhdGUuIFRoZSBzZXJ2 ZXIgY2VydGlmaWNhdGUgbXVzdCBiZSBpbnN0YWxsZWQgYmVmb3JlaGFuZCBpbiBlYWNoIGNs aWVudC4gVGhpcyBpcyBub3QgYSB0cml2aWFsIHJlcXVpcmVtZW50OyB0aGUgY2VydGlmaWNh dGUgdHJhaWwgbXVzdCBiZSBjb25zdHJ1Y3RlZCBzZXBhcmF0ZWx5Lg0KDQoNCldoZW4gdHdv IG9yIG1vcmUgYnJvYWRjYXN0IGNsaWVudCBhc3NvY2lhdGlvbnMgYXJlIGluIHRoZSBzYW1l IGhvc3QsIGl0IGlzIGNvbnZlbmllbnQgdG8gaW5jbHVkZSB0aGUgY2VydGlmaWNhdGUgbmFt ZSBpbiBhbiBleHRlbnNpb24gZmllbGQgb2YgdGhlIGJyb2FkY2FzdCBwYWNrZXQuICBUaGlz IHNlbGVjdHMgdGhlIHNlcnZlciBjZXJ0aWZpY2F0ZSBhbmQgdGh1cyB0aGUgY29ycmVjdCBz aWduYXR1cmUga2V5Lg0KDQoNCkEgY29tbW9uIHByb2JsZW0gaW4gdGhpcyBhbmQgb3RoZXIg YnJvYWRjYXN0IHNjaGVtZXMgaXMgdnVsbmVyYWJpbGl0eSB0byBjb3BpZXMgb2Ygb2xkLCBv ciBwZXJoYXBzIHZlcnkgb2xkLCBtZXNzYWdlcy4gVGhlIHByb3Bvc2VkIHNvbHV0aW9uIGlz IHRvIHVzZSB0aGUgdHJhbnNtaXQgdGltZXN0YW1wIGFzIGEgc2VxdWVuY2UgbnVtYmVyIGFu ZCBvcmRlcmluZyBmdW5jdGlvbi4gQW4gb2xkIGR1cGxpY2F0ZSBpcyByZWNvZ25pemVkIGJ5 IGEgdHJhbnNtaXQgdGltZXN0YW1wIG9sZGVyIHRoYW4gdGhlIG1vc3QgcmVjZW50IHRyYW5z bWl0IHRpbWVzdGFtcC4gT25jZSB0aGUgZmlyc3QgcGFja2V0IGlzIHJlY2VpdmVkLCB0aGUg YnJvYWRjYXN0IGNsaWVudCBpZ25vcmVzIGFsbCBicm9hZGNhc3QgcGFja2V0cyB3aXRoIGFu IGVhcmxpZXIgdHJhbnNtaXQgdGltZXN0YW1wLiBUaGlzIGRlc2lnbiB3b3JrcyBldmVuIGlm IHRoZSBicm9hZGNhc3Qgc2VydmVyIGlzIHJlc3RhcnRlZC4gSWYgYSBicm9hZGNhc3QgY2xp ZW50IGlzIHJlc3RhcnRlZCwgdGhlcmUgbWlnaHQgYmUgc29tZSBzcHVyaW91cyBvbGQgZHVw bGljYXRlcyBiZWZvcmUgdGhlIGZpcnN0IG5ldyBtZXNzYWdlLiBJZiB0aGUgbW9zdCByZWNl bnQgdHJhbnNtaXQgdGltZXN0YW1wIGlzIHByZXNlcnZlZCBiZXR3ZWVuIHJlc3RhcnRzLCB0 aGVzZSBvbGQgZHVwbGljYXRlcyBhcmUgc3VwcHJlc3NlZC4NCg0KDQo5LiBFcnJvciBSZWNv dmVyeQ0KDQoNCk9uZSBvZiB0aGUgZmlyc3QgdGhpbmdzIGEgc3VzcGljaW91cyBjcnlwdG9n cmFwaGVyIGxvb2tzIGF0IGlzIHRoZSBzaXplIG9mIHRoZSBiaXQgc3RyaW5ncyB1c2VkIGlu IHRoZSBhdXRoZW50aWNhdGlvbiBzY2hlbWUuIEEgYnJ1dGUgZm9yY2UgYXR0YWNrIG9uIHRo ZSBzaGFyZWQgaGFzaCBrZXkgbWlnaHQgbm90IHdvcmsgaW4gYWxsIGNhc2VzLiBDb25zaWRl ciB0aGUgbnVtYmVyIGsgb2Ygc3B1cmlvdXMga2V5cyB0aGF0IGNvcnJlY3RseSBkZWNyeXB0 IGEgY2lwaGVydGV4dCBvZiBuIHN5bWJvbHMuIFRoZSBudW1iZXIgayBnZW5lcmFsbHkgZGVj cmVhc2VzIGFzIG4gaW5jcmVhc2VzLiBUaGUgbnVtYmVyIG9mIHN5bWJvbHMgbiB3aGVyZSBr IGRlY3JlYXNlcyB0byBvbmUgaXMgY2FsbGVkIHRoZSB1bmljaXR5IGRpc3RhbmNlLiBJZiB0 aGUgcGFja2V0IGxlbmd0aCBpcyBsZXNzIHRoYW4gdGhlIHVuaWNpdHkgZGlzdGFuY2UsIHRo aXMgbWVhbnMgdGhhdCBhIGtleSB0aGF0IGNvcnJlY3RseSBkZWNyeXB0cyBhIGNpcGhlcnRl eHQgeCBtYXkgbm90IGNvcnJlY3RseSBkZWNyeXB0IGEgY2lwaGVydGV4dCBvdGhlciB0aGFu IHguDQoNCg0KVGhlIHVzdWFsIHJlc3BvbnNlIHRvIGEgaGFzaCBvciBzaWduYXR1cmUgZmFp bHVyZSBpbiBzeW1tZXRyaWMgYW5kIHNlcnZlciBtb2RlcyBpcyB0byBzZW5kIGEgY3J5cHRv LU5BSyBhbmQgZGlzY2FyZCB0aGUgcGFja2V0LiBUaGUgY3J5cHRvLU5BSyBpcyBub3QgdXNl ZCBpbiBjbGllbnQgb3IgYnJvYWRjYXN0IG1vZGVzLg0KDQoNCklmIHRoZSBjcnlwdG8tTkFL IHJlc3VsdHMgZnJvbSBhIGhhc2ggZmFpbHVyZSwgb25seSB0aGUgYWdyZWVtZW50IHBoYXNl IG9mIHRoZSBjb29raWUgZXhjaGFuZ2UgaXMgbmVjZXNzYXJ5LiBJZiB0aGUgY3J5cHRvLU5B SyByZXN1bHRzIGZyb20gYSBzaWduYXR1cmUgZmFpbHVyZSwgdGhlIHByb3RvY29sIGlzIHJl c3RhcnRlZC4NCg0KDQpBbGwgbWVzc2FnZXMsIGluY2x1ZGluZyB0aGUgY3J5cHRvLU5BSywg YXJlIHZhbGlkYXRlZCBieSB0aGUgbG9vcGJhY2sgdGVzdCBvZiB0aGUgb24td2lyZSBwcm90 b2NvbC4gSW4gYWRkaXRpb24sIGFsbCBtZXNzYWdlcyBhZnRlciB0aGUgYWdyZWVtZW50IHBo YXNlIG9mIHRoZSBjb29raWUgZXhjaGFuZ2UgYXJlIHByb3RlY3RlZCBieSB0aGUgYWdyZWVk IGhhc2gga2V5IGFuZCBoYXNoIGFsZ29yaXRobS4NCg0KDQpUaGVyZSBpcyBhIHdpZGUgc3Bl Y3RydW0gb2YgcG9zc2libGUgaG9zdGlsZSBwcm9iZXMgb24gdGhlIE5UUCBpbXBsZW1lbnRh dGlvbiBpdHNlbGYuIE9uZSBvZiB0aGVzZSBpcyBzaW1wbHkgdG8gYW1wdXRhdGUgdGhlIGNy eXB0b2dyYXBoaWMgZGF0YSBmcm9tIGEgdHJhbnNtaXR0ZWQgcGFja2V0LiBBbiBpbW1hdHVy ZSBpbXBsZW1lbnRhdGlvbiBtaWdodCBhc3N1bWUgdGhhdCB0aGUgTlRQIGRlc2lnbiBwZXJt aXRzIGJvdGggc2VjdXJlIGFuZCB1bnNlY3VyZSBvcGVyYXRpb25zIHRvIGJlIHNhbmN0aW9u ZWQuIFN1Y2ggYW4gZXJyb3IgaW52aXRlcyBhIG1pZGRsZW1hbiB0byBzaWduaWZpY2FudGx5 IGFsdGVyIHRoZSByZWNlaXZlIGFuZCB0cmFuc21pdCB0aW1lc3RhbXBzIG9uIHRoZSBOVFAg cGFja2V0LCByZXN1bHRpbmcgaW4gYW55IG9mIHRoZSBhY3Rpb25zIGRlc2NyaWJlZCBiZWxv dy4NCg0KDQpBIHByb3RvY29sIHJlc3RhcnQgaXMgaW5pdGlhdGVkIHVwb24gcmVjZWlwdCBv ZiBhIHZhbGlkIGNyeXB0by1OQUsgaW4gcmVzcG9uc2UgdG8gYSBzaWduYXR1cmUgZmFpbHVy ZSBvciBwcm90b2NvbCBlcnJvci4gQSBjcnlwdG8tTkFLIHJlc3VsdGluZyBmcm9tIGEgaGFz aCBmYWlsdXJlIG9yZGluYXJpbHkgcmVzdWx0cyBpbiBvbmx5IGEgY29va2llIGV4Y2hhbmdl LiANCg0KDQpJbiBzeW1tZXRyaWMgbW9kZSBlYWNoIHJlc3RhcnQgcmVzdWx0cyBpbiBhIGRp ZmZlcmVudCBzaGFyZWQgaGFzaCBrZXkuIEluIGNsaWVudC9zZXJ2ZXIgbW9kZSwgdGhlIHNo YXJlZCBoYXNoIGtleSBpcyBjaGFuZ2VkIG9ubHkgd2hlbiB0aGUgc2VydmVyIHNlY3JldCB2 YWx1ZSBvciB0aGUgYWJvdmUgbm9uY2UgaXMgY2hhbmdlZC4NCg0KDQpUaGUgcmVzdGFydCB0 aGVuIGRlbGF5cyBhIHRpbWUgaW50ZXJ2YWwgcmFuZG9taXplZCBvdmVyIHRoZSBwb2xsIGlu dGVydmFsLCB0aGVuIHNlbmRzIGEgcGFyYW1ldGVyIGV4Y2hhbmdlIGFuZCBjb250aW51ZXMg dGhlIGRhbmNlLg0KDQoNClRoaXMgZGVzaWduIHByb3ZpZGVzIGNvcnJlY3QgcmVjb3Zlcnkg aW4gY2FzZSBvZiBwdWJsaWMga2V5IGNoYW5nZXMgYW5kIHNlcnZlciBzZWNyZXQga2V5IHVw ZGF0ZXMuIFdoaWxlIHRoaXMgc2NoZW1lIGludml0ZXMgYSB0ZXJyb3Jpc3QgdG8gZGlzcnVw dCB0aGUgcHJvdG9jb2wgYnkgaW5qZWN0aW5nIGEgYm9ndXMgcGFyYW1ldGVyIGV4Y2hhbmdl IGluIHRoZSBtaWRkbGUgb2Ygb3JkaW5hcnkgb3BlcmF0aW9ucywgdGhlIGNob2ljZSBvZiBr ZXkgemVybyBwcm90ZWN0cyB0aGUgaGFuZHNoYWtlIGZyb20gZm9yZWlnbiBuZXR3b3JrcyB3 aXRob3V0IGtub3dsZWRnZSBvZiB0aGUga2V5IHplcm8gdmFsdWUuIFRoZSByZXN1bHQgbWF5 IG5vdCBiZSBhIHZ1bG5lcmFiaWxpdHksIGJ1dCBpbiBhbnkgY2FzZSByZXByZXNlbnRzIGEg ZGVuaWFsIG9mIHNlcnZpY2UgYXR0YWNrLg0KDQoNClRoZSByYW5kb20gZGVsYXkgYXQgcmVz dGFydCBpcyBkZXNpZ25lZCB0byBtaW5pbWl6ZSBjb2xsaXNpb25zIGluIHN5bW1ldHJpYyBt b2RlLiBBIHNpbXBsZSBhbGdvcml0aG0gaXMgdXNlZCBpbiB0aGUgcmVmZXJlbmNlIGltcGxl bWVudGF0aW9uIHRvIHNsZXcgdGhlIHBhY2tldHMgb2Ygb25lIHBlZXIgdG8gYmUgdHJhbnNt aXR0ZWQgbmVhciB0aGUgbWlkcG9pbnQgb2YgdGhlIG90aGVyIHBlZXLigJlzIHBvbGwgaW50 ZXJ2YWwuDQoNCg0KSWYgYSB0aW1lb3V0IG9jY3VycyBiZWZvcmUgcmVjZWl2aW5nIGEgcmVz cG9uc2UgdG8gYSBwcmV2aW91cyByZXF1ZXN0LCB0aGUgcmVxdWVzdCBpcyBzZW50IGFnYWlu IHdpdGggbmV3IHN0YXRlIHZhcmlhYmxlcyBpbiB0aGUgbmV4dCBOVFAgcGFja2V0LiAgQSBy ZXNwb25zZSB3aXRob3V0IGEgcHJldmlvdXMgbWF0Y2hpbmcgcmVxdWVzdCBpcyBkaXNjYXJk ZWQuIElmIGEgcmVxdWVzdCBpcyByZWNlaXZlZCBiZWZvcmUgdGhlIHJlc3BvbnNlIHRvIGEg cHJldmlvdXMgcmVxdWVzdCwgdGhlIHJlc3VsdCBpcyBhIHByb3RvY29sIGVycm9yLiBJZiBh IHNpZ24gcmVxdWVzdCBpcyByZWNlaXZlZCBiZWZvcmUgdGhlIGNlcnRpZmljYXRlIGV4Y2hh bmdlLCB0aGUgcmVxdWVzdCBpcyBpZ25vcmVkLg0KDQoNCk9uY2UgdGhlIHByb3RvY29sIGRh bmNlcyBoYXZlIGxlZnQgdGhlIHN0YWdlLCB0aGUgcmVzdWx0IGlzIGEgc2hhcmVkIGhhc2gg a2V5LiBUaGUgaGFzaCBrZXkgaXMgdXNlZCB0byBjb25zdHJ1Y3QgdGhlIGhhc2ggZm9yIHRo ZSBNQUMuIFRoZSBrZXkgSUQgaXMgY29kZWQgdG8gZGlzdGluZ3Vpc2ggYWdyZWVkIGtleXMg ZnJvbSB0YWJsZSBrZXlzLiBUaGUgY3J5cHRvZ3JhcGhpYyBzdHJlbmd0aCBkZXBlbmRzIG9u IHRoZSBzaXplIG9mIHRoZSBoYXNoIGFuZCB0aGUgaGFzaCBhbGdvcml0aG07IG90aGVyd2lz ZSwgdGhlIHN0cmVuZ3RoIG9mIHRoZSBhZ3JlZWQga2V5IGFuZCB0YWJsZSBrZXkgYXJlIHRo ZSBzYW1lLg0KDQoNCldoaWxlIGl0IGlzIGNyeXB0b2dyYXBoaWNhbGx5IGhhcmQgdG8gbWFz cXVlcmFkZSBhcyBhIHZhbGlkIHBlZXIsIGNsaWVudCBvciBzZXJ2ZXIsIGEgY2xldmVyIG1p ZGRsZW1hbiBjYW4gc2ltcGx5IGNoYW5nZSBhIHBhY2tldCB0byBpbnRlbnRpb25hbGx5IGNh dXNlIGEgY3J5cHRvLU5BSyBhbmQgZXZlbnR1YWxseSBhIHByb3RvY29sIHJlc3RhcnQuIERv bmUgb2Z0ZW4gZW5vdWdoLCB0aGUgcmVzdWx0IHJlcHJlc2VudHMgYSBkZW5pYWwgb2Ygc2Vy dmljZSBhdHRhY2suDQoNCg0KVGhlIHByb3RvY29sIGRhbmNlIGlzIHByb3RlY3RlZCBpbiBw YXJ0IGJ5IHRoZSBvbi13aXJlIHByb3RvY29sIGxheWVyIGFuZCBieSB0aGUgc2hhcmVkIGhh c2gga2V5LiBUaGUgcGFyYW1ldGVyIHJlcXVlc3QgaW5jbHVkZXMgdGhlIHN1YmplY3QgbmFt ZSBvZiB0aGUgaG9zdCBjZXJ0aWZpY2F0ZTsgdGhlIHBhcmFtZXRlciByZXNwb25zZSBpbmNs dWRlcyB0aGUgc3ViamVjdCBuYW1lIG9mIHRoZSBzZXJ2ZXIgY2VydGlmaWNhdGUuIFRoZXNl IG5hbWVzIGNhbiBiZSB2ZXJpZmllZCBieSB0aGUgY2xpZW50IGFzc29jaWF0aW9uLg0KDQoN ClRoZSBmaXJzdCBjZXJ0aWZpY2F0ZSBleGNoYW5nZSByZXZlYWxzIHRoZSBzZXJ2ZXIgY2Vy dGlmaWNhdGUgdXNlZCB0byB2YWxpZGF0ZSB0aGUgY29va2llIGV4Y2hhbmdlLiBUaHVzLCBh IGhvc3RpbGUgaW50cnVkZXIgY2Fubm90IHRvc3MgZmFrZSB2YWx1ZXMgd2l0aCBlZmZlY3Qg b24gdGhlIHN0YXRlIG9mIHRoZSByZWNpcGllbnQuIEF0dGFja3Mgb24gdGhlIHBhcmFtZXRl ciBhbmQgY29va2llIGV4Y2hhbmdlcyBhcmUgZGVmbGVjdGVkIGJ5IGtleSB6ZXJvLCBidXQg YXJlIG1pdGlnYXRlZCBieSB0aGUgb24td2lyZSBsYXllcjsgcGFja2V0cyB3aXRoIGxvb3Bi YWNrIGVycm9ycyBhcmUgaWdub3JlZC4gVGh1cywgdGhlIG1vc3QgbGlrZWx5IHJlc3VsdCBv ZiBhIG1pZGRsZW1hbiBpbnZhc2lvbiBpcyBhIHJlc3RhcnQsIHJhdGhlciB0aGFuIGEgZmFs c2UgYWdyZWVtZW50Lg0KDQoNCkEgc2lnbmlmaWNhbnQgZGlzcnVwdGlvbiBpcyBsaWtlbHkg d2hlbiBhIG5ldyBwdWJsaWMvcHJpdmF0ZSBrZXkgYW5kIGNlcnRpZmljYXRlIGFyZSBnZW5l cmF0ZWQgaW4gdGhlIG1pZGRsZSBvZiB0aGUgY2VydGlmaWNhdGUgdHJhaWwuIFRoaXMgcmVx dWlyZXMgcmVjb21wdXRpbmcgdGhlIG5ldyBjZXJ0aWZpY2F0ZSBzaWduYXR1cmUgaW4gdGhl IGltbWVkaWF0ZSB1cHN0cmVhbSBob3N0IGFuZCBhbGwgaW1tZWRpYXRlIGRvd25zdHJlYW0g aG9zdHMuDQoNCg0KSW4gYnJvYWRjYXN0IG1vZGUsIHRoZSBtb3N0IHBvcHVsYXIgYXR0YWNr IGlzIHRvIHJlcGVhdCBvbGQgdmFsaWQgbWVzc2FnZXMuIE9yZGluYXJpbHksIHRoZXNlIGFy ZSBzdXBwcmVzc2VkIGJ5IHRoZSB0cmFuc21pdCB0aW1lc3RhbXAgYXMgZGVzY3JpYmVkIGFi b3ZlLiBIb3dldmVyLCBwcm90b2NvbCByZXN0YXJ0cyBhbmQgbG9zdCBwYWNrZXRzIG1pZ2h0 IHJlc3VsdCBpbiBtaXNvcmRlcmVkIG1lc3NhZ2VzLiBUaGUgZW5saWdodGVuZWQgcmVzcG9u c2UgaXMgdG8gcnVuIGEgdGltZW91dCB1cG9uIHJlY2VpdmluZyBhIHZhbGlkIG1lc3NhZ2Ug YW5kIHRlcm1pbmF0ZSBpdCB1cG9uIHJlY2VpdmluZyBhIG1lc3NhZ2Ugd2l0aCBhIGxhdGVy IHRpbWVzdGFtcC4gTm90ZSB0aGF0IGEgdGVycm9yaXN0IGNhbm5vdCBjb25zdHJ1Y3QgYSB2 YWxpZCBtZXNzYWdlLCBhcyBpdCBjYW5ub3QgY29uc3RydWN0IGEgdmFsaWQgc2lnbmF0dXJl Lg0KDQoNCk9mIHRoZSB0aHJlYXQgc2NlbmFyaW9zLCBhIGRpc3RyaWJ1dGVkIGRlbmlhbCBv ZiBzZXJ2aWNlIGF0dGFjayBpcyB0aGUgbW9zdCBkaXNydXB0aXZlLiAgVGhpcyBzY2VuYXJp byBjYW4gYmUgY3JlYXRlZCB3aGVuIGEgbGFyZ2UgbnVtYmVyIG9mIGF0dGFja2VycyBjb29w ZXJhdGUgdG8gc2VuZCBhIHN0cmVhbSBvZiBwYWNrZXRzIHRvIHZpY3RpbSBzZXJ2ZXIgYXQg aGlnaCByYXRlLg0KDQoNCk9uZSBzb2x1dGlvbiB1c2VzIHRoZSBtb3N0IHJlY2VudGx5IHVz ZWQgKE1SVSkgbGlzdCB1c2VkIGJ5IHRoZSByYXRlIG1hbmFnZW1lbnQgZnVuY3Rpb24uICBF YWNoIGVudHJ5IGluY2x1ZGVzIHRoZSBjbGllbnQgYWRkcmVzcywgcHJvY2VzcyB0aW1lIG9m IGFycml2YWwgYW5kIHJlbGF0ZWQgaW5mb3JtYXRpb24uICBUaGUgbGlzdCBpcyBvcmRlcmVk IGJ5IGluY3JlYXNpbmcgcHJvY2VzcyB0aW1lIG9mIGFycml2YWwgd2l0aCBkdXBsaWNhdGUg SVAgYWRkcmVzc2VzIHN1cHByZXNzZWQuICBBIEREb1MgYXR0YWNrIGlzIHNpZ25hbGxlZCB3 aGVuIHRoZSBsaXN0IGZpbGxzIHVwIGFuZCBvdmVyZmxvd3MuICBPbiBvdmVyZmxvdywgbmV3 IHBhY2tldHMgYXJlIGRpc2NhcmRlZCBhdCBhIHJhdGUgY29uc2lzdGVudCB3aXRoIHRoZSBv dmVyZmxvdyByYXRlLg0KDQoNCkluIHRoZSBwcm90b2NvbCBkZXNjcmliZWQgaW4gdGhpcyBk b2N1bWVudCwgYW4gYW1wbGlmaWNhdGlvbiBoYXphcmQgaXMgd2hlbiBhIHNtYWxsIHJlcXVl c3QgbWVzc2FnZSByZXN1bHRzIGluIGEgbGFyZ2UgcmVzcG9uc2UgbWVzc2FnZS4gIFRoaXMg aXMgYXZvaWRlZCBpbiB0aGUgTlRTIHByb3Bvc2FsIGJ5IGluY2x1ZGluZyBhIGR1bW15IHBs YWNlaG9sZGVyIGluIHRoZSByZXF1ZXN0LCBzbyB0aGF0IHRoZSByZXNwb25zZSBoYXMgdGhl IHNhbWUgbGVuZ3RoIGFzIHRoZSByZXF1ZXN0LiAgVGhpcyBpcyBjb25zaWRlcmVkIGEgd2Fz dGUgb2YgbmV0d29yayByZXNvdXJjZXMgYW5kIHVubmVjZXNzYXJ5IGluIHRoZSBwcm90b2Nv bCBwcm9wb3NlIGhlcmUuICBXaXRoIHRoZSBwcm9wb3NlZCBleGNoYW5nZXMgaW4gdGhpcyBk b2N1bWVudCwgdGhlcmUgYXJlIG5vIGluc3RhbmNlcyBvZiBzaWduaWZpY2FudCBkaWZmZXJl bmNlcyBiZXR3ZWVuIHRoZSBsZW5ndGhzIG9mIHJlcXVlc3QgYW5kIHJlc3BvbnNlDQptZXNz YWdlcywgZXhjZXB0IGZvciB0aGUgY29va2llIHJlc3BvbnNlIG1lc3NhZ2UgYXMgZGVzY3Jp YmVkIHByZXZpb3VzbHkuDQoNCg0KQWxzbyBub3RlICB0aGF0IHRoZSBvcmlnaW5hbCBsaWJy YXJ5IHByb2dyYW0gdXNlZCB0byBnZW5lcmF0ZSBrZXlzIGFuZCBjZXJ0aWZpY2F0ZSBhcHBs aWNhdGlvbnMgY29udGludWVzIHRvIHdvcmsgd2l0aCB0aGUgcHJvcG9zZWQgc2NoZW1lLiAg QSBzaWduaWZpY2FudCBjaGFsbGVuZ2UgaXMgdG8gbWluaW1pemUgdGhlIGNvbXBsZXhpdHkg b2YgdGhlIGNvbmZpZ3VyYXRpb24gZWZmb3J0Lg0KDQoNCjkuMSBEYXRhIE1pbmltaXphdGlv bg0KDQoNCltDb250ZW50IHRvIGJlIGFkZGVkXQ0KDQoNCjkuMiBERG9TIENvbnNpZGVyYXRp b25zDQoNCg0KW0NvbnRlbnQgdG8gYmUgYWRkZWRdDQoNCg0KMTAuIEhhY2tlciBPcHBvcnR1 bml0aWVzDQoNCg0KQ29uc2lkZXIgd2hlbiBhIHNlcnZlciB1cGRhdGUgaGFzIHBhc3NlZCBh bGwgZm9ybXMgb2YgY3J5cHRvZ3JhcGhpYyBhbmQgcHJvdG9jb2wgZGVmZW5zZXMuIEEgY3Jp dGljYWwgcXVlc3Rpb24gaXMgd2hlbiB0aGUgc2VydmVyIHRpbWUgaXMgaW50ZW50aW9uYWxs eSBkaXNydXB0ZWQgaW4gb3JkZXIgdG8gZGVzdGFiaWxpemUgdGhlIGNsaWVudCBjbG9jay4g VGhlcmUgYXJlIHNldmVyYWwgbXV0dWFsbHkgZXhjbHVzaXZlIGhhY2tlciBvcHBvcnR1bml0 aWVzIGRlc2NyaWJlZCBiZWxvdy4NCg0KDQoxMC4xIFN0b3AgQXR0YWNrDQoNCg0KSW4gYSBz dG9wIGF0dGFjaywgdGhlIHNlcnZlciBzaW1wbHkgc3RvcHMgb3BlcmF0aW5nLiBUaGUgcmVz dWx0IGlzIHRoYXQgdGhlIGNsaWVudCBjbG9jayBjb250aW51ZXMgYXQgaXRzIGludHJpbnNp YyB0aW1lIGFuZCBmcmVxdWVuY3kuIElmIHRoZSBmcmVxdWVuY3kgaXMgZmFyIGZyb20gbm9t aW5hbCwgdGhlIGNsaWVudCBjbG9jayBlcnJvciB3aWxsIGdyb3cgd2l0aG91dCBib3VuZC4N Cg0KDQoxMC4yIFBhbmljIEF0dGFjaw0KDQoNCkluIGEgcGFuaWMgYXR0YWNrLCB0aGUgc2Vy dmVyIGNsb2NrIG9mZnNldCBpcyBncmVhdGVyIHRoYW4gdGhlIHBhbmljIHRocmVzaG9sZCwg dXN1YWxseSA5MDAgc2Vjb25kcy4gSW4gdGhpcyBzY2VuYXJpbyB0aGUgY2xpZW50IGNsb2Nr IGlzIHN0ZXBwZWQgdG8gc29tZSBsYXJnZSBvZmZzZXQgZ3JlYXRlciB0aGFuIHRoZSBwYW5p YyB0aHJlc2hvbGQuIElmIGl0IGlzIHRoZSBmaXJzdCB1cGRhdGUsIHRoZSBjbGllbnQgY2xv Y2sgaXMgc3RlcHBlZCB0byB0aGUgYXBwYXJlbnQgdGltZSBhbmQgb3BlcmF0aW9uIGNvbnRp bnVlcyB3aXRoIHRoaXMgdGltZS4gVGhpcyBpcyBvZnRlbiB0aGUgY2FzZSBhdCBjbGllbnQg c3RhcnR1cCB3aXRoIG5vIHJlYWwgdGltZSBjbG9jayBoYXJkd2FyZS4gSWYgaXQgaXMgbm90 IHRoZSBmaXJzdCB1cGRhdGUsIHRoZSBjbGllbnQgc3RvcHMgdGhlIE5UUCBwcm9ncmFtIHdp dGggYSBsb2cgZW50cnkgYW5kIG9wZXJhdG9yIHdhcm5pbmcuIElmIHRoaXMgaGFwcGVucywg dGhlIGluZXhwZXJpZW5jZWQgb3BlcmF0b3Igc2ltcGx5IHJlc3RhcnRzIHRoZSBwcm9ncmFt IGFuZCB0aGUgZXZpbCBzdGVwIG9jY3VycyBhbnl3YXkuIFRoaXMgY2FuIGRlc3RhYmlsaXpl IHRoZSBjbGllbnQgYXBwbGljYXRpb25zIGluIG1hc3NpdmUgd2F5cy4NCg0KDQoxMC4zIFN0 ZXAgQXR0YWNrDQoNCg0KSW4gYSBzdGVwIGF0dGFjaywgdGhlIGNsaWVudCBjbG9jayBpcyBz dGVwcGVkIGxlc3MgdGhhbiB0aGUgcGFuaWMgdGhyZXNob2xkLCBidXQgZ3JlYXRlciB0aGFu IHRoZSBzdGVwIHRocmVzaG9sZCwgdXN1YWxseSAxMjggbWlsbGlzZWNvbmRzLiBUaGUgc2Vy dmVyIGNvbnRpbnVlcyBpbiB0aGlzIHdheSBmb3IgdGhlIHN0ZXBvdXQgdGhyZXNob2xkLCB1 c3VhbGx5IDkwMCBzZWNvbmRzLiBBZnRlciB0aGlzLCB0aGUgbmV4dCB1cGRhdGUgd2lsbCBz dGVwIHRoZSBjbGllbnQgY2xvY2sgYnkgdGhlIHNlcnZlciB1cGRhdGUuIFRoZSBjbGV2ZXIg dGVycm9yaXN0IGNhbiByZXBlYXQgdGhpcyB3aXRoIGRpZmZlcmVudCBvZmZzZXRzLCBjYXVz aW5nIHRoZSBjbGllbnQgY2xvY2sgdG8gb3NjaWxsYXRlIHdpbGRseS4NCg0KDQoxMC40IFN3 aXNoIEF0dGFjaw0KDQoNCkluIGEgc3dpc2ggYXR0YWNrLCB0aGUgc2VydmVyIHVzZXMgb2Zm c2V0cyBsZXNzIHRoYW4gdGhlIHN0ZXAgdGhyZXNob2xkIGJ1dCBhZGRzIG9yIHN1YnRyYWN0 cyBpbmNyZWFzaW5nIG9mZnNldHMuIFRoZSBjbG9jayBldmVudHVhbGx5IHJlYWNoZXMgYW5k IGhvbGRzIGF0IHRoZSBtYXhpbXVtIGZyZXF1ZW5jeSwgY3VycmVudGx5IDUwMCBwYXJ0cyBw ZXIgbWlsbGlvbi4NCg0KDQoxMS4gSW1wbGVtZW50YXRpb24gU3VnZ2VzdGlvbnMNCg0KDQpK dWRnaW5nIGZyb20gZGV2ZWxvcG1lbnQgZXhwZXJpZW5jZSwgdGlua2VyaW5nIHdpdGggcHJv dG9jb2wgZGVzaWduIGNhbiBiZSB0ZWRpb3VzLiBUaGUgZGFuY2VzIGludGVyYWN0IHdpdGgg dGhlIHRpbWVvdXQgYW5kIHJhdGUgbWFuYWdlbWVudCBmdW5jdGlvbnMsIHdoaWxlIGV4Y2hh bmdlcyBtYXkgZWl0aGVyIHRpbWVvdXQgb3IgcmVzdWx0IGluIGVycm9yLiBDdXJyZW50IGFu ZCB1c2VmdWwgZmVhdHVyZXMgb2YgdGhlIHJlZmVyZW5jZSBpbXBsZW1lbnRhdGlvbg0KbWF5 IGJlIGxvc3QgaW4gYSBuZXcgaW1wbGVtZW50YXRpb24uIFRoZSBlZmZlY3RpdmUgYXBwcm9h Y2ggbWF5IGJlIHRvIGV2aXNjZXJhdGUgdGhlIGN1cnJlbnQgQXV0b2tleSBwcm92aXNpb25z IGluIHRoZSByZWZlcmVuY2UgaW1wbGVtZW50YXRpb24gYW5kIHJlcGxhY2Ugd2l0aCB0aGUg YWJvdmUgZGVzaWduLiBUaGlzIG1heSBub3QgYmUgYXMgZGlmZmljdWx0IGFzIGl0IHNlZW1z LiBUaGUgZmlyc3Qgc3RlcCBpcyB0byByZW1vdmUgYWxsIGV4dGVuc2lvbiBmaWVsZCByZWZl cmVuY2VzIHRvIGFzc29jaWF0aW9uIElELCB0aW1lc3RhbXBzIGFuZCBmaWxlc3RhbXBzLiBO b3RlIHRoYXQgdGhlIHByb2dyZXNzaW9uIG9mIGV4Y2hhbmdlcyBpcyBub3QgY2hhbmdlZC4g VGhlIG5leHQgc3RlcCBpcyB0byBpbXBsZW1lbnQgdGhlIGNvb2tpZSBhbmQgREggYWdyZWVt ZW50IGFsZ29yaXRobXMgYXMgZGVzY3JpYmVkIGFib3ZlLiBUaGUgZmluYWwgc3RlcCBpcyB0 byByZW1vdmUgYWxsIHJlZmVyZW5jZXMgdG8gdGhlIFNLRVkgc2NoZW1lIGFuZCByZXBsYWNl IHdpdGggdGhlIHNpZ25hdHVyZSBzY2hlbWUgYXMgZGVzY3JpYmVkLg0KDQoNCjEyLiBBbHRl cm5hdGl2ZSBNb2RlbHMNCg0KDQpBcyBhbiBhc2lkZSwgQVNOLjEgZW5jb2Rpbmcgb2YgZXh0 ZW5zaW9uIGZpZWxkcyBpcyBwcm9iYWJseSBub3QgYSBnb29kIGlkZWEuIEhvd2V2ZXIsIEFT Ti4xIGlzIGFwcHJvcHJpYXRlIGZvciBwYXJhbWV0ZXIgZGF0YS4gQWxsIG90aGVyIGV4dGVu c2lvbiBmaWVsZHMgdXNlIG9ubHkgb3BhcXVlIG9jdGV0IHN0cmluZ3MuIEV2ZW4gQVNOLjEg ZW5jb2RlZCBkYXRhLCBzdWNoIGFzIGNlcnRpZmljYXRlcywgYXJlIHRyYW5zbWl0dGVkIGFz IGZsYXQgb3BhcXVlIGJpdCBzdHJpbmdzLg0KDQoNClRMUy9UQ1AsIERUTFMvVURQIG9yIGNv bWJpbmF0aW9ucyBvZiB0aGVzZSBtaWdodCBiZSBhIGdvb2QgYWx0ZXJuYXRlIGFwcHJvYWNo LiBUaGUgbW90aXZhdGlvbiBmb3IgdGhpcyBhcHByb2FjaCBpcyB0byB1c2UgZXhpc3Rpbmcg cHVibGljIHNlY3VyaXR5IHNjaGVtZXMgdG8gYXV0aGVudGljYXRlIE5UUCBwYWNrZXRzLiBU aGlzIGFwcHJvYWNoIHJlcXVpcmVzIGEgcHVibGljIHNvZnR3YXJlIHByb3RvY29sIHN0YWNr IG9yIGxpYnJhcnkuIEJlc2lkZXMgZm9ybWluZyBhbiBhZGRpdGlvbmFsIHRhcmdldCBmb3Ig aG9zdGlsZSBhdHRhY2ssIHRoZSB0aW1lIGFuZCByZXNvdXJjZXMgcmVxdWlyZWQgbWF5IGJl IGJ1cmRlbnNvbWUgYW5kIHJlc3VsdCBpbiBzaWduaWZpY2FudCBsb3NzIG9mIHRpbWVrZWVw aW5nIGFjY3VyYWN5Lg0KDQoNCkluIHRoZSBjYXNlIG9mIFRMUy9UQ1AsIHRoZSBUQ1AgcHJv dG9jb2wgZGVzaWduIGlzIGF0IG9kZHMgd2l0aCB0aGUgTlRQIGRhdGFncmFtIHN0cnVjdHVy ZSBhbmQgcmF0ZSBtYW5hZ2VtZW50IHByaW5jaXBsZXMuIEluIGFkZGl0aW9uLCBUQ1AgcmVx dWlyZXMgYSBmb3JtYXQgbGF5ZXIgdGhhdCBpZGVudGlmaWVzIHBhY2tldCBib3VuZGFyaWVz Lg0KDQoNCldoaWxlIFRDUCBwcm92aWRlcyByZWxpYWJsZSBkZWxpdmVyeSwgcmV0cmFuc21p c3Npb25zIHJlbmRlciBOVFAgdGltZXN0YW1wcyBlc3NlbnRpYWxseSB1c2VsZXNzLiBUaGUg TlRQIHBhY2tldCByYXRlIGxpbWl0IG1vZGVsIGlzIGF0IG9kZHMgd2l0aCB0aGUgVENQIGFy Y2hpdGVjdHVyZSwgd2hlcmUgdGhlIHJlc291cmNlcyB0byBjb25zZXJ2ZSBhcmUgYnVmZmVy cyBhbmQgZGF0YSBmbG93IG1hbmFnZW1lbnQuDQoNCg0KVGhlIFRDUCBtb2RlbCByZXF1aXJl cyBib3RoIHNlcnZlciBhbmQgY2xpZW50IHRvIG1haW50YWluIHByb3RvY29sIHN0YXRlLCB3 aGljaCBpcyBub3QgcHJhY3RpY2FsIGluIGEgc3RhdGVsZXNzIHNlcnZlciBhcmNoaXRlY3R1 cmUuIEl0IGFsc28gcmVxdWlyZXMgY29weWluZyBOVFAgcGFja2V0cyB0byBpbnRlcm5hbCBi dWZmZXJzIGFuZCB0aGVuIGNvcHlpbmcgZGF0YSBmcm9tIHRoZXNlIGJ1ZmZlcnMgdG8gTlRQ IG1lc3NhZ2VzLiBUaGUgb3ZlcmhlYWQgaW4gdGhlc2UgYWN0aW9ucyB3b3VsZCBvdmVyd2hl bG0gYSBwcm9jZXNzb3IgZmFjZWQgd2l0aCBhIHN3YXJtIG9mIDMwMDAgTlRQIHBhY2tldHMg cGVyIHNlY29uZC4gRmluYWxseSwgdGhlIFRMUy9UQ1AgcHJvdG9jb2wgb3ZlcmhlYWQgcmVx dWlyZXMgdXAgdG8gc2V2ZW4gY29udHJvbCBwYWNrZXRzIGluIGFkZGl0aW9uIHRvIHRoZSBk YW5jZSBwYWNrZXRzLCB3aGlsZSBvYmV5aW5nIHRoZSByYXRlIGNvbnN0cmFpbnRzLiBUaGUg aW5ldml0YWJsZSBjb25jbHVzaW9uIGlzIHRoYXQgYW55IHNlY3VyaXR5IG1vZGVsIGJhc2Vk IG9uIFRDUCBpcyBpbmFwcHJvcHJpYXRlIGZvciBkaXJlY3QgdXNlIGJ5IE5UUC4gW0RJU0NV U1NdDQoNCg0KRFRMUy9VRFAgYXQgZmlyc3QgZ2xhbmNlIHNlZW1zIGEgbXVjaCBiZXR0ZXIg c2VjdXJpdHkgcHJvdG9jb2wgZm9yIE5UUCB0aGFuIFRMUy9UQ1AgZHVlIHRvIGl0cyBpbnRy aW5zaWMgc3RydWN0dXJlIGJhc2VkIG9uIGRhdGFncmFtIHByaW5jaXBsZXMuIEhvd2V2ZXIs IGluIHRoaXMgcHJvdG9jb2wsIHRoZSBiYXNpYyBOVFAgaGVhZGVyIGFuZCBleHRlbnNpb24g ZmllbGRzIGFyZSBlbWJlZGRlZCBpbiB0aGUgRFRMUy9VRFAgcmVjb3JkIHByb3RvY29sLCB3 aGljaCByZXF1aXJlcyBjb3B5aW5nLCBhcyBpbiBUTFMvVENQLiBUaGlzIHJlc3VsdHMgaW4g Y29uc2lkZXJhYmxlIG92ZXJoZWFkIGFuZCBsb3NzIG9mIHRpbWVzdGFtcCBhY2N1cmFjeS4N Cg0KDQpUaGUgaGFuZHNoYWtlIHByb3RvY29sIGlzIG5vdCB3ZWxsIHByb3RlY3RlZCwgYnV0 IHRoZSBrZXkgemVybyBzY2hlbWUgY291bGQgcmVzb2x2ZSB0aGlzIHByb2JsZW0uIEhvd2V2 ZXIsIHRoZSByZWNvcmQgcHJvdG9jb2wgY291bGQgYmUgYXZvaWRlZCBpZiB0aGUgSS9PIGJ1 ZmZlciBjb250YWlucyB0aGUgY29tcGxldGUgcGFja2V0IC0gTlRQIGhlYWRlciwgUERVcyBh bmQgTUFDLiBUaGlzIGlzIGFuIGV4YW1wbGUgb2YgdGhlICJjb3B5IG9ubHkgb25jZSIgcHJp bmNpcGxlLCB3aGljaCBpcyBhZG9wdGVkIGluIHRoZSBhYm92ZSBwcm9wb3NhbCBhcyB3ZWxs Lg0KDQoNCkl0IHdvdWxkIGJlIGEgc2hvd3N0b3BwZXIgcHJvYmxlbSBpZiBEVExTL1VEUCB3 YXMgbGltaXRlZCB0byBjbGllbnQvc2VydmVyIG1vZGUuIFRoaXMgZG9jdW1lbnQgaXMgY2Fy ZWZ1bGx5IGNyYWZ0ZWQgdG8gaW5jbHVkZSBzeW1tZXRyaWMgbW9kZS4gSW4gcHJpbmNpcGxl LCB0aGUgb25seSBkaWZmZXJlbmNlIGJldHdlZW4gdGhlc2UgbW9kZXMgaXMgaW4gdGhlIGFn cmVlbWVudCBwaGFzZSBvZiB0aGUgY29va2llIGV4Y2hhbmdlLiBUaGUgbmVlZCB0byBhc3Nl bWJsZSBEVExTIGhlYWRlcnMgYW5kIHRyYWlsZXJzLCBhbmQgTlRQIHBhY2tldHMgaW4gcmVj b3JkcyBtYXkgcmVxdWlyZSBjb3B5aW5nIGRhdGEgaW4gYnVmZmVycywgcmVzdWx0aW5nIGlu IGZ1cnRoZXIgb3ZlcmhlYWQuIFRoZSBEVExTL1VEUCBoYW5kc2hha2UgcHJvdG9jb2wgY291 bGQgYmUgdXNlZCB3aXRob3V0IHRoZSByZWNvcmQgbGF5ZXIuDQoNCg0KRm9yIHRoZSBiZXN0 IGFjY3VyYWN5LCB0aGUgb24td2lyZSB0aW1lc3RhbXBzIHNob3VsZCBiZSBpbXBsZW1lbnRl ZCBhcyBjbG9zZSBhcyBwb3NzaWJsZSB0byB0aGUgZW5kIG9mIHBhY2tldCBoYXJkd2FyZSBp bnRlcnJ1cHQuIFRoZSByZWZlcmVuY2UgaW1wbGVtZW50YXRpb24gZG9lcyB0aGlzIGJ5IGFu IGludHJpY2F0ZSBzY2hlbWUgaW52b2x2aW5nIHRoZSBVbml4IGludGVycnVwdCBxdWV1ZSBh bmQgcmVjb3JkaW5nIG9mIHRoZSB0aW1lc3RhbXAgaW4gdGhlIGlucHV0IHBhY2tldCBidWZm ZXIuIEluIHRoZSBEVExTL1VEUCBtb2RlbCwgdGhlIGJ1ZmZlciBpcyB0aGVuIHBhc3NlZCB0 byB0aGUgRFRMUy9VRFAgcmVjb3JkIHByb3RvY29sLCB3aGljaCBtaWdodCBub3QgcHJlc2Vy dmUgdGhlIHRpbWVzdGFtcC4gVGhpcyB3b3VsZCBiZSBwb3NzaWJsZSBvbmx5IHdpdGggY29u c2lkZXJhYmxlIG1vZGlmaWNhdGlvbnMgdG8gdGhlIERUTFMvVURQIHB1YmxpYyBzb2Z0d2Fy ZSBkaXN0cmlidXRpb24uDQoNCg0KVG8gY29udGludWUgc3VwcG9ydCBmb3IgdGhlIG5vbi1h dXRoZW50aWNhdGVkIHByb3RvY29sIGFuZCB0aGUgYXV0aGVudGljYXRlZCBrZXlzIGZpbGUg bW9kZWwsIHRoZSBOVFAgcG9ydCBtdXN0IGJlIDEyMyBhcyByZXF1aXJlZCBmb3IgaGlzdG9y aWMgb3BlcmF0aW9ucy4gVGhlcmVmb3JlLCBhIG5ldyBEVExTL1VEUCBzZWN1cml0eSBwcm90 b2NvbCBtdXN0IGJlIHN1cHBvcnRlZCBvbiBhIGRpZmZlcmVudCBwb3J0LiBbRElTQ1VTU10N Cg0KDQpUaGUgdXNlIG9mIERUTFMgb24gYSBwb3J0IG90aGVyIHRoYW4gMTIzIGNhbiBzdXBw b3J0IHNlZ21lbnRhdGlvbiBhbmQgcmVhc3NlbWJseSBmb3IgdGhlIGhhbmRzaGFrZSBwcm90 b2NvbCBidXQgcmVzdWx0IGluIHVzZWxlc3MgdGltZXN0YW1wcy4gVGhlIHJlYWwga2lsbGVy IGluIGEgRFRMUy9VRFAgZGVzaWduIGlzIHdoYXQgdG8gZG8gYWJvdXQgZnJhZ21lbnRhdGlv biBhbmQgcmVhc3NlbWJseS4gQXBwYXJlbnRseSwgdGhlIGN1cnJlbnQgc2VjdXJpdHkgaW5m cmFzdHJ1Y3R1cmUgcmVxdWlyZXMgY2VydGlmaWNhdGVzIG9mIG92ZXIgNTAwMCBvY3RldHMs IHdoaWNoIHJlcXVpcmUgbXVsdGlwbGUgZnJhZ21lbnRzIG5vdCBncmVhdGVyIHRoYW4gdGhl IDE1MDAtb2N0ZXQgTVRVLiBEVExTL1VEUCBzb2x2ZXMgdGhpcyBwcm9ibGVtIGJ5IGZyYWdt ZW50YXRpb24gYW5kIHJlYXNzZW1ibHkgYnV0IHJlc3VsdHMgaW4gdW5hY2NlcHRhYmxlIGxv c3Mgb2YgdGltZWtlZXBpbmcgYWNjdXJhY3kuIFRoZSBtb3N0IGVmZmVjdGl2ZSBzb2x1dGlv biBpcyB0byByZXF1aXJlIGNlcnRpZmljYXRlcyB0byBiZSBsZXNzIHRoYW4gdGhlIE1UVSBv ZiAxNTAwIG9jdGV0cy4gSXQgaXMgbm90IGNsZWFyIHdoeSBzdWNoIGxhcmdlIHBhY2tldHMg YXJlIHJlcXVpcmVkIGJ1dCB0aGUgc2ltcGxlIG9ic2VydmF0aW9uIGlzIHRoYXQgY2VydGlm aWNhdGVzIGZvciBOVFAgc2VjdXJpdHkgbmVlZCBub3QgYmUgYXMgcm9idXN0IGFzIG5lZWRl ZCBmb3Igd2ViIGJyb3dzaW5nLg0KDQoNCjEzLiBQYXJ0aW5nIFNob3RzDQoNCg0KV2l0aCBy ZXNwZWN0IHRvIHRoZSBOVFAgbW9kZWwgaW4gUkZDNTkwNSwgdGhlIHByb3Bvc2VkIHByb3Rv Y29sIGluIHRoZSBOVFMgYW5kIE5UUCBkb2N1bWVudHMgc2VlbSBhdCBvZGRzLiBUaGUgTlRT IHNjaGVtZSBtYWtlcyBubyBkaXN0aW5jdGlvbiBiZXR3ZWVuIGNsaWVudC9zZXJ2ZXIgYW5k IHN5bW1ldHJpYyBtb2RlcywgYXMgc3ltbWV0cmljIG1vZGUgZG9lcyBpbmRlZWQgaGF2ZSBz dGF0ZS4gVGhlIHByb3Bvc2VkIE5UUyBicm9hZGNhc3Qgc2NoZW1lIHJlcXVpcmVzIGEgdHdv LXdheSBtZXNzYWdlIHBhdGgsIHdoaWNoIGlzIG5vdCBhIHJlcXVpcmVtZW50IGluIHRoZSBO VFAgbW9kZWwuIFdoaWxlIHRoZSBwcm9wb3NlZCBOVFMgc2NoZW1lIGNvdWxkIGJlIGEgY29u ZmlndXJhdGlvbiBvcHRpb24sIHRoZSBwcm9wb3NlZCBzY2hlbWUgaW4gdGhpcyBkb2N1bWVu dCBpcyBhIG5lY2Vzc2l0eSBmb3IgdGhlIG9uZS13YXkgY29uZmlndXJhdGlvbi4NCg0KDQpP biB0aGUgb3RoZXIgaGFuZCwgdGhlIHByb3Bvc2VkIE5UUyBzY2hlbWUgc2VlbXMgd2hvbGx5 IGFwcHJvcHJpYXRlIGZvciBhbiBhcHBsaWNhdGlvbiBzdWNoIGFzIHRoZSBJUCBUSU1FIG9y IFNOVFAgcHJvdG9jb2wsIHdoZXJlIHRoZXJlIGlzIG5vIG9uLXdpcmUgcHJvdG9jb2wgbGF5 ZXIuIFdpdGggTlRQLCB0aGlzIGxheWVyIGF2b2lkcyB0aGUgbmVlZCBmb3IgZXhwbGljaXQg bm9uY2UgYW5kIHNlc3Npb24ga2V5cy4NCg0KDQpUaGVyZSBhcmUgc29tZSB3YXJ0cyBpbiB0 aGUgcmVmZXJlbmNlIGltcGxlbWVudGF0aW9uIGFuZCBwcm9wb3NlZCBwdWJsaWMga2V5IHNj aGVtZXMuIFRoZXJlIG1pZ2h0IGJlIG90aGVyIHdheXMgdG8gdmFsaWRhdGUgdGhlIGNlcnRp ZmljYXRlIHRyYWlsIG90aGVyIHRoYW4gdGhlIElGRiB6ZXJvLWtub3dsZWRnZSBzY2hlbWUu DQoNCg0KQXMgaW4gYWxsIGNyeXB0b2dyYXBoaWMgc2NoZW1lcywgcHJvdmlzaW9ucyBtdXN0 IGJlIG1hZGUgdG8gcmVmcmVzaCB0aGUga2V5IG1hdGVyaWFsLiBBcyBzdWdnZXN0ZWQgYWJv dmUsIHRoZSBzZWNyZXQga2V5IG9mIHRoZSBzZXJ2ZXIgc2hvdWxkIGJlIHJlZnJlc2hlZCBh Ym91dCBvbmNlIHBlciBkYXkuIEZvciBtb3JlIGRpc3J1cHRpb24gZHVlIHRvIGNlcnRpZmlj YXRlIHVwZGF0ZXMsIHRoZSBwcmVzZW50IGRlc2lnbiBkb2VzIHRoaXMgYnkgc2h1dHRpbmcg ZG93biBhbmQNCnRoZW4gcmVzdGFydGluZyBhbGwgYXNzb2NpYXRpb25zIG9uY2UgcGVyIHdl ZWsuIE1vcmUgc29waGlzdGljYXRlZCBzY2hlbWVzIG1pZ2h0IGJlIGRldmlzZWQuDQoNCg0K T2NjYXNpb25hbCBjb2xsaXNpb25zIHdvdWxkIGJlIGV4cGVjdGVkIGluIHN5bW1ldHJpYyBt b2RlLiBUaGlzIHdvdWxkIGhhcHBlbiB3aGVuIGJvdGggcGVlcnMgc3RhcnQgdGhlIHByb3Rv Y29sIGF0IHRoZSBzYW1lIHRpbWUuIFRoaXMgY2FuIGJlIGF2b2lkZWQgdXNpbmcgYSByYW5k b20gZGVsYXkgYXQgYXNzb2NpYXRpb24gc3RhcnR1cCwgYXMgZGVzY3JpYmVkIHByZXZpb3Vz bHkgaW4gdGhpcyBkb2N1bWVudC4NCg0KDQpJYnVyc3QgaGFzIGJlZW4gZGlzY291cmFnZWQg aW4gc3ltbWV0cmljIG1vZGUsIGJlY2F1c2Ugb2YgdGhlIGluY3JlYXNlZCByaXNrIG9mIGNv bGxpc2lvbnMgaWYgYm90aCBzaWRlcyBhcmUgbm90IHJlYWR5LiAgU3ltbWV0cmljIG1vZGUg aWJ1cnN0IHNob3VsZCBiZSBzYWZlIGFzIGxvbmcgYXMgaXQgaXMgb25seSBpbml0aWF0ZWQg YWZ0ZXIgdGhlIG90aGVyIHNpZGUgaGFzIHJlc3BvbmRlZCB0byBhbiBhY3RpdmUtbW9kZSBy ZXF1ZXN0Lg0KDQoNCldoaWxlIG5vdCBleHBsb3JlZCwgdGhlIHByb3RvY29sIG1pZ2h0IG5v dCBlc3RhYmxpc2ggYSBwcm9wZXIgaGFuZHNoYWtlIG9uIHRoZSBmaXJzdCB0cnkuICBIb3dl dmVyIGl0IHNob3VsZCBiZWNvbWUgc3RhYmlsaXplZCBhZnRlciBhdCBtb3N0IGEgZmV3IHJl c3RhcnRzLiBBIHNpbXVsYXRpb24gZXhlcmNpc2UsIGFzIGluIHByZXZpb3VzIGRvY3VtZW50 cywgY291bGQgcmVzb2x2ZSB0aGVzZSBpc3N1ZXMu --------------3C4BF6836A7A9E69A9AB312E Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp --------------3C4BF6836A7A9E69A9AB312E-- From nobody Mon Aug 21 00:27:39 2017 Return-Path: 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 B80FD132914 for ; Mon, 21 Aug 2017 00:27:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 kwGa0xA4lrgY for ; Mon, 21 Aug 2017 00:27:34 -0700 (PDT) Received: from mx1.bs.ptb.de (mx1.bs.ptb.de [IPv6:2001:638:610:bd01::120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BB3E1328DB for ; Mon, 21 Aug 2017 00:27:33 -0700 (PDT) Received: from smtp-hub.bs.ptb.de (smtpint01.bs.ptb.de [141.25.87.32]) by mx1.bs.ptb.de with ESMTP id v7L7RVGe013627-v7L7RVGg013627 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 21 Aug 2017 09:27:31 +0200 Received: from rose.bs.ptb.de (rose.bs.ptb.de [141.25.85.201]) by smtp-hub.bs.ptb.de (Postfix) with ESMTPS id 42F1C52F5DD; Mon, 21 Aug 2017 09:27:30 +0200 (CEST) In-Reply-To: References: To: Harlan Stenn Cc: ntp@ietf.org MIME-Version: 1.0 Message-ID: From: dieter.sibold@ptb.de Date: Mon, 21 Aug 2017 09:27:28 +0200 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha-256; boundary=-------z29935_boundary_sign Archived-At: Subject: [Ntp] Antwort: NTS/Updated Autokey X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Aug 2017 07:27:38 -0000 This is an S/MIME signed message. ---------z29935_boundary_sign Content-Type: multipart/alternative; boundary="=_alternative 0028F79CC1258183_=" Dies ist eine mehrteilige Nachricht im MIME-Format. --=_alternative 0028F79CC1258183_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable To clarify: I asked Dave to discuss his questions regarding the NTS draft=20 (https://www.ietf.org/id/draft-ietf-ntp-using-nts-for-ntp-09.txt) in the=20 NTP mailing list. I didn't asked to submit a further proposal. Dieter > Von: Harlan Stenn > An: ntp@ietf.org > Datum: 21.08.2017 04:41 > Betreff: [Ntp] NTS/Updated Autokey > Gesendet von: "ntp" >=20 > Dave has been working on an evaluation of the NTS proposal. >=20 > We've been discussing this document in our internal NTS implementation > meetings, and Dieter asked me to send this to the WG mailing list. >=20 > Dave updated the document after my last go-round, so I just took his new > version and integrated his changes with the ones we made. >=20 > I'll be working on my WGLC comments separately. > --=20 > Harlan Stenn, Network Time Foundation > http://nwtime.org - be a Member! > [Anhang "Autokey-20170815.txt" gel=F6scht von Dieter Sibold/PTB]=20 > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > ntp mailing list > ntp@ietf.org > https://www.ietf.org/mailman/listinfo/ntp --=_alternative 0028F79CC1258183_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable To clarify: I asked Dave to discuss his questions regarding the NTS draft (https://www.ietf.org/id/draft-ietf-ntp-using-nts-for-ntp-09= .txt) in the NTP mailing list. I didn't asked to submit a further proposal.

Dieter




> Von: Harlan Stenn <stenn@nwtime.org>
> An: ntp@ietf.org
> Datum: 21.08.2017 04:41
> Betreff: [Ntp] NTS/Updated Autokey
> Gesendet von: "ntp" <ntp-bounces@i= etf.org>
>
> Dave has been working on an evaluation of the NTS proposal.
>
> We've been discussing this document in our internal NTS implementation=
> meetings, and Dieter asked me to send this to the WG mailing list.
>
> Dave updated the document after my last go-round, so I just took his new
> version and integrated his changes with the ones we made.
>
> I'll be working on my WGLC comments separately.
> --
> Harlan Stenn, Network Time Foundation
> http://nwt= ime.org - be a Member!
> [Anhang "Autokey-20170815.txt" gel=F6scht von Dieter Sibold/= PTB]
> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
> ntp mailing list
> ntp@ietf.org
> https://www.ietf.org/mailman/listinfo/ntp<= font size=3D2>
 --=_alternative 0028F79CC1258183_=-- ---------z29935_boundary_sign Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIIp0gIBATEPMA0GCWCGSAFlAwQCAQUAMAsGCSqGSIb3DQEHAaCCJsYw ggOfMIICh6ADAgECAgEmMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNE ZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYD VQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw05OTA3MDkxMjExMDBaFw0xOTA3MDky MzU5MDBaMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYD VQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJv b3QgQ0EgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKsLozXgiykUsRSFrzwQ5Dlv NV1Krt3qYY2VSfRvZKMaYGakqUAihNnUpeV4kw5oAa25TVw6ztO4qEJA38+juoJZapIbrBya2ggr JSf5aSNH8eDrLHqb9RMC0H40fMKePABZq/XaDPUyPCusUNrWw96DlMqoDJkyDghIVltq+9rhWFgB SV9yQTwVBgGOXa2quJO0zZ7rp+hqLVI02zrvXHVR2tvzMfnucZgyxFQVRAz5m1Xtrd8YCKCjhopJ 7lMFjxlM1d5YeZvSahxCq8XVp89oD5bk4WGYdmHIkXzWPgDikVCH4Z0K5q2X0h3GOn3LvNoDNNWO WwH1age3FrZuSn8CAwEAAaNCMEAwHQYDVR0OBBYEFDHDeRu69VPXF+CJei0XbAqzK50zMA8GA1Ud EwQIMAYBAf8CAQUwDgYDVR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBBQUAA4IBAQCUZFmtOWTnKesT /lrDixNXyAQk8HR3wGDjZ/vpiaaDv5aCfG7Uwz3vnoBuuym0mHqxO1TrORdHfhqOC/wfMVkxBLLO F/Msx2I2VeIi2IlVtJhIqmT61hw22ER4WlojOleX9XowT66fakxLK46gA+M+4KnU0nvSs6jicjyt nv+AWeSbRbT2O7DNORmYMuXqIWGQ5DEhjjSx9y81SoUQ2ueKNyG+WWPg8oWIMVPUVBSFcHn0LgZ3 J3UvH7iK+f7Futg25IPs52W3v2Na80avgZQ31EGM1iPWHs/1aBtEY6Jauqc1WaHlcAWbDiNXmZQK bbo5YyiGkvMYhNj70c8FVmRXMIIDnzCCAoegAwIBAgIBJjANBgkqhkiG9w0BAQUFADBxMQswCQYD VQQGEwJERTEcMBoGA1UEChMTRGV1dHNjaGUgVGVsZWtvbSBBRzEfMB0GA1UECxMWVC1UZWxlU2Vj IFRydXN0IENlbnRlcjEjMCEGA1UEAxMaRGV1dHNjaGUgVGVsZWtvbSBSb290IENBIDIwHhcNOTkw NzA5MTIxMTAwWhcNMTkwNzA5MjM1OTAwWjBxMQswCQYDVQQGEwJERTEcMBoGA1UEChMTRGV1dHNj aGUgVGVsZWtvbSBBRzEfMB0GA1UECxMWVC1UZWxlU2VjIFRydXN0IENlbnRlcjEjMCEGA1UEAxMa RGV1dHNjaGUgVGVsZWtvbSBSb290IENBIDIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCrC6M14IspFLEUha88EOQ5bzVdSq7d6mGNlUn0b2SjGmBmpKlAIoTZ1KXleJMOaAGtuU1cOs7T uKhCQN/Po7qCWWqSG6wcmtoIKyUn+WkjR/Hg6yx6m/UTAtB+NHzCnjwAWav12gz1MjwrrFDa1sPe g5TKqAyZMg4ISFZbavva4VhYAUlfckE8FQYBjl2tqriTtM2e66foai1SNNs671x1Udrb8zH57nGY MsRUFUQM+ZtV7a3fGAigo4aKSe5TBY8ZTNXeWHmb0mocQqvF1afPaA+W5OFhmHZhyJF81j4A4pFQ h+GdCuatl9Idxjp9y7zaAzTVjlsB9WoHtxa2bkp/AgMBAAGjQjBAMB0GA1UdDgQWBBQxw3kbuvVT 1xfgiXotF2wKsyudMzAPBgNVHRMECDAGAQH/AgEFMA4GA1UdDwEB/wQEAwIBBjANBgkqhkiG9w0B AQUFAAOCAQEAlGRZrTlk5ynrE/5aw4sTV8gEJPB0d8Bg42f76Ymmg7+Wgnxu1MM9756AbrsptJh6 sTtU6zkXR34ajgv8HzFZMQSyzhfzLMdiNlXiItiJVbSYSKpk+tYcNthEeFpaIzpXl/V6ME+un2pM SyuOoAPjPuCp1NJ70rOo4nI8rZ7/gFnkm0W09juwzTkZmDLl6iFhkOQxIY40sfcvNUqFENrnijch vllj4PKFiDFT1FQUhXB59C4Gdyd1Lx+4ivn+xbrYNuSD7Odlt79jWvNGr4GUN9RBjNYj1h7P9Wgb RGOiWrqnNVmh5XAFmw4jV5mUCm26OWMohpLzGITY+9HPBVZkVzCCBNUwggO9oAMCAQICCFBOxvU9 EbRkMA0GCSqGSIb3DQEBCwUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNEZXV0c2NoZSBUZWxl a29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYDVQQDExpEZXV0c2No ZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0xNDA3MjIxMjA4MjZaFw0xOTA3MDkyMzU5MDBaMFoxCzAJ BgNVBAYTAkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQD ExtERk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U1wBblSJ01CDrNI/W7MAxBAuZgeKmFNJSoCgjhIt0 iQReW+DieMF4yxbLKDU5ey2QRdDtoAB6fL9KDhsAw4bpXCsxEXsM84IkQ4wcOItqaACa7txPeKvS xhObdq3u3ibo7wGvdA/BCaL2a869080UME/15eOkyGKbghoDJzANAmVgTe3RCSMqljVYJ9N2xnG2 kB3E7f81hn1vM7PbD8URwoqDoZRdQWvY0hD1TP3KUazZve+Sg7va64sWVlZDz+HVEz2mHycwzUlU 28kTNJpxdcVs6qcLmPkhnSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjggGGMIIBgjAOBgNVHQ8BAf8E BAMCAQYwHQYDVR0OBBYEFEm3xs/oPR9/6kR7Eyn38QpwPt5kMB8GA1UdIwQYMBaAFDHDeRu69VPX F+CJei0XbAqzK50zMBIGA1UdEwEB/wQIMAYBAf8CAQIwYgYDVR0gBFswWTARBg8rBgEEAYGtIYIs AQEEAgIwEQYPKwYBBAGBrSGCLAEBBAMAMBEGDysGAQQBga0hgiwBAQQDATAPBg0rBgEEAYGtIYIs AQEEMA0GCysGAQQBga0hgiweMD4GA1UdHwQ3MDUwM6AxoC+GLWh0dHA6Ly9wa2kwMzM2LnRlbGVz ZWMuZGUvcmwvRFRfUk9PVF9DQV8yLmNybDB4BggrBgEFBQcBAQRsMGowLAYIKwYBBQUHMAGGIGh0 dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMDoGCCsGAQUFBzAChi5odHRwOi8vcGtpMDMz Ni50ZWxlc2VjLmRlL2NydC9EVF9ST09UX0NBXzIuY2VyMA0GCSqGSIb3DQEBCwUAA4IBAQBjICj9 nCGGcr45Rlk5MiW8qQGbDczKfUGchm0KbiyzE1l1sTOSG2EnFv/DstU1gvuEKgFJvWa7Zi+ywgZd bj9u4wFaW8pDY1yVtuExpx/VB19N5mWCTjL5w3x6S81NXHTuIfJ1AuxSPtLJatOQI25JZzW+f01W pOzML8+3oZeocj7JvEDWWqQIPda8gsO3tzKOsSyOam23NQIZz/U5RFhjpyQAELC7/E6vbi84u6VX ST/YblBvLJeW3B1GmmWJz67M8uXZn1OzPqEvkqnYC8aEHwTG6x7on321e6UC8STFJGMRNMxakyAq eYg6JUKQqWU7fIbTEhUjKfws2sw5W1QXMIIE1TCCA72gAwIBAgIIUE7G9T0RtGQwDQYJKoZIhvcN AQELBQAwcTELMAkGA1UEBhMCREUxHDAaBgNVBAoTE0RldXRzY2hlIFRlbGVrb20gQUcxHzAdBgNV BAsTFlQtVGVsZVNlYyBUcnVzdCBDZW50ZXIxIzAhBgNVBAMTGkRldXRzY2hlIFRlbGVrb20gUm9v dCBDQSAyMB4XDTE0MDcyMjEyMDgyNloXDTE5MDcwOTIzNTkwMFowWjELMAkGA1UEBhMCREUxEzAR BgNVBAoTCkRGTi1WZXJlaW4xEDAOBgNVBAsTB0RGTi1QS0kxJDAiBgNVBAMTG0RGTi1WZXJlaW4g UENBIEdsb2JhbCAtIEcwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOmbw2eF+Q2u 9Y1Uw5ZQNT1i6W5M7ZTXAFuVInTUIOs0j9bswDEEC5mB4qYU0lKgKCOEi3SJBF5b4OJ4wXjLFsso NTl7LZBF0O2gAHp8v0oOGwDDhulcKzERewzzgiRDjBw4i2poAJru3E94q9LGE5t2re7eJujvAa90 D8EJovZrzr3TzRQwT/Xl46TIYpuCGgMnMA0CZWBN7dEJIyqWNVgn03bGcbaQHcTt/zWGfW8zs9sP xRHCioOhlF1Ba9jSEPVM/cpRrNm975KDu9rrixZWVkPP4dUTPaYfJzDNSVTbyRM0mnF1xWzqpwuY +SGdJ68+ozk5SGqMrcmZ+8MS8r0CAwEAAaOCAYYwggGCMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4E FgQUSbfGz+g9H3/qRHsTKffxCnA+3mQwHwYDVR0jBBgwFoAUMcN5G7r1U9cX4Il6LRdsCrMrnTMw EgYDVR0TAQH/BAgwBgEB/wIBAjBiBgNVHSAEWzBZMBEGDysGAQQBga0hgiwBAQQCAjARBg8rBgEE AYGtIYIsAQEEAwAwEQYPKwYBBAGBrSGCLAEBBAMBMA8GDSsGAQQBga0hgiwBAQQwDQYLKwYBBAGB rSGCLB4wPgYDVR0fBDcwNTAzoDGgL4YtaHR0cDovL3BraTAzMzYudGVsZXNlYy5kZS9ybC9EVF9S T09UX0NBXzIuY3JsMHgGCCsGAQUFBwEBBGwwajAsBggrBgEFBQcwAYYgaHR0cDovL29jc3AwMzM2 LnRlbGVzZWMuZGUvb2NzcHIwOgYIKwYBBQUHMAKGLmh0dHA6Ly9wa2kwMzM2LnRlbGVzZWMuZGUv Y3J0L0RUX1JPT1RfQ0FfMi5jZXIwDQYJKoZIhvcNAQELBQADggEBAGMgKP2cIYZyvjlGWTkyJbyp AZsNzMp9QZyGbQpuLLMTWXWxM5IbYScW/8Oy1TWC+4QqAUm9ZrtmL7LCBl1uP27jAVpbykNjXJW2 4TGnH9UHX03mZYJOMvnDfHpLzU1cdO4h8nUC7FI+0slq05AjbklnNb5/TVak7Mwvz7ehl6hyPsm8 QNZapAg91ryCw7e3Mo6xLI5qbbc1AhnP9TlEWGOnJAAQsLv8Tq9uLzi7pVdJP9huUG8sl5bcHUaa ZYnPrszy5dmfU7M+oS+SqdgLxoQfBMbrHuiffbV7pQLxJMUkYxE0zFqTICp5iDolQpCpZTt8htMS FSMp/CzazDlbVBcwggU9MIIEJaADAgECAgcXr/adVkv+MA0GCSqGSIb3DQEBCwUAMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtE Rk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwHhcNMTQwNjA1MTQwNTAyWhcNMTkwNzA5MjM1OTAw WjBpMQswCQYDVQQGEwJERTEuMCwGA1UEChMlUGh5c2lrYWxpc2NoLVRlY2huaXNjaGUgQnVuZGVz YW5zdGFsdDEPMA0GA1UEAxMGUFRCIENBMRkwFwYJKoZIhvcNAQkBFgpwa2lAcHRiLmRlMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvArCgzkqw2LMAYuU38VJTgyGBC+Pp+uvw52LmtI6 MEMiFr0xY6SEzYcDG3z5NSohZisdnL7bu8Ee7MFD3TZX1jVBie//UNAJqXbHnUzE8hbJYCR5ydb9 WqIzoT5PzG07qJWblbidcrZVcCQEef9V1CaRyfXuqiSTOgibqODLP98N7jMIImz2ipUgMdoGyOgS h/qds5SM6CUgwMeuJ42QpYNot9ri1IKAweyhIIa3TANsu56scy+Fc2+XWOfsuImeeLcaiu6HJPk6 X55QT+kWaAoQf6qJyJXv8b/n6l1nmTIU2AY2B5EnO/rIT+DW+MJy77/HO+7rtwaznuntXMgytwID AQABo4IB9zCCAfMwEgYDVR0TAQH/BAgwBgEB/wIBATAOBgNVHQ8BAf8EBAMCAQYwEQYDVR0gBAow CDAGBgRVHSAAMB0GA1UdDgQWBBTEgNBuKBVoMVrscF94juEwQzjqNDAfBgNVHSMEGDAWgBRJt8bP 6D0ff+pEexMp9/EKcD7eZDAVBgNVHREEDjAMgQpwa2lAcHRiLmRlMIGIBgNVHR8EgYAwfjA9oDug OYY3aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY3JsL2NhY3JsLmNy bDA9oDugOYY3aHR0cDovL2NkcDIucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY3JsL2Nh Y3JsLmNybDCB1wYIKwYBBQUHAQEEgcowgccwMwYIKwYBBQUHMAGGJ2h0dHA6Ly9vY3NwLnBjYS5k Zm4uZGUvT0NTUC1TZXJ2ZXIvT0NTUDBHBggrBgEFBQcwAoY7aHR0cDovL2NkcDEucGNhLmRmbi5k ZS9nbG9iYWwtcm9vdC1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwRwYIKwYBBQUHMAKGO2h0dHA6 Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MA0G CSqGSIb3DQEBCwUAA4IBAQCo3hebMpEocLPJTOlDMAmSzpxK3SA1ftaQqodbMncOi9WkeICQlmIv rQxGCq8Be/6hKtIrbFOhRtSzQi870glJRj7dhZaHC+WOgT5tP5Nkgwpgl4k4pQDXPPrwmaI6cSYD a/LpprQzBNjEQMdQqkeanpD0WU9U1pOPFIMfIrxh2cy8mBpIAMuZqMHbMyPNDZk/YN4r3b2DcBrQ wL/tHerp6Vc7n9WqO+3cm7Fa4AxL9q2KeItyYe0Cws2KZNz4IuiMjQAclNL0PhTEqIzkD/EiK6Ag 1qcH7o3ktpmakvL2RzSZA71irCfONRgh/+ixfuMu6YA5uzyA8SYfwyFQcABdMIIFPTCCBCWgAwIB AgIHF6/2nVZL/jANBgkqhkiG9w0BAQsFADBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZOLVZl cmVpbjEQMA4GA1UECxMHREZOLVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xvYmFsIC0g RzAxMB4XDTE0MDYwNTE0MDUwMloXDTE5MDcwOTIzNTkwMFowaTELMAkGA1UEBhMCREUxLjAsBgNV BAoTJVBoeXNpa2FsaXNjaC1UZWNobmlzY2hlIEJ1bmRlc2Fuc3RhbHQxDzANBgNVBAMTBlBUQiBD QTEZMBcGCSqGSIb3DQEJARYKcGtpQHB0Yi5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALwKwoM5KsNizAGLlN/FSU4MhgQvj6frr8Odi5rSOjBDIha9MWOkhM2HAxt8+TUqIWYrHZy+ 27vBHuzBQ902V9Y1QYnv/1DQCal2x51MxPIWyWAkecnW/VqiM6E+T8xtO6iVm5W4nXK2VXAkBHn/ VdQmkcn17qokkzoIm6jgyz/fDe4zCCJs9oqVIDHaBsjoEof6nbOUjOglIMDHrieNkKWDaLfa4tSC gMHsoSCGt0wDbLuerHMvhXNvl1jn7LiJnni3GoruhyT5Ol+eUE/pFmgKEH+qiciV7/G/5+pdZ5ky FNgGNgeRJzv6yE/g1vjCcu+/xzvu67cGs57p7VzIMrcCAwEAAaOCAfcwggHzMBIGA1UdEwEB/wQI MAYBAf8CAQEwDgYDVR0PAQH/BAQDAgEGMBEGA1UdIAQKMAgwBgYEVR0gADAdBgNVHQ4EFgQUxIDQ bigVaDFa7HBfeI7hMEM46jQwHwYDVR0jBBgwFoAUSbfGz+g9H3/qRHsTKffxCnA+3mQwFQYDVR0R BA4wDIEKcGtpQHB0Yi5kZTCBiAYDVR0fBIGAMH4wPaA7oDmGN2h0dHA6Ly9jZHAxLnBjYS5kZm4u ZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NybC9jYWNybC5jcmwwPaA7oDmGN2h0dHA6Ly9jZHAyLnBj YS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NybC9jYWNybC5jcmwwgdcGCCsGAQUFBwEBBIHK MIHHMDMGCCsGAQUFBzABhidodHRwOi8vb2NzcC5wY2EuZGZuLmRlL09DU1AtU2VydmVyL09DU1Aw RwYIKwYBBQUHMAKGO2h0dHA6Ly9jZHAxLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2Nh Y2VydC9jYWNlcnQuY3J0MEcGCCsGAQUFBzAChjtodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2dsb2Jh bC1yb290LWNhL3B1Yi9jYWNlcnQvY2FjZXJ0LmNydDANBgkqhkiG9w0BAQsFAAOCAQEAqN4XmzKR KHCzyUzpQzAJks6cSt0gNX7WkKqHWzJ3DovVpHiAkJZiL60MRgqvAXv+oSrSK2xToUbUs0IvO9IJ SUY+3YWWhwvljoE+bT+TZIMKYJeJOKUA1zz68JmiOnEmA2vy6aa0MwTYxEDHUKpHmp6Q9FlPVNaT jxSDHyK8YdnMvJgaSADLmajB2zMjzQ2ZP2DeK929g3Aa0MC/7R3q6elXO5/Vqjvt3JuxWuAMS/at iniLcmHtAsLNimTc+CLojI0AHJTS9D4UxKiM5A/xIiugINanB+6N5LaZmpLy9kc0mQO9YqwnzjUY If/osX7jLumAObs8gPEmH8MhUHAAXTCCBaIwggSKoAMCAQICDBxmO6qdufc5yhZ6iDANBgkqhkiG 9w0BAQsFADBpMQswCQYDVQQGEwJERTEuMCwGA1UEChMlUGh5c2lrYWxpc2NoLVRlY2huaXNjaGUg QnVuZGVzYW5zdGFsdDEPMA0GA1UEAxMGUFRCIENBMRkwFwYJKoZIhvcNAQkBFgpwa2lAcHRiLmRl MB4XDTE2MTIwNjEzMzMxNFoXDTE5MDcwOTIzNTkwMFowaDELMAkGA1UEBhMCREUxLjAsBgNVBAoM JVBoeXNpa2FsaXNjaC1UZWNobmlzY2hlIEJ1bmRlc2Fuc3RhbHQxDTALBgNVBAsMBFEuNDIxGjAY BgNVBAMMEURyLiBEaWV0ZXIgU2lib2xkMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA +AOQrmrEQ2k8s9su/TVvmdF46YbL2MuF6OvnrjjKaJIkBvchop87cCwv80aZEbmU3as54egQEMGn NFkp1fF4bics4TJdEpND116l+jbi5DCtA3hHP/spV1aQZBDc/BDkm1Nl5WYKh/DxN6sUhZxorbb4 Y0nmSxnK2ctIwuF4Qdibsw7GE2YLvWF4tlzSCGbDjSy2agSn1wYHMsC+tAcFflcMXF2sDMZHkYuq 5IHwng8GBQFhsldYl1fk2sB2/hVRLYU205qaj13H94WjfDLuB22sT17XPJ2U/9tuFN/sxAPR0/N4 y4/IgMnOaP30VU0FMmULd7qJg0WST5D5kwgMhwIDAQABo4ICSTCCAkUwQAYDVR0gBDkwNzARBg8r BgEEAYGtIYIsAQEEAwUwEQYPKwYBBAGBrSGCLAIBBAMBMA8GDSsGAQQBga0hgiwBAQQwCQYDVR0T BAIwADAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1Ud DgQWBBQHn42zKDpvJi1bsJ4OVk2A9liUFjAfBgNVHSMEGDAWgBTEgNBuKBVoMVrscF94juEwQzjq NDBEBgNVHREEPTA7gRRkaWV0ZXIuc2lib2xkQHB0Yi5kZaAjBgorBgEEAYI3FAIDoBUME3NpYm9s ZDAxQHBhZC5wdGIuZGUwdwYDVR0fBHAwbjA1oDOgMYYvaHR0cDovL2NkcDEucGNhLmRmbi5kZS9w dGItY2EvcHViL2NybC9jYWNybC5jcmwwNaAzoDGGL2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvcHRi LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIHHBggrBgEFBQcBAQSBujCBtzAzBggrBgEFBQcwAYYnaHR0 cDovL29jc3AucGNhLmRmbi5kZS9PQ1NQLVNlcnZlci9PQ1NQMD8GCCsGAQUFBzAChjNodHRwOi8v Y2RwMS5wY2EuZGZuLmRlL3B0Yi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwPwYIKwYBBQUHMAKG M2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvcHRiLWNhL3B1Yi9jYWNlcnQvY2FjZXJ0LmNydDANBgkq hkiG9w0BAQsFAAOCAQEADaSfgrrQZx9eiQrCK7kgJMpLstro5OgIcWSpW4i4AQ1wEwyDUrdB1XWK GjA8/KwExSBP9a+dcdW+ACjX7TyURQPLqRTOkoPc9dafRx327mV4K8PE8z7fg5l2ittYNs0nXlOB QevRbYYP4XUOMYohFWfHpDwEg3ExmoArb2HaQCzKhq/2VcIIXTwaN6AVr2NVKEuH3qwpgOUSlJJ1 5ORb6TD4p1G2W6XT3jk3tOa8nRaOkI5hqpPvLfbPEibn+Bfqm6GWqpXfQ6NLAvWYcI8ltSKgdnCw Rmqdh1Ba/KWGdm41PDtQIx58vgbZGfN5GKJrp+OwS5D+/e/r296qoKUBRDCCBaIwggSKoAMCAQIC DBxmO6qdufc5yhZ6iDANBgkqhkiG9w0BAQsFADBpMQswCQYDVQQGEwJERTEuMCwGA1UEChMlUGh5 c2lrYWxpc2NoLVRlY2huaXNjaGUgQnVuZGVzYW5zdGFsdDEPMA0GA1UEAxMGUFRCIENBMRkwFwYJ KoZIhvcNAQkBFgpwa2lAcHRiLmRlMB4XDTE2MTIwNjEzMzMxNFoXDTE5MDcwOTIzNTkwMFowaDEL MAkGA1UEBhMCREUxLjAsBgNVBAoMJVBoeXNpa2FsaXNjaC1UZWNobmlzY2hlIEJ1bmRlc2Fuc3Rh bHQxDTALBgNVBAsMBFEuNDIxGjAYBgNVBAMMEURyLiBEaWV0ZXIgU2lib2xkMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA+AOQrmrEQ2k8s9su/TVvmdF46YbL2MuF6OvnrjjKaJIkBvch op87cCwv80aZEbmU3as54egQEMGnNFkp1fF4bics4TJdEpND116l+jbi5DCtA3hHP/spV1aQZBDc /BDkm1Nl5WYKh/DxN6sUhZxorbb4Y0nmSxnK2ctIwuF4Qdibsw7GE2YLvWF4tlzSCGbDjSy2agSn 1wYHMsC+tAcFflcMXF2sDMZHkYuq5IHwng8GBQFhsldYl1fk2sB2/hVRLYU205qaj13H94WjfDLu B22sT17XPJ2U/9tuFN/sxAPR0/N4y4/IgMnOaP30VU0FMmULd7qJg0WST5D5kwgMhwIDAQABo4IC STCCAkUwQAYDVR0gBDkwNzARBg8rBgEEAYGtIYIsAQEEAwUwEQYPKwYBBAGBrSGCLAIBBAMBMA8G DSsGAQQBga0hgiwBAQQwCQYDVR0TBAIwADAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYB BQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQHn42zKDpvJi1bsJ4OVk2A9liUFjAfBgNVHSMEGDAW gBTEgNBuKBVoMVrscF94juEwQzjqNDBEBgNVHREEPTA7gRRkaWV0ZXIuc2lib2xkQHB0Yi5kZaAj BgorBgEEAYI3FAIDoBUME3NpYm9sZDAxQHBhZC5wdGIuZGUwdwYDVR0fBHAwbjA1oDOgMYYvaHR0 cDovL2NkcDEucGNhLmRmbi5kZS9wdGItY2EvcHViL2NybC9jYWNybC5jcmwwNaAzoDGGL2h0dHA6 Ly9jZHAyLnBjYS5kZm4uZGUvcHRiLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIHHBggrBgEFBQcBAQSB ujCBtzAzBggrBgEFBQcwAYYnaHR0cDovL29jc3AucGNhLmRmbi5kZS9PQ1NQLVNlcnZlci9PQ1NQ MD8GCCsGAQUFBzAChjNodHRwOi8vY2RwMS5wY2EuZGZuLmRlL3B0Yi1jYS9wdWIvY2FjZXJ0L2Nh Y2VydC5jcnQwPwYIKwYBBQUHMAKGM2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvcHRiLWNhL3B1Yi9j YWNlcnQvY2FjZXJ0LmNydDANBgkqhkiG9w0BAQsFAAOCAQEADaSfgrrQZx9eiQrCK7kgJMpLstro 5OgIcWSpW4i4AQ1wEwyDUrdB1XWKGjA8/KwExSBP9a+dcdW+ACjX7TyURQPLqRTOkoPc9dafRx32 7mV4K8PE8z7fg5l2ittYNs0nXlOBQevRbYYP4XUOMYohFWfHpDwEg3ExmoArb2HaQCzKhq/2VcII XTwaN6AVr2NVKEuH3qwpgOUSlJJ15ORb6TD4p1G2W6XT3jk3tOa8nRaOkI5hqpPvLfbPEibn+Bfq m6GWqpXfQ6NLAvWYcI8ltSKgdnCwRmqdh1Ba/KWGdm41PDtQIx58vgbZGfN5GKJrp+OwS5D+/e/r 296qoKUBRDGCAuMwggLfAgEBMHkwaTELMAkGA1UEBhMCREUxLjAsBgNVBAoTJVBoeXNpa2FsaXNj aC1UZWNobmlzY2hlIEJ1bmRlc2Fuc3RhbHQxDzANBgNVBAMTBlBUQiBDQTEZMBcGCSqGSIb3DQEJ ARYKcGtpQHB0Yi5kZQIMHGY7qp259znKFnqIMA0GCWCGSAFlAwQCAQUAoIIBOzAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzA4MjEwNzI3MjhaMC8GCSqGSIb3DQEJ BDEiBCBlCyseFGBJWKQZeui+ck2tEwF1EqinklJEVmoY3pzi/DBDBgkqhkiG9w0BCQ8xNjA0MAcG BSsOAwIdMA4GCCqGSIb3DQMCAgIAgDAKBggqhkiG9w0DBzANBggqhkiG9w0DAgIBKDCBigYLKoZI hvcNAQkQAgsxe6B5MGkxCzAJBgNVBAYTAkRFMS4wLAYDVQQKEyVQaHlzaWthbGlzY2gtVGVjaG5p c2NoZSBCdW5kZXNhbnN0YWx0MQ8wDQYDVQQDEwZQVEIgQ0ExGTAXBgkqhkiG9w0BCQEWCnBraUBw dGIuZGUCDBxmO6qdufc5yhZ6iDANBgkqhkiG9w0BAQEFAASCAQDfj4TGoUUclUJVqDhvjNQIFurD 7lDqa0pHHNsoHJKqj5JKiZlfd3T/Uy8cPfuen1yNYJ1O0Xne+Lna+2aBSgMSlty7Pv3tJHnbKRBC aB9AbZAILuQY741S/8JT7OAYDV5KRkYK2mgHfgunSBckaJAFmF8OW2F4oFtYZJUdPkvtPVvJC72B T/3yOx9pskRRFwuva3nKQxMzji/gMhf+Puc82Ot1NocdS6c5CwjoUNcKLqLPpvDPM1O5xlaM770b pKxcbtsVxpCWSmVVZWKc9/doAJzWWk6CzHorEm9Y4E9/lhRrMFEqjszmMK4HhhzLUwrlDY767YJa edOdsVSNYYbpAAAAAA== ---------z29935_boundary_sign-- From ntp-bounces@ietf.org Mon Aug 21 00:27:39 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 99C9613291B; Mon, 21 Aug 2017 00:27:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1503300459; bh=HaR1ociv5UAILZCFfyDk/0qYfCsC72RjeRUQRX1l3G4=; h=In-Reply-To:References:To:From:Date:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc; b=mJAwTUB98h0I0IX4PVqmhrpwuYkwfQ9xXhFHe7ZjqrJb8QQS6ESJxQ6iWJym3+kxN Ndp2SBLxuMz5QYsWTDgDOaXX3IOnekUlStlD6X5X8r/5Dh4xLCcp/PjfPeUr3GFuAm iD0miBWuSVB6QTnSg8ZpWI21LILTlto9V2M1qQHM= 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 B80FD132914 for ; Mon, 21 Aug 2017 00:27:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 kwGa0xA4lrgY for ; Mon, 21 Aug 2017 00:27:34 -0700 (PDT) Received: from mx1.bs.ptb.de (mx1.bs.ptb.de [IPv6:2001:638:610:bd01::120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BB3E1328DB for ; Mon, 21 Aug 2017 00:27:33 -0700 (PDT) Received: from smtp-hub.bs.ptb.de (smtpint01.bs.ptb.de [141.25.87.32]) by mx1.bs.ptb.de with ESMTP id v7L7RVGe013627-v7L7RVGg013627 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 21 Aug 2017 09:27:31 +0200 Received: from rose.bs.ptb.de (rose.bs.ptb.de [141.25.85.201]) by smtp-hub.bs.ptb.de (Postfix) with ESMTPS id 42F1C52F5DD; Mon, 21 Aug 2017 09:27:30 +0200 (CEST) In-Reply-To: References: To: Harlan Stenn MIME-Version: 1.0 Message-ID: From: dieter.sibold@ptb.de Date: Mon, 21 Aug 2017 09:27:28 +0200 Archived-At: Subject: [Ntp] Antwort: NTS/Updated Autokey X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: ntp@ietf.org Content-Type: multipart/mixed; boundary="===============9181650928720247679==" Errors-To: ntp-bounces@ietf.org Sender: "ntp" This is an S/MIME signed message. --===============9181650928720247679== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha-256; boundary=-------z29935_boundary_sign This is an S/MIME signed message. ---------z29935_boundary_sign Content-Type: multipart/alternative; boundary="=_alternative 0028F79CC1258183_=" Dies ist eine mehrteilige Nachricht im MIME-Format. --=_alternative 0028F79CC1258183_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable To clarify: I asked Dave to discuss his questions regarding the NTS draft=20 (https://www.ietf.org/id/draft-ietf-ntp-using-nts-for-ntp-09.txt) in the=20 NTP mailing list. I didn't asked to submit a further proposal. Dieter > Von: Harlan Stenn > An: ntp@ietf.org > Datum: 21.08.2017 04:41 > Betreff: [Ntp] NTS/Updated Autokey > Gesendet von: "ntp" >=20 > Dave has been working on an evaluation of the NTS proposal. >=20 > We've been discussing this document in our internal NTS implementation > meetings, and Dieter asked me to send this to the WG mailing list. >=20 > Dave updated the document after my last go-round, so I just took his new > version and integrated his changes with the ones we made. >=20 > I'll be working on my WGLC comments separately. > --=20 > Harlan Stenn, Network Time Foundation > http://nwtime.org - be a Member! > [Anhang "Autokey-20170815.txt" gel=F6scht von Dieter Sibold/PTB]=20 > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > ntp mailing list > ntp@ietf.org > https://www.ietf.org/mailman/listinfo/ntp --=_alternative 0028F79CC1258183_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable To clarify: I asked Dave to discuss his questions regarding the NTS draft (https://www.ietf.org/id/draft-ietf-ntp-using-nts-for-ntp-09= .txt) in the NTP mailing list. I didn't asked to submit a further proposal.

Dieter




> Von: Harlan Stenn <stenn@nwtime.org>
> An: ntp@ietf.org
> Datum: 21.08.2017 04:41
> Betreff: [Ntp] NTS/Updated Autokey
> Gesendet von: "ntp" <ntp-bounces@i= etf.org>
>
> Dave has been working on an evaluation of the NTS proposal.
>
> We've been discussing this document in our internal NTS implementation=
> meetings, and Dieter asked me to send this to the WG mailing list.
>
> Dave updated the document after my last go-round, so I just took his new
> version and integrated his changes with the ones we made.
>
> I'll be working on my WGLC comments separately.
> --
> Harlan Stenn, Network Time Foundation
> http://nwt= ime.org - be a Member!
> [Anhang "Autokey-20170815.txt" gel=F6scht von Dieter Sibold/= PTB]
> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
> ntp mailing list
> ntp@ietf.org
> https://www.ietf.org/mailman/listinfo/ntp<= font size=3D2>
 --=_alternative 0028F79CC1258183_=-- ---------z29935_boundary_sign Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIIp0gIBATEPMA0GCWCGSAFlAwQCAQUAMAsGCSqGSIb3DQEHAaCCJsYw ggOfMIICh6ADAgECAgEmMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNE ZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYD VQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw05OTA3MDkxMjExMDBaFw0xOTA3MDky MzU5MDBaMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYD VQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJv b3QgQ0EgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKsLozXgiykUsRSFrzwQ5Dlv NV1Krt3qYY2VSfRvZKMaYGakqUAihNnUpeV4kw5oAa25TVw6ztO4qEJA38+juoJZapIbrBya2ggr JSf5aSNH8eDrLHqb9RMC0H40fMKePABZq/XaDPUyPCusUNrWw96DlMqoDJkyDghIVltq+9rhWFgB SV9yQTwVBgGOXa2quJO0zZ7rp+hqLVI02zrvXHVR2tvzMfnucZgyxFQVRAz5m1Xtrd8YCKCjhopJ 7lMFjxlM1d5YeZvSahxCq8XVp89oD5bk4WGYdmHIkXzWPgDikVCH4Z0K5q2X0h3GOn3LvNoDNNWO WwH1age3FrZuSn8CAwEAAaNCMEAwHQYDVR0OBBYEFDHDeRu69VPXF+CJei0XbAqzK50zMA8GA1Ud EwQIMAYBAf8CAQUwDgYDVR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBBQUAA4IBAQCUZFmtOWTnKesT /lrDixNXyAQk8HR3wGDjZ/vpiaaDv5aCfG7Uwz3vnoBuuym0mHqxO1TrORdHfhqOC/wfMVkxBLLO F/Msx2I2VeIi2IlVtJhIqmT61hw22ER4WlojOleX9XowT66fakxLK46gA+M+4KnU0nvSs6jicjyt nv+AWeSbRbT2O7DNORmYMuXqIWGQ5DEhjjSx9y81SoUQ2ueKNyG+WWPg8oWIMVPUVBSFcHn0LgZ3 J3UvH7iK+f7Futg25IPs52W3v2Na80avgZQ31EGM1iPWHs/1aBtEY6Jauqc1WaHlcAWbDiNXmZQK bbo5YyiGkvMYhNj70c8FVmRXMIIDnzCCAoegAwIBAgIBJjANBgkqhkiG9w0BAQUFADBxMQswCQYD VQQGEwJERTEcMBoGA1UEChMTRGV1dHNjaGUgVGVsZWtvbSBBRzEfMB0GA1UECxMWVC1UZWxlU2Vj IFRydXN0IENlbnRlcjEjMCEGA1UEAxMaRGV1dHNjaGUgVGVsZWtvbSBSb290IENBIDIwHhcNOTkw NzA5MTIxMTAwWhcNMTkwNzA5MjM1OTAwWjBxMQswCQYDVQQGEwJERTEcMBoGA1UEChMTRGV1dHNj aGUgVGVsZWtvbSBBRzEfMB0GA1UECxMWVC1UZWxlU2VjIFRydXN0IENlbnRlcjEjMCEGA1UEAxMa RGV1dHNjaGUgVGVsZWtvbSBSb290IENBIDIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCrC6M14IspFLEUha88EOQ5bzVdSq7d6mGNlUn0b2SjGmBmpKlAIoTZ1KXleJMOaAGtuU1cOs7T uKhCQN/Po7qCWWqSG6wcmtoIKyUn+WkjR/Hg6yx6m/UTAtB+NHzCnjwAWav12gz1MjwrrFDa1sPe g5TKqAyZMg4ISFZbavva4VhYAUlfckE8FQYBjl2tqriTtM2e66foai1SNNs671x1Udrb8zH57nGY MsRUFUQM+ZtV7a3fGAigo4aKSe5TBY8ZTNXeWHmb0mocQqvF1afPaA+W5OFhmHZhyJF81j4A4pFQ h+GdCuatl9Idxjp9y7zaAzTVjlsB9WoHtxa2bkp/AgMBAAGjQjBAMB0GA1UdDgQWBBQxw3kbuvVT 1xfgiXotF2wKsyudMzAPBgNVHRMECDAGAQH/AgEFMA4GA1UdDwEB/wQEAwIBBjANBgkqhkiG9w0B AQUFAAOCAQEAlGRZrTlk5ynrE/5aw4sTV8gEJPB0d8Bg42f76Ymmg7+Wgnxu1MM9756AbrsptJh6 sTtU6zkXR34ajgv8HzFZMQSyzhfzLMdiNlXiItiJVbSYSKpk+tYcNthEeFpaIzpXl/V6ME+un2pM SyuOoAPjPuCp1NJ70rOo4nI8rZ7/gFnkm0W09juwzTkZmDLl6iFhkOQxIY40sfcvNUqFENrnijch vllj4PKFiDFT1FQUhXB59C4Gdyd1Lx+4ivn+xbrYNuSD7Odlt79jWvNGr4GUN9RBjNYj1h7P9Wgb RGOiWrqnNVmh5XAFmw4jV5mUCm26OWMohpLzGITY+9HPBVZkVzCCBNUwggO9oAMCAQICCFBOxvU9 EbRkMA0GCSqGSIb3DQEBCwUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNEZXV0c2NoZSBUZWxl a29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYDVQQDExpEZXV0c2No ZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0xNDA3MjIxMjA4MjZaFw0xOTA3MDkyMzU5MDBaMFoxCzAJ BgNVBAYTAkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQD ExtERk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U1wBblSJ01CDrNI/W7MAxBAuZgeKmFNJSoCgjhIt0 iQReW+DieMF4yxbLKDU5ey2QRdDtoAB6fL9KDhsAw4bpXCsxEXsM84IkQ4wcOItqaACa7txPeKvS xhObdq3u3ibo7wGvdA/BCaL2a869080UME/15eOkyGKbghoDJzANAmVgTe3RCSMqljVYJ9N2xnG2 kB3E7f81hn1vM7PbD8URwoqDoZRdQWvY0hD1TP3KUazZve+Sg7va64sWVlZDz+HVEz2mHycwzUlU 28kTNJpxdcVs6qcLmPkhnSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjggGGMIIBgjAOBgNVHQ8BAf8E BAMCAQYwHQYDVR0OBBYEFEm3xs/oPR9/6kR7Eyn38QpwPt5kMB8GA1UdIwQYMBaAFDHDeRu69VPX F+CJei0XbAqzK50zMBIGA1UdEwEB/wQIMAYBAf8CAQIwYgYDVR0gBFswWTARBg8rBgEEAYGtIYIs AQEEAgIwEQYPKwYBBAGBrSGCLAEBBAMAMBEGDysGAQQBga0hgiwBAQQDATAPBg0rBgEEAYGtIYIs AQEEMA0GCysGAQQBga0hgiweMD4GA1UdHwQ3MDUwM6AxoC+GLWh0dHA6Ly9wa2kwMzM2LnRlbGVz ZWMuZGUvcmwvRFRfUk9PVF9DQV8yLmNybDB4BggrBgEFBQcBAQRsMGowLAYIKwYBBQUHMAGGIGh0 dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMDoGCCsGAQUFBzAChi5odHRwOi8vcGtpMDMz Ni50ZWxlc2VjLmRlL2NydC9EVF9ST09UX0NBXzIuY2VyMA0GCSqGSIb3DQEBCwUAA4IBAQBjICj9 nCGGcr45Rlk5MiW8qQGbDczKfUGchm0KbiyzE1l1sTOSG2EnFv/DstU1gvuEKgFJvWa7Zi+ywgZd bj9u4wFaW8pDY1yVtuExpx/VB19N5mWCTjL5w3x6S81NXHTuIfJ1AuxSPtLJatOQI25JZzW+f01W pOzML8+3oZeocj7JvEDWWqQIPda8gsO3tzKOsSyOam23NQIZz/U5RFhjpyQAELC7/E6vbi84u6VX ST/YblBvLJeW3B1GmmWJz67M8uXZn1OzPqEvkqnYC8aEHwTG6x7on321e6UC8STFJGMRNMxakyAq eYg6JUKQqWU7fIbTEhUjKfws2sw5W1QXMIIE1TCCA72gAwIBAgIIUE7G9T0RtGQwDQYJKoZIhvcN AQELBQAwcTELMAkGA1UEBhMCREUxHDAaBgNVBAoTE0RldXRzY2hlIFRlbGVrb20gQUcxHzAdBgNV BAsTFlQtVGVsZVNlYyBUcnVzdCBDZW50ZXIxIzAhBgNVBAMTGkRldXRzY2hlIFRlbGVrb20gUm9v dCBDQSAyMB4XDTE0MDcyMjEyMDgyNloXDTE5MDcwOTIzNTkwMFowWjELMAkGA1UEBhMCREUxEzAR BgNVBAoTCkRGTi1WZXJlaW4xEDAOBgNVBAsTB0RGTi1QS0kxJDAiBgNVBAMTG0RGTi1WZXJlaW4g UENBIEdsb2JhbCAtIEcwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOmbw2eF+Q2u 9Y1Uw5ZQNT1i6W5M7ZTXAFuVInTUIOs0j9bswDEEC5mB4qYU0lKgKCOEi3SJBF5b4OJ4wXjLFsso NTl7LZBF0O2gAHp8v0oOGwDDhulcKzERewzzgiRDjBw4i2poAJru3E94q9LGE5t2re7eJujvAa90 D8EJovZrzr3TzRQwT/Xl46TIYpuCGgMnMA0CZWBN7dEJIyqWNVgn03bGcbaQHcTt/zWGfW8zs9sP xRHCioOhlF1Ba9jSEPVM/cpRrNm975KDu9rrixZWVkPP4dUTPaYfJzDNSVTbyRM0mnF1xWzqpwuY +SGdJ68+ozk5SGqMrcmZ+8MS8r0CAwEAAaOCAYYwggGCMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4E FgQUSbfGz+g9H3/qRHsTKffxCnA+3mQwHwYDVR0jBBgwFoAUMcN5G7r1U9cX4Il6LRdsCrMrnTMw EgYDVR0TAQH/BAgwBgEB/wIBAjBiBgNVHSAEWzBZMBEGDysGAQQBga0hgiwBAQQCAjARBg8rBgEE AYGtIYIsAQEEAwAwEQYPKwYBBAGBrSGCLAEBBAMBMA8GDSsGAQQBga0hgiwBAQQwDQYLKwYBBAGB rSGCLB4wPgYDVR0fBDcwNTAzoDGgL4YtaHR0cDovL3BraTAzMzYudGVsZXNlYy5kZS9ybC9EVF9S T09UX0NBXzIuY3JsMHgGCCsGAQUFBwEBBGwwajAsBggrBgEFBQcwAYYgaHR0cDovL29jc3AwMzM2 LnRlbGVzZWMuZGUvb2NzcHIwOgYIKwYBBQUHMAKGLmh0dHA6Ly9wa2kwMzM2LnRlbGVzZWMuZGUv Y3J0L0RUX1JPT1RfQ0FfMi5jZXIwDQYJKoZIhvcNAQELBQADggEBAGMgKP2cIYZyvjlGWTkyJbyp AZsNzMp9QZyGbQpuLLMTWXWxM5IbYScW/8Oy1TWC+4QqAUm9ZrtmL7LCBl1uP27jAVpbykNjXJW2 4TGnH9UHX03mZYJOMvnDfHpLzU1cdO4h8nUC7FI+0slq05AjbklnNb5/TVak7Mwvz7ehl6hyPsm8 QNZapAg91ryCw7e3Mo6xLI5qbbc1AhnP9TlEWGOnJAAQsLv8Tq9uLzi7pVdJP9huUG8sl5bcHUaa ZYnPrszy5dmfU7M+oS+SqdgLxoQfBMbrHuiffbV7pQLxJMUkYxE0zFqTICp5iDolQpCpZTt8htMS FSMp/CzazDlbVBcwggU9MIIEJaADAgECAgcXr/adVkv+MA0GCSqGSIb3DQEBCwUAMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtE Rk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwHhcNMTQwNjA1MTQwNTAyWhcNMTkwNzA5MjM1OTAw WjBpMQswCQYDVQQGEwJERTEuMCwGA1UEChMlUGh5c2lrYWxpc2NoLVRlY2huaXNjaGUgQnVuZGVz YW5zdGFsdDEPMA0GA1UEAxMGUFRCIENBMRkwFwYJKoZIhvcNAQkBFgpwa2lAcHRiLmRlMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvArCgzkqw2LMAYuU38VJTgyGBC+Pp+uvw52LmtI6 MEMiFr0xY6SEzYcDG3z5NSohZisdnL7bu8Ee7MFD3TZX1jVBie//UNAJqXbHnUzE8hbJYCR5ydb9 WqIzoT5PzG07qJWblbidcrZVcCQEef9V1CaRyfXuqiSTOgibqODLP98N7jMIImz2ipUgMdoGyOgS h/qds5SM6CUgwMeuJ42QpYNot9ri1IKAweyhIIa3TANsu56scy+Fc2+XWOfsuImeeLcaiu6HJPk6 X55QT+kWaAoQf6qJyJXv8b/n6l1nmTIU2AY2B5EnO/rIT+DW+MJy77/HO+7rtwaznuntXMgytwID AQABo4IB9zCCAfMwEgYDVR0TAQH/BAgwBgEB/wIBATAOBgNVHQ8BAf8EBAMCAQYwEQYDVR0gBAow CDAGBgRVHSAAMB0GA1UdDgQWBBTEgNBuKBVoMVrscF94juEwQzjqNDAfBgNVHSMEGDAWgBRJt8bP 6D0ff+pEexMp9/EKcD7eZDAVBgNVHREEDjAMgQpwa2lAcHRiLmRlMIGIBgNVHR8EgYAwfjA9oDug OYY3aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY3JsL2NhY3JsLmNy bDA9oDugOYY3aHR0cDovL2NkcDIucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY3JsL2Nh Y3JsLmNybDCB1wYIKwYBBQUHAQEEgcowgccwMwYIKwYBBQUHMAGGJ2h0dHA6Ly9vY3NwLnBjYS5k Zm4uZGUvT0NTUC1TZXJ2ZXIvT0NTUDBHBggrBgEFBQcwAoY7aHR0cDovL2NkcDEucGNhLmRmbi5k ZS9nbG9iYWwtcm9vdC1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwRwYIKwYBBQUHMAKGO2h0dHA6 Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MA0G CSqGSIb3DQEBCwUAA4IBAQCo3hebMpEocLPJTOlDMAmSzpxK3SA1ftaQqodbMncOi9WkeICQlmIv rQxGCq8Be/6hKtIrbFOhRtSzQi870glJRj7dhZaHC+WOgT5tP5Nkgwpgl4k4pQDXPPrwmaI6cSYD a/LpprQzBNjEQMdQqkeanpD0WU9U1pOPFIMfIrxh2cy8mBpIAMuZqMHbMyPNDZk/YN4r3b2DcBrQ wL/tHerp6Vc7n9WqO+3cm7Fa4AxL9q2KeItyYe0Cws2KZNz4IuiMjQAclNL0PhTEqIzkD/EiK6Ag 1qcH7o3ktpmakvL2RzSZA71irCfONRgh/+ixfuMu6YA5uzyA8SYfwyFQcABdMIIFPTCCBCWgAwIB AgIHF6/2nVZL/jANBgkqhkiG9w0BAQsFADBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZOLVZl cmVpbjEQMA4GA1UECxMHREZOLVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xvYmFsIC0g RzAxMB4XDTE0MDYwNTE0MDUwMloXDTE5MDcwOTIzNTkwMFowaTELMAkGA1UEBhMCREUxLjAsBgNV BAoTJVBoeXNpa2FsaXNjaC1UZWNobmlzY2hlIEJ1bmRlc2Fuc3RhbHQxDzANBgNVBAMTBlBUQiBD QTEZMBcGCSqGSIb3DQEJARYKcGtpQHB0Yi5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALwKwoM5KsNizAGLlN/FSU4MhgQvj6frr8Odi5rSOjBDIha9MWOkhM2HAxt8+TUqIWYrHZy+ 27vBHuzBQ902V9Y1QYnv/1DQCal2x51MxPIWyWAkecnW/VqiM6E+T8xtO6iVm5W4nXK2VXAkBHn/ VdQmkcn17qokkzoIm6jgyz/fDe4zCCJs9oqVIDHaBsjoEof6nbOUjOglIMDHrieNkKWDaLfa4tSC gMHsoSCGt0wDbLuerHMvhXNvl1jn7LiJnni3GoruhyT5Ol+eUE/pFmgKEH+qiciV7/G/5+pdZ5ky FNgGNgeRJzv6yE/g1vjCcu+/xzvu67cGs57p7VzIMrcCAwEAAaOCAfcwggHzMBIGA1UdEwEB/wQI MAYBAf8CAQEwDgYDVR0PAQH/BAQDAgEGMBEGA1UdIAQKMAgwBgYEVR0gADAdBgNVHQ4EFgQUxIDQ bigVaDFa7HBfeI7hMEM46jQwHwYDVR0jBBgwFoAUSbfGz+g9H3/qRHsTKffxCnA+3mQwFQYDVR0R BA4wDIEKcGtpQHB0Yi5kZTCBiAYDVR0fBIGAMH4wPaA7oDmGN2h0dHA6Ly9jZHAxLnBjYS5kZm4u ZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NybC9jYWNybC5jcmwwPaA7oDmGN2h0dHA6Ly9jZHAyLnBj YS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NybC9jYWNybC5jcmwwgdcGCCsGAQUFBwEBBIHK MIHHMDMGCCsGAQUFBzABhidodHRwOi8vb2NzcC5wY2EuZGZuLmRlL09DU1AtU2VydmVyL09DU1Aw RwYIKwYBBQUHMAKGO2h0dHA6Ly9jZHAxLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2Nh Y2VydC9jYWNlcnQuY3J0MEcGCCsGAQUFBzAChjtodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2dsb2Jh bC1yb290LWNhL3B1Yi9jYWNlcnQvY2FjZXJ0LmNydDANBgkqhkiG9w0BAQsFAAOCAQEAqN4XmzKR KHCzyUzpQzAJks6cSt0gNX7WkKqHWzJ3DovVpHiAkJZiL60MRgqvAXv+oSrSK2xToUbUs0IvO9IJ SUY+3YWWhwvljoE+bT+TZIMKYJeJOKUA1zz68JmiOnEmA2vy6aa0MwTYxEDHUKpHmp6Q9FlPVNaT jxSDHyK8YdnMvJgaSADLmajB2zMjzQ2ZP2DeK929g3Aa0MC/7R3q6elXO5/Vqjvt3JuxWuAMS/at iniLcmHtAsLNimTc+CLojI0AHJTS9D4UxKiM5A/xIiugINanB+6N5LaZmpLy9kc0mQO9YqwnzjUY If/osX7jLumAObs8gPEmH8MhUHAAXTCCBaIwggSKoAMCAQICDBxmO6qdufc5yhZ6iDANBgkqhkiG 9w0BAQsFADBpMQswCQYDVQQGEwJERTEuMCwGA1UEChMlUGh5c2lrYWxpc2NoLVRlY2huaXNjaGUg QnVuZGVzYW5zdGFsdDEPMA0GA1UEAxMGUFRCIENBMRkwFwYJKoZIhvcNAQkBFgpwa2lAcHRiLmRl MB4XDTE2MTIwNjEzMzMxNFoXDTE5MDcwOTIzNTkwMFowaDELMAkGA1UEBhMCREUxLjAsBgNVBAoM JVBoeXNpa2FsaXNjaC1UZWNobmlzY2hlIEJ1bmRlc2Fuc3RhbHQxDTALBgNVBAsMBFEuNDIxGjAY BgNVBAMMEURyLiBEaWV0ZXIgU2lib2xkMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA +AOQrmrEQ2k8s9su/TVvmdF46YbL2MuF6OvnrjjKaJIkBvchop87cCwv80aZEbmU3as54egQEMGn NFkp1fF4bics4TJdEpND116l+jbi5DCtA3hHP/spV1aQZBDc/BDkm1Nl5WYKh/DxN6sUhZxorbb4 Y0nmSxnK2ctIwuF4Qdibsw7GE2YLvWF4tlzSCGbDjSy2agSn1wYHMsC+tAcFflcMXF2sDMZHkYuq 5IHwng8GBQFhsldYl1fk2sB2/hVRLYU205qaj13H94WjfDLuB22sT17XPJ2U/9tuFN/sxAPR0/N4 y4/IgMnOaP30VU0FMmULd7qJg0WST5D5kwgMhwIDAQABo4ICSTCCAkUwQAYDVR0gBDkwNzARBg8r BgEEAYGtIYIsAQEEAwUwEQYPKwYBBAGBrSGCLAIBBAMBMA8GDSsGAQQBga0hgiwBAQQwCQYDVR0T BAIwADAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1Ud DgQWBBQHn42zKDpvJi1bsJ4OVk2A9liUFjAfBgNVHSMEGDAWgBTEgNBuKBVoMVrscF94juEwQzjq NDBEBgNVHREEPTA7gRRkaWV0ZXIuc2lib2xkQHB0Yi5kZaAjBgorBgEEAYI3FAIDoBUME3NpYm9s ZDAxQHBhZC5wdGIuZGUwdwYDVR0fBHAwbjA1oDOgMYYvaHR0cDovL2NkcDEucGNhLmRmbi5kZS9w dGItY2EvcHViL2NybC9jYWNybC5jcmwwNaAzoDGGL2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvcHRi LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIHHBggrBgEFBQcBAQSBujCBtzAzBggrBgEFBQcwAYYnaHR0 cDovL29jc3AucGNhLmRmbi5kZS9PQ1NQLVNlcnZlci9PQ1NQMD8GCCsGAQUFBzAChjNodHRwOi8v Y2RwMS5wY2EuZGZuLmRlL3B0Yi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwPwYIKwYBBQUHMAKG M2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvcHRiLWNhL3B1Yi9jYWNlcnQvY2FjZXJ0LmNydDANBgkq hkiG9w0BAQsFAAOCAQEADaSfgrrQZx9eiQrCK7kgJMpLstro5OgIcWSpW4i4AQ1wEwyDUrdB1XWK GjA8/KwExSBP9a+dcdW+ACjX7TyURQPLqRTOkoPc9dafRx327mV4K8PE8z7fg5l2ittYNs0nXlOB QevRbYYP4XUOMYohFWfHpDwEg3ExmoArb2HaQCzKhq/2VcIIXTwaN6AVr2NVKEuH3qwpgOUSlJJ1 5ORb6TD4p1G2W6XT3jk3tOa8nRaOkI5hqpPvLfbPEibn+Bfqm6GWqpXfQ6NLAvWYcI8ltSKgdnCw Rmqdh1Ba/KWGdm41PDtQIx58vgbZGfN5GKJrp+OwS5D+/e/r296qoKUBRDCCBaIwggSKoAMCAQIC DBxmO6qdufc5yhZ6iDANBgkqhkiG9w0BAQsFADBpMQswCQYDVQQGEwJERTEuMCwGA1UEChMlUGh5 c2lrYWxpc2NoLVRlY2huaXNjaGUgQnVuZGVzYW5zdGFsdDEPMA0GA1UEAxMGUFRCIENBMRkwFwYJ KoZIhvcNAQkBFgpwa2lAcHRiLmRlMB4XDTE2MTIwNjEzMzMxNFoXDTE5MDcwOTIzNTkwMFowaDEL MAkGA1UEBhMCREUxLjAsBgNVBAoMJVBoeXNpa2FsaXNjaC1UZWNobmlzY2hlIEJ1bmRlc2Fuc3Rh bHQxDTALBgNVBAsMBFEuNDIxGjAYBgNVBAMMEURyLiBEaWV0ZXIgU2lib2xkMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA+AOQrmrEQ2k8s9su/TVvmdF46YbL2MuF6OvnrjjKaJIkBvch op87cCwv80aZEbmU3as54egQEMGnNFkp1fF4bics4TJdEpND116l+jbi5DCtA3hHP/spV1aQZBDc /BDkm1Nl5WYKh/DxN6sUhZxorbb4Y0nmSxnK2ctIwuF4Qdibsw7GE2YLvWF4tlzSCGbDjSy2agSn 1wYHMsC+tAcFflcMXF2sDMZHkYuq5IHwng8GBQFhsldYl1fk2sB2/hVRLYU205qaj13H94WjfDLu B22sT17XPJ2U/9tuFN/sxAPR0/N4y4/IgMnOaP30VU0FMmULd7qJg0WST5D5kwgMhwIDAQABo4IC STCCAkUwQAYDVR0gBDkwNzARBg8rBgEEAYGtIYIsAQEEAwUwEQYPKwYBBAGBrSGCLAIBBAMBMA8G DSsGAQQBga0hgiwBAQQwCQYDVR0TBAIwADAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYB BQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQHn42zKDpvJi1bsJ4OVk2A9liUFjAfBgNVHSMEGDAW gBTEgNBuKBVoMVrscF94juEwQzjqNDBEBgNVHREEPTA7gRRkaWV0ZXIuc2lib2xkQHB0Yi5kZaAj BgorBgEEAYI3FAIDoBUME3NpYm9sZDAxQHBhZC5wdGIuZGUwdwYDVR0fBHAwbjA1oDOgMYYvaHR0 cDovL2NkcDEucGNhLmRmbi5kZS9wdGItY2EvcHViL2NybC9jYWNybC5jcmwwNaAzoDGGL2h0dHA6 Ly9jZHAyLnBjYS5kZm4uZGUvcHRiLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIHHBggrBgEFBQcBAQSB ujCBtzAzBggrBgEFBQcwAYYnaHR0cDovL29jc3AucGNhLmRmbi5kZS9PQ1NQLVNlcnZlci9PQ1NQ MD8GCCsGAQUFBzAChjNodHRwOi8vY2RwMS5wY2EuZGZuLmRlL3B0Yi1jYS9wdWIvY2FjZXJ0L2Nh Y2VydC5jcnQwPwYIKwYBBQUHMAKGM2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvcHRiLWNhL3B1Yi9j YWNlcnQvY2FjZXJ0LmNydDANBgkqhkiG9w0BAQsFAAOCAQEADaSfgrrQZx9eiQrCK7kgJMpLstro 5OgIcWSpW4i4AQ1wEwyDUrdB1XWKGjA8/KwExSBP9a+dcdW+ACjX7TyURQPLqRTOkoPc9dafRx32 7mV4K8PE8z7fg5l2ittYNs0nXlOBQevRbYYP4XUOMYohFWfHpDwEg3ExmoArb2HaQCzKhq/2VcII XTwaN6AVr2NVKEuH3qwpgOUSlJJ15ORb6TD4p1G2W6XT3jk3tOa8nRaOkI5hqpPvLfbPEibn+Bfq m6GWqpXfQ6NLAvWYcI8ltSKgdnCwRmqdh1Ba/KWGdm41PDtQIx58vgbZGfN5GKJrp+OwS5D+/e/r 296qoKUBRDGCAuMwggLfAgEBMHkwaTELMAkGA1UEBhMCREUxLjAsBgNVBAoTJVBoeXNpa2FsaXNj aC1UZWNobmlzY2hlIEJ1bmRlc2Fuc3RhbHQxDzANBgNVBAMTBlBUQiBDQTEZMBcGCSqGSIb3DQEJ ARYKcGtpQHB0Yi5kZQIMHGY7qp259znKFnqIMA0GCWCGSAFlAwQCAQUAoIIBOzAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzA4MjEwNzI3MjhaMC8GCSqGSIb3DQEJ BDEiBCBlCyseFGBJWKQZeui+ck2tEwF1EqinklJEVmoY3pzi/DBDBgkqhkiG9w0BCQ8xNjA0MAcG BSsOAwIdMA4GCCqGSIb3DQMCAgIAgDAKBggqhkiG9w0DBzANBggqhkiG9w0DAgIBKDCBigYLKoZI hvcNAQkQAgsxe6B5MGkxCzAJBgNVBAYTAkRFMS4wLAYDVQQKEyVQaHlzaWthbGlzY2gtVGVjaG5p c2NoZSBCdW5kZXNhbnN0YWx0MQ8wDQYDVQQDEwZQVEIgQ0ExGTAXBgkqhkiG9w0BCQEWCnBraUBw dGIuZGUCDBxmO6qdufc5yhZ6iDANBgkqhkiG9w0BAQEFAASCAQDfj4TGoUUclUJVqDhvjNQIFurD 7lDqa0pHHNsoHJKqj5JKiZlfd3T/Uy8cPfuen1yNYJ1O0Xne+Lna+2aBSgMSlty7Pv3tJHnbKRBC aB9AbZAILuQY741S/8JT7OAYDV5KRkYK2mgHfgunSBckaJAFmF8OW2F4oFtYZJUdPkvtPVvJC72B T/3yOx9pskRRFwuva3nKQxMzji/gMhf+Puc82Ot1NocdS6c5CwjoUNcKLqLPpvDPM1O5xlaM770b pKxcbtsVxpCWSmVVZWKc9/doAJzWWk6CzHorEm9Y4E9/lhRrMFEqjszmMK4HhhzLUwrlDY767YJa edOdsVSNYYbpAAAAAA== ---------z29935_boundary_sign-- --===============9181650928720247679== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp --===============9181650928720247679==-- From nobody Mon Aug 21 00:45:11 2017 Return-Path: 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 16943132926 for ; Mon, 21 Aug 2017 00:45:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no 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 hqRoWRPkLvDs for ; Mon, 21 Aug 2017 00:45:08 -0700 (PDT) Received: from rrzmta2.uni-regensburg.de (rrzmta2.uni-regensburg.de [194.94.155.52]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A82151328DB for ; Mon, 21 Aug 2017 00:45:07 -0700 (PDT) Received: from rrzmta2.uni-regensburg.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id C2F8F7947C for ; Mon, 21 Aug 2017 09:45:05 +0200 (CEST) Received: from gwsmtp1.uni-regensburg.de (gwsmtp1.uni-regensburg.de [132.199.5.51]) by rrzmta2.uni-regensburg.de (Postfix) with ESMTP id 9F2CA793FA for ; Mon, 21 Aug 2017 09:45:05 +0200 (CEST) Received: from uni-regensburg-smtp1-MTA by gwsmtp1.uni-regensburg.de with Novell_GroupWise; Mon, 21 Aug 2017 09:45:04 +0200 Message-Id: <599A8F7E020000A10002787B@gwsmtp1.uni-regensburg.de> X-Mailer: Novell GroupWise Internet Agent 14.2.2 Date: Mon, 21 Aug 2017 09:45:02 +0200 From: "Ulrich Windl" To: "ntp@ietf.org" , References: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Archived-At: Subject: [Ntp] Antw: NTS/Updated Autokey X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Aug 2017 07:45:10 -0000 >>> Harlan Stenn schrieb am 21.08.2017 um 04:41 in = Nachricht : > Dave has been working on an evaluation of the NTS proposal. >=20 > We've been discussing this document in our internal NTS implementation > meetings, and Dieter asked me to send this to the WG mailing list. >=20 > Dave updated the document after my last go-round, so I just took his new > version and integrated his changes with the ones we made. >=20 Hi, some random comments: "Ordinarily, the function octet for both the request and response messages = is the same; a bit is allocated in the function octet to serve as a = response indicator." This is kind of a contradiction IMHO: If one bit = changes, the function octet cannot be the same. I think the "minimum packet headway" is a new phrase. Why not using = "minimum poll delay" (or interval) instead? "An NTP secure network consists of an acyclic, undirected graph organized = as a tree with nodes descending from the root node." Is there really one = root? What about multiple stratum-1 servers being configured? Maybe = clarify this. "Each step involves a sign exchange, (...)" I would name it "signature = exchange" for consistency. "In particular, the packet header and extension field lengths, if = present." This is an incomplete sentence; is "are verified" missing at the = end? "The format scan results in a pointer just before the message authenticatio= n code (MAC)." Isn't this an unnecessary implementation detail (to = describe the semantics)? Maybe describe what the layer is expected to do = in better words. "However, i,t is vital (...)" Simple typo ("it is vital")... "If a shared hash key is not available, such as during the agreement = process itself, the existence of an implicit hash key zero is assumed. The = value of hash key zero could be a random number known only to verified and = trusted hosts in the NTP network. Hash key zero could be any mutually = agreed upon symmetric key. The design intent is to verify this number as = well as detect errors, rather than protect against middleman attack. By = protocol rule, if a message request uses hash key zero, the message = response also uses hash key zero." Isn't that a change to the current = implementation where no key or key ID zero means "no MAC"? "The OpenSSL library includes just about every hash algorithm likely to be = imagined. While historically ambiguous, the International Trade in Arms = Regulations (ITAR) prohibits export of the OpenSSL library, so only the = MD5 hash algorithm is included in the reference distribution. Alternatively= , the OpenSSL library can be imported from foreign or domestic sources, = although generated binaries may not be exported from the US.." Isn't there = an exception for open source products? "(...)and the modifier octet used as the key number." Shouldn't "as the = key number" be "is the key number"? Note on "The comparison of these two timestamps is called the loopback = test. The transmit timestamp functions as a nonce to verify that the = response corresponds to the original request.": In the current implementati= on this test fails if one client is configured multiple times, it seems. I'm unhappy with the phrase "sign exchange" (as said earlier): Either = "signature exchange" or "sign(ature) request" would better. Maybe it's a = CSR (Certificate Signing Request)... "In the following, the host certificate belongs to the host containing the = public/private keys, while a server certificate belongs to each association= separately." Does this say that each host has a public/private key pair = in addition to is self-signed certificate, while there is only a certificat= e for each association? If so I find the latter statement more clear. "In the authentication phase, Alice sends her signature of the shared hash = key to Bob. Bob verifies the signature, then sends his signature of the = shared hash key to Alice. Alice verifies his signature." I'm not a crypto = expert, but isn't the hash key also encrypted (in addition to being = signed) for the other party? Regards, Ulrich From ntp-bounces@ietf.org Mon Aug 21 00:45:11 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FF25132926; Mon, 21 Aug 2017 00:45:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1503301511; bh=r5aYLL2S0z8uFNiSEz/uML43oK7SSPGCJx8coY8BzUM=; h=Date:From:To:References:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe; b=j5T37Ge72wcRE2T0SsVnWxJ2qQHtIij0TEtFAKq4j8Rsi7UWY8qUIweyX97WoG4v0 jCyvKen4hM+SR78uwenI1C3YognWWRtGJCZ9byk/hx4ZhOtvVstPd1h1ejHyrzHjpl BVPe4sJQWRWhfR1TL8xkRymI2e/+7UGzoMy8s/dA= 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 16943132926 for ; Mon, 21 Aug 2017 00:45:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no 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 hqRoWRPkLvDs for ; Mon, 21 Aug 2017 00:45:08 -0700 (PDT) Received: from rrzmta2.uni-regensburg.de (rrzmta2.uni-regensburg.de [194.94.155.52]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A82151328DB for ; Mon, 21 Aug 2017 00:45:07 -0700 (PDT) Received: from rrzmta2.uni-regensburg.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id C2F8F7947C for ; Mon, 21 Aug 2017 09:45:05 +0200 (CEST) Received: from gwsmtp1.uni-regensburg.de (gwsmtp1.uni-regensburg.de [132.199.5.51]) by rrzmta2.uni-regensburg.de (Postfix) with ESMTP id 9F2CA793FA for ; Mon, 21 Aug 2017 09:45:05 +0200 (CEST) Received: from uni-regensburg-smtp1-MTA by gwsmtp1.uni-regensburg.de with Novell_GroupWise; Mon, 21 Aug 2017 09:45:04 +0200 Message-Id: <599A8F7E020000A10002787B@gwsmtp1.uni-regensburg.de> X-Mailer: Novell GroupWise Internet Agent 14.2.2 Date: Mon, 21 Aug 2017 09:45:02 +0200 From: "Ulrich Windl" To: "ntp@ietf.org" , References: In-Reply-To: Mime-Version: 1.0 Content-Disposition: inline Archived-At: Subject: [Ntp] Antw: NTS/Updated Autokey X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ntp-bounces@ietf.org Sender: "ntp" >>> Harlan Stenn schrieb am 21.08.2017 um 04:41 in Nachricht : > Dave has been working on an evaluation of the NTS proposal. > > We've been discussing this document in our internal NTS implementation > meetings, and Dieter asked me to send this to the WG mailing list. > > Dave updated the document after my last go-round, so I just took his new > version and integrated his changes with the ones we made. > Hi, some random comments: "Ordinarily, the function octet for both the request and response messages is the same; a bit is allocated in the function octet to serve as a response indicator." This is kind of a contradiction IMHO: If one bit changes, the function octet cannot be the same. I think the "minimum packet headway" is a new phrase. Why not using "minimum poll delay" (or interval) instead? "An NTP secure network consists of an acyclic, undirected graph organized as a tree with nodes descending from the root node." Is there really one root? What about multiple stratum-1 servers being configured? Maybe clarify this. "Each step involves a sign exchange, (...)" I would name it "signature exchange" for consistency. "In particular, the packet header and extension field lengths, if present." This is an incomplete sentence; is "are verified" missing at the end? "The format scan results in a pointer just before the message authentication code (MAC)." Isn't this an unnecessary implementation detail (to describe the semantics)? Maybe describe what the layer is expected to do in better words. "However, i,t is vital (...)" Simple typo ("it is vital")... "If a shared hash key is not available, such as during the agreement process itself, the existence of an implicit hash key zero is assumed. The value of hash key zero could be a random number known only to verified and trusted hosts in the NTP network. Hash key zero could be any mutually agreed upon symmetric key. The design intent is to verify this number as well as detect errors, rather than protect against middleman attack. By protocol rule, if a message request uses hash key zero, the message response also uses hash key zero." Isn't that a change to the current implementation where no key or key ID zero means "no MAC"? "The OpenSSL library includes just about every hash algorithm likely to be imagined. While historically ambiguous, the International Trade in Arms Regulations (ITAR) prohibits export of the OpenSSL library, so only the MD5 hash algorithm is included in the reference distribution. Alternatively, the OpenSSL library can be imported from foreign or domestic sources, although generated binaries may not be exported from the US.." Isn't there an exception for open source products? "(...)and the modifier octet used as the key number." Shouldn't "as the key number" be "is the key number"? Note on "The comparison of these two timestamps is called the loopback test. The transmit timestamp functions as a nonce to verify that the response corresponds to the original request.": In the current implementation this test fails if one client is configured multiple times, it seems. I'm unhappy with the phrase "sign exchange" (as said earlier): Either "signature exchange" or "sign(ature) request" would better. Maybe it's a CSR (Certificate Signing Request)... "In the following, the host certificate belongs to the host containing the public/private keys, while a server certificate belongs to each association separately." Does this say that each host has a public/private key pair in addition to is self-signed certificate, while there is only a certificate for each association? If so I find the latter statement more clear. "In the authentication phase, Alice sends her signature of the shared hash key to Bob. Bob verifies the signature, then sends his signature of the shared hash key to Alice. Alice verifies his signature." I'm not a crypto expert, but isn't the hash key also encrypted (in addition to being signed) for the other party? Regards, Ulrich _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp From nobody Mon Aug 21 01:39:06 2017 Return-Path: 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 27FDC13294F for ; Mon, 21 Aug 2017 01:39:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 vQje_pOYAXHf for ; Mon, 21 Aug 2017 01:39:02 -0700 (PDT) Received: from mx1.bs.ptb.de (mx1.bs.ptb.de [IPv6:2001:638:610:bd01::120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BD8A132944 for ; Mon, 21 Aug 2017 01:39:02 -0700 (PDT) Received: from smtp-hub.bs.ptb.de (smtpint01.bs.ptb.de [141.25.87.32]) by mx1.bs.ptb.de with ESMTP id v7L8d0M4021653-v7L8d0M6021653 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 21 Aug 2017 10:39:00 +0200 Received: from lotus.bs.ptb.de (lotus.bs.ptb.de [141.25.85.200]) by smtp-hub.bs.ptb.de (Postfix) with ESMTPS id 7A7EC52F71A; Mon, 21 Aug 2017 10:39:00 +0200 (CEST) In-Reply-To: References: To: dieter.sibold@ptb.de Cc: Harlan Stenn , ntp@ietf.org MIME-Version: 1.0 Message-ID: From: kristof.teichel@ptb.de Date: Mon, 21 Aug 2017 10:38:59 +0200 Content-Type: multipart/alternative; boundary="=_alternative 002F8413C1258183_=" Archived-At: Subject: Re: [Ntp] Antwort: NTS/Updated Autokey X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Aug 2017 08:39:05 -0000 Dies ist eine mehrteilige Nachricht im MIME-Format. --=_alternative 002F8413C1258183_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable I also would like to emphasize that it needs to be clearer whether (and,=20 if yes, how) Dave's document is supposed to relate to the NTS draft and=20 its current WGLC procedure. Kristof Von: dieter.sibold@ptb.de An: Harlan Stenn Kopie: ntp@ietf.org Datum: 21.08.2017 09:27 Betreff: [Ntp] Antwort: NTS/Updated Autokey Gesendet von: "ntp" To clarify: I asked Dave to discuss his questions regarding the NTS draft=20 (https://www.ietf.org/id/draft-ietf-ntp-using-nts-for-ntp-09.txt) in the=20 NTP mailing list. I didn't asked to submit a further proposal.=20 Dieter > Von: Harlan Stenn =20 > An: ntp@ietf.org=20 > Datum: 21.08.2017 04:41=20 > Betreff: [Ntp] NTS/Updated Autokey=20 > Gesendet von: "ntp" =20 >=20 > Dave has been working on an evaluation of the NTS proposal. >=20 > We've been discussing this document in our internal NTS implementation > meetings, and Dieter asked me to send this to the WG mailing list. >=20 > Dave updated the document after my last go-round, so I just took his new > version and integrated his changes with the ones we made. >=20 > I'll be working on my WGLC comments separately. > --=20 > Harlan Stenn, Network Time Foundation > http://nwtime.org - be a Member! > [Anhang "Autokey-20170815.txt" gel=F6scht von Dieter Sibold/PTB]=20 > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > ntp mailing list > ntp@ietf.org > https://www.ietf.org/mailman/listinfo/ntp[Anhang "smime.p7s" gel=F6scht=20 von Kristof Teichel/PTB] =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp --=_alternative 002F8413C1258183_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable I also would like to emphasize that it needs to be clearer whether (and, if yes, how) Dave's document is supposed to relate to the NTS draft and its current WGLC procedure.

Kristof




Von:     &= nbsp;  dieter.sibold@ptb.de
An:     &n= bsp;  Harlan Stenn <stenn@nwti= me.org>
Kopie:    =    ntp@ietf.org
Datum:    =    21.08.2017 09:27
Betreff:   &nbs= p;    [Ntp] Antwort:  NTS/Updated Autokey
Gesendet von:  =      "ntp" <ntp-bounces@ietf.org>



To clarify: I asked Dave to discuss his questions regarding the NTS draft (https://www.ietf.org/id/draft-ietf-ntp-using-nts-for= -ntp-09.txt) in the NTP mailing list. I didn't asked to submit a further proposal.

Dieter




> Von: Harlan Stenn <stenn@nwtime.org>
> An: ntp@ietf.org =
> Datum: 21.08.2017 04:41
> Betreff: [Ntp] NTS/Updated Autokey <= tt>
> Gesendet von: "ntp" <ntp-bounces@ietf.org>=
>
> Dave has been working on an evaluation of the NTS proposal.
>
> We've been discussing this document in our internal NTS implementation=
> meetings, and Dieter asked me to send this to the WG mailing list.
>
> Dave updated the document after my last go-round, so I just took his new
> version and integrated his changes with the ones we made.
>
> I'll be working on my WGLC comments separately.
> --
> Harlan Stenn, Network Time Foundation
> http://nwtime.org - be a Member!
> [Anhang "Autokey-20170815.txt" gel=F6scht von Dieter Sibold/= PTB]
> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
> ntp mailing list
> ntp@ietf.org
> https://www.ietf.org/mailman/listinfo/ntp<= /font>[Anhang "smime.p7s" gel=F6scht von Kristof Teichel/PTB] <= tt>=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F
ntp mailing list
ntp@ietf.org
https://www.ietf.org/mailman/listinfo/ntp

--=_alternative 002F8413C1258183_=-- From ntp-bounces@ietf.org Mon Aug 21 01:39:07 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E019C13294F; Mon, 21 Aug 2017 01:39:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1503304746; bh=TtITbiksjRjtDyUunYWLJRi31i+JG9TQANC10SDWCRY=; h=In-Reply-To:References:To:From:Date:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc; b=GEhO83Z1PhehD7xIMiA0pytDgB5EDSnyT/PriXBGHsg3YnVNpvKrBPXjC/bDjEbsF b4WsVWzZdM8fNMD717RKDVzpf0QuAHioxNKVbkHfh0iqM8Ee6x1fDetOY5rDuO4rYP J/1TsiGdCr5riGnIzKDfQNEK8S/ay2gxIFhC/2qc= 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 27FDC13294F for ; Mon, 21 Aug 2017 01:39:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 vQje_pOYAXHf for ; Mon, 21 Aug 2017 01:39:02 -0700 (PDT) Received: from mx1.bs.ptb.de (mx1.bs.ptb.de [IPv6:2001:638:610:bd01::120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BD8A132944 for ; Mon, 21 Aug 2017 01:39:02 -0700 (PDT) Received: from smtp-hub.bs.ptb.de (smtpint01.bs.ptb.de [141.25.87.32]) by mx1.bs.ptb.de with ESMTP id v7L8d0M4021653-v7L8d0M6021653 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 21 Aug 2017 10:39:00 +0200 Received: from lotus.bs.ptb.de (lotus.bs.ptb.de [141.25.85.200]) by smtp-hub.bs.ptb.de (Postfix) with ESMTPS id 7A7EC52F71A; Mon, 21 Aug 2017 10:39:00 +0200 (CEST) In-Reply-To: References: To: dieter.sibold@ptb.de MIME-Version: 1.0 Message-ID: From: kristof.teichel@ptb.de Date: Mon, 21 Aug 2017 10:38:59 +0200 Archived-At: Subject: Re: [Ntp] Antwort: NTS/Updated Autokey X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: ntp@ietf.org, Harlan Stenn Content-Type: multipart/mixed; boundary="===============3634890649764306518==" Errors-To: ntp-bounces@ietf.org Sender: "ntp" Dies ist eine mehrteilige Nachricht im MIME-Format. --===============3634890649764306518== Content-Type: multipart/alternative; boundary="=_alternative 002F8413C1258183_=" Dies ist eine mehrteilige Nachricht im MIME-Format. --=_alternative 002F8413C1258183_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable I also would like to emphasize that it needs to be clearer whether (and,=20 if yes, how) Dave's document is supposed to relate to the NTS draft and=20 its current WGLC procedure. Kristof Von: dieter.sibold@ptb.de An: Harlan Stenn Kopie: ntp@ietf.org Datum: 21.08.2017 09:27 Betreff: [Ntp] Antwort: NTS/Updated Autokey Gesendet von: "ntp" To clarify: I asked Dave to discuss his questions regarding the NTS draft=20 (https://www.ietf.org/id/draft-ietf-ntp-using-nts-for-ntp-09.txt) in the=20 NTP mailing list. I didn't asked to submit a further proposal.=20 Dieter > Von: Harlan Stenn =20 > An: ntp@ietf.org=20 > Datum: 21.08.2017 04:41=20 > Betreff: [Ntp] NTS/Updated Autokey=20 > Gesendet von: "ntp" =20 >=20 > Dave has been working on an evaluation of the NTS proposal. >=20 > We've been discussing this document in our internal NTS implementation > meetings, and Dieter asked me to send this to the WG mailing list. >=20 > Dave updated the document after my last go-round, so I just took his new > version and integrated his changes with the ones we made. >=20 > I'll be working on my WGLC comments separately. > --=20 > Harlan Stenn, Network Time Foundation > http://nwtime.org - be a Member! > [Anhang "Autokey-20170815.txt" gel=F6scht von Dieter Sibold/PTB]=20 > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > ntp mailing list > ntp@ietf.org > https://www.ietf.org/mailman/listinfo/ntp[Anhang "smime.p7s" gel=F6scht=20 von Kristof Teichel/PTB] =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp --=_alternative 002F8413C1258183_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable I also would like to emphasize that it needs to be clearer whether (and, if yes, how) Dave's document is supposed to relate to the NTS draft and its current WGLC procedure.

Kristof




Von:     &= nbsp;  dieter.sibold@ptb.de
An:     &n= bsp;  Harlan Stenn <stenn@nwti= me.org>
Kopie:    =    ntp@ietf.org
Datum:    =    21.08.2017 09:27
Betreff:   &nbs= p;    [Ntp] Antwort:  NTS/Updated Autokey
Gesendet von:  =      "ntp" <ntp-bounces@ietf.org>



To clarify: I asked Dave to discuss his questions regarding the NTS draft (https://www.ietf.org/id/draft-ietf-ntp-using-nts-for= -ntp-09.txt) in the NTP mailing list. I didn't asked to submit a further proposal.

Dieter




> Von: Harlan Stenn <stenn@nwtime.org>
> An: ntp@ietf.org =
> Datum: 21.08.2017 04:41
> Betreff: [Ntp] NTS/Updated Autokey <= tt>
> Gesendet von: "ntp" <ntp-bounces@ietf.org>=
>
> Dave has been working on an evaluation of the NTS proposal.
>
> We've been discussing this document in our internal NTS implementation=
> meetings, and Dieter asked me to send this to the WG mailing list.
>
> Dave updated the document after my last go-round, so I just took his new
> version and integrated his changes with the ones we made.
>
> I'll be working on my WGLC comments separately.
> --
> Harlan Stenn, Network Time Foundation
> http://nwtime.org - be a Member!
> [Anhang "Autokey-20170815.txt" gel=F6scht von Dieter Sibold/= PTB]
> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
> ntp mailing list
> ntp@ietf.org
> https://www.ietf.org/mailman/listinfo/ntp<= /font>[Anhang "smime.p7s" gel=F6scht von Kristof Teichel/PTB] <= tt>=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F
ntp mailing list
ntp@ietf.org
https://www.ietf.org/mailman/listinfo/ntp

--=_alternative 002F8413C1258183_=-- --===============3634890649764306518== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp --===============3634890649764306518==-- From nobody Mon Aug 21 01:44:37 2017 Return-Path: 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 D62A5132953 for ; Mon, 21 Aug 2017 01:44:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 V-A8y5mv5yvY for ; Mon, 21 Aug 2017 01:44:33 -0700 (PDT) Received: from chessie.everett.org (chessie.everett.org [66.220.13.234]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8A97132076 for ; Mon, 21 Aug 2017 01:44:33 -0700 (PDT) Received: from [10.66.3.3] (96-41-166-181.dhcp.mdfd.or.charter.com [96.41.166.181]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by chessie.everett.org (Postfix) with ESMTPSA id 90EE2B873; Mon, 21 Aug 2017 08:44:33 +0000 (UTC) To: kristof.teichel@ptb.de, dieter.sibold@ptb.de Cc: ntp@ietf.org References: From: Harlan Stenn Message-ID: Date: Mon, 21 Aug 2017 01:44:34 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ntp] Antwort: NTS/Updated Autokey X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Aug 2017 08:44:36 -0000 Dave cannot easily participate on the mailing list discussions. You can discuss this with him on the call if you like. Either way, he raises a number of points in his document that he feels must be addressed in any proposal that would intend to replace the existing Autokey proposal. H On 8/21/2017 1:38 AM, kristof.teichel@ptb.de wrote: > I also would like to emphasize that it needs to be clearer whether (and, > if yes, how) Dave's document is supposed to relate to the NTS draft and > its current WGLC procedure. > > Kristof > > > > > Von:        dieter.sibold@ptb.de > An:        Harlan Stenn > Kopie:        ntp@ietf.org > Datum:        21.08.2017 09:27 > Betreff:        [Ntp] Antwort:  NTS/Updated Autokey > Gesendet von:        "ntp" > ------------------------------------------------------------------------ > > > > To clarify: I asked Dave to discuss his questions regarding the NTS > draft > (_https://www.ietf.org/id/draft-ietf-ntp-using-nts-for-ntp-09.txt_) in > the NTP mailing list. I didn't asked to submit a further proposal. > > Dieter > > > > >> Von: Harlan Stenn >> An: ntp@ietf.org >> Datum: 21.08.2017 04:41 >> Betreff: [Ntp] NTS/Updated Autokey >> Gesendet von: "ntp" >> >> Dave has been working on an evaluation of the NTS proposal. >> >> We've been discussing this document in our internal NTS implementation >> meetings, and Dieter asked me to send this to the WG mailing list. >> >> Dave updated the document after my last go-round, so I just took his new >> version and integrated his changes with the ones we made. >> >> I'll be working on my WGLC comments separately. >> -- >> Harlan Stenn, Network Time Foundation >> _http://nwtime.org_ - be a Member! >> [Anhang "Autokey-20170815.txt" gelöscht von Dieter Sibold/PTB] >> _______________________________________________ >> ntp mailing list >> ntp@ietf.org >> _https://www.ietf.org/mailman/listinfo/ntp__[Anhang "smime.p7s" > gelöscht von Kristof Teichel/PTB] > ________________________________________________ > ntp mailing list > ntp@ietf.org > https://www.ietf.org/mailman/listinfo/ntp > > -- Harlan Stenn, Network Time Foundation http://nwtime.org - be a Member! From ntp-bounces@ietf.org Mon Aug 21 01:44:37 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 93D8A132953; Mon, 21 Aug 2017 01:44:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1503305077; bh=Tq6ZwuOHIIq5FGsncnjVtkEbAQLAJ4kZQnjiaAPJuRk=; h=To:References:From:Date:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc; b=kbreQLABs9RrMjUADeqtNRXn5c4u6Duthpya06j600FScaG/Wda+UxqTeFOIMVY2O QScqifGHKZGHxG2Fp+aYqSD5MlSHfh7kcLxrALw6jru55dXD9BkSlCZYxRPbdtrH4z 6p2oN7KPUhLbGXKSGD2jFjc2T0FZOUFnkdbsFPpA= 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 D62A5132953 for ; Mon, 21 Aug 2017 01:44:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 V-A8y5mv5yvY for ; Mon, 21 Aug 2017 01:44:33 -0700 (PDT) Received: from chessie.everett.org (chessie.everett.org [66.220.13.234]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8A97132076 for ; Mon, 21 Aug 2017 01:44:33 -0700 (PDT) Received: from [10.66.3.3] (96-41-166-181.dhcp.mdfd.or.charter.com [96.41.166.181]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by chessie.everett.org (Postfix) with ESMTPSA id 90EE2B873; Mon, 21 Aug 2017 08:44:33 +0000 (UTC) To: kristof.teichel@ptb.de, dieter.sibold@ptb.de References: From: Harlan Stenn Message-ID: Date: Mon, 21 Aug 2017 01:44:34 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US Archived-At: Subject: Re: [Ntp] Antwort: NTS/Updated Autokey X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: ntp@ietf.org Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Errors-To: ntp-bounces@ietf.org Sender: "ntp" Dave cannot easily participate on the mailing list discussions. You can discuss this with him on the call if you like. Either way, he raises a number of points in his document that he feels must be addressed in any proposal that would intend to replace the existing Autokey proposal. H On 8/21/2017 1:38 AM, kristof.teichel@ptb.de wrote: > I also would like to emphasize that it needs to be clearer whether (and, > if yes, how) Dave's document is supposed to relate to the NTS draft and > its current WGLC procedure. > = > Kristof > = > = > = > = > Von: =A0 =A0 =A0 =A0dieter.sibold@ptb.de > An: =A0 =A0 =A0 =A0Harlan Stenn > Kopie: =A0 =A0 =A0 =A0ntp@ietf.org > Datum: =A0 =A0 =A0 =A021.08.2017 09:27 > Betreff: =A0 =A0 =A0 =A0[Ntp] Antwort: =A0NTS/Updated Autokey > Gesendet von: =A0 =A0 =A0 =A0"ntp" > ------------------------------------------------------------------------ > = > = > = > To clarify: I asked Dave to discuss his questions regarding the NTS > draft > (_https://www.ietf.org/id/draft-ietf-ntp-using-nts-for-ntp-09.txt_) in > the NTP mailing list. I didn't asked to submit a further proposal. > = > Dieter > = > = > = > = >> Von: Harlan Stenn >> An: ntp@ietf.org >> Datum: 21.08.2017 04:41 >> Betreff: [Ntp] NTS/Updated Autokey >> Gesendet von: "ntp" >> >> Dave has been working on an evaluation of the NTS proposal. >> >> We've been discussing this document in our internal NTS implementation >> meetings, and Dieter asked me to send this to the WG mailing list. >> >> Dave updated the document after my last go-round, so I just took his new >> version and integrated his changes with the ones we made. >> >> I'll be working on my WGLC comments separately. >> -- >> Harlan Stenn, Network Time Foundation >> _http://nwtime.org_ - be a Member! >> [Anhang "Autokey-20170815.txt" gel=F6scht von Dieter Sibold/PTB] >> _______________________________________________ >> ntp mailing list >> ntp@ietf.org >> _https://www.ietf.org/mailman/listinfo/ntp__[Anhang "smime.p7s" > gel=F6scht von Kristof Teichel/PTB] > ________________________________________________ > ntp mailing list > ntp@ietf.org > https://www.ietf.org/mailman/listinfo/ntp > = > = -- = Harlan Stenn, Network Time Foundation http://nwtime.org - be a Member! _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp From nobody Mon Aug 21 02:06:39 2017 Return-Path: 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 E6E1C132977 for ; Mon, 21 Aug 2017 02:06:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 y5KTEKVXaNJi for ; Mon, 21 Aug 2017 02:06:36 -0700 (PDT) Received: from chessie.everett.org (chessie.everett.org [66.220.13.234]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFA2C132969 for ; Mon, 21 Aug 2017 02:06:35 -0700 (PDT) Received: from [10.66.3.3] (96-41-166-181.dhcp.mdfd.or.charter.com [96.41.166.181]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by chessie.everett.org (Postfix) with ESMTPSA id AF24FB873; Mon, 21 Aug 2017 09:06:35 +0000 (UTC) To: Ulrich Windl , "ntp@ietf.org" References: <599A8F7E020000A10002787B@gwsmtp1.uni-regensburg.de> From: Harlan Stenn Message-ID: Date: Mon, 21 Aug 2017 02:06:37 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <599A8F7E020000A10002787B@gwsmtp1.uni-regensburg.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ntp] Antw: NTS/Updated Autokey X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Aug 2017 09:06:38 -0000 On 8/21/2017 12:45 AM, Ulrich Windl wrote: >>>> Harlan Stenn schrieb am 21.08.2017 um 04:41 in Nachricht > : >> Dave has been working on an evaluation of the NTS proposal. >> >> We've been discussing this document in our internal NTS implementation >> meetings, and Dieter asked me to send this to the WG mailing list. >> >> Dave updated the document after my last go-round, so I just took his new >> version and integrated his changes with the ones we made. >> > > Hi, > > some random comments: > > "Ordinarily, the function octet for both the request and response messages is the same; a bit is allocated in the function octet to serve as a response indicator." This is kind of a contradiction IMHO: If one bit changes, the function octet cannot be the same. Really? That's how autokey did it, and the I-DO proposal does this as well. NTS would also use this. > I think the "minimum packet headway" is a new phrase. Why not using "minimum poll delay" (or interval) instead? I'll ask Dave about this. > "An NTP secure network consists of an acyclic, undirected graph organized as a tree with nodes descending from the root node." Is there really one root? What about multiple stratum-1 servers being configured? Maybe clarify this. There is one root. If you are using multiple stratum 1 servers, you're still using at most 1 of them as a system peer. > "Each step involves a sign exchange, (...)" I would name it "signature exchange" for consistency. I'll tell Dave you agree with me :) > "In particular, the packet header and extension field lengths, if present." This is an incomplete sentence; is "are verified" missing at the end? I think so. > "The format scan results in a pointer just before the message authentication code (MAC)." Isn't this an unnecessary implementation detail (to describe the semantics)? Maybe describe what the layer is expected to do in better words. It's likely also specific to the Legacy MAC. I'll ask. > "However, i,t is vital (...)" Simple typo ("it is vital")... > > "If a shared hash key is not available, such as during the agreement process itself, the existence of an implicit hash key zero is assumed. The value of hash key zero could be a random number known only to verified and trusted hosts in the NTP network. Hash key zero could be any mutually agreed upon symmetric key. The design intent is to verify this number as well as detect errors, rather than protect against middleman attack. By protocol rule, if a message request uses hash key zero, the message response also uses hash key zero." Isn't that a change to the current implementation where no key or key ID zero means "no MAC"? I don't think so. It's descriptive, and need not imply a literal key#0. It *could* be used, as a crypto-NAK is keyID 0 *and* a zero length field. The point is that each side must agree on the key being used to validate the initial exchange. There's room for discussion here. > "The OpenSSL library includes just about every hash algorithm likely to be imagined. While historically ambiguous, the International Trade in Arms Regulations (ITAR) prohibits export of the OpenSSL library, so only the MD5 hash algorithm is included in the reference distribution. Alternatively, the OpenSSL library can be imported from foreign or domestic sources, although generated binaries may not be exported from the US.." Isn't there an exception for open source products? Maybe. But Dave is not a lawyer, and when Autokey was first deployed and when OpenSSL was first used for symmetric key stuff, we could not export that code from the US. Things may have changed since then. > "(...)and the modifier octet used as the key number." Shouldn't "as the key number" be "is the key number"? I'll look or ask Dave, after I wake up. > Note on "The comparison of these two timestamps is called the loopback test. The transmit timestamp functions as a nonce to verify that the response corresponds to the original request.": In the current implementation this test fails if one client is configured multiple times, it seems. I'll check. > I'm unhappy with the phrase "sign exchange" (as said earlier): Either "signature exchange" or "sign(ature) request" would better. Maybe it's a CSR (Certificate Signing Request)... > > "In the following, the host certificate belongs to the host containing the public/private keys, while a server certificate belongs to each association separately." Does this say that each host has a public/private key pair in addition to is self-signed certificate, while there is only a certificate for each association? If so I find the latter statement more clear. > > "In the authentication phase, Alice sends her signature of the shared hash key to Bob. Bob verifies the signature, then sends his signature of the shared hash key to Alice. Alice verifies his signature." I'm not a crypto expert, but isn't the hash key also encrypted (in addition to being signed) for the other party? I'll ask Dave. Thanks! > Regards, > Ulrich > > -- Harlan Stenn, Network Time Foundation http://nwtime.org - be a Member! From ntp-bounces@ietf.org Mon Aug 21 02:06:40 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DE5D4132969; Mon, 21 Aug 2017 02:06:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1503306400; bh=9N3o7l6+FcuBLhjYrdAWABBeOgImJwJwWQhRYN+/Kx0=; h=To:References:From:Date:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe; b=tIM1kRAPw3pOEaU0il3Uw7tgdiPcRoHjBDeqxzG4Em85/dlZkGjwXlAy2aie8/kby vYKQLzDisJNINdUvUXC9I0ziEK6aXk/WtgS9PZ1UDcnFfrXZPsZGK06+yGi0ZpN2Ed 3KrSV9ff/VPq5xN4kPT58uiyAVz/G6YMQv6oeE7M= 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 E6E1C132977 for ; Mon, 21 Aug 2017 02:06:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 y5KTEKVXaNJi for ; Mon, 21 Aug 2017 02:06:36 -0700 (PDT) Received: from chessie.everett.org (chessie.everett.org [66.220.13.234]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFA2C132969 for ; Mon, 21 Aug 2017 02:06:35 -0700 (PDT) Received: from [10.66.3.3] (96-41-166-181.dhcp.mdfd.or.charter.com [96.41.166.181]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by chessie.everett.org (Postfix) with ESMTPSA id AF24FB873; Mon, 21 Aug 2017 09:06:35 +0000 (UTC) To: Ulrich Windl , "ntp@ietf.org" References: <599A8F7E020000A10002787B@gwsmtp1.uni-regensburg.de> From: Harlan Stenn Message-ID: Date: Mon, 21 Aug 2017 02:06:37 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <599A8F7E020000A10002787B@gwsmtp1.uni-regensburg.de> Content-Language: en-US Archived-At: Subject: Re: [Ntp] Antw: NTS/Updated Autokey X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ntp-bounces@ietf.org Sender: "ntp" On 8/21/2017 12:45 AM, Ulrich Windl wrote: >>>> Harlan Stenn schrieb am 21.08.2017 um 04:41 in Nachricht > : >> Dave has been working on an evaluation of the NTS proposal. >> >> We've been discussing this document in our internal NTS implementation >> meetings, and Dieter asked me to send this to the WG mailing list. >> >> Dave updated the document after my last go-round, so I just took his new >> version and integrated his changes with the ones we made. >> > > Hi, > > some random comments: > > "Ordinarily, the function octet for both the request and response messages is the same; a bit is allocated in the function octet to serve as a response indicator." This is kind of a contradiction IMHO: If one bit changes, the function octet cannot be the same. Really? That's how autokey did it, and the I-DO proposal does this as well. NTS would also use this. > I think the "minimum packet headway" is a new phrase. Why not using "minimum poll delay" (or interval) instead? I'll ask Dave about this. > "An NTP secure network consists of an acyclic, undirected graph organized as a tree with nodes descending from the root node." Is there really one root? What about multiple stratum-1 servers being configured? Maybe clarify this. There is one root. If you are using multiple stratum 1 servers, you're still using at most 1 of them as a system peer. > "Each step involves a sign exchange, (...)" I would name it "signature exchange" for consistency. I'll tell Dave you agree with me :) > "In particular, the packet header and extension field lengths, if present." This is an incomplete sentence; is "are verified" missing at the end? I think so. > "The format scan results in a pointer just before the message authentication code (MAC)." Isn't this an unnecessary implementation detail (to describe the semantics)? Maybe describe what the layer is expected to do in better words. It's likely also specific to the Legacy MAC. I'll ask. > "However, i,t is vital (...)" Simple typo ("it is vital")... > > "If a shared hash key is not available, such as during the agreement process itself, the existence of an implicit hash key zero is assumed. The value of hash key zero could be a random number known only to verified and trusted hosts in the NTP network. Hash key zero could be any mutually agreed upon symmetric key. The design intent is to verify this number as well as detect errors, rather than protect against middleman attack. By protocol rule, if a message request uses hash key zero, the message response also uses hash key zero." Isn't that a change to the current implementation where no key or key ID zero means "no MAC"? I don't think so. It's descriptive, and need not imply a literal key#0. It *could* be used, as a crypto-NAK is keyID 0 *and* a zero length field. The point is that each side must agree on the key being used to validate the initial exchange. There's room for discussion here. > "The OpenSSL library includes just about every hash algorithm likely to be imagined. While historically ambiguous, the International Trade in Arms Regulations (ITAR) prohibits export of the OpenSSL library, so only the MD5 hash algorithm is included in the reference distribution. Alternatively, the OpenSSL library can be imported from foreign or domestic sources, although generated binaries may not be exported from the US.." Isn't there an exception for open source products? Maybe. But Dave is not a lawyer, and when Autokey was first deployed and when OpenSSL was first used for symmetric key stuff, we could not export that code from the US. Things may have changed since then. > "(...)and the modifier octet used as the key number." Shouldn't "as the key number" be "is the key number"? I'll look or ask Dave, after I wake up. > Note on "The comparison of these two timestamps is called the loopback test. The transmit timestamp functions as a nonce to verify that the response corresponds to the original request.": In the current implementation this test fails if one client is configured multiple times, it seems. I'll check. > I'm unhappy with the phrase "sign exchange" (as said earlier): Either "signature exchange" or "sign(ature) request" would better. Maybe it's a CSR (Certificate Signing Request)... > > "In the following, the host certificate belongs to the host containing the public/private keys, while a server certificate belongs to each association separately." Does this say that each host has a public/private key pair in addition to is self-signed certificate, while there is only a certificate for each association? If so I find the latter statement more clear. > > "In the authentication phase, Alice sends her signature of the shared hash key to Bob. Bob verifies the signature, then sends his signature of the shared hash key to Alice. Alice verifies his signature." I'm not a crypto expert, but isn't the hash key also encrypted (in addition to being signed) for the other party? I'll ask Dave. Thanks! > Regards, > Ulrich > > -- Harlan Stenn, Network Time Foundation http://nwtime.org - be a Member! _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp From nobody Mon Aug 21 05:54:07 2017 Return-Path: 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 993A7132A13 for ; Mon, 21 Aug 2017 05:54:05 -0700 (PDT) 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, SPF_PASS=-0.001] 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 NUHwESvqo4s3 for ; Mon, 21 Aug 2017 05:54:03 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::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 CF0B0132A10 for ; Mon, 21 Aug 2017 05:54:03 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v7LCpusw032563; Mon, 21 Aug 2017 13:54:01 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=wzUCELat7g/5So52aL//Q8UhxOlH7cplmTJEM2yzWTw=; b=mRbwzMpYaK6O3CDVohiUBMilhKEFdFXxSljUftFGPth2lsr3nc5QhhM8LELU9Xe0CoBz 1yhArg0KsKibm1S7mXNF8hLmHsttEd8iSzvmg5ucdsciv5vekMZ8nzybV6ASZVg7Ign6 ybVlBjJ5hFeyg6HMRaN9PhiHtLR+QyCFs+sOfpvu0XhPjhN6Ku2/GgXHhO8tZZfIpXZ2 PH4GJR0lxFlepaDXOqxLYBagjb1Ju8DoO7yrnONlFVtPKNdbkLO1uAlSrFRz8TtWX4tR 9aH4dVSvtz0MA+6fpYu3DffDdJVgHP3ps1KsfTtvGb7nKdXbn0HHgaoxRppdNNG30Gdj Xw== Received: from prod-mail-ppoint4 ([96.6.114.87]) by m0050102.ppops.net-00190b01. with ESMTP id 2ceadc7nk9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 21 Aug 2017 13:54:01 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v7LCodKo024498; Mon, 21 Aug 2017 08:54:00 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint4.akamai.com with ESMTP id 2cegnvcg7q-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 21 Aug 2017 08:54:00 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 21 Aug 2017 08:53:58 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Mon, 21 Aug 2017 08:53:58 -0400 From: "Salz, Rich" To: Harlan Stenn , "ntp@ietf.org" Thread-Topic: [Ntp] NTS/Updated Autokey Thread-Index: AQHTGib4qmQ1rMewyUOfL1yxwYBbv6KOxM6A Date: Mon, 21 Aug 2017 12:53:57 +0000 Message-ID: <6AC635D8-E173-49F2-A9B6-90FBDFD7700F@akamai.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1b.0.161010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.40.157] Content-Type: text/plain; charset="utf-8" Content-ID: <5DB83266880E554B941A0E0DD07C0352@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-21_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1708210203 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-21_09:, , 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=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1708210203 Archived-At: Subject: Re: [Ntp] NTS/Updated Autokey X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Aug 2017 12:54:06 -0000 SXQgaXMgdW5mb3J0dW5hdGUgdGhhdCBEYXZlIGNhbm5vdCBlYXNpbHkgcGFydGljaXBhdGUgaW4g dGhlIG1haWxpbmcgbGlzdCBkaXNjdXNzaW9uLCBzaW5jZSB3ZSBhbGwga25vdyB0aGF0IGlzIHdo ZXJlIHRoZSBJRVRGIGRvZXMgaXRzIHdvcmsuDQoNCkkgZ2F2ZSBhIHF1aWNrIHJlYWQgdG8gaGlz IGRvY3VtZW50LiAgRmlyc3QsIGl0IHNlZW1zIHRvIGJlIGEgbWl4IG9mIHF1ZXN0aW9ucy9jb21t ZW50cyBhbmQgYW4gYWx0ZXJuYXRlIHByb3Bvc2FsLiAgUGxlYXNlIGFzayBoaW0gdG8gc2VwYXJh dGUgdGhvc2UgaW50byB0d28gbWVzc2FnZXMuICBJZiB5b3UgYXJlIGFjdGluZyBhcyBoaXMgaW50 ZXJsb2N1dG9yLCBwbGVhc2UgcG9zdCB0aGUgcXVlc3Rpb25zIHBhcnQgZGlyZWN0bHksIG5vdCBh cyBhbiBhdHRhY2htZW50LiAgU2Vjb25kLCBESCBpcyB3YXkgdG9vIGV4cGVuc2l2ZSwgRUNESCBw cm9iYWJseSB1c2luZyBYMjU1MTksIGlzIHRoZSBvbmx5IG1lY2hhbmlzbSB0byB1c2UuDQoNCiAN Cg0K From ntp-bounces@ietf.org Mon Aug 21 05:54:07 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FECB132A13; Mon, 21 Aug 2017 05:54:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1503320047; bh=2xmivRP2wPg6riuTWSTnZSAgbn/B5tQowQIwQQmBvYw=; h=From:To:Date:References:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe; b=gzEIFtNXDt0CJ/0RJm4nweCuRE9E54yLfZ1jSYy+ri/nX91fJ55J7EpBqQXXAzFC5 Icms6lX/Hx+088KjLlZNwE2p4aZZNG8hE111JdxTF7iE5sXAZYZtfGOg2osP71O+HQ bOunitiHI2AVehtkUqdyw+zNCAtzIo8ewXHLsA1c= 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 993A7132A13 for ; Mon, 21 Aug 2017 05:54:05 -0700 (PDT) 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, SPF_PASS=-0.001] 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 NUHwESvqo4s3 for ; Mon, 21 Aug 2017 05:54:03 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::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 CF0B0132A10 for ; Mon, 21 Aug 2017 05:54:03 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v7LCpusw032563; Mon, 21 Aug 2017 13:54:01 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=wzUCELat7g/5So52aL//Q8UhxOlH7cplmTJEM2yzWTw=; b=mRbwzMpYaK6O3CDVohiUBMilhKEFdFXxSljUftFGPth2lsr3nc5QhhM8LELU9Xe0CoBz 1yhArg0KsKibm1S7mXNF8hLmHsttEd8iSzvmg5ucdsciv5vekMZ8nzybV6ASZVg7Ign6 ybVlBjJ5hFeyg6HMRaN9PhiHtLR+QyCFs+sOfpvu0XhPjhN6Ku2/GgXHhO8tZZfIpXZ2 PH4GJR0lxFlepaDXOqxLYBagjb1Ju8DoO7yrnONlFVtPKNdbkLO1uAlSrFRz8TtWX4tR 9aH4dVSvtz0MA+6fpYu3DffDdJVgHP3ps1KsfTtvGb7nKdXbn0HHgaoxRppdNNG30Gdj Xw== Received: from prod-mail-ppoint4 ([96.6.114.87]) by m0050102.ppops.net-00190b01. with ESMTP id 2ceadc7nk9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 21 Aug 2017 13:54:01 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v7LCodKo024498; Mon, 21 Aug 2017 08:54:00 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint4.akamai.com with ESMTP id 2cegnvcg7q-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 21 Aug 2017 08:54:00 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 21 Aug 2017 08:53:58 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Mon, 21 Aug 2017 08:53:58 -0400 From: "Salz, Rich" To: Harlan Stenn , "ntp@ietf.org" Thread-Topic: [Ntp] NTS/Updated Autokey Thread-Index: AQHTGib4qmQ1rMewyUOfL1yxwYBbv6KOxM6A Date: Mon, 21 Aug 2017 12:53:57 +0000 Message-ID: <6AC635D8-E173-49F2-A9B6-90FBDFD7700F@akamai.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1b.0.161010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.40.157] Content-ID: <5DB83266880E554B941A0E0DD07C0352@akamai.com> MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-21_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1708210203 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-21_09:, , 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=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1708210203 Archived-At: Subject: Re: [Ntp] NTS/Updated Autokey X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ntp-bounces@ietf.org Sender: "ntp" It is unfortunate that Dave cannot easily participate in the mailing list discussion, since we all know that is where the IETF does its work. I gave a quick read to his document. First, it seems to be a mix of questions/comments and an alternate proposal. Please ask him to separate those into two messages. If you are acting as his interlocutor, please post the questions part directly, not as an attachment. Second, DH is way too expensive, ECDH probably using X25519, is the only mechanism to use. _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp From nobody Mon Aug 21 06:21:36 2017 Return-Path: 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 A9B5C132A2F for ; Mon, 21 Aug 2017 06:21:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no 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 IUddnERjDq58 for ; Mon, 21 Aug 2017 06:21:31 -0700 (PDT) Received: from rrzmta2.uni-regensburg.de (rrzmta2.uni-regensburg.de [194.94.155.52]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39DB8132A25 for ; Mon, 21 Aug 2017 06:21:31 -0700 (PDT) Received: from rrzmta2.uni-regensburg.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id B9CA177B64 for ; Mon, 21 Aug 2017 15:21:29 +0200 (CEST) Received: from gwsmtp1.uni-regensburg.de (gwsmtp1.uni-regensburg.de [132.199.5.51]) by rrzmta2.uni-regensburg.de (Postfix) with ESMTP id 801BF76269 for ; Mon, 21 Aug 2017 15:21:29 +0200 (CEST) Received: from uni-regensburg-smtp1-MTA by gwsmtp1.uni-regensburg.de with Novell_GroupWise; Mon, 21 Aug 2017 15:21:28 +0200 Message-Id: <599ADE56020000A1000278B4@gwsmtp1.uni-regensburg.de> X-Mailer: Novell GroupWise Internet Agent 14.2.2 Date: Mon, 21 Aug 2017 15:21:26 +0200 From: "Ulrich Windl" To: "Rich Salz" ,"ntp@ietf.org" , References: <6AC635D8-E173-49F2-A9B6-90FBDFD7700F@akamai.com> In-Reply-To: <6AC635D8-E173-49F2-A9B6-90FBDFD7700F@akamai.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Archived-At: Subject: [Ntp] Antw: Re: NTS/Updated Autokey X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Aug 2017 13:21:34 -0000 >>> "Salz, Rich" schrieb am 21.08.2017 um 14:53 in = Nachricht <6AC635D8-E173-49F2-A9B6-90FBDFD7700F@akamai.com>: > It is unfortunate that Dave cannot easily participate in the mailing = list=20 > discussion, since we all know that is where the IETF does its work. >=20 > I gave a quick read to his document. First, it seems to be a mix of=20 > questions/comments and an alternate proposal. Please ask him to = separate=20 > those into two messages. If you are acting as his interlocutor, please = post=20 > the questions part directly, not as an attachment. Second, DH is way = too=20 > expensive, ECDH probably using X25519, is the only mechanism to use. Hi! When discussing "way too expensive", can we talk in cycles of a modern = CPU, comapring the state now and the proposed changes. I'm aware that = desktop CPU's may be very high end, while some embedded CPU's have weaker = CPUs. (Did I mention our old serial console server (fan-less 400MHz ARM CPU, I = think) that needs several seconds to establish an SSH login?) ;-) 2017-08-21 15:17:09 Connecting to 192.x.x.40 port 22 2017-08-21 15:17:09 We claim version: SSH-2.0-PuTTY_Release_0.69 2017-08-21 15:17:10 Server version: SSH-2.0-OpenSSH_4.4 2017-08-21 15:17:10 We believe remote version has SSH-2 channel = request bug 2017-08-21 15:17:10 Using SSH protocol version 2 2017-08-21 15:17:10 Doing Diffie-Hellman group exchange 2017-08-21 15:17:10 Doing Diffie-Hellman key exchange with hash = SHA-256 2017-08-21 15:17:26 Server also has ssh-dss host key, but we don't = know it 2017-08-21 15:17:26 Host key fingerprint is: 2017-08-21 15:17:26 ssh-rsa 1024 32:24:1f:3f:d1:29:15:e7:51:6b:cd:5a:b8= :df:40:ce 2017-08-21 15:17:26 Initialised AES-256 SDCTR client->server encryption= 2017-08-21 15:17:26 Initialised HMAC-SHA1 client->server MAC algorithm 2017-08-21 15:17:26 Initialised AES-256 SDCTR server->client encryption= 2017-08-21 15:17:26 Initialised HMAC-SHA1 server->client MAC algorithm Regards, Ulrich >=20 > =20 >=20 > _______________________________________________ > ntp mailing list > ntp@ietf.org=20 > https://www.ietf.org/mailman/listinfo/ntp=20 From ntp-bounces@ietf.org Mon Aug 21 06:21:37 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C9E8132A2E; Mon, 21 Aug 2017 06:21:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1503321697; bh=etP/jOxZSbuRxVsaCkfLadQEhpuIBOQyFKL9Dhzr+qs=; h=Date:From:To:References:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe; b=s7ShWMud7mApWFvQ8K5AQ+goaLRWvfePLEidf+X5VePYqGaqIQ6ReR4kwjFoCplaT EnhJIP6AGrNIvF01YZPv1smsqZnBzZOfYYADeSGtSnH6qWFEvfsGdtS/zBhuGu/Y+/ 1hq+6kJc0IOaLWOGHAFlNiQXloi4V5IzGlcUKs2s= 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 A9B5C132A2F for ; Mon, 21 Aug 2017 06:21:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no 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 IUddnERjDq58 for ; Mon, 21 Aug 2017 06:21:31 -0700 (PDT) Received: from rrzmta2.uni-regensburg.de (rrzmta2.uni-regensburg.de [194.94.155.52]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39DB8132A25 for ; Mon, 21 Aug 2017 06:21:31 -0700 (PDT) Received: from rrzmta2.uni-regensburg.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id B9CA177B64 for ; Mon, 21 Aug 2017 15:21:29 +0200 (CEST) Received: from gwsmtp1.uni-regensburg.de (gwsmtp1.uni-regensburg.de [132.199.5.51]) by rrzmta2.uni-regensburg.de (Postfix) with ESMTP id 801BF76269 for ; Mon, 21 Aug 2017 15:21:29 +0200 (CEST) Received: from uni-regensburg-smtp1-MTA by gwsmtp1.uni-regensburg.de with Novell_GroupWise; Mon, 21 Aug 2017 15:21:28 +0200 Message-Id: <599ADE56020000A1000278B4@gwsmtp1.uni-regensburg.de> X-Mailer: Novell GroupWise Internet Agent 14.2.2 Date: Mon, 21 Aug 2017 15:21:26 +0200 From: "Ulrich Windl" To: "Rich Salz" ,"ntp@ietf.org" , References: <6AC635D8-E173-49F2-A9B6-90FBDFD7700F@akamai.com> In-Reply-To: <6AC635D8-E173-49F2-A9B6-90FBDFD7700F@akamai.com> Mime-Version: 1.0 Content-Disposition: inline Archived-At: Subject: [Ntp] Antw: Re: NTS/Updated Autokey X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ntp-bounces@ietf.org Sender: "ntp" >>> "Salz, Rich" schrieb am 21.08.2017 um 14:53 in Nachricht <6AC635D8-E173-49F2-A9B6-90FBDFD7700F@akamai.com>: > It is unfortunate that Dave cannot easily participate in the mailing list > discussion, since we all know that is where the IETF does its work. > > I gave a quick read to his document. First, it seems to be a mix of > questions/comments and an alternate proposal. Please ask him to separate > those into two messages. If you are acting as his interlocutor, please post > the questions part directly, not as an attachment. Second, DH is way too > expensive, ECDH probably using X25519, is the only mechanism to use. Hi! When discussing "way too expensive", can we talk in cycles of a modern CPU, comapring the state now and the proposed changes. I'm aware that desktop CPU's may be very high end, while some embedded CPU's have weaker CPUs. (Did I mention our old serial console server (fan-less 400MHz ARM CPU, I think) that needs several seconds to establish an SSH login?) ;-) 2017-08-21 15:17:09 Connecting to 192.x.x.40 port 22 2017-08-21 15:17:09 We claim version: SSH-2.0-PuTTY_Release_0.69 2017-08-21 15:17:10 Server version: SSH-2.0-OpenSSH_4.4 2017-08-21 15:17:10 We believe remote version has SSH-2 channel request bug 2017-08-21 15:17:10 Using SSH protocol version 2 2017-08-21 15:17:10 Doing Diffie-Hellman group exchange 2017-08-21 15:17:10 Doing Diffie-Hellman key exchange with hash SHA-256 2017-08-21 15:17:26 Server also has ssh-dss host key, but we don't know it 2017-08-21 15:17:26 Host key fingerprint is: 2017-08-21 15:17:26 ssh-rsa 1024 32:24:1f:3f:d1:29:15:e7:51:6b:cd:5a:b8:df:40:ce 2017-08-21 15:17:26 Initialised AES-256 SDCTR client->server encryption 2017-08-21 15:17:26 Initialised HMAC-SHA1 client->server MAC algorithm 2017-08-21 15:17:26 Initialised AES-256 SDCTR server->client encryption 2017-08-21 15:17:26 Initialised HMAC-SHA1 server->client MAC algorithm Regards, Ulrich > > > > _______________________________________________ > ntp mailing list > ntp@ietf.org > https://www.ietf.org/mailman/listinfo/ntp _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp From nobody Mon Aug 21 06:36:57 2017 Return-Path: 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 ED88C1321EB for ; Mon, 21 Aug 2017 06:36:54 -0700 (PDT) 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, SPF_PASS=-0.001] 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 SD90C_KTd8Mc for ; Mon, 21 Aug 2017 06:36:53 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::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 3771B132125 for ; Mon, 21 Aug 2017 06:36:53 -0700 (PDT) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v7LDW6gC009623; Mon, 21 Aug 2017 14:36:51 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=QvpajZ/jzu+mQ7FPDHERaDo/TWLlfH5f58nWgunM7KM=; b=lq+sURF9sNmfWTXu5bmfOO7uJagPtrVFdZJEj+d66vKusbIrkKcRUPhPtnkUJ3E+bmAw +JlRezG1DX8DxfaKr1MIxNbQRtTbn1ncFU3IquxkXhLYlvfK4a6biIDo98TqdRobTaoi Mbcny91O36DCKo0cvZ0RiW87GolmpHMIZ39o0MiM4cPuPrqUIwi5Ac8K4Xey9yT0ofdM HusgrM0M+Y/V7yuZVvWsdsEyh4lRYHh1NNAQmt4CTqERfr/iYpoeD9u5juo34HgOvMSZ ZMfHJt/1kLL+FKzOQNYiACIEf3448dyH4fze7evcEZQ2AaZNqGm3sAv4CgsfCGlre/vC 9A== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by m0050096.ppops.net-00190b01. with ESMTP id 2cedr5q9fj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 21 Aug 2017 14:36:50 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v7LDaTiJ009464; Mon, 21 Aug 2017 09:36:50 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.30]) by prod-mail-ppoint1.akamai.com with ESMTP id 2cegntxqqc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 21 Aug 2017 09:36:50 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 21 Aug 2017 09:36:49 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Mon, 21 Aug 2017 09:36:49 -0400 From: "Salz, Rich" To: Ulrich Windl , "ntp@ietf.org" , "stenn@nwtime.org" Thread-Topic: Antw: Re: [Ntp] NTS/Updated Autokey Thread-Index: AQHTGib4qmQ1rMewyUOfL1yxwYBbv6KOxM6AgABKugD//8E9AA== Date: Mon, 21 Aug 2017 13:36:48 +0000 Message-ID: <7CCBC927-AAB1-4EFA-958B-7917B6F4368A@akamai.com> References: <6AC635D8-E173-49F2-A9B6-90FBDFD7700F@akamai.com> <599ADE56020000A1000278B4@gwsmtp1.uni-regensburg.de> In-Reply-To: <599ADE56020000A1000278B4@gwsmtp1.uni-regensburg.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1b.0.161010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.40.157] Content-Type: text/plain; charset="utf-8" Content-ID: <3B3BB3AC3D732F4BB553499056F61217@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-21_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1708210216 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-21_09:, , 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=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1708210215 Archived-At: Subject: Re: [Ntp] Antw: Re: NTS/Updated Autokey X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Aug 2017 13:36:55 -0000 4p6iIFdoZW4gZGlzY3Vzc2luZyAid2F5IHRvbyBleHBlbnNpdmUiLCBjYW4gd2UgdGFsayBpbiBj eWNsZXMgb2YgYSBtb2Rlcm4gQ1BVLCBjb21hcHJpbmcgdGhlIHN0YXRlIG5vdyBhbmQgdGhlIHBy b3Bvc2VkIGNoYW5nZXMuIEknbSBhd2FyZSB0aGF0IGRlc2t0b3AgQ1BVJ3MgbWF5IGJlIHZlcnkg aGlnaCBlbmQsIHdoaWxlIHNvbWUgZW1iZWRkZWQgQ1BVJ3MgaGF2ZSB3ZWFrZXIgQ1BVcy4NCiAg ICANClNvcnJ5LiAgU3RhcnQgaGVyZTogaHR0cHM6Ly9jci55cC50by9lY2RoL2N1cnZlMjU1MTkt MjAwNjAyMDkucGRmDQoNCg0KDQo= From ntp-bounces@ietf.org Mon Aug 21 06:36:57 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EE0331321EB; Mon, 21 Aug 2017 06:36:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1503322617; bh=Ch9ReXxp8W7GhC+cO+1cHJJMkOHX23tn757ZWL8rO98=; h=From:To:Date:References:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe; b=VZJxq/CQQnxduqErC4+uKvOHXTLCupbH3X7NKWmoA2tdYM/95xANFYezm0tPos8ie unfmEmr4yNs4+8Ckee4JMx1/AkzfIaqshOGdHbuv9Z796kLngWMqKHkFW9pyUVFdQa 0CU39x6rT5rxuk63ySP6vnfATU5/sVblMaroo3FM= 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 ED88C1321EB for ; Mon, 21 Aug 2017 06:36:54 -0700 (PDT) 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, SPF_PASS=-0.001] 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 SD90C_KTd8Mc for ; Mon, 21 Aug 2017 06:36:53 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::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 3771B132125 for ; Mon, 21 Aug 2017 06:36:53 -0700 (PDT) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v7LDW6gC009623; Mon, 21 Aug 2017 14:36:51 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=QvpajZ/jzu+mQ7FPDHERaDo/TWLlfH5f58nWgunM7KM=; b=lq+sURF9sNmfWTXu5bmfOO7uJagPtrVFdZJEj+d66vKusbIrkKcRUPhPtnkUJ3E+bmAw +JlRezG1DX8DxfaKr1MIxNbQRtTbn1ncFU3IquxkXhLYlvfK4a6biIDo98TqdRobTaoi Mbcny91O36DCKo0cvZ0RiW87GolmpHMIZ39o0MiM4cPuPrqUIwi5Ac8K4Xey9yT0ofdM HusgrM0M+Y/V7yuZVvWsdsEyh4lRYHh1NNAQmt4CTqERfr/iYpoeD9u5juo34HgOvMSZ ZMfHJt/1kLL+FKzOQNYiACIEf3448dyH4fze7evcEZQ2AaZNqGm3sAv4CgsfCGlre/vC 9A== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by m0050096.ppops.net-00190b01. with ESMTP id 2cedr5q9fj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 21 Aug 2017 14:36:50 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v7LDaTiJ009464; Mon, 21 Aug 2017 09:36:50 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.30]) by prod-mail-ppoint1.akamai.com with ESMTP id 2cegntxqqc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 21 Aug 2017 09:36:50 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 21 Aug 2017 09:36:49 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Mon, 21 Aug 2017 09:36:49 -0400 From: "Salz, Rich" To: Ulrich Windl , "ntp@ietf.org" , "stenn@nwtime.org" Thread-Topic: Antw: Re: [Ntp] NTS/Updated Autokey Thread-Index: AQHTGib4qmQ1rMewyUOfL1yxwYBbv6KOxM6AgABKugD//8E9AA== Date: Mon, 21 Aug 2017 13:36:48 +0000 Message-ID: <7CCBC927-AAB1-4EFA-958B-7917B6F4368A@akamai.com> References: <6AC635D8-E173-49F2-A9B6-90FBDFD7700F@akamai.com> <599ADE56020000A1000278B4@gwsmtp1.uni-regensburg.de> In-Reply-To: <599ADE56020000A1000278B4@gwsmtp1.uni-regensburg.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1b.0.161010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.40.157] Content-ID: <3B3BB3AC3D732F4BB553499056F61217@akamai.com> MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-21_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1708210216 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-21_09:, , 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=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1708210215 Archived-At: Subject: Re: [Ntp] Antw: Re: NTS/Updated Autokey X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Errors-To: ntp-bounces@ietf.org Sender: "ntp" 4p6iIFdoZW4gZGlzY3Vzc2luZyAid2F5IHRvbyBleHBlbnNpdmUiLCBjYW4gd2UgdGFsayBpbiBj eWNsZXMgb2YgYSBtb2Rlcm4gQ1BVLCBjb21hcHJpbmcgdGhlIHN0YXRlIG5vdyBhbmQgdGhlIHBy b3Bvc2VkIGNoYW5nZXMuIEknbSBhd2FyZSB0aGF0IGRlc2t0b3AgQ1BVJ3MgbWF5IGJlIHZlcnkg aGlnaCBlbmQsIHdoaWxlIHNvbWUgZW1iZWRkZWQgQ1BVJ3MgaGF2ZSB3ZWFrZXIgQ1BVcy4NCiAg ICANClNvcnJ5LiAgU3RhcnQgaGVyZTogaHR0cHM6Ly9jci55cC50by9lY2RoL2N1cnZlMjU1MTkt MjAwNjAyMDkucGRmDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXwpudHAgbWFpbGluZyBsaXN0Cm50cEBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL250cAo= From nobody Mon Aug 21 08:18:39 2017 Return-Path: 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 A2FBD132A66 for ; Mon, 21 Aug 2017 08:18:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01] autolearn=ham autolearn_force=no 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 qTu5YW3VH812 for ; Mon, 21 Aug 2017 08:18:35 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (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 AE91A132A67 for ; Mon, 21 Aug 2017 08:18:35 -0700 (PDT) Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v7LFIYAE008428 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 21 Aug 2017 15:18:34 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id v7LFIVHc004033 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 21 Aug 2017 15:18:32 GMT Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id v7LFIUXQ018094; Mon, 21 Aug 2017 15:18:31 GMT Received: from [192.168.1.39] (/75.69.254.163) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 21 Aug 2017 08:18:30 -0700 To: Harlan Stenn , Ulrich Windl , "ntp@ietf.org" References: <599A8F7E020000A10002787B@gwsmtp1.uni-regensburg.de> From: Brian Utterback Message-ID: Date: Mon, 21 Aug 2017 11:18:32 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------45173DF8F3A045C9DC88CC7F" Content-Language: en-US X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Subject: Re: [Ntp] Antw: NTS/Updated Autokey X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Aug 2017 15:18:37 -0000 This is a multi-part message in MIME format. --------------45173DF8F3A045C9DC88CC7F Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 8/21/2017 5:06 AM, Harlan Stenn wrote: > On 8/21/2017 12:45 AM, Ulrich Windl wrote: >>>>> Harlan Stenn schrieb am 21.08.2017 um 04:41 in Nachricht >> : >>> Dave has been working on an evaluation of the NTS proposal. >>> >>> We've been discussing this document in our internal NTS implementation >>> meetings, and Dieter asked me to send this to the WG mailing list. >>> >>> Dave updated the document after my last go-round, so I just took his new >>> version and integrated his changes with the ones we made. >>> >> Hi, >> >> some random comments: >> >> "Ordinarily, the function octet for both the request and response messages is the same; a bit is allocated in the function octet to serve as a response indicator." This is kind of a contradiction IMHO: If one bit changes, the function octet cannot be the same. > Really? That's how autokey did it, and the I-DO proposal does this as > well. NTS would also use this. > I don't think Ulrich is saying it is bad or good, he is saying that this sentence is ambiguous. I noticed this as well. It could be "Ordinarily the function octet for both the request and response messages is the same, but in this protocol a bit is allocated in the function octet to serve as a response indicator, making them response and request function octet different." or it could be the self inconsistent sentence "This protocol uses the same function octet for response and requests, with a bit allocated in the function octet to serve as a response indicator." The problem is that logic would suggest the first, but the sentence structure suggests the second. -- Oracle Brian Utterback | Principal Software Engineer Phone: +1 6038973049 Oracle Systems Server & Cloud Engineering 1 Oracle Dr. | Nashua, NH 03062 ------------------------------------------------------------------------ All working systems eventually show their own agendas. ------------------------------------------------------------------------ Green Oracle Oracle is committed to developing practices and products that help protect the environment --------------45173DF8F3A045C9DC88CC7F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
On 8/21/2017 5:06 AM, Harlan Stenn wrote:
On 8/21/2017 12:45 AM, Ulrich Windl wrote:

Harlan Stenn <stenn@nwtime.org> schrieb am 21.08.2017 um 04:41 in Nachricht

<a359ab89-a9f7-27d4-abd8-7b808461bd72@nwtime.org>:

Dave has been working on an evaluation of the NTS proposal.

We've been discussing this document in our internal NTS implementation
meetings, and Dieter asked me to send this to the WG mailing list.

Dave updated the document after my last go-round, so I just took his new
version and integrated his changes with the ones we made.


Hi,

some random comments:

"Ordinarily, the function octet for both the request and response messages is the same; a bit is allocated in the function octet to serve as a response indicator." This is kind of a contradiction IMHO: If one bit changes, the function octet cannot be the same.

Really?  That's how autokey did it, and the I-DO proposal does this as
well.  NTS would also use this.

I don't think Ulrich is saying it is bad or good, he is saying that this sentence is ambiguous. I noticed this as well.

It could be "Ordinarily the function octet for both the request and response messages is the same, but in this protocol a bit is allocated in the function octet to serve as a response indicator, making them response and request function octet different."

or it could be the self inconsistent sentence "This protocol uses the same function octet for response and requests, with a bit allocated in the function octet to serve as a response indicator."

The problem is that logic would suggest the first, but the sentence structure suggests the second.

--
Oracle
Brian Utterback | Principal Software Engineer
Phone: +1 6038973049
Oracle Systems Server & Cloud Engineering
1 Oracle Dr. | Nashua, NH 03062
All working systems eventually show their own agendas.
Green Oracle Oracle is committed to developing practices and products that help protect the environment
--------------45173DF8F3A045C9DC88CC7F-- From ntp-bounces@ietf.org Mon Aug 21 08:18:39 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EA5B132A68; Mon, 21 Aug 2017 08:18:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1503328719; bh=ImdIBu5FkNbYYnQiMUYY0j32AqnECcHhjzrGD/gOOqg=; h=To:References:From:Date:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe; b=dh5RO6nr14YR1GyBgQDqJH13RSsAaWYZNqcH1Yu7964S+i7HLcZFRWMB4LgqW2yQL Yh+/2/hXR2nfEWfDDJZWehOYb7G/Sjo85BjmD+XnUfrbA5XtR4JpxcMX9PZEcGlpHt OmAOaGYQ4sBXEWAaOkDovQhYYW4GrojJVkOkaI24= 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 A2FBD132A66 for ; Mon, 21 Aug 2017 08:18:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01] autolearn=ham autolearn_force=no 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 qTu5YW3VH812 for ; Mon, 21 Aug 2017 08:18:35 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (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 AE91A132A67 for ; Mon, 21 Aug 2017 08:18:35 -0700 (PDT) Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v7LFIYAE008428 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 21 Aug 2017 15:18:34 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id v7LFIVHc004033 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 21 Aug 2017 15:18:32 GMT Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id v7LFIUXQ018094; Mon, 21 Aug 2017 15:18:31 GMT Received: from [192.168.1.39] (/75.69.254.163) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 21 Aug 2017 08:18:30 -0700 To: Harlan Stenn , Ulrich Windl , "ntp@ietf.org" References: <599A8F7E020000A10002787B@gwsmtp1.uni-regensburg.de> From: Brian Utterback Message-ID: Date: Mon, 21 Aug 2017 11:18:32 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Subject: Re: [Ntp] Antw: NTS/Updated Autokey X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============5378013838237033005==" Errors-To: ntp-bounces@ietf.org Sender: "ntp" This is a multi-part message in MIME format. --===============5378013838237033005== Content-Type: multipart/alternative; boundary="------------45173DF8F3A045C9DC88CC7F" Content-Language: en-US This is a multi-part message in MIME format. --------------45173DF8F3A045C9DC88CC7F Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 8/21/2017 5:06 AM, Harlan Stenn wrote: > On 8/21/2017 12:45 AM, Ulrich Windl wrote: >>>>> Harlan Stenn schrieb am 21.08.2017 um 04:41 in Nachricht >> : >>> Dave has been working on an evaluation of the NTS proposal. >>> >>> We've been discussing this document in our internal NTS implementation >>> meetings, and Dieter asked me to send this to the WG mailing list. >>> >>> Dave updated the document after my last go-round, so I just took his new >>> version and integrated his changes with the ones we made. >>> >> Hi, >> >> some random comments: >> >> "Ordinarily, the function octet for both the request and response messages is the same; a bit is allocated in the function octet to serve as a response indicator." This is kind of a contradiction IMHO: If one bit changes, the function octet cannot be the same. > Really? That's how autokey did it, and the I-DO proposal does this as > well. NTS would also use this. > I don't think Ulrich is saying it is bad or good, he is saying that this sentence is ambiguous. I noticed this as well. It could be "Ordinarily the function octet for both the request and response messages is the same, but in this protocol a bit is allocated in the function octet to serve as a response indicator, making them response and request function octet different." or it could be the self inconsistent sentence "This protocol uses the same function octet for response and requests, with a bit allocated in the function octet to serve as a response indicator." The problem is that logic would suggest the first, but the sentence structure suggests the second. -- Oracle Brian Utterback | Principal Software Engineer Phone: +1 6038973049 Oracle Systems Server & Cloud Engineering 1 Oracle Dr. | Nashua, NH 03062 ------------------------------------------------------------------------ All working systems eventually show their own agendas. ------------------------------------------------------------------------ Green Oracle Oracle is committed to developing practices and products that help protect the environment --------------45173DF8F3A045C9DC88CC7F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
On 8/21/2017 5:06 AM, Harlan Stenn wrote:
On 8/21/2017 12:45 AM, Ulrich Windl wrote:

Harlan Stenn <stenn@nwtime.org> schrieb am 21.08.2017 um 04:41 in Nachricht

<a359ab89-a9f7-27d4-abd8-7b808461bd72@nwtime.org>:

Dave has been working on an evaluation of the NTS proposal.

We've been discussing this document in our internal NTS implementation
meetings, and Dieter asked me to send this to the WG mailing list.

Dave updated the document after my last go-round, so I just took his new
version and integrated his changes with the ones we made.


Hi,

some random comments:

"Ordinarily, the function octet for both the request and response messages is the same; a bit is allocated in the function octet to serve as a response indicator." This is kind of a contradiction IMHO: If one bit changes, the function octet cannot be the same.

Really?  That's how autokey did it, and the I-DO proposal does this as
well.  NTS would also use this.

I don't think Ulrich is saying it is bad or good, he is saying that this sentence is ambiguous. I noticed this as well.

It could be "Ordinarily the function octet for both the request and response messages is the same, but in this protocol a bit is allocated in the function octet to serve as a response indicator, making them response and request function octet different."

or it could be the self inconsistent sentence "This protocol uses the same function octet for response and requests, with a bit allocated in the function octet to serve as a response indicator."

The problem is that logic would suggest the first, but the sentence structure suggests the second.

--
Oracle
Brian Utterback | Principal Software Engineer
Phone: +1 6038973049
Oracle Systems Server & Cloud Engineering
1 Oracle Dr. | Nashua, NH 03062
All working systems eventually show their own agendas.
Green Oracle Oracle is committed to developing practices and products that help protect the environment
--------------45173DF8F3A045C9DC88CC7F-- --===============5378013838237033005== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp --===============5378013838237033005==-- From nobody Mon Aug 21 17:14:04 2017 Return-Path: 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 D69FA132AE4 for ; Mon, 21 Aug 2017 17:14:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 GN32hjb2faPy for ; Mon, 21 Aug 2017 17:14:01 -0700 (PDT) Received: from chessie.everett.org (chessie.everett.org [66.220.13.234]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DA87132AE2 for ; Mon, 21 Aug 2017 17:14:01 -0700 (PDT) Received: from [10.66.3.3] (96-41-166-181.dhcp.mdfd.or.charter.com [96.41.166.181]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by chessie.everett.org (Postfix) with ESMTPSA id C89FEB872; Tue, 22 Aug 2017 00:14:00 +0000 (UTC) To: ntp@ietf.org References: <6AC635D8-E173-49F2-A9B6-90FBDFD7700F@akamai.com> From: Harlan Stenn Message-ID: Date: Mon, 21 Aug 2017 17:14:02 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <6AC635D8-E173-49F2-A9B6-90FBDFD7700F@akamai.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ntp] NTS/Updated Autokey X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Aug 2017 00:14:03 -0000 On 8/21/2017 5:53 AM, Salz, Rich wrote: > It is unfortunate that Dave cannot easily participate in the mailing > list discussion, since we all know that is where the IETF does its > work. Yes. It's unfortunate that Dave is effectively blind. It's unfortunate that accessibility tools aren't up for the job of handling intricate and meticulous work like this. He can be on calls. > I gave a quick read to his document. First, it seems to be a mix of > questions/comments and an alternate proposal. Please ask him to separate > those into two messages. If you are acting as his interlocutor, please > post the questions part directly, not as an attachment. Second, DH is > way too expensive, ECDH probably using X25519, is the only mechanism to use. Sorry, he can't easily do that, and I have way too many other things biting at my heels to do it. Dave says using ECDH is fine - he disagrees that DH is way too expensive. In his document, see the Symmetric mode discussion in section 8, which talks about all of this in more detail. -- Harlan Stenn, Network Time Foundation http://nwtime.org - be a Member! From ntp-bounces@ietf.org Mon Aug 21 17:14:05 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E27BE132AE0; Mon, 21 Aug 2017 17:14:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1503360845; bh=Ftw8oMaWUFJBH6GJmYXn9IyAwTSb4o8YY56N1xG19+w=; h=To:References:From:Date:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe; b=Urb5QP3EHFkqJu6iNzX3NHUzL0zaiKYs618A1AeD9IU2CR34LqR46yEeKrhDvdWJj Ea95AVP/dMwKhfV0qfPpUpXvM4rC+rEollpWbTGlSPjcMx5Vdv4/vaL7yJK0+4nSP9 Se4oKveKPFgiPgqz9hXNlmYVbEVluaIPINb7E+uA= 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 D69FA132AE4 for ; Mon, 21 Aug 2017 17:14:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 GN32hjb2faPy for ; Mon, 21 Aug 2017 17:14:01 -0700 (PDT) Received: from chessie.everett.org (chessie.everett.org [66.220.13.234]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DA87132AE2 for ; Mon, 21 Aug 2017 17:14:01 -0700 (PDT) Received: from [10.66.3.3] (96-41-166-181.dhcp.mdfd.or.charter.com [96.41.166.181]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by chessie.everett.org (Postfix) with ESMTPSA id C89FEB872; Tue, 22 Aug 2017 00:14:00 +0000 (UTC) To: ntp@ietf.org References: <6AC635D8-E173-49F2-A9B6-90FBDFD7700F@akamai.com> From: Harlan Stenn Message-ID: Date: Mon, 21 Aug 2017 17:14:02 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <6AC635D8-E173-49F2-A9B6-90FBDFD7700F@akamai.com> Content-Language: en-US Archived-At: Subject: Re: [Ntp] NTS/Updated Autokey X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ntp-bounces@ietf.org Sender: "ntp" On 8/21/2017 5:53 AM, Salz, Rich wrote: > It is unfortunate that Dave cannot easily participate in the mailing > list discussion, since we all know that is where the IETF does its > work. Yes. It's unfortunate that Dave is effectively blind. It's unfortunate that accessibility tools aren't up for the job of handling intricate and meticulous work like this. He can be on calls. > I gave a quick read to his document. First, it seems to be a mix of > questions/comments and an alternate proposal. Please ask him to separate > those into two messages. If you are acting as his interlocutor, please > post the questions part directly, not as an attachment. Second, DH is > way too expensive, ECDH probably using X25519, is the only mechanism to use. Sorry, he can't easily do that, and I have way too many other things biting at my heels to do it. Dave says using ECDH is fine - he disagrees that DH is way too expensive. In his document, see the Symmetric mode discussion in section 8, which talks about all of this in more detail. -- Harlan Stenn, Network Time Foundation http://nwtime.org - be a Member! _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp From nobody Mon Aug 21 19:34:45 2017 Return-Path: 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 5D5C81321B9 for ; Mon, 21 Aug 2017 19:34:44 -0700 (PDT) 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, SPF_PASS=-0.001] 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 Q9bv8GkduSmN for ; Mon, 21 Aug 2017 19:34:43 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::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 DAD9E131D19 for ; Mon, 21 Aug 2017 19:34:42 -0700 (PDT) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v7M2WW7S015267; Tue, 22 Aug 2017 03:34:40 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=gy+nq+xMfprHI2/JpT8DXPaJeB+nPfhhDc2qeYcLTI8=; b=O52vCAMZq+28wFo7utwaWrNV3KZ0f7ILlyv/Zqe2h++wVEV1KO7N0oroZM1f9lA/Zs88 IGgJTNjzRIG0b3KJJc7HQe9Ko0u/qoGr+mEXCJkjKAn+5wEdIb7GyGudbJsZ4UorMhYE axbDtC9EUiDJgFvHxuyRRIp1TtO7zQRa1fF+rsIVY01nEljYZPTzjHgG8oC6JqGz1bx0 yO6iLCYv3kdFBupeXHs6/n25nby1XUzdn6Dl1DlQaP9jbmDhShxxxeY+OyuWxaozWNE9 RPf0J/7Ti+hwxiI53Q4F9XndNsTBXqgqPX3m1wIDU6OoJcqJOHG+hlD7MN4oCS3yIqi/ yA== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by m0050096.ppops.net-00190b01. with ESMTP id 2cedr5sdfq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 22 Aug 2017 03:34:40 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v7M2VDf0028100; Mon, 21 Aug 2017 22:34:39 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint1.akamai.com with ESMTP id 2cegnu14ap-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 21 Aug 2017 22:34:39 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 21 Aug 2017 22:34:38 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Mon, 21 Aug 2017 22:34:39 -0400 From: "Salz, Rich" To: Harlan Stenn , "ntp@ietf.org" Thread-Topic: [Ntp] NTS/Updated Autokey Thread-Index: AQHTGib4qmQ1rMewyUOfL1yxwYBbv6KOxM6AgAEBDwD//+Q7AA== Date: Tue, 22 Aug 2017 02:34:38 +0000 Message-ID: References: <6AC635D8-E173-49F2-A9B6-90FBDFD7700F@akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1b.0.161010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.40.84] Content-Type: text/plain; charset="utf-8" Content-ID: <71A418FC7DB772449AD2CB547BD4174B@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-21_14:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1708220036 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-21_14:, , 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 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1708220036 Archived-At: Subject: Re: [Ntp] NTS/Updated Autokey X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Aug 2017 02:34:44 -0000 4p6iIEl0J3MgdW5mb3J0dW5hdGUgdGhhdCBEYXZlIGlzIGVmZmVjdGl2ZWx5IGJsaW5kLg0K4p6i ICAgICBJdCdzIHVuZm9ydHVuYXRlIHRoYXQgYWNjZXNzaWJpbGl0eSB0b29scyBhcmVuJ3QgdXAg Zm9yIHRoZSBqb2Igb2YNCuKeoiBoYW5kbGluZyBpbnRyaWNhdGUgYW5kIG1ldGljdWxvdXMgd29y ayBsaWtlIHRoaXMuDQogICAgDQpJIGFtIHNvcnJ5IHRvIGhlYXIgdGhhdC4NCg0K4p6iICAgICBT b3JyeSwgaGUgY2FuJ3QgZWFzaWx5IFtzcGxpdCB0aGUgZG9jdW1lbnRdLCBhbmQgSSBoYXZlIHdh eSB0b28gbWFueSBvdGhlciB0aGluZ3MNCuKeoiAgICAgYml0aW5nIGF0IG15IGhlZWxzIHRvIGRv IGl0Lg0KICAgIA0KUGVyaGFwcyBzb21lb25lIGVsc2Ugd2lsbCBiZSBhYmxlIHRvIGRvIHNvLiAg QW4gaW50ZXJtaXggb2YgcXVlc3Rpb25zIGFuZCBhbHRlcm5hdGl2ZSBwcm9wb3NhbCDigJMgaXMg aXQgaW50ZW5kZWQgdG8gYmVjb21lIGEgbmV3IGRyYWZ0PyDigJMgd2lsbCBtYWtlIGl0IGhhcmQg dG8gYWRkcmVzcyBhbnkgcXVlc3Rpb25zIGFuZCBjb25jZXJucyBoZSBtaWdodCBoYXZlLg0KDQri nqIgICAgIERhdmUgc2F5cyB1c2luZyBFQ0RIIGlzIGZpbmUgLSBoZSBkaXNhZ3JlZXMgdGhhdCBE SCBpcyB3YXkgdG9vIGV4cGVuc2l2ZS4NCiAgIA0KV2l0aCBhbGwgZHVlIHJlc3BlY3QsIGhlIGlz IHdyb25nLg0KIA0KIA0KDQo= From ntp-bounces@ietf.org Mon Aug 21 19:34:46 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2422F1321B9; Mon, 21 Aug 2017 19:34:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1503369286; bh=LBM4Unfl5BQC5S/vHuS6AylZ4QpkQfCKoikRl4jIuLk=; h=From:To:Date:References:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe; b=Bsi1CnN6y0GVPDJDrGEqz1ugjs9TXANVPnFBVkEecbcDmDbr2MRi7KUKQVuGwQsVa OWEHMvtGNGHVYVyqDX6mP0BIO/cp7EzW8QgNa7krlAjDsK7jVvOqvQQ3Xt0B59JSMn Mk/lrnjvxepN5YzfAUi5xbQq8U/YiNGHr6p4Yqv0= 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 5D5C81321B9 for ; Mon, 21 Aug 2017 19:34:44 -0700 (PDT) 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, SPF_PASS=-0.001] 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 Q9bv8GkduSmN for ; Mon, 21 Aug 2017 19:34:43 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::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 DAD9E131D19 for ; Mon, 21 Aug 2017 19:34:42 -0700 (PDT) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v7M2WW7S015267; Tue, 22 Aug 2017 03:34:40 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=gy+nq+xMfprHI2/JpT8DXPaJeB+nPfhhDc2qeYcLTI8=; b=O52vCAMZq+28wFo7utwaWrNV3KZ0f7ILlyv/Zqe2h++wVEV1KO7N0oroZM1f9lA/Zs88 IGgJTNjzRIG0b3KJJc7HQe9Ko0u/qoGr+mEXCJkjKAn+5wEdIb7GyGudbJsZ4UorMhYE axbDtC9EUiDJgFvHxuyRRIp1TtO7zQRa1fF+rsIVY01nEljYZPTzjHgG8oC6JqGz1bx0 yO6iLCYv3kdFBupeXHs6/n25nby1XUzdn6Dl1DlQaP9jbmDhShxxxeY+OyuWxaozWNE9 RPf0J/7Ti+hwxiI53Q4F9XndNsTBXqgqPX3m1wIDU6OoJcqJOHG+hlD7MN4oCS3yIqi/ yA== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by m0050096.ppops.net-00190b01. with ESMTP id 2cedr5sdfq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 22 Aug 2017 03:34:40 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v7M2VDf0028100; Mon, 21 Aug 2017 22:34:39 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint1.akamai.com with ESMTP id 2cegnu14ap-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 21 Aug 2017 22:34:39 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 21 Aug 2017 22:34:38 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Mon, 21 Aug 2017 22:34:39 -0400 From: "Salz, Rich" To: Harlan Stenn , "ntp@ietf.org" Thread-Topic: [Ntp] NTS/Updated Autokey Thread-Index: AQHTGib4qmQ1rMewyUOfL1yxwYBbv6KOxM6AgAEBDwD//+Q7AA== Date: Tue, 22 Aug 2017 02:34:38 +0000 Message-ID: References: <6AC635D8-E173-49F2-A9B6-90FBDFD7700F@akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1b.0.161010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.40.84] Content-ID: <71A418FC7DB772449AD2CB547BD4174B@akamai.com> MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-21_14:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1708220036 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-21_14:, , 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 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1708220036 Archived-At: Subject: Re: [Ntp] NTS/Updated Autokey X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Errors-To: ntp-bounces@ietf.org Sender: "ntp" 4p6iIEl0J3MgdW5mb3J0dW5hdGUgdGhhdCBEYXZlIGlzIGVmZmVjdGl2ZWx5IGJsaW5kLg0K4p6i ICAgICBJdCdzIHVuZm9ydHVuYXRlIHRoYXQgYWNjZXNzaWJpbGl0eSB0b29scyBhcmVuJ3QgdXAg Zm9yIHRoZSBqb2Igb2YNCuKeoiBoYW5kbGluZyBpbnRyaWNhdGUgYW5kIG1ldGljdWxvdXMgd29y ayBsaWtlIHRoaXMuDQogICAgDQpJIGFtIHNvcnJ5IHRvIGhlYXIgdGhhdC4NCg0K4p6iICAgICBT b3JyeSwgaGUgY2FuJ3QgZWFzaWx5IFtzcGxpdCB0aGUgZG9jdW1lbnRdLCBhbmQgSSBoYXZlIHdh eSB0b28gbWFueSBvdGhlciB0aGluZ3MNCuKeoiAgICAgYml0aW5nIGF0IG15IGhlZWxzIHRvIGRv IGl0Lg0KICAgIA0KUGVyaGFwcyBzb21lb25lIGVsc2Ugd2lsbCBiZSBhYmxlIHRvIGRvIHNvLiAg QW4gaW50ZXJtaXggb2YgcXVlc3Rpb25zIGFuZCBhbHRlcm5hdGl2ZSBwcm9wb3NhbCDigJMgaXMg aXQgaW50ZW5kZWQgdG8gYmVjb21lIGEgbmV3IGRyYWZ0PyDigJMgd2lsbCBtYWtlIGl0IGhhcmQg dG8gYWRkcmVzcyBhbnkgcXVlc3Rpb25zIGFuZCBjb25jZXJucyBoZSBtaWdodCBoYXZlLg0KDQri nqIgICAgIERhdmUgc2F5cyB1c2luZyBFQ0RIIGlzIGZpbmUgLSBoZSBkaXNhZ3JlZXMgdGhhdCBE SCBpcyB3YXkgdG9vIGV4cGVuc2l2ZS4NCiAgIA0KV2l0aCBhbGwgZHVlIHJlc3BlY3QsIGhlIGlz IHdyb25nLg0KIA0KIA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXwpudHAgbWFpbGluZyBsaXN0Cm50cEBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL250cAo= From nobody Mon Aug 21 20:33:08 2017 Return-Path: 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 32B73132B0F for ; Mon, 21 Aug 2017 20:33:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=azet.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 NInTjH1KT-fF for ; Mon, 21 Aug 2017 20:33:04 -0700 (PDT) Received: from mail-wr0-x22f.google.com (mail-wr0-x22f.google.com [IPv6:2a00:1450:400c:c0c::22f]) (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 D17D0132B0D for ; Mon, 21 Aug 2017 20:33:03 -0700 (PDT) Received: by mail-wr0-x22f.google.com with SMTP id z91so112120746wrc.4 for ; Mon, 21 Aug 2017 20:33:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=azet.org; s=gmail; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=CnLVcUHXI2Wr6zQW+ez3+vZW1CsRdOEp3zvMDj+CjG4=; b=BDhBtfDeg3XUAvmTJd2VCD64tVqY2YGCTUpTIGxZx6mALxM6SKrVreay5XGrT/fHDR aqyS1hbIxBYFZsUVELkqnHKhIPUg+GmmLQetpCW9QWl1ScNiP15J7eFCg6/+WEkgbtlp aVT5W1/OPzcKq/wSVv70AA/dX8gefEowwGmOs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=CnLVcUHXI2Wr6zQW+ez3+vZW1CsRdOEp3zvMDj+CjG4=; b=eTsidztvE2hL5Tp3FEhN9T1leEs/d9tY2Dfevh85xCPxhgvyIPUD547y8dvHC9s2d7 friKXGxwEZ8E+lTJ8M1eycTRpcNnFigXbTlHOKi419DoLzZ9Dx6vnFgh98uJkItLR18f mLgrC0AV//Ag+r9FxB2eW5i/6lkQ8vV+apvZOPPHMfNoL5SUYEadjQhYkwT6Nh6oeoNN MHfyfQ/fw/jKmicBKozixOCbLlNPBSzo43OgVpEuD886FmDm4cfyuAVQyd0+G7yeXnWn +8AQLvYNEvv31UbO6MchLNvLVbrzMtY+QI9P2TVtzBIQNkEkTJXfuAL0PCiwmo7QAAxz bCSQ== X-Gm-Message-State: AHYfb5hYHCj+KgQLgoCl++c7gtQ2MHSuic2pGFA+2OJE4Yozuej83oXw 8fMlMg1hWsVklOEh X-Received: by 10.223.170.202 with SMTP id i10mr9129007wrc.140.1503372782374; Mon, 21 Aug 2017 20:33:02 -0700 (PDT) Received: from typhoon.azet.org (80-108-49-181.cable.dynamic.surfer.at. [80.108.49.181]) by smtp.gmail.com with ESMTPSA id v46sm7076924wrb.7.2017.08.21.20.33.01 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 21 Aug 2017 20:33:01 -0700 (PDT) Date: Tue, 22 Aug 2017 05:32:59 +0200 From: Aaron Zauner To: "Salz, Rich" Cc: Harlan Stenn , "ntp@ietf.org" Message-ID: <20170822053227.7ce90801aa@f091978d2a2e47f> References: <6AC635D8-E173-49F2-A9B6-90FBDFD7700F@akamai.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="x7l3lbqsvnchrnk3" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Ntp] NTS/Updated Autokey X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Aug 2017 03:33:06 -0000 --x7l3lbqsvnchrnk3 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Short comment in support: * Salz, Rich [22/08/2017 04:34:46] wrote: > =E2=9E=A2 It's unfortunate that Dave is effectively blind. > =E2=9E=A2 It's unfortunate that accessibility tools aren't up for the= job of > =E2=9E=A2 handling intricate and meticulous work like this. > =20 > I am sorry to hear that. >=20 > =E2=9E=A2 Sorry, he can't easily [split the document], and I have way= too many other things > =E2=9E=A2 biting at my heels to do it. > =20 > Perhaps someone else will be able to do so. An intermix of questions and= alternative proposal =E2=80=93 is it intended to become a new draft? =E2= =80=93 will make it hard to address any questions and concerns he might hav= e. >=20 > =E2=9E=A2 Dave says using ECDH is fine - he disagrees that DH is way = too expensive. > =20 > With all due respect, he is wrong. +1. Aaron > =20 > =20 >=20 > _______________________________________________ > ntp mailing list > ntp@ietf.org > https://www.ietf.org/mailman/listinfo/ntp --x7l3lbqsvnchrnk3 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfLYZfjhaAtwV2OIj5Ntkkv25tdUFAlmbpeMACgkQ5Ntkkv25 tdU1FRAAhHT/K5nK5oTto4bMn67ZorKcKS9eR5Jbrlp/Uxvt95Lfh/7/1ZwXnDor xwZqZko3VXUc6N2/LAjUDMsylZhwacxTFKaORRf1CFOTDkmEbOb4OKse/kW3zfBl obasHfdqnUwr14fXkqHIyBH1AqKNYqocqw+grz+pOptRgFGk/m6HZY5Nr1bzelaQ adk9sdHVsbw6SVbsR3WbU17XI5Tg/3CDf7IpEWdP26nwb9nSbnsKMAujvqauAJd8 I7tc2Lkqp59KhQe6tCFJLOBLbygq8wK3rRIEMXStUd8bV+ddEJGwAtptQcrBVMe0 DCo6CyxJZ192fICFoSN3xJTYF+h59Iea2wN2TIOB/01D6a3+K3LjhPhwMvFL7m7J jk7R8BkEwDRYDT/aEO+0GJRRvHHrOhLfzBUVE2W5ApB0uxTYh2Nr3l9vLlHL+3kg csyRtEW99nhhseIIeyAhB5lfL2QPYcSeBr1WaiI8PI5wUdwBFNk+o+05Tr+VwzXD cND0N85irLxXXPn7zPWBOEQboqtG/JKhm9+Eke/URGFQW6Qc1JdxwEQyeWk5j1O0 B9hyYymK9sfQ2EobgoiSgfEWbdBAvV3qvx91ykx867YMK3qPDSL9+9VwQ9ODy+Kv UxrznX5xlUllhIYcQepxhidZqL3jdmCgYjeYllbJ1bgT77v/6vQ= =Lq6L -----END PGP SIGNATURE----- --x7l3lbqsvnchrnk3-- From ntp-bounces@ietf.org Mon Aug 21 20:33:08 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E95A132B0E; Mon, 21 Aug 2017 20:33:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1503372788; bh=9Hi77U7rV2s/hMibarg4ta0Y8j+bjMt03hvRlxLo2Ag=; h=Date:From:To:References:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc; b=Aa1OsKQJGF+xzc4Pham25SYjhCmlxzkYLoiOraQFnhehKqzBJfz/aPhNTzmV4+tDg iqA510+9VO0UKRFcvpQd1r1TqWQS3br1ARUnk7TDiooZyyGt/ZMVlQFqnTHOvW13cB btex0coO8gX/uEEeF2lD51d9A8wq/IgF98WGZ3hM= 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 32B73132B0F for ; Mon, 21 Aug 2017 20:33:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=azet.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 NInTjH1KT-fF for ; Mon, 21 Aug 2017 20:33:04 -0700 (PDT) Received: from mail-wr0-x22f.google.com (mail-wr0-x22f.google.com [IPv6:2a00:1450:400c:c0c::22f]) (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 D17D0132B0D for ; Mon, 21 Aug 2017 20:33:03 -0700 (PDT) Received: by mail-wr0-x22f.google.com with SMTP id z91so112120746wrc.4 for ; Mon, 21 Aug 2017 20:33:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=azet.org; s=gmail; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=CnLVcUHXI2Wr6zQW+ez3+vZW1CsRdOEp3zvMDj+CjG4=; b=BDhBtfDeg3XUAvmTJd2VCD64tVqY2YGCTUpTIGxZx6mALxM6SKrVreay5XGrT/fHDR aqyS1hbIxBYFZsUVELkqnHKhIPUg+GmmLQetpCW9QWl1ScNiP15J7eFCg6/+WEkgbtlp aVT5W1/OPzcKq/wSVv70AA/dX8gefEowwGmOs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=CnLVcUHXI2Wr6zQW+ez3+vZW1CsRdOEp3zvMDj+CjG4=; b=eTsidztvE2hL5Tp3FEhN9T1leEs/d9tY2Dfevh85xCPxhgvyIPUD547y8dvHC9s2d7 friKXGxwEZ8E+lTJ8M1eycTRpcNnFigXbTlHOKi419DoLzZ9Dx6vnFgh98uJkItLR18f mLgrC0AV//Ag+r9FxB2eW5i/6lkQ8vV+apvZOPPHMfNoL5SUYEadjQhYkwT6Nh6oeoNN MHfyfQ/fw/jKmicBKozixOCbLlNPBSzo43OgVpEuD886FmDm4cfyuAVQyd0+G7yeXnWn +8AQLvYNEvv31UbO6MchLNvLVbrzMtY+QI9P2TVtzBIQNkEkTJXfuAL0PCiwmo7QAAxz bCSQ== X-Gm-Message-State: AHYfb5hYHCj+KgQLgoCl++c7gtQ2MHSuic2pGFA+2OJE4Yozuej83oXw 8fMlMg1hWsVklOEh X-Received: by 10.223.170.202 with SMTP id i10mr9129007wrc.140.1503372782374; Mon, 21 Aug 2017 20:33:02 -0700 (PDT) Received: from typhoon.azet.org (80-108-49-181.cable.dynamic.surfer.at. [80.108.49.181]) by smtp.gmail.com with ESMTPSA id v46sm7076924wrb.7.2017.08.21.20.33.01 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 21 Aug 2017 20:33:01 -0700 (PDT) Date: Tue, 22 Aug 2017 05:32:59 +0200 From: Aaron Zauner To: "Salz, Rich" Message-ID: <20170822053227.7ce90801aa@f091978d2a2e47f> References: <6AC635D8-E173-49F2-A9B6-90FBDFD7700F@akamai.com> MIME-Version: 1.0 In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Ntp] NTS/Updated Autokey X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "ntp@ietf.org" , Harlan Stenn Content-Type: multipart/mixed; boundary="===============0565900866407911838==" Errors-To: ntp-bounces@ietf.org Sender: "ntp" --===============0565900866407911838== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="x7l3lbqsvnchrnk3" Content-Disposition: inline --x7l3lbqsvnchrnk3 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Short comment in support: * Salz, Rich [22/08/2017 04:34:46] wrote: > =E2=9E=A2 It's unfortunate that Dave is effectively blind. > =E2=9E=A2 It's unfortunate that accessibility tools aren't up for the= job of > =E2=9E=A2 handling intricate and meticulous work like this. > =20 > I am sorry to hear that. >=20 > =E2=9E=A2 Sorry, he can't easily [split the document], and I have way= too many other things > =E2=9E=A2 biting at my heels to do it. > =20 > Perhaps someone else will be able to do so. An intermix of questions and= alternative proposal =E2=80=93 is it intended to become a new draft? =E2= =80=93 will make it hard to address any questions and concerns he might hav= e. >=20 > =E2=9E=A2 Dave says using ECDH is fine - he disagrees that DH is way = too expensive. > =20 > With all due respect, he is wrong. +1. Aaron > =20 > =20 >=20 > _______________________________________________ > ntp mailing list > ntp@ietf.org > https://www.ietf.org/mailman/listinfo/ntp --x7l3lbqsvnchrnk3 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfLYZfjhaAtwV2OIj5Ntkkv25tdUFAlmbpeMACgkQ5Ntkkv25 tdU1FRAAhHT/K5nK5oTto4bMn67ZorKcKS9eR5Jbrlp/Uxvt95Lfh/7/1ZwXnDor xwZqZko3VXUc6N2/LAjUDMsylZhwacxTFKaORRf1CFOTDkmEbOb4OKse/kW3zfBl obasHfdqnUwr14fXkqHIyBH1AqKNYqocqw+grz+pOptRgFGk/m6HZY5Nr1bzelaQ adk9sdHVsbw6SVbsR3WbU17XI5Tg/3CDf7IpEWdP26nwb9nSbnsKMAujvqauAJd8 I7tc2Lkqp59KhQe6tCFJLOBLbygq8wK3rRIEMXStUd8bV+ddEJGwAtptQcrBVMe0 DCo6CyxJZ192fICFoSN3xJTYF+h59Iea2wN2TIOB/01D6a3+K3LjhPhwMvFL7m7J jk7R8BkEwDRYDT/aEO+0GJRRvHHrOhLfzBUVE2W5ApB0uxTYh2Nr3l9vLlHL+3kg csyRtEW99nhhseIIeyAhB5lfL2QPYcSeBr1WaiI8PI5wUdwBFNk+o+05Tr+VwzXD cND0N85irLxXXPn7zPWBOEQboqtG/JKhm9+Eke/URGFQW6Qc1JdxwEQyeWk5j1O0 B9hyYymK9sfQ2EobgoiSgfEWbdBAvV3qvx91ykx867YMK3qPDSL9+9VwQ9ODy+Kv UxrznX5xlUllhIYcQepxhidZqL3jdmCgYjeYllbJ1bgT77v/6vQ= =Lq6L -----END PGP SIGNATURE----- --x7l3lbqsvnchrnk3-- --===============0565900866407911838== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp --===============0565900866407911838==-- From nobody Mon Aug 21 21:16:06 2017 Return-Path: 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 EAED512426E for ; Mon, 21 Aug 2017 21:16:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 GHkVfgUQ13bo for ; Mon, 21 Aug 2017 21:16:03 -0700 (PDT) Received: from chessie.everett.org (chessie.everett.org [66.220.13.234]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 240301252BA for ; Mon, 21 Aug 2017 21:16:03 -0700 (PDT) Received: from [10.66.3.3] (96-41-166-181.dhcp.mdfd.or.charter.com [96.41.166.181]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by chessie.everett.org (Postfix) with ESMTPSA id 8106AB872; Tue, 22 Aug 2017 04:16:02 +0000 (UTC) To: Aaron Zauner , "Salz, Rich" Cc: "ntp@ietf.org" References: <6AC635D8-E173-49F2-A9B6-90FBDFD7700F@akamai.com> <20170822053227.7ce90801aa@f091978d2a2e47f> From: Harlan Stenn Message-ID: Date: Mon, 21 Aug 2017 21:16:04 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20170822053227.7ce90801aa@f091978d2a2e47f> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ntp] NTS/Updated Autokey X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Aug 2017 04:16:05 -0000 On 8/21/2017 8:32 PM, Aaron Zauner wrote: > Short comment in support: > > * Salz, Rich [22/08/2017 04:34:46] wrote: >> ➢ It's unfortunate that Dave is effectively blind. >> ➢ It's unfortunate that accessibility tools aren't up for the job of >> ➢ handling intricate and meticulous work like this. >> >> I am sorry to hear that. >> >> ➢ Sorry, he can't easily [split the document], and I have way too many other things >> ➢ biting at my heels to do it. >> >> Perhaps someone else will be able to do so. An intermix of questions and alternative proposal – is it intended to become a new draft? – will make it hard to address any questions and concerns he might have. >> >> ➢ Dave says using ECDH is fine - he disagrees that DH is way too expensive. >> >> With all due respect, he is wrong. > > +1. > > Aaron No worries. Dave already said that ECDH is fine, and his express intent is to implement a station-to-station protocol. The choice of *which* DH scheme is used isn't really the point. -- Harlan Stenn, Network Time Foundation http://nwtime.org - be a Member! From ntp-bounces@ietf.org Mon Aug 21 21:16:07 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 365471252BA; Mon, 21 Aug 2017 21:16:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1503375367; bh=O1eqEBz7cF124y/sCXqgR28L5H3QnxZ1Cg0pY+Ot2eo=; h=To:References:From:Date:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc; b=artReGYSuiUYmcQxJHjLiaUTO0PqwACd+qqKFK2E+ckXhmg9oeugnSFao/T7UxVHN L92vaILMp7Na5qgrGiKfbZwIoaEU3QdGTPUQbIy0EklOozW6oE9rEtze4N9g30/z1f 7Yx4AeYS7a5d66T2kwrDH3xVB8J06MJhGqA9CDK0= 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 EAED512426E for ; Mon, 21 Aug 2017 21:16:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 GHkVfgUQ13bo for ; Mon, 21 Aug 2017 21:16:03 -0700 (PDT) Received: from chessie.everett.org (chessie.everett.org [66.220.13.234]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 240301252BA for ; Mon, 21 Aug 2017 21:16:03 -0700 (PDT) Received: from [10.66.3.3] (96-41-166-181.dhcp.mdfd.or.charter.com [96.41.166.181]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by chessie.everett.org (Postfix) with ESMTPSA id 8106AB872; Tue, 22 Aug 2017 04:16:02 +0000 (UTC) To: Aaron Zauner , "Salz, Rich" References: <6AC635D8-E173-49F2-A9B6-90FBDFD7700F@akamai.com> <20170822053227.7ce90801aa@f091978d2a2e47f> From: Harlan Stenn Message-ID: Date: Mon, 21 Aug 2017 21:16:04 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20170822053227.7ce90801aa@f091978d2a2e47f> Content-Language: en-US Archived-At: Subject: Re: [Ntp] NTS/Updated Autokey X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "ntp@ietf.org" Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Errors-To: ntp-bounces@ietf.org Sender: "ntp" CgpPbiA4LzIxLzIwMTcgODozMiBQTSwgQWFyb24gWmF1bmVyIHdyb3RlOgo+IFNob3J0IGNvbW1l bnQgaW4gc3VwcG9ydDoKPiAKPiAqIFNhbHosIFJpY2ggPHJzYWx6QGFrYW1haS5jb20+IFsyMi8w OC8yMDE3IDA0OjM0OjQ2XSB3cm90ZToKPj4g4p6iIEl0J3MgdW5mb3J0dW5hdGUgdGhhdCBEYXZl IGlzIGVmZmVjdGl2ZWx5IGJsaW5kLgo+PiDinqIgICAgIEl0J3MgdW5mb3J0dW5hdGUgdGhhdCBh Y2Nlc3NpYmlsaXR5IHRvb2xzIGFyZW4ndCB1cCBmb3IgdGhlIGpvYiBvZgo+PiDinqIgaGFuZGxp bmcgaW50cmljYXRlIGFuZCBtZXRpY3Vsb3VzIHdvcmsgbGlrZSB0aGlzLgo+PiAgICAgCj4+IEkg YW0gc29ycnkgdG8gaGVhciB0aGF0Lgo+Pgo+PiDinqIgICAgIFNvcnJ5LCBoZSBjYW4ndCBlYXNp bHkgW3NwbGl0IHRoZSBkb2N1bWVudF0sIGFuZCBJIGhhdmUgd2F5IHRvbyBtYW55IG90aGVyIHRo aW5ncwo+PiDinqIgICAgIGJpdGluZyBhdCBteSBoZWVscyB0byBkbyBpdC4KPj4gICAgIAo+PiBQ ZXJoYXBzIHNvbWVvbmUgZWxzZSB3aWxsIGJlIGFibGUgdG8gZG8gc28uICBBbiBpbnRlcm1peCBv ZiBxdWVzdGlvbnMgYW5kIGFsdGVybmF0aXZlIHByb3Bvc2FsIOKAkyBpcyBpdCBpbnRlbmRlZCB0 byBiZWNvbWUgYSBuZXcgZHJhZnQ/IOKAkyB3aWxsIG1ha2UgaXQgaGFyZCB0byBhZGRyZXNzIGFu eSBxdWVzdGlvbnMgYW5kIGNvbmNlcm5zIGhlIG1pZ2h0IGhhdmUuCj4+Cj4+IOKeoiAgICAgRGF2 ZSBzYXlzIHVzaW5nIEVDREggaXMgZmluZSAtIGhlIGRpc2FncmVlcyB0aGF0IERIIGlzIHdheSB0 b28gZXhwZW5zaXZlLgo+PiAgICAKPj4gV2l0aCBhbGwgZHVlIHJlc3BlY3QsIGhlIGlzIHdyb25n Lgo+IAo+ICsxLgo+IAo+IEFhcm9uCgpObyB3b3JyaWVzLgoKRGF2ZSBhbHJlYWR5IHNhaWQgdGhh dCBFQ0RIIGlzIGZpbmUsIGFuZCBoaXMgZXhwcmVzcyBpbnRlbnQgaXMgdG8KaW1wbGVtZW50IGEg c3RhdGlvbi10by1zdGF0aW9uIHByb3RvY29sLiAgVGhlIGNob2ljZSBvZiAqd2hpY2gqIERICnNj aGVtZSBpcyB1c2VkIGlzbid0IHJlYWxseSB0aGUgcG9pbnQuCgotLSAKSGFybGFuIFN0ZW5uLCBO ZXR3b3JrIFRpbWUgRm91bmRhdGlvbgpodHRwOi8vbnd0aW1lLm9yZyAtIGJlIGEgTWVtYmVyIQoK X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbnRwIG1haWxp bmcgbGlzdApudHBAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9udHAK From nobody Tue Aug 22 00:56:43 2017 Return-Path: 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 D8126126B71; Tue, 22 Aug 2017 00:56:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 vg9-489yxhUE; Tue, 22 Aug 2017 00:56:38 -0700 (PDT) Received: from mx1.bs.ptb.de (mx1.bs.ptb.de [IPv6:2001:638:610:bd01::120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 983F81321B7; Tue, 22 Aug 2017 00:56:38 -0700 (PDT) Received: from smtp-hub.bs.ptb.de (smtpint01.bs.ptb.de [141.25.87.32]) by mx1.bs.ptb.de with ESMTP id v7M7uXvg019554-v7M7uXvi019554 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 22 Aug 2017 09:56:33 +0200 Received: from rose.bs.ptb.de (rose.bs.ptb.de [141.25.85.201]) by smtp-hub.bs.ptb.de (Postfix) with ESMTPS id 0977A530156; Tue, 22 Aug 2017 09:56:33 +0200 (CEST) In-Reply-To: <6AC635D8-E173-49F2-A9B6-90FBDFD7700F@akamai.com> References: <6AC635D8-E173-49F2-A9B6-90FBDFD7700F@akamai.com> To: "Salz, Rich" Cc: "ntp@ietf.org" , "ntp" , Harlan Stenn MIME-Version: 1.0 Message-ID: From: dieter.sibold@ptb.de Date: Tue, 22 Aug 2017 09:56:31 +0200 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha-256; boundary=-------z48124_boundary_sign Archived-At: Subject: [Ntp] Antwort: Re: NTS/Updated Autokey X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Aug 2017 07:56:42 -0000 This is an S/MIME signed message. ---------z48124_boundary_sign Content-Type: multipart/alternative; boundary="=_alternative 002BA090C1258184_=" Dies ist eine mehrteilige Nachricht im MIME-Format. --=_alternative 002BA090C1258184_= Content-Type: text/plain; charset="US-ASCII" I agree with Rich. It would be very helpful if especially concerns regarding the NTS draft are posted separately. Dieter "ntp" schrieb am 21.08.2017 14:53:57: > Von: "Salz, Rich" > An: Harlan Stenn , "ntp@ietf.org" > Datum: 21.08.2017 14:54 > Betreff: Re: [Ntp] NTS/Updated Autokey > Gesendet von: "ntp" > > It is unfortunate that Dave cannot easily participate in the mailing > list discussion, since we all know that is where the IETF does its work. > > I gave a quick read to his document. First, it seems to be a mix of > questions/comments and an alternate proposal. Please ask him to > separate those into two messages. If you are acting as his > interlocutor, please post the questions part directly, not as an > attachment. Second, DH is way too expensive, ECDH probably using > X25519, is the only mechanism to use. > > > > _______________________________________________ > ntp mailing list > ntp@ietf.org > https://www.ietf.org/mailman/listinfo/ntp --=_alternative 002BA090C1258184_= Content-Type: text/html; charset="US-ASCII" I agree with Rich. It would be very helpful if especially concerns regarding the NTS draft are posted separately.
Dieter


"ntp" <ntp-bounces@ietf.org> schrieb am 21.08.2017 14:53:57:

> Von: "Salz, Rich" <rsalz@akamai.com>
> An: Harlan Stenn <stenn@nwtime.org>, "ntp@ietf.org" <ntp@ietf.org>
> Datum: 21.08.2017 14:54
> Betreff: Re: [Ntp] NTS/Updated Autokey
> Gesendet von: "ntp" <ntp-bounces@ietf.org>
>
> It is unfortunate that Dave cannot easily participate in the mailing
> list discussion, since we all know that is where the IETF does its work.
>
> I gave a quick read to his document.  First, it seems to be a mix of
> questions/comments and an alternate proposal.  Please ask him to
> separate those into two messages.  If you are acting as his
> interlocutor, please post the questions part directly, not as an
> attachment.  Second, DH is way too expensive, ECDH probably using
> X25519, is the only mechanism to use.
>
>  
>
> _______________________________________________
> ntp mailing list
> ntp@ietf.org
> https://www.ietf.org/mailman/listinfo/ntp
 --=_alternative 002BA090C1258184_=-- ---------z48124_boundary_sign Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIIp0gIBATEPMA0GCWCGSAFlAwQCAQUAMAsGCSqGSIb3DQEHAaCCJsYw ggOfMIICh6ADAgECAgEmMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNE ZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYD VQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw05OTA3MDkxMjExMDBaFw0xOTA3MDky MzU5MDBaMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYD VQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJv b3QgQ0EgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKsLozXgiykUsRSFrzwQ5Dlv NV1Krt3qYY2VSfRvZKMaYGakqUAihNnUpeV4kw5oAa25TVw6ztO4qEJA38+juoJZapIbrBya2ggr JSf5aSNH8eDrLHqb9RMC0H40fMKePABZq/XaDPUyPCusUNrWw96DlMqoDJkyDghIVltq+9rhWFgB SV9yQTwVBgGOXa2quJO0zZ7rp+hqLVI02zrvXHVR2tvzMfnucZgyxFQVRAz5m1Xtrd8YCKCjhopJ 7lMFjxlM1d5YeZvSahxCq8XVp89oD5bk4WGYdmHIkXzWPgDikVCH4Z0K5q2X0h3GOn3LvNoDNNWO WwH1age3FrZuSn8CAwEAAaNCMEAwHQYDVR0OBBYEFDHDeRu69VPXF+CJei0XbAqzK50zMA8GA1Ud EwQIMAYBAf8CAQUwDgYDVR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBBQUAA4IBAQCUZFmtOWTnKesT /lrDixNXyAQk8HR3wGDjZ/vpiaaDv5aCfG7Uwz3vnoBuuym0mHqxO1TrORdHfhqOC/wfMVkxBLLO F/Msx2I2VeIi2IlVtJhIqmT61hw22ER4WlojOleX9XowT66fakxLK46gA+M+4KnU0nvSs6jicjyt nv+AWeSbRbT2O7DNORmYMuXqIWGQ5DEhjjSx9y81SoUQ2ueKNyG+WWPg8oWIMVPUVBSFcHn0LgZ3 J3UvH7iK+f7Futg25IPs52W3v2Na80avgZQ31EGM1iPWHs/1aBtEY6Jauqc1WaHlcAWbDiNXmZQK bbo5YyiGkvMYhNj70c8FVmRXMIIDnzCCAoegAwIBAgIBJjANBgkqhkiG9w0BAQUFADBxMQswCQYD VQQGEwJERTEcMBoGA1UEChMTRGV1dHNjaGUgVGVsZWtvbSBBRzEfMB0GA1UECxMWVC1UZWxlU2Vj IFRydXN0IENlbnRlcjEjMCEGA1UEAxMaRGV1dHNjaGUgVGVsZWtvbSBSb290IENBIDIwHhcNOTkw NzA5MTIxMTAwWhcNMTkwNzA5MjM1OTAwWjBxMQswCQYDVQQGEwJERTEcMBoGA1UEChMTRGV1dHNj aGUgVGVsZWtvbSBBRzEfMB0GA1UECxMWVC1UZWxlU2VjIFRydXN0IENlbnRlcjEjMCEGA1UEAxMa RGV1dHNjaGUgVGVsZWtvbSBSb290IENBIDIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCrC6M14IspFLEUha88EOQ5bzVdSq7d6mGNlUn0b2SjGmBmpKlAIoTZ1KXleJMOaAGtuU1cOs7T uKhCQN/Po7qCWWqSG6wcmtoIKyUn+WkjR/Hg6yx6m/UTAtB+NHzCnjwAWav12gz1MjwrrFDa1sPe g5TKqAyZMg4ISFZbavva4VhYAUlfckE8FQYBjl2tqriTtM2e66foai1SNNs671x1Udrb8zH57nGY MsRUFUQM+ZtV7a3fGAigo4aKSe5TBY8ZTNXeWHmb0mocQqvF1afPaA+W5OFhmHZhyJF81j4A4pFQ h+GdCuatl9Idxjp9y7zaAzTVjlsB9WoHtxa2bkp/AgMBAAGjQjBAMB0GA1UdDgQWBBQxw3kbuvVT 1xfgiXotF2wKsyudMzAPBgNVHRMECDAGAQH/AgEFMA4GA1UdDwEB/wQEAwIBBjANBgkqhkiG9w0B AQUFAAOCAQEAlGRZrTlk5ynrE/5aw4sTV8gEJPB0d8Bg42f76Ymmg7+Wgnxu1MM9756AbrsptJh6 sTtU6zkXR34ajgv8HzFZMQSyzhfzLMdiNlXiItiJVbSYSKpk+tYcNthEeFpaIzpXl/V6ME+un2pM SyuOoAPjPuCp1NJ70rOo4nI8rZ7/gFnkm0W09juwzTkZmDLl6iFhkOQxIY40sfcvNUqFENrnijch vllj4PKFiDFT1FQUhXB59C4Gdyd1Lx+4ivn+xbrYNuSD7Odlt79jWvNGr4GUN9RBjNYj1h7P9Wgb RGOiWrqnNVmh5XAFmw4jV5mUCm26OWMohpLzGITY+9HPBVZkVzCCBNUwggO9oAMCAQICCFBOxvU9 EbRkMA0GCSqGSIb3DQEBCwUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNEZXV0c2NoZSBUZWxl a29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYDVQQDExpEZXV0c2No ZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0xNDA3MjIxMjA4MjZaFw0xOTA3MDkyMzU5MDBaMFoxCzAJ BgNVBAYTAkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQD ExtERk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U1wBblSJ01CDrNI/W7MAxBAuZgeKmFNJSoCgjhIt0 iQReW+DieMF4yxbLKDU5ey2QRdDtoAB6fL9KDhsAw4bpXCsxEXsM84IkQ4wcOItqaACa7txPeKvS xhObdq3u3ibo7wGvdA/BCaL2a869080UME/15eOkyGKbghoDJzANAmVgTe3RCSMqljVYJ9N2xnG2 kB3E7f81hn1vM7PbD8URwoqDoZRdQWvY0hD1TP3KUazZve+Sg7va64sWVlZDz+HVEz2mHycwzUlU 28kTNJpxdcVs6qcLmPkhnSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjggGGMIIBgjAOBgNVHQ8BAf8E BAMCAQYwHQYDVR0OBBYEFEm3xs/oPR9/6kR7Eyn38QpwPt5kMB8GA1UdIwQYMBaAFDHDeRu69VPX F+CJei0XbAqzK50zMBIGA1UdEwEB/wQIMAYBAf8CAQIwYgYDVR0gBFswWTARBg8rBgEEAYGtIYIs AQEEAgIwEQYPKwYBBAGBrSGCLAEBBAMAMBEGDysGAQQBga0hgiwBAQQDATAPBg0rBgEEAYGtIYIs AQEEMA0GCysGAQQBga0hgiweMD4GA1UdHwQ3MDUwM6AxoC+GLWh0dHA6Ly9wa2kwMzM2LnRlbGVz ZWMuZGUvcmwvRFRfUk9PVF9DQV8yLmNybDB4BggrBgEFBQcBAQRsMGowLAYIKwYBBQUHMAGGIGh0 dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMDoGCCsGAQUFBzAChi5odHRwOi8vcGtpMDMz Ni50ZWxlc2VjLmRlL2NydC9EVF9ST09UX0NBXzIuY2VyMA0GCSqGSIb3DQEBCwUAA4IBAQBjICj9 nCGGcr45Rlk5MiW8qQGbDczKfUGchm0KbiyzE1l1sTOSG2EnFv/DstU1gvuEKgFJvWa7Zi+ywgZd bj9u4wFaW8pDY1yVtuExpx/VB19N5mWCTjL5w3x6S81NXHTuIfJ1AuxSPtLJatOQI25JZzW+f01W pOzML8+3oZeocj7JvEDWWqQIPda8gsO3tzKOsSyOam23NQIZz/U5RFhjpyQAELC7/E6vbi84u6VX ST/YblBvLJeW3B1GmmWJz67M8uXZn1OzPqEvkqnYC8aEHwTG6x7on321e6UC8STFJGMRNMxakyAq eYg6JUKQqWU7fIbTEhUjKfws2sw5W1QXMIIE1TCCA72gAwIBAgIIUE7G9T0RtGQwDQYJKoZIhvcN AQELBQAwcTELMAkGA1UEBhMCREUxHDAaBgNVBAoTE0RldXRzY2hlIFRlbGVrb20gQUcxHzAdBgNV BAsTFlQtVGVsZVNlYyBUcnVzdCBDZW50ZXIxIzAhBgNVBAMTGkRldXRzY2hlIFRlbGVrb20gUm9v dCBDQSAyMB4XDTE0MDcyMjEyMDgyNloXDTE5MDcwOTIzNTkwMFowWjELMAkGA1UEBhMCREUxEzAR BgNVBAoTCkRGTi1WZXJlaW4xEDAOBgNVBAsTB0RGTi1QS0kxJDAiBgNVBAMTG0RGTi1WZXJlaW4g UENBIEdsb2JhbCAtIEcwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOmbw2eF+Q2u 9Y1Uw5ZQNT1i6W5M7ZTXAFuVInTUIOs0j9bswDEEC5mB4qYU0lKgKCOEi3SJBF5b4OJ4wXjLFsso NTl7LZBF0O2gAHp8v0oOGwDDhulcKzERewzzgiRDjBw4i2poAJru3E94q9LGE5t2re7eJujvAa90 D8EJovZrzr3TzRQwT/Xl46TIYpuCGgMnMA0CZWBN7dEJIyqWNVgn03bGcbaQHcTt/zWGfW8zs9sP xRHCioOhlF1Ba9jSEPVM/cpRrNm975KDu9rrixZWVkPP4dUTPaYfJzDNSVTbyRM0mnF1xWzqpwuY +SGdJ68+ozk5SGqMrcmZ+8MS8r0CAwEAAaOCAYYwggGCMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4E FgQUSbfGz+g9H3/qRHsTKffxCnA+3mQwHwYDVR0jBBgwFoAUMcN5G7r1U9cX4Il6LRdsCrMrnTMw EgYDVR0TAQH/BAgwBgEB/wIBAjBiBgNVHSAEWzBZMBEGDysGAQQBga0hgiwBAQQCAjARBg8rBgEE AYGtIYIsAQEEAwAwEQYPKwYBBAGBrSGCLAEBBAMBMA8GDSsGAQQBga0hgiwBAQQwDQYLKwYBBAGB rSGCLB4wPgYDVR0fBDcwNTAzoDGgL4YtaHR0cDovL3BraTAzMzYudGVsZXNlYy5kZS9ybC9EVF9S T09UX0NBXzIuY3JsMHgGCCsGAQUFBwEBBGwwajAsBggrBgEFBQcwAYYgaHR0cDovL29jc3AwMzM2 LnRlbGVzZWMuZGUvb2NzcHIwOgYIKwYBBQUHMAKGLmh0dHA6Ly9wa2kwMzM2LnRlbGVzZWMuZGUv Y3J0L0RUX1JPT1RfQ0FfMi5jZXIwDQYJKoZIhvcNAQELBQADggEBAGMgKP2cIYZyvjlGWTkyJbyp AZsNzMp9QZyGbQpuLLMTWXWxM5IbYScW/8Oy1TWC+4QqAUm9ZrtmL7LCBl1uP27jAVpbykNjXJW2 4TGnH9UHX03mZYJOMvnDfHpLzU1cdO4h8nUC7FI+0slq05AjbklnNb5/TVak7Mwvz7ehl6hyPsm8 QNZapAg91ryCw7e3Mo6xLI5qbbc1AhnP9TlEWGOnJAAQsLv8Tq9uLzi7pVdJP9huUG8sl5bcHUaa ZYnPrszy5dmfU7M+oS+SqdgLxoQfBMbrHuiffbV7pQLxJMUkYxE0zFqTICp5iDolQpCpZTt8htMS FSMp/CzazDlbVBcwggU9MIIEJaADAgECAgcXr/adVkv+MA0GCSqGSIb3DQEBCwUAMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtE Rk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwHhcNMTQwNjA1MTQwNTAyWhcNMTkwNzA5MjM1OTAw WjBpMQswCQYDVQQGEwJERTEuMCwGA1UEChMlUGh5c2lrYWxpc2NoLVRlY2huaXNjaGUgQnVuZGVz YW5zdGFsdDEPMA0GA1UEAxMGUFRCIENBMRkwFwYJKoZIhvcNAQkBFgpwa2lAcHRiLmRlMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvArCgzkqw2LMAYuU38VJTgyGBC+Pp+uvw52LmtI6 MEMiFr0xY6SEzYcDG3z5NSohZisdnL7bu8Ee7MFD3TZX1jVBie//UNAJqXbHnUzE8hbJYCR5ydb9 WqIzoT5PzG07qJWblbidcrZVcCQEef9V1CaRyfXuqiSTOgibqODLP98N7jMIImz2ipUgMdoGyOgS h/qds5SM6CUgwMeuJ42QpYNot9ri1IKAweyhIIa3TANsu56scy+Fc2+XWOfsuImeeLcaiu6HJPk6 X55QT+kWaAoQf6qJyJXv8b/n6l1nmTIU2AY2B5EnO/rIT+DW+MJy77/HO+7rtwaznuntXMgytwID AQABo4IB9zCCAfMwEgYDVR0TAQH/BAgwBgEB/wIBATAOBgNVHQ8BAf8EBAMCAQYwEQYDVR0gBAow CDAGBgRVHSAAMB0GA1UdDgQWBBTEgNBuKBVoMVrscF94juEwQzjqNDAfBgNVHSMEGDAWgBRJt8bP 6D0ff+pEexMp9/EKcD7eZDAVBgNVHREEDjAMgQpwa2lAcHRiLmRlMIGIBgNVHR8EgYAwfjA9oDug OYY3aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY3JsL2NhY3JsLmNy bDA9oDugOYY3aHR0cDovL2NkcDIucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY3JsL2Nh Y3JsLmNybDCB1wYIKwYBBQUHAQEEgcowgccwMwYIKwYBBQUHMAGGJ2h0dHA6Ly9vY3NwLnBjYS5k Zm4uZGUvT0NTUC1TZXJ2ZXIvT0NTUDBHBggrBgEFBQcwAoY7aHR0cDovL2NkcDEucGNhLmRmbi5k ZS9nbG9iYWwtcm9vdC1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwRwYIKwYBBQUHMAKGO2h0dHA6 Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MA0G CSqGSIb3DQEBCwUAA4IBAQCo3hebMpEocLPJTOlDMAmSzpxK3SA1ftaQqodbMncOi9WkeICQlmIv rQxGCq8Be/6hKtIrbFOhRtSzQi870glJRj7dhZaHC+WOgT5tP5Nkgwpgl4k4pQDXPPrwmaI6cSYD a/LpprQzBNjEQMdQqkeanpD0WU9U1pOPFIMfIrxh2cy8mBpIAMuZqMHbMyPNDZk/YN4r3b2DcBrQ wL/tHerp6Vc7n9WqO+3cm7Fa4AxL9q2KeItyYe0Cws2KZNz4IuiMjQAclNL0PhTEqIzkD/EiK6Ag 1qcH7o3ktpmakvL2RzSZA71irCfONRgh/+ixfuMu6YA5uzyA8SYfwyFQcABdMIIFPTCCBCWgAwIB AgIHF6/2nVZL/jANBgkqhkiG9w0BAQsFADBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZOLVZl cmVpbjEQMA4GA1UECxMHREZOLVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xvYmFsIC0g RzAxMB4XDTE0MDYwNTE0MDUwMloXDTE5MDcwOTIzNTkwMFowaTELMAkGA1UEBhMCREUxLjAsBgNV BAoTJVBoeXNpa2FsaXNjaC1UZWNobmlzY2hlIEJ1bmRlc2Fuc3RhbHQxDzANBgNVBAMTBlBUQiBD QTEZMBcGCSqGSIb3DQEJARYKcGtpQHB0Yi5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALwKwoM5KsNizAGLlN/FSU4MhgQvj6frr8Odi5rSOjBDIha9MWOkhM2HAxt8+TUqIWYrHZy+ 27vBHuzBQ902V9Y1QYnv/1DQCal2x51MxPIWyWAkecnW/VqiM6E+T8xtO6iVm5W4nXK2VXAkBHn/ VdQmkcn17qokkzoIm6jgyz/fDe4zCCJs9oqVIDHaBsjoEof6nbOUjOglIMDHrieNkKWDaLfa4tSC gMHsoSCGt0wDbLuerHMvhXNvl1jn7LiJnni3GoruhyT5Ol+eUE/pFmgKEH+qiciV7/G/5+pdZ5ky FNgGNgeRJzv6yE/g1vjCcu+/xzvu67cGs57p7VzIMrcCAwEAAaOCAfcwggHzMBIGA1UdEwEB/wQI MAYBAf8CAQEwDgYDVR0PAQH/BAQDAgEGMBEGA1UdIAQKMAgwBgYEVR0gADAdBgNVHQ4EFgQUxIDQ bigVaDFa7HBfeI7hMEM46jQwHwYDVR0jBBgwFoAUSbfGz+g9H3/qRHsTKffxCnA+3mQwFQYDVR0R BA4wDIEKcGtpQHB0Yi5kZTCBiAYDVR0fBIGAMH4wPaA7oDmGN2h0dHA6Ly9jZHAxLnBjYS5kZm4u ZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NybC9jYWNybC5jcmwwPaA7oDmGN2h0dHA6Ly9jZHAyLnBj YS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NybC9jYWNybC5jcmwwgdcGCCsGAQUFBwEBBIHK MIHHMDMGCCsGAQUFBzABhidodHRwOi8vb2NzcC5wY2EuZGZuLmRlL09DU1AtU2VydmVyL09DU1Aw RwYIKwYBBQUHMAKGO2h0dHA6Ly9jZHAxLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2Nh Y2VydC9jYWNlcnQuY3J0MEcGCCsGAQUFBzAChjtodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2dsb2Jh bC1yb290LWNhL3B1Yi9jYWNlcnQvY2FjZXJ0LmNydDANBgkqhkiG9w0BAQsFAAOCAQEAqN4XmzKR KHCzyUzpQzAJks6cSt0gNX7WkKqHWzJ3DovVpHiAkJZiL60MRgqvAXv+oSrSK2xToUbUs0IvO9IJ SUY+3YWWhwvljoE+bT+TZIMKYJeJOKUA1zz68JmiOnEmA2vy6aa0MwTYxEDHUKpHmp6Q9FlPVNaT jxSDHyK8YdnMvJgaSADLmajB2zMjzQ2ZP2DeK929g3Aa0MC/7R3q6elXO5/Vqjvt3JuxWuAMS/at iniLcmHtAsLNimTc+CLojI0AHJTS9D4UxKiM5A/xIiugINanB+6N5LaZmpLy9kc0mQO9YqwnzjUY If/osX7jLumAObs8gPEmH8MhUHAAXTCCBaIwggSKoAMCAQICDBxmO6qdufc5yhZ6iDANBgkqhkiG 9w0BAQsFADBpMQswCQYDVQQGEwJERTEuMCwGA1UEChMlUGh5c2lrYWxpc2NoLVRlY2huaXNjaGUg QnVuZGVzYW5zdGFsdDEPMA0GA1UEAxMGUFRCIENBMRkwFwYJKoZIhvcNAQkBFgpwa2lAcHRiLmRl MB4XDTE2MTIwNjEzMzMxNFoXDTE5MDcwOTIzNTkwMFowaDELMAkGA1UEBhMCREUxLjAsBgNVBAoM JVBoeXNpa2FsaXNjaC1UZWNobmlzY2hlIEJ1bmRlc2Fuc3RhbHQxDTALBgNVBAsMBFEuNDIxGjAY BgNVBAMMEURyLiBEaWV0ZXIgU2lib2xkMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA +AOQrmrEQ2k8s9su/TVvmdF46YbL2MuF6OvnrjjKaJIkBvchop87cCwv80aZEbmU3as54egQEMGn NFkp1fF4bics4TJdEpND116l+jbi5DCtA3hHP/spV1aQZBDc/BDkm1Nl5WYKh/DxN6sUhZxorbb4 Y0nmSxnK2ctIwuF4Qdibsw7GE2YLvWF4tlzSCGbDjSy2agSn1wYHMsC+tAcFflcMXF2sDMZHkYuq 5IHwng8GBQFhsldYl1fk2sB2/hVRLYU205qaj13H94WjfDLuB22sT17XPJ2U/9tuFN/sxAPR0/N4 y4/IgMnOaP30VU0FMmULd7qJg0WST5D5kwgMhwIDAQABo4ICSTCCAkUwQAYDVR0gBDkwNzARBg8r BgEEAYGtIYIsAQEEAwUwEQYPKwYBBAGBrSGCLAIBBAMBMA8GDSsGAQQBga0hgiwBAQQwCQYDVR0T BAIwADAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1Ud DgQWBBQHn42zKDpvJi1bsJ4OVk2A9liUFjAfBgNVHSMEGDAWgBTEgNBuKBVoMVrscF94juEwQzjq NDBEBgNVHREEPTA7gRRkaWV0ZXIuc2lib2xkQHB0Yi5kZaAjBgorBgEEAYI3FAIDoBUME3NpYm9s ZDAxQHBhZC5wdGIuZGUwdwYDVR0fBHAwbjA1oDOgMYYvaHR0cDovL2NkcDEucGNhLmRmbi5kZS9w dGItY2EvcHViL2NybC9jYWNybC5jcmwwNaAzoDGGL2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvcHRi LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIHHBggrBgEFBQcBAQSBujCBtzAzBggrBgEFBQcwAYYnaHR0 cDovL29jc3AucGNhLmRmbi5kZS9PQ1NQLVNlcnZlci9PQ1NQMD8GCCsGAQUFBzAChjNodHRwOi8v Y2RwMS5wY2EuZGZuLmRlL3B0Yi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwPwYIKwYBBQUHMAKG M2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvcHRiLWNhL3B1Yi9jYWNlcnQvY2FjZXJ0LmNydDANBgkq hkiG9w0BAQsFAAOCAQEADaSfgrrQZx9eiQrCK7kgJMpLstro5OgIcWSpW4i4AQ1wEwyDUrdB1XWK GjA8/KwExSBP9a+dcdW+ACjX7TyURQPLqRTOkoPc9dafRx327mV4K8PE8z7fg5l2ittYNs0nXlOB QevRbYYP4XUOMYohFWfHpDwEg3ExmoArb2HaQCzKhq/2VcIIXTwaN6AVr2NVKEuH3qwpgOUSlJJ1 5ORb6TD4p1G2W6XT3jk3tOa8nRaOkI5hqpPvLfbPEibn+Bfqm6GWqpXfQ6NLAvWYcI8ltSKgdnCw Rmqdh1Ba/KWGdm41PDtQIx58vgbZGfN5GKJrp+OwS5D+/e/r296qoKUBRDCCBaIwggSKoAMCAQIC DBxmO6qdufc5yhZ6iDANBgkqhkiG9w0BAQsFADBpMQswCQYDVQQGEwJERTEuMCwGA1UEChMlUGh5 c2lrYWxpc2NoLVRlY2huaXNjaGUgQnVuZGVzYW5zdGFsdDEPMA0GA1UEAxMGUFRCIENBMRkwFwYJ KoZIhvcNAQkBFgpwa2lAcHRiLmRlMB4XDTE2MTIwNjEzMzMxNFoXDTE5MDcwOTIzNTkwMFowaDEL MAkGA1UEBhMCREUxLjAsBgNVBAoMJVBoeXNpa2FsaXNjaC1UZWNobmlzY2hlIEJ1bmRlc2Fuc3Rh bHQxDTALBgNVBAsMBFEuNDIxGjAYBgNVBAMMEURyLiBEaWV0ZXIgU2lib2xkMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA+AOQrmrEQ2k8s9su/TVvmdF46YbL2MuF6OvnrjjKaJIkBvch op87cCwv80aZEbmU3as54egQEMGnNFkp1fF4bics4TJdEpND116l+jbi5DCtA3hHP/spV1aQZBDc /BDkm1Nl5WYKh/DxN6sUhZxorbb4Y0nmSxnK2ctIwuF4Qdibsw7GE2YLvWF4tlzSCGbDjSy2agSn 1wYHMsC+tAcFflcMXF2sDMZHkYuq5IHwng8GBQFhsldYl1fk2sB2/hVRLYU205qaj13H94WjfDLu B22sT17XPJ2U/9tuFN/sxAPR0/N4y4/IgMnOaP30VU0FMmULd7qJg0WST5D5kwgMhwIDAQABo4IC STCCAkUwQAYDVR0gBDkwNzARBg8rBgEEAYGtIYIsAQEEAwUwEQYPKwYBBAGBrSGCLAIBBAMBMA8G DSsGAQQBga0hgiwBAQQwCQYDVR0TBAIwADAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYB BQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQHn42zKDpvJi1bsJ4OVk2A9liUFjAfBgNVHSMEGDAW gBTEgNBuKBVoMVrscF94juEwQzjqNDBEBgNVHREEPTA7gRRkaWV0ZXIuc2lib2xkQHB0Yi5kZaAj BgorBgEEAYI3FAIDoBUME3NpYm9sZDAxQHBhZC5wdGIuZGUwdwYDVR0fBHAwbjA1oDOgMYYvaHR0 cDovL2NkcDEucGNhLmRmbi5kZS9wdGItY2EvcHViL2NybC9jYWNybC5jcmwwNaAzoDGGL2h0dHA6 Ly9jZHAyLnBjYS5kZm4uZGUvcHRiLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIHHBggrBgEFBQcBAQSB ujCBtzAzBggrBgEFBQcwAYYnaHR0cDovL29jc3AucGNhLmRmbi5kZS9PQ1NQLVNlcnZlci9PQ1NQ MD8GCCsGAQUFBzAChjNodHRwOi8vY2RwMS5wY2EuZGZuLmRlL3B0Yi1jYS9wdWIvY2FjZXJ0L2Nh Y2VydC5jcnQwPwYIKwYBBQUHMAKGM2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvcHRiLWNhL3B1Yi9j YWNlcnQvY2FjZXJ0LmNydDANBgkqhkiG9w0BAQsFAAOCAQEADaSfgrrQZx9eiQrCK7kgJMpLstro 5OgIcWSpW4i4AQ1wEwyDUrdB1XWKGjA8/KwExSBP9a+dcdW+ACjX7TyURQPLqRTOkoPc9dafRx32 7mV4K8PE8z7fg5l2ittYNs0nXlOBQevRbYYP4XUOMYohFWfHpDwEg3ExmoArb2HaQCzKhq/2VcII XTwaN6AVr2NVKEuH3qwpgOUSlJJ15ORb6TD4p1G2W6XT3jk3tOa8nRaOkI5hqpPvLfbPEibn+Bfq m6GWqpXfQ6NLAvWYcI8ltSKgdnCwRmqdh1Ba/KWGdm41PDtQIx58vgbZGfN5GKJrp+OwS5D+/e/r 296qoKUBRDGCAuMwggLfAgEBMHkwaTELMAkGA1UEBhMCREUxLjAsBgNVBAoTJVBoeXNpa2FsaXNj aC1UZWNobmlzY2hlIEJ1bmRlc2Fuc3RhbHQxDzANBgNVBAMTBlBUQiBDQTEZMBcGCSqGSIb3DQEJ ARYKcGtpQHB0Yi5kZQIMHGY7qp259znKFnqIMA0GCWCGSAFlAwQCAQUAoIIBOzAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzA4MjIwNzU2MzJaMC8GCSqGSIb3DQEJ BDEiBCA6odwaY6dkfb6ljLxb4TgHjMB2GTwF5Ri4//P+Cxkj6zBDBgkqhkiG9w0BCQ8xNjA0MAcG BSsOAwIdMA4GCCqGSIb3DQMCAgIAgDAKBggqhkiG9w0DBzANBggqhkiG9w0DAgIBKDCBigYLKoZI hvcNAQkQAgsxe6B5MGkxCzAJBgNVBAYTAkRFMS4wLAYDVQQKEyVQaHlzaWthbGlzY2gtVGVjaG5p c2NoZSBCdW5kZXNhbnN0YWx0MQ8wDQYDVQQDEwZQVEIgQ0ExGTAXBgkqhkiG9w0BCQEWCnBraUBw dGIuZGUCDBxmO6qdufc5yhZ6iDANBgkqhkiG9w0BAQEFAASCAQBmqZ5JiuGqPSmqefNGWuvUItqG P5h8UA3WKIRVFVwO6I0N9cA1/QqFxYUaf+G3lGzBtceXYbTJOu9L8RbWkT9UHuv9vIpSm1tbggZs Gfvn0AoLx/7UlaZEX4uddsL89BF920Q2Z69KAtbF6xutL5BrkKzs/ASCgByu8zRH1fij+y0KaNog sDnncZVyHWK6SmWVAB9DSg8yYk81a7cJD3emmWXFCQ0UL3Kg9uccMmyNJsm/fqe0EyHdl2wr2JuY 7uf1rdjdMhIhBJCkR05HG7yDMviut6obBUZ+7uY43rbkkq3QlFl603iRsUXu77m7hKIx5esGd4lI EbfC0Kj+4BVaAAAAAA== ---------z48124_boundary_sign-- From ntp-bounces@ietf.org Tue Aug 22 00:56:44 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 43B531321B7; Tue, 22 Aug 2017 00:56:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1503388604; bh=l0rB4+3EawiQ1YRHPEF9CLoSi83N1rI9lLd5bAyq+XE=; h=In-Reply-To:References:To:From:Date:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc; b=zLRuyLtQTnhcmocW8S+C+w3uNfIDpg4URHEQKRq0+P1MDoQMMeq4NC5ybXCrvwdIC ou04VsL11oNwhJQoo0a1ZDjwhgBpyKnZ0EXgzXx7PDFD6rfDQJcYEnnbEDA0n4S3WA zOoqC15XCyr4VTo5DD+f+0oGaxwdKe8nmwXKJhIY= 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 D8126126B71; Tue, 22 Aug 2017 00:56:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 vg9-489yxhUE; Tue, 22 Aug 2017 00:56:38 -0700 (PDT) Received: from mx1.bs.ptb.de (mx1.bs.ptb.de [IPv6:2001:638:610:bd01::120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 983F81321B7; Tue, 22 Aug 2017 00:56:38 -0700 (PDT) Received: from smtp-hub.bs.ptb.de (smtpint01.bs.ptb.de [141.25.87.32]) by mx1.bs.ptb.de with ESMTP id v7M7uXvg019554-v7M7uXvi019554 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 22 Aug 2017 09:56:33 +0200 Received: from rose.bs.ptb.de (rose.bs.ptb.de [141.25.85.201]) by smtp-hub.bs.ptb.de (Postfix) with ESMTPS id 0977A530156; Tue, 22 Aug 2017 09:56:33 +0200 (CEST) In-Reply-To: <6AC635D8-E173-49F2-A9B6-90FBDFD7700F@akamai.com> References: <6AC635D8-E173-49F2-A9B6-90FBDFD7700F@akamai.com> To: "Salz, Rich" MIME-Version: 1.0 Message-ID: From: dieter.sibold@ptb.de Date: Tue, 22 Aug 2017 09:56:31 +0200 Archived-At: Subject: [Ntp] Antwort: Re: NTS/Updated Autokey X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "ntp@ietf.org" , Harlan Stenn , ntp Content-Type: multipart/mixed; boundary="===============5853265590257143769==" Errors-To: ntp-bounces@ietf.org Sender: "ntp" This is an S/MIME signed message. --===============5853265590257143769== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha-256; boundary=-------z48124_boundary_sign This is an S/MIME signed message. ---------z48124_boundary_sign Content-Type: multipart/alternative; boundary="=_alternative 002BA090C1258184_=" Dies ist eine mehrteilige Nachricht im MIME-Format. --=_alternative 002BA090C1258184_= Content-Type: text/plain; charset="US-ASCII" I agree with Rich. It would be very helpful if especially concerns regarding the NTS draft are posted separately. Dieter "ntp" schrieb am 21.08.2017 14:53:57: > Von: "Salz, Rich" > An: Harlan Stenn , "ntp@ietf.org" > Datum: 21.08.2017 14:54 > Betreff: Re: [Ntp] NTS/Updated Autokey > Gesendet von: "ntp" > > It is unfortunate that Dave cannot easily participate in the mailing > list discussion, since we all know that is where the IETF does its work. > > I gave a quick read to his document. First, it seems to be a mix of > questions/comments and an alternate proposal. Please ask him to > separate those into two messages. If you are acting as his > interlocutor, please post the questions part directly, not as an > attachment. Second, DH is way too expensive, ECDH probably using > X25519, is the only mechanism to use. > > > > _______________________________________________ > ntp mailing list > ntp@ietf.org > https://www.ietf.org/mailman/listinfo/ntp --=_alternative 002BA090C1258184_= Content-Type: text/html; charset="US-ASCII" I agree with Rich. It would be very helpful if especially concerns regarding the NTS draft are posted separately.
Dieter


"ntp" <ntp-bounces@ietf.org> schrieb am 21.08.2017 14:53:57:

> Von: "Salz, Rich" <rsalz@akamai.com>
> An: Harlan Stenn <stenn@nwtime.org>, "ntp@ietf.org" <ntp@ietf.org>
> Datum: 21.08.2017 14:54
> Betreff: Re: [Ntp] NTS/Updated Autokey
> Gesendet von: "ntp" <ntp-bounces@ietf.org>
>
> It is unfortunate that Dave cannot easily participate in the mailing
> list discussion, since we all know that is where the IETF does its work.
>
> I gave a quick read to his document.  First, it seems to be a mix of
> questions/comments and an alternate proposal.  Please ask him to
> separate those into two messages.  If you are acting as his
> interlocutor, please post the questions part directly, not as an
> attachment.  Second, DH is way too expensive, ECDH probably using
> X25519, is the only mechanism to use.
>
>  
>
> _______________________________________________
> ntp mailing list
> ntp@ietf.org
> https://www.ietf.org/mailman/listinfo/ntp
 --=_alternative 002BA090C1258184_=-- ---------z48124_boundary_sign Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIIp0gIBATEPMA0GCWCGSAFlAwQCAQUAMAsGCSqGSIb3DQEHAaCCJsYw ggOfMIICh6ADAgECAgEmMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNE ZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYD VQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw05OTA3MDkxMjExMDBaFw0xOTA3MDky MzU5MDBaMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYD VQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJv b3QgQ0EgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKsLozXgiykUsRSFrzwQ5Dlv NV1Krt3qYY2VSfRvZKMaYGakqUAihNnUpeV4kw5oAa25TVw6ztO4qEJA38+juoJZapIbrBya2ggr JSf5aSNH8eDrLHqb9RMC0H40fMKePABZq/XaDPUyPCusUNrWw96DlMqoDJkyDghIVltq+9rhWFgB SV9yQTwVBgGOXa2quJO0zZ7rp+hqLVI02zrvXHVR2tvzMfnucZgyxFQVRAz5m1Xtrd8YCKCjhopJ 7lMFjxlM1d5YeZvSahxCq8XVp89oD5bk4WGYdmHIkXzWPgDikVCH4Z0K5q2X0h3GOn3LvNoDNNWO WwH1age3FrZuSn8CAwEAAaNCMEAwHQYDVR0OBBYEFDHDeRu69VPXF+CJei0XbAqzK50zMA8GA1Ud EwQIMAYBAf8CAQUwDgYDVR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBBQUAA4IBAQCUZFmtOWTnKesT /lrDixNXyAQk8HR3wGDjZ/vpiaaDv5aCfG7Uwz3vnoBuuym0mHqxO1TrORdHfhqOC/wfMVkxBLLO F/Msx2I2VeIi2IlVtJhIqmT61hw22ER4WlojOleX9XowT66fakxLK46gA+M+4KnU0nvSs6jicjyt nv+AWeSbRbT2O7DNORmYMuXqIWGQ5DEhjjSx9y81SoUQ2ueKNyG+WWPg8oWIMVPUVBSFcHn0LgZ3 J3UvH7iK+f7Futg25IPs52W3v2Na80avgZQ31EGM1iPWHs/1aBtEY6Jauqc1WaHlcAWbDiNXmZQK bbo5YyiGkvMYhNj70c8FVmRXMIIDnzCCAoegAwIBAgIBJjANBgkqhkiG9w0BAQUFADBxMQswCQYD VQQGEwJERTEcMBoGA1UEChMTRGV1dHNjaGUgVGVsZWtvbSBBRzEfMB0GA1UECxMWVC1UZWxlU2Vj IFRydXN0IENlbnRlcjEjMCEGA1UEAxMaRGV1dHNjaGUgVGVsZWtvbSBSb290IENBIDIwHhcNOTkw NzA5MTIxMTAwWhcNMTkwNzA5MjM1OTAwWjBxMQswCQYDVQQGEwJERTEcMBoGA1UEChMTRGV1dHNj aGUgVGVsZWtvbSBBRzEfMB0GA1UECxMWVC1UZWxlU2VjIFRydXN0IENlbnRlcjEjMCEGA1UEAxMa RGV1dHNjaGUgVGVsZWtvbSBSb290IENBIDIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCrC6M14IspFLEUha88EOQ5bzVdSq7d6mGNlUn0b2SjGmBmpKlAIoTZ1KXleJMOaAGtuU1cOs7T uKhCQN/Po7qCWWqSG6wcmtoIKyUn+WkjR/Hg6yx6m/UTAtB+NHzCnjwAWav12gz1MjwrrFDa1sPe g5TKqAyZMg4ISFZbavva4VhYAUlfckE8FQYBjl2tqriTtM2e66foai1SNNs671x1Udrb8zH57nGY MsRUFUQM+ZtV7a3fGAigo4aKSe5TBY8ZTNXeWHmb0mocQqvF1afPaA+W5OFhmHZhyJF81j4A4pFQ h+GdCuatl9Idxjp9y7zaAzTVjlsB9WoHtxa2bkp/AgMBAAGjQjBAMB0GA1UdDgQWBBQxw3kbuvVT 1xfgiXotF2wKsyudMzAPBgNVHRMECDAGAQH/AgEFMA4GA1UdDwEB/wQEAwIBBjANBgkqhkiG9w0B AQUFAAOCAQEAlGRZrTlk5ynrE/5aw4sTV8gEJPB0d8Bg42f76Ymmg7+Wgnxu1MM9756AbrsptJh6 sTtU6zkXR34ajgv8HzFZMQSyzhfzLMdiNlXiItiJVbSYSKpk+tYcNthEeFpaIzpXl/V6ME+un2pM SyuOoAPjPuCp1NJ70rOo4nI8rZ7/gFnkm0W09juwzTkZmDLl6iFhkOQxIY40sfcvNUqFENrnijch vllj4PKFiDFT1FQUhXB59C4Gdyd1Lx+4ivn+xbrYNuSD7Odlt79jWvNGr4GUN9RBjNYj1h7P9Wgb RGOiWrqnNVmh5XAFmw4jV5mUCm26OWMohpLzGITY+9HPBVZkVzCCBNUwggO9oAMCAQICCFBOxvU9 EbRkMA0GCSqGSIb3DQEBCwUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNEZXV0c2NoZSBUZWxl a29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYDVQQDExpEZXV0c2No ZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0xNDA3MjIxMjA4MjZaFw0xOTA3MDkyMzU5MDBaMFoxCzAJ BgNVBAYTAkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQD ExtERk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U1wBblSJ01CDrNI/W7MAxBAuZgeKmFNJSoCgjhIt0 iQReW+DieMF4yxbLKDU5ey2QRdDtoAB6fL9KDhsAw4bpXCsxEXsM84IkQ4wcOItqaACa7txPeKvS xhObdq3u3ibo7wGvdA/BCaL2a869080UME/15eOkyGKbghoDJzANAmVgTe3RCSMqljVYJ9N2xnG2 kB3E7f81hn1vM7PbD8URwoqDoZRdQWvY0hD1TP3KUazZve+Sg7va64sWVlZDz+HVEz2mHycwzUlU 28kTNJpxdcVs6qcLmPkhnSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjggGGMIIBgjAOBgNVHQ8BAf8E BAMCAQYwHQYDVR0OBBYEFEm3xs/oPR9/6kR7Eyn38QpwPt5kMB8GA1UdIwQYMBaAFDHDeRu69VPX F+CJei0XbAqzK50zMBIGA1UdEwEB/wQIMAYBAf8CAQIwYgYDVR0gBFswWTARBg8rBgEEAYGtIYIs AQEEAgIwEQYPKwYBBAGBrSGCLAEBBAMAMBEGDysGAQQBga0hgiwBAQQDATAPBg0rBgEEAYGtIYIs AQEEMA0GCysGAQQBga0hgiweMD4GA1UdHwQ3MDUwM6AxoC+GLWh0dHA6Ly9wa2kwMzM2LnRlbGVz ZWMuZGUvcmwvRFRfUk9PVF9DQV8yLmNybDB4BggrBgEFBQcBAQRsMGowLAYIKwYBBQUHMAGGIGh0 dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMDoGCCsGAQUFBzAChi5odHRwOi8vcGtpMDMz Ni50ZWxlc2VjLmRlL2NydC9EVF9ST09UX0NBXzIuY2VyMA0GCSqGSIb3DQEBCwUAA4IBAQBjICj9 nCGGcr45Rlk5MiW8qQGbDczKfUGchm0KbiyzE1l1sTOSG2EnFv/DstU1gvuEKgFJvWa7Zi+ywgZd bj9u4wFaW8pDY1yVtuExpx/VB19N5mWCTjL5w3x6S81NXHTuIfJ1AuxSPtLJatOQI25JZzW+f01W pOzML8+3oZeocj7JvEDWWqQIPda8gsO3tzKOsSyOam23NQIZz/U5RFhjpyQAELC7/E6vbi84u6VX ST/YblBvLJeW3B1GmmWJz67M8uXZn1OzPqEvkqnYC8aEHwTG6x7on321e6UC8STFJGMRNMxakyAq eYg6JUKQqWU7fIbTEhUjKfws2sw5W1QXMIIE1TCCA72gAwIBAgIIUE7G9T0RtGQwDQYJKoZIhvcN AQELBQAwcTELMAkGA1UEBhMCREUxHDAaBgNVBAoTE0RldXRzY2hlIFRlbGVrb20gQUcxHzAdBgNV BAsTFlQtVGVsZVNlYyBUcnVzdCBDZW50ZXIxIzAhBgNVBAMTGkRldXRzY2hlIFRlbGVrb20gUm9v dCBDQSAyMB4XDTE0MDcyMjEyMDgyNloXDTE5MDcwOTIzNTkwMFowWjELMAkGA1UEBhMCREUxEzAR BgNVBAoTCkRGTi1WZXJlaW4xEDAOBgNVBAsTB0RGTi1QS0kxJDAiBgNVBAMTG0RGTi1WZXJlaW4g UENBIEdsb2JhbCAtIEcwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOmbw2eF+Q2u 9Y1Uw5ZQNT1i6W5M7ZTXAFuVInTUIOs0j9bswDEEC5mB4qYU0lKgKCOEi3SJBF5b4OJ4wXjLFsso NTl7LZBF0O2gAHp8v0oOGwDDhulcKzERewzzgiRDjBw4i2poAJru3E94q9LGE5t2re7eJujvAa90 D8EJovZrzr3TzRQwT/Xl46TIYpuCGgMnMA0CZWBN7dEJIyqWNVgn03bGcbaQHcTt/zWGfW8zs9sP xRHCioOhlF1Ba9jSEPVM/cpRrNm975KDu9rrixZWVkPP4dUTPaYfJzDNSVTbyRM0mnF1xWzqpwuY +SGdJ68+ozk5SGqMrcmZ+8MS8r0CAwEAAaOCAYYwggGCMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4E FgQUSbfGz+g9H3/qRHsTKffxCnA+3mQwHwYDVR0jBBgwFoAUMcN5G7r1U9cX4Il6LRdsCrMrnTMw EgYDVR0TAQH/BAgwBgEB/wIBAjBiBgNVHSAEWzBZMBEGDysGAQQBga0hgiwBAQQCAjARBg8rBgEE AYGtIYIsAQEEAwAwEQYPKwYBBAGBrSGCLAEBBAMBMA8GDSsGAQQBga0hgiwBAQQwDQYLKwYBBAGB rSGCLB4wPgYDVR0fBDcwNTAzoDGgL4YtaHR0cDovL3BraTAzMzYudGVsZXNlYy5kZS9ybC9EVF9S T09UX0NBXzIuY3JsMHgGCCsGAQUFBwEBBGwwajAsBggrBgEFBQcwAYYgaHR0cDovL29jc3AwMzM2 LnRlbGVzZWMuZGUvb2NzcHIwOgYIKwYBBQUHMAKGLmh0dHA6Ly9wa2kwMzM2LnRlbGVzZWMuZGUv Y3J0L0RUX1JPT1RfQ0FfMi5jZXIwDQYJKoZIhvcNAQELBQADggEBAGMgKP2cIYZyvjlGWTkyJbyp AZsNzMp9QZyGbQpuLLMTWXWxM5IbYScW/8Oy1TWC+4QqAUm9ZrtmL7LCBl1uP27jAVpbykNjXJW2 4TGnH9UHX03mZYJOMvnDfHpLzU1cdO4h8nUC7FI+0slq05AjbklnNb5/TVak7Mwvz7ehl6hyPsm8 QNZapAg91ryCw7e3Mo6xLI5qbbc1AhnP9TlEWGOnJAAQsLv8Tq9uLzi7pVdJP9huUG8sl5bcHUaa ZYnPrszy5dmfU7M+oS+SqdgLxoQfBMbrHuiffbV7pQLxJMUkYxE0zFqTICp5iDolQpCpZTt8htMS FSMp/CzazDlbVBcwggU9MIIEJaADAgECAgcXr/adVkv+MA0GCSqGSIb3DQEBCwUAMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtE Rk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwHhcNMTQwNjA1MTQwNTAyWhcNMTkwNzA5MjM1OTAw WjBpMQswCQYDVQQGEwJERTEuMCwGA1UEChMlUGh5c2lrYWxpc2NoLVRlY2huaXNjaGUgQnVuZGVz YW5zdGFsdDEPMA0GA1UEAxMGUFRCIENBMRkwFwYJKoZIhvcNAQkBFgpwa2lAcHRiLmRlMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvArCgzkqw2LMAYuU38VJTgyGBC+Pp+uvw52LmtI6 MEMiFr0xY6SEzYcDG3z5NSohZisdnL7bu8Ee7MFD3TZX1jVBie//UNAJqXbHnUzE8hbJYCR5ydb9 WqIzoT5PzG07qJWblbidcrZVcCQEef9V1CaRyfXuqiSTOgibqODLP98N7jMIImz2ipUgMdoGyOgS h/qds5SM6CUgwMeuJ42QpYNot9ri1IKAweyhIIa3TANsu56scy+Fc2+XWOfsuImeeLcaiu6HJPk6 X55QT+kWaAoQf6qJyJXv8b/n6l1nmTIU2AY2B5EnO/rIT+DW+MJy77/HO+7rtwaznuntXMgytwID AQABo4IB9zCCAfMwEgYDVR0TAQH/BAgwBgEB/wIBATAOBgNVHQ8BAf8EBAMCAQYwEQYDVR0gBAow CDAGBgRVHSAAMB0GA1UdDgQWBBTEgNBuKBVoMVrscF94juEwQzjqNDAfBgNVHSMEGDAWgBRJt8bP 6D0ff+pEexMp9/EKcD7eZDAVBgNVHREEDjAMgQpwa2lAcHRiLmRlMIGIBgNVHR8EgYAwfjA9oDug OYY3aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY3JsL2NhY3JsLmNy bDA9oDugOYY3aHR0cDovL2NkcDIucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY3JsL2Nh Y3JsLmNybDCB1wYIKwYBBQUHAQEEgcowgccwMwYIKwYBBQUHMAGGJ2h0dHA6Ly9vY3NwLnBjYS5k Zm4uZGUvT0NTUC1TZXJ2ZXIvT0NTUDBHBggrBgEFBQcwAoY7aHR0cDovL2NkcDEucGNhLmRmbi5k ZS9nbG9iYWwtcm9vdC1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwRwYIKwYBBQUHMAKGO2h0dHA6 Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MA0G CSqGSIb3DQEBCwUAA4IBAQCo3hebMpEocLPJTOlDMAmSzpxK3SA1ftaQqodbMncOi9WkeICQlmIv rQxGCq8Be/6hKtIrbFOhRtSzQi870glJRj7dhZaHC+WOgT5tP5Nkgwpgl4k4pQDXPPrwmaI6cSYD a/LpprQzBNjEQMdQqkeanpD0WU9U1pOPFIMfIrxh2cy8mBpIAMuZqMHbMyPNDZk/YN4r3b2DcBrQ wL/tHerp6Vc7n9WqO+3cm7Fa4AxL9q2KeItyYe0Cws2KZNz4IuiMjQAclNL0PhTEqIzkD/EiK6Ag 1qcH7o3ktpmakvL2RzSZA71irCfONRgh/+ixfuMu6YA5uzyA8SYfwyFQcABdMIIFPTCCBCWgAwIB AgIHF6/2nVZL/jANBgkqhkiG9w0BAQsFADBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZOLVZl cmVpbjEQMA4GA1UECxMHREZOLVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xvYmFsIC0g RzAxMB4XDTE0MDYwNTE0MDUwMloXDTE5MDcwOTIzNTkwMFowaTELMAkGA1UEBhMCREUxLjAsBgNV BAoTJVBoeXNpa2FsaXNjaC1UZWNobmlzY2hlIEJ1bmRlc2Fuc3RhbHQxDzANBgNVBAMTBlBUQiBD QTEZMBcGCSqGSIb3DQEJARYKcGtpQHB0Yi5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALwKwoM5KsNizAGLlN/FSU4MhgQvj6frr8Odi5rSOjBDIha9MWOkhM2HAxt8+TUqIWYrHZy+ 27vBHuzBQ902V9Y1QYnv/1DQCal2x51MxPIWyWAkecnW/VqiM6E+T8xtO6iVm5W4nXK2VXAkBHn/ VdQmkcn17qokkzoIm6jgyz/fDe4zCCJs9oqVIDHaBsjoEof6nbOUjOglIMDHrieNkKWDaLfa4tSC gMHsoSCGt0wDbLuerHMvhXNvl1jn7LiJnni3GoruhyT5Ol+eUE/pFmgKEH+qiciV7/G/5+pdZ5ky FNgGNgeRJzv6yE/g1vjCcu+/xzvu67cGs57p7VzIMrcCAwEAAaOCAfcwggHzMBIGA1UdEwEB/wQI MAYBAf8CAQEwDgYDVR0PAQH/BAQDAgEGMBEGA1UdIAQKMAgwBgYEVR0gADAdBgNVHQ4EFgQUxIDQ bigVaDFa7HBfeI7hMEM46jQwHwYDVR0jBBgwFoAUSbfGz+g9H3/qRHsTKffxCnA+3mQwFQYDVR0R BA4wDIEKcGtpQHB0Yi5kZTCBiAYDVR0fBIGAMH4wPaA7oDmGN2h0dHA6Ly9jZHAxLnBjYS5kZm4u ZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NybC9jYWNybC5jcmwwPaA7oDmGN2h0dHA6Ly9jZHAyLnBj YS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NybC9jYWNybC5jcmwwgdcGCCsGAQUFBwEBBIHK MIHHMDMGCCsGAQUFBzABhidodHRwOi8vb2NzcC5wY2EuZGZuLmRlL09DU1AtU2VydmVyL09DU1Aw RwYIKwYBBQUHMAKGO2h0dHA6Ly9jZHAxLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2Nh Y2VydC9jYWNlcnQuY3J0MEcGCCsGAQUFBzAChjtodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2dsb2Jh bC1yb290LWNhL3B1Yi9jYWNlcnQvY2FjZXJ0LmNydDANBgkqhkiG9w0BAQsFAAOCAQEAqN4XmzKR KHCzyUzpQzAJks6cSt0gNX7WkKqHWzJ3DovVpHiAkJZiL60MRgqvAXv+oSrSK2xToUbUs0IvO9IJ SUY+3YWWhwvljoE+bT+TZIMKYJeJOKUA1zz68JmiOnEmA2vy6aa0MwTYxEDHUKpHmp6Q9FlPVNaT jxSDHyK8YdnMvJgaSADLmajB2zMjzQ2ZP2DeK929g3Aa0MC/7R3q6elXO5/Vqjvt3JuxWuAMS/at iniLcmHtAsLNimTc+CLojI0AHJTS9D4UxKiM5A/xIiugINanB+6N5LaZmpLy9kc0mQO9YqwnzjUY If/osX7jLumAObs8gPEmH8MhUHAAXTCCBaIwggSKoAMCAQICDBxmO6qdufc5yhZ6iDANBgkqhkiG 9w0BAQsFADBpMQswCQYDVQQGEwJERTEuMCwGA1UEChMlUGh5c2lrYWxpc2NoLVRlY2huaXNjaGUg QnVuZGVzYW5zdGFsdDEPMA0GA1UEAxMGUFRCIENBMRkwFwYJKoZIhvcNAQkBFgpwa2lAcHRiLmRl MB4XDTE2MTIwNjEzMzMxNFoXDTE5MDcwOTIzNTkwMFowaDELMAkGA1UEBhMCREUxLjAsBgNVBAoM JVBoeXNpa2FsaXNjaC1UZWNobmlzY2hlIEJ1bmRlc2Fuc3RhbHQxDTALBgNVBAsMBFEuNDIxGjAY BgNVBAMMEURyLiBEaWV0ZXIgU2lib2xkMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA +AOQrmrEQ2k8s9su/TVvmdF46YbL2MuF6OvnrjjKaJIkBvchop87cCwv80aZEbmU3as54egQEMGn NFkp1fF4bics4TJdEpND116l+jbi5DCtA3hHP/spV1aQZBDc/BDkm1Nl5WYKh/DxN6sUhZxorbb4 Y0nmSxnK2ctIwuF4Qdibsw7GE2YLvWF4tlzSCGbDjSy2agSn1wYHMsC+tAcFflcMXF2sDMZHkYuq 5IHwng8GBQFhsldYl1fk2sB2/hVRLYU205qaj13H94WjfDLuB22sT17XPJ2U/9tuFN/sxAPR0/N4 y4/IgMnOaP30VU0FMmULd7qJg0WST5D5kwgMhwIDAQABo4ICSTCCAkUwQAYDVR0gBDkwNzARBg8r BgEEAYGtIYIsAQEEAwUwEQYPKwYBBAGBrSGCLAIBBAMBMA8GDSsGAQQBga0hgiwBAQQwCQYDVR0T BAIwADAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1Ud DgQWBBQHn42zKDpvJi1bsJ4OVk2A9liUFjAfBgNVHSMEGDAWgBTEgNBuKBVoMVrscF94juEwQzjq NDBEBgNVHREEPTA7gRRkaWV0ZXIuc2lib2xkQHB0Yi5kZaAjBgorBgEEAYI3FAIDoBUME3NpYm9s ZDAxQHBhZC5wdGIuZGUwdwYDVR0fBHAwbjA1oDOgMYYvaHR0cDovL2NkcDEucGNhLmRmbi5kZS9w dGItY2EvcHViL2NybC9jYWNybC5jcmwwNaAzoDGGL2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvcHRi LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIHHBggrBgEFBQcBAQSBujCBtzAzBggrBgEFBQcwAYYnaHR0 cDovL29jc3AucGNhLmRmbi5kZS9PQ1NQLVNlcnZlci9PQ1NQMD8GCCsGAQUFBzAChjNodHRwOi8v Y2RwMS5wY2EuZGZuLmRlL3B0Yi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwPwYIKwYBBQUHMAKG M2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvcHRiLWNhL3B1Yi9jYWNlcnQvY2FjZXJ0LmNydDANBgkq hkiG9w0BAQsFAAOCAQEADaSfgrrQZx9eiQrCK7kgJMpLstro5OgIcWSpW4i4AQ1wEwyDUrdB1XWK GjA8/KwExSBP9a+dcdW+ACjX7TyURQPLqRTOkoPc9dafRx327mV4K8PE8z7fg5l2ittYNs0nXlOB QevRbYYP4XUOMYohFWfHpDwEg3ExmoArb2HaQCzKhq/2VcIIXTwaN6AVr2NVKEuH3qwpgOUSlJJ1 5ORb6TD4p1G2W6XT3jk3tOa8nRaOkI5hqpPvLfbPEibn+Bfqm6GWqpXfQ6NLAvWYcI8ltSKgdnCw Rmqdh1Ba/KWGdm41PDtQIx58vgbZGfN5GKJrp+OwS5D+/e/r296qoKUBRDCCBaIwggSKoAMCAQIC DBxmO6qdufc5yhZ6iDANBgkqhkiG9w0BAQsFADBpMQswCQYDVQQGEwJERTEuMCwGA1UEChMlUGh5 c2lrYWxpc2NoLVRlY2huaXNjaGUgQnVuZGVzYW5zdGFsdDEPMA0GA1UEAxMGUFRCIENBMRkwFwYJ KoZIhvcNAQkBFgpwa2lAcHRiLmRlMB4XDTE2MTIwNjEzMzMxNFoXDTE5MDcwOTIzNTkwMFowaDEL MAkGA1UEBhMCREUxLjAsBgNVBAoMJVBoeXNpa2FsaXNjaC1UZWNobmlzY2hlIEJ1bmRlc2Fuc3Rh bHQxDTALBgNVBAsMBFEuNDIxGjAYBgNVBAMMEURyLiBEaWV0ZXIgU2lib2xkMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA+AOQrmrEQ2k8s9su/TVvmdF46YbL2MuF6OvnrjjKaJIkBvch op87cCwv80aZEbmU3as54egQEMGnNFkp1fF4bics4TJdEpND116l+jbi5DCtA3hHP/spV1aQZBDc /BDkm1Nl5WYKh/DxN6sUhZxorbb4Y0nmSxnK2ctIwuF4Qdibsw7GE2YLvWF4tlzSCGbDjSy2agSn 1wYHMsC+tAcFflcMXF2sDMZHkYuq5IHwng8GBQFhsldYl1fk2sB2/hVRLYU205qaj13H94WjfDLu B22sT17XPJ2U/9tuFN/sxAPR0/N4y4/IgMnOaP30VU0FMmULd7qJg0WST5D5kwgMhwIDAQABo4IC STCCAkUwQAYDVR0gBDkwNzARBg8rBgEEAYGtIYIsAQEEAwUwEQYPKwYBBAGBrSGCLAIBBAMBMA8G DSsGAQQBga0hgiwBAQQwCQYDVR0TBAIwADAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYB BQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQHn42zKDpvJi1bsJ4OVk2A9liUFjAfBgNVHSMEGDAW gBTEgNBuKBVoMVrscF94juEwQzjqNDBEBgNVHREEPTA7gRRkaWV0ZXIuc2lib2xkQHB0Yi5kZaAj BgorBgEEAYI3FAIDoBUME3NpYm9sZDAxQHBhZC5wdGIuZGUwdwYDVR0fBHAwbjA1oDOgMYYvaHR0 cDovL2NkcDEucGNhLmRmbi5kZS9wdGItY2EvcHViL2NybC9jYWNybC5jcmwwNaAzoDGGL2h0dHA6 Ly9jZHAyLnBjYS5kZm4uZGUvcHRiLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIHHBggrBgEFBQcBAQSB ujCBtzAzBggrBgEFBQcwAYYnaHR0cDovL29jc3AucGNhLmRmbi5kZS9PQ1NQLVNlcnZlci9PQ1NQ MD8GCCsGAQUFBzAChjNodHRwOi8vY2RwMS5wY2EuZGZuLmRlL3B0Yi1jYS9wdWIvY2FjZXJ0L2Nh Y2VydC5jcnQwPwYIKwYBBQUHMAKGM2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvcHRiLWNhL3B1Yi9j YWNlcnQvY2FjZXJ0LmNydDANBgkqhkiG9w0BAQsFAAOCAQEADaSfgrrQZx9eiQrCK7kgJMpLstro 5OgIcWSpW4i4AQ1wEwyDUrdB1XWKGjA8/KwExSBP9a+dcdW+ACjX7TyURQPLqRTOkoPc9dafRx32 7mV4K8PE8z7fg5l2ittYNs0nXlOBQevRbYYP4XUOMYohFWfHpDwEg3ExmoArb2HaQCzKhq/2VcII XTwaN6AVr2NVKEuH3qwpgOUSlJJ15ORb6TD4p1G2W6XT3jk3tOa8nRaOkI5hqpPvLfbPEibn+Bfq m6GWqpXfQ6NLAvWYcI8ltSKgdnCwRmqdh1Ba/KWGdm41PDtQIx58vgbZGfN5GKJrp+OwS5D+/e/r 296qoKUBRDGCAuMwggLfAgEBMHkwaTELMAkGA1UEBhMCREUxLjAsBgNVBAoTJVBoeXNpa2FsaXNj aC1UZWNobmlzY2hlIEJ1bmRlc2Fuc3RhbHQxDzANBgNVBAMTBlBUQiBDQTEZMBcGCSqGSIb3DQEJ ARYKcGtpQHB0Yi5kZQIMHGY7qp259znKFnqIMA0GCWCGSAFlAwQCAQUAoIIBOzAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzA4MjIwNzU2MzJaMC8GCSqGSIb3DQEJ BDEiBCA6odwaY6dkfb6ljLxb4TgHjMB2GTwF5Ri4//P+Cxkj6zBDBgkqhkiG9w0BCQ8xNjA0MAcG BSsOAwIdMA4GCCqGSIb3DQMCAgIAgDAKBggqhkiG9w0DBzANBggqhkiG9w0DAgIBKDCBigYLKoZI hvcNAQkQAgsxe6B5MGkxCzAJBgNVBAYTAkRFMS4wLAYDVQQKEyVQaHlzaWthbGlzY2gtVGVjaG5p c2NoZSBCdW5kZXNhbnN0YWx0MQ8wDQYDVQQDEwZQVEIgQ0ExGTAXBgkqhkiG9w0BCQEWCnBraUBw dGIuZGUCDBxmO6qdufc5yhZ6iDANBgkqhkiG9w0BAQEFAASCAQBmqZ5JiuGqPSmqefNGWuvUItqG P5h8UA3WKIRVFVwO6I0N9cA1/QqFxYUaf+G3lGzBtceXYbTJOu9L8RbWkT9UHuv9vIpSm1tbggZs Gfvn0AoLx/7UlaZEX4uddsL89BF920Q2Z69KAtbF6xutL5BrkKzs/ASCgByu8zRH1fij+y0KaNog sDnncZVyHWK6SmWVAB9DSg8yYk81a7cJD3emmWXFCQ0UL3Kg9uccMmyNJsm/fqe0EyHdl2wr2JuY 7uf1rdjdMhIhBJCkR05HG7yDMviut6obBUZ+7uY43rbkkq3QlFl603iRsUXu77m7hKIx5esGd4lI EbfC0Kj+4BVaAAAAAA== ---------z48124_boundary_sign-- --===============5853265590257143769== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp --===============5853265590257143769==-- From ntp-bounces@ietf.org Sun Aug 27 22:05:09 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AD021321EF; Sun, 27 Aug 2017 22:05:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1503896709; bh=xUt7IYuo5uoTAuP2Z8X6eBKVjdPDff4UQIW8n3v8PIw=; h=To:References:From:Date:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe; b=QMoa8WKCVu/ev/kHC21ZBwS7GdvL1VXlnwS9sAXpkM/lXYtR+r4EnFRM5SdcplKlC o/yNsn/EoFKh9PzgEChxZmNuYm/VnMqtAu8FuEZkiNAfmLmWbQeL6TQOekQj92TKq2 LUxmzCWxckmLmFZeQsICSxM75Skdd6Rs0JIv1/Sc= 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 B1DE213218C for ; Sun, 27 Aug 2017 22:05:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 z3qn2ujkupgI for ; Sun, 27 Aug 2017 22:05:05 -0700 (PDT) Received: from chessie.everett.org (chessie.everett.org [IPv6:2001:470:1:205::234]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E9381320DC for ; Sun, 27 Aug 2017 22:05:05 -0700 (PDT) Received: from [10.200.74.153] (nat0.fmt1.everett.org [64.71.190.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by chessie.everett.org (Postfix) with ESMTPSA id 9D537B835; Mon, 28 Aug 2017 05:05:04 +0000 (UTC) To: ntp@ietf.org References: <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> From: Harlan Stenn Message-ID: <47b5b4e3-41c9-6779-4a96-b11650483499@nwtime.org> Date: Sun, 27 Aug 2017 22:05:02 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> Content-Language: en-US Archived-At: Subject: Re: [Ntp] WGLC for draft-ietf-ntp-using-nts-for-ntp X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ntp-bounces@ietf.org Sender: "ntp" I spent 2 hours on the phone on Friday with Dave Mills, discussing this proposal. Here is the "result" of that conversation. Dave: Do not ratify this proposal. It needs more discussion and clarification. The proposal as written should NOT be approved. Harlan: I agree with Dave. TL;DR version: There are some parts of the proposal that are wrong, and some other parts are misleading. There are sections of the proposal that are confusing, and there are sections of the proposal that are inadequately described. Long version: 1.1. Objectives - Confidentiality: Under what conditions is this actually useful? If confidentiality is a need for some, in those situations why not just send the NTP traffic over an encrypted VPN? - Replay prevention: The core NTP specification already has replay prevention. The proposed language is misleading, implying that without NTS there is no replay protection. If the existing core protection against replay is inadequate, please describe the problem(s). You could also say "NTS offers another, additional layer of replay prevention beyond what NTP already provides." - Request-response consistency: The core NTP protocol already has request-response consistency checks, where useful. The proposed language is misleading, implying that without NTS there is no request-response consistency checking. If the existing checks for request-response consistency is inadequate, please describe the problem(s). You could also say "NTS offers another, additional layer of request-response consistency checks beyond what NTP already provides." - Unlinkability: The stated threat seems extraordinarily unlikely to be possible if more than several networks are involved. Even if such a threat was possible and used, if the client/server model for NTS is to use NTP packets with NTS extension fields, an outside observer can still see that there is a client sending requests to a set of servers that some other client has used before. How is that traffic not "linkable"? This "feature" seems to be a red-herring. - Non-amplification: The core problem is DDoS. Amplification is a secondary problem. Sure, the avoidance of amplification is a useful interim step. But the target protocol isn't the place to solve the DDoS problem. DDoS is basically an "overcommit" problem. BCP38, anyone? - Scalability: The way this is phrased is confusing. If this goal is specific to NTS, then it should say so. Given the subsequent discussions about C2S, S2C, etc., it also seems disingenuous. Aside from these things, it seems to be another red-herring. More detail below. 1.2. Protocol Overview "These various modes have different and contradictory requirement for security and performance." This is a naive observation, and is not true. We *always* care about performance and security. Different modes simply use different equations for deciding how to achieve the performance and security goals they require. "... it is harmless for servers to process replayed packets." This may be true as far as the server is concerned, but carried to its extreme this is no different from how a DDoS attack is conducted. But servers are expected to be stateless, and, again, the target protocol isn't the place to solve the DDoS problem. "In order to simultaneously serve these *conflicting* requirements..." Again, the requirements are not conflicting, they're just different, based on the use-case. "... NTS is structured as a suite of three protocols:" It should be noted that other methods to accomplish these goals are possible, and that what is subsequently described is *one* way that is expected to satisfy the requirements. - DTLS-encapsulated NTPv4: No mention is made of the fact that this method will increase timing jitter, and degrade the quality of timekeeping. This is especially troublesome given that peer mode is mostly used for groups of lower-stratum servers offering time to many clients. - NTS Extensions for NTPv4: Should this be "NTS Extension Fields for NTPv4"? Is the comment about the server not needing state correct? No subsequent discussion is provided to support this. Several paragraphs into "6.7. Protocol Details" we see "Upon receiving an NTS-protected request, the server SHALL (through some implementation-defined mechanism) use the cookie to recover the AEAD Algorithm, C2S key, and S2C key associated with the request, ..." but says nothing more about this. Please offer even one description of how this can be done, efficiently if possible, without the server retaining state. This paragraph then goes on to talk about how the proposed NTF Extension Fields are (only) "suitable for securing client/server ...". Is "suitable" the right word in this sentence? How about "needed", "appropriate", or "used", or "useful"? The paragraph again mentions "the server can implement them without retaining per-client state" and then says the NTF EFs are "suitable *only* for client/server mode because only the client, and not the server, is protected from replay." This section has a number of serious problems. One is that NTS is all about securing NTP traffic, but it's confusing when this section passively describes client/server traffic. This seems to be true, since symmetric mode is expected to be protected via DTLS and not NTS-EFs. We think it would be more clear to actively describe how NTS protects the different modes of NTP. I.e., a section describing all the steps by which NTS protects symmetric mode (active/active is really no different from active/passive for this situation), then all the steps for client/server, then how NTS does not (yet) have a solution for broadcast mode, and, finally, NTS for mode 6/7. The paragraph continues the unsubstantiated and dubious claim that the server does not need per-client state. We could again note that NTP broadcast mode is only expected to be used in trusted networks, and that symmetric keys offer authentication in these presumably trusted networks. The core NTP specification already provides authentication functionality for all modes using symmetric keys. Symmetric key protection suffers from not having a built-in means to perform key exchange. There is also an issue with multiple "trust groups", but that problem might be solved with MAC-EFs, where multiple MACs are provided for the different trust groups. If the key exchange problem was solved, the only thing remaining to do is to limit symmetric keys to known IPs, and that is a problem we have already solved. - NTS Key Establishment: Where is NTS-KE actually described? This is hinted at by the reference to RFC7505, but it should be explicitly stated and at least contain a summary description. - "It is intended that NTP implementations will use DTLS-encapsulated NTPv4 to secure symmetric ..." This sentence should appear much earlier in the document. - "As previously stated, DTLS-encapsulated NTPv4 is trivial." Again, please note exactly what mode(s) are using this method, and expressly note that DTLS-encapsulated NTP traffic will show more timing jitter and be less accurate than normal NTPv4 UDP traffic. While interleave mode was inadvertently left out of RFC5905, it is likely the best way to attempt to mitigate the jitter problems created by DTLS-encapsulated NTPv4. However, it is not yet clear that there is any way to easily capture the packet receive or transmit timestamps in a DTLS-encapsulated transport. - "The typical protocol flow for client/server mode is as follows. ..." Where is the process to generate the shared key described? Please see Dave's recent Autokey paper, Section 8, for the level of detail we're looking for here. What are the details on the "supply of cookies"? - "Time synchronization proceeds ... Included among these fields are ..." How? Please provide details. Describe how to recover from a dropped packet (or few). "The server uses the cookie to recover this key material (previously discarded) ...". How? Details, please. Assuming this can be done without saving state, how expensive is it? - 4. The NTS-encapsulated NTPv4 protocol. This is new language. Was "DTLS-encapsulated NTPv4 protocol" meant instead? What port will be used? - "The NTS-encapsulated NTPv4 protocol is the RECOMMENDED ...": Again, should this be "DTLS-encapsulated"? Also there is no mention of the degradation of the NTP protocol because of the increased jitter caused by the DTLS encapsulation. - "Since DTLS-encapsulated ...": Again, no mention of the performance degradation. - "For symmetric operation ...": There are two paragraphs which discuss this. Dave expressly disagrees with the first paragraph. The differences between active/active and active/passive in this situation would seem to be spurious. Why are they called out? What difference does it make which side it the DTLS server and which side is the DTLS client? A protocol restart in this case could easily cause the roles to reverse. As for the situation where both sides create DTLS sessions, how can this possibly happen? There should be a single association between the two parties, and the implementation can be expected to prevent this from happening. See Section 8 of Dave's recent Autokey paper for how Dave would implement this. - "If, likely as a result of user error, ...": how about "configuration error" oe "user configuration error" instead of "user error"? It's "symmetric active", not "symmetry active". In any event, this situation is no different from one side sending a mode 1 (active) packet, and getting back a mode 4 (server) response. Except that NTS recommends DTLS encapsulation for symmetric servers, and recommends against DTLS encapsulation for client/server mode. - 6. NTS Extensions for NTPv4: If you're talking about NTP extension fields, please call them extension fields. - 6.1. Key Extraction: When does NTS-KE mean "key establishment" and when does KE mean "key extraction"? Please more clearly identify when talking about TLS exchanges over the TCP port, and when talking about extension fields in a UDP NTP packet. - 6.2. Packet structure overview - "Possibly, some additional extensions which are neither encrypted nor authenticated. >These are discarded by the receiver.<" The part about discarding EFs after the NTS packet seems wrong - it's over-reach. - "The purpose of the unique-identifier extension is to protect the client from replay attacks.": Again, this is *additional* replay prevention, beyond the existing prevention offered in the base protocol. - 6.3. The Unique Identifier extension: This is an NTP/NTS extension field, right? If so, please use the normal language. This should not use a new EF, it should use the proposed NTS EF Field Type of (recommended value) 4, with a sub-code of [TBD], perhaps suggesting 1. - 6.4. The NTS Cookie extension: Ditto - EF type 4, sub-code of [TBD], perhaps suggesting 2. - 6.5. The NTS Cookie Placeholder extension: Ditto - EF type 4, sub-code of [TBD], perhaps suggesting 3. - 6.6. The NTS Authenticator and Encrypted Extensions extension: Ditto, it's an "Extension Field", not an "extension", and it should be EF type 4, sub-code of [TBD], perhaps suggesting 4. Should 6.2. be: 6.2. Packet structure overview and then use: 6.3. NTS Extension Field and Sub-Codes The NTS Extension Field uses a Field Type of [TBD] (recommendation to IANA: 4), with the following sub-codes: 6.3.1. The Unique Identifier Sub-Code 6.3.2. The Cookie Extension Sub-Code 6.3.3. The Cookie Placeholder Extension Sub-Code 6.3.4. The Authenticator and Encrypted Extensions Sub-Code Please note that I might have mis-named sub-code - the RFC I've proposed to address this isn't handy. When specifying EF types and sub-codes, please note which top-level bits (R/E/O/I) are expected. - 6.7. Protocol details - "Upon receiving an NTS-protected request, the server SHALL (thru some implementation-defined mechanism) use the cookie to recover ...": First, "NTS-protected request" is not quite right - this only applies to the NTS EFs, correct, as they're the only ones that use an NTS-generated MAC, right? No MAC protection is suggested for DTLS-encapsulated NTPv4, correct? Next, as previously mentioned, please provide details on how an implementation would accomplish this without saving state on a per-client basis. Also describe any computational or storage costs. - "... C2S key, and S2C key ...": What do separate keys offer us that 1 key doesn't? - "... the server SHALL include the following extensions in its response:": First, "extensions" should be "Extension Fields", right? The list of EFs that are included does not explicitly say where the MAC lives. One would *assume* the MAC lives in or after the last NTS Cookie Extension Field, but it doesn't say this. Also NTS Cookie EFs must be authenticated *and* encrypted. If the MAC lives in the last NTS Cookie EF, is the MAC encrypted? The answer to that last question MUST be "no", in which case there seems to be a need for the MAC to live as either a legacy MAC, or in a MAC-EF, after the last NTS Cookie EF. - "The server MAY include additional (non-NTS-related) ...": Please explain and justify. This seems like massive over-reach, and should not be "controlled" by the NTS specification. - "In general, however, the client MUST discard any unauthenticated extensions and process the packet as though they were not present.": Please explain and justify. This seems like massive over-reach, and should not be "controlled" by the NTS specification. - "If the server is unable to validate, ... KoD ...": This is overloading/mis-using KoD. What is wrong with the crypto-NAK for this purpose? - "Upon receiving an NTS-protected response, ...": Again, NTS does both client/server and peer mode exchanges. This section seems to only need to concern itself with client/server. Furthermore, the sentence would be more accurate if it was: "After passing the NTP base-packet checks, a packet protected by NTS Extension Fields MUST verify that the ..." - 8. IANA Considerations - Port Number: [[TBD1]]: why not use TCP/123? If this is done, please clearly demonstrate that the protocol will allow additional uses on this port, as we'd like to eventually use TCP/123 for monitoring and control purposes, too. - [[TBD2]]-[[TBD5]]: see earlier discussion. We want a single NTS Extension Field (type 4 is suggested), with sub-codes for the specific subfield types. Please better identify in the IANA considerations when you're asking about EF codes v. TLS codes. - 9.1. Avoiding DDoS amplification: We discussed this above, and I won't repeat that here. I will again repeat that the core issue is DDoS, and the secondary issue is amplification. - 9.2. NTP is designed to come up from a position of zero access to any network resources, and as network resources become available, NTP will evaluate these resources. In particular, DNS cannot be trusted before time is trusted, and most 3rd-party certificates cannot be trusted until after time is trusted. Dave's recent Autokey paper discusses these issues as well, and a thorough comparison of the requirements and assertions of the Autokey and NTS documents should be performed. - 9.3. Usage of NTP pools - "... Pools in existence as of 2017 are volunteer-run, with minimal requirements for admission and no organized effort to monitor pool servers for misbehavior. ..." Really? Where did you get this "information"? - 10.1. Unlinkability. This would seem to be a red-herring. Beyond that, see the comments under 1.1. - 10.2. Confidentiality. Please. What client-confidential information exists in a normal NTP header that is not able to be adequately protected right now? Using SNTP wueries with minimal data fields one already gets all of the protections described in ntp-data-minimization. The point about "Future extension fields could hypothetically contain sensitive information" seems implausible. Have any such possibilities >that are appropriate for an NTP Extension Field< packet even been considered? But assuming there is a way to tell NTS to send this information encrypted, that would mean that the peer-mode DTLS connection would have to provide encryption, and the client/server NTS EF would have to provide an API, which has not been described here, to contain this encrypted information. -- Harlan Stenn http://networktimefoundation.org - be a member! _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp From nobody Sun Aug 27 22:05:09 2017 Return-Path: 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 B1DE213218C for ; Sun, 27 Aug 2017 22:05:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 z3qn2ujkupgI for ; Sun, 27 Aug 2017 22:05:05 -0700 (PDT) Received: from chessie.everett.org (chessie.everett.org [IPv6:2001:470:1:205::234]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E9381320DC for ; Sun, 27 Aug 2017 22:05:05 -0700 (PDT) Received: from [10.200.74.153] (nat0.fmt1.everett.org [64.71.190.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by chessie.everett.org (Postfix) with ESMTPSA id 9D537B835; Mon, 28 Aug 2017 05:05:04 +0000 (UTC) To: ntp@ietf.org References: <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> From: Harlan Stenn Message-ID: <47b5b4e3-41c9-6779-4a96-b11650483499@nwtime.org> Date: Sun, 27 Aug 2017 22:05:02 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ntp] WGLC for draft-ietf-ntp-using-nts-for-ntp X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Aug 2017 05:05:07 -0000 I spent 2 hours on the phone on Friday with Dave Mills, discussing this proposal. Here is the "result" of that conversation. Dave: Do not ratify this proposal. It needs more discussion and clarification. The proposal as written should NOT be approved. Harlan: I agree with Dave. TL;DR version: There are some parts of the proposal that are wrong, and some other parts are misleading. There are sections of the proposal that are confusing, and there are sections of the proposal that are inadequately described. Long version: 1.1. Objectives - Confidentiality: Under what conditions is this actually useful? If confidentiality is a need for some, in those situations why not just send the NTP traffic over an encrypted VPN? - Replay prevention: The core NTP specification already has replay prevention. The proposed language is misleading, implying that without NTS there is no replay protection. If the existing core protection against replay is inadequate, please describe the problem(s). You could also say "NTS offers another, additional layer of replay prevention beyond what NTP already provides." - Request-response consistency: The core NTP protocol already has request-response consistency checks, where useful. The proposed language is misleading, implying that without NTS there is no request-response consistency checking. If the existing checks for request-response consistency is inadequate, please describe the problem(s). You could also say "NTS offers another, additional layer of request-response consistency checks beyond what NTP already provides." - Unlinkability: The stated threat seems extraordinarily unlikely to be possible if more than several networks are involved. Even if such a threat was possible and used, if the client/server model for NTS is to use NTP packets with NTS extension fields, an outside observer can still see that there is a client sending requests to a set of servers that some other client has used before. How is that traffic not "linkable"? This "feature" seems to be a red-herring. - Non-amplification: The core problem is DDoS. Amplification is a secondary problem. Sure, the avoidance of amplification is a useful interim step. But the target protocol isn't the place to solve the DDoS problem. DDoS is basically an "overcommit" problem. BCP38, anyone? - Scalability: The way this is phrased is confusing. If this goal is specific to NTS, then it should say so. Given the subsequent discussions about C2S, S2C, etc., it also seems disingenuous. Aside from these things, it seems to be another red-herring. More detail below. 1.2. Protocol Overview "These various modes have different and contradictory requirement for security and performance." This is a naive observation, and is not true. We *always* care about performance and security. Different modes simply use different equations for deciding how to achieve the performance and security goals they require. "... it is harmless for servers to process replayed packets." This may be true as far as the server is concerned, but carried to its extreme this is no different from how a DDoS attack is conducted. But servers are expected to be stateless, and, again, the target protocol isn't the place to solve the DDoS problem. "In order to simultaneously serve these *conflicting* requirements..." Again, the requirements are not conflicting, they're just different, based on the use-case. "... NTS is structured as a suite of three protocols:" It should be noted that other methods to accomplish these goals are possible, and that what is subsequently described is *one* way that is expected to satisfy the requirements. - DTLS-encapsulated NTPv4: No mention is made of the fact that this method will increase timing jitter, and degrade the quality of timekeeping. This is especially troublesome given that peer mode is mostly used for groups of lower-stratum servers offering time to many clients. - NTS Extensions for NTPv4: Should this be "NTS Extension Fields for NTPv4"? Is the comment about the server not needing state correct? No subsequent discussion is provided to support this. Several paragraphs into "6.7. Protocol Details" we see "Upon receiving an NTS-protected request, the server SHALL (through some implementation-defined mechanism) use the cookie to recover the AEAD Algorithm, C2S key, and S2C key associated with the request, ..." but says nothing more about this. Please offer even one description of how this can be done, efficiently if possible, without the server retaining state. This paragraph then goes on to talk about how the proposed NTF Extension Fields are (only) "suitable for securing client/server ...". Is "suitable" the right word in this sentence? How about "needed", "appropriate", or "used", or "useful"? The paragraph again mentions "the server can implement them without retaining per-client state" and then says the NTF EFs are "suitable *only* for client/server mode because only the client, and not the server, is protected from replay." This section has a number of serious problems. One is that NTS is all about securing NTP traffic, but it's confusing when this section passively describes client/server traffic. This seems to be true, since symmetric mode is expected to be protected via DTLS and not NTS-EFs. We think it would be more clear to actively describe how NTS protects the different modes of NTP. I.e., a section describing all the steps by which NTS protects symmetric mode (active/active is really no different from active/passive for this situation), then all the steps for client/server, then how NTS does not (yet) have a solution for broadcast mode, and, finally, NTS for mode 6/7. The paragraph continues the unsubstantiated and dubious claim that the server does not need per-client state. We could again note that NTP broadcast mode is only expected to be used in trusted networks, and that symmetric keys offer authentication in these presumably trusted networks. The core NTP specification already provides authentication functionality for all modes using symmetric keys. Symmetric key protection suffers from not having a built-in means to perform key exchange. There is also an issue with multiple "trust groups", but that problem might be solved with MAC-EFs, where multiple MACs are provided for the different trust groups. If the key exchange problem was solved, the only thing remaining to do is to limit symmetric keys to known IPs, and that is a problem we have already solved. - NTS Key Establishment: Where is NTS-KE actually described? This is hinted at by the reference to RFC7505, but it should be explicitly stated and at least contain a summary description. - "It is intended that NTP implementations will use DTLS-encapsulated NTPv4 to secure symmetric ..." This sentence should appear much earlier in the document. - "As previously stated, DTLS-encapsulated NTPv4 is trivial." Again, please note exactly what mode(s) are using this method, and expressly note that DTLS-encapsulated NTP traffic will show more timing jitter and be less accurate than normal NTPv4 UDP traffic. While interleave mode was inadvertently left out of RFC5905, it is likely the best way to attempt to mitigate the jitter problems created by DTLS-encapsulated NTPv4. However, it is not yet clear that there is any way to easily capture the packet receive or transmit timestamps in a DTLS-encapsulated transport. - "The typical protocol flow for client/server mode is as follows. ..." Where is the process to generate the shared key described? Please see Dave's recent Autokey paper, Section 8, for the level of detail we're looking for here. What are the details on the "supply of cookies"? - "Time synchronization proceeds ... Included among these fields are ..." How? Please provide details. Describe how to recover from a dropped packet (or few). "The server uses the cookie to recover this key material (previously discarded) ...". How? Details, please. Assuming this can be done without saving state, how expensive is it? - 4. The NTS-encapsulated NTPv4 protocol. This is new language. Was "DTLS-encapsulated NTPv4 protocol" meant instead? What port will be used? - "The NTS-encapsulated NTPv4 protocol is the RECOMMENDED ...": Again, should this be "DTLS-encapsulated"? Also there is no mention of the degradation of the NTP protocol because of the increased jitter caused by the DTLS encapsulation. - "Since DTLS-encapsulated ...": Again, no mention of the performance degradation. - "For symmetric operation ...": There are two paragraphs which discuss this. Dave expressly disagrees with the first paragraph. The differences between active/active and active/passive in this situation would seem to be spurious. Why are they called out? What difference does it make which side it the DTLS server and which side is the DTLS client? A protocol restart in this case could easily cause the roles to reverse. As for the situation where both sides create DTLS sessions, how can this possibly happen? There should be a single association between the two parties, and the implementation can be expected to prevent this from happening. See Section 8 of Dave's recent Autokey paper for how Dave would implement this. - "If, likely as a result of user error, ...": how about "configuration error" oe "user configuration error" instead of "user error"? It's "symmetric active", not "symmetry active". In any event, this situation is no different from one side sending a mode 1 (active) packet, and getting back a mode 4 (server) response. Except that NTS recommends DTLS encapsulation for symmetric servers, and recommends against DTLS encapsulation for client/server mode. - 6. NTS Extensions for NTPv4: If you're talking about NTP extension fields, please call them extension fields. - 6.1. Key Extraction: When does NTS-KE mean "key establishment" and when does KE mean "key extraction"? Please more clearly identify when talking about TLS exchanges over the TCP port, and when talking about extension fields in a UDP NTP packet. - 6.2. Packet structure overview - "Possibly, some additional extensions which are neither encrypted nor authenticated. >These are discarded by the receiver.<" The part about discarding EFs after the NTS packet seems wrong - it's over-reach. - "The purpose of the unique-identifier extension is to protect the client from replay attacks.": Again, this is *additional* replay prevention, beyond the existing prevention offered in the base protocol. - 6.3. The Unique Identifier extension: This is an NTP/NTS extension field, right? If so, please use the normal language. This should not use a new EF, it should use the proposed NTS EF Field Type of (recommended value) 4, with a sub-code of [TBD], perhaps suggesting 1. - 6.4. The NTS Cookie extension: Ditto - EF type 4, sub-code of [TBD], perhaps suggesting 2. - 6.5. The NTS Cookie Placeholder extension: Ditto - EF type 4, sub-code of [TBD], perhaps suggesting 3. - 6.6. The NTS Authenticator and Encrypted Extensions extension: Ditto, it's an "Extension Field", not an "extension", and it should be EF type 4, sub-code of [TBD], perhaps suggesting 4. Should 6.2. be: 6.2. Packet structure overview and then use: 6.3. NTS Extension Field and Sub-Codes The NTS Extension Field uses a Field Type of [TBD] (recommendation to IANA: 4), with the following sub-codes: 6.3.1. The Unique Identifier Sub-Code 6.3.2. The Cookie Extension Sub-Code 6.3.3. The Cookie Placeholder Extension Sub-Code 6.3.4. The Authenticator and Encrypted Extensions Sub-Code Please note that I might have mis-named sub-code - the RFC I've proposed to address this isn't handy. When specifying EF types and sub-codes, please note which top-level bits (R/E/O/I) are expected. - 6.7. Protocol details - "Upon receiving an NTS-protected request, the server SHALL (thru some implementation-defined mechanism) use the cookie to recover ...": First, "NTS-protected request" is not quite right - this only applies to the NTS EFs, correct, as they're the only ones that use an NTS-generated MAC, right? No MAC protection is suggested for DTLS-encapsulated NTPv4, correct? Next, as previously mentioned, please provide details on how an implementation would accomplish this without saving state on a per-client basis. Also describe any computational or storage costs. - "... C2S key, and S2C key ...": What do separate keys offer us that 1 key doesn't? - "... the server SHALL include the following extensions in its response:": First, "extensions" should be "Extension Fields", right? The list of EFs that are included does not explicitly say where the MAC lives. One would *assume* the MAC lives in or after the last NTS Cookie Extension Field, but it doesn't say this. Also NTS Cookie EFs must be authenticated *and* encrypted. If the MAC lives in the last NTS Cookie EF, is the MAC encrypted? The answer to that last question MUST be "no", in which case there seems to be a need for the MAC to live as either a legacy MAC, or in a MAC-EF, after the last NTS Cookie EF. - "The server MAY include additional (non-NTS-related) ...": Please explain and justify. This seems like massive over-reach, and should not be "controlled" by the NTS specification. - "In general, however, the client MUST discard any unauthenticated extensions and process the packet as though they were not present.": Please explain and justify. This seems like massive over-reach, and should not be "controlled" by the NTS specification. - "If the server is unable to validate, ... KoD ...": This is overloading/mis-using KoD. What is wrong with the crypto-NAK for this purpose? - "Upon receiving an NTS-protected response, ...": Again, NTS does both client/server and peer mode exchanges. This section seems to only need to concern itself with client/server. Furthermore, the sentence would be more accurate if it was: "After passing the NTP base-packet checks, a packet protected by NTS Extension Fields MUST verify that the ..." - 8. IANA Considerations - Port Number: [[TBD1]]: why not use TCP/123? If this is done, please clearly demonstrate that the protocol will allow additional uses on this port, as we'd like to eventually use TCP/123 for monitoring and control purposes, too. - [[TBD2]]-[[TBD5]]: see earlier discussion. We want a single NTS Extension Field (type 4 is suggested), with sub-codes for the specific subfield types. Please better identify in the IANA considerations when you're asking about EF codes v. TLS codes. - 9.1. Avoiding DDoS amplification: We discussed this above, and I won't repeat that here. I will again repeat that the core issue is DDoS, and the secondary issue is amplification. - 9.2. NTP is designed to come up from a position of zero access to any network resources, and as network resources become available, NTP will evaluate these resources. In particular, DNS cannot be trusted before time is trusted, and most 3rd-party certificates cannot be trusted until after time is trusted. Dave's recent Autokey paper discusses these issues as well, and a thorough comparison of the requirements and assertions of the Autokey and NTS documents should be performed. - 9.3. Usage of NTP pools - "... Pools in existence as of 2017 are volunteer-run, with minimal requirements for admission and no organized effort to monitor pool servers for misbehavior. ..." Really? Where did you get this "information"? - 10.1. Unlinkability. This would seem to be a red-herring. Beyond that, see the comments under 1.1. - 10.2. Confidentiality. Please. What client-confidential information exists in a normal NTP header that is not able to be adequately protected right now? Using SNTP wueries with minimal data fields one already gets all of the protections described in ntp-data-minimization. The point about "Future extension fields could hypothetically contain sensitive information" seems implausible. Have any such possibilities >that are appropriate for an NTP Extension Field< packet even been considered? But assuming there is a way to tell NTS to send this information encrypted, that would mean that the peer-mode DTLS connection would have to provide encryption, and the client/server NTS EF would have to provide an API, which has not been described here, to contain this encrypted information. -- Harlan Stenn http://networktimefoundation.org - be a member! From nobody Mon Aug 28 14:01:21 2017 Return-Path: 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 48DE5132983 for ; Mon, 28 Aug 2017 14:01:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 SCJfEBXLfNeq for ; Mon, 28 Aug 2017 14:01:16 -0700 (PDT) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (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 BDBED126BF0 for ; Mon, 28 Aug 2017 14:01:15 -0700 (PDT) Received: by mail-qt0-x22a.google.com with SMTP id w42so7504749qtg.5 for ; Mon, 28 Aug 2017 14:01:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=cItUn4wTod+d3P82lwfceYuzbhfEyTuKDWGzE7/4q3Y=; b=EUfuhVmGMshkxo613gKcqophZz8eTVPtsfe4ZP3gpQ4L6bRrAzPKlnLQMGhkgRv3nc kkRs+N5CGCMLOXIj7JxZrdxSSXRCySyYxrjQq3N/mZ6aIU4Jr1/799YU1weh5QSG2lG+ fxi/cT4E+7+7FJFie+j/VBtnTE4Mmrm/T/4YKjV+i0o+wRDVz3vyZOlA/+xa9XOFKi0P NymzqH+dECHdwT+KvNK5aDXrYXcOKfHWAg4KYiAoGVf68llFmKZOh6WX8yJeHPFVpE8v H9+GcNc3zRjZdmnLjXxy5ivDkkksG7D8RbDD3j+wWiO1gpe4B8P44WVktH1RYhLfqe5I yBdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=cItUn4wTod+d3P82lwfceYuzbhfEyTuKDWGzE7/4q3Y=; b=l7LlytzdZCGhd5xGppRxMCvEDnY8pB5XOZ2QDG12aGJIPv8fpZZ5wDf2DacXeyhxW5 VFBpMQc4FgWWDCzX+ZBQwWezO4oYSbegh3itM1HzbyvplbVYCyNNm1PWR4ZO7KGiF/h2 7LsE8DsqyaMEPXa4o0CyKnLflHr5q3QV0Br/gLxruYRY7/fyHVL8qdphJEeazeOaiX5U 9AxEoSnbwWP5znF2eMtvZ6creCOPK7sLrPdjYEjM/KK8vzAPE8QedrFe+zu0ExOWaiMj VVP+cgw+7hPpT00egOM85pUqTe2p4M6B9F/G/FxcDBugZP0L37CpdqDkIxF57s9Iw2fv GKow== X-Gm-Message-State: AHYfb5i3stowkWqdo3qetHuDsJWEFYw7A6MvlYqNnaqTqZ3JM4txcdYM RaZRCFlCG5GcBtMaAB6ROsA3NY8ZpsK5 X-Received: by 10.80.159.138 with SMTP id c10mr1552739edf.257.1503954066024; Mon, 28 Aug 2017 14:01:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.157.140 with HTTP; Mon, 28 Aug 2017 14:01:04 -0700 (PDT) In-Reply-To: <47b5b4e3-41c9-6779-4a96-b11650483499@nwtime.org> References: <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> <47b5b4e3-41c9-6779-4a96-b11650483499@nwtime.org> From: Daniel Franke Date: Mon, 28 Aug 2017 17:01:04 -0400 Message-ID: To: Harlan Stenn Cc: ntp@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Ntp] WGLC for draft-ietf-ntp-using-nts-for-ntp X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Aug 2017 21:01:19 -0000 Responses inline, some paragraphs reordered so I can address them together. On 8/28/17, Harlan Stenn wrote: > I spent 2 hours on the phone on Friday with Dave Mills, discussing this > proposal. Here is the "result" of that conversation. > > Dave: Do not ratify this proposal. It needs more discussion and > clarification. The proposal as written should NOT be approved. > > Harlan: I agree with Dave. > > TL;DR version: > > There are some parts of the proposal that are wrong, and some other > parts are misleading. There are sections of the proposal that are > confusing, and there are sections of the proposal that are inadequately > described. > > Long version: > > 1.1. Objectives > > - Confidentiality: Under what conditions is this actually useful? If > confidentiality is a need for some, in those situations why not just > send the NTP traffic over an encrypted VPN? > > ... > > The point about "Future extension fields could hypothetically contain > sensitive information" seems implausible. Have any such possibilities > >that are appropriate for an NTP Extension Field< packet even been > considered? But assuming there is a way to tell NTS to send this > information encrypted, that would mean that the peer-mode DTLS > connection would have to provide encryption, and the client/server NTS > EF would have to provide an API, which has not been described here, to > contain this encrypted information. Within NTS, the confidentiality scheme is a necessary building block to achieve unlinkability. Where *else* will it be useful? I don't know. We've built a tool; I can't predict every way people will use it. If you want to put confidential information into an extension field, now you can. If this ability never gets used for anything except NTS cookies, then so be it: we've done no work that wasn't already necessary for that case. > What client-confidential information exists in a normal NTP header > that is not able to be adequately protected right now? Using SNTP > wueries with minimal data fields one already gets all of the > protections described in ntp-data-minimization. Is there something here you suppose I disagree with? What's stated in section 10.2 is that NTS doesn't protect the confidentiality of the header, but if you implement data minimization then that's okay because there'll be nothing left there that needs protecting. > - Replay prevention: The core NTP specification already has replay > prevention. The proposed language is misleading, implying that without > NTS there is no replay protection. If the existing core protection > against replay is inadequate, please describe the problem(s). You could > also say "NTS offers another, additional layer of replay prevention > beyond what NTP already provides." > > ... > > - "The purpose of the unique-identifier extension is to protect the > client from replay attacks.": Again, this is *additional* replay > prevention, beyond the existing prevention offered in the base protocol. The existing text here is very terse, I don't think it implies anything one way or the other about existing protections, and I think we should leave it that way since such a discussion is of no use to implementers. But anyway, if it were necessary to opine, my answer would be twofold: 1. As a general matter of good design, a security protocol should be generically secure and not rely on assumptions about the structure of the plaintext it's protecting. That alone should be good enough, but, 2. The 64-bit origin timestamp is not big enough to protect against accidental collision. I could expand, but since, in the data minimization draft, it was over your objection that we recommended even taking full advantage of the bits we've got, I'm certain the explanation would not be to your liking and you'd be happier with the document's present silence on the matter. > - Request-response consistency: The core NTP protocol already has > request-response consistency checks, where useful. The proposed > language is misleading, implying that without NTS there is no > request-response consistency checking. If the existing checks for > request-response consistency is inadequate, please describe the > problem(s). You could also say "NTS offers another, additional layer of > request-response consistency checks beyond what NTP already provides." Request-response consistency comes out of the same set of mechanisms that provide replay protection, so in reply to this I reiterate what I wrote above. > - Unlinkability: The stated threat seems extraordinarily unlikely to be > possible if more than several networks are involved. Even if such a > threat was possible and used, if the client/server model for NTS is to > use NTP packets with NTS extension fields, an outside observer can still > see that there is a client sending requests to a set of servers that > some other client has used before. How is that traffic not "linkable"? > This "feature" seems to be a red-herring. > > ... > > - 10.1. Unlinkability. This would seem to be a red-herring. Beyond > that, see the comments under 1.1. We discussed this last year in Boston. What's written is "For mobile clients, *NTS* will not leak any information which would permit a passive adversary to determine that two packets sent over different networks came from the same client" (emphasis added). Yes, there are aspects of NTP, as well as other things running on most people's systems having nothing at all to do with NTP, which can sabotage this goal. We wrote the data minimization draft to clean up the other NTP-specific bits to the best of our ability. The whole rest of ecosystem is outside this WG's sphere of responsibility, and cleaning it up is going to be long haul for the IETF over decades. Nonetheless, the IETF does seem committed to this goal, and we're doing our small part. > - Non-amplification: The core problem is DDoS. Amplification is a > secondary problem. Sure, the avoidance of amplification is a useful > interim step. But the target protocol isn't the place to solve the > DDoS problem. DDoS is basically an "overcommit" problem. BCP38, anyone? > > ... > > - 9.1. Avoiding DDoS amplification: We discussed this above, and I won't > repeat that here. I will again repeat that the core issue is DDoS, and > the secondary issue is amplification. I don't follow your point. No, of course NTS is not designed to solve DDoS in general, internet-wide. The goal that's written is "implementations [of NTS] may avoid acting as DDoS amplifiers by never responding to a request with a packet larger than the request packet" and that's what the design achieves. > - Scalability: The way this is phrased is confusing. If this goal is > specific to NTS, then it should say so. Given the subsequent > discussions about C2S, S2C, etc., it also seems disingenuous. Aside > from these things, it seems to be another red-herring. More detail below. The text says, "Servers implementations may serve large numbers of clients without having to retain any client-specific state". Given that this is the document specifying NTS, is it not already clear that this means "server implementations of NTS"? See below about statelessness. > 1.2. Protocol Overview > > "These various modes have different and contradictory requirement for > security and performance." This is a naive observation, and is not > true. We *always* care about performance and security. Different modes > simply use different equations for deciding how to achieve the > performance and security goals they require. > > "In order to simultaneously serve these *conflicting* requirements..." > Again, the requirements are not conflicting, they're just different, > based on the use-case. Am I correct in reading this as an objection to word choice and not to substance? The language seems clear to me as it stands, but if you think it can be improved then please propose text. > "... it is harmless for servers to process replayed packets." This may > be true as far as the server is concerned, but carried to its extreme > this is no different from how a DDoS attack is conducted. But servers > are expected to be stateless, and, again, the target protocol isn't the > place to solve the DDoS problem. Replayed packets aren't any more of a contributor to DDoS than fresh ones, so this seems like a strange thing to bring up here. > "... NTS is structured as a suite of three protocols:" It should be > noted that other methods to accomplish these goals are possible, and > that what is subsequently described is *one* way that is expected to > satisfy the requirements. Of course other designs are possible. This is the one, and the only one, that we're proposing as a standard. > - DTLS-encapsulated NTPv4: No mention is made of the fact that this > method will increase timing jitter, and degrade the quality of > timekeeping. This is especially troublesome given that peer mode is > mostly used for groups of lower-stratum servers offering time to many > clients. > [...] > Also there is no mention of the degradation of the NTP protocol > because of the increased jitter caused by the DTLS encapsulation. No mention is made of this because there is no reason or evidence that it would be true. All the necessary cryptographic algorithms can, should, and generally do have constant-time implementations, and their execution time is negligible compared to network latency even over a LAN. > - NTS Extensions for NTPv4: Should this be "NTS Extension Fields for > NTPv4"? Is the comment about the server not needing state correct? No > subsequent discussion is provided to support this. Several paragraphs > into "6.7. Protocol Details" we see "Upon receiving an NTS-protected > request, the server SHALL (through some implementation-defined > mechanism) use the cookie to recover the AEAD Algorithm, C2S key, and > S2C key associated with the request, ..." but says nothing more about > this. Please offer even one description of how this can be done, > efficiently if possible, without the server retaining state. > > ... > > Next, as previously mentioned, please provide details on how > an implementation would accomplish this without saving state on a > per-client basis. Also describe any computational or storage costs. As explained toward the end of the protocol overview section (1.2), server statelessness is enabled through cookies. Section 7, which appears missing from your feedback, explains how. > This paragraph then goes on to talk about how the proposed NTF Extension > Fields are (only) "suitable for securing client/server ...". Is > "suitable" the right word in this sentence? How about "needed", > "appropriate", or "used", or "useful"? I mean "suitable" in the sense of "satisfying all stated objectives". I think it carries that sense better than any of those proposed synonyms. > The paragraph again mentions "the server can implement them without > retaining per-client state" and then says the NTF EFs are "suitable > *only* for client/server mode because only the client, and not the > server, is protected from replay." This section has a number of serious > problems. One is that NTS is all about securing NTP traffic, but it's > confusing when this section passively describes client/server traffic. > This seems to be true, since symmetric mode is expected to be protected > via DTLS and not NTS-EFs. We think it would be more clear to actively > describe how NTS protects the different modes of NTP. I.e., a section > describing all the steps by which NTS protects symmetric mode > (active/active is really no different from active/passive for this > situation), then all the steps for client/server, then how NTS does not > (yet) have a solution for broadcast mode, and, finally, NTS for mode > 6/7. The paragraph continues the unsubstantiated and dubious claim that > the server does not need per-client state. We could again note that NTP > broadcast mode is only expected to be used in trusted networks, and that > symmetric keys offer authentication in these presumably trusted networks. > > The core NTP specification already provides authentication functionality > for all modes using symmetric keys. Symmetric key protection suffers > from not having a built-in means to perform key exchange. There is also > an issue with multiple "trust groups", but that problem might be solved > with MAC-EFs, where multiple MACs are provided for the different trust > groups. If the key exchange problem was solved, the only thing > remaining to do is to limit symmetric keys to known IPs, and that is a > problem we have already solved. > - NTS Key Establishment: Where is NTS-KE actually described? This is > hinted at by the reference to RFC7505, but it should be explicitly > stated and at least contain a summary description. NTS-KE is specified in section 5, which appears missing from your feedback. > - "It is intended that NTP implementations will use DTLS-encapsulated > NTPv4 to secure symmetric ..." This sentence should appear much earlier > in the document. It's already just a few paragraphs into the overview section. How much earlier do you want it? > - "As previously stated, DTLS-encapsulated NTPv4 is trivial." Again, > please note exactly what mode(s) are using this method, and expressly > note that DTLS-encapsulated NTP traffic will show more timing jitter and > be less accurate than normal NTPv4 UDP traffic. While interleave mode > was inadvertently left out of RFC5905, it is likely the best way to > attempt to mitigate the jitter problems created by DTLS-encapsulated > NTPv4. However, it is not yet clear that there is any way to easily > capture the packet receive or transmit timestamps in a DTLS-encapsulated > transport. DTLS doesn't do any flow control or group or split any packets. Getting timestamps for a DTLS packet is literally no different than for any other. > - "The typical protocol flow for client/server mode is as follows. ..." > Where is the process to generate the shared key described? In section 5 and 6.1. > Please see Dave's recent Autokey paper, Section 8, for the level of > detail we're looking for here. What are the details on the "supply > of cookies"? The initial supply is sent as specified in section 5.1.6. Clients manage and refresh their supply as specified in section 6.7. The structure of cookies is described in section 7. > - "Time synchronization proceeds ... Included among these fields are > ..." How? Please provide details. Describe how to recover from a > dropped packet (or few). "The server uses the cookie to recover this > key material (previously discarded) ...". How? Details, please. > Assuming this can be done without saving state, how expensive is it? See section 7. > - 4. The NTS-encapsulated NTPv4 protocol. This is new language. Was > "DTLS-encapsulated NTPv4 protocol" meant instead? What port will be used? > > ... > - "The NTS-encapsulated NTPv4 protocol is the RECOMMENDED ...": Again, > should this be "DTLS-encapsulated"? Aaargh, crud. I swore I fixed these but obviously I didn't. It should say "DTLS-encapsulated" everywhere. "NTS-encapsulated" is a holdover from earlier drafts; we changed it because "DTLS-encapsulated" is clearer and more accurate. I'll fix this properly in the post-WGLC draft. > - "For symmetric operation ...": There are two paragraphs which discuss > this. Dave expressly disagrees with the first paragraph. The > differences between active/active and active/passive in this situation > would seem to be spurious. Why are they called out? What difference > does it make which side it the DTLS server and which side is the DTLS > client? A protocol restart in this case could easily cause the roles to > reverse. As for the situation where both sides create DTLS sessions, > how can this possibly happen? There should be a single association > between the two parties, and the implementation can be expected to > prevent this from happening. See Section 8 of Dave's recent Autokey > paper for how Dave would implement this. I'm not following you here. In the suggested arrangement, any peer configured as active is going to be initiating a DTLS session as a DTLS client, therefore active-active and active-passive configurations will result in different outcomes, and in the active-active case you might end up with two of them. If you have a better recommendation which avoids this, please post text. > - "If, likely as a result of user error, ...": how about "configuration > error" oe "user configuration error" instead of "user error"? It's > "symmetric active", not "symmetry active". You're right, "configuration error" is better. The latter is a typo and I'll fix it in the post-WGLC draft. > In any event, this situation is no different from one side sending a > mode 1 (active) packet, and getting back a mode 4 (server) response. > Except that NTS recommends DTLS encapsulation for symmetric servers, > and recommends against DTLS encapsulation for client/server mode. My reading of RFC 5905 suggests that a mode 4 packet is not a legal response to a mode 1 packet, and your code seems to agree with me. See https://github.com/ntp-project/ntp/blob/stable/ntpd/ntp_peer.c#L25 > - 6. NTS Extensions for NTPv4: If you're talking about NTP extension > fields, please call them extension fields. > > ... > > - "... the server SHALL include the following extensions in its > response:": First, "extensions" should be "Extension Fields", right? No objection to changing section 6 to "NTS Extension Fields for NTPv4" if there's consensus for this. > - 6.1. Key Extraction: When does NTS-KE mean "key establishment" and > when does KE mean "key extraction"? Please more clearly identify when > talking about TLS exchanges over the TCP port, and when talking about > extension fields in a UDP NTP packet. The "KE" in NTS-KE always stands for "key establishment" and runs over TLS/TCP as specified in section 5. Extraction is the RFC5705 computation that both parties perform after the establishment protocol has been completed. It doesn't run "over" anything because it's just a function evaluation, not a message. > - 6.2. Packet structure overview > - "Possibly, some additional extensions which are neither encrypted nor > authenticated. >These are discarded by the receiver.<" The part about > discarding EFs after the NTS packet seems wrong - it's over-reach. > ... > - "The server MAY include additional (non-NTS-related) ...": Please > explain and justify. This seems like massive over-reach, and should not > be "controlled" by the NTS specification. How is this over-reach? Doing otherwise entirely defeats the authentication objectives of the protocol. > - 6.3. The Unique Identifier extension: This is an NTP/NTS extension > field, right? If so, please use the normal language. Yes, it's an NTP extension field, and I'm happy to add the word "field" in there. I left "NTS" out of its name on purpose, because it's nothing but a bag of random bytes that the server is expected to echo back. NTS requires the EF, but using the EF does not require NTS. > This should not use a new EF, it should use the proposed NTS EF Field Type of > (recommended value) 4, with a sub-code of [TBD], perhaps suggesting 1. > > - 6.4. The NTS Cookie extension: Ditto - EF type 4, sub-code of [TBD], > perhaps suggesting 2. > > - 6.5. The NTS Cookie Placeholder extension: Ditto - EF type 4, > sub-code of [TBD], perhaps suggesting 3. > > - 6.6. The NTS Authenticator and Encrypted Extensions extension: Ditto, > it's an "Extension Field", not an "extension", and it should be EF type > 4, sub-code of [TBD], perhaps suggesting 4. > > Should 6.2. be: > > 6.2. Packet structure overview > > and then use: > > 6.3. NTS Extension Field and Sub-Codes > The NTS Extension Field uses a Field Type of [TBD] (recommendation to > IANA: 4), with the following sub-codes: > > 6.3.1. The Unique Identifier Sub-Code > 6.3.2. The Cookie Extension Sub-Code > 6.3.3. The Cookie Placeholder Extension Sub-Code > 6.3.4. The Authenticator and Encrypted Extensions Sub-Code > > Please note that I might have mis-named sub-code - the RFC I've proposed > to address this isn't handy. > > When specifying EF types and sub-codes, please note which top-level bits > (R/E/O/I) are expected. > > ... > > - [[TBD2]]-[[TBD5]]: see earlier discussion. We want a single NTS > Extension Field (type 4 is suggested), with sub-codes for the specific > subfield types. These top-level bits are not reserved and have no meaning outside of Autokey. There is no mention of them in either RFC 5905 or RFC 7822, and when we discussed this in Chicago, there was an overwhelming consensus against any attempt to change this. In light of this, I see no benefit to cramming all NTS extensions into a single code and requiring a sub-code to disambiguate them. > - 6.7. Protocol details > No MAC protection is suggested for DTLS-encapsulated NTPv4, correct? When NTP traffic is already encapsulated in DTLS, adding a legacy MAC serves no further purpose. But, as stated, DTLS-encapsulated NTPv4 permits arbitrary NTP traffic, which means there's no prohibition on including one. > - "Upon receiving an NTS-protected request, the server SHALL (thru some > implementation-defined mechanism) use the cookie to recover ...": > First, "NTS-protected request" is not quite right - this only applies to > the NTS EFs, correct, as they're the only ones that use an NTS-generated > MAC, right? > > ... > > The list of EFs that are included does not explicitly say where the MAC > lives. One would *assume* the MAC lives in or after the last NTS Cookie > Extension Field, but it doesn't say this. Also NTS Cookie EFs must be > authenticated *and* encrypted. If the MAC lives in the last NTS Cookie > EF, is the MAC encrypted? The answer to that last question MUST be > "no", in which case there seems to be a need for the MAC to live as > either a legacy MAC, or in a MAC-EF, after the last NTS Cookie EF. NTS doesn't use the legacy MAC field, or a MAC at all; it uses AEAD, as specified in section 6.6. The output of the AEAD function will generally include something that's functionally similar to a MAC, but the structure of that is specified in RFC 5116 and (in the specific case of AES-SIV) 5297, not here. The AEAD output lives in the NTS Authenticator and Encrypted Extensions EF. > - "... C2S key, and S2C key ...": What do separate keys offer us that 1 > key doesn't? We discussed this a bit in the thread with Scott Fluhrer from last May (note to self: I need to add Scott to the acknowledgements). In general, there are two reasons that cryptographic protocols should use separate keys for different message directions: 1. To keep messages intended for one recipient from being accepted if they're maliciously redirected to another (including back to the sender). In the particular case of NTP client/server mode, this one's not a big issue because the mode field is already there for disambiguation, but see above about how crypto protocols ought to be generically secure. 2. So that it isn't necessary for one sender to avoid using a nonce already used by the other. As Scott pointed out, there is a slight downside to using separate keys: it enlarges cookies by a bit. I don't make much of this since everything still fits comfortably inside a single packet. One possibility that hasn't yet been discussed: add an extra step to the key extraction function of section 6.1, so that one intermediate secret is extracted from the master secret, and then the S2C and C2S keys are extracted from the intermediate secret. Then, to save space, just store the intermediate secret in the cookie. This approach has a small computational downside since now you have to recompute the TLS-PRF for every packet you handle, but server implementors who consider this a bad trade-off can just go on storing the S2C and C2S keys in the cookie. I'm open to making this change if the WG agrees it's a good idea. You can already achieve the same thing by storing the master secret in the cookie, but this weakens forward secrecy of the NTS-KE session in a way that seems undesirable. > - "If the server is unable to validate, ... KoD ...": This is > overloading/mis-using KoD. What is wrong with the crypto-NAK for this > purpose? On the contrary, this seems like an overloading/misuse of crypto-NAK, which indicates a problem with the legacy MAC field. KoD is suited just fine for this sort of purpose; it's only a rate-limiting mechanism when the kiss code is "RATE". Looking at figure 13 in RFC 5905, NTS NAK seems to fit in just fine among all the other kiss codes defined there. > - "Upon receiving an NTS-protected response, ...": Again, NTS does both > client/server and peer mode exchanges. This section seems to only need > to concern itself with client/server. Right. This is in section 6 which indeed only concerns itself with client/server mode. It prohibits including these extensions in any other mode; you need to use DTLS-encapsulated NTPv4 for that. > Furthermore, the sentence would be more accurate if it was: "After > passing the NTP base-packet checks, a packet protected by NTS > Extension Fields MUST verify that the ..." No! This is an implementation detail and not something the spec needs to opine on, but NTS fields should be the first thing checked, not the last. Why expose all that other attack surface to packets that might be forgeries if you don't have to? > - 8. IANA Considerations > - Port Number: [[TBD1]]: why not use TCP/123? If this is done, please > clearly demonstrate that the protocol will allow additional uses on this > port, as we'd like to eventually use TCP/123 for monitoring and control > purposes, too. You just answered your own question, more or less. You mentioned in Boston that you intended to make use of NTP's existing TCP/123 allocation because ordered-and-reliable delivery can be desirable for large mode 6 responses. We went to a separate port to avoid stepping on this, as there would be no elegant and reliable way to disambiguate what protocol we're speaking. Same goes for the UDP port. > Please better identify in the IANA considerations when you're asking > about EF codes v. TLS codes. What's a "TLS code", and what's unclear? Each request to IANA states the name of the registry the request pertains to. > - 9.2. NTP is designed to come up from a position of zero access to any > network resources, and as network resources become available, NTP will > evaluate these resources. In particular, DNS cannot be trusted before > time is trusted, and most 3rd-party certificates cannot be trusted until > after time is trusted. Dave's recent Autokey paper discusses these > issues as well, and a thorough comparison of the requirements and > assertions of the Autokey and NTS documents should be performed. DNS can't, and needn't, be trusted regardless since we're not assuming DNSsec, and addressing the issues around X.509 trust is the whole purpose of this section. Discussion of how these problems apply to entirely different protocol (Autokey) seems like a strange thing to include here. > - 9.3. Usage of NTP pools > - "... Pools in existence as of 2017 are volunteer-run, with minimal > requirements for admission and no organized effort to monitor pool > servers for misbehavior. ..." Really? Where did you get this > "information"? For all the but the last part, from http://www.pool.ntp.org/en/join.html. If I'm wrong about the "no organized effort to monitor pool servers for misbehavior" part, please cite one and I'll remove or revise that phrase. From ntp-bounces@ietf.org Mon Aug 28 14:01:21 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 43BD4132983; Mon, 28 Aug 2017 14:01:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1503954081; bh=KSoKiP4rOk8WQV219E3kl8qkgNm1JbK8nBkE1rSRdRc=; h=In-Reply-To:References:From:Date:To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc; b=R0Qqo7nta0Ycu814iHUHHwkqWWleh2JtVwsYMKaJ2S+vQPj00cM0Wrq6xMJ2jflI6 eJlHQBYhnGPvdUVALG/uG3NAan+OpsATu1HWTdIC9lz/5n1neUKTU9N5uNJlZ9CJEp cGXj9YTbfx4kwuO1xJCoKJdbDSfrWw9362QWjDLo= 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 48DE5132983 for ; Mon, 28 Aug 2017 14:01:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 SCJfEBXLfNeq for ; Mon, 28 Aug 2017 14:01:16 -0700 (PDT) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (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 BDBED126BF0 for ; Mon, 28 Aug 2017 14:01:15 -0700 (PDT) Received: by mail-qt0-x22a.google.com with SMTP id w42so7504749qtg.5 for ; Mon, 28 Aug 2017 14:01:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=cItUn4wTod+d3P82lwfceYuzbhfEyTuKDWGzE7/4q3Y=; b=EUfuhVmGMshkxo613gKcqophZz8eTVPtsfe4ZP3gpQ4L6bRrAzPKlnLQMGhkgRv3nc kkRs+N5CGCMLOXIj7JxZrdxSSXRCySyYxrjQq3N/mZ6aIU4Jr1/799YU1weh5QSG2lG+ fxi/cT4E+7+7FJFie+j/VBtnTE4Mmrm/T/4YKjV+i0o+wRDVz3vyZOlA/+xa9XOFKi0P NymzqH+dECHdwT+KvNK5aDXrYXcOKfHWAg4KYiAoGVf68llFmKZOh6WX8yJeHPFVpE8v H9+GcNc3zRjZdmnLjXxy5ivDkkksG7D8RbDD3j+wWiO1gpe4B8P44WVktH1RYhLfqe5I yBdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=cItUn4wTod+d3P82lwfceYuzbhfEyTuKDWGzE7/4q3Y=; b=l7LlytzdZCGhd5xGppRxMCvEDnY8pB5XOZ2QDG12aGJIPv8fpZZ5wDf2DacXeyhxW5 VFBpMQc4FgWWDCzX+ZBQwWezO4oYSbegh3itM1HzbyvplbVYCyNNm1PWR4ZO7KGiF/h2 7LsE8DsqyaMEPXa4o0CyKnLflHr5q3QV0Br/gLxruYRY7/fyHVL8qdphJEeazeOaiX5U 9AxEoSnbwWP5znF2eMtvZ6creCOPK7sLrPdjYEjM/KK8vzAPE8QedrFe+zu0ExOWaiMj VVP+cgw+7hPpT00egOM85pUqTe2p4M6B9F/G/FxcDBugZP0L37CpdqDkIxF57s9Iw2fv GKow== X-Gm-Message-State: AHYfb5i3stowkWqdo3qetHuDsJWEFYw7A6MvlYqNnaqTqZ3JM4txcdYM RaZRCFlCG5GcBtMaAB6ROsA3NY8ZpsK5 X-Received: by 10.80.159.138 with SMTP id c10mr1552739edf.257.1503954066024; Mon, 28 Aug 2017 14:01:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.157.140 with HTTP; Mon, 28 Aug 2017 14:01:04 -0700 (PDT) In-Reply-To: <47b5b4e3-41c9-6779-4a96-b11650483499@nwtime.org> References: <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> <47b5b4e3-41c9-6779-4a96-b11650483499@nwtime.org> From: Daniel Franke Date: Mon, 28 Aug 2017 17:01:04 -0400 Message-ID: To: Harlan Stenn Archived-At: Subject: Re: [Ntp] WGLC for draft-ietf-ntp-using-nts-for-ntp X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: ntp@ietf.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ntp-bounces@ietf.org Sender: "ntp" Responses inline, some paragraphs reordered so I can address them together. On 8/28/17, Harlan Stenn wrote: > I spent 2 hours on the phone on Friday with Dave Mills, discussing this > proposal. Here is the "result" of that conversation. > > Dave: Do not ratify this proposal. It needs more discussion and > clarification. The proposal as written should NOT be approved. > > Harlan: I agree with Dave. > > TL;DR version: > > There are some parts of the proposal that are wrong, and some other > parts are misleading. There are sections of the proposal that are > confusing, and there are sections of the proposal that are inadequately > described. > > Long version: > > 1.1. Objectives > > - Confidentiality: Under what conditions is this actually useful? If > confidentiality is a need for some, in those situations why not just > send the NTP traffic over an encrypted VPN? > > ... > > The point about "Future extension fields could hypothetically contain > sensitive information" seems implausible. Have any such possibilities > >that are appropriate for an NTP Extension Field< packet even been > considered? But assuming there is a way to tell NTS to send this > information encrypted, that would mean that the peer-mode DTLS > connection would have to provide encryption, and the client/server NTS > EF would have to provide an API, which has not been described here, to > contain this encrypted information. Within NTS, the confidentiality scheme is a necessary building block to achieve unlinkability. Where *else* will it be useful? I don't know. We've built a tool; I can't predict every way people will use it. If you want to put confidential information into an extension field, now you can. If this ability never gets used for anything except NTS cookies, then so be it: we've done no work that wasn't already necessary for that case. > What client-confidential information exists in a normal NTP header > that is not able to be adequately protected right now? Using SNTP > wueries with minimal data fields one already gets all of the > protections described in ntp-data-minimization. Is there something here you suppose I disagree with? What's stated in section 10.2 is that NTS doesn't protect the confidentiality of the header, but if you implement data minimization then that's okay because there'll be nothing left there that needs protecting. > - Replay prevention: The core NTP specification already has replay > prevention. The proposed language is misleading, implying that without > NTS there is no replay protection. If the existing core protection > against replay is inadequate, please describe the problem(s). You could > also say "NTS offers another, additional layer of replay prevention > beyond what NTP already provides." > > ... > > - "The purpose of the unique-identifier extension is to protect the > client from replay attacks.": Again, this is *additional* replay > prevention, beyond the existing prevention offered in the base protocol. The existing text here is very terse, I don't think it implies anything one way or the other about existing protections, and I think we should leave it that way since such a discussion is of no use to implementers. But anyway, if it were necessary to opine, my answer would be twofold: 1. As a general matter of good design, a security protocol should be generically secure and not rely on assumptions about the structure of the plaintext it's protecting. That alone should be good enough, but, 2. The 64-bit origin timestamp is not big enough to protect against accidental collision. I could expand, but since, in the data minimization draft, it was over your objection that we recommended even taking full advantage of the bits we've got, I'm certain the explanation would not be to your liking and you'd be happier with the document's present silence on the matter. > - Request-response consistency: The core NTP protocol already has > request-response consistency checks, where useful. The proposed > language is misleading, implying that without NTS there is no > request-response consistency checking. If the existing checks for > request-response consistency is inadequate, please describe the > problem(s). You could also say "NTS offers another, additional layer of > request-response consistency checks beyond what NTP already provides." Request-response consistency comes out of the same set of mechanisms that provide replay protection, so in reply to this I reiterate what I wrote above. > - Unlinkability: The stated threat seems extraordinarily unlikely to be > possible if more than several networks are involved. Even if such a > threat was possible and used, if the client/server model for NTS is to > use NTP packets with NTS extension fields, an outside observer can still > see that there is a client sending requests to a set of servers that > some other client has used before. How is that traffic not "linkable"? > This "feature" seems to be a red-herring. > > ... > > - 10.1. Unlinkability. This would seem to be a red-herring. Beyond > that, see the comments under 1.1. We discussed this last year in Boston. What's written is "For mobile clients, *NTS* will not leak any information which would permit a passive adversary to determine that two packets sent over different networks came from the same client" (emphasis added). Yes, there are aspects of NTP, as well as other things running on most people's systems having nothing at all to do with NTP, which can sabotage this goal. We wrote the data minimization draft to clean up the other NTP-specific bits to the best of our ability. The whole rest of ecosystem is outside this WG's sphere of responsibility, and cleaning it up is going to be long haul for the IETF over decades. Nonetheless, the IETF does seem committed to this goal, and we're doing our small part. > - Non-amplification: The core problem is DDoS. Amplification is a > secondary problem. Sure, the avoidance of amplification is a useful > interim step. But the target protocol isn't the place to solve the > DDoS problem. DDoS is basically an "overcommit" problem. BCP38, anyone? > > ... > > - 9.1. Avoiding DDoS amplification: We discussed this above, and I won't > repeat that here. I will again repeat that the core issue is DDoS, and > the secondary issue is amplification. I don't follow your point. No, of course NTS is not designed to solve DDoS in general, internet-wide. The goal that's written is "implementations [of NTS] may avoid acting as DDoS amplifiers by never responding to a request with a packet larger than the request packet" and that's what the design achieves. > - Scalability: The way this is phrased is confusing. If this goal is > specific to NTS, then it should say so. Given the subsequent > discussions about C2S, S2C, etc., it also seems disingenuous. Aside > from these things, it seems to be another red-herring. More detail below. The text says, "Servers implementations may serve large numbers of clients without having to retain any client-specific state". Given that this is the document specifying NTS, is it not already clear that this means "server implementations of NTS"? See below about statelessness. > 1.2. Protocol Overview > > "These various modes have different and contradictory requirement for > security and performance." This is a naive observation, and is not > true. We *always* care about performance and security. Different modes > simply use different equations for deciding how to achieve the > performance and security goals they require. > > "In order to simultaneously serve these *conflicting* requirements..." > Again, the requirements are not conflicting, they're just different, > based on the use-case. Am I correct in reading this as an objection to word choice and not to substance? The language seems clear to me as it stands, but if you think it can be improved then please propose text. > "... it is harmless for servers to process replayed packets." This may > be true as far as the server is concerned, but carried to its extreme > this is no different from how a DDoS attack is conducted. But servers > are expected to be stateless, and, again, the target protocol isn't the > place to solve the DDoS problem. Replayed packets aren't any more of a contributor to DDoS than fresh ones, so this seems like a strange thing to bring up here. > "... NTS is structured as a suite of three protocols:" It should be > noted that other methods to accomplish these goals are possible, and > that what is subsequently described is *one* way that is expected to > satisfy the requirements. Of course other designs are possible. This is the one, and the only one, that we're proposing as a standard. > - DTLS-encapsulated NTPv4: No mention is made of the fact that this > method will increase timing jitter, and degrade the quality of > timekeeping. This is especially troublesome given that peer mode is > mostly used for groups of lower-stratum servers offering time to many > clients. > [...] > Also there is no mention of the degradation of the NTP protocol > because of the increased jitter caused by the DTLS encapsulation. No mention is made of this because there is no reason or evidence that it would be true. All the necessary cryptographic algorithms can, should, and generally do have constant-time implementations, and their execution time is negligible compared to network latency even over a LAN. > - NTS Extensions for NTPv4: Should this be "NTS Extension Fields for > NTPv4"? Is the comment about the server not needing state correct? No > subsequent discussion is provided to support this. Several paragraphs > into "6.7. Protocol Details" we see "Upon receiving an NTS-protected > request, the server SHALL (through some implementation-defined > mechanism) use the cookie to recover the AEAD Algorithm, C2S key, and > S2C key associated with the request, ..." but says nothing more about > this. Please offer even one description of how this can be done, > efficiently if possible, without the server retaining state. > > ... > > Next, as previously mentioned, please provide details on how > an implementation would accomplish this without saving state on a > per-client basis. Also describe any computational or storage costs. As explained toward the end of the protocol overview section (1.2), server statelessness is enabled through cookies. Section 7, which appears missing from your feedback, explains how. > This paragraph then goes on to talk about how the proposed NTF Extension > Fields are (only) "suitable for securing client/server ...". Is > "suitable" the right word in this sentence? How about "needed", > "appropriate", or "used", or "useful"? I mean "suitable" in the sense of "satisfying all stated objectives". I think it carries that sense better than any of those proposed synonyms. > The paragraph again mentions "the server can implement them without > retaining per-client state" and then says the NTF EFs are "suitable > *only* for client/server mode because only the client, and not the > server, is protected from replay." This section has a number of serious > problems. One is that NTS is all about securing NTP traffic, but it's > confusing when this section passively describes client/server traffic. > This seems to be true, since symmetric mode is expected to be protected > via DTLS and not NTS-EFs. We think it would be more clear to actively > describe how NTS protects the different modes of NTP. I.e., a section > describing all the steps by which NTS protects symmetric mode > (active/active is really no different from active/passive for this > situation), then all the steps for client/server, then how NTS does not > (yet) have a solution for broadcast mode, and, finally, NTS for mode > 6/7. The paragraph continues the unsubstantiated and dubious claim that > the server does not need per-client state. We could again note that NTP > broadcast mode is only expected to be used in trusted networks, and that > symmetric keys offer authentication in these presumably trusted networks. > > The core NTP specification already provides authentication functionality > for all modes using symmetric keys. Symmetric key protection suffers > from not having a built-in means to perform key exchange. There is also > an issue with multiple "trust groups", but that problem might be solved > with MAC-EFs, where multiple MACs are provided for the different trust > groups. If the key exchange problem was solved, the only thing > remaining to do is to limit symmetric keys to known IPs, and that is a > problem we have already solved. > - NTS Key Establishment: Where is NTS-KE actually described? This is > hinted at by the reference to RFC7505, but it should be explicitly > stated and at least contain a summary description. NTS-KE is specified in section 5, which appears missing from your feedback. > - "It is intended that NTP implementations will use DTLS-encapsulated > NTPv4 to secure symmetric ..." This sentence should appear much earlier > in the document. It's already just a few paragraphs into the overview section. How much earlier do you want it? > - "As previously stated, DTLS-encapsulated NTPv4 is trivial." Again, > please note exactly what mode(s) are using this method, and expressly > note that DTLS-encapsulated NTP traffic will show more timing jitter and > be less accurate than normal NTPv4 UDP traffic. While interleave mode > was inadvertently left out of RFC5905, it is likely the best way to > attempt to mitigate the jitter problems created by DTLS-encapsulated > NTPv4. However, it is not yet clear that there is any way to easily > capture the packet receive or transmit timestamps in a DTLS-encapsulated > transport. DTLS doesn't do any flow control or group or split any packets. Getting timestamps for a DTLS packet is literally no different than for any other. > - "The typical protocol flow for client/server mode is as follows. ..." > Where is the process to generate the shared key described? In section 5 and 6.1. > Please see Dave's recent Autokey paper, Section 8, for the level of > detail we're looking for here. What are the details on the "supply > of cookies"? The initial supply is sent as specified in section 5.1.6. Clients manage and refresh their supply as specified in section 6.7. The structure of cookies is described in section 7. > - "Time synchronization proceeds ... Included among these fields are > ..." How? Please provide details. Describe how to recover from a > dropped packet (or few). "The server uses the cookie to recover this > key material (previously discarded) ...". How? Details, please. > Assuming this can be done without saving state, how expensive is it? See section 7. > - 4. The NTS-encapsulated NTPv4 protocol. This is new language. Was > "DTLS-encapsulated NTPv4 protocol" meant instead? What port will be used? > > ... > - "The NTS-encapsulated NTPv4 protocol is the RECOMMENDED ...": Again, > should this be "DTLS-encapsulated"? Aaargh, crud. I swore I fixed these but obviously I didn't. It should say "DTLS-encapsulated" everywhere. "NTS-encapsulated" is a holdover from earlier drafts; we changed it because "DTLS-encapsulated" is clearer and more accurate. I'll fix this properly in the post-WGLC draft. > - "For symmetric operation ...": There are two paragraphs which discuss > this. Dave expressly disagrees with the first paragraph. The > differences between active/active and active/passive in this situation > would seem to be spurious. Why are they called out? What difference > does it make which side it the DTLS server and which side is the DTLS > client? A protocol restart in this case could easily cause the roles to > reverse. As for the situation where both sides create DTLS sessions, > how can this possibly happen? There should be a single association > between the two parties, and the implementation can be expected to > prevent this from happening. See Section 8 of Dave's recent Autokey > paper for how Dave would implement this. I'm not following you here. In the suggested arrangement, any peer configured as active is going to be initiating a DTLS session as a DTLS client, therefore active-active and active-passive configurations will result in different outcomes, and in the active-active case you might end up with two of them. If you have a better recommendation which avoids this, please post text. > - "If, likely as a result of user error, ...": how about "configuration > error" oe "user configuration error" instead of "user error"? It's > "symmetric active", not "symmetry active". You're right, "configuration error" is better. The latter is a typo and I'll fix it in the post-WGLC draft. > In any event, this situation is no different from one side sending a > mode 1 (active) packet, and getting back a mode 4 (server) response. > Except that NTS recommends DTLS encapsulation for symmetric servers, > and recommends against DTLS encapsulation for client/server mode. My reading of RFC 5905 suggests that a mode 4 packet is not a legal response to a mode 1 packet, and your code seems to agree with me. See https://github.com/ntp-project/ntp/blob/stable/ntpd/ntp_peer.c#L25 > - 6. NTS Extensions for NTPv4: If you're talking about NTP extension > fields, please call them extension fields. > > ... > > - "... the server SHALL include the following extensions in its > response:": First, "extensions" should be "Extension Fields", right? No objection to changing section 6 to "NTS Extension Fields for NTPv4" if there's consensus for this. > - 6.1. Key Extraction: When does NTS-KE mean "key establishment" and > when does KE mean "key extraction"? Please more clearly identify when > talking about TLS exchanges over the TCP port, and when talking about > extension fields in a UDP NTP packet. The "KE" in NTS-KE always stands for "key establishment" and runs over TLS/TCP as specified in section 5. Extraction is the RFC5705 computation that both parties perform after the establishment protocol has been completed. It doesn't run "over" anything because it's just a function evaluation, not a message. > - 6.2. Packet structure overview > - "Possibly, some additional extensions which are neither encrypted nor > authenticated. >These are discarded by the receiver.<" The part about > discarding EFs after the NTS packet seems wrong - it's over-reach. > ... > - "The server MAY include additional (non-NTS-related) ...": Please > explain and justify. This seems like massive over-reach, and should not > be "controlled" by the NTS specification. How is this over-reach? Doing otherwise entirely defeats the authentication objectives of the protocol. > - 6.3. The Unique Identifier extension: This is an NTP/NTS extension > field, right? If so, please use the normal language. Yes, it's an NTP extension field, and I'm happy to add the word "field" in there. I left "NTS" out of its name on purpose, because it's nothing but a bag of random bytes that the server is expected to echo back. NTS requires the EF, but using the EF does not require NTS. > This should not use a new EF, it should use the proposed NTS EF Field Type of > (recommended value) 4, with a sub-code of [TBD], perhaps suggesting 1. > > - 6.4. The NTS Cookie extension: Ditto - EF type 4, sub-code of [TBD], > perhaps suggesting 2. > > - 6.5. The NTS Cookie Placeholder extension: Ditto - EF type 4, > sub-code of [TBD], perhaps suggesting 3. > > - 6.6. The NTS Authenticator and Encrypted Extensions extension: Ditto, > it's an "Extension Field", not an "extension", and it should be EF type > 4, sub-code of [TBD], perhaps suggesting 4. > > Should 6.2. be: > > 6.2. Packet structure overview > > and then use: > > 6.3. NTS Extension Field and Sub-Codes > The NTS Extension Field uses a Field Type of [TBD] (recommendation to > IANA: 4), with the following sub-codes: > > 6.3.1. The Unique Identifier Sub-Code > 6.3.2. The Cookie Extension Sub-Code > 6.3.3. The Cookie Placeholder Extension Sub-Code > 6.3.4. The Authenticator and Encrypted Extensions Sub-Code > > Please note that I might have mis-named sub-code - the RFC I've proposed > to address this isn't handy. > > When specifying EF types and sub-codes, please note which top-level bits > (R/E/O/I) are expected. > > ... > > - [[TBD2]]-[[TBD5]]: see earlier discussion. We want a single NTS > Extension Field (type 4 is suggested), with sub-codes for the specific > subfield types. These top-level bits are not reserved and have no meaning outside of Autokey. There is no mention of them in either RFC 5905 or RFC 7822, and when we discussed this in Chicago, there was an overwhelming consensus against any attempt to change this. In light of this, I see no benefit to cramming all NTS extensions into a single code and requiring a sub-code to disambiguate them. > - 6.7. Protocol details > No MAC protection is suggested for DTLS-encapsulated NTPv4, correct? When NTP traffic is already encapsulated in DTLS, adding a legacy MAC serves no further purpose. But, as stated, DTLS-encapsulated NTPv4 permits arbitrary NTP traffic, which means there's no prohibition on including one. > - "Upon receiving an NTS-protected request, the server SHALL (thru some > implementation-defined mechanism) use the cookie to recover ...": > First, "NTS-protected request" is not quite right - this only applies to > the NTS EFs, correct, as they're the only ones that use an NTS-generated > MAC, right? > > ... > > The list of EFs that are included does not explicitly say where the MAC > lives. One would *assume* the MAC lives in or after the last NTS Cookie > Extension Field, but it doesn't say this. Also NTS Cookie EFs must be > authenticated *and* encrypted. If the MAC lives in the last NTS Cookie > EF, is the MAC encrypted? The answer to that last question MUST be > "no", in which case there seems to be a need for the MAC to live as > either a legacy MAC, or in a MAC-EF, after the last NTS Cookie EF. NTS doesn't use the legacy MAC field, or a MAC at all; it uses AEAD, as specified in section 6.6. The output of the AEAD function will generally include something that's functionally similar to a MAC, but the structure of that is specified in RFC 5116 and (in the specific case of AES-SIV) 5297, not here. The AEAD output lives in the NTS Authenticator and Encrypted Extensions EF. > - "... C2S key, and S2C key ...": What do separate keys offer us that 1 > key doesn't? We discussed this a bit in the thread with Scott Fluhrer from last May (note to self: I need to add Scott to the acknowledgements). In general, there are two reasons that cryptographic protocols should use separate keys for different message directions: 1. To keep messages intended for one recipient from being accepted if they're maliciously redirected to another (including back to the sender). In the particular case of NTP client/server mode, this one's not a big issue because the mode field is already there for disambiguation, but see above about how crypto protocols ought to be generically secure. 2. So that it isn't necessary for one sender to avoid using a nonce already used by the other. As Scott pointed out, there is a slight downside to using separate keys: it enlarges cookies by a bit. I don't make much of this since everything still fits comfortably inside a single packet. One possibility that hasn't yet been discussed: add an extra step to the key extraction function of section 6.1, so that one intermediate secret is extracted from the master secret, and then the S2C and C2S keys are extracted from the intermediate secret. Then, to save space, just store the intermediate secret in the cookie. This approach has a small computational downside since now you have to recompute the TLS-PRF for every packet you handle, but server implementors who consider this a bad trade-off can just go on storing the S2C and C2S keys in the cookie. I'm open to making this change if the WG agrees it's a good idea. You can already achieve the same thing by storing the master secret in the cookie, but this weakens forward secrecy of the NTS-KE session in a way that seems undesirable. > - "If the server is unable to validate, ... KoD ...": This is > overloading/mis-using KoD. What is wrong with the crypto-NAK for this > purpose? On the contrary, this seems like an overloading/misuse of crypto-NAK, which indicates a problem with the legacy MAC field. KoD is suited just fine for this sort of purpose; it's only a rate-limiting mechanism when the kiss code is "RATE". Looking at figure 13 in RFC 5905, NTS NAK seems to fit in just fine among all the other kiss codes defined there. > - "Upon receiving an NTS-protected response, ...": Again, NTS does both > client/server and peer mode exchanges. This section seems to only need > to concern itself with client/server. Right. This is in section 6 which indeed only concerns itself with client/server mode. It prohibits including these extensions in any other mode; you need to use DTLS-encapsulated NTPv4 for that. > Furthermore, the sentence would be more accurate if it was: "After > passing the NTP base-packet checks, a packet protected by NTS > Extension Fields MUST verify that the ..." No! This is an implementation detail and not something the spec needs to opine on, but NTS fields should be the first thing checked, not the last. Why expose all that other attack surface to packets that might be forgeries if you don't have to? > - 8. IANA Considerations > - Port Number: [[TBD1]]: why not use TCP/123? If this is done, please > clearly demonstrate that the protocol will allow additional uses on this > port, as we'd like to eventually use TCP/123 for monitoring and control > purposes, too. You just answered your own question, more or less. You mentioned in Boston that you intended to make use of NTP's existing TCP/123 allocation because ordered-and-reliable delivery can be desirable for large mode 6 responses. We went to a separate port to avoid stepping on this, as there would be no elegant and reliable way to disambiguate what protocol we're speaking. Same goes for the UDP port. > Please better identify in the IANA considerations when you're asking > about EF codes v. TLS codes. What's a "TLS code", and what's unclear? Each request to IANA states the name of the registry the request pertains to. > - 9.2. NTP is designed to come up from a position of zero access to any > network resources, and as network resources become available, NTP will > evaluate these resources. In particular, DNS cannot be trusted before > time is trusted, and most 3rd-party certificates cannot be trusted until > after time is trusted. Dave's recent Autokey paper discusses these > issues as well, and a thorough comparison of the requirements and > assertions of the Autokey and NTS documents should be performed. DNS can't, and needn't, be trusted regardless since we're not assuming DNSsec, and addressing the issues around X.509 trust is the whole purpose of this section. Discussion of how these problems apply to entirely different protocol (Autokey) seems like a strange thing to include here. > - 9.3. Usage of NTP pools > - "... Pools in existence as of 2017 are volunteer-run, with minimal > requirements for admission and no organized effort to monitor pool > servers for misbehavior. ..." Really? Where did you get this > "information"? For all the but the last part, from http://www.pool.ntp.org/en/join.html. If I'm wrong about the "no organized effort to monitor pool servers for misbehavior" part, please cite one and I'll remove or revise that phrase. _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp From ntp-bounces@ietf.org Mon Aug 28 14:16:20 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A1E8132644; Mon, 28 Aug 2017 14:16:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1503954980; bh=2OGpKIUie8gYnANVc6Pma0DN7PGTALYs3PXMzUeTeb4=; h=To:References:From:Date:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc; b=aKaZGkTbxmGXda+VTqSY2L2EL3KpY5DmFSryPfNMNylowe1+yQ3fVhAcTSR3UaO0E VbiDmjwWzWt4/bF8HOQ3Hs6lyDpLlr3HmjGzVY5t67vdcIVp7ua7tdSDPeAKd1f2L8 7MYhFkP5rMmZHJFDhfgi2MeSHVbqnLgIheMHM67I= 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 B45731200F3 for ; Mon, 28 Aug 2017 14:16:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 CW3fC2EU70LK for ; Mon, 28 Aug 2017 14:16:15 -0700 (PDT) Received: from chessie.everett.org (chessie.everett.org [66.220.13.234]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B1B7132644 for ; Mon, 28 Aug 2017 14:16:15 -0700 (PDT) Received: from [10.200.74.153] (nat0.fmt1.everett.org [64.71.190.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by chessie.everett.org (Postfix) with ESMTPSA id 28848B847; Mon, 28 Aug 2017 21:16:15 +0000 (UTC) To: Daniel Franke References: <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> <47b5b4e3-41c9-6779-4a96-b11650483499@nwtime.org> From: Harlan Stenn Message-ID: <1dee3e5d-6906-cf40-d0c3-a387adc2ba42@nwtime.org> Date: Mon, 28 Aug 2017 14:16:12 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US Archived-At: Subject: Re: [Ntp] WGLC for draft-ietf-ntp-using-nts-for-ntp X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: ntp@ietf.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ntp-bounces@ietf.org Sender: "ntp" I don't have time to respond now, and since I'm at ISPCS this week I probably won't have time to respond before the 31st. Daniel, based on my initial read of your response, nothing you have said changes what Dave and I think. If it turns out that something *does* change what we think, it means that the language in the draft is still unclear and should be revised. Dave and I still vote "NO" on advancing this document at this time. H On 8/28/2017 2:01 PM, Daniel Franke wrote: > Responses inline, some paragraphs reordered so I can address them > together. > > On 8/28/17, Harlan Stenn wrote: >> I spent 2 hours on the phone on Friday with Dave Mills, discussing this >> proposal. Here is the "result" of that conversation. >> >> Dave: Do not ratify this proposal. It needs more discussion and >> clarification. The proposal as written should NOT be approved. >> >> Harlan: I agree with Dave. >> >> TL;DR version: >> >> There are some parts of the proposal that are wrong, and some other >> parts are misleading. There are sections of the proposal that are >> confusing, and there are sections of the proposal that are inadequately >> described. >> >> Long version: >> >> 1.1. Objectives >> >> - Confidentiality: Under what conditions is this actually useful? If >> confidentiality is a need for some, in those situations why not just >> send the NTP traffic over an encrypted VPN? >> >> ... >> >> The point about "Future extension fields could hypothetically contain >> sensitive information" seems implausible. Have any such possibilities >>> that are appropriate for an NTP Extension Field< packet even been >> considered? But assuming there is a way to tell NTS to send this >> information encrypted, that would mean that the peer-mode DTLS >> connection would have to provide encryption, and the client/server NTS >> EF would have to provide an API, which has not been described here, to >> contain this encrypted information. > > Within NTS, the confidentiality scheme is a necessary building block > to achieve unlinkability. Where *else* will it be useful? I don't > know. We've built a tool; I can't predict every way people will use > it. If you want to put confidential information into an extension > field, now you can. If this ability never gets used for anything > except NTS cookies, then so be it: we've done no work that wasn't > already necessary for that case. > >> What client-confidential information exists in a normal NTP header >> that is not able to be adequately protected right now? Using SNTP >> wueries with minimal data fields one already gets all of the >> protections described in ntp-data-minimization. > > Is there something here you suppose I disagree with? What's stated in > section 10.2 is that NTS doesn't protect the confidentiality of the > header, but if you implement data minimization then that's okay > because there'll be nothing left there that needs protecting. > >> - Replay prevention: The core NTP specification already has replay >> prevention. The proposed language is misleading, implying that without >> NTS there is no replay protection. If the existing core protection >> against replay is inadequate, please describe the problem(s). You could >> also say "NTS offers another, additional layer of replay prevention >> beyond what NTP already provides." >> >> ... >> >> - "The purpose of the unique-identifier extension is to protect the >> client from replay attacks.": Again, this is *additional* replay >> prevention, beyond the existing prevention offered in the base protocol. > > The existing text here is very terse, I don't think it implies > anything one way or the other about existing protections, and I think > we should leave it that way since such a discussion is of no use to > implementers. But anyway, if it were necessary to opine, my answer > would be twofold: > > 1. As a general matter of good design, a security protocol should be > generically secure and not rely on assumptions about the structure of > the plaintext it's protecting. That alone should be good enough, but, > > 2. The 64-bit origin timestamp is not big enough to protect against > accidental collision. I could expand, but since, in the data > minimization draft, it was over your objection that we recommended > even taking full advantage of the bits we've got, I'm certain the > explanation would not be to your liking and you'd be happier with the > document's present silence on the matter. > >> - Request-response consistency: The core NTP protocol already has >> request-response consistency checks, where useful. The proposed >> language is misleading, implying that without NTS there is no >> request-response consistency checking. If the existing checks for >> request-response consistency is inadequate, please describe the >> problem(s). You could also say "NTS offers another, additional layer of >> request-response consistency checks beyond what NTP already provides." > > Request-response consistency comes out of the same set of mechanisms > that provide replay protection, so in reply to this I reiterate what I > wrote above. > >> - Unlinkability: The stated threat seems extraordinarily unlikely to be >> possible if more than several networks are involved. Even if such a >> threat was possible and used, if the client/server model for NTS is to >> use NTP packets with NTS extension fields, an outside observer can still >> see that there is a client sending requests to a set of servers that >> some other client has used before. How is that traffic not "linkable"? >> This "feature" seems to be a red-herring. >> >> ... >> >> - 10.1. Unlinkability. This would seem to be a red-herring. Beyond >> that, see the comments under 1.1. > > We discussed this last year in Boston. What's written is "For mobile > clients, *NTS* will not leak any information which would permit a > passive adversary to determine that two packets sent over different > networks came from the same client" (emphasis added). Yes, there are > aspects of NTP, as well as other things running on most people's > systems having nothing at all to do with NTP, which can sabotage this > goal. We wrote the data minimization draft to clean up the other > NTP-specific bits to the best of our ability. The whole rest of > ecosystem is outside this WG's sphere of responsibility, and cleaning > it up is going to be long haul for the IETF over decades. Nonetheless, > the IETF does seem committed to this goal, and we're doing our small > part. > >> - Non-amplification: The core problem is DDoS. Amplification is a >> secondary problem. Sure, the avoidance of amplification is a useful >> interim step. But the target protocol isn't the place to solve the >> DDoS problem. DDoS is basically an "overcommit" problem. BCP38, anyone? >> >> ... >> >> - 9.1. Avoiding DDoS amplification: We discussed this above, and I won't >> repeat that here. I will again repeat that the core issue is DDoS, and >> the secondary issue is amplification. > > I don't follow your point. No, of course NTS is not designed to solve > DDoS in general, internet-wide. The goal that's written is > "implementations [of NTS] may avoid acting as DDoS amplifiers by never > responding to a request with a packet larger than the request packet" > and that's what the design achieves. > >> - Scalability: The way this is phrased is confusing. If this goal is >> specific to NTS, then it should say so. Given the subsequent >> discussions about C2S, S2C, etc., it also seems disingenuous. Aside >> from these things, it seems to be another red-herring. More detail below. > > The text says, "Servers implementations may serve large numbers of > clients without having to retain any client-specific state". Given > that this is the document specifying NTS, is it not already clear that > this means "server implementations of NTS"? See below about > statelessness. > >> 1.2. Protocol Overview >> >> "These various modes have different and contradictory requirement for >> security and performance." This is a naive observation, and is not >> true. We *always* care about performance and security. Different modes >> simply use different equations for deciding how to achieve the >> performance and security goals they require. >> >> "In order to simultaneously serve these *conflicting* requirements..." >> Again, the requirements are not conflicting, they're just different, >> based on the use-case. > > Am I correct in reading this as an objection to word choice and not to > substance? The language seems clear to me as it stands, but if you think > it can be improved then please propose text. > >> "... it is harmless for servers to process replayed packets." This may >> be true as far as the server is concerned, but carried to its extreme >> this is no different from how a DDoS attack is conducted. But servers >> are expected to be stateless, and, again, the target protocol isn't the >> place to solve the DDoS problem. > > Replayed packets aren't any more of a contributor to DDoS than fresh ones, > so this seems like a strange thing to bring up here. > >> "... NTS is structured as a suite of three protocols:" It should be >> noted that other methods to accomplish these goals are possible, and >> that what is subsequently described is *one* way that is expected to >> satisfy the requirements. > > Of course other designs are possible. This is the one, and the only > one, that we're proposing as a standard. > >> - DTLS-encapsulated NTPv4: No mention is made of the fact that this >> method will increase timing jitter, and degrade the quality of >> timekeeping. This is especially troublesome given that peer mode is >> mostly used for groups of lower-stratum servers offering time to many >> clients. > >> [...] > >> Also there is no mention of the degradation of the NTP protocol >> because of the increased jitter caused by the DTLS encapsulation. > > No mention is made of this because there is no reason or evidence that > it would be true. All the necessary cryptographic algorithms can, should, > and generally do have constant-time implementations, and their execution > time is negligible compared to network latency even over a LAN. > >> - NTS Extensions for NTPv4: Should this be "NTS Extension Fields for >> NTPv4"? Is the comment about the server not needing state correct? No >> subsequent discussion is provided to support this. Several paragraphs >> into "6.7. Protocol Details" we see "Upon receiving an NTS-protected >> request, the server SHALL (through some implementation-defined >> mechanism) use the cookie to recover the AEAD Algorithm, C2S key, and >> S2C key associated with the request, ..." but says nothing more about >> this. Please offer even one description of how this can be done, >> efficiently if possible, without the server retaining state. >> >> ... >> >> Next, as previously mentioned, please provide details on how >> an implementation would accomplish this without saving state on a >> per-client basis. Also describe any computational or storage costs. > > As explained toward the end of the protocol overview section (1.2), > server statelessness is enabled through cookies. Section 7, which > appears missing from your feedback, explains how. > >> This paragraph then goes on to talk about how the proposed NTF Extension >> Fields are (only) "suitable for securing client/server ...". Is >> "suitable" the right word in this sentence? How about "needed", >> "appropriate", or "used", or "useful"? > > I mean "suitable" in the sense of "satisfying all stated > objectives". I think it carries that sense better than any of those > proposed synonyms. > >> The paragraph again mentions "the server can implement them without >> retaining per-client state" and then says the NTF EFs are "suitable >> *only* for client/server mode because only the client, and not the >> server, is protected from replay." This section has a number of serious >> problems. One is that NTS is all about securing NTP traffic, but it's >> confusing when this section passively describes client/server traffic. >> This seems to be true, since symmetric mode is expected to be protected >> via DTLS and not NTS-EFs. We think it would be more clear to actively >> describe how NTS protects the different modes of NTP. I.e., a section >> describing all the steps by which NTS protects symmetric mode >> (active/active is really no different from active/passive for this >> situation), then all the steps for client/server, then how NTS does not >> (yet) have a solution for broadcast mode, and, finally, NTS for mode >> 6/7. The paragraph continues the unsubstantiated and dubious claim that >> the server does not need per-client state. We could again note that NTP >> broadcast mode is only expected to be used in trusted networks, and that >> symmetric keys offer authentication in these presumably trusted networks. >> >> The core NTP specification already provides authentication functionality >> for all modes using symmetric keys. Symmetric key protection suffers >> from not having a built-in means to perform key exchange. There is also >> an issue with multiple "trust groups", but that problem might be solved >> with MAC-EFs, where multiple MACs are provided for the different trust >> groups. If the key exchange problem was solved, the only thing >> remaining to do is to limit symmetric keys to known IPs, and that is a >> problem we have already solved. > >> - NTS Key Establishment: Where is NTS-KE actually described? This is >> hinted at by the reference to RFC7505, but it should be explicitly >> stated and at least contain a summary description. > > NTS-KE is specified in section 5, which appears missing from your > feedback. > >> - "It is intended that NTP implementations will use DTLS-encapsulated >> NTPv4 to secure symmetric ..." This sentence should appear much earlier >> in the document. > > It's already just a few paragraphs into the overview section. How much > earlier do you want it? > >> - "As previously stated, DTLS-encapsulated NTPv4 is trivial." Again, >> please note exactly what mode(s) are using this method, and expressly >> note that DTLS-encapsulated NTP traffic will show more timing jitter and >> be less accurate than normal NTPv4 UDP traffic. While interleave mode >> was inadvertently left out of RFC5905, it is likely the best way to >> attempt to mitigate the jitter problems created by DTLS-encapsulated >> NTPv4. However, it is not yet clear that there is any way to easily >> capture the packet receive or transmit timestamps in a DTLS-encapsulated >> transport. > > DTLS doesn't do any flow control or group or split any > packets. Getting timestamps for a DTLS packet is literally no > different than for any other. > >> - "The typical protocol flow for client/server mode is as follows. ..." >> Where is the process to generate the shared key described? > > In section 5 and 6.1. > >> Please see Dave's recent Autokey paper, Section 8, for the level of >> detail we're looking for here. What are the details on the "supply >> of cookies"? > > The initial supply is sent as specified in section 5.1.6. Clients manage > and refresh their supply as specified in section 6.7. The structure of > cookies is described in section 7. > >> - "Time synchronization proceeds ... Included among these fields are >> ..." How? Please provide details. Describe how to recover from a >> dropped packet (or few). "The server uses the cookie to recover this >> key material (previously discarded) ...". How? Details, please. >> Assuming this can be done without saving state, how expensive is it? > > See section 7. > >> - 4. The NTS-encapsulated NTPv4 protocol. This is new language. Was >> "DTLS-encapsulated NTPv4 protocol" meant instead? What port will be used? >> >> ... >> - "The NTS-encapsulated NTPv4 protocol is the RECOMMENDED ...": Again, >> should this be "DTLS-encapsulated"? > > Aaargh, crud. I swore I fixed these but obviously I didn't. It should > say "DTLS-encapsulated" everywhere. "NTS-encapsulated" is a holdover > from earlier drafts; we changed it because "DTLS-encapsulated" is > clearer and more accurate. I'll fix this properly in the post-WGLC draft. > >> - "For symmetric operation ...": There are two paragraphs which discuss >> this. Dave expressly disagrees with the first paragraph. The >> differences between active/active and active/passive in this situation >> would seem to be spurious. Why are they called out? What difference >> does it make which side it the DTLS server and which side is the DTLS >> client? A protocol restart in this case could easily cause the roles to >> reverse. As for the situation where both sides create DTLS sessions, >> how can this possibly happen? There should be a single association >> between the two parties, and the implementation can be expected to >> prevent this from happening. See Section 8 of Dave's recent Autokey >> paper for how Dave would implement this. > > I'm not following you here. In the suggested arrangement, any peer > configured as active is going to be initiating a DTLS session as a > DTLS client, therefore active-active and active-passive configurations > will result in different outcomes, and in the active-active case you > might end up with two of them. If you have a better recommendation > which avoids this, please post text. > >> - "If, likely as a result of user error, ...": how about "configuration >> error" oe "user configuration error" instead of "user error"? It's >> "symmetric active", not "symmetry active". > > You're right, "configuration error" is better. The latter is a typo > and I'll fix it in the post-WGLC draft. > >> In any event, this situation is no different from one side sending a >> mode 1 (active) packet, and getting back a mode 4 (server) response. >> Except that NTS recommends DTLS encapsulation for symmetric servers, >> and recommends against DTLS encapsulation for client/server mode. > > My reading of RFC 5905 suggests that a mode 4 packet is not a legal > response to a mode 1 packet, and your code seems to agree with me. > See https://github.com/ntp-project/ntp/blob/stable/ntpd/ntp_peer.c#L25 > >> - 6. NTS Extensions for NTPv4: If you're talking about NTP extension >> fields, please call them extension fields. >> >> ... >> >> - "... the server SHALL include the following extensions in its >> response:": First, "extensions" should be "Extension Fields", right? > > No objection to changing section 6 to "NTS Extension Fields for NTPv4" > if there's consensus for this. > >> - 6.1. Key Extraction: When does NTS-KE mean "key establishment" and >> when does KE mean "key extraction"? Please more clearly identify when >> talking about TLS exchanges over the TCP port, and when talking about >> extension fields in a UDP NTP packet. > > The "KE" in NTS-KE always stands for "key establishment" and runs over > TLS/TCP as specified in section 5. Extraction is the RFC5705 > computation that both parties perform after the establishment protocol > has been completed. It doesn't run "over" anything because it's just a > function evaluation, not a message. > >> - 6.2. Packet structure overview >> - "Possibly, some additional extensions which are neither encrypted nor >> authenticated. >These are discarded by the receiver.<" The part about >> discarding EFs after the NTS packet seems wrong - it's over-reach. >> ... >> - "The server MAY include additional (non-NTS-related) ...": Please >> explain and justify. This seems like massive over-reach, and should not >> be "controlled" by the NTS specification. > > How is this over-reach? Doing otherwise entirely defeats the > authentication objectives of the protocol. > >> - 6.3. The Unique Identifier extension: This is an NTP/NTS extension >> field, right? If so, please use the normal language. > > Yes, it's an NTP extension field, and I'm happy to add the word > "field" in there. I left "NTS" out of its name on purpose, because > it's nothing but a bag of random bytes that the server is expected to > echo back. NTS requires the EF, but using the EF does not require NTS. > >> This should not use a new EF, it should use the proposed NTS EF Field Type of >> (recommended value) 4, with a sub-code of [TBD], perhaps suggesting 1. >> >> - 6.4. The NTS Cookie extension: Ditto - EF type 4, sub-code of [TBD], >> perhaps suggesting 2. >> >> - 6.5. The NTS Cookie Placeholder extension: Ditto - EF type 4, >> sub-code of [TBD], perhaps suggesting 3. >> >> - 6.6. The NTS Authenticator and Encrypted Extensions extension: Ditto, >> it's an "Extension Field", not an "extension", and it should be EF type >> 4, sub-code of [TBD], perhaps suggesting 4. >> >> Should 6.2. be: >> >> 6.2. Packet structure overview >> >> and then use: >> >> 6.3. NTS Extension Field and Sub-Codes >> The NTS Extension Field uses a Field Type of [TBD] (recommendation to >> IANA: 4), with the following sub-codes: >> >> 6.3.1. The Unique Identifier Sub-Code >> 6.3.2. The Cookie Extension Sub-Code >> 6.3.3. The Cookie Placeholder Extension Sub-Code >> 6.3.4. The Authenticator and Encrypted Extensions Sub-Code >> >> Please note that I might have mis-named sub-code - the RFC I've proposed >> to address this isn't handy. >> >> When specifying EF types and sub-codes, please note which top-level bits >> (R/E/O/I) are expected. >> >> ... >> >> - [[TBD2]]-[[TBD5]]: see earlier discussion. We want a single NTS >> Extension Field (type 4 is suggested), with sub-codes for the specific >> subfield types. > > These top-level bits are not reserved and have no meaning outside of > Autokey. There is no mention of them in either RFC 5905 or RFC 7822, > and when we discussed this in Chicago, there was an overwhelming > consensus against any attempt to change this. In light of this, I see > no benefit to cramming all NTS extensions into a single code and > requiring a sub-code to disambiguate them. > >> - 6.7. Protocol details > >> No MAC protection is suggested for DTLS-encapsulated NTPv4, correct? > > When NTP traffic is already encapsulated in DTLS, adding a legacy MAC > serves no further purpose. But, as stated, DTLS-encapsulated NTPv4 > permits arbitrary NTP traffic, which means there's no prohibition on > including one. > >> - "Upon receiving an NTS-protected request, the server SHALL (thru some >> implementation-defined mechanism) use the cookie to recover ...": >> First, "NTS-protected request" is not quite right - this only applies to >> the NTS EFs, correct, as they're the only ones that use an NTS-generated >> MAC, right? >> >> ... >> >> The list of EFs that are included does not explicitly say where the MAC >> lives. One would *assume* the MAC lives in or after the last NTS Cookie >> Extension Field, but it doesn't say this. Also NTS Cookie EFs must be >> authenticated *and* encrypted. If the MAC lives in the last NTS Cookie >> EF, is the MAC encrypted? The answer to that last question MUST be >> "no", in which case there seems to be a need for the MAC to live as >> either a legacy MAC, or in a MAC-EF, after the last NTS Cookie EF. > > NTS doesn't use the legacy MAC field, or a MAC at all; it uses AEAD, > as specified in section 6.6. The output of the AEAD function will > generally include something that's functionally similar to a MAC, but > the structure of that is specified in RFC 5116 and (in the specific > case of AES-SIV) 5297, not here. The AEAD output lives in the NTS > Authenticator and Encrypted Extensions EF. > >> - "... C2S key, and S2C key ...": What do separate keys offer us that 1 >> key doesn't? > > We discussed this a bit in the thread with Scott Fluhrer from last May > (note to self: I need to add Scott to the acknowledgements). In > general, there are two reasons that cryptographic protocols should use > separate keys for different message directions: > > 1. To keep messages intended for one recipient from being accepted if > they're maliciously redirected to another (including back to the > sender). In the particular case of NTP client/server mode, this one's > not a big issue because the mode field is already there for > disambiguation, but see above about how crypto protocols ought to be > generically secure. > > 2. So that it isn't necessary for one sender to avoid using a nonce > already used by the other. > > As Scott pointed out, there is a slight downside to using separate > keys: it enlarges cookies by a bit. I don't make much of this since > everything still fits comfortably inside a single packet. > > One possibility that hasn't yet been discussed: add an extra step to > the key extraction function of section 6.1, so that one intermediate > secret is extracted from the master secret, and then the S2C and C2S > keys are extracted from the intermediate secret. Then, to save space, > just store the intermediate secret in the cookie. This approach has a > small computational downside since now you have to recompute the > TLS-PRF for every packet you handle, but server implementors who > consider this a bad trade-off can just go on storing the S2C and C2S > keys in the cookie. I'm open to making this change if the WG agrees > it's a good idea. > > You can already achieve the same thing by storing the master secret > in the cookie, but this weakens forward secrecy of the NTS-KE > session in a way that seems undesirable. > >> - "If the server is unable to validate, ... KoD ...": This is >> overloading/mis-using KoD. What is wrong with the crypto-NAK for this >> purpose? > > On the contrary, this seems like an overloading/misuse of crypto-NAK, > which indicates a problem with the legacy MAC field. KoD is suited > just fine for this sort of purpose; it's only a rate-limiting > mechanism when the kiss code is "RATE". Looking at figure 13 in RFC > 5905, NTS NAK seems to fit in just fine among all the other kiss codes > defined there. > >> - "Upon receiving an NTS-protected response, ...": Again, NTS does both >> client/server and peer mode exchanges. This section seems to only need >> to concern itself with client/server. > > Right. This is in section 6 which indeed only concerns itself with > client/server mode. It prohibits including these extensions in any > other mode; you need to use DTLS-encapsulated NTPv4 for that. > >> Furthermore, the sentence would be more accurate if it was: "After >> passing the NTP base-packet checks, a packet protected by NTS >> Extension Fields MUST verify that the ..." > > No! This is an implementation detail and not something the spec needs > to opine on, but NTS fields should be the first thing checked, not the > last. Why expose all that other attack surface to packets that might > be forgeries if you don't have to? > >> - 8. IANA Considerations >> - Port Number: [[TBD1]]: why not use TCP/123? If this is done, please >> clearly demonstrate that the protocol will allow additional uses on this >> port, as we'd like to eventually use TCP/123 for monitoring and control >> purposes, too. > > You just answered your own question, more or less. You mentioned in > Boston that you intended to make use of NTP's existing TCP/123 > allocation because ordered-and-reliable delivery can be desirable for > large mode 6 responses. We went to a separate port to avoid stepping > on this, as there would be no elegant and reliable way to disambiguate > what protocol we're speaking. Same goes for the UDP port. > >> Please better identify in the IANA considerations when you're asking >> about EF codes v. TLS codes. > > What's a "TLS code", and what's unclear? Each request to IANA states the > name of the registry the request pertains to. > >> - 9.2. NTP is designed to come up from a position of zero access to any >> network resources, and as network resources become available, NTP will >> evaluate these resources. In particular, DNS cannot be trusted before >> time is trusted, and most 3rd-party certificates cannot be trusted until >> after time is trusted. Dave's recent Autokey paper discusses these >> issues as well, and a thorough comparison of the requirements and >> assertions of the Autokey and NTS documents should be performed. > > DNS can't, and needn't, be trusted regardless since we're not assuming > DNSsec, and addressing the issues around X.509 trust is the whole > purpose of this section. Discussion of how these problems apply to > entirely different protocol (Autokey) seems like a strange thing to > include here. > >> - 9.3. Usage of NTP pools >> - "... Pools in existence as of 2017 are volunteer-run, with minimal >> requirements for admission and no organized effort to monitor pool >> servers for misbehavior. ..." Really? Where did you get this >> "information"? > > For all the but the last part, from > http://www.pool.ntp.org/en/join.html. If I'm wrong about the "no > organized effort to monitor pool servers for misbehavior" part, please > cite one and I'll remove or revise that phrase. > -- Harlan Stenn http://networktimefoundation.org - be a member! _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp From nobody Mon Aug 28 14:16:20 2017 Return-Path: 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 B45731200F3 for ; Mon, 28 Aug 2017 14:16:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 CW3fC2EU70LK for ; Mon, 28 Aug 2017 14:16:15 -0700 (PDT) Received: from chessie.everett.org (chessie.everett.org [66.220.13.234]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B1B7132644 for ; Mon, 28 Aug 2017 14:16:15 -0700 (PDT) Received: from [10.200.74.153] (nat0.fmt1.everett.org [64.71.190.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by chessie.everett.org (Postfix) with ESMTPSA id 28848B847; Mon, 28 Aug 2017 21:16:15 +0000 (UTC) To: Daniel Franke Cc: ntp@ietf.org References: <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> <47b5b4e3-41c9-6779-4a96-b11650483499@nwtime.org> From: Harlan Stenn Message-ID: <1dee3e5d-6906-cf40-d0c3-a387adc2ba42@nwtime.org> Date: Mon, 28 Aug 2017 14:16:12 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Ntp] WGLC for draft-ietf-ntp-using-nts-for-ntp X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Aug 2017 21:16:18 -0000 I don't have time to respond now, and since I'm at ISPCS this week I probably won't have time to respond before the 31st. Daniel, based on my initial read of your response, nothing you have said changes what Dave and I think. If it turns out that something *does* change what we think, it means that the language in the draft is still unclear and should be revised. Dave and I still vote "NO" on advancing this document at this time. H On 8/28/2017 2:01 PM, Daniel Franke wrote: > Responses inline, some paragraphs reordered so I can address them > together. > > On 8/28/17, Harlan Stenn wrote: >> I spent 2 hours on the phone on Friday with Dave Mills, discussing this >> proposal. Here is the "result" of that conversation. >> >> Dave: Do not ratify this proposal. It needs more discussion and >> clarification. The proposal as written should NOT be approved. >> >> Harlan: I agree with Dave. >> >> TL;DR version: >> >> There are some parts of the proposal that are wrong, and some other >> parts are misleading. There are sections of the proposal that are >> confusing, and there are sections of the proposal that are inadequately >> described. >> >> Long version: >> >> 1.1. Objectives >> >> - Confidentiality: Under what conditions is this actually useful? If >> confidentiality is a need for some, in those situations why not just >> send the NTP traffic over an encrypted VPN? >> >> ... >> >> The point about "Future extension fields could hypothetically contain >> sensitive information" seems implausible. Have any such possibilities >>> that are appropriate for an NTP Extension Field< packet even been >> considered? But assuming there is a way to tell NTS to send this >> information encrypted, that would mean that the peer-mode DTLS >> connection would have to provide encryption, and the client/server NTS >> EF would have to provide an API, which has not been described here, to >> contain this encrypted information. > > Within NTS, the confidentiality scheme is a necessary building block > to achieve unlinkability. Where *else* will it be useful? I don't > know. We've built a tool; I can't predict every way people will use > it. If you want to put confidential information into an extension > field, now you can. If this ability never gets used for anything > except NTS cookies, then so be it: we've done no work that wasn't > already necessary for that case. > >> What client-confidential information exists in a normal NTP header >> that is not able to be adequately protected right now? Using SNTP >> wueries with minimal data fields one already gets all of the >> protections described in ntp-data-minimization. > > Is there something here you suppose I disagree with? What's stated in > section 10.2 is that NTS doesn't protect the confidentiality of the > header, but if you implement data minimization then that's okay > because there'll be nothing left there that needs protecting. > >> - Replay prevention: The core NTP specification already has replay >> prevention. The proposed language is misleading, implying that without >> NTS there is no replay protection. If the existing core protection >> against replay is inadequate, please describe the problem(s). You could >> also say "NTS offers another, additional layer of replay prevention >> beyond what NTP already provides." >> >> ... >> >> - "The purpose of the unique-identifier extension is to protect the >> client from replay attacks.": Again, this is *additional* replay >> prevention, beyond the existing prevention offered in the base protocol. > > The existing text here is very terse, I don't think it implies > anything one way or the other about existing protections, and I think > we should leave it that way since such a discussion is of no use to > implementers. But anyway, if it were necessary to opine, my answer > would be twofold: > > 1. As a general matter of good design, a security protocol should be > generically secure and not rely on assumptions about the structure of > the plaintext it's protecting. That alone should be good enough, but, > > 2. The 64-bit origin timestamp is not big enough to protect against > accidental collision. I could expand, but since, in the data > minimization draft, it was over your objection that we recommended > even taking full advantage of the bits we've got, I'm certain the > explanation would not be to your liking and you'd be happier with the > document's present silence on the matter. > >> - Request-response consistency: The core NTP protocol already has >> request-response consistency checks, where useful. The proposed >> language is misleading, implying that without NTS there is no >> request-response consistency checking. If the existing checks for >> request-response consistency is inadequate, please describe the >> problem(s). You could also say "NTS offers another, additional layer of >> request-response consistency checks beyond what NTP already provides." > > Request-response consistency comes out of the same set of mechanisms > that provide replay protection, so in reply to this I reiterate what I > wrote above. > >> - Unlinkability: The stated threat seems extraordinarily unlikely to be >> possible if more than several networks are involved. Even if such a >> threat was possible and used, if the client/server model for NTS is to >> use NTP packets with NTS extension fields, an outside observer can still >> see that there is a client sending requests to a set of servers that >> some other client has used before. How is that traffic not "linkable"? >> This "feature" seems to be a red-herring. >> >> ... >> >> - 10.1. Unlinkability. This would seem to be a red-herring. Beyond >> that, see the comments under 1.1. > > We discussed this last year in Boston. What's written is "For mobile > clients, *NTS* will not leak any information which would permit a > passive adversary to determine that two packets sent over different > networks came from the same client" (emphasis added). Yes, there are > aspects of NTP, as well as other things running on most people's > systems having nothing at all to do with NTP, which can sabotage this > goal. We wrote the data minimization draft to clean up the other > NTP-specific bits to the best of our ability. The whole rest of > ecosystem is outside this WG's sphere of responsibility, and cleaning > it up is going to be long haul for the IETF over decades. Nonetheless, > the IETF does seem committed to this goal, and we're doing our small > part. > >> - Non-amplification: The core problem is DDoS. Amplification is a >> secondary problem. Sure, the avoidance of amplification is a useful >> interim step. But the target protocol isn't the place to solve the >> DDoS problem. DDoS is basically an "overcommit" problem. BCP38, anyone? >> >> ... >> >> - 9.1. Avoiding DDoS amplification: We discussed this above, and I won't >> repeat that here. I will again repeat that the core issue is DDoS, and >> the secondary issue is amplification. > > I don't follow your point. No, of course NTS is not designed to solve > DDoS in general, internet-wide. The goal that's written is > "implementations [of NTS] may avoid acting as DDoS amplifiers by never > responding to a request with a packet larger than the request packet" > and that's what the design achieves. > >> - Scalability: The way this is phrased is confusing. If this goal is >> specific to NTS, then it should say so. Given the subsequent >> discussions about C2S, S2C, etc., it also seems disingenuous. Aside >> from these things, it seems to be another red-herring. More detail below. > > The text says, "Servers implementations may serve large numbers of > clients without having to retain any client-specific state". Given > that this is the document specifying NTS, is it not already clear that > this means "server implementations of NTS"? See below about > statelessness. > >> 1.2. Protocol Overview >> >> "These various modes have different and contradictory requirement for >> security and performance." This is a naive observation, and is not >> true. We *always* care about performance and security. Different modes >> simply use different equations for deciding how to achieve the >> performance and security goals they require. >> >> "In order to simultaneously serve these *conflicting* requirements..." >> Again, the requirements are not conflicting, they're just different, >> based on the use-case. > > Am I correct in reading this as an objection to word choice and not to > substance? The language seems clear to me as it stands, but if you think > it can be improved then please propose text. > >> "... it is harmless for servers to process replayed packets." This may >> be true as far as the server is concerned, but carried to its extreme >> this is no different from how a DDoS attack is conducted. But servers >> are expected to be stateless, and, again, the target protocol isn't the >> place to solve the DDoS problem. > > Replayed packets aren't any more of a contributor to DDoS than fresh ones, > so this seems like a strange thing to bring up here. > >> "... NTS is structured as a suite of three protocols:" It should be >> noted that other methods to accomplish these goals are possible, and >> that what is subsequently described is *one* way that is expected to >> satisfy the requirements. > > Of course other designs are possible. This is the one, and the only > one, that we're proposing as a standard. > >> - DTLS-encapsulated NTPv4: No mention is made of the fact that this >> method will increase timing jitter, and degrade the quality of >> timekeeping. This is especially troublesome given that peer mode is >> mostly used for groups of lower-stratum servers offering time to many >> clients. > >> [...] > >> Also there is no mention of the degradation of the NTP protocol >> because of the increased jitter caused by the DTLS encapsulation. > > No mention is made of this because there is no reason or evidence that > it would be true. All the necessary cryptographic algorithms can, should, > and generally do have constant-time implementations, and their execution > time is negligible compared to network latency even over a LAN. > >> - NTS Extensions for NTPv4: Should this be "NTS Extension Fields for >> NTPv4"? Is the comment about the server not needing state correct? No >> subsequent discussion is provided to support this. Several paragraphs >> into "6.7. Protocol Details" we see "Upon receiving an NTS-protected >> request, the server SHALL (through some implementation-defined >> mechanism) use the cookie to recover the AEAD Algorithm, C2S key, and >> S2C key associated with the request, ..." but says nothing more about >> this. Please offer even one description of how this can be done, >> efficiently if possible, without the server retaining state. >> >> ... >> >> Next, as previously mentioned, please provide details on how >> an implementation would accomplish this without saving state on a >> per-client basis. Also describe any computational or storage costs. > > As explained toward the end of the protocol overview section (1.2), > server statelessness is enabled through cookies. Section 7, which > appears missing from your feedback, explains how. > >> This paragraph then goes on to talk about how the proposed NTF Extension >> Fields are (only) "suitable for securing client/server ...". Is >> "suitable" the right word in this sentence? How about "needed", >> "appropriate", or "used", or "useful"? > > I mean "suitable" in the sense of "satisfying all stated > objectives". I think it carries that sense better than any of those > proposed synonyms. > >> The paragraph again mentions "the server can implement them without >> retaining per-client state" and then says the NTF EFs are "suitable >> *only* for client/server mode because only the client, and not the >> server, is protected from replay." This section has a number of serious >> problems. One is that NTS is all about securing NTP traffic, but it's >> confusing when this section passively describes client/server traffic. >> This seems to be true, since symmetric mode is expected to be protected >> via DTLS and not NTS-EFs. We think it would be more clear to actively >> describe how NTS protects the different modes of NTP. I.e., a section >> describing all the steps by which NTS protects symmetric mode >> (active/active is really no different from active/passive for this >> situation), then all the steps for client/server, then how NTS does not >> (yet) have a solution for broadcast mode, and, finally, NTS for mode >> 6/7. The paragraph continues the unsubstantiated and dubious claim that >> the server does not need per-client state. We could again note that NTP >> broadcast mode is only expected to be used in trusted networks, and that >> symmetric keys offer authentication in these presumably trusted networks. >> >> The core NTP specification already provides authentication functionality >> for all modes using symmetric keys. Symmetric key protection suffers >> from not having a built-in means to perform key exchange. There is also >> an issue with multiple "trust groups", but that problem might be solved >> with MAC-EFs, where multiple MACs are provided for the different trust >> groups. If the key exchange problem was solved, the only thing >> remaining to do is to limit symmetric keys to known IPs, and that is a >> problem we have already solved. > >> - NTS Key Establishment: Where is NTS-KE actually described? This is >> hinted at by the reference to RFC7505, but it should be explicitly >> stated and at least contain a summary description. > > NTS-KE is specified in section 5, which appears missing from your > feedback. > >> - "It is intended that NTP implementations will use DTLS-encapsulated >> NTPv4 to secure symmetric ..." This sentence should appear much earlier >> in the document. > > It's already just a few paragraphs into the overview section. How much > earlier do you want it? > >> - "As previously stated, DTLS-encapsulated NTPv4 is trivial." Again, >> please note exactly what mode(s) are using this method, and expressly >> note that DTLS-encapsulated NTP traffic will show more timing jitter and >> be less accurate than normal NTPv4 UDP traffic. While interleave mode >> was inadvertently left out of RFC5905, it is likely the best way to >> attempt to mitigate the jitter problems created by DTLS-encapsulated >> NTPv4. However, it is not yet clear that there is any way to easily >> capture the packet receive or transmit timestamps in a DTLS-encapsulated >> transport. > > DTLS doesn't do any flow control or group or split any > packets. Getting timestamps for a DTLS packet is literally no > different than for any other. > >> - "The typical protocol flow for client/server mode is as follows. ..." >> Where is the process to generate the shared key described? > > In section 5 and 6.1. > >> Please see Dave's recent Autokey paper, Section 8, for the level of >> detail we're looking for here. What are the details on the "supply >> of cookies"? > > The initial supply is sent as specified in section 5.1.6. Clients manage > and refresh their supply as specified in section 6.7. The structure of > cookies is described in section 7. > >> - "Time synchronization proceeds ... Included among these fields are >> ..." How? Please provide details. Describe how to recover from a >> dropped packet (or few). "The server uses the cookie to recover this >> key material (previously discarded) ...". How? Details, please. >> Assuming this can be done without saving state, how expensive is it? > > See section 7. > >> - 4. The NTS-encapsulated NTPv4 protocol. This is new language. Was >> "DTLS-encapsulated NTPv4 protocol" meant instead? What port will be used? >> >> ... >> - "The NTS-encapsulated NTPv4 protocol is the RECOMMENDED ...": Again, >> should this be "DTLS-encapsulated"? > > Aaargh, crud. I swore I fixed these but obviously I didn't. It should > say "DTLS-encapsulated" everywhere. "NTS-encapsulated" is a holdover > from earlier drafts; we changed it because "DTLS-encapsulated" is > clearer and more accurate. I'll fix this properly in the post-WGLC draft. > >> - "For symmetric operation ...": There are two paragraphs which discuss >> this. Dave expressly disagrees with the first paragraph. The >> differences between active/active and active/passive in this situation >> would seem to be spurious. Why are they called out? What difference >> does it make which side it the DTLS server and which side is the DTLS >> client? A protocol restart in this case could easily cause the roles to >> reverse. As for the situation where both sides create DTLS sessions, >> how can this possibly happen? There should be a single association >> between the two parties, and the implementation can be expected to >> prevent this from happening. See Section 8 of Dave's recent Autokey >> paper for how Dave would implement this. > > I'm not following you here. In the suggested arrangement, any peer > configured as active is going to be initiating a DTLS session as a > DTLS client, therefore active-active and active-passive configurations > will result in different outcomes, and in the active-active case you > might end up with two of them. If you have a better recommendation > which avoids this, please post text. > >> - "If, likely as a result of user error, ...": how about "configuration >> error" oe "user configuration error" instead of "user error"? It's >> "symmetric active", not "symmetry active". > > You're right, "configuration error" is better. The latter is a typo > and I'll fix it in the post-WGLC draft. > >> In any event, this situation is no different from one side sending a >> mode 1 (active) packet, and getting back a mode 4 (server) response. >> Except that NTS recommends DTLS encapsulation for symmetric servers, >> and recommends against DTLS encapsulation for client/server mode. > > My reading of RFC 5905 suggests that a mode 4 packet is not a legal > response to a mode 1 packet, and your code seems to agree with me. > See https://github.com/ntp-project/ntp/blob/stable/ntpd/ntp_peer.c#L25 > >> - 6. NTS Extensions for NTPv4: If you're talking about NTP extension >> fields, please call them extension fields. >> >> ... >> >> - "... the server SHALL include the following extensions in its >> response:": First, "extensions" should be "Extension Fields", right? > > No objection to changing section 6 to "NTS Extension Fields for NTPv4" > if there's consensus for this. > >> - 6.1. Key Extraction: When does NTS-KE mean "key establishment" and >> when does KE mean "key extraction"? Please more clearly identify when >> talking about TLS exchanges over the TCP port, and when talking about >> extension fields in a UDP NTP packet. > > The "KE" in NTS-KE always stands for "key establishment" and runs over > TLS/TCP as specified in section 5. Extraction is the RFC5705 > computation that both parties perform after the establishment protocol > has been completed. It doesn't run "over" anything because it's just a > function evaluation, not a message. > >> - 6.2. Packet structure overview >> - "Possibly, some additional extensions which are neither encrypted nor >> authenticated. >These are discarded by the receiver.<" The part about >> discarding EFs after the NTS packet seems wrong - it's over-reach. >> ... >> - "The server MAY include additional (non-NTS-related) ...": Please >> explain and justify. This seems like massive over-reach, and should not >> be "controlled" by the NTS specification. > > How is this over-reach? Doing otherwise entirely defeats the > authentication objectives of the protocol. > >> - 6.3. The Unique Identifier extension: This is an NTP/NTS extension >> field, right? If so, please use the normal language. > > Yes, it's an NTP extension field, and I'm happy to add the word > "field" in there. I left "NTS" out of its name on purpose, because > it's nothing but a bag of random bytes that the server is expected to > echo back. NTS requires the EF, but using the EF does not require NTS. > >> This should not use a new EF, it should use the proposed NTS EF Field Type of >> (recommended value) 4, with a sub-code of [TBD], perhaps suggesting 1. >> >> - 6.4. The NTS Cookie extension: Ditto - EF type 4, sub-code of [TBD], >> perhaps suggesting 2. >> >> - 6.5. The NTS Cookie Placeholder extension: Ditto - EF type 4, >> sub-code of [TBD], perhaps suggesting 3. >> >> - 6.6. The NTS Authenticator and Encrypted Extensions extension: Ditto, >> it's an "Extension Field", not an "extension", and it should be EF type >> 4, sub-code of [TBD], perhaps suggesting 4. >> >> Should 6.2. be: >> >> 6.2. Packet structure overview >> >> and then use: >> >> 6.3. NTS Extension Field and Sub-Codes >> The NTS Extension Field uses a Field Type of [TBD] (recommendation to >> IANA: 4), with the following sub-codes: >> >> 6.3.1. The Unique Identifier Sub-Code >> 6.3.2. The Cookie Extension Sub-Code >> 6.3.3. The Cookie Placeholder Extension Sub-Code >> 6.3.4. The Authenticator and Encrypted Extensions Sub-Code >> >> Please note that I might have mis-named sub-code - the RFC I've proposed >> to address this isn't handy. >> >> When specifying EF types and sub-codes, please note which top-level bits >> (R/E/O/I) are expected. >> >> ... >> >> - [[TBD2]]-[[TBD5]]: see earlier discussion. We want a single NTS >> Extension Field (type 4 is suggested), with sub-codes for the specific >> subfield types. > > These top-level bits are not reserved and have no meaning outside of > Autokey. There is no mention of them in either RFC 5905 or RFC 7822, > and when we discussed this in Chicago, there was an overwhelming > consensus against any attempt to change this. In light of this, I see > no benefit to cramming all NTS extensions into a single code and > requiring a sub-code to disambiguate them. > >> - 6.7. Protocol details > >> No MAC protection is suggested for DTLS-encapsulated NTPv4, correct? > > When NTP traffic is already encapsulated in DTLS, adding a legacy MAC > serves no further purpose. But, as stated, DTLS-encapsulated NTPv4 > permits arbitrary NTP traffic, which means there's no prohibition on > including one. > >> - "Upon receiving an NTS-protected request, the server SHALL (thru some >> implementation-defined mechanism) use the cookie to recover ...": >> First, "NTS-protected request" is not quite right - this only applies to >> the NTS EFs, correct, as they're the only ones that use an NTS-generated >> MAC, right? >> >> ... >> >> The list of EFs that are included does not explicitly say where the MAC >> lives. One would *assume* the MAC lives in or after the last NTS Cookie >> Extension Field, but it doesn't say this. Also NTS Cookie EFs must be >> authenticated *and* encrypted. If the MAC lives in the last NTS Cookie >> EF, is the MAC encrypted? The answer to that last question MUST be >> "no", in which case there seems to be a need for the MAC to live as >> either a legacy MAC, or in a MAC-EF, after the last NTS Cookie EF. > > NTS doesn't use the legacy MAC field, or a MAC at all; it uses AEAD, > as specified in section 6.6. The output of the AEAD function will > generally include something that's functionally similar to a MAC, but > the structure of that is specified in RFC 5116 and (in the specific > case of AES-SIV) 5297, not here. The AEAD output lives in the NTS > Authenticator and Encrypted Extensions EF. > >> - "... C2S key, and S2C key ...": What do separate keys offer us that 1 >> key doesn't? > > We discussed this a bit in the thread with Scott Fluhrer from last May > (note to self: I need to add Scott to the acknowledgements). In > general, there are two reasons that cryptographic protocols should use > separate keys for different message directions: > > 1. To keep messages intended for one recipient from being accepted if > they're maliciously redirected to another (including back to the > sender). In the particular case of NTP client/server mode, this one's > not a big issue because the mode field is already there for > disambiguation, but see above about how crypto protocols ought to be > generically secure. > > 2. So that it isn't necessary for one sender to avoid using a nonce > already used by the other. > > As Scott pointed out, there is a slight downside to using separate > keys: it enlarges cookies by a bit. I don't make much of this since > everything still fits comfortably inside a single packet. > > One possibility that hasn't yet been discussed: add an extra step to > the key extraction function of section 6.1, so that one intermediate > secret is extracted from the master secret, and then the S2C and C2S > keys are extracted from the intermediate secret. Then, to save space, > just store the intermediate secret in the cookie. This approach has a > small computational downside since now you have to recompute the > TLS-PRF for every packet you handle, but server implementors who > consider this a bad trade-off can just go on storing the S2C and C2S > keys in the cookie. I'm open to making this change if the WG agrees > it's a good idea. > > You can already achieve the same thing by storing the master secret > in the cookie, but this weakens forward secrecy of the NTS-KE > session in a way that seems undesirable. > >> - "If the server is unable to validate, ... KoD ...": This is >> overloading/mis-using KoD. What is wrong with the crypto-NAK for this >> purpose? > > On the contrary, this seems like an overloading/misuse of crypto-NAK, > which indicates a problem with the legacy MAC field. KoD is suited > just fine for this sort of purpose; it's only a rate-limiting > mechanism when the kiss code is "RATE". Looking at figure 13 in RFC > 5905, NTS NAK seems to fit in just fine among all the other kiss codes > defined there. > >> - "Upon receiving an NTS-protected response, ...": Again, NTS does both >> client/server and peer mode exchanges. This section seems to only need >> to concern itself with client/server. > > Right. This is in section 6 which indeed only concerns itself with > client/server mode. It prohibits including these extensions in any > other mode; you need to use DTLS-encapsulated NTPv4 for that. > >> Furthermore, the sentence would be more accurate if it was: "After >> passing the NTP base-packet checks, a packet protected by NTS >> Extension Fields MUST verify that the ..." > > No! This is an implementation detail and not something the spec needs > to opine on, but NTS fields should be the first thing checked, not the > last. Why expose all that other attack surface to packets that might > be forgeries if you don't have to? > >> - 8. IANA Considerations >> - Port Number: [[TBD1]]: why not use TCP/123? If this is done, please >> clearly demonstrate that the protocol will allow additional uses on this >> port, as we'd like to eventually use TCP/123 for monitoring and control >> purposes, too. > > You just answered your own question, more or less. You mentioned in > Boston that you intended to make use of NTP's existing TCP/123 > allocation because ordered-and-reliable delivery can be desirable for > large mode 6 responses. We went to a separate port to avoid stepping > on this, as there would be no elegant and reliable way to disambiguate > what protocol we're speaking. Same goes for the UDP port. > >> Please better identify in the IANA considerations when you're asking >> about EF codes v. TLS codes. > > What's a "TLS code", and what's unclear? Each request to IANA states the > name of the registry the request pertains to. > >> - 9.2. NTP is designed to come up from a position of zero access to any >> network resources, and as network resources become available, NTP will >> evaluate these resources. In particular, DNS cannot be trusted before >> time is trusted, and most 3rd-party certificates cannot be trusted until >> after time is trusted. Dave's recent Autokey paper discusses these >> issues as well, and a thorough comparison of the requirements and >> assertions of the Autokey and NTS documents should be performed. > > DNS can't, and needn't, be trusted regardless since we're not assuming > DNSsec, and addressing the issues around X.509 trust is the whole > purpose of this section. Discussion of how these problems apply to > entirely different protocol (Autokey) seems like a strange thing to > include here. > >> - 9.3. Usage of NTP pools >> - "... Pools in existence as of 2017 are volunteer-run, with minimal >> requirements for admission and no organized effort to monitor pool >> servers for misbehavior. ..." Really? Where did you get this >> "information"? > > For all the but the last part, from > http://www.pool.ntp.org/en/join.html. If I'm wrong about the "no > organized effort to monitor pool servers for misbehavior" part, please > cite one and I'll remove or revise that phrase. > -- Harlan Stenn http://networktimefoundation.org - be a member! From ntp-bounces@ietf.org Mon Aug 28 14:28:25 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CB76E132A87; Mon, 28 Aug 2017 14:28:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1503955705; bh=faehgt6gv6N1zjKVpPE9KnytcVqbM3cABd+G/7T3QkU=; h=In-Reply-To:References:From:Date:To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc; b=d/bpih+d3YwyGqta/X2XYUUUFgbsf+ppUeqklxzKxroGCLSz37ZXaGQLwhy5OAtk0 FkdQDvpH1AP5DI1AWwRX47JxJkYwZZ46EZA5jMG//qRraYN6uLq2kgwVUXd/dA1aVs XKztLLI3NOGzFHbWUrzUdeGGH6K4U6CLDjSPf8Po= 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 4719A132A87 for ; Mon, 28 Aug 2017 14:28:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 JbrVZBkGpVWk for ; Mon, 28 Aug 2017 14:28:22 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (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 98A23132A85 for ; Mon, 28 Aug 2017 14:28:22 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id b82so10256965wmd.1 for ; Mon, 28 Aug 2017 14:28:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=CB/yrpcyH4GqPKa/x/yY1Z3JN3BbqbWBhcc21aXnCok=; b=gVcojRl+6DHBjqTLZQaDsHvBfc34qBTEa/YRJbPinscCxjlYiGsVrfmsq1H6rHPkVE vpeqp90F0V7XAQwoq0qglhP9/KiSCd+z55F3EJGP8a+IDa0GyKNcgISxZDETrwU3FGjA 174+8aEt3J20es9nWEnE9RqphCpuoxwuFOyljPkke5PufcxGe3Qx4QTcZsJyMFhgwupy EJVsKsIjAAEtT3He/weuBHy9nnTP19uNlNXlYcXMgHZZG56WUc0foCXpbuWOVsRC6adh p+tz8D0i+84KT1A23r/4vrRFSBNGXMefSJZQ7tj0yKOz+MR0A2Q+xdRhFXPPreWmNaA7 4/9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=CB/yrpcyH4GqPKa/x/yY1Z3JN3BbqbWBhcc21aXnCok=; b=fbL5FbxWA3cSiUoVcWE7R9ShvvkCBIcQqAc9Rwid061T+6QA1kEMCPxa5IYS4Zc1cA NWZfZsQZqthsKoKq2N0jcSSVOHL0ZlQt8iCmO6aA1Vu4G8DnqKoD1b6YbkF0hA05F6FR 3S8at8mgANy7ESySS1oYkiESps2sjvu4x4HlblFpejxH3OjKPFzClAmhM+eY4LYbsK3E YeZ7e2vecM6rJXwp3Geu5nHupZztI6pgxMdBbUfOEB1VkHSp4r0Icr2eoAqxmu4ZcLrx ic7tnHIMDNd8GQ0zvd5g/TCXEdJ76ocQizHAXHKTrkWeQKfigUDf3gwLOpuBcGcrBFEs M51w== X-Gm-Message-State: AHYfb5immLXoeuNcLlULUgo3kM95Hc7xxejuiOLMgGT1VmEqF5iDT6sp LvUV5mVpz4wjx+W4R2Qt4EvZRUkJjw== X-Received: by 10.80.147.94 with SMTP id n30mr1605551eda.86.1503955700972; Mon, 28 Aug 2017 14:28:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.157.140 with HTTP; Mon, 28 Aug 2017 14:28:20 -0700 (PDT) In-Reply-To: <1dee3e5d-6906-cf40-d0c3-a387adc2ba42@nwtime.org> References: <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> <47b5b4e3-41c9-6779-4a96-b11650483499@nwtime.org> <1dee3e5d-6906-cf40-d0c3-a387adc2ba42@nwtime.org> From: Daniel Franke Date: Mon, 28 Aug 2017 17:28:20 -0400 Message-ID: To: Harlan Stenn Archived-At: Subject: Re: [Ntp] WGLC for draft-ietf-ntp-using-nts-for-ntp X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: ntp@ietf.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ntp-bounces@ietf.org Sender: "ntp" On 8/28/17, Harlan Stenn wrote: > Dave and I still vote "NO" on advancing this document at this time. Harlan, your opposition is noted, but your attempt to seize the mantle of Prof. Mills' authority here is inappropriate I want you to stop. Prof. Mills could not possibly have read and responded to my comments in the time it took you to send this reply. Your original critique, in which you claim to be speaking for the two of you, is also written entirely in your style with no indication of what is Prof. Mills' commentary and what is yours. I understand that Prof. Mills' health makes it challenging for him to participate fully in this discussion. We should all do everything we possibly can to accommodate him. But you are not acting as a faithful messenger and I will not accept your words as his. _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp From nobody Mon Aug 28 14:28:25 2017 Return-Path: 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 4719A132A87 for ; Mon, 28 Aug 2017 14:28:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 JbrVZBkGpVWk for ; Mon, 28 Aug 2017 14:28:22 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (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 98A23132A85 for ; Mon, 28 Aug 2017 14:28:22 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id b82so10256965wmd.1 for ; Mon, 28 Aug 2017 14:28:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=CB/yrpcyH4GqPKa/x/yY1Z3JN3BbqbWBhcc21aXnCok=; b=gVcojRl+6DHBjqTLZQaDsHvBfc34qBTEa/YRJbPinscCxjlYiGsVrfmsq1H6rHPkVE vpeqp90F0V7XAQwoq0qglhP9/KiSCd+z55F3EJGP8a+IDa0GyKNcgISxZDETrwU3FGjA 174+8aEt3J20es9nWEnE9RqphCpuoxwuFOyljPkke5PufcxGe3Qx4QTcZsJyMFhgwupy EJVsKsIjAAEtT3He/weuBHy9nnTP19uNlNXlYcXMgHZZG56WUc0foCXpbuWOVsRC6adh p+tz8D0i+84KT1A23r/4vrRFSBNGXMefSJZQ7tj0yKOz+MR0A2Q+xdRhFXPPreWmNaA7 4/9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=CB/yrpcyH4GqPKa/x/yY1Z3JN3BbqbWBhcc21aXnCok=; b=fbL5FbxWA3cSiUoVcWE7R9ShvvkCBIcQqAc9Rwid061T+6QA1kEMCPxa5IYS4Zc1cA NWZfZsQZqthsKoKq2N0jcSSVOHL0ZlQt8iCmO6aA1Vu4G8DnqKoD1b6YbkF0hA05F6FR 3S8at8mgANy7ESySS1oYkiESps2sjvu4x4HlblFpejxH3OjKPFzClAmhM+eY4LYbsK3E YeZ7e2vecM6rJXwp3Geu5nHupZztI6pgxMdBbUfOEB1VkHSp4r0Icr2eoAqxmu4ZcLrx ic7tnHIMDNd8GQ0zvd5g/TCXEdJ76ocQizHAXHKTrkWeQKfigUDf3gwLOpuBcGcrBFEs M51w== X-Gm-Message-State: AHYfb5immLXoeuNcLlULUgo3kM95Hc7xxejuiOLMgGT1VmEqF5iDT6sp LvUV5mVpz4wjx+W4R2Qt4EvZRUkJjw== X-Received: by 10.80.147.94 with SMTP id n30mr1605551eda.86.1503955700972; Mon, 28 Aug 2017 14:28:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.157.140 with HTTP; Mon, 28 Aug 2017 14:28:20 -0700 (PDT) In-Reply-To: <1dee3e5d-6906-cf40-d0c3-a387adc2ba42@nwtime.org> References: <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> <47b5b4e3-41c9-6779-4a96-b11650483499@nwtime.org> <1dee3e5d-6906-cf40-d0c3-a387adc2ba42@nwtime.org> From: Daniel Franke Date: Mon, 28 Aug 2017 17:28:20 -0400 Message-ID: To: Harlan Stenn Cc: ntp@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Ntp] WGLC for draft-ietf-ntp-using-nts-for-ntp X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Aug 2017 21:28:24 -0000 On 8/28/17, Harlan Stenn wrote: > Dave and I still vote "NO" on advancing this document at this time. Harlan, your opposition is noted, but your attempt to seize the mantle of Prof. Mills' authority here is inappropriate I want you to stop. Prof. Mills could not possibly have read and responded to my comments in the time it took you to send this reply. Your original critique, in which you claim to be speaking for the two of you, is also written entirely in your style with no indication of what is Prof. Mills' commentary and what is yours. I understand that Prof. Mills' health makes it challenging for him to participate fully in this discussion. We should all do everything we possibly can to accommodate him. But you are not acting as a faithful messenger and I will not accept your words as his. From nobody Mon Aug 28 17:17:44 2017 Return-Path: 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 DA0C412008A for ; Mon, 28 Aug 2017 17:17:42 -0700 (PDT) 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, SPF_PASS=-0.001] 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 TB2qWOI2muES for ; Mon, 28 Aug 2017 17:17:41 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::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 8EBAB1321DF for ; Mon, 28 Aug 2017 17:17:41 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v7T0Gc9q008549; Tue, 29 Aug 2017 01:17:37 +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=S7nmE4QqD1S0jNmm9B96YdQVNtaKGjjKNuzk+FVc2H0=; b=o6bnLlPhma67+U4xHIngKAh8p9Eo4hRZvj/qvuhwmO/fuB9OT3nYb51APEMluLhu2Xpq +ilX1EEsbwO1ekU20WO3q7tHzm8AWgjyig3Rq1JMxf8DT23WM7ZZVaWiREysNrdP3l5Y b6YJVbIZVUjTUBMBzHU/zcou3p8T6eNS9SK0itPhLYVUaRTFuVpgxI12dG0gaXgbQJfH 0/xSsbJE/YE5kJBXEPiZk+Ja8H3K40IbFmUsvepPrptaopQZ/LLuJVjgzV7kbXFI2bTZ tgO6hzraIU/CDbv8VrWp5PoKFHA7eVlI/tTbZpCcXiKZn2CHlxffoOh9PJewalcBJC+p 2w== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by m0050102.ppops.net-00190b01. with ESMTP id 2cjx2bephn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 29 Aug 2017 01:17:36 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v7T0GGSd012396; Mon, 28 Aug 2017 20:17:36 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint2.akamai.com with ESMTP id 2ck4aucbtq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 28 Aug 2017 20:17:36 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 28 Aug 2017 20:17:35 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Mon, 28 Aug 2017 20:17:35 -0400 From: "Salz, Rich" To: Harlan Stenn , Daniel Franke CC: "ntp@ietf.org" Thread-Topic: [Ntp] WGLC for draft-ietf-ntp-using-nts-for-ntp Thread-Index: AQHTEMnCM2s3Nc34m0O8jzUH1rPjTqKZl+MAgAELHACAAAQ7AP//754A Date: Tue, 29 Aug 2017 00:17:35 +0000 Message-ID: <27D59834-53F7-4509-A962-4D67C4234AE1@akamai.com> References: <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> <47b5b4e3-41c9-6779-4a96-b11650483499@nwtime.org> <1dee3e5d-6906-cf40-d0c3-a387adc2ba42@nwtime.org> In-Reply-To: <1dee3e5d-6906-cf40-d0c3-a387adc2ba42@nwtime.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1b.0.161010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.45.73] Content-Type: text/plain; charset="utf-8" Content-ID: <393BBA9620B3E94F92B1A48B3F5C0209@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-28_13:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1708290002 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-28_13:, , 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=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1708290002 Archived-At: Subject: Re: [Ntp] WGLC for draft-ietf-ntp-using-nts-for-ntp X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Aug 2017 00:17:43 -0000 DQo+ICAgIEkgZG9uJ3QgaGF2ZSB0aW1lIHRvIHJlc3BvbmQgbm93LCBhbmQgc2luY2UgSSdtIGF0 IElTUENTIHRoaXMgd2VlayBJDQogID4gIHByb2JhYmx5IHdvbid0IGhhdmUgdGltZSB0byByZXNw b25kIGJlZm9yZSB0aGUgMzFzdC4NCiAgICANCj4gICAgRGFuaWVsLCBiYXNlZCBvbiBteSBpbml0 aWFsIHJlYWQgb2YgeW91ciByZXNwb25zZSwgbm90aGluZyB5b3UgaGF2ZSBzYWlkDQogPiAgIGNo YW5nZXMgd2hhdCBEYXZlIGFuZCBJIHRoaW5rLg0KDQpIYXMgRGF2ZSBzZWVuIChvciBoZWFyZCBJ IHN1cHBvc2UpIERhbmllbOKAmXMgcmVzcG9uc2U/ICBJZiBub3QsIHBsZWFzZSBrZWVwIHlvdXIg dmlldyBvbiBoaXMgc2VwYXJhdGUuDQoNCg0K From ntp-bounces@ietf.org Mon Aug 28 17:17:45 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 29DF8132256; Mon, 28 Aug 2017 17:17:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1503965865; bh=A9rFZpvFA6YHmQrfY79b5LzOpeOWAVodqU5+apt/w50=; h=From:To:Date:References:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc; b=JWfxqZXN2vJ/GfslNaUAFgdgVZZvbP6FMJS4CtFhOzNUWiWLKhZibQJVHjCo/dzEI lhWvpJe+ZRSH5w/5lq4HpbA/HHKqIieUhiaiB0e+01BVlhF6nMTy3NUTTZx+AGLFTC jTd8Eue2p6DnAqU51AgrVfPVsWqt4qQywBS+DqWE= 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 DA0C412008A for ; Mon, 28 Aug 2017 17:17:42 -0700 (PDT) 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, SPF_PASS=-0.001] 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 TB2qWOI2muES for ; Mon, 28 Aug 2017 17:17:41 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::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 8EBAB1321DF for ; Mon, 28 Aug 2017 17:17:41 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v7T0Gc9q008549; Tue, 29 Aug 2017 01:17:37 +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=S7nmE4QqD1S0jNmm9B96YdQVNtaKGjjKNuzk+FVc2H0=; b=o6bnLlPhma67+U4xHIngKAh8p9Eo4hRZvj/qvuhwmO/fuB9OT3nYb51APEMluLhu2Xpq +ilX1EEsbwO1ekU20WO3q7tHzm8AWgjyig3Rq1JMxf8DT23WM7ZZVaWiREysNrdP3l5Y b6YJVbIZVUjTUBMBzHU/zcou3p8T6eNS9SK0itPhLYVUaRTFuVpgxI12dG0gaXgbQJfH 0/xSsbJE/YE5kJBXEPiZk+Ja8H3K40IbFmUsvepPrptaopQZ/LLuJVjgzV7kbXFI2bTZ tgO6hzraIU/CDbv8VrWp5PoKFHA7eVlI/tTbZpCcXiKZn2CHlxffoOh9PJewalcBJC+p 2w== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by m0050102.ppops.net-00190b01. with ESMTP id 2cjx2bephn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 29 Aug 2017 01:17:36 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v7T0GGSd012396; Mon, 28 Aug 2017 20:17:36 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint2.akamai.com with ESMTP id 2ck4aucbtq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 28 Aug 2017 20:17:36 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 28 Aug 2017 20:17:35 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Mon, 28 Aug 2017 20:17:35 -0400 From: "Salz, Rich" To: Harlan Stenn , Daniel Franke Thread-Topic: [Ntp] WGLC for draft-ietf-ntp-using-nts-for-ntp Thread-Index: AQHTEMnCM2s3Nc34m0O8jzUH1rPjTqKZl+MAgAELHACAAAQ7AP//754A Date: Tue, 29 Aug 2017 00:17:35 +0000 Message-ID: <27D59834-53F7-4509-A962-4D67C4234AE1@akamai.com> References: <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> <47b5b4e3-41c9-6779-4a96-b11650483499@nwtime.org> <1dee3e5d-6906-cf40-d0c3-a387adc2ba42@nwtime.org> In-Reply-To: <1dee3e5d-6906-cf40-d0c3-a387adc2ba42@nwtime.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1b.0.161010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.45.73] Content-ID: <393BBA9620B3E94F92B1A48B3F5C0209@akamai.com> MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-28_13:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1708290002 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-28_13:, , 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=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1708290002 Archived-At: Subject: Re: [Ntp] WGLC for draft-ietf-ntp-using-nts-for-ntp X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "ntp@ietf.org" Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Errors-To: ntp-bounces@ietf.org Sender: "ntp" DQo+ICAgIEkgZG9uJ3QgaGF2ZSB0aW1lIHRvIHJlc3BvbmQgbm93LCBhbmQgc2luY2UgSSdtIGF0 IElTUENTIHRoaXMgd2VlayBJDQogID4gIHByb2JhYmx5IHdvbid0IGhhdmUgdGltZSB0byByZXNw b25kIGJlZm9yZSB0aGUgMzFzdC4NCiAgICANCj4gICAgRGFuaWVsLCBiYXNlZCBvbiBteSBpbml0 aWFsIHJlYWQgb2YgeW91ciByZXNwb25zZSwgbm90aGluZyB5b3UgaGF2ZSBzYWlkDQogPiAgIGNo YW5nZXMgd2hhdCBEYXZlIGFuZCBJIHRoaW5rLg0KDQpIYXMgRGF2ZSBzZWVuIChvciBoZWFyZCBJ IHN1cHBvc2UpIERhbmllbOKAmXMgcmVzcG9uc2U/ICBJZiBub3QsIHBsZWFzZSBrZWVwIHlvdXIg dmlldyBvbiBoaXMgc2VwYXJhdGUuDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18KbnRwIG1haWxpbmcgbGlzdApudHBAaWV0Zi5vcmcKaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9udHAK From nobody Mon Aug 28 17:28:41 2017 Return-Path: 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 D07061321C0 for ; Mon, 28 Aug 2017 17:28:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 h-3n3ZUIUOej for ; Mon, 28 Aug 2017 17:28:38 -0700 (PDT) Received: from chessie.everett.org (chessie.everett.org [IPv6:2001:470:1:205::234]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 166B513219A for ; Mon, 28 Aug 2017 17:28:38 -0700 (PDT) Received: from [10.200.74.153] (nat0.fmt1.everett.org [64.71.190.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by chessie.everett.org (Postfix) with ESMTPSA id B76D9B835; Tue, 29 Aug 2017 00:28:37 +0000 (UTC) To: Daniel Franke Cc: ntp@ietf.org References: <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> <47b5b4e3-41c9-6779-4a96-b11650483499@nwtime.org> <1dee3e5d-6906-cf40-d0c3-a387adc2ba42@nwtime.org> From: Harlan Stenn Message-ID: <2d46f8f8-cdad-c7d7-53a0-ac26c25e594c@nwtime.org> Date: Mon, 28 Aug 2017 17:28:35 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ntp] WGLC for draft-ietf-ntp-using-nts-for-ntp X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Aug 2017 00:28:40 -0000 On 8/28/2017 2:28 PM, Daniel Franke wrote: > On 8/28/17, Harlan Stenn wrote: >> Dave and I still vote "NO" on advancing this document at this time. > > Harlan, your opposition is noted, but your attempt to seize the mantle > of Prof. Mills' authority here is inappropriate I want you to stop. Please focus on responding to our comments. > Prof. Mills could not possibly have read and responded to my comments > in the time it took you to send this reply. Daniel, you're right, Dave hasn't seen your response yet. But you did not address the points we wanted to make, so I'm comfortable with my response and position. > Your original critique, in > which you claim to be speaking for the two of you, is also written > entirely in your style with no indication of what is Prof. Mills' > commentary and what is yours. If it actually makes a different I can try and identify the comments that were Dave's and the comments that were mine. But the bottom line is that Dave and I were/are on the same page on these things. If we did not communicate our reasoning in the way you found optimal, I can try and address this. In the meantime I fall back on the top portion of the message Dave expressly told me to convey to this group: >> Dave: Do not ratify this proposal. It needs more discussion and >> clarification. The proposal as written should NOT be approved. >> >> Harlan: I agree with Dave. >> >> TL;DR version: >> >> There are some parts of the proposal that are wrong, and some other >> parts are misleading. There are sections of the proposal that are >> confusing, and there are sections of the proposal that are >> inadequately described. > I understand that Prof. Mills' health makes it challenging for him to > participate fully in this discussion. We should all do everything we > possibly can to accommodate him. But you are not acting as a faithful > messenger and I will not accept your words as his. I wouldn't say it's his "health", I'd say it's his physical limitations. And I will get your responses to him for his comments, but that almost certainly won't happen before the 31st. -- Harlan Stenn http://networktimefoundation.org - be a member! From ntp-bounces@ietf.org Mon Aug 28 17:28:42 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 35D6813219A; Mon, 28 Aug 2017 17:28:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1503966522; bh=ngtyYiA3sZj/8LKVCP3o0wM3K6FEkkI+sibcY2TE/io=; h=To:References:From:Date:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc; b=c/zYXzg+yRJMgve74n7ACzrfHn4jduktGjAfA1J59KjfUgmW/j30zpqbBZzIhNgil 4E0MM0LKJlJRQF9jJAfD0gfs04zuW5zNPIRkUrorVbbF7q1WoMMdKwM+ZMLb3a+WcM /kMqJ5PxE6nmMAD1y6VPpxYgATadzNpa7a9ZcV4g= 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 D07061321C0 for ; Mon, 28 Aug 2017 17:28:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 h-3n3ZUIUOej for ; Mon, 28 Aug 2017 17:28:38 -0700 (PDT) Received: from chessie.everett.org (chessie.everett.org [IPv6:2001:470:1:205::234]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 166B513219A for ; Mon, 28 Aug 2017 17:28:38 -0700 (PDT) Received: from [10.200.74.153] (nat0.fmt1.everett.org [64.71.190.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by chessie.everett.org (Postfix) with ESMTPSA id B76D9B835; Tue, 29 Aug 2017 00:28:37 +0000 (UTC) To: Daniel Franke References: <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> <47b5b4e3-41c9-6779-4a96-b11650483499@nwtime.org> <1dee3e5d-6906-cf40-d0c3-a387adc2ba42@nwtime.org> From: Harlan Stenn Message-ID: <2d46f8f8-cdad-c7d7-53a0-ac26c25e594c@nwtime.org> Date: Mon, 28 Aug 2017 17:28:35 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US Archived-At: Subject: Re: [Ntp] WGLC for draft-ietf-ntp-using-nts-for-ntp X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: ntp@ietf.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ntp-bounces@ietf.org Sender: "ntp" On 8/28/2017 2:28 PM, Daniel Franke wrote: > On 8/28/17, Harlan Stenn wrote: >> Dave and I still vote "NO" on advancing this document at this time. > > Harlan, your opposition is noted, but your attempt to seize the mantle > of Prof. Mills' authority here is inappropriate I want you to stop. Please focus on responding to our comments. > Prof. Mills could not possibly have read and responded to my comments > in the time it took you to send this reply. Daniel, you're right, Dave hasn't seen your response yet. But you did not address the points we wanted to make, so I'm comfortable with my response and position. > Your original critique, in > which you claim to be speaking for the two of you, is also written > entirely in your style with no indication of what is Prof. Mills' > commentary and what is yours. If it actually makes a different I can try and identify the comments that were Dave's and the comments that were mine. But the bottom line is that Dave and I were/are on the same page on these things. If we did not communicate our reasoning in the way you found optimal, I can try and address this. In the meantime I fall back on the top portion of the message Dave expressly told me to convey to this group: >> Dave: Do not ratify this proposal. It needs more discussion and >> clarification. The proposal as written should NOT be approved. >> >> Harlan: I agree with Dave. >> >> TL;DR version: >> >> There are some parts of the proposal that are wrong, and some other >> parts are misleading. There are sections of the proposal that are >> confusing, and there are sections of the proposal that are >> inadequately described. > I understand that Prof. Mills' health makes it challenging for him to > participate fully in this discussion. We should all do everything we > possibly can to accommodate him. But you are not acting as a faithful > messenger and I will not accept your words as his. I wouldn't say it's his "health", I'd say it's his physical limitations. And I will get your responses to him for his comments, but that almost certainly won't happen before the 31st. -- Harlan Stenn http://networktimefoundation.org - be a member! _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp From nobody Mon Aug 28 17:32:31 2017 Return-Path: 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 E67A5132356 for ; Mon, 28 Aug 2017 17:32:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 ATh13H548hWn for ; Mon, 28 Aug 2017 17:32:28 -0700 (PDT) Received: from chessie.everett.org (chessie.everett.org [IPv6:2001:470:1:205::234]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72717124207 for ; Mon, 28 Aug 2017 17:32:28 -0700 (PDT) Received: from [10.200.74.153] (nat0.fmt1.everett.org [64.71.190.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by chessie.everett.org (Postfix) with ESMTPSA id 2AB8CB835; Tue, 29 Aug 2017 00:32:28 +0000 (UTC) To: "Salz, Rich" , Daniel Franke Cc: "ntp@ietf.org" References: <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> <47b5b4e3-41c9-6779-4a96-b11650483499@nwtime.org> <1dee3e5d-6906-cf40-d0c3-a387adc2ba42@nwtime.org> <27D59834-53F7-4509-A962-4D67C4234AE1@akamai.com> From: Harlan Stenn Message-ID: Date: Mon, 28 Aug 2017 17:32:25 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <27D59834-53F7-4509-A962-4D67C4234AE1@akamai.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ntp] WGLC for draft-ietf-ntp-using-nts-for-ntp X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Aug 2017 00:32:30 -0000 On 8/28/2017 5:17 PM, Salz, Rich wrote: > >> I don't have time to respond now, and since I'm at ISPCS this week I > > probably won't have time to respond before the 31st. > >> Daniel, based on my initial read of your response, nothing you have said > > changes what Dave and I think. > > Has Dave seen (or heard I suppose) Daniel’s response? If not, please keep your view on his separate. As I just replied, no. But, as I also wrote, based on my read of Daniel's response, Daniel did not address the points we raised. If he really did, however, then this reaffirms our point about the document being unclear. -- Harlan Stenn http://networktimefoundation.org - be a member! From ntp-bounces@ietf.org Mon Aug 28 17:32:32 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 076321321E6; Mon, 28 Aug 2017 17:32:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1503966752; bh=V58uydw5WmgRXAGIfuk3GsTjwrntYSntpZgXVcN9dcg=; h=To:References:From:Date:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc; b=DHu4EiPl6++61NMuM8PB/BYUIl+6hO6/uNUr5sx15LljyJNfMBM7Nn4xEgl5Qs+Ra 1/BlhNioYSH91qatI+DJpmo80EoUKZ+o1Vj3Xdg0RDDwK1eWyg2DQzJmQrt26dZXm8 9iCM1ZWhvWO15XXwg8zF9mk7ALiLDiMHRnvJIKT4= 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 E67A5132356 for ; Mon, 28 Aug 2017 17:32:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 ATh13H548hWn for ; Mon, 28 Aug 2017 17:32:28 -0700 (PDT) Received: from chessie.everett.org (chessie.everett.org [IPv6:2001:470:1:205::234]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72717124207 for ; Mon, 28 Aug 2017 17:32:28 -0700 (PDT) Received: from [10.200.74.153] (nat0.fmt1.everett.org [64.71.190.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by chessie.everett.org (Postfix) with ESMTPSA id 2AB8CB835; Tue, 29 Aug 2017 00:32:28 +0000 (UTC) To: "Salz, Rich" , Daniel Franke References: <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> <47b5b4e3-41c9-6779-4a96-b11650483499@nwtime.org> <1dee3e5d-6906-cf40-d0c3-a387adc2ba42@nwtime.org> <27D59834-53F7-4509-A962-4D67C4234AE1@akamai.com> From: Harlan Stenn Message-ID: Date: Mon, 28 Aug 2017 17:32:25 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <27D59834-53F7-4509-A962-4D67C4234AE1@akamai.com> Content-Language: en-US Archived-At: Subject: Re: [Ntp] WGLC for draft-ietf-ntp-using-nts-for-ntp X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "ntp@ietf.org" Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Errors-To: ntp-bounces@ietf.org Sender: "ntp" T24gOC8yOC8yMDE3IDU6MTcgUE0sIFNhbHosIFJpY2ggd3JvdGU6Cj4gCj4+ICAgIEkgZG9uJ3Qg aGF2ZSB0aW1lIHRvIHJlc3BvbmQgbm93LCBhbmQgc2luY2UgSSdtIGF0IElTUENTIHRoaXMgd2Vl ayBJCj4gICA+ICBwcm9iYWJseSB3b24ndCBoYXZlIHRpbWUgdG8gcmVzcG9uZCBiZWZvcmUgdGhl IDMxc3QuCj4gICAgIAo+PiAgICBEYW5pZWwsIGJhc2VkIG9uIG15IGluaXRpYWwgcmVhZCBvZiB5 b3VyIHJlc3BvbnNlLCBub3RoaW5nIHlvdSBoYXZlIHNhaWQKPiAgPiAgIGNoYW5nZXMgd2hhdCBE YXZlIGFuZCBJIHRoaW5rLgo+IAo+IEhhcyBEYXZlIHNlZW4gKG9yIGhlYXJkIEkgc3VwcG9zZSkg RGFuaWVs4oCZcyByZXNwb25zZT8gIElmIG5vdCwgcGxlYXNlIGtlZXAgeW91ciB2aWV3IG9uIGhp cyBzZXBhcmF0ZS4KCkFzIEkganVzdCByZXBsaWVkLCBuby4gIEJ1dCwgYXMgSSBhbHNvIHdyb3Rl LCBiYXNlZCBvbiBteSByZWFkIG9mCkRhbmllbCdzIHJlc3BvbnNlLCBEYW5pZWwgZGlkIG5vdCBh ZGRyZXNzIHRoZSBwb2ludHMgd2UgcmFpc2VkLiAgSWYgaGUKcmVhbGx5IGRpZCwgaG93ZXZlciwg dGhlbiB0aGlzIHJlYWZmaXJtcyBvdXIgcG9pbnQgYWJvdXQgdGhlIGRvY3VtZW50CmJlaW5nIHVu Y2xlYXIuCgotLSAKSGFybGFuIFN0ZW5uIDxzdGVubkBud3RpbWUub3JnPgpodHRwOi8vbmV0d29y a3RpbWVmb3VuZGF0aW9uLm9yZyAtIGJlIGEgbWVtYmVyIQoKX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18KbnRwIG1haWxpbmcgbGlzdApudHBAaWV0Zi5vcmcK aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9udHAK From nobody Mon Aug 28 19:21:45 2017 Return-Path: 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 4BBEE120721 for ; Mon, 28 Aug 2017 19:21:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, URIBL_BLOCKED=0.001] autolearn=ham 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 SBM_XXKUB-Kn for ; Mon, 28 Aug 2017 19:21:42 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0052.outbound.protection.outlook.com [104.47.34.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C9C9132192 for ; Mon, 28 Aug 2017 19:21:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isoc.org; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=6X7SyuVCIp09frw+8HqGPLvHqcmObyPH6oqZgfyRDSQ=; b=QH/sfXYE8xCjC0A1jocIMU69CCAf3n4BNnatXApDgveOILkuW/mhm3S02qt6+T9cY1NsJmz1DYPUwmdrPsTMcU9nrP/bLrHVsUUinofwc8mmVtVMjOnQ1FoIufJpPogayKv+BEyNBQ49tqo1zfQEZa/7DTFN+U2mN8/7ZZZjrow= Received: from CY4PR06MB2456.namprd06.prod.outlook.com (10.169.186.136) by CY4PR06MB3063.namprd06.prod.outlook.com (10.173.43.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1385.9; Tue, 29 Aug 2017 02:21:37 +0000 Received: from CY4PR06MB2456.namprd06.prod.outlook.com ([10.169.186.136]) by CY4PR06MB2456.namprd06.prod.outlook.com ([10.169.186.136]) with mapi id 15.01.1385.014; Tue, 29 Aug 2017 02:21:37 +0000 From: Karen O'Donoghue To: Harlan Stenn , Daniel Franke , Rich Salz CC: "ntp@ietf.org" Thread-Topic: [Ntp] WGLC for draft-ietf-ntp-using-nts-for-ntp Thread-Index: AQHTEMnCjue8Luaa4E6rvQH1AttmiKKZVNUAgAELHACAAAQ7AIAAMq2AgAAEJYCAAB58gA== Date: Tue, 29 Aug 2017 02:21:37 +0000 Message-ID: <7399DDDE-E303-44C9-AE30-3A06239D3F0F@isoc.org> References: <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> <47b5b4e3-41c9-6779-4a96-b11650483499@nwtime.org> <1dee3e5d-6906-cf40-d0c3-a387adc2ba42@nwtime.org> <27D59834-53F7-4509-A962-4D67C4234AE1@akamai.com> In-Reply-To: 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: [24.245.108.20] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR06MB3063; 6:L+BZSUcMuv7Iea7Xl2Ev2NzaluiETVq980Pn51bZbah/Nd8puLMbuLCFOVrw+0qy4lHuH+tgQDAWDXNAyjU61Kao5t0G6uFLfNs3j2WqCstJgaxPumjbR2UX511QXrLwbcNm3mymeAFCo8fMWLZ0mi7pFQUkIMzE2g4YN+/oMIEp+dlCylLbZg878ypfc56+lUDMi48rklmFWWudwpSvh6lsWUzU9C1/uCyeTrsaePKl7TlqAmsvdnRHUgI4yDf+XhUja3F1Fg9zGLTBdzC8R83YN97uJWbdow4oiaYpr3QV/JD7fPcvQ1wRiuQgrz472UNTNdll1toQVE/plorp/w==; 5:PVIzrDHVu00KxqIvcvZ5SlyC4wI0uiDYcBaKIyU/Fl0yTcibOole9ZGsI+l6tbEewFthDdkE3UC0UsXJ6NCRC94OWTVewJHJf0rFsqi9Utbmbv0z2qCCallXn5q3vTWF+qAixY4/z0gTyewf/WK4zg==; 24:8CBwJDk5IbmkJ36FH4w2Rnyh7Rq1Zo0FNlS2Uzn1yWKOAQ2WuoiZGHDjWfH2VIrxM5NF/1aF8MSvuQCEItJGjvKp/fBVRBYcNJjnH/2GZj8=; 7:Rqu1/i4I/Bx//ePEhVppRDpudsPmd2E0CU3sKihKy/Vlj1WIpDwOhipOzMywk0SiKhFTAzcOh60mi1/zPDowvYdHauwj6DWdpp3LHPidgKr1bvo3EKu7IOCPl8EKR9J8K2WfkIplqoe5buW+G6ZNk7n4lz470hS82Y1AdVKV79BITQ+X753dFC3XBRRXuiJLxXjhIhB6rp9DYaziMnbEdcgEFBVpdMQqN6u/+q8cXZQ= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 1ee6ddb5-5fe4-4c4b-c7a6-08d4ee84ad32 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY4PR06MB3063; x-ms-traffictypediagnostic: CY4PR06MB3063: x-exchange-antispam-report-test: UriScan:(35073007944872); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(10201501046)(93006095)(93001095)(3002001)(6041248)(20161123560025)(20161123562025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR06MB3063; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR06MB3063; x-forefront-prvs: 0414DF926F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39830400002)(189002)(377454003)(199003)(24454002)(53386004)(25786009)(105586002)(106356001)(2906002)(7736002)(230783001)(6246003)(3660700001)(68736007)(14454004)(3280700002)(305945005)(478600001)(86362001)(2900100001)(966005)(54356999)(76176999)(39060400002)(33656002)(101416001)(82746002)(50986999)(2950100002)(8676002)(66066001)(81166006)(53546010)(189998001)(81156014)(93886005)(97736004)(6512007)(77096006)(6306002)(6116002)(36756003)(3846002)(99286003)(102836003)(5660300001)(4326008)(6486002)(6506006)(83716003)(53936002)(8936002)(6436002)(229853002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR06MB3063; H:CY4PR06MB2456.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: isoc.org does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Aug 2017 02:21:37.3400 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR06MB3063 Archived-At: Subject: Re: [Ntp] WGLC for draft-ietf-ntp-using-nts-for-ntp X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Aug 2017 02:21:44 -0000 R2VudGxlbWVuLA0KDQpUaGUgdG9uZSBvZiB0aGlzIGNvbnZlcnNhdGlvbiBpcyBub3QgaGVscGZ1 bCBvciBwcm9kdWN0aXZlLiBQbGVhc2UgbGltaXQgYWxsIGRpc2N1c3Npb24gdG8gdGhlIG1lcml0 cyBvZiB0aGUgdGVjaG5pY2FsIHBvaW50cyBiZWluZyByYWlzZWQuIA0KDQpIYXJsYW4sIHdoaWxl IEkgdW5kZXJzdGFuZCB0aGF0IERhdmUgTWlsbHMgaXMgdW5hYmxlIHRvIHBhcnRpY2lwYXRlIGZ1 bGx5IGluIHRoZSBtYWlsaW5nIGxpc3QgZm9yIGhlYWx0aCByZWFzb25zLCBJIGFzayB5b3UgdG8g bGltaXQgeW91ciBjb21tZW50cyBhbmQgZGlzY3Vzc2lvbiB0byB5b3VyIHBlcnNvbmFsIG9waW5p b25zIG9ubHkuIEFueXRoaW5nIGVsc2UgaXMgaGVhcnNheS4gDQoNClRvIGZhY2lsaXRhdGUgRGF2 ZeKAmXMgcGFydGljaXBhdGlvbiwgRGlldGVyIGFuZCBJIHdpbGwgcmVhY2ggb3V0IHRvIERhdmUg TWlsbHMgYXMgV0cgY2hhaXJzIHRvIHByb3ZpZGUgaGltIGFuIG9wcG9ydHVuaXR5IHRvIGNvbW1l bnQuIEFkZGl0aW9uYWxseSwgd2Ugd2lsbCBzY2hlZHVsZSBhIHZpcnR1YWwgaW50ZXJpbSB0byBh ZGRyZXNzIGNvbW1lbnRzIHJlY2VpdmVkIG9uIHRoaXMgV0dMQywgYW5kIHRoYXQgd2lsbCBwcm92 aWRlIGFuIGFkZGl0aW9uYWwgb3Bwb3J0dW5pdHkgZm9yIERhdmUgdG8gcGVyc29uYWxseSBleHBy ZXNzIGhpcyBvcGluaW9ucyBhbmQgaW50ZXJhY3Qgd2l0aCB0aGUgd29ya2luZyBncm91cC4gDQoN CkFsbCB3b3JraW5nIGdyb3VwIG1lbWJlcnM6ICBQbGVhc2Ugbm90ZSB0aGF0IHRoZSBXR0xDIG9u IHRoaXMgZG9jdW1lbnQgaGFzIGJlZW4gb3V0IGZvciBhbG1vc3QgdGhyZWUgd2Vla3MsIGFuZCB0 aGUgb25seSBzZXQgb2YgY29tbWVudHMgcmVjZWl2ZWQgdG8gZGF0ZSBhcmUgSGFybGFu4oCZcy4g UGxlYXNlIHJldmlldyBhbmQgY29tbWVudCBpbW1lZGlhdGVseSBvciBEaWV0ZXIgYW5kIEkgd2ls bCBub3QgaGF2ZSBzdWZmaWNpZW50IGluZm9ybWF0aW9uIHRvIGRldGVybWluZSBjb25zZW5zdXMu IA0KDQpLYXJlbg0KDQoNCg0KPiBPbiBBdWcgMjgsIDIwMTcsIGF0IDg6MzIgUE0sIEhhcmxhbiBT dGVubiA8c3Rlbm5Abnd0aW1lLm9yZz4gd3JvdGU6DQo+IA0KPiBPbiA4LzI4LzIwMTcgNToxNyBQ TSwgU2FseiwgUmljaCB3cm90ZToNCj4+IA0KPj4+ICAgSSBkb24ndCBoYXZlIHRpbWUgdG8gcmVz cG9uZCBub3csIGFuZCBzaW5jZSBJJ20gYXQgSVNQQ1MgdGhpcyB3ZWVrIEkNCj4+PiBwcm9iYWJs eSB3b24ndCBoYXZlIHRpbWUgdG8gcmVzcG9uZCBiZWZvcmUgdGhlIDMxc3QuDQo+PiANCj4+PiAg IERhbmllbCwgYmFzZWQgb24gbXkgaW5pdGlhbCByZWFkIG9mIHlvdXIgcmVzcG9uc2UsIG5vdGhp bmcgeW91IGhhdmUgc2FpZA0KPj4+ICBjaGFuZ2VzIHdoYXQgRGF2ZSBhbmQgSSB0aGluay4NCj4+ IA0KPj4gSGFzIERhdmUgc2VlbiAob3IgaGVhcmQgSSBzdXBwb3NlKSBEYW5pZWzigJlzIHJlc3Bv bnNlPyAgSWYgbm90LCBwbGVhc2Uga2VlcCB5b3VyIHZpZXcgb24gaGlzIHNlcGFyYXRlLg0KPiAN Cj4gQXMgSSBqdXN0IHJlcGxpZWQsIG5vLiAgQnV0LCBhcyBJIGFsc28gd3JvdGUsIGJhc2VkIG9u IG15IHJlYWQgb2YNCj4gRGFuaWVsJ3MgcmVzcG9uc2UsIERhbmllbCBkaWQgbm90IGFkZHJlc3Mg dGhlIHBvaW50cyB3ZSByYWlzZWQuICBJZiBoZQ0KPiByZWFsbHkgZGlkLCBob3dldmVyLCB0aGVu IHRoaXMgcmVhZmZpcm1zIG91ciBwb2ludCBhYm91dCB0aGUgZG9jdW1lbnQNCj4gYmVpbmcgdW5j bGVhci4NCj4gDQo+IC0tIA0KPiBIYXJsYW4gU3Rlbm4gPHN0ZW5uQG53dGltZS5vcmc+DQo+IGh0 dHA6Ly9uZXR3b3JrdGltZWZvdW5kYXRpb24ub3JnIC0gYmUgYSBtZW1iZXIhDQo+IA0KPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBudHAgbWFpbGlu ZyBsaXN0DQo+IG50cEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL250cA0KDQo= From ntp-bounces@ietf.org Mon Aug 28 19:21:45 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 679BF12422F; Mon, 28 Aug 2017 19:21:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1503973305; bh=Gg0jdNB6jNl8V7/9Y4ZBL0DpLc0/Z0UaeH1JDOZLg3w=; h=From:To:Date:References:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc; b=KlPMfVEYjxJV9Mwya+SJku+lKRdZC5CaZBse2GKQd197LjIKUf2lFja8HPiIK3juE 2ArVAvFQgxvME+VijPheUkzHluu4KcJxOCA3BwU/0IdATilmWiwTpfD2dKo8TzX9+K +OfP5/ilbG90g4Q70mM4EXErtLBTHLE9P03lAAIA= 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 4BBEE120721 for ; Mon, 28 Aug 2017 19:21:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, URIBL_BLOCKED=0.001] autolearn=ham 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 SBM_XXKUB-Kn for ; Mon, 28 Aug 2017 19:21:42 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0052.outbound.protection.outlook.com [104.47.34.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C9C9132192 for ; Mon, 28 Aug 2017 19:21:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isoc.org; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=6X7SyuVCIp09frw+8HqGPLvHqcmObyPH6oqZgfyRDSQ=; b=QH/sfXYE8xCjC0A1jocIMU69CCAf3n4BNnatXApDgveOILkuW/mhm3S02qt6+T9cY1NsJmz1DYPUwmdrPsTMcU9nrP/bLrHVsUUinofwc8mmVtVMjOnQ1FoIufJpPogayKv+BEyNBQ49tqo1zfQEZa/7DTFN+U2mN8/7ZZZjrow= Received: from CY4PR06MB2456.namprd06.prod.outlook.com (10.169.186.136) by CY4PR06MB3063.namprd06.prod.outlook.com (10.173.43.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1385.9; Tue, 29 Aug 2017 02:21:37 +0000 Received: from CY4PR06MB2456.namprd06.prod.outlook.com ([10.169.186.136]) by CY4PR06MB2456.namprd06.prod.outlook.com ([10.169.186.136]) with mapi id 15.01.1385.014; Tue, 29 Aug 2017 02:21:37 +0000 From: Karen O'Donoghue To: Harlan Stenn , Daniel Franke , Rich Salz Thread-Topic: [Ntp] WGLC for draft-ietf-ntp-using-nts-for-ntp Thread-Index: AQHTEMnCjue8Luaa4E6rvQH1AttmiKKZVNUAgAELHACAAAQ7AIAAMq2AgAAEJYCAAB58gA== Date: Tue, 29 Aug 2017 02:21:37 +0000 Message-ID: <7399DDDE-E303-44C9-AE30-3A06239D3F0F@isoc.org> References: <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> <47b5b4e3-41c9-6779-4a96-b11650483499@nwtime.org> <1dee3e5d-6906-cf40-d0c3-a387adc2ba42@nwtime.org> <27D59834-53F7-4509-A962-4D67C4234AE1@akamai.com> In-Reply-To: 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: [24.245.108.20] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR06MB3063; 6:L+BZSUcMuv7Iea7Xl2Ev2NzaluiETVq980Pn51bZbah/Nd8puLMbuLCFOVrw+0qy4lHuH+tgQDAWDXNAyjU61Kao5t0G6uFLfNs3j2WqCstJgaxPumjbR2UX511QXrLwbcNm3mymeAFCo8fMWLZ0mi7pFQUkIMzE2g4YN+/oMIEp+dlCylLbZg878ypfc56+lUDMi48rklmFWWudwpSvh6lsWUzU9C1/uCyeTrsaePKl7TlqAmsvdnRHUgI4yDf+XhUja3F1Fg9zGLTBdzC8R83YN97uJWbdow4oiaYpr3QV/JD7fPcvQ1wRiuQgrz472UNTNdll1toQVE/plorp/w==; 5:PVIzrDHVu00KxqIvcvZ5SlyC4wI0uiDYcBaKIyU/Fl0yTcibOole9ZGsI+l6tbEewFthDdkE3UC0UsXJ6NCRC94OWTVewJHJf0rFsqi9Utbmbv0z2qCCallXn5q3vTWF+qAixY4/z0gTyewf/WK4zg==; 24:8CBwJDk5IbmkJ36FH4w2Rnyh7Rq1Zo0FNlS2Uzn1yWKOAQ2WuoiZGHDjWfH2VIrxM5NF/1aF8MSvuQCEItJGjvKp/fBVRBYcNJjnH/2GZj8=; 7:Rqu1/i4I/Bx//ePEhVppRDpudsPmd2E0CU3sKihKy/Vlj1WIpDwOhipOzMywk0SiKhFTAzcOh60mi1/zPDowvYdHauwj6DWdpp3LHPidgKr1bvo3EKu7IOCPl8EKR9J8K2WfkIplqoe5buW+G6ZNk7n4lz470hS82Y1AdVKV79BITQ+X753dFC3XBRRXuiJLxXjhIhB6rp9DYaziMnbEdcgEFBVpdMQqN6u/+q8cXZQ= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 1ee6ddb5-5fe4-4c4b-c7a6-08d4ee84ad32 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY4PR06MB3063; x-ms-traffictypediagnostic: CY4PR06MB3063: x-exchange-antispam-report-test: UriScan:(35073007944872); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(10201501046)(93006095)(93001095)(3002001)(6041248)(20161123560025)(20161123562025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR06MB3063; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR06MB3063; x-forefront-prvs: 0414DF926F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39830400002)(189002)(377454003)(199003)(24454002)(53386004)(25786009)(105586002)(106356001)(2906002)(7736002)(230783001)(6246003)(3660700001)(68736007)(14454004)(3280700002)(305945005)(478600001)(86362001)(2900100001)(966005)(54356999)(76176999)(39060400002)(33656002)(101416001)(82746002)(50986999)(2950100002)(8676002)(66066001)(81166006)(53546010)(189998001)(81156014)(93886005)(97736004)(6512007)(77096006)(6306002)(6116002)(36756003)(3846002)(99286003)(102836003)(5660300001)(4326008)(6486002)(6506006)(83716003)(53936002)(8936002)(6436002)(229853002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR06MB3063; H:CY4PR06MB2456.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: isoc.org does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: MIME-Version: 1.0 X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Aug 2017 02:21:37.3400 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR06MB3063 Archived-At: Subject: Re: [Ntp] WGLC for draft-ietf-ntp-using-nts-for-ntp X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "ntp@ietf.org" Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Errors-To: ntp-bounces@ietf.org Sender: "ntp" R2VudGxlbWVuLA0KDQpUaGUgdG9uZSBvZiB0aGlzIGNvbnZlcnNhdGlvbiBpcyBub3QgaGVscGZ1 bCBvciBwcm9kdWN0aXZlLiBQbGVhc2UgbGltaXQgYWxsIGRpc2N1c3Npb24gdG8gdGhlIG1lcml0 cyBvZiB0aGUgdGVjaG5pY2FsIHBvaW50cyBiZWluZyByYWlzZWQuIA0KDQpIYXJsYW4sIHdoaWxl IEkgdW5kZXJzdGFuZCB0aGF0IERhdmUgTWlsbHMgaXMgdW5hYmxlIHRvIHBhcnRpY2lwYXRlIGZ1 bGx5IGluIHRoZSBtYWlsaW5nIGxpc3QgZm9yIGhlYWx0aCByZWFzb25zLCBJIGFzayB5b3UgdG8g bGltaXQgeW91ciBjb21tZW50cyBhbmQgZGlzY3Vzc2lvbiB0byB5b3VyIHBlcnNvbmFsIG9waW5p b25zIG9ubHkuIEFueXRoaW5nIGVsc2UgaXMgaGVhcnNheS4gDQoNClRvIGZhY2lsaXRhdGUgRGF2 ZeKAmXMgcGFydGljaXBhdGlvbiwgRGlldGVyIGFuZCBJIHdpbGwgcmVhY2ggb3V0IHRvIERhdmUg TWlsbHMgYXMgV0cgY2hhaXJzIHRvIHByb3ZpZGUgaGltIGFuIG9wcG9ydHVuaXR5IHRvIGNvbW1l bnQuIEFkZGl0aW9uYWxseSwgd2Ugd2lsbCBzY2hlZHVsZSBhIHZpcnR1YWwgaW50ZXJpbSB0byBh ZGRyZXNzIGNvbW1lbnRzIHJlY2VpdmVkIG9uIHRoaXMgV0dMQywgYW5kIHRoYXQgd2lsbCBwcm92 aWRlIGFuIGFkZGl0aW9uYWwgb3Bwb3J0dW5pdHkgZm9yIERhdmUgdG8gcGVyc29uYWxseSBleHBy ZXNzIGhpcyBvcGluaW9ucyBhbmQgaW50ZXJhY3Qgd2l0aCB0aGUgd29ya2luZyBncm91cC4gDQoN CkFsbCB3b3JraW5nIGdyb3VwIG1lbWJlcnM6ICBQbGVhc2Ugbm90ZSB0aGF0IHRoZSBXR0xDIG9u IHRoaXMgZG9jdW1lbnQgaGFzIGJlZW4gb3V0IGZvciBhbG1vc3QgdGhyZWUgd2Vla3MsIGFuZCB0 aGUgb25seSBzZXQgb2YgY29tbWVudHMgcmVjZWl2ZWQgdG8gZGF0ZSBhcmUgSGFybGFu4oCZcy4g UGxlYXNlIHJldmlldyBhbmQgY29tbWVudCBpbW1lZGlhdGVseSBvciBEaWV0ZXIgYW5kIEkgd2ls bCBub3QgaGF2ZSBzdWZmaWNpZW50IGluZm9ybWF0aW9uIHRvIGRldGVybWluZSBjb25zZW5zdXMu IA0KDQpLYXJlbg0KDQoNCg0KPiBPbiBBdWcgMjgsIDIwMTcsIGF0IDg6MzIgUE0sIEhhcmxhbiBT dGVubiA8c3Rlbm5Abnd0aW1lLm9yZz4gd3JvdGU6DQo+IA0KPiBPbiA4LzI4LzIwMTcgNToxNyBQ TSwgU2FseiwgUmljaCB3cm90ZToNCj4+IA0KPj4+ICAgSSBkb24ndCBoYXZlIHRpbWUgdG8gcmVz cG9uZCBub3csIGFuZCBzaW5jZSBJJ20gYXQgSVNQQ1MgdGhpcyB3ZWVrIEkNCj4+PiBwcm9iYWJs eSB3b24ndCBoYXZlIHRpbWUgdG8gcmVzcG9uZCBiZWZvcmUgdGhlIDMxc3QuDQo+PiANCj4+PiAg IERhbmllbCwgYmFzZWQgb24gbXkgaW5pdGlhbCByZWFkIG9mIHlvdXIgcmVzcG9uc2UsIG5vdGhp bmcgeW91IGhhdmUgc2FpZA0KPj4+ICBjaGFuZ2VzIHdoYXQgRGF2ZSBhbmQgSSB0aGluay4NCj4+ IA0KPj4gSGFzIERhdmUgc2VlbiAob3IgaGVhcmQgSSBzdXBwb3NlKSBEYW5pZWzigJlzIHJlc3Bv bnNlPyAgSWYgbm90LCBwbGVhc2Uga2VlcCB5b3VyIHZpZXcgb24gaGlzIHNlcGFyYXRlLg0KPiAN Cj4gQXMgSSBqdXN0IHJlcGxpZWQsIG5vLiAgQnV0LCBhcyBJIGFsc28gd3JvdGUsIGJhc2VkIG9u IG15IHJlYWQgb2YNCj4gRGFuaWVsJ3MgcmVzcG9uc2UsIERhbmllbCBkaWQgbm90IGFkZHJlc3Mg dGhlIHBvaW50cyB3ZSByYWlzZWQuICBJZiBoZQ0KPiByZWFsbHkgZGlkLCBob3dldmVyLCB0aGVu IHRoaXMgcmVhZmZpcm1zIG91ciBwb2ludCBhYm91dCB0aGUgZG9jdW1lbnQNCj4gYmVpbmcgdW5j bGVhci4NCj4gDQo+IC0tIA0KPiBIYXJsYW4gU3Rlbm4gPHN0ZW5uQG53dGltZS5vcmc+DQo+IGh0 dHA6Ly9uZXR3b3JrdGltZWZvdW5kYXRpb24ub3JnIC0gYmUgYSBtZW1iZXIhDQo+IA0KPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBudHAgbWFpbGlu ZyBsaXN0DQo+IG50cEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL250cA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXwpudHAgbWFpbGluZyBsaXN0Cm50cEBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL250cAo= From ntp-bounces@ietf.org Mon Aug 28 19:25:10 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ED8F1321EC; Mon, 28 Aug 2017 19:25:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1503973510; bh=6Rz+LePZk7LebSeaLsD/0v7VrG05T00fKRZZjGqYMAA=; h=From:To:Date:References:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc; b=N4oHOP66WM9FfsH1EbxroZT0C1+iIQJdrfMHd6DalzeUTFcTRNrOrB/FNU0J0XRzR bNyMX4M6NvQF8Fwz6ZJ5BYzV+eD9iJnWRCqWep5cL+3VRMkGmawaw2iWtNA5x28DLz 8ZsN/JsFAOK0NaDOPOJXVY9wqtMGZq6jzPZNLBMA= 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 C7489132192; Mon, 28 Aug 2017 19:25:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 BPqIwmJZSHLe; Mon, 28 Aug 2017 19:25:05 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0088.outbound.protection.outlook.com [104.47.32.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BDF3120721; Mon, 28 Aug 2017 19:25:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isoc.org; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=qBFsibk0BJOGzHh1Wg4ae6EPXFcw3DkfSJdJrE7U5Kc=; b=BTX35ZWAZGP/FUZ29265f4W3DW5c38QXXr2A+rVRDWLHzhx/sHEeouAGzwP2liLk9s5ObnsUcim88CeBZQS149iJdPClmurSShMQY1ijx1XvV0eaaALhLaaOtO4BCgIhBRG0weFq2w9CsA/y8LJP8fXtG4dMCantbAYGwGSOniw= Received: from CY4PR06MB2456.namprd06.prod.outlook.com (10.169.186.136) by CY4PR06MB2805.namprd06.prod.outlook.com (10.175.117.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1385.9; Tue, 29 Aug 2017 02:25:02 +0000 Received: from CY4PR06MB2456.namprd06.prod.outlook.com ([10.169.186.136]) by CY4PR06MB2456.namprd06.prod.outlook.com ([10.169.186.136]) with mapi id 15.01.1385.014; Tue, 29 Aug 2017 02:25:02 +0000 From: Karen O'Donoghue To: "ntp@ietf.org" Thread-Topic: REMINDER: WGLC for draft-ietf-ntp-using-nts-for-ntp Thread-Index: AQHTEMnCjue8Luaa4E6rvQH1AttmiKKaum+A Date: Tue, 29 Aug 2017 02:25:02 +0000 Message-ID: <766290C1-0828-4DAC-9437-4FF1EE5DC02E@isoc.org> References: <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> In-Reply-To: <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [24.245.108.20] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR06MB2805; 6:0P8szQ2Do58qBjUgxSO5cbT5/fQ8YOIC6ZFzgT936UHcfIYM7p1QryFSEdF2zGiuzEkh4C3B0Kpe+tFn5Zr6NZxZbfDFdn0arL5kqwMtdRPEGfF78x8kg9jQ6o/83lCdbTAY70EC2oeJFneXdi/fHjwFb6izc5oK6o4nu8NpzIOl/slBwmcIiqe3vMWLsuWZ8RODzfOHdf5iEA+5pw7avr/04qf8C3YrjbFBZZsvDyiQaurHGktLXxRiv2NXmbs7JGxu3pz+EbBSqZgXUuJYySSWRkpS/tyU3vZRIItGHnLdWO4s7PX5m2rdlFqfgnWkhjC1oXnMTxT2keBF1NaDOQ==; 5:CcUyN+Wdl6Eai7gspvjsvlLbjRSkCVrKEqWSvshBVu/aF7LuMagLg+zqoGNS6HOAdPmmGU3I1PLnQZtRTNNDv/z6N91sqwfzEf25ldHR4RVNb+iDP8F2G24wPx1rvG/iOeRAeKHWKZUzdX/ZFJ0nNw==; 24:m8xEHebbBiDJTMRgRaMSmpjwFkWs2pLilf1pNVKoHoo9C5QvTkBPSPv3+tngKfJF2XSXH5TrUHsM4+MzNvk5Xw25u85pF1Ev1VNZTRSrJLM=; 7:GCmSrt1oww89YqH6aYd/mCSQgeAZnpJXQ4PG1+fnEj1+lqukUUF9TjE83rjuN3DW+lPHfl2O8BavP048OeumBZNgesaqDKQ5tZWcMP1nC9PtqL8dLEUcoIJiDnZ6nGuydO6AgM5WFUl+w932CW10Ns4QCuNG5n0wrqNdietaAaLeQU8IIeOWhBPVYWl4JVMU52NE37t9+bEh44FpDmKRlSXI7nWArGNUNnuckgwNFo4= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: bc82cbc0-d31f-4041-f90c-08d4ee85276c x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY4PR06MB2805; x-ms-traffictypediagnostic: CY4PR06MB2805: x-exchange-antispam-report-test: UriScan:(120809045254105)(192374486261705)(100405760836317); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(3002001)(6041248)(20161123555025)(20161123560025)(20161123562025)(20161123564025)(20161123558100)(201703131423075)(201703061421075)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR06MB2805; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR06MB2805; x-forefront-prvs: 0414DF926F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(24454002)(12213003)(189002)(199003)(377454003)(450100002)(33656002)(99286003)(2900100001)(36756003)(53936002)(230783001)(110136004)(50986999)(6512007)(6306002)(68736007)(83716003)(6486002)(81156014)(77096006)(2501003)(6506006)(8676002)(97736004)(189998001)(966005)(81166006)(6116002)(102836003)(3846002)(8936002)(1730700003)(5640700003)(2351001)(6436002)(66066001)(3660700001)(305945005)(3280700002)(6916009)(4326008)(5660300001)(2950100002)(53546010)(7736002)(14454004)(82746002)(106356001)(76176999)(2906002)(25786009)(54356999)(86362001)(508600001)(101416001)(105586002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR06MB2805; H:CY4PR06MB2456.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: isoc.org does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=odonoghue@isoc.org; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: <366E8662DA305640BFEFC5048F8994FC@namprd06.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Aug 2017 02:25:02.4659 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR06MB2805 Archived-At: Subject: [Ntp] REMINDER: WGLC for draft-ietf-ntp-using-nts-for-ntp X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "tictoc@ietf.org" Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Errors-To: ntp-bounces@ietf.org Sender: "ntp" Rm9sa3MsDQoNClRoZSB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBmb3IgdGhpcyBkb2N1bWVudCBo YXMgYmVlbiBvdXQgZm9yIGFsbW9zdCB0aHJlZSB3ZWVrcyBub3cuIFBsZWFzZSByZXNwb25kIGlt bWVkaWF0ZWx5IHdpdGggdGVjaG5pY2FsIGNvbW1lbnRzIGFuZCBhbiBpbmRpY2F0aW9uIG9mIHdo ZXRoZXIgb3Igbm90IHlvdSBhcHByb3ZlIHRoZSBhZHZhbmNlbWVudCBvZiB0aGlzIGRvY3VtZW50 LiANCg0KUmVnYXJkcywNCkthcmVuDQoNCj4gT24gQXVnIDksIDIwMTcsIGF0IDEyOjQxIEFNLCBL YXJlbiBPJ0Rvbm9naHVlIDxvZG9ub2dodWVAaXNvYy5vcmc+IHdyb3RlOg0KPiANCj4gRm9sa3Ms DQo+IA0KPiBUaGlzIGJlZ2lucyBhIHRocmVlIHdlZWsgd29ya2luZyBncm91cCBsYXN0IGNhbGwg KFdHTEMpIGZvciAiTmV0d29yayBUaW1lIFNlY3VyaXR5IGZvciB0aGUgTmV0d29yayBUaW1lIFBy b3RvY29s4oCdLg0KPiANCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt aWV0Zi1udHAtdXNpbmctbnRzLWZvci1udHAvDQo+IA0KPiBQbGVhc2UgcmV2aWV3IGFuZCBwcm92 aWRlIGNvbW1lbnRzIHRvIHRoZSBtYWlsaW5nIGxpc3QgYnkgbm8gbGF0ZXIgdGhhbiAzMSBBdWd1 c3QgMjAxNy4gRWFybGllciBjb21tZW50cyBhbmQgZGlzY3Vzc2lvbiB3b3VsZCBiZSBhcHByZWNp YXRlZC4gUGxlYXNlIG5vdGUgdGhhdCB0aGUgY2hhaXJzIHdpbGwgYmUgdXNpbmcgdGhpcyBXR0xD IHRvIGRldGVybWluZSBjb25zZW5zdXMgdG8gbW92ZSB0aGlzIGRvY3VtZW50IGZvcndhcmQgdG8g dGhlIElFU0cuIA0KPiANCj4gQWxzbywgYXMgYSByZW1pbmRlciwgd2UgaGF2ZSBtaWdyYXRlZCB0 aGUgd29ya2luZyBncm91cCBtYWlsaW5nIGxpc3QgdG8gSUVURiBpbmZyYXN0cnVjdHVyZS4gUGxl YXNlIHJlc3BvbmQgdG8gbnRwQGlldGYub3JnLiBdDQo+IA0KPiBSZWdhcmRzLA0KPiBLYXJlbiBh bmQgRGlldGVyDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+IG50cCBtYWlsaW5nIGxpc3QNCj4gbnRwQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbnRwDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fCm50cCBtYWlsaW5nIGxpc3QKbnRwQGlldGYub3JnCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbnRwCg== From nobody Mon Aug 28 19:25:15 2017 Return-Path: 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 C7489132192; Mon, 28 Aug 2017 19:25:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 BPqIwmJZSHLe; Mon, 28 Aug 2017 19:25:05 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0088.outbound.protection.outlook.com [104.47.32.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BDF3120721; Mon, 28 Aug 2017 19:25:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isoc.org; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=qBFsibk0BJOGzHh1Wg4ae6EPXFcw3DkfSJdJrE7U5Kc=; b=BTX35ZWAZGP/FUZ29265f4W3DW5c38QXXr2A+rVRDWLHzhx/sHEeouAGzwP2liLk9s5ObnsUcim88CeBZQS149iJdPClmurSShMQY1ijx1XvV0eaaALhLaaOtO4BCgIhBRG0weFq2w9CsA/y8LJP8fXtG4dMCantbAYGwGSOniw= Received: from CY4PR06MB2456.namprd06.prod.outlook.com (10.169.186.136) by CY4PR06MB2805.namprd06.prod.outlook.com (10.175.117.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1385.9; Tue, 29 Aug 2017 02:25:02 +0000 Received: from CY4PR06MB2456.namprd06.prod.outlook.com ([10.169.186.136]) by CY4PR06MB2456.namprd06.prod.outlook.com ([10.169.186.136]) with mapi id 15.01.1385.014; Tue, 29 Aug 2017 02:25:02 +0000 From: Karen O'Donoghue To: "ntp@ietf.org" CC: "tictoc@ietf.org" Thread-Topic: REMINDER: WGLC for draft-ietf-ntp-using-nts-for-ntp Thread-Index: AQHTEMnCjue8Luaa4E6rvQH1AttmiKKaum+A Date: Tue, 29 Aug 2017 02:25:02 +0000 Message-ID: <766290C1-0828-4DAC-9437-4FF1EE5DC02E@isoc.org> References: <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> In-Reply-To: <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [24.245.108.20] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR06MB2805; 6:0P8szQ2Do58qBjUgxSO5cbT5/fQ8YOIC6ZFzgT936UHcfIYM7p1QryFSEdF2zGiuzEkh4C3B0Kpe+tFn5Zr6NZxZbfDFdn0arL5kqwMtdRPEGfF78x8kg9jQ6o/83lCdbTAY70EC2oeJFneXdi/fHjwFb6izc5oK6o4nu8NpzIOl/slBwmcIiqe3vMWLsuWZ8RODzfOHdf5iEA+5pw7avr/04qf8C3YrjbFBZZsvDyiQaurHGktLXxRiv2NXmbs7JGxu3pz+EbBSqZgXUuJYySSWRkpS/tyU3vZRIItGHnLdWO4s7PX5m2rdlFqfgnWkhjC1oXnMTxT2keBF1NaDOQ==; 5:CcUyN+Wdl6Eai7gspvjsvlLbjRSkCVrKEqWSvshBVu/aF7LuMagLg+zqoGNS6HOAdPmmGU3I1PLnQZtRTNNDv/z6N91sqwfzEf25ldHR4RVNb+iDP8F2G24wPx1rvG/iOeRAeKHWKZUzdX/ZFJ0nNw==; 24:m8xEHebbBiDJTMRgRaMSmpjwFkWs2pLilf1pNVKoHoo9C5QvTkBPSPv3+tngKfJF2XSXH5TrUHsM4+MzNvk5Xw25u85pF1Ev1VNZTRSrJLM=; 7:GCmSrt1oww89YqH6aYd/mCSQgeAZnpJXQ4PG1+fnEj1+lqukUUF9TjE83rjuN3DW+lPHfl2O8BavP048OeumBZNgesaqDKQ5tZWcMP1nC9PtqL8dLEUcoIJiDnZ6nGuydO6AgM5WFUl+w932CW10Ns4QCuNG5n0wrqNdietaAaLeQU8IIeOWhBPVYWl4JVMU52NE37t9+bEh44FpDmKRlSXI7nWArGNUNnuckgwNFo4= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: bc82cbc0-d31f-4041-f90c-08d4ee85276c x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY4PR06MB2805; x-ms-traffictypediagnostic: CY4PR06MB2805: x-exchange-antispam-report-test: UriScan:(120809045254105)(192374486261705)(100405760836317); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(3002001)(6041248)(20161123555025)(20161123560025)(20161123562025)(20161123564025)(20161123558100)(201703131423075)(201703061421075)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR06MB2805; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR06MB2805; x-forefront-prvs: 0414DF926F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(24454002)(12213003)(189002)(199003)(377454003)(450100002)(33656002)(99286003)(2900100001)(36756003)(53936002)(230783001)(110136004)(50986999)(6512007)(6306002)(68736007)(83716003)(6486002)(81156014)(77096006)(2501003)(6506006)(8676002)(97736004)(189998001)(966005)(81166006)(6116002)(102836003)(3846002)(8936002)(1730700003)(5640700003)(2351001)(6436002)(66066001)(3660700001)(305945005)(3280700002)(6916009)(4326008)(5660300001)(2950100002)(53546010)(7736002)(14454004)(82746002)(106356001)(76176999)(2906002)(25786009)(54356999)(86362001)(508600001)(101416001)(105586002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR06MB2805; H:CY4PR06MB2456.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: isoc.org does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=odonoghue@isoc.org; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <366E8662DA305640BFEFC5048F8994FC@namprd06.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Aug 2017 02:25:02.4659 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR06MB2805 Archived-At: Subject: [Ntp] REMINDER: WGLC for draft-ietf-ntp-using-nts-for-ntp X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Aug 2017 02:25:08 -0000 Rm9sa3MsDQoNClRoZSB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBmb3IgdGhpcyBkb2N1bWVudCBo YXMgYmVlbiBvdXQgZm9yIGFsbW9zdCB0aHJlZSB3ZWVrcyBub3cuIFBsZWFzZSByZXNwb25kIGlt bWVkaWF0ZWx5IHdpdGggdGVjaG5pY2FsIGNvbW1lbnRzIGFuZCBhbiBpbmRpY2F0aW9uIG9mIHdo ZXRoZXIgb3Igbm90IHlvdSBhcHByb3ZlIHRoZSBhZHZhbmNlbWVudCBvZiB0aGlzIGRvY3VtZW50 LiANCg0KUmVnYXJkcywNCkthcmVuDQoNCj4gT24gQXVnIDksIDIwMTcsIGF0IDEyOjQxIEFNLCBL YXJlbiBPJ0Rvbm9naHVlIDxvZG9ub2dodWVAaXNvYy5vcmc+IHdyb3RlOg0KPiANCj4gRm9sa3Ms DQo+IA0KPiBUaGlzIGJlZ2lucyBhIHRocmVlIHdlZWsgd29ya2luZyBncm91cCBsYXN0IGNhbGwg KFdHTEMpIGZvciAiTmV0d29yayBUaW1lIFNlY3VyaXR5IGZvciB0aGUgTmV0d29yayBUaW1lIFBy b3RvY29s4oCdLg0KPiANCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt aWV0Zi1udHAtdXNpbmctbnRzLWZvci1udHAvDQo+IA0KPiBQbGVhc2UgcmV2aWV3IGFuZCBwcm92 aWRlIGNvbW1lbnRzIHRvIHRoZSBtYWlsaW5nIGxpc3QgYnkgbm8gbGF0ZXIgdGhhbiAzMSBBdWd1 c3QgMjAxNy4gRWFybGllciBjb21tZW50cyBhbmQgZGlzY3Vzc2lvbiB3b3VsZCBiZSBhcHByZWNp YXRlZC4gUGxlYXNlIG5vdGUgdGhhdCB0aGUgY2hhaXJzIHdpbGwgYmUgdXNpbmcgdGhpcyBXR0xD IHRvIGRldGVybWluZSBjb25zZW5zdXMgdG8gbW92ZSB0aGlzIGRvY3VtZW50IGZvcndhcmQgdG8g dGhlIElFU0cuIA0KPiANCj4gQWxzbywgYXMgYSByZW1pbmRlciwgd2UgaGF2ZSBtaWdyYXRlZCB0 aGUgd29ya2luZyBncm91cCBtYWlsaW5nIGxpc3QgdG8gSUVURiBpbmZyYXN0cnVjdHVyZS4gUGxl YXNlIHJlc3BvbmQgdG8gbnRwQGlldGYub3JnLiBdDQo+IA0KPiBSZWdhcmRzLA0KPiBLYXJlbiBh bmQgRGlldGVyDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+IG50cCBtYWlsaW5nIGxpc3QNCj4gbnRwQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbnRwDQoNCg== From nobody Mon Aug 28 19:26:09 2017 Return-Path: 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 EC86E1321A7; Mon, 28 Aug 2017 19:26:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 oCUHJgQLipn1; Mon, 28 Aug 2017 19:26:05 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0084.outbound.protection.outlook.com [104.47.32.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62F9B120721; Mon, 28 Aug 2017 19:26:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isoc.org; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=bgOfL2amCVhc5olUtuxdgamJUDtaFfguKHQGvW4i5CU=; b=dmacV92/UqFWKVY95TiSml/rTkLQCNVN+C+FXARVWOgNy/j4nEDswGaqKZ8mLeLzF6V3/C6QWgIvPHsaHZZme+t1Q0xK7Fi5idnG427oT1n15IRnYx9GwvAffWV4a8VuXFValhRKmFE9W86nRPCAdjfDW/B822lsprHyI6hkD+Y= Received: from CY4PR06MB2456.namprd06.prod.outlook.com (10.169.186.136) by CY4PR06MB2805.namprd06.prod.outlook.com (10.175.117.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1385.9; Tue, 29 Aug 2017 02:26:03 +0000 Received: from CY4PR06MB2456.namprd06.prod.outlook.com ([10.169.186.136]) by CY4PR06MB2456.namprd06.prod.outlook.com ([10.169.186.136]) with mapi id 15.01.1385.014; Tue, 29 Aug 2017 02:26:03 +0000 From: Karen O'Donoghue To: "ntp@ietf.org" CC: "tictoc@ietf.org" Thread-Topic: REMINDER: WGLC for draft-ietf-ntp-mac Thread-Index: AQHTEMt6uMJhymzF7kSKqP7bQkn6waKaurUA Date: Tue, 29 Aug 2017 02:26:03 +0000 Message-ID: <80E159E7-17F1-4B0E-8DA1-07581DF7FC6C@isoc.org> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [24.245.108.20] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR06MB2805; 6:UdXgRSs+0t70RkBZ+WJL2EfcwlLfPl1QcwB1ZWprET65RxPLq8ktZ83kfohyrZz11GEQpODFBTJSlu5Y75VOQsuRGHdSR5IbLuM0yuAzaz6sAHSwG96NCwf42dnYS86KUb4W/RmqQLsVApTWjl584uIRJjBOqOdVqM8xkHsW4EJGYTxmnmtQ+i9uTXL/UBUYAbxvyYgXGwYwsCxJGaG7xWI6gUS68Mmko2qW8WFdjHGQOmYU8nw8M0Jl3Kq9h6VDp9w0yqGvXZAiSQSI/KLuGNKsjrhnHmAzWJrtLzYpuzHSMbwgGHvbDiXl/fW+hSnBBQhCdCWSfW3t55izIOxk+A==; 5:cn/AWeEq2k3LdVUXIsf3NTOpAfPpCqXnmEp1mKqcLiayDZ6M+D2swqb8BEi/7XMA0eYoz5BzuCm0hr5pbm/rrwlOzQyAMtKrNaLjxinmAWT2jJTabazL7Emd3bcfhVSNWZHROXFXnYSY070VEtDe9g==; 24:wni+NbJI0khCVlCeIGAgl/HmR3M4XN6joJKWmRI3jKhl5N8TXI7FIex7AXuxuCta09yb1LmpmCjCsHBndMTIqaD+hMY6Yp19UeGftiiyKAU=; 7:Wb3rCRowIStjVcn2gQyNfSZMbZRB/04YjK30XYEMtDdR97WXJqyAAbS6CP+o19GcCCDSLLRz55+puFwGhvOLAztRCuD/0dUJOpWg9RiehW+dSdKhi6XlzlE1Ox/TmKFwUIxcloVzVh7Brpua2aYDsvHwJBDNXaLHNck5x/wVAikZGnkEPwzKvL09/FxMw3ITzzShAG22OixGIGSrv3CzUo5c44J7OZ/l5SYpE2/gKFs= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 42c2a27e-b9a6-4a05-a03b-08d4ee854bec x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY4PR06MB2805; x-ms-traffictypediagnostic: CY4PR06MB2805: x-exchange-antispam-report-test: UriScan:(120809045254105)(100405760836317); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(3002001)(6041248)(20161123555025)(20161123560025)(20161123562025)(20161123564025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR06MB2805; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR06MB2805; x-forefront-prvs: 0414DF926F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39830400002)(189002)(377454003)(199003)(12213003)(24454002)(4326008)(236005)(6916009)(53546010)(606006)(5660300001)(2950100002)(3660700001)(66066001)(3280700002)(86362001)(101416001)(105586002)(14454004)(82746002)(106356001)(7736002)(25786009)(54356999)(76176999)(478600001)(2906002)(50986999)(110136004)(6512007)(6306002)(68736007)(54896002)(230783001)(99286003)(450100002)(33656002)(83716003)(53936002)(2900100001)(36756003)(102836003)(6116002)(3846002)(5640700003)(2351001)(8936002)(1730700003)(2501003)(6486002)(6436002)(81156014)(77096006)(81166006)(6506006)(966005)(189998001)(97736004)(8676002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR06MB2805; H:CY4PR06MB2456.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: isoc.org does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=odonoghue@isoc.org; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_80E159E717F14B0E8DA107581DF7FC6Cisocorg_" MIME-Version: 1.0 X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Aug 2017 02:26:03.6848 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR06MB2805 Archived-At: Subject: [Ntp] REMINDER: WGLC for draft-ietf-ntp-mac X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Aug 2017 02:26:08 -0000 --_000_80E159E717F14B0E8DA107581DF7FC6Cisocorg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, The working group last call for this document has been out for almost three= weeks now. Please respond immediately with technical comments and an indic= ation of whether or not you approve the advancement of this document. Regards, Karen On Aug 9, 2017, at 12:53 AM, Karen O'Donoghue > wrote: Folks, This begins a three week working group last call (WGLC) for "Message Authen= tication Code for the Network Time Protocol" https://datatracker.ietf.org/doc/draft-ietf-ntp-mac/ Please review and provide comments to the mailing list by no later than 31 = August 2017. Earlier comments and discussion would be appreciated. Please n= ote that the chairs will be using this WGLC to determine consensus to move = this document forward to the IESG. Also, as a reminder, we have migrated the working group mailing list to IET= F infrastructure. Please respond to ntp@ietf.org. Regards, Karen and Dieter _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp --_000_80E159E717F14B0E8DA107581DF7FC6Cisocorg_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable Folks,

The working group last call for this document has been out for almost three= weeks now. Please respond immediately with technical comments and an indic= ation of whether or not you approve the advancement of this document. =

Regards,
Karen

On Aug 9, 2017, at 12:53 AM, Karen O'Donoghue <odonoghue@isoc.org> wrote:=

Folks,

This begins a three week working group last call (WGLC) for "Message A= uthentication Code for the Network Time Protocol"
https://datatracker.ietf.org/doc/draft-ietf-ntp-mac/

Please review and provide comments to the mailing list by no later than 31 = August 2017. Earlier comments and discussion would be appreciated. Please n= ote that the chairs will be using this WGLC to determine consensus to move = this document forward to the IESG. 

Also, as a reminder, we have migrated the working group mailing list to IET= F infrastructure. Please respond to ntp@ietf.org. 

Regards,
Karen and Dieter
_______________________________________________
ntp mailing list
ntp@ietf.org
https://www.ietf.org/mailman/listinfo/ntp

--_000_80E159E717F14B0E8DA107581DF7FC6Cisocorg_-- From ntp-bounces@ietf.org Mon Aug 28 19:26:10 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D59C51321A7; Mon, 28 Aug 2017 19:26:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1503973569; bh=H31Hl1YEabtYXExGvnfhPRounE0qtT6awpPguqzDkB0=; h=From:To:Date:References:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc; b=Wh+KKLXIcr908m6Gij8eAtXnk+beHoADQjwrxKaqMjSQQVfcJdVsZVCTLOrRqJMvV ceu5wRgYONaGfKIVec6OTwBraH/8/Bk03PPxiTu5Tp4ffTaJQf9qNcfmJlDd3D7Qox Y+w1utwa5+K68D0knWA4zKkXnAWcmQPmTMu/d+wU= 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 EC86E1321A7; Mon, 28 Aug 2017 19:26:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 oCUHJgQLipn1; Mon, 28 Aug 2017 19:26:05 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0084.outbound.protection.outlook.com [104.47.32.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62F9B120721; Mon, 28 Aug 2017 19:26:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isoc.org; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=bgOfL2amCVhc5olUtuxdgamJUDtaFfguKHQGvW4i5CU=; b=dmacV92/UqFWKVY95TiSml/rTkLQCNVN+C+FXARVWOgNy/j4nEDswGaqKZ8mLeLzF6V3/C6QWgIvPHsaHZZme+t1Q0xK7Fi5idnG427oT1n15IRnYx9GwvAffWV4a8VuXFValhRKmFE9W86nRPCAdjfDW/B822lsprHyI6hkD+Y= Received: from CY4PR06MB2456.namprd06.prod.outlook.com (10.169.186.136) by CY4PR06MB2805.namprd06.prod.outlook.com (10.175.117.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1385.9; Tue, 29 Aug 2017 02:26:03 +0000 Received: from CY4PR06MB2456.namprd06.prod.outlook.com ([10.169.186.136]) by CY4PR06MB2456.namprd06.prod.outlook.com ([10.169.186.136]) with mapi id 15.01.1385.014; Tue, 29 Aug 2017 02:26:03 +0000 From: Karen O'Donoghue To: "ntp@ietf.org" Thread-Topic: REMINDER: WGLC for draft-ietf-ntp-mac Thread-Index: AQHTEMt6uMJhymzF7kSKqP7bQkn6waKaurUA Date: Tue, 29 Aug 2017 02:26:03 +0000 Message-ID: <80E159E7-17F1-4B0E-8DA1-07581DF7FC6C@isoc.org> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [24.245.108.20] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR06MB2805; 6:UdXgRSs+0t70RkBZ+WJL2EfcwlLfPl1QcwB1ZWprET65RxPLq8ktZ83kfohyrZz11GEQpODFBTJSlu5Y75VOQsuRGHdSR5IbLuM0yuAzaz6sAHSwG96NCwf42dnYS86KUb4W/RmqQLsVApTWjl584uIRJjBOqOdVqM8xkHsW4EJGYTxmnmtQ+i9uTXL/UBUYAbxvyYgXGwYwsCxJGaG7xWI6gUS68Mmko2qW8WFdjHGQOmYU8nw8M0Jl3Kq9h6VDp9w0yqGvXZAiSQSI/KLuGNKsjrhnHmAzWJrtLzYpuzHSMbwgGHvbDiXl/fW+hSnBBQhCdCWSfW3t55izIOxk+A==; 5:cn/AWeEq2k3LdVUXIsf3NTOpAfPpCqXnmEp1mKqcLiayDZ6M+D2swqb8BEi/7XMA0eYoz5BzuCm0hr5pbm/rrwlOzQyAMtKrNaLjxinmAWT2jJTabazL7Emd3bcfhVSNWZHROXFXnYSY070VEtDe9g==; 24:wni+NbJI0khCVlCeIGAgl/HmR3M4XN6joJKWmRI3jKhl5N8TXI7FIex7AXuxuCta09yb1LmpmCjCsHBndMTIqaD+hMY6Yp19UeGftiiyKAU=; 7:Wb3rCRowIStjVcn2gQyNfSZMbZRB/04YjK30XYEMtDdR97WXJqyAAbS6CP+o19GcCCDSLLRz55+puFwGhvOLAztRCuD/0dUJOpWg9RiehW+dSdKhi6XlzlE1Ox/TmKFwUIxcloVzVh7Brpua2aYDsvHwJBDNXaLHNck5x/wVAikZGnkEPwzKvL09/FxMw3ITzzShAG22OixGIGSrv3CzUo5c44J7OZ/l5SYpE2/gKFs= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 42c2a27e-b9a6-4a05-a03b-08d4ee854bec x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY4PR06MB2805; x-ms-traffictypediagnostic: CY4PR06MB2805: x-exchange-antispam-report-test: UriScan:(120809045254105)(100405760836317); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(3002001)(6041248)(20161123555025)(20161123560025)(20161123562025)(20161123564025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR06MB2805; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR06MB2805; x-forefront-prvs: 0414DF926F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39830400002)(189002)(377454003)(199003)(12213003)(24454002)(4326008)(236005)(6916009)(53546010)(606006)(5660300001)(2950100002)(3660700001)(66066001)(3280700002)(86362001)(101416001)(105586002)(14454004)(82746002)(106356001)(7736002)(25786009)(54356999)(76176999)(478600001)(2906002)(50986999)(110136004)(6512007)(6306002)(68736007)(54896002)(230783001)(99286003)(450100002)(33656002)(83716003)(53936002)(2900100001)(36756003)(102836003)(6116002)(3846002)(5640700003)(2351001)(8936002)(1730700003)(2501003)(6486002)(6436002)(81156014)(77096006)(81166006)(6506006)(966005)(189998001)(97736004)(8676002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR06MB2805; H:CY4PR06MB2456.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: isoc.org does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=odonoghue@isoc.org; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Aug 2017 02:26:03.6848 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR06MB2805 Archived-At: Subject: [Ntp] REMINDER: WGLC for draft-ietf-ntp-mac X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "tictoc@ietf.org" Content-Type: multipart/mixed; boundary="===============5567956556006922259==" Errors-To: ntp-bounces@ietf.org Sender: "ntp" --===============5567956556006922259== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_80E159E717F14B0E8DA107581DF7FC6Cisocorg_" --_000_80E159E717F14B0E8DA107581DF7FC6Cisocorg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, The working group last call for this document has been out for almost three= weeks now. Please respond immediately with technical comments and an indic= ation of whether or not you approve the advancement of this document. Regards, Karen On Aug 9, 2017, at 12:53 AM, Karen O'Donoghue > wrote: Folks, This begins a three week working group last call (WGLC) for "Message Authen= tication Code for the Network Time Protocol" https://datatracker.ietf.org/doc/draft-ietf-ntp-mac/ Please review and provide comments to the mailing list by no later than 31 = August 2017. Earlier comments and discussion would be appreciated. Please n= ote that the chairs will be using this WGLC to determine consensus to move = this document forward to the IESG. Also, as a reminder, we have migrated the working group mailing list to IET= F infrastructure. Please respond to ntp@ietf.org. Regards, Karen and Dieter _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp --_000_80E159E717F14B0E8DA107581DF7FC6Cisocorg_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable Folks,

The working group last call for this document has been out for almost three= weeks now. Please respond immediately with technical comments and an indic= ation of whether or not you approve the advancement of this document. =

Regards,
Karen

On Aug 9, 2017, at 12:53 AM, Karen O'Donoghue <odonoghue@isoc.org> wrote:=

Folks,

This begins a three week working group last call (WGLC) for "Message A= uthentication Code for the Network Time Protocol"
https://datatracker.ietf.org/doc/draft-ietf-ntp-mac/

Please review and provide comments to the mailing list by no later than 31 = August 2017. Earlier comments and discussion would be appreciated. Please n= ote that the chairs will be using this WGLC to determine consensus to move = this document forward to the IESG. 

Also, as a reminder, we have migrated the working group mailing list to IET= F infrastructure. Please respond to ntp@ietf.org. 

Regards,
Karen and Dieter
_______________________________________________
ntp mailing list
ntp@ietf.org
https://www.ietf.org/mailman/listinfo/ntp

--_000_80E159E717F14B0E8DA107581DF7FC6Cisocorg_-- --===============5567956556006922259== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp --===============5567956556006922259==-- From ntp-bounces@ietf.org Mon Aug 28 19:35:27 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C16651323A8; Mon, 28 Aug 2017 19:35:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1503974127; bh=lVDQ4Mc0Cuettd12FN+vdARtDnIT9pazyQGbBb3QtRs=; h=In-Reply-To:References:From:Date:To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc; b=sj06/KVKjTNo2Oli92coM7g4MzRERnDyukEHP9Pp9URx79rWjLqDkt6pjfDdTyjZ5 14E3C1uf/OmttK4zfVrs1Ri5F8GncPcwW3MSUfCSsgbiHaY8+tqHrtRj8kWTXIle2W 3LTwd1Ia/M34MICriVhoU8BcNvdXimmQdPpb2fbU= 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 B2CD5126B71; Mon, 28 Aug 2017 19:35:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 CTRcME9TwNSE; Mon, 28 Aug 2017 19:35:22 -0700 (PDT) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (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 CAA5B120721; Mon, 28 Aug 2017 19:35:21 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id b82so12642020wmd.1; Mon, 28 Aug 2017 19:35:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=SXG7y1WnI8g/D26RfK30FU/YcdJyrmaH1H7QzCgV4FM=; b=L+barebLVAGvraZxlIf5bCigjYIX0opjtWE3xeFp7n1ADAOVOIwl5+NDFV4L1QIWba c8dmboCgfquWTw/qQjxT8tENSEnP5Uu6nbFIPWsOnqYcS3QHW5jT9f0co7SESrQF1O3K nsqi64VKR4lWZOH5SmVHewjx9NiyePoF4kWmBOAbRYO+TPEagKmnso8H+puoKy9PfAZK L1ND/LNrIJv0a0Se5vQB5F+gsa6yGEQj8UXoyzJcrkG5OYl56S55bbiwAOeRVb09ssjO IN5hzvD42ImPTo//H55e3peXoT+rK1uqoize9/vKl62iRQRVEJw+pQyWbaT9eZsTFrwC U87g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=SXG7y1WnI8g/D26RfK30FU/YcdJyrmaH1H7QzCgV4FM=; b=LXD25fkbyLRwJUQrEp8AJbao2whsobyRRaRK7pevvGZ+Di4zlIqrrJhb5aupxjLZ9W cyFpFwNMoY1PsKCaL6DF51PUZvjOQU8bkp3K6+irAY00QmW9odwyGGnsOwv+0sGK2Hep ykerSup+TW6b7I1iFKbbCxVnvnnZmf2Dd06vN3LPIksGoEgQHxXfp8cjg3KT7UQAJhcZ 8VQpJljLYKSxGopem18Q74AIJibUqE72ktB1svetS2hQCwu1xRpHXVhc2E8UmehfksXg xVGAE32jsyXHUCRa7J7lE1gDt/lNpOBUhMYli9b+gnefhACVrxcmULVYqHAwkwdbZpND dUYw== X-Gm-Message-State: AHYfb5iVioQSKn0osNmhqiE5hUmmFAun22NwK6Lh7GwEe0YULCIbRexE mBZyQvrRZa36C4uRFblkB3TdhYz11w== X-Received: by 10.80.151.90 with SMTP id d26mr2038342edb.19.1503974120224; Mon, 28 Aug 2017 19:35:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.157.140 with HTTP; Mon, 28 Aug 2017 19:35:19 -0700 (PDT) In-Reply-To: References: From: Daniel Franke Date: Mon, 28 Aug 2017 22:35:19 -0400 Message-ID: To: "Karen O'Donoghue" Archived-At: Subject: Re: [Ntp] WGLC for draft-ietf-ntp-mac X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "ntp@ietf.org" , "tictoc@ietf.org" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ntp-bounces@ietf.org Sender: "ntp" I support advancement of this draft. My only editorial comment at this point is that I think several of the references currently listed as normative, specifically RFC 1321, 6151, and 7696, should properly be listed as informative. On 8/9/17, Karen O'Donoghue wrote: > Folks, > > This begins a three week working group last call (WGLC) for "Message > Authentication Code for the Network Time Protocol" > https://datatracker.ietf.org/doc/draft-ietf-ntp-mac/ > > Please review and provide comments to the mailing list by no later than 31 > August 2017. Earlier comments and discussion would be appreciated. Please > note that the chairs will be using this WGLC to determine consensus to move > this document forward to the IESG. > > Also, as a reminder, we have migrated the working group mailing list to IETF > infrastructure. Please respond to ntp@ietf.org. > > Regards, > Karen and Dieter > _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp From nobody Mon Aug 28 19:35:32 2017 Return-Path: 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 B2CD5126B71; Mon, 28 Aug 2017 19:35:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 CTRcME9TwNSE; Mon, 28 Aug 2017 19:35:22 -0700 (PDT) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (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 CAA5B120721; Mon, 28 Aug 2017 19:35:21 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id b82so12642020wmd.1; Mon, 28 Aug 2017 19:35:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=SXG7y1WnI8g/D26RfK30FU/YcdJyrmaH1H7QzCgV4FM=; b=L+barebLVAGvraZxlIf5bCigjYIX0opjtWE3xeFp7n1ADAOVOIwl5+NDFV4L1QIWba c8dmboCgfquWTw/qQjxT8tENSEnP5Uu6nbFIPWsOnqYcS3QHW5jT9f0co7SESrQF1O3K nsqi64VKR4lWZOH5SmVHewjx9NiyePoF4kWmBOAbRYO+TPEagKmnso8H+puoKy9PfAZK L1ND/LNrIJv0a0Se5vQB5F+gsa6yGEQj8UXoyzJcrkG5OYl56S55bbiwAOeRVb09ssjO IN5hzvD42ImPTo//H55e3peXoT+rK1uqoize9/vKl62iRQRVEJw+pQyWbaT9eZsTFrwC U87g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=SXG7y1WnI8g/D26RfK30FU/YcdJyrmaH1H7QzCgV4FM=; b=LXD25fkbyLRwJUQrEp8AJbao2whsobyRRaRK7pevvGZ+Di4zlIqrrJhb5aupxjLZ9W cyFpFwNMoY1PsKCaL6DF51PUZvjOQU8bkp3K6+irAY00QmW9odwyGGnsOwv+0sGK2Hep ykerSup+TW6b7I1iFKbbCxVnvnnZmf2Dd06vN3LPIksGoEgQHxXfp8cjg3KT7UQAJhcZ 8VQpJljLYKSxGopem18Q74AIJibUqE72ktB1svetS2hQCwu1xRpHXVhc2E8UmehfksXg xVGAE32jsyXHUCRa7J7lE1gDt/lNpOBUhMYli9b+gnefhACVrxcmULVYqHAwkwdbZpND dUYw== X-Gm-Message-State: AHYfb5iVioQSKn0osNmhqiE5hUmmFAun22NwK6Lh7GwEe0YULCIbRexE mBZyQvrRZa36C4uRFblkB3TdhYz11w== X-Received: by 10.80.151.90 with SMTP id d26mr2038342edb.19.1503974120224; Mon, 28 Aug 2017 19:35:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.157.140 with HTTP; Mon, 28 Aug 2017 19:35:19 -0700 (PDT) In-Reply-To: References: From: Daniel Franke Date: Mon, 28 Aug 2017 22:35:19 -0400 Message-ID: To: "Karen O'Donoghue" Cc: "ntp@ietf.org" , "tictoc@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Ntp] WGLC for draft-ietf-ntp-mac X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Aug 2017 02:35:25 -0000 I support advancement of this draft. My only editorial comment at this point is that I think several of the references currently listed as normative, specifically RFC 1321, 6151, and 7696, should properly be listed as informative. On 8/9/17, Karen O'Donoghue wrote: > Folks, > > This begins a three week working group last call (WGLC) for "Message > Authentication Code for the Network Time Protocol" > https://datatracker.ietf.org/doc/draft-ietf-ntp-mac/ > > Please review and provide comments to the mailing list by no later than 31 > August 2017. Earlier comments and discussion would be appreciated. Please > note that the chairs will be using this WGLC to determine consensus to move > this document forward to the IESG. > > Also, as a reminder, we have migrated the working group mailing list to IETF > infrastructure. Please respond to ntp@ietf.org. > > Regards, > Karen and Dieter > From ntp-bounces@ietf.org Mon Aug 28 23:55:23 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 11795132403; Mon, 28 Aug 2017 23:55:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1503989723; bh=Grda6Rawg+vvgYRG8Pc9232K2UK0LeNiWXBlrxqDnAY=; h=In-Reply-To:References:To:From:Date:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc; b=HvCbq0dLAybd2IbBscmi6/gJaWioVDHYJlETkDonLMyNmY7CqutjnlLeRKWs/cxRH +IIVh42vC4vv9ZnJhYqDMR7YOssJhenMKi/0k41yMsvXevNeFnEkokho8SaSpLZQAI kHvvKWGgRm/Mpx2KHiI2aKybSM9V+Nr03+NQfd4Q= 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 52032132403; Mon, 28 Aug 2017 23:55:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 TxMMay36Mv-e; Mon, 28 Aug 2017 23:55:19 -0700 (PDT) Received: from mx1.bs.ptb.de (mx1.bs.ptb.de [IPv6:2001:638:610:bd01::120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F06751320BB; Mon, 28 Aug 2017 23:55:18 -0700 (PDT) Received: from smtp-hub.bs.ptb.de (smtpint01.bs.ptb.de [141.25.87.32]) by mx1.bs.ptb.de with ESMTP id v7T6tFXk028820-v7T6tFXm028820 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 29 Aug 2017 08:55:15 +0200 Received: from lotus.bs.ptb.de (lotus.bs.ptb.de [141.25.85.200]) by smtp-hub.bs.ptb.de (Postfix) with ESMTPS id C7CF1533452; Tue, 29 Aug 2017 08:55:15 +0200 (CEST) In-Reply-To: <2d46f8f8-cdad-c7d7-53a0-ac26c25e594c@nwtime.org> References: <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> <47b5b4e3-41c9-6779-4a96-b11650483499@nwtime.org> <1dee3e5d-6906-cf40-d0c3-a387adc2ba42@nwtime.org> <2d46f8f8-cdad-c7d7-53a0-ac26c25e594c@nwtime.org> To: Harlan Stenn MIME-Version: 1.0 Message-ID: From: kristof.teichel@ptb.de Date: Tue, 29 Aug 2017 08:55:12 +0200 Archived-At: Subject: Re: [Ntp] WGLC for draft-ietf-ntp-using-nts-for-ntp X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: ntp , ntp@ietf.org, Daniel Franke Content-Type: multipart/mixed; boundary="===============3931143670400421711==" Errors-To: ntp-bounces@ietf.org Sender: "ntp" Dies ist eine mehrteilige Nachricht im MIME-Format. --===============3931143670400421711== Content-Type: multipart/alternative; boundary="=_alternative 0026049CC125818B_=" Dies ist eine mehrteilige Nachricht im MIME-Format. --=_alternative 0026049CC125818B_= Content-Type: text/plain; charset="US-ASCII" "ntp" schrieb am 29.08.2017 02:28:35: > Von: Harlan Stenn > An: Daniel Franke > Kopie: ntp@ietf.org > Datum: 29.08.2017 02:28 > Betreff: Re: [Ntp] WGLC for draft-ietf-ntp-using-nts-for-ntp > Gesendet von: "ntp" > > On 8/28/2017 2:28 PM, Daniel Franke wrote: > > On 8/28/17, Harlan Stenn wrote: > >> Dave and I still vote "NO" on advancing this document at this time. (Citing as found in Daniel's mail, since for some reason, I seem to never have received the original message) Harlan, on what grounds exactly? Let me clarify: I believe it would be helpful if you could mark up for the WG what you (and potentially Dave, if he can contribute) see as "dealbreakers". The list of feedback/issues you sent to the list suffers from a non-differentiation with regard to perceived severity of the items -- especially since some of them pretty clearly seem to be of the sort "fix the typo/adjust the wording and the problem is solved", purely editorial and solvable in very little time. With more clarity on how severe you think the individual issues are and (roughly) what you think could be done to solve them, I believe the input would become much more constructive. Best regards, Kristof --=_alternative 0026049CC125818B_= Content-Type: text/html; charset="US-ASCII" "ntp" <ntp-bounces@ietf.org> schrieb am 29.08.2017 02:28:35:

> Von: Harlan Stenn <stenn@nwtime.org>
> An: Daniel Franke <dfoxfranke@gmail.com>
> Kopie: ntp@ietf.org
> Datum: 29.08.2017 02:28
> Betreff: Re: [Ntp] WGLC for draft-ietf-ntp-using-nts-for-ntp
> Gesendet von: "ntp" <ntp-bounces@ietf.org>
>
> On 8/28/2017 2:28 PM, Daniel Franke wrote:
> > On 8/28/17, Harlan Stenn <stenn@nwtime.org> wrote:

> >> Dave and I still vote "NO" on advancing this document at this time.
(Citing as found in Daniel's mail, since for some reason, I seem to never have received the original message)

Harlan, on what grounds exactly?

Let me clarify: I believe it would be helpful if you could mark up for the WG what you (and potentially Dave, if he can contribute) see as "dealbreakers".
The list of feedback/issues you sent to the list suffers from a non-differentiation with regard to perceived severity of the items -- especially since some of them pretty clearly seem to be of the sort "fix the typo/adjust the wording and the problem is solved", purely editorial and solvable in very little time.

With more clarity on how severe you think the individual issues are and (roughly) what you think could be done to solve them, I believe the input would become much more constructive.


Best regards,
Kristof --=_alternative 0026049CC125818B_=-- --===============3931143670400421711== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp --===============3931143670400421711==-- From nobody Mon Aug 28 23:55:23 2017 Return-Path: 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 52032132403; Mon, 28 Aug 2017 23:55:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 TxMMay36Mv-e; Mon, 28 Aug 2017 23:55:19 -0700 (PDT) Received: from mx1.bs.ptb.de (mx1.bs.ptb.de [IPv6:2001:638:610:bd01::120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F06751320BB; Mon, 28 Aug 2017 23:55:18 -0700 (PDT) Received: from smtp-hub.bs.ptb.de (smtpint01.bs.ptb.de [141.25.87.32]) by mx1.bs.ptb.de with ESMTP id v7T6tFXk028820-v7T6tFXm028820 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 29 Aug 2017 08:55:15 +0200 Received: from lotus.bs.ptb.de (lotus.bs.ptb.de [141.25.85.200]) by smtp-hub.bs.ptb.de (Postfix) with ESMTPS id C7CF1533452; Tue, 29 Aug 2017 08:55:15 +0200 (CEST) In-Reply-To: <2d46f8f8-cdad-c7d7-53a0-ac26c25e594c@nwtime.org> References: <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> <47b5b4e3-41c9-6779-4a96-b11650483499@nwtime.org> <1dee3e5d-6906-cf40-d0c3-a387adc2ba42@nwtime.org> <2d46f8f8-cdad-c7d7-53a0-ac26c25e594c@nwtime.org> To: Harlan Stenn Cc: Daniel Franke , ntp@ietf.org, "ntp" MIME-Version: 1.0 Message-ID: From: kristof.teichel@ptb.de Date: Tue, 29 Aug 2017 08:55:12 +0200 Content-Type: multipart/alternative; boundary="=_alternative 0026049CC125818B_=" Archived-At: Subject: Re: [Ntp] WGLC for draft-ietf-ntp-using-nts-for-ntp X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Aug 2017 06:55:21 -0000 Dies ist eine mehrteilige Nachricht im MIME-Format. --=_alternative 0026049CC125818B_= Content-Type: text/plain; charset="US-ASCII" "ntp" schrieb am 29.08.2017 02:28:35: > Von: Harlan Stenn > An: Daniel Franke > Kopie: ntp@ietf.org > Datum: 29.08.2017 02:28 > Betreff: Re: [Ntp] WGLC for draft-ietf-ntp-using-nts-for-ntp > Gesendet von: "ntp" > > On 8/28/2017 2:28 PM, Daniel Franke wrote: > > On 8/28/17, Harlan Stenn wrote: > >> Dave and I still vote "NO" on advancing this document at this time. (Citing as found in Daniel's mail, since for some reason, I seem to never have received the original message) Harlan, on what grounds exactly? Let me clarify: I believe it would be helpful if you could mark up for the WG what you (and potentially Dave, if he can contribute) see as "dealbreakers". The list of feedback/issues you sent to the list suffers from a non-differentiation with regard to perceived severity of the items -- especially since some of them pretty clearly seem to be of the sort "fix the typo/adjust the wording and the problem is solved", purely editorial and solvable in very little time. With more clarity on how severe you think the individual issues are and (roughly) what you think could be done to solve them, I believe the input would become much more constructive. Best regards, Kristof --=_alternative 0026049CC125818B_= Content-Type: text/html; charset="US-ASCII" "ntp" <ntp-bounces@ietf.org> schrieb am 29.08.2017 02:28:35:

> Von: Harlan Stenn <stenn@nwtime.org>
> An: Daniel Franke <dfoxfranke@gmail.com>
> Kopie: ntp@ietf.org
> Datum: 29.08.2017 02:28
> Betreff: Re: [Ntp] WGLC for draft-ietf-ntp-using-nts-for-ntp
> Gesendet von: "ntp" <ntp-bounces@ietf.org>
>
> On 8/28/2017 2:28 PM, Daniel Franke wrote:
> > On 8/28/17, Harlan Stenn <stenn@nwtime.org> wrote:

> >> Dave and I still vote "NO" on advancing this document at this time.
(Citing as found in Daniel's mail, since for some reason, I seem to never have received the original message)

Harlan, on what grounds exactly?

Let me clarify: I believe it would be helpful if you could mark up for the WG what you (and potentially Dave, if he can contribute) see as "dealbreakers".
The list of feedback/issues you sent to the list suffers from a non-differentiation with regard to perceived severity of the items -- especially since some of them pretty clearly seem to be of the sort "fix the typo/adjust the wording and the problem is solved", purely editorial and solvable in very little time.

With more clarity on how severe you think the individual issues are and (roughly) what you think could be done to solve them, I believe the input would become much more constructive.


Best regards,
Kristof --=_alternative 0026049CC125818B_=-- From ntp-bounces@ietf.org Tue Aug 29 00:02:45 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 33EFC132709; Tue, 29 Aug 2017 00:02:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1503990165; bh=aLWyraW2I1xPa4Jjxzm5TIDdUnGTspQPSy0qQ1VQYQM=; h=Date:From:To:References:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc; b=aguS5Sf2SeNfNOUntujqpOf6G5Z1qHFbKSHsdZpJK+ZIGWs4T9UME5xaaVbLlArns Hju0SylkI5G/hwd2mwlXjIy9K7hQEQ6BJ65N/OBiWwaaNcVfV2qcaFAnh0niHknPMi mcLQmGxIzC4KjaVWcbeM6hsowpr4p8T6GfPEXvAE= 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 7410213238E for ; Tue, 29 Aug 2017 00:02:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 H_kd2uTFVcZy for ; Tue, 29 Aug 2017 00:02:41 -0700 (PDT) Received: from rrzmta1.uni-regensburg.de (rrzmta1.uni-regensburg.de [194.94.155.51]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 021EE132386 for ; Tue, 29 Aug 2017 00:02:41 -0700 (PDT) Received: from rrzmta1.uni-regensburg.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 527F15DA8B for ; Tue, 29 Aug 2017 09:02:39 +0200 (CEST) Received: from gwsmtp1.uni-regensburg.de (gwsmtp1.uni-regensburg.de [132.199.5.51]) by rrzmta1.uni-regensburg.de (Postfix) with ESMTP id 39AA25D6A1 for ; Tue, 29 Aug 2017 09:02:39 +0200 (CEST) Received: from uni-regensburg-smtp1-MTA by gwsmtp1.uni-regensburg.de with Novell_GroupWise; Tue, 29 Aug 2017 09:02:39 +0200 Message-Id: <59A5118C020000A100027A32@gwsmtp1.uni-regensburg.de> X-Mailer: Novell GroupWise Internet Agent 14.2.2 Date: Tue, 29 Aug 2017 09:02:36 +0200 From: "Ulrich Windl" To: "Daniel Franke" , References: <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> <47b5b4e3-41c9-6779-4a96-b11650483499@nwtime.org> <1dee3e5d-6906-cf40-d0c3-a387adc2ba42@nwtime.org> In-Reply-To: Mime-Version: 1.0 Content-Disposition: inline Archived-At: Subject: [Ntp] Antw: Re: WGLC for draft-ietf-ntp-using-nts-for-ntp X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "ntp@ietf.org" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ntp-bounces@ietf.org Sender: "ntp" Hi guys! Maybe Dave Mills will agree to voice recording. Then you could attach a voice transcript of your discussion. For example OPUS (Request for Comments: 6716) is a nice audio codec for speech ;-) Regards, Ulrich >>> Daniel Franke schrieb am 28.08.2017 um 23:28 in Nachricht : > On 8/28/17, Harlan Stenn wrote: >> Dave and I still vote "NO" on advancing this document at this time. > > Harlan, your opposition is noted, but your attempt to seize the mantle > of Prof. Mills' authority here is inappropriate I want you to stop. > Prof. Mills could not possibly have read and responded to my comments > in the time it took you to send this reply. Your original critique, in > which you claim to be speaking for the two of you, is also written > entirely in your style with no indication of what is Prof. Mills' > commentary and what is yours. > > I understand that Prof. Mills' health makes it challenging for him to > participate fully in this discussion. We should all do everything we > possibly can to accommodate him. But you are not acting as a faithful > messenger and I will not accept your words as his. > > _______________________________________________ > ntp mailing list > ntp@ietf.org > https://www.ietf.org/mailman/listinfo/ntp _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp From nobody Tue Aug 29 00:02:45 2017 Return-Path: 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 7410213238E for ; Tue, 29 Aug 2017 00:02:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 H_kd2uTFVcZy for ; Tue, 29 Aug 2017 00:02:41 -0700 (PDT) Received: from rrzmta1.uni-regensburg.de (rrzmta1.uni-regensburg.de [194.94.155.51]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 021EE132386 for ; Tue, 29 Aug 2017 00:02:41 -0700 (PDT) Received: from rrzmta1.uni-regensburg.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 527F15DA8B for ; Tue, 29 Aug 2017 09:02:39 +0200 (CEST) Received: from gwsmtp1.uni-regensburg.de (gwsmtp1.uni-regensburg.de [132.199.5.51]) by rrzmta1.uni-regensburg.de (Postfix) with ESMTP id 39AA25D6A1 for ; Tue, 29 Aug 2017 09:02:39 +0200 (CEST) Received: from uni-regensburg-smtp1-MTA by gwsmtp1.uni-regensburg.de with Novell_GroupWise; Tue, 29 Aug 2017 09:02:39 +0200 Message-Id: <59A5118C020000A100027A32@gwsmtp1.uni-regensburg.de> X-Mailer: Novell GroupWise Internet Agent 14.2.2 Date: Tue, 29 Aug 2017 09:02:36 +0200 From: "Ulrich Windl" To: "Daniel Franke" , Cc: "ntp@ietf.org" References: <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> <47b5b4e3-41c9-6779-4a96-b11650483499@nwtime.org> <1dee3e5d-6906-cf40-d0c3-a387adc2ba42@nwtime.org> In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Archived-At: Subject: [Ntp] Antw: Re: WGLC for draft-ietf-ntp-using-nts-for-ntp X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Aug 2017 07:02:43 -0000 Hi guys! Maybe Dave Mills will agree to voice recording. Then you could attach a = voice transcript of your discussion. For example OPUS (Request for = Comments: 6716) is a nice audio codec for speech ;-) Regards, Ulrich >>> Daniel Franke schrieb am 28.08.2017 um 23:28 in Nachricht := > On 8/28/17, Harlan Stenn wrote: >> Dave and I still vote "NO" on advancing this document at this time. >=20 > Harlan, your opposition is noted, but your attempt to seize the mantle > of Prof. Mills' authority here is inappropriate I want you to stop. > Prof. Mills could not possibly have read and responded to my comments > in the time it took you to send this reply. Your original critique, in > which you claim to be speaking for the two of you, is also written > entirely in your style with no indication of what is Prof. Mills' > commentary and what is yours. >=20 > I understand that Prof. Mills' health makes it challenging for him to > participate fully in this discussion. We should all do everything we > possibly can to accommodate him. But you are not acting as a faithful > messenger and I will not accept your words as his. >=20 > _______________________________________________ > ntp mailing list > ntp@ietf.org=20 > https://www.ietf.org/mailman/listinfo/ntp=20 From nobody Tue Aug 29 00:49:27 2017 Return-Path: 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 C23B7132620; Tue, 29 Aug 2017 00:49:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no 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 8GNBMKVCs4JQ; Tue, 29 Aug 2017 00:49:24 -0700 (PDT) Received: from rrzmta1.uni-regensburg.de (rrzmta1.uni-regensburg.de [194.94.155.51]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AE6913235C; Tue, 29 Aug 2017 00:49:24 -0700 (PDT) Received: from rrzmta1.uni-regensburg.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 579815D006; Tue, 29 Aug 2017 09:49:23 +0200 (CEST) Received: from gwsmtp1.uni-regensburg.de (gwsmtp1.uni-regensburg.de [132.199.5.51]) by rrzmta1.uni-regensburg.de (Postfix) with ESMTP id 3F6875CE9C; Tue, 29 Aug 2017 09:49:23 +0200 (CEST) Received: from uni-regensburg-smtp1-MTA by gwsmtp1.uni-regensburg.de with Novell_GroupWise; Tue, 29 Aug 2017 09:49:23 +0200 Message-Id: <59A51C80020000A100027A4B@gwsmtp1.uni-regensburg.de> X-Mailer: Novell GroupWise Internet Agent 14.2.2 Date: Tue, 29 Aug 2017 09:49:20 +0200 From: "Ulrich Windl" To: "Daniel Franke" , Cc: "ntp@ietf.org" ,"tictoc@ietf.org" References: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Archived-At: Subject: [Ntp] Antw: Re: WGLC for draft-ietf-ntp-mac X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Aug 2017 07:49:26 -0000 >>> Daniel Franke schrieb am 29.08.2017 um 04:35 in Nachricht := > I support advancement of this draft. My only editorial comment at this > point is that I think several of the references currently listed as > normative, specifically RFC 1321, 6151, and 7696, should properly be > listed as informative. I just cross-checked: The first two are INFORMATIVE, the last one is BCP = 201. ;-) [...] From ntp-bounces@ietf.org Tue Aug 29 00:49:27 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 725C11326DF; Tue, 29 Aug 2017 00:49:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1503992967; bh=0MHy3k8qBQeDsGS8YWqWJC/wol7jUxXnA0VH3kqOd38=; h=Date:From:To:References:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc; b=Ow7wuvuE4K9wLqvFs/GUpvJzgOT2qieuKWKX8TE57r+mVukpna/32Sc5uR+pFEE2Q oAjmZNHINpwUrsx0PnTUDqBa2PUQZyBk1nNaejT2zd78W2FTA+jgmd7Ax2PhbwtNxT lYCdiCfzqD4yeM5mfhcy64fyvWAqPYThPn9GJiOA= 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 C23B7132620; Tue, 29 Aug 2017 00:49:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no 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 8GNBMKVCs4JQ; Tue, 29 Aug 2017 00:49:24 -0700 (PDT) Received: from rrzmta1.uni-regensburg.de (rrzmta1.uni-regensburg.de [194.94.155.51]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AE6913235C; Tue, 29 Aug 2017 00:49:24 -0700 (PDT) Received: from rrzmta1.uni-regensburg.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 579815D006; Tue, 29 Aug 2017 09:49:23 +0200 (CEST) Received: from gwsmtp1.uni-regensburg.de (gwsmtp1.uni-regensburg.de [132.199.5.51]) by rrzmta1.uni-regensburg.de (Postfix) with ESMTP id 3F6875CE9C; Tue, 29 Aug 2017 09:49:23 +0200 (CEST) Received: from uni-regensburg-smtp1-MTA by gwsmtp1.uni-regensburg.de with Novell_GroupWise; Tue, 29 Aug 2017 09:49:23 +0200 Message-Id: <59A51C80020000A100027A4B@gwsmtp1.uni-regensburg.de> X-Mailer: Novell GroupWise Internet Agent 14.2.2 Date: Tue, 29 Aug 2017 09:49:20 +0200 From: "Ulrich Windl" To: "Daniel Franke" , References: In-Reply-To: Mime-Version: 1.0 Content-Disposition: inline Archived-At: Subject: [Ntp] Antw: Re: WGLC for draft-ietf-ntp-mac X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "ntp@ietf.org" , "tictoc@ietf.org" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ntp-bounces@ietf.org Sender: "ntp" >>> Daniel Franke schrieb am 29.08.2017 um 04:35 in Nachricht : > I support advancement of this draft. My only editorial comment at this > point is that I think several of the references currently listed as > normative, specifically RFC 1321, 6151, and 7696, should properly be > listed as informative. I just cross-checked: The first two are INFORMATIVE, the last one is BCP 201. ;-) [...] _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp From nobody Tue Aug 29 01:05:31 2017 Return-Path: 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 06C23132D46 for ; Tue, 29 Aug 2017 01:05:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 egMSSZ2bl0xa for ; Tue, 29 Aug 2017 01:05:27 -0700 (PDT) Received: from mx1.bs.ptb.de (mx1.bs.ptb.de [IPv6:2001:638:610:bd01::120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7097A132D49 for ; Tue, 29 Aug 2017 01:05:27 -0700 (PDT) Received: from smtp-hub.bs.ptb.de (smtpint01.bs.ptb.de [141.25.87.32]) by mx1.bs.ptb.de with ESMTP id v7T85Pq9004865-v7T85PqB004865 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 29 Aug 2017 10:05:25 +0200 Received: from lotus.bs.ptb.de (lotus.bs.ptb.de [141.25.85.200]) by smtp-hub.bs.ptb.de (Postfix) with ESMTPS id AF36853357A; Tue, 29 Aug 2017 10:05:25 +0200 (CEST) In-Reply-To: <47b5b4e3-41c9-6779-4a96-b11650483499@nwtime.org> References: <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> <47b5b4e3-41c9-6779-4a96-b11650483499@nwtime.org> To: Harlan Stenn Cc: ntp@ietf.org MIME-Version: 1.0 Message-ID: From: kristof.teichel@ptb.de Date: Tue, 29 Aug 2017 10:05:22 +0200 Content-Type: multipart/alternative; boundary="=_alternative 002C7119C125818B_=" Archived-At: Subject: [Ntp] [NTP] WGLC for draft-ietf-ntp-using-nts-for-ntp (Objectives Subsection) X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Aug 2017 08:05:30 -0000 Dies ist eine mehrteilige Nachricht im MIME-Format. --=_alternative 002C7119C125818B_= Content-Type: text/plain; charset="US-ASCII" Hello all, I am going to attempt a rundown of Harlan's input, trying to avoid too much overlap with responses that Daniel already gave. I want to treat the "Objectives" subsection separately, ASAP, because consensus here is really essential for consensus anywhere else. > [...] > > TL;DR version: > > There are some parts of the proposal that are wrong, and some other > parts are misleading. There are sections of the proposal that are > confusing, and there are sections of the proposal that are inadequately > described. > > Long version: > > 1.1. Objectives > > - Confidentiality: Under what conditions is this actually useful? If > confidentiality is a need for some, in those situations why not just > send the NTP traffic over an encrypted VPN? The need for confidentiality (for fresh keys) is derived from the need for unlinkability (see Daniel's response). Editorial: I believe that for better logical structure, confidentiality should therefore be listed after unlinkability, and be given a short comment acknowledging this derivation. Content: I think necessity is proven and I see no significant downside. > > - Replay prevention: The core NTP specification already has replay > prevention. The proposed language is misleading, implying that without > NTS there is no replay protection. If the existing core protection > against replay is inadequate, please describe the problem(s). You could > also say "NTS offers another, additional layer of replay prevention > beyond what NTP already provides." I don't see how it is helpful to read the NTS proposal as a critique of NTPv4. Content: Relying on timestamps for replay protection simply offers much less entropy than relying on random values. Also, see Daniel's response. Personally, I see necessity for this objective. Also, I cannot see any significant downside. > > - Request-response consistency: The core NTP protocol already has > request-response consistency checks, where useful. The proposed > language is misleading, implying that without NTS there is no > request-response consistency checking. If the existing checks for > request-response consistency is inadequate, please describe the > problem(s). You could also say "NTS offers another, additional layer of > request-response consistency checks beyond what NTP already provides." See replay prevention. > - Unlinkability: The stated threat seems extraordinarily unlikely to be > possible if more than several networks are involved. Even if such a > threat was possible and used, if the client/server model for NTS is to > use NTP packets with NTS extension fields, an outside observer can still > see that there is a client sending requests to a set of servers that > some other client has used before. How is that traffic not "linkable"? > This "feature" seems to be a red-herring. I don't think there is much merit to re-evaluating general IETF policy for our special case. Editorial: can we have a citation for where this policy is stated? Content: - Necessity is derived from general policy. So we will do the best we can. An argument along the lines of "but it might not good enough" should not influence that policy. - This is item 1/2 where we are facing a kind of categorical imperative. The overall system only works if all protocols follow a certain ruleset. Therefore, we must follow that ruleset. In this case, the rule is: do not introduce new ways for an observer to recognize you by your traffic. > - Non-amplification: The core problem is DDoS. Amplification is a > secondary problem. Sure, the avoidance of amplification is a useful > interim step. But the target protocol isn't the place to solve the > DDoS problem. DDoS is basically an "overcommit" problem. BCP38, anyone? See unlinkability. - This is item 2/2 where categorical imperative comes into play. The rule here is: do not introduce new ways for an attacker to direct to a target a message larger than the one sent by the attacker. > - Scalability: The way this is phrased is confusing. If this goal is > specific to NTS, then it should say so. It's a little more complex: NTS must not *introduce a need for* per-client state. But I don't think that level of detail would be helpful here. > Given the subsequent > discussions about C2S, S2C, etc., it also seems disingenuous. Do I understand correctly that you don't believe the objective is being fulfilled? If so, I disagree. But in any event, this question should not influence our policy of having scalability as an objective. > Aside > from these things, it seems to be another red-herring. More detail below. No, scalability is not a "red herring". On the contrary, it is a major reason why we need a new standard (because scalability is a huge drawback of using symmetric key protection). My take-away for the "Objectives" subsection is this: I believe it could be clearer. Specifically, I would suggest we add some language linking to RFC 7384 (Tal's "Security Requirements...") for the objectives that are derived from there, and some other language for objectives that are derived from generic IETF goals for security protocols. I would like to stress that all of this is solvable by small amounts of editorial work. I also believe that nothing in this subsection is wrong or misleading. (Confirmation from other reviewers welcome - again, consensus here is needed as a basis for all other discussion) --=_alternative 002C7119C125818B_= Content-Type: text/html; charset="US-ASCII" Hello all,

I am going to attempt a rundown of Harlan's input, trying to avoid too much overlap with responses that Daniel already gave.
I want to treat the "Objectives" subsection separately, ASAP, because consensus here is really essential for consensus anywhere else.


> [...]
>
> TL;DR version:
>
> There are some parts of the proposal that are wrong, and some other
> parts are misleading.  There are sections of the proposal that are
> confusing, and there are sections of the proposal that are inadequately
> described.
>
> Long version:
>
> 1.1. Objectives
>
> - Confidentiality: Under what conditions is this actually useful?  If
> confidentiality is a need for some, in those situations why not just
> send the NTP traffic over an encrypted VPN?

The need for confidentiality (for fresh keys) is derived from the need for unlinkability (see Daniel's response).
Editorial: I believe that for better logical structure, confidentiality should therefore be listed after unlinkability, and be given a short comment acknowledging this derivation.
Content: I think necessity is proven and I see no significant downside.


>
> - Replay prevention: The core NTP specification already has replay
> prevention.  The proposed language is misleading, implying that without
> NTS there is no replay protection.  If the existing core protection
> against replay is inadequate, please describe the problem(s).  You could
> also say "NTS offers another, additional layer of replay prevention
> beyond what NTP already provides."

I don't see how it is helpful to read the NTS proposal as a critique of NTPv4.
Content: Relying on timestamps for replay protection simply offers much less entropy than relying on random values. Also, see Daniel's response. Personally, I see necessity for this objective. Also, I cannot see any significant downside.


>
> - Request-response consistency: The core NTP protocol already has
> request-response consistency checks, where useful.  The proposed
> language is misleading, implying that without NTS there is no
> request-response consistency checking.  If the existing checks for
> request-response consistency is inadequate, please describe the
> problem(s).  You could also say "NTS offers another, additional layer of
> request-response consistency checks beyond what NTP already provides."

See replay prevention.


> - Unlinkability: The stated threat seems extraordinarily unlikely to be
> possible if more than several networks are involved.  Even if such a
> threat was possible and used, if the client/server model for NTS is to
> use NTP packets with NTS extension fields, an outside observer can still
> see that there is a client sending requests to a set of servers that
> some other client has used before.  How is that traffic not "linkable"?
> This "feature" seems to be a red-herring.

I don't think there is much merit to re-evaluating general IETF policy for our special case.
Editorial: can we have a citation for where this policy is stated?
Content:
- Necessity is derived from general policy. So we will do the best we can. An argument along the lines of "but it might not good enough" should not influence that policy.
- This is item 1/2 where we are facing a kind of categorical imperative. The overall system only works if all protocols follow a certain ruleset. Therefore, we must follow that ruleset. In this case, the rule is: do not introduce new ways for an observer to recognize you by your traffic.


> - Non-amplification: The core problem is DDoS.  Amplification is a
> secondary problem.  Sure, the avoidance of amplification is a useful
> interim step.  But the target protocol isn't the place to solve the
> DDoS problem.  DDoS is basically an "overcommit" problem.  BCP38, anyone?
See unlinkability.
- This is item 2/2 where categorical imperative comes into play. The rule here is: do not introduce new ways for an attacker to direct to a target a message larger than the one sent by the attacker.


> - Scalability: The way this is phrased is confusing.  If this goal is
> specific to NTS, then it should say so.

It's a little more complex: NTS must not *introduce a need for* per-client state.
But I don't think that level of detail would be helpful here.

> Given the subsequent
> discussions about C2S, S2C, etc., it also seems disingenuous.  

Do I understand correctly that you don't believe the objective is being fulfilled?
If so, I disagree. But in any event, this question should not influence our policy of having scalability as an objective.

> Aside
> from these things, it seems to be another red-herring.  More detail below.

No, scalability is not a "red herring". On the contrary, it is a major reason why we need a new standard (because scalability is a huge drawback of using symmetric key protection).



My take-away for the "Objectives" subsection is this:

I believe it could be clearer. Specifically, I would suggest we add some language linking to RFC 7384 (Tal's "Security Requirements...") for the objectives that are derived from there, and some other language for objectives that are derived from generic IETF goals for security protocols.
I would like to stress that all of this is solvable by small amounts of editorial work.

I also believe that nothing in this subsection is wrong or misleading.
(Confirmation from other reviewers welcome - again, consensus here is needed as a basis for all other discussion) --=_alternative 002C7119C125818B_=-- From ntp-bounces@ietf.org Tue Aug 29 01:05:32 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E1686132D49; Tue, 29 Aug 2017 01:05:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1503993931; bh=V5MoAswMlJxPhqN1nwqo1bplT7Xqf5f/Hvjqpa4x/JA=; h=In-Reply-To:References:To:From:Date:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc; b=sbC6lEwa9rBdmL7ouhBcA0Nu6ex/DwqIREfBuKdYPNVIF/r7vYo0PoSABEac8KuR6 Sox2E6clF/oLLLDpSx6v9kg90ytJeMc3QVyDQ8iehyJoKU1sqToi69SD9rWKpKtdaR TyQzKKhBtlWQ58OLSGQLT96R9Grqhi2FjwD5jFko= 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 06C23132D46 for ; Tue, 29 Aug 2017 01:05:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 egMSSZ2bl0xa for ; Tue, 29 Aug 2017 01:05:27 -0700 (PDT) Received: from mx1.bs.ptb.de (mx1.bs.ptb.de [IPv6:2001:638:610:bd01::120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7097A132D49 for ; Tue, 29 Aug 2017 01:05:27 -0700 (PDT) Received: from smtp-hub.bs.ptb.de (smtpint01.bs.ptb.de [141.25.87.32]) by mx1.bs.ptb.de with ESMTP id v7T85Pq9004865-v7T85PqB004865 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 29 Aug 2017 10:05:25 +0200 Received: from lotus.bs.ptb.de (lotus.bs.ptb.de [141.25.85.200]) by smtp-hub.bs.ptb.de (Postfix) with ESMTPS id AF36853357A; Tue, 29 Aug 2017 10:05:25 +0200 (CEST) In-Reply-To: <47b5b4e3-41c9-6779-4a96-b11650483499@nwtime.org> References: <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> <47b5b4e3-41c9-6779-4a96-b11650483499@nwtime.org> To: Harlan Stenn MIME-Version: 1.0 Message-ID: From: kristof.teichel@ptb.de Date: Tue, 29 Aug 2017 10:05:22 +0200 Archived-At: Subject: [Ntp] [NTP] WGLC for draft-ietf-ntp-using-nts-for-ntp (Objectives Subsection) X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: ntp@ietf.org Content-Type: multipart/mixed; boundary="===============0727380197219689446==" Errors-To: ntp-bounces@ietf.org Sender: "ntp" Dies ist eine mehrteilige Nachricht im MIME-Format. --===============0727380197219689446== Content-Type: multipart/alternative; boundary="=_alternative 002C7119C125818B_=" Dies ist eine mehrteilige Nachricht im MIME-Format. --=_alternative 002C7119C125818B_= Content-Type: text/plain; charset="US-ASCII" Hello all, I am going to attempt a rundown of Harlan's input, trying to avoid too much overlap with responses that Daniel already gave. I want to treat the "Objectives" subsection separately, ASAP, because consensus here is really essential for consensus anywhere else. > [...] > > TL;DR version: > > There are some parts of the proposal that are wrong, and some other > parts are misleading. There are sections of the proposal that are > confusing, and there are sections of the proposal that are inadequately > described. > > Long version: > > 1.1. Objectives > > - Confidentiality: Under what conditions is this actually useful? If > confidentiality is a need for some, in those situations why not just > send the NTP traffic over an encrypted VPN? The need for confidentiality (for fresh keys) is derived from the need for unlinkability (see Daniel's response). Editorial: I believe that for better logical structure, confidentiality should therefore be listed after unlinkability, and be given a short comment acknowledging this derivation. Content: I think necessity is proven and I see no significant downside. > > - Replay prevention: The core NTP specification already has replay > prevention. The proposed language is misleading, implying that without > NTS there is no replay protection. If the existing core protection > against replay is inadequate, please describe the problem(s). You could > also say "NTS offers another, additional layer of replay prevention > beyond what NTP already provides." I don't see how it is helpful to read the NTS proposal as a critique of NTPv4. Content: Relying on timestamps for replay protection simply offers much less entropy than relying on random values. Also, see Daniel's response. Personally, I see necessity for this objective. Also, I cannot see any significant downside. > > - Request-response consistency: The core NTP protocol already has > request-response consistency checks, where useful. The proposed > language is misleading, implying that without NTS there is no > request-response consistency checking. If the existing checks for > request-response consistency is inadequate, please describe the > problem(s). You could also say "NTS offers another, additional layer of > request-response consistency checks beyond what NTP already provides." See replay prevention. > - Unlinkability: The stated threat seems extraordinarily unlikely to be > possible if more than several networks are involved. Even if such a > threat was possible and used, if the client/server model for NTS is to > use NTP packets with NTS extension fields, an outside observer can still > see that there is a client sending requests to a set of servers that > some other client has used before. How is that traffic not "linkable"? > This "feature" seems to be a red-herring. I don't think there is much merit to re-evaluating general IETF policy for our special case. Editorial: can we have a citation for where this policy is stated? Content: - Necessity is derived from general policy. So we will do the best we can. An argument along the lines of "but it might not good enough" should not influence that policy. - This is item 1/2 where we are facing a kind of categorical imperative. The overall system only works if all protocols follow a certain ruleset. Therefore, we must follow that ruleset. In this case, the rule is: do not introduce new ways for an observer to recognize you by your traffic. > - Non-amplification: The core problem is DDoS. Amplification is a > secondary problem. Sure, the avoidance of amplification is a useful > interim step. But the target protocol isn't the place to solve the > DDoS problem. DDoS is basically an "overcommit" problem. BCP38, anyone? See unlinkability. - This is item 2/2 where categorical imperative comes into play. The rule here is: do not introduce new ways for an attacker to direct to a target a message larger than the one sent by the attacker. > - Scalability: The way this is phrased is confusing. If this goal is > specific to NTS, then it should say so. It's a little more complex: NTS must not *introduce a need for* per-client state. But I don't think that level of detail would be helpful here. > Given the subsequent > discussions about C2S, S2C, etc., it also seems disingenuous. Do I understand correctly that you don't believe the objective is being fulfilled? If so, I disagree. But in any event, this question should not influence our policy of having scalability as an objective. > Aside > from these things, it seems to be another red-herring. More detail below. No, scalability is not a "red herring". On the contrary, it is a major reason why we need a new standard (because scalability is a huge drawback of using symmetric key protection). My take-away for the "Objectives" subsection is this: I believe it could be clearer. Specifically, I would suggest we add some language linking to RFC 7384 (Tal's "Security Requirements...") for the objectives that are derived from there, and some other language for objectives that are derived from generic IETF goals for security protocols. I would like to stress that all of this is solvable by small amounts of editorial work. I also believe that nothing in this subsection is wrong or misleading. (Confirmation from other reviewers welcome - again, consensus here is needed as a basis for all other discussion) --=_alternative 002C7119C125818B_= Content-Type: text/html; charset="US-ASCII" Hello all,

I am going to attempt a rundown of Harlan's input, trying to avoid too much overlap with responses that Daniel already gave.
I want to treat the "Objectives" subsection separately, ASAP, because consensus here is really essential for consensus anywhere else.


> [...]
>
> TL;DR version:
>
> There are some parts of the proposal that are wrong, and some other
> parts are misleading.  There are sections of the proposal that are
> confusing, and there are sections of the proposal that are inadequately
> described.
>
> Long version:
>
> 1.1. Objectives
>
> - Confidentiality: Under what conditions is this actually useful?  If
> confidentiality is a need for some, in those situations why not just
> send the NTP traffic over an encrypted VPN?

The need for confidentiality (for fresh keys) is derived from the need for unlinkability (see Daniel's response).
Editorial: I believe that for better logical structure, confidentiality should therefore be listed after unlinkability, and be given a short comment acknowledging this derivation.
Content: I think necessity is proven and I see no significant downside.


>
> - Replay prevention: The core NTP specification already has replay
> prevention.  The proposed language is misleading, implying that without
> NTS there is no replay protection.  If the existing core protection
> against replay is inadequate, please describe the problem(s).  You could
> also say "NTS offers another, additional layer of replay prevention
> beyond what NTP already provides."

I don't see how it is helpful to read the NTS proposal as a critique of NTPv4.
Content: Relying on timestamps for replay protection simply offers much less entropy than relying on random values. Also, see Daniel's response. Personally, I see necessity for this objective. Also, I cannot see any significant downside.


>
> - Request-response consistency: The core NTP protocol already has
> request-response consistency checks, where useful.  The proposed
> language is misleading, implying that without NTS there is no
> request-response consistency checking.  If the existing checks for
> request-response consistency is inadequate, please describe the
> problem(s).  You could also say "NTS offers another, additional layer of
> request-response consistency checks beyond what NTP already provides."

See replay prevention.


> - Unlinkability: The stated threat seems extraordinarily unlikely to be
> possible if more than several networks are involved.  Even if such a
> threat was possible and used, if the client/server model for NTS is to
> use NTP packets with NTS extension fields, an outside observer can still
> see that there is a client sending requests to a set of servers that
> some other client has used before.  How is that traffic not "linkable"?
> This "feature" seems to be a red-herring.

I don't think there is much merit to re-evaluating general IETF policy for our special case.
Editorial: can we have a citation for where this policy is stated?
Content:
- Necessity is derived from general policy. So we will do the best we can. An argument along the lines of "but it might not good enough" should not influence that policy.
- This is item 1/2 where we are facing a kind of categorical imperative. The overall system only works if all protocols follow a certain ruleset. Therefore, we must follow that ruleset. In this case, the rule is: do not introduce new ways for an observer to recognize you by your traffic.


> - Non-amplification: The core problem is DDoS.  Amplification is a
> secondary problem.  Sure, the avoidance of amplification is a useful
> interim step.  But the target protocol isn't the place to solve the
> DDoS problem.  DDoS is basically an "overcommit" problem.  BCP38, anyone?
See unlinkability.
- This is item 2/2 where categorical imperative comes into play. The rule here is: do not introduce new ways for an attacker to direct to a target a message larger than the one sent by the attacker.


> - Scalability: The way this is phrased is confusing.  If this goal is
> specific to NTS, then it should say so.

It's a little more complex: NTS must not *introduce a need for* per-client state.
But I don't think that level of detail would be helpful here.

> Given the subsequent
> discussions about C2S, S2C, etc., it also seems disingenuous.  

Do I understand correctly that you don't believe the objective is being fulfilled?
If so, I disagree. But in any event, this question should not influence our policy of having scalability as an objective.

> Aside
> from these things, it seems to be another red-herring.  More detail below.

No, scalability is not a "red herring". On the contrary, it is a major reason why we need a new standard (because scalability is a huge drawback of using symmetric key protection).



My take-away for the "Objectives" subsection is this:

I believe it could be clearer. Specifically, I would suggest we add some language linking to RFC 7384 (Tal's "Security Requirements...") for the objectives that are derived from there, and some other language for objectives that are derived from generic IETF goals for security protocols.
I would like to stress that all of this is solvable by small amounts of editorial work.

I also believe that nothing in this subsection is wrong or misleading.
(Confirmation from other reviewers welcome - again, consensus here is needed as a basis for all other discussion) --=_alternative 002C7119C125818B_=-- --===============0727380197219689446== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp --===============0727380197219689446==-- From nobody Tue Aug 29 01:55:20 2017 Return-Path: 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 8C97A132D58 for ; Tue, 29 Aug 2017 01:55:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.018 X-Spam-Level: X-Spam-Status: No, score=-2.018 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ptbde.onmicrosoft.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 vfN03ON6N2n2 for ; Tue, 29 Aug 2017 01:55:16 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0125.outbound.protection.outlook.com [104.47.1.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F48E132D55 for ; Tue, 29 Aug 2017 01:55:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ptbde.onmicrosoft.com; s=selector1-ptbde-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=S2pejN9wGvPgcKiz5LX0ZrbHjYtTEaQ6TNKb6A7TH+0=; b=oFWxJUIvbzAErrdJeYCD4TOJ5+CI3OY1SkSajkTp/YPuM8XIL1mPskPp+TaUo2qhXRy6AS0VoK95F17VcMeGAA/SAOez0UUplP1JMi3P8NFAFGXNr7YA7O2UI+qDcMYUVQmiQ62K1CMIfRz8bhq4q6g2dNwGAgiZpXFUuWuwOk4= Received: from DB3PR05MB172.eurprd05.prod.outlook.com (10.242.132.18) by DB3PR05MB108.eurprd05.prod.outlook.com (10.255.251.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1385.9; Tue, 29 Aug 2017 08:55:11 +0000 Received: from DB3PR05MB172.eurprd05.prod.outlook.com ([fe80::cf:70d1:53e0:1a6a]) by DB3PR05MB172.eurprd05.prod.outlook.com ([fe80::cf:70d1:53e0:1a6a%17]) with mapi id 15.01.1385.013; Tue, 29 Aug 2017 08:55:11 +0000 From: Dieter Sibold To: "ntp@ietf.org" Thread-Topic: [Ntp] some comments on the NTS4NTP-Draft09 Thread-Index: AQHTEoUfXL53iq6idEaRaWneOGte1aKbIerw Date: Tue, 29 Aug 2017 08:55:10 +0000 Message-ID: References: <70a0c971b2978.598d965e@ostfalia.de> In-Reply-To: <70a0c971b2978.598d965e@ostfalia.de> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=dieter.sibold@ptbde.onmicrosoft.com; x-originating-ip: [192.53.103.119] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB3PR05MB108; 6:VzhdHTp+P8/1UsXHzy0TYZ4kbh8ovP16xUjWw8d6W8zbuYIu4joF/M/nDYfIjIhMxwxwN7k51wYsfbk2dos6c0WpJGz5rye33LnN6DwCQilxpRxL9Th0W4Ecpdk93vunXdzkizENLSEWAwpEfWJOS6jOPodzRVO520j5ygVbbiNYwRkqcxolXEAb0TWdlBpQmXOK/Hog6fZoLVEgNlxsZVyIFByyioSKV4M2pk9MHdHM7DNDv5E/8vtGGrF/xOR2u+U7i21Jki7P9IYMUIwg2Ol02jdw0x8bWzbWpyj83hjZsEUx9N2YMHKli1dVcatX5T4mMAgj+fsuQB2O3MyOZQ==; 5:M89ZaUvsURJlsLd96cj+0BeothudFts024njkXSV5P6lkc7/h8bcXNQ3j9mOjLF+sg3qekS//GS7mzRUFYqatgO0imwAiQI5Fe1Y3xxowbIgq6svAsCI6epgovQWL5XKWO1Q1zFFdyRcBUvQZ2zZAA==; 24:gftIIyg2mAVCwaCRX1uB4aMMRcRQFWwtlUwdrfFOTStBb02FkhhIJaZe52yVVskdNPLABZhw6HVe7izdI6+js0tL6+vPL4QzwKqOMbMyBM4=; 7:l6wwMRvRPawIk8FzIHHS27hTCm3w3tUuZ6ibeDNoSVJA/LSxVvUPi393V83o9RweOlcUtTmcxwqEbc6cozd+pp/6VVmsly8XaB+DBtrUXs8jkfnrds7V2pRFJRqeBiE4Dz3/Yvu22vwOUTh9McxtF7HiWeuxbHzkO8skngp6veHB+aEXKhqNfu3NXkdFm02gLiNxGHNshU+NRcDERUwQiqy/xDt/GXaD3Yoix1embNU= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 172bfda8-8f1a-455a-6f78-08d4eebba820 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(2017082002075)(300000503095)(300135400095)(2017052603199)(49563074)(201703131423075)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DB3PR05MB108; x-ms-traffictypediagnostic: DB3PR05MB108: x-exchange-antispam-report-test: UriScan:(158342451672863)(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(102415395)(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(6041248)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(201703131423075)(201703061421075)(2016111802025)(20161123558100)(6072148)(6043046)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DB3PR05MB108; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DB3PR05MB108; x-forefront-prvs: 0414DF926F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(76094002)(189002)(53754006)(377454003)(2950100002)(6916009)(2351001)(5660300001)(6436002)(14454004)(2900100001)(33656002)(64872007)(53546010)(189998001)(42882006)(2906002)(86902001)(229853002)(54356999)(3660700001)(99286003)(50986999)(508600001)(6506006)(76176999)(55016002)(110136004)(6456002)(3280700002)(5640700003)(561944003)(5250100002)(101416001)(97736004)(74316002)(99936001)(2473003)(790700001)(6116002)(102836003)(106356001)(54896002)(3846002)(9686003)(53936002)(6306002)(25786009)(8676002)(7696004)(5630700001)(81156014)(1730700003)(81166006)(86442002)(66066001)(2501003)(8936002)(105586002)(7736002)(68736007)(86362001)(32563001)(19627235001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR05MB108; H:DB3PR05MB172.eurprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; received-spf: None (protection.outlook.com: ptbde.onmicrosoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/mixed; boundary="_004_DB3PR05MB1725F35D5353CF4038E7E37B39F0DB3PR05MB172eurprd_" MIME-Version: 1.0 X-OriginatorOrg: ptbde.onmicrosoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Aug 2017 08:55:11.0203 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 463cf4b2-037b-4a7c-a75c-ae2c1aef241a X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR05MB108 Archived-At: Subject: [Ntp] FW: some comments on the NTS4NTP-Draft09 X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Aug 2017 08:55:20 -0000 --_004_DB3PR05MB1725F35D5353CF4038E7E37B39F0DB3PR05MB172eurprd_ Content-Type: multipart/alternative; boundary="_000_DB3PR05MB1725F35D5353CF4038E7E37B39F0DB3PR05MB172eurprd_" --_000_DB3PR05MB1725F35D5353CF4038E7E37B39F0DB3PR05MB172eurprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB3YW50IGRyYXcgYXR0ZW50aW9uIHRvIE1hcnRpbiBMYW5nZXLigJlzIHRlY2huaWNhbCBxdWVz dGlvbiBvbiBkcmFmdC1pZXRmLW50cC11c2luZy1udHMtZm9yLW50cCwgd2hpY2ggaGUgc2VudCBh dCAxMXRoIEF1Z3VzdC4NCg0KRnJvbTogbnRwIFttYWlsdG86bnRwLWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZiBPZiBNYXJ0aW4gTGFuZ2VyDQpTZW50OiBGcmlkYXksIEF1Z3VzdCAxMSwgMjAx NyAxMTozNSBBTQ0KVG86IG50cEBpZXRmLm9yZw0KU3ViamVjdDogW050cF0gc29tZSBjb21tZW50 cyBvbiB0aGUgTlRTNE5UUC1EcmFmdDA5DQoNCkhpIGFsbCwNCg0KQXQgZmlyc3QsIEkgd2FudGVk IHRvIHRlbGwgeW91IGJyaWVmbHkgdGhhdCB0aGUgbmV3IE5UUyBpbXBsZW1lbnRhdGlvbiB3aWxs IHN0YXJ0IG5leHQgd2Vlay4gSSBoYXZlIHNvbWUgcG9pbnRzL2NvbW1lbnRzIG9uIHRoZSBOVFM0 TlRQLURyYWZ0MDkgdGhhdCBJIHdhbnRlZCB0byBtZW50aW9uIGluIHRoaXMgd2F5LiBUaGVyZWZv cmUsIHRoZSBjb250ZW50IGlzIHByaW1hcmlseSBkaXJlY3RlZCBhdCBEYW5pZWwgRnJhbmtlLg0K SW4gYWR2YW5jZSwgSSdtIGluIEphcGFuIGZvciB0aGUgbmV4dCAzIHdlZWtzIGFuZCB3aWxsIHBy b2JhYmx5IG5vdCBiZSBhYmxlIHRvIHJlc3BvbmQgdG8gY29tbWVudHMgb3IgZW1haWxzLiBJIGFz ayBmb3IgdW5kZXJzdGFuZGluZy4NCg0KDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCk5UUzRO VFAtRHJhZnQwOQ0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQoNCg0KMS4gY29uZnVzaW5nIHRl cm0gIm50cC80Ig0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09DQoNCnBhZ2UgMTAgKGNoYXB0ZXIgNS4xLjUsIDJuZCBzZWN0aW9uKToN Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpbLi4uXSBJZiB0aGUg TlRTIE5leHQgUHJvdG9jb2wgTmVnb3RpYXRpb24gcmVjb3JkIG9mZmVycyAibnRwLzQiLHRoaXMg cmVjb3JkIE1VU1QgYmUgaW5jbHVkZWQgZXhhY3RseSBvbmNlLiBbLi4uXQ0KDQoNCnBhZ2UgMTEg KGNoYXB0ZXIgNS4xLjUsIDR0aCBzZWN0aW9uKToNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQpbLi4uXSBhbmQgdGhlIHNlcnZlciBhY2NlcHRzIHRoZSAibnRwLzQi IHByb3RvY29sIGluIGl0cyBOVFMgTmV4dCBQcm90b2NvbCBOZWdvdGlhdGlvbiByZWNvcmQgWy4u Ll0NCg0KDQpwYWdlIDExIChjaGFwdGVyIDYuMSwgMXN0IHNlY3Rpb24pOg0KLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClsuLi5dIEZvbGxvd2luZyBhIHN1Y2Nlc3Nm dWwgcnVuIG9mIHRoZSBOVFMtS0UgcHJvdG9jb2wgd2hlcmVpbiAibnRwLzQiIGlzIHNlbGVjdGVk IGFzIGEgTmV4dCBQcm90b2NvbCBbLi4uXQ0KDQoNCnJlbWFyazoNCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoibnRwLzQiIGlzIHRoZSBzYW1lIHRlcm0gYXMgaW4g dGhlIFRMUyBBTFBOIGV4dGVuc2lvbiAoc2VlOiBwYWdlIDE4LCBjaGFwdGVyIDgpOg0KDQpbLi4u XSBJQU5BIGlzIHJlcXVlc3RlZCB0byBhbGxvY2F0ZSB0aGUgZm9sbG93aW5nIHR3byBlbnRyaWVz IGluIHRoZSBBcHBsaWNhdGlvbi1MYXllciBQcm90b2NvbCBOZWdvdGF0aW9uIChBTFBOKSBQcm90 b2NvbCBJRHMgcmVnaXN0cnk6IFsuLi5dIFByb3RvY29sOiBOZXR3b3JrIFRpbWUgUHJvdG9jb2ws IHZlcnNpb24gNCAgIElkZW50aWZpY2F0aW9uIFNlcXVlbmNlOiAweDZFIDB4NzQgMHg3MCAweDJG IDB4MzQgKCJudHAvNCIpIFsuLi5dDQoNCkJ1dCB0aGUgTlRTIE5leHQgUHJvdG9jb2wgTmVnb3Rp YXRpb24gcmVjb3JkIGNvbnRhaW5zIElEcyAoZS5nLiAweDAwIGZvciAnTmV0d29yayBUaW1lIFBy b3RvY29sIHZlcnNpb24gNCc7IHNlZSB0YWJsZSBhdCBwYWdlIDIxKSBhbmQgbm90IHRoZSB0ZXJt ICdudHAvNCcuIFRoaXMgY2FuIGNvbmZ1c2luZyBzb21lIHJlYWRlcnMuDQoNCg0KDQoNCg0KMi4g TmV0d29yayBCeXRlIE9yZGVyIC8gSG9zdCBCeXRlIE9yZGVyDQo9PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCg0KcGFnZSA4IChjaGFw dGVyIDUsIDV0aCBzZWN0aW9uKToNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQpbLi4uXSBSZWNvcmQgVHlwZTogQSAxNS1iaXQgaW50ZWdlciBpbiBuZXR3b3JrIGJ5 dGUgb3JkZXIgKGZyb20gbW9zdC10by1sZWFzdCBzaWduaWZpY2FudCwgaXRzIGJpdHMgYXJlIHJl Y29yZCBiaXRzIDctMSBhbmQgdGhlbiAxNS04KS4gWy4uLl0NCg0KDQpyZW1hcms6DQotLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KV2h5IDctMSBhbmQgdGhlbiAxNS04 PyBBcmUgd2UgdXNlIHRoZSBMaXR0bGUgRW5kaWFuIGZvcm1hdCBmb3IgdGhlICdSZWNvcmQgVHlw ZScgb25seSBvciBmb3IgdGhlIHdob2xlIHJlY29yZD8gV2h5IHdlIGRvbid0IHVzZSBCaWcgRW5k aWFuPw0KDQoNCg0KDQoNCg0KMy4gZ2VuZXJhbCBjb21tZW50DQo9PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCg0KcGFnZSAxMiAoY2hh cHRlciA2LjEsIDJuZCBzZWN0aW9uKToNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQpbLi4uXSBUaGUgcGVyLWFzc29jaWF0aW9uIGNvbnRleHQgdmFsdWUgU0hBTEwg Y29uc2lzdCBvZiB0aGUgZm9sbG93aW5nIGZpdmUgb2N0ZXRzOiBUaGUgZmlyc3QgdHdvIG9jdGV0 cyBTSEFMTCBiZSB6ZXJvLlsuLi5dDQoNCg0KcmVtYXJrOg0KLS0tLS0tLS0tLS0NCk15IGZpcnN0 IHRob3VnaHQgd2FzOiB3aHk/IEF0IGZpcnN0IGl0IHdhcyBhIG1hZ2ljIG51bWJlciBmb3IgbWUu IFRoZSBzb2x1dGlvbiBpcyBoZXJlOiBjaGFwdGVyIDUuMjoNClsuLi5dIGFuZCBNVVNUIGJlZ2lu IHdpdGggdGhlIHR3by1vY3RldCBQcm90b2NvbCBJRCB3aGljaCB3YXMgbmVnb3RpYXRlZCBhcyBh IE5leHQgUHJvdG9jb2wuIFsuLi5dDQoNCkkgdGhpbmsgdGhpcyBzaG91bGQgYmUgbWVudGlvbmVk IGFnYWluIG9yIHJlZmVyZW5jZWQgdG8gdGhlIGNvcnJlc3BvbmRpbmcgdGFibGUgKGNoYXB0ZXIg OCkuDQoNCg0KDQoNCg0KNC4gZ2VuZXJhbCBjb21tZW50DQo9PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCg0KcGFnZSAxMyAoY2hhcHRl ciA2LjUsIDJuZCBzZWN0aW9uKToNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQpbLi4uXSBUaGlzIGxlbmd0aCByZXF1aXJlbWVudCBzZXJ2ZXMgdG8gZW5zdXJlIHRo YXQgdGhlIHJlc3BvbnNlIHdpbGwgbm90IGJlIGxhcmdlciB0aGFuIHRoZSByZXF1ZXN0LCBpbiBv cmRlciB0byBpbXByb3ZlIHRpbWVrZWVwaW5nIHByZWNpc2lvbiBhbmQgWy4uLl0NCg0KDQpyZW1h cms6DQotLS0tLS0tLS0tLQ0KRG9lcyBpdCByZWFsbHkgaW1wcm92ZSB0aGUgdGltZWtlZXBpbmc/ IEkgdGhpbmsgdGhlIGlkZWEgaXMgdG8gcmVkdWNlIHRoZSBhc3ltbWV0cnkgaWYgdGhlIHJlcXVl c3QgYW5kIHJlc3BvbnNlIG1lc3NhZ2UgaGF2ZSB0aGUgc2FtZSBzaXplLg0KQnV0IGNsaWVudCBh bmQgc2VydmVyIG1heSBoYXZlIGRpZmZlcmVudCBwZXJmb3JtYW5jZSBhbmQgdGhlcmVmb3JlIHRo ZSBwcm9jZXNzaW5nIHNwZWVkIHBlciBOVFAgUGFja2FnZSBpcyBkaWZmZXJlbnQgdG9vLiAgLi4u aXQncyBqdXN0IGEgdGhvdWdodA0KDQoNCg0KDQoNCjUuIGFsdGVybmF0aXZlIHByb3Bvc2FsDQo9 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT0NCg0KcGFnZSAyMCAoY2hhcHRlciA4LCAxc3Qgc2VjdGlvbik6DQotLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWy4uLl0gVHlwZSBOdW1iZXIgKFJFUVVJUkVEKTog QW4gaW50ZWdlciBpbiB0aGUgcmFuZ2UgMC0zMjc2NyBpbmNsdXNpdmUgWy4uLl0NCg0KDQpiZXR0 ZXI/Og0KLS0tLS0tLS0tLS0NClsuLi5dIFR5cGUgTnVtYmVyIChSRVFVSVJFRCk6IEFuIDE1IGJp dCBpbnRlZ2VyIGluIHRoZSByYW5nZSAwLTMyNzY3IGluY2x1c2l2ZSBbLi4uXQ0KDQouLi4ubm90 IDE2IGJpdCwgYmVjYXVzZSB3ZSB1c2UgYSBjcml0aWNhbCBiaXQgaW4gb3VyIHJlY29yZHMgKGZp cnN0IGJpdCkNCg0KDQoNCg0KDQoNCjYuIHNvbWUgcHJvYmxlbXMgd2l0aCAnVGhlIE5UUyBBdXRo ZW50aWNhdG9yIGFuZCBFbmNyeXB0ZWQgRXh0ZW5zaW9ucyBleHRlbnNpb24nIChwYWdlIDE0LCBj aGFwdGVyIDYuNikNCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PQ0KDQpmaWVsZCBkZXNjcmlwdGlvbjoNCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQonTm9uY2UgbGVuZ2h0JzogV2Ugc2hvdWxkIG1lbnRp b24gdGhhdCB0aGUgdmFsdWUgaXMgdG8gYmUgaW50ZXJwcmV0ZWQgYXMgJ3Vuc2lnbmVkIGludCcu DQoNCidOb25jZSc6IEF0IGZpcnN0IEkgaGFkIHNvbWUgdHJvdWJsZSB0byB1bmRlcnN0YW5kIHdo ZXJlIHRoZSBub25jZSBjb21lcyBmcm9tIGFuZCB3aGljaCBsZW5ndGggd2UgdXNlLiBOb3cgSSBr bm93IGl0LCBidXQgbWF5YmUgd2Ugc2hvdWxkIGFkZCBzb21lIG1vcmUgaW5mb3JtYXRpb24gdG8g dGhpcyBmaWVsZC4NCnBlcmhhcHMgZnJvbSB0aGVzZTogICBbLi4uXSBOb25jZTogYSBub25jZSBh cyByZXF1aXJlZCBieSB0aGUgbmVnb3RpYXRlZCBBRUFEIEFsZ29yaXRobS4gWy4uLl0gICB0byB0 aGVzZTogICBbLi4uXSBOb25jZTogYSBuZXcgZ2VuZXJhdGVkIG5vbmNlIHdob3NlIGxlbmd0aCBh bmQgZm9ybWF0IGlzIGRldGVybWluZWQgYnkgdGhlIG5lZ290aWF0ZWQgQUVBRCBhbGdvcml0aG0g KFJGQyA1MTE2LCBjaGFwdGVyIDMuMikuIFsuLi5dDQoNCg0KJ0NoaXBlcnRleHQnOiBTb21lIHJl YWRlcnMgKHN0dWRlbnRzIGluIG15IHRlYW0pIGhhZCBkaWZmaWN1bHRpZXMgdG8gdW5kZXJzdGFu ZCB0aGlzIGZpZWxkLiBBbGwgb2YgdGhlbSB0aG91Z2h0LCB0aGF0IHRoaXMgZmllbGQgY29udGFp bnMgYW4gZW5jcnlwdGVkIHZlcnNpb24gb2YgdGhlIHdob2xlIE5UUCBwYWNrYWdlLiBBbmQgdGhp cyBpcyB3cm9uZy4gSSB0aGluayB0aGUgcHJvYmxlbSBpcyB0aGlzIGxpbmU6IFsuLi5dIGF1dGhl bnRpY2F0aW9uIHRhZyBpbiBhZGRpdGlvbiB0byB0aGUgYWN0dWFsIGNpcGhlcnRleHQuIFsuLi5d LiBXZWxsLCBpZiByZWFkZXJzIGRvIG5vdCBrbm93IGV4YWN0bHkgaG93IEFFQUQgd29ya3MsIHRo ZW4gdGhpcyBsZWFkcyB0byBzdHJvbmcgdW5kZXJzdGFuZGluZyBwcm9ibGVtcyBhdCB0aGlzIHBv aW50LCBzaW5jZSB0aGUgdGVybXMgJ2F1dGhlbnRpY2F0aW9uIHRhZycgYW5kICdjaXBoZXJ0ZXh0 JyBzZWVtIG5vdCBrbm93bi4gSSB0aGluayB3ZSBzaG91bGQgYWRkIGEgcmVmZXJlbmNlIChSRkMg NTExNiAtLT4gQUVBRCkgb3Igc29tZSBpbmZvcm1hdGlvbiBhYm91dCB0aGlzIHRlcm1zICgnYXV0 aGVudGljYXRpb24gdGFnJyBpcyBsaWtlIGEgTUFDIGFuZCAnY2lwaGVydGV4dCcgY29udGFpbnMg b3B0aW9uYWwgRXh0ZW5zaW9uIEZpZWxkcyBhbmQgY2FuIGJlIGFic2VudCBpZiBubyBFeHRlbnNp b24gRmllbGRzIGFyZSBlbmNyeXB0ZWQuKS4gTWF5YmUgY29uZnVzZXMgdGhlIGZpZWxkIG5hbWUg J0NoaXBlcnRleHQnIHRvby4NCg0KDQonUGFkZGluZzonICBUaGlzIGxpbmU6IFsuLi5dIHNvIHRo YXQgaW1wbGVtZW50YXRpb25zIGNhbiB1bmFtYmlndW91c2x5IGRlbGltaXQgdGhlIGVuZCBvZiB0 aGUgY2lwaGVydGV4dCBmcm9tIHRoZSBzdGFydCBvZiB0aGUgcGFkZGluZyBbLi4uXSBjYW4gYmUg ZGlmZmljdWx0IHRvLiBJbiB0aGUgYmVnaW5uaW5nIEkgZGlkIG5vdCBrbm93IGhvdyB0aGlzIHNo b3VsZCB3b3JrLiBXZSBzaG91bGQgc2F5IHRoYXQgaW1wbGVtZW50YXRpb25zIGNhbiByZWFkIHRo ZSBsYXN0IG9jdGV0IG9mIHRoaXMgZXh0ZW5zaW9uIGNvbnRlbnQsIHRvIGZpbmQgb3V0IGhvdyBi aWcgdGhlIHBhZGRpbmcgaXMuDQoNCkZ1cnRoZXJtb3JlIHdlIHNob3VsZCBjaGFuZ2UgdGhpcyBs aW5lOg0KWy4uLl0gcmVxdWlyZW1lbnQgdGhhdCAoaW4gdGhlIGFic2VuY2Ugb2YgYSBsZWdhY3kg TUFDKSBleHRlbnNpb25zIGhhdmUgYSB0b3RhbCBsZW5ndGggaW4gb2N0ZXRzIChpbmNsdWRpbmcg dGhlIGZvdXIgb2N0ZXRzIGZvciB0aGUgdHlwZSBhbmQgbGVuZ3RoIGZpZWxkcykgIFsuLi5dDQoN CmluIHRoaXM6DQpbLi4uXSByZXF1aXJlbWVudCB0aGF0IChpbiB0aGUgYWJzZW5jZSBvZiBhIGxl Z2FjeSBNQUMpIE5UUCBleHRlbnNpb25zIGhhdmUgYSB0b3RhbCBsZW5ndGggaW4gb2N0ZXRzIChp bmNsdWRpbmcgdGhlIGZvdXIgb2N0ZXRzIGZvciB0aGUgdHlwZSBhbmQgbGVuZ3RoIGZpZWxkcykg Wy4uLl0NCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpbLi4uXSBQOiBU aGUgcGxhaW50ZXh0IFNIQUxMIGNvbnNpc3Qgb2YgYWxsIChpZiBhbnkpIGV4dGVuc2lvbnMgdG8g YmUgZW5jcnlwdGVkLiBbLi4uXQ0KDQpXaGljaCBmb3JtYXQ/IFR5cGljYWwgTlRQdjQgRXh0ZW5z aW9uIEZpZWxkcyBvciBhbm90aGVyIGZvcm1hdD8gV2Ugc2hvdWxkIGRlZmluZSB0aGF0LiBXZSBz aG91bGQgYWxzbyBtZW50aW9uIHRoYXQgb25seSB0aGlzIGNvbnRlbnQgaXMgZW5jcnlwdGVkIChu b3QgdGhlIGNvbnRlbnQgb2YgcGFyYW1ldGVyICdBJykuDQpJZiB3ZSBkb24ndCB3YW50IGVuY3J5 cHQgYW55dGhpbmcgKGRlZmF1bHQgY2FzZSksIHRoZW4gdGhpcyBwYXJhbWV0ZXIgaXMgZW1wdHku DQoNCg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09DQoNClBsZWFzZSBsZXQgbWUga25vdyBpZiB5b3UgaGF2ZSBwcm9ibGVtcyB0byB1 bmRlcnN0YW5kIG15ICplbmdsaXNoKi4NCg0KDQpCZXN0IHJlZ2FyZHMsDQpNYXJ0aW4NCg== --_000_DB3PR05MB1725F35D5353CF4038E7E37B39F0DB3PR05MB172eurprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBz cGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBs aS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7 DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEyLjBw dDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLkUtTWFpbEZv cm1hdHZvcmxhZ2UxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBE ZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJbXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0K CW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgMi4wY20gNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24x DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94 bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2 OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFw ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkRFIiBsaW5r PSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjttc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+SSB3YW50IGRyYXcgYXR0ZW50aW9uIHRvIE1hcnRpbiBMYW5n ZXLigJlzIHRlY2huaWNhbCBxdWVzdGlvbiBvbiBkcmFmdC1pZXRmLW50cC11c2luZy1udHMtZm9y LW50cCwgd2hpY2ggaGUgc2VudCBhdCAxMTxzdXA+dGg8L3N1cD4gQXVndXN0LjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9z ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9hPjwvcD4NCjxzcGFuIHN0eWxlPSJtc28tYm9v a21hcms6X01haWxFbmRDb21wb3NlIj48L3NwYW4+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+IG50cCBbbWFpbHRvOm50cC1ib3VuY2VzQGlldGYub3JnXQ0KPGI+ T24gQmVoYWxmIE9mIDwvYj5NYXJ0aW4gTGFuZ2VyPGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwg QXVndXN0IDExLCAyMDE3IDExOjM1IEFNPGJyPg0KPGI+VG86PC9iPiBudHBAaWV0Zi5vcmc8YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gW050cF0gc29tZSBjb21tZW50cyBvbiB0aGUgTlRTNE5UUC1EcmFm dDA5PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPkhpIGFs bCw8YnI+DQo8YnI+DQpBdCBmaXJzdCwgSSB3YW50ZWQgdG8gdGVsbCB5b3UgYnJpZWZseSB0aGF0 IHRoZSBuZXcgTlRTIGltcGxlbWVudGF0aW9uIHdpbGwgc3RhcnQgbmV4dCB3ZWVrLiBJIGhhdmUg c29tZSBwb2ludHMvY29tbWVudHMgb24gdGhlIE5UUzROVFAtRHJhZnQwOSB0aGF0IEkgd2FudGVk IHRvIG1lbnRpb24gaW4gdGhpcyB3YXkuIFRoZXJlZm9yZSwgdGhlIGNvbnRlbnQgaXMgcHJpbWFy aWx5IGRpcmVjdGVkIGF0IERhbmllbCBGcmFua2UuPGJyPg0KSW4gYWR2YW5jZSwgSSdtIGluIEph cGFuIGZvciB0aGUgbmV4dCAzIHdlZWtzIGFuZCB3aWxsIHByb2JhYmx5IG5vdCBiZSBhYmxlIHRv IHJlc3BvbmQgdG8gY29tbWVudHMgb3IgZW1haWxzLiBJIGFzayBmb3IgdW5kZXJzdGFuZGluZy48 YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPj09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTxi cj4NCk5UUzROVFAtRHJhZnQwOTxicj4NCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTxicj4NCjxi cj4NCjxicj4NCjEuIGNvbmZ1c2luZyB0ZXJtICZxdW90O250cC80JnF1b3Q7PGJyPg0KPT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PGJy Pg0KPGJyPg0KcGFnZSAxMCAoY2hhcHRlciA1LjEuNSwgMm5kIHNlY3Rpb24pOjxicj4NCi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KWy4uLl0gSWYgdGhlIE5U UyBOZXh0IFByb3RvY29sIE5lZ290aWF0aW9uIHJlY29yZCBvZmZlcnMgJnF1b3Q7bnRwLzQmcXVv dDssdGhpcyByZWNvcmQgTVVTVCBiZSBpbmNsdWRlZCBleGFjdGx5IG9uY2UuIFsuLi5dPGJyPg0K PGJyPg0KPGJyPg0KcGFnZSAxMSAoY2hhcHRlciA1LjEuNSwgNHRoIHNlY3Rpb24pOjxicj4NCi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KWy4uLl0gYW5kIHRo ZSBzZXJ2ZXIgYWNjZXB0cyB0aGUgJnF1b3Q7bnRwLzQmcXVvdDsgcHJvdG9jb2wgaW4gaXRzIE5U UyBOZXh0IFByb3RvY29sIE5lZ290aWF0aW9uIHJlY29yZCBbLi4uXTxicj4NCjxicj4NCjxicj4N CnBhZ2UgMTEgKGNoYXB0ZXIgNi4xLCAxc3Qgc2VjdGlvbik6PGJyPg0KLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQpbLi4uXSBGb2xsb3dpbmcgYSBzdWNjZXNz ZnVsIHJ1biBvZiB0aGUgTlRTLUtFIHByb3RvY29sIHdoZXJlaW4gJnF1b3Q7bnRwLzQmcXVvdDsg aXMgc2VsZWN0ZWQgYXMgYSBOZXh0IFByb3RvY29sIFsuLi5dPGJyPg0KPGJyPg0KPGJyPg0KcmVt YXJrOjxicj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0K JnF1b3Q7bnRwLzQmcXVvdDsgaXMgdGhlIHNhbWUgdGVybSBhcyBpbiB0aGUgVExTIEFMUE4gZXh0 ZW5zaW9uIChzZWU6IHBhZ2UgMTgsIGNoYXB0ZXIgOCk6PGJyPg0KPGJyPg0KWy4uLl0gSUFOQSBp cyByZXF1ZXN0ZWQgdG8gYWxsb2NhdGUgdGhlIGZvbGxvd2luZyB0d28gZW50cmllcyBpbiB0aGUg QXBwbGljYXRpb24tTGF5ZXIgUHJvdG9jb2wgTmVnb3RhdGlvbiAoQUxQTikgUHJvdG9jb2wgSURz IHJlZ2lzdHJ5OiBbLi4uXSBQcm90b2NvbDogTmV0d29yayBUaW1lIFByb3RvY29sLCB2ZXJzaW9u IDQmbmJzcDsmbmJzcDsgSWRlbnRpZmljYXRpb24gU2VxdWVuY2U6IDB4NkUgMHg3NCAweDcwIDB4 MkYgMHgzNCAoJnF1b3Q7bnRwLzQmcXVvdDspIFsuLi5dPGJyPg0KPGJyPg0KQnV0IHRoZSBOVFMg TmV4dCBQcm90b2NvbCBOZWdvdGlhdGlvbiByZWNvcmQgY29udGFpbnMgSURzIChlLmcuIDB4MDAg Zm9yICdOZXR3b3JrIFRpbWUgUHJvdG9jb2wgdmVyc2lvbiA0Jzsgc2VlIHRhYmxlIGF0IHBhZ2Ug MjEpIGFuZCBub3QgdGhlIHRlcm0gJ250cC80Jy4gVGhpcyBjYW4gY29uZnVzaW5nIHNvbWUgcmVh ZGVycy48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQoyLiBOZXR3b3JrIEJ5dGUg T3JkZXIgLyBIb3N0IEJ5dGUgT3JkZXI8YnI+DQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08YnI+DQo8YnI+DQpwYWdlIDggKGNoYXB0 ZXIgNSwgNXRoIHNlY3Rpb24pOjxicj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tPGJyPg0KWy4uLl0gUmVjb3JkIFR5cGU6IEEgMTUtYml0IGludGVnZXIgaW4gbmV0 d29yayBieXRlIG9yZGVyIChmcm9tIG1vc3QtdG8tbGVhc3Qgc2lnbmlmaWNhbnQsIGl0cyBiaXRz IGFyZSByZWNvcmQgYml0cyA3LTEgYW5kIHRoZW4gMTUtOCkuIFsuLi5dPGJyPg0KPGJyPg0KPGJy Pg0KcmVtYXJrOjxicj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t IDxicj4NCldoeSA3LTEgYW5kIHRoZW4gMTUtOD8gQXJlIHdlIHVzZSB0aGUgTGl0dGxlIEVuZGlh biBmb3JtYXQgZm9yIHRoZSAnUmVjb3JkIFR5cGUnIG9ubHkgb3IgZm9yIHRoZSB3aG9sZSByZWNv cmQ/IFdoeSB3ZSBkb24ndCB1c2UgQmlnIEVuZGlhbj88YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8 YnI+DQo8YnI+DQo8YnI+DQozLiBnZW5lcmFsIGNvbW1lbnQ8YnI+DQo9PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08YnI+DQo8YnI+DQpw YWdlIDEyIChjaGFwdGVyIDYuMSwgMm5kIHNlY3Rpb24pOjxicj4NCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KWy4uLl0gVGhlIHBlci1hc3NvY2lhdGlvbiBj b250ZXh0IHZhbHVlIFNIQUxMIGNvbnNpc3Qgb2YgdGhlIGZvbGxvd2luZyBmaXZlIG9jdGV0czog VGhlIGZpcnN0IHR3byBvY3RldHMgU0hBTEwgYmUgemVyby5bLi4uXTxicj4NCjxicj4NCjxicj4N CnJlbWFyazo8YnI+DQotLS0tLS0tLS0tLSA8YnI+DQpNeSBmaXJzdCB0aG91Z2h0IHdhczogd2h5 PyBBdCBmaXJzdCBpdCB3YXMgYSBtYWdpYyBudW1iZXIgZm9yIG1lLiBUaGUgc29sdXRpb24gaXMg aGVyZTogY2hhcHRlciA1LjI6DQo8YnI+DQpbLi4uXSBhbmQgTVVTVCBiZWdpbiB3aXRoIHRoZSB0 d28tb2N0ZXQgUHJvdG9jb2wgSUQgd2hpY2ggd2FzIG5lZ290aWF0ZWQgYXMgYSBOZXh0IFByb3Rv Y29sLiBbLi4uXTxicj4NCjxicj4NCkkgdGhpbmsgdGhpcyBzaG91bGQgYmUgbWVudGlvbmVkIGFn YWluIG9yIHJlZmVyZW5jZWQgdG8gdGhlIGNvcnJlc3BvbmRpbmcgdGFibGUgKGNoYXB0ZXIgOCku PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KNC4gZ2VuZXJhbCBjb21tZW50PGJy Pg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PGJyPg0KPGJyPg0KcGFnZSAxMyAoY2hhcHRlciA2LjUsIDJuZCBzZWN0aW9uKTo8YnI+ DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NClsuLi5dIFRo aXMgbGVuZ3RoIHJlcXVpcmVtZW50IHNlcnZlcyB0byBlbnN1cmUgdGhhdCB0aGUgcmVzcG9uc2Ug d2lsbCBub3QgYmUgbGFyZ2VyIHRoYW4gdGhlIHJlcXVlc3QsIGluIG9yZGVyIHRvIGltcHJvdmUg dGltZWtlZXBpbmcgcHJlY2lzaW9uIGFuZCBbLi4uXTxicj4NCjxicj4NCjxicj4NCnJlbWFyazo8 YnI+DQotLS0tLS0tLS0tLSA8YnI+DQpEb2VzIGl0IHJlYWxseSBpbXByb3ZlIHRoZSB0aW1la2Vl cGluZz8gSSB0aGluayB0aGUgaWRlYSBpcyB0byByZWR1Y2UgdGhlIGFzeW1tZXRyeSBpZiB0aGUg cmVxdWVzdCBhbmQgcmVzcG9uc2UgbWVzc2FnZSBoYXZlIHRoZSBzYW1lIHNpemUuDQo8YnI+DQpC dXQgY2xpZW50IGFuZCBzZXJ2ZXIgbWF5IGhhdmUgZGlmZmVyZW50IHBlcmZvcm1hbmNlIGFuZCB0 aGVyZWZvcmUgdGhlIHByb2Nlc3Npbmcgc3BlZWQgcGVyIE5UUCBQYWNrYWdlIGlzIGRpZmZlcmVu dCB0b28uJm5ic3A7IC4uLml0J3MganVzdCBhIHRob3VnaHQ8YnI+DQo8YnI+DQo8YnI+DQo8YnI+ DQo8YnI+DQo8YnI+DQo1LiBhbHRlcm5hdGl2ZSBwcm9wb3NhbDxicj4NCj09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTxicj4NCjxicj4N CnBhZ2UgMjAgKGNoYXB0ZXIgOCwgMXN0IHNlY3Rpb24pOjxicj4NCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KWy4uLl0gVHlwZSBOdW1iZXIgKFJFUVVJUkVE KTogQW4gaW50ZWdlciBpbiB0aGUgcmFuZ2UgMC0zMjc2NyBpbmNsdXNpdmUgWy4uLl08YnI+DQo8 YnI+DQo8YnI+DQpiZXR0ZXI/Ojxicj4NCi0tLS0tLS0tLS0tIDxicj4NClsuLi5dIFR5cGUgTnVt YmVyIChSRVFVSVJFRCk6IEFuIDxiPjE1IGJpdDwvYj4gaW50ZWdlciBpbiB0aGUgcmFuZ2UgMC0z Mjc2NyBpbmNsdXNpdmUgWy4uLl08YnI+DQo8YnI+DQouLi4ubm90IDE2IGJpdCwgYmVjYXVzZSB3 ZSB1c2UgYSBjcml0aWNhbCBiaXQgaW4gb3VyIHJlY29yZHMgKGZpcnN0IGJpdCk8YnI+DQo8YnI+ DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo2LiBzb21lIHByb2JsZW1zIHdpdGggJ1Ro ZSBOVFMgQXV0aGVudGljYXRvciBhbmQgRW5jcnlwdGVkIEV4dGVuc2lvbnMgZXh0ZW5zaW9uJyAo cGFnZSAxNCwgY2hhcHRlciA2LjYpPGJyPg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PGJyPg0KPGJyPg0KZmllbGQgZGVzY3JpcHRp b246PGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQon Tm9uY2UgbGVuZ2h0JzogV2Ugc2hvdWxkIG1lbnRpb24gdGhhdCB0aGUgdmFsdWUgaXMgdG8gYmUg aW50ZXJwcmV0ZWQgYXMgJ3Vuc2lnbmVkIGludCcuPGJyPg0KPGJyPg0KJ05vbmNlJzogQXQgZmly c3QgSSBoYWQgc29tZSB0cm91YmxlIHRvIHVuZGVyc3RhbmQgd2hlcmUgdGhlIG5vbmNlIGNvbWVz IGZyb20gYW5kIHdoaWNoIGxlbmd0aCB3ZSB1c2UuIE5vdyBJIGtub3cgaXQsIGJ1dCBtYXliZSB3 ZSBzaG91bGQgYWRkIHNvbWUgbW9yZSBpbmZvcm1hdGlvbiB0byB0aGlzIGZpZWxkLjxicj4NCnBl cmhhcHMgZnJvbSB0aGVzZTombmJzcDsmbmJzcDsgWy4uLl0gTm9uY2U6IGEgbm9uY2UgYXMgcmVx dWlyZWQgYnkgdGhlIG5lZ290aWF0ZWQgQUVBRCBBbGdvcml0aG0uIFsuLi5dJm5ic3A7Jm5ic3A7 IHRvIHRoZXNlOiZuYnNwOyZuYnNwOyBbLi4uXSBOb25jZTogYSBuZXcgZ2VuZXJhdGVkIG5vbmNl IHdob3NlIGxlbmd0aCBhbmQgZm9ybWF0IGlzIGRldGVybWluZWQgYnkgdGhlIG5lZ290aWF0ZWQg QUVBRCBhbGdvcml0aG0gKFJGQyA1MTE2LCBjaGFwdGVyIDMuMikuIFsuLi5dPGJyPg0KPGJyPg0K PGJyPg0KJ0NoaXBlcnRleHQnOiBTb21lIHJlYWRlcnMgKHN0dWRlbnRzIGluIG15IHRlYW0pIGhh ZCBkaWZmaWN1bHRpZXMgdG8gdW5kZXJzdGFuZCB0aGlzIGZpZWxkLiBBbGwgb2YgdGhlbSB0aG91 Z2h0LCB0aGF0IHRoaXMgZmllbGQgY29udGFpbnMgYW4gZW5jcnlwdGVkIHZlcnNpb24gb2YgdGhl IHdob2xlIE5UUCBwYWNrYWdlLiBBbmQgdGhpcyBpcyB3cm9uZy4gSSB0aGluayB0aGUgcHJvYmxl bSBpcyB0aGlzIGxpbmU6IFsuLi5dIGF1dGhlbnRpY2F0aW9uDQogdGFnIGluIGFkZGl0aW9uIHRv IHRoZSBhY3R1YWwgY2lwaGVydGV4dC4gWy4uLl0uIFdlbGwsIGlmIHJlYWRlcnMgZG8gbm90IGtu b3cgZXhhY3RseSBob3cgQUVBRCB3b3JrcywgdGhlbiB0aGlzIGxlYWRzIHRvIHN0cm9uZyB1bmRl cnN0YW5kaW5nIHByb2JsZW1zIGF0IHRoaXMgcG9pbnQsIHNpbmNlIHRoZSB0ZXJtcyAnYXV0aGVu dGljYXRpb24gdGFnJyBhbmQgJ2NpcGhlcnRleHQnIHNlZW0gbm90IGtub3duLiBJIHRoaW5rIHdl IHNob3VsZCBhZGQNCiBhIHJlZmVyZW5jZSAoUkZDIDUxMTYgLS0mZ3Q7IEFFQUQpIG9yIHNvbWUg aW5mb3JtYXRpb24gYWJvdXQgdGhpcyB0ZXJtcyAoJ2F1dGhlbnRpY2F0aW9uIHRhZycgaXMgbGlr ZSBhIE1BQyBhbmQgJ2NpcGhlcnRleHQnIGNvbnRhaW5zIG9wdGlvbmFsIEV4dGVuc2lvbiBGaWVs ZHMgYW5kIGNhbiBiZSBhYnNlbnQgaWYgbm8gRXh0ZW5zaW9uIEZpZWxkcyBhcmUgZW5jcnlwdGVk LikuIE1heWJlIGNvbmZ1c2VzIHRoZSBmaWVsZCBuYW1lICdDaGlwZXJ0ZXh0Jw0KIHRvby48YnI+ DQo8YnI+DQo8YnI+DQonUGFkZGluZzonJm5ic3A7IFRoaXMgbGluZTogWy4uLl0gc28gdGhhdCBp bXBsZW1lbnRhdGlvbnMgY2FuIHVuYW1iaWd1b3VzbHkgZGVsaW1pdCB0aGUgZW5kIG9mIHRoZSBj aXBoZXJ0ZXh0IGZyb20gdGhlIHN0YXJ0IG9mIHRoZSBwYWRkaW5nIFsuLi5dIGNhbiBiZSBkaWZm aWN1bHQgdG8uIEluIHRoZSBiZWdpbm5pbmcgSSBkaWQgbm90IGtub3cgaG93IHRoaXMgc2hvdWxk IHdvcmsuIFdlIHNob3VsZCBzYXkgdGhhdCBpbXBsZW1lbnRhdGlvbnMgY2FuIHJlYWQNCiB0aGUg bGFzdCBvY3RldCBvZiB0aGlzIGV4dGVuc2lvbiBjb250ZW50LCB0byBmaW5kIG91dCBob3cgYmln IHRoZSBwYWRkaW5nIGlzLjxicj4NCjxicj4NCkZ1cnRoZXJtb3JlIHdlIHNob3VsZCBjaGFuZ2Ug dGhpcyBsaW5lOjxicj4NClsuLi5dIHJlcXVpcmVtZW50IHRoYXQgKGluIHRoZSBhYnNlbmNlIG9m IGEgbGVnYWN5IE1BQykgZXh0ZW5zaW9ucyBoYXZlIGEgdG90YWwgbGVuZ3RoIGluIG9jdGV0cyAo aW5jbHVkaW5nIHRoZSBmb3VyIG9jdGV0cyBmb3IgdGhlIHR5cGUgYW5kIGxlbmd0aCBmaWVsZHMp Jm5ic3A7IFsuLi5dPGJyPg0KPGJyPg0KaW4gdGhpczo8YnI+DQpbLi4uXSByZXF1aXJlbWVudCB0 aGF0IChpbiB0aGUgYWJzZW5jZSBvZiBhIGxlZ2FjeSBNQUMpIDxiPk5UUDwvYj4gZXh0ZW5zaW9u cyBoYXZlIGEgdG90YWwgbGVuZ3RoIGluIG9jdGV0cyAoaW5jbHVkaW5nIHRoZSBmb3VyIG9jdGV0 cyBmb3IgdGhlIHR5cGUgYW5kIGxlbmd0aCBmaWVsZHMpIFsuLi5dPGJyPg0KPGJyPg0KPGJyPg0K LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQo8YnI+DQpbLi4uXSBQOiBUaGUg cGxhaW50ZXh0IFNIQUxMIGNvbnNpc3Qgb2YgYWxsIChpZiBhbnkpIGV4dGVuc2lvbnMgdG8gYmUg ZW5jcnlwdGVkLiBbLi4uXQ0KPGJyPg0KPGJyPg0KV2hpY2ggZm9ybWF0PyBUeXBpY2FsIE5UUHY0 IEV4dGVuc2lvbiBGaWVsZHMgb3IgYW5vdGhlciBmb3JtYXQ/IFdlIHNob3VsZCBkZWZpbmUgdGhh dC4gV2Ugc2hvdWxkIGFsc28gbWVudGlvbiB0aGF0IG9ubHkgdGhpcyBjb250ZW50IGlzIGVuY3J5 cHRlZCAobm90IHRoZSBjb250ZW50IG9mIHBhcmFtZXRlciAnQScpLg0KPGJyPg0KSWYgd2UgZG9u J3Qgd2FudCBlbmNyeXB0IGFueXRoaW5nIChkZWZhdWx0IGNhc2UpLCB0aGVuIHRoaXMgcGFyYW1l dGVyIGlzIGVtcHR5Ljxicj4NCjxicj4NCjxicj4NCj09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTxicj4NCjxicj4NClBsZWFzZSBsZXQg bWUga25vdyBpZiB5b3UgaGF2ZSBwcm9ibGVtcyB0byB1bmRlcnN0YW5kIG15ICplbmdsaXNoKi48 YnI+DQo8YnI+DQo8YnI+DQo8L3NwYW4+QmVzdCByZWdhcmRzLDxicj4NCk1hcnRpbjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_DB3PR05MB1725F35D5353CF4038E7E37B39F0DB3PR05MB172eurprd_-- --_004_DB3PR05MB1725F35D5353CF4038E7E37B39F0DB3PR05MB172eurprd_ Content-Type: text/plain; name="ATT00001.txt" Content-Description: ATT00001.txt Content-Disposition: attachment; filename="ATT00001.txt"; size=124; creation-date="Fri, 11 Aug 2017 09:35:09 GMT"; modification-date="Fri, 11 Aug 2017 09:35:09 GMT" Content-ID: <0535E245A8D2DE45B3709FA9FC562C3C@eurprd05.prod.outlook.com> Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm50cCBtYWls aW5nIGxpc3QNCm50cEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9udHANCg== --_004_DB3PR05MB1725F35D5353CF4038E7E37B39F0DB3PR05MB172eurprd_-- From ntp-bounces@ietf.org Tue Aug 29 01:55:21 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 32E19132D55; Tue, 29 Aug 2017 01:55:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1503996921; bh=ymAxi2QTx2zIEt9DnPfOyAO2aWzUASaNX5A2NKSuj8E=; h=From:To:Date:References:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe; b=Ww3GLPMrhJTDb+oqWEypXtM6OInsXkX5jt3DgNPtc7zCl8OEpDqUCk3tQfDytRjUK S2H+c1jk1nxj+cqJUK9jZFn822vImnUrdX1i48/HKgMeJmebx2Rt3ZCqdib2BavFMn WAHv0gmAveL4vOX2VpYAQO9vyGpecfYp8zX6jDf8= 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 8C97A132D58 for ; Tue, 29 Aug 2017 01:55:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.018 X-Spam-Level: X-Spam-Status: No, score=-2.018 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ptbde.onmicrosoft.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 vfN03ON6N2n2 for ; Tue, 29 Aug 2017 01:55:16 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0125.outbound.protection.outlook.com [104.47.1.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F48E132D55 for ; Tue, 29 Aug 2017 01:55:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ptbde.onmicrosoft.com; s=selector1-ptbde-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=S2pejN9wGvPgcKiz5LX0ZrbHjYtTEaQ6TNKb6A7TH+0=; b=oFWxJUIvbzAErrdJeYCD4TOJ5+CI3OY1SkSajkTp/YPuM8XIL1mPskPp+TaUo2qhXRy6AS0VoK95F17VcMeGAA/SAOez0UUplP1JMi3P8NFAFGXNr7YA7O2UI+qDcMYUVQmiQ62K1CMIfRz8bhq4q6g2dNwGAgiZpXFUuWuwOk4= Received: from DB3PR05MB172.eurprd05.prod.outlook.com (10.242.132.18) by DB3PR05MB108.eurprd05.prod.outlook.com (10.255.251.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1385.9; Tue, 29 Aug 2017 08:55:11 +0000 Received: from DB3PR05MB172.eurprd05.prod.outlook.com ([fe80::cf:70d1:53e0:1a6a]) by DB3PR05MB172.eurprd05.prod.outlook.com ([fe80::cf:70d1:53e0:1a6a%17]) with mapi id 15.01.1385.013; Tue, 29 Aug 2017 08:55:11 +0000 From: Dieter Sibold To: "ntp@ietf.org" Thread-Topic: [Ntp] some comments on the NTS4NTP-Draft09 Thread-Index: AQHTEoUfXL53iq6idEaRaWneOGte1aKbIerw Date: Tue, 29 Aug 2017 08:55:10 +0000 Message-ID: References: <70a0c971b2978.598d965e@ostfalia.de> In-Reply-To: <70a0c971b2978.598d965e@ostfalia.de> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=dieter.sibold@ptbde.onmicrosoft.com; x-originating-ip: [192.53.103.119] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB3PR05MB108; 6:VzhdHTp+P8/1UsXHzy0TYZ4kbh8ovP16xUjWw8d6W8zbuYIu4joF/M/nDYfIjIhMxwxwN7k51wYsfbk2dos6c0WpJGz5rye33LnN6DwCQilxpRxL9Th0W4Ecpdk93vunXdzkizENLSEWAwpEfWJOS6jOPodzRVO520j5ygVbbiNYwRkqcxolXEAb0TWdlBpQmXOK/Hog6fZoLVEgNlxsZVyIFByyioSKV4M2pk9MHdHM7DNDv5E/8vtGGrF/xOR2u+U7i21Jki7P9IYMUIwg2Ol02jdw0x8bWzbWpyj83hjZsEUx9N2YMHKli1dVcatX5T4mMAgj+fsuQB2O3MyOZQ==; 5:M89ZaUvsURJlsLd96cj+0BeothudFts024njkXSV5P6lkc7/h8bcXNQ3j9mOjLF+sg3qekS//GS7mzRUFYqatgO0imwAiQI5Fe1Y3xxowbIgq6svAsCI6epgovQWL5XKWO1Q1zFFdyRcBUvQZ2zZAA==; 24:gftIIyg2mAVCwaCRX1uB4aMMRcRQFWwtlUwdrfFOTStBb02FkhhIJaZe52yVVskdNPLABZhw6HVe7izdI6+js0tL6+vPL4QzwKqOMbMyBM4=; 7:l6wwMRvRPawIk8FzIHHS27hTCm3w3tUuZ6ibeDNoSVJA/LSxVvUPi393V83o9RweOlcUtTmcxwqEbc6cozd+pp/6VVmsly8XaB+DBtrUXs8jkfnrds7V2pRFJRqeBiE4Dz3/Yvu22vwOUTh9McxtF7HiWeuxbHzkO8skngp6veHB+aEXKhqNfu3NXkdFm02gLiNxGHNshU+NRcDERUwQiqy/xDt/GXaD3Yoix1embNU= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 172bfda8-8f1a-455a-6f78-08d4eebba820 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(2017082002075)(300000503095)(300135400095)(2017052603199)(49563074)(201703131423075)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DB3PR05MB108; x-ms-traffictypediagnostic: DB3PR05MB108: x-exchange-antispam-report-test: UriScan:(158342451672863)(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(102415395)(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(6041248)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(201703131423075)(201703061421075)(2016111802025)(20161123558100)(6072148)(6043046)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DB3PR05MB108; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DB3PR05MB108; x-forefront-prvs: 0414DF926F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(76094002)(189002)(53754006)(377454003)(2950100002)(6916009)(2351001)(5660300001)(6436002)(14454004)(2900100001)(33656002)(64872007)(53546010)(189998001)(42882006)(2906002)(86902001)(229853002)(54356999)(3660700001)(99286003)(50986999)(508600001)(6506006)(76176999)(55016002)(110136004)(6456002)(3280700002)(5640700003)(561944003)(5250100002)(101416001)(97736004)(74316002)(99936001)(2473003)(790700001)(6116002)(102836003)(106356001)(54896002)(3846002)(9686003)(53936002)(6306002)(25786009)(8676002)(7696004)(5630700001)(81156014)(1730700003)(81166006)(86442002)(66066001)(2501003)(8936002)(105586002)(7736002)(68736007)(86362001)(32563001)(19627235001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR05MB108; H:DB3PR05MB172.eurprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; received-spf: None (protection.outlook.com: ptbde.onmicrosoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/mixed; boundary="_004_DB3PR05MB1725F35D5353CF4038E7E37B39F0DB3PR05MB172eurprd_" MIME-Version: 1.0 X-OriginatorOrg: ptbde.onmicrosoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Aug 2017 08:55:11.0203 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 463cf4b2-037b-4a7c-a75c-ae2c1aef241a X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR05MB108 Archived-At: Subject: [Ntp] FW: some comments on the NTS4NTP-Draft09 X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ntp-bounces@ietf.org Sender: "ntp" --_004_DB3PR05MB1725F35D5353CF4038E7E37B39F0DB3PR05MB172eurprd_ Content-Type: multipart/alternative; boundary="_000_DB3PR05MB1725F35D5353CF4038E7E37B39F0DB3PR05MB172eurprd_" --_000_DB3PR05MB1725F35D5353CF4038E7E37B39F0DB3PR05MB172eurprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB3YW50IGRyYXcgYXR0ZW50aW9uIHRvIE1hcnRpbiBMYW5nZXLigJlzIHRlY2huaWNhbCBxdWVz dGlvbiBvbiBkcmFmdC1pZXRmLW50cC11c2luZy1udHMtZm9yLW50cCwgd2hpY2ggaGUgc2VudCBh dCAxMXRoIEF1Z3VzdC4NCg0KRnJvbTogbnRwIFttYWlsdG86bnRwLWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZiBPZiBNYXJ0aW4gTGFuZ2VyDQpTZW50OiBGcmlkYXksIEF1Z3VzdCAxMSwgMjAx NyAxMTozNSBBTQ0KVG86IG50cEBpZXRmLm9yZw0KU3ViamVjdDogW050cF0gc29tZSBjb21tZW50 cyBvbiB0aGUgTlRTNE5UUC1EcmFmdDA5DQoNCkhpIGFsbCwNCg0KQXQgZmlyc3QsIEkgd2FudGVk IHRvIHRlbGwgeW91IGJyaWVmbHkgdGhhdCB0aGUgbmV3IE5UUyBpbXBsZW1lbnRhdGlvbiB3aWxs IHN0YXJ0IG5leHQgd2Vlay4gSSBoYXZlIHNvbWUgcG9pbnRzL2NvbW1lbnRzIG9uIHRoZSBOVFM0 TlRQLURyYWZ0MDkgdGhhdCBJIHdhbnRlZCB0byBtZW50aW9uIGluIHRoaXMgd2F5LiBUaGVyZWZv cmUsIHRoZSBjb250ZW50IGlzIHByaW1hcmlseSBkaXJlY3RlZCBhdCBEYW5pZWwgRnJhbmtlLg0K SW4gYWR2YW5jZSwgSSdtIGluIEphcGFuIGZvciB0aGUgbmV4dCAzIHdlZWtzIGFuZCB3aWxsIHBy b2JhYmx5IG5vdCBiZSBhYmxlIHRvIHJlc3BvbmQgdG8gY29tbWVudHMgb3IgZW1haWxzLiBJIGFz ayBmb3IgdW5kZXJzdGFuZGluZy4NCg0KDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCk5UUzRO VFAtRHJhZnQwOQ0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQoNCg0KMS4gY29uZnVzaW5nIHRl cm0gIm50cC80Ig0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09DQoNCnBhZ2UgMTAgKGNoYXB0ZXIgNS4xLjUsIDJuZCBzZWN0aW9uKToN Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpbLi4uXSBJZiB0aGUg TlRTIE5leHQgUHJvdG9jb2wgTmVnb3RpYXRpb24gcmVjb3JkIG9mZmVycyAibnRwLzQiLHRoaXMg cmVjb3JkIE1VU1QgYmUgaW5jbHVkZWQgZXhhY3RseSBvbmNlLiBbLi4uXQ0KDQoNCnBhZ2UgMTEg KGNoYXB0ZXIgNS4xLjUsIDR0aCBzZWN0aW9uKToNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQpbLi4uXSBhbmQgdGhlIHNlcnZlciBhY2NlcHRzIHRoZSAibnRwLzQi IHByb3RvY29sIGluIGl0cyBOVFMgTmV4dCBQcm90b2NvbCBOZWdvdGlhdGlvbiByZWNvcmQgWy4u Ll0NCg0KDQpwYWdlIDExIChjaGFwdGVyIDYuMSwgMXN0IHNlY3Rpb24pOg0KLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClsuLi5dIEZvbGxvd2luZyBhIHN1Y2Nlc3Nm dWwgcnVuIG9mIHRoZSBOVFMtS0UgcHJvdG9jb2wgd2hlcmVpbiAibnRwLzQiIGlzIHNlbGVjdGVk IGFzIGEgTmV4dCBQcm90b2NvbCBbLi4uXQ0KDQoNCnJlbWFyazoNCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoibnRwLzQiIGlzIHRoZSBzYW1lIHRlcm0gYXMgaW4g dGhlIFRMUyBBTFBOIGV4dGVuc2lvbiAoc2VlOiBwYWdlIDE4LCBjaGFwdGVyIDgpOg0KDQpbLi4u XSBJQU5BIGlzIHJlcXVlc3RlZCB0byBhbGxvY2F0ZSB0aGUgZm9sbG93aW5nIHR3byBlbnRyaWVz IGluIHRoZSBBcHBsaWNhdGlvbi1MYXllciBQcm90b2NvbCBOZWdvdGF0aW9uIChBTFBOKSBQcm90 b2NvbCBJRHMgcmVnaXN0cnk6IFsuLi5dIFByb3RvY29sOiBOZXR3b3JrIFRpbWUgUHJvdG9jb2ws IHZlcnNpb24gNCAgIElkZW50aWZpY2F0aW9uIFNlcXVlbmNlOiAweDZFIDB4NzQgMHg3MCAweDJG IDB4MzQgKCJudHAvNCIpIFsuLi5dDQoNCkJ1dCB0aGUgTlRTIE5leHQgUHJvdG9jb2wgTmVnb3Rp YXRpb24gcmVjb3JkIGNvbnRhaW5zIElEcyAoZS5nLiAweDAwIGZvciAnTmV0d29yayBUaW1lIFBy b3RvY29sIHZlcnNpb24gNCc7IHNlZSB0YWJsZSBhdCBwYWdlIDIxKSBhbmQgbm90IHRoZSB0ZXJt ICdudHAvNCcuIFRoaXMgY2FuIGNvbmZ1c2luZyBzb21lIHJlYWRlcnMuDQoNCg0KDQoNCg0KMi4g TmV0d29yayBCeXRlIE9yZGVyIC8gSG9zdCBCeXRlIE9yZGVyDQo9PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCg0KcGFnZSA4IChjaGFw dGVyIDUsIDV0aCBzZWN0aW9uKToNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQpbLi4uXSBSZWNvcmQgVHlwZTogQSAxNS1iaXQgaW50ZWdlciBpbiBuZXR3b3JrIGJ5 dGUgb3JkZXIgKGZyb20gbW9zdC10by1sZWFzdCBzaWduaWZpY2FudCwgaXRzIGJpdHMgYXJlIHJl Y29yZCBiaXRzIDctMSBhbmQgdGhlbiAxNS04KS4gWy4uLl0NCg0KDQpyZW1hcms6DQotLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KV2h5IDctMSBhbmQgdGhlbiAxNS04 PyBBcmUgd2UgdXNlIHRoZSBMaXR0bGUgRW5kaWFuIGZvcm1hdCBmb3IgdGhlICdSZWNvcmQgVHlw ZScgb25seSBvciBmb3IgdGhlIHdob2xlIHJlY29yZD8gV2h5IHdlIGRvbid0IHVzZSBCaWcgRW5k aWFuPw0KDQoNCg0KDQoNCg0KMy4gZ2VuZXJhbCBjb21tZW50DQo9PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCg0KcGFnZSAxMiAoY2hh cHRlciA2LjEsIDJuZCBzZWN0aW9uKToNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQpbLi4uXSBUaGUgcGVyLWFzc29jaWF0aW9uIGNvbnRleHQgdmFsdWUgU0hBTEwg Y29uc2lzdCBvZiB0aGUgZm9sbG93aW5nIGZpdmUgb2N0ZXRzOiBUaGUgZmlyc3QgdHdvIG9jdGV0 cyBTSEFMTCBiZSB6ZXJvLlsuLi5dDQoNCg0KcmVtYXJrOg0KLS0tLS0tLS0tLS0NCk15IGZpcnN0 IHRob3VnaHQgd2FzOiB3aHk/IEF0IGZpcnN0IGl0IHdhcyBhIG1hZ2ljIG51bWJlciBmb3IgbWUu IFRoZSBzb2x1dGlvbiBpcyBoZXJlOiBjaGFwdGVyIDUuMjoNClsuLi5dIGFuZCBNVVNUIGJlZ2lu IHdpdGggdGhlIHR3by1vY3RldCBQcm90b2NvbCBJRCB3aGljaCB3YXMgbmVnb3RpYXRlZCBhcyBh IE5leHQgUHJvdG9jb2wuIFsuLi5dDQoNCkkgdGhpbmsgdGhpcyBzaG91bGQgYmUgbWVudGlvbmVk IGFnYWluIG9yIHJlZmVyZW5jZWQgdG8gdGhlIGNvcnJlc3BvbmRpbmcgdGFibGUgKGNoYXB0ZXIg OCkuDQoNCg0KDQoNCg0KNC4gZ2VuZXJhbCBjb21tZW50DQo9PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCg0KcGFnZSAxMyAoY2hhcHRl ciA2LjUsIDJuZCBzZWN0aW9uKToNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQpbLi4uXSBUaGlzIGxlbmd0aCByZXF1aXJlbWVudCBzZXJ2ZXMgdG8gZW5zdXJlIHRo YXQgdGhlIHJlc3BvbnNlIHdpbGwgbm90IGJlIGxhcmdlciB0aGFuIHRoZSByZXF1ZXN0LCBpbiBv cmRlciB0byBpbXByb3ZlIHRpbWVrZWVwaW5nIHByZWNpc2lvbiBhbmQgWy4uLl0NCg0KDQpyZW1h cms6DQotLS0tLS0tLS0tLQ0KRG9lcyBpdCByZWFsbHkgaW1wcm92ZSB0aGUgdGltZWtlZXBpbmc/ IEkgdGhpbmsgdGhlIGlkZWEgaXMgdG8gcmVkdWNlIHRoZSBhc3ltbWV0cnkgaWYgdGhlIHJlcXVl c3QgYW5kIHJlc3BvbnNlIG1lc3NhZ2UgaGF2ZSB0aGUgc2FtZSBzaXplLg0KQnV0IGNsaWVudCBh bmQgc2VydmVyIG1heSBoYXZlIGRpZmZlcmVudCBwZXJmb3JtYW5jZSBhbmQgdGhlcmVmb3JlIHRo ZSBwcm9jZXNzaW5nIHNwZWVkIHBlciBOVFAgUGFja2FnZSBpcyBkaWZmZXJlbnQgdG9vLiAgLi4u aXQncyBqdXN0IGEgdGhvdWdodA0KDQoNCg0KDQoNCjUuIGFsdGVybmF0aXZlIHByb3Bvc2FsDQo9 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT0NCg0KcGFnZSAyMCAoY2hhcHRlciA4LCAxc3Qgc2VjdGlvbik6DQotLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWy4uLl0gVHlwZSBOdW1iZXIgKFJFUVVJUkVEKTog QW4gaW50ZWdlciBpbiB0aGUgcmFuZ2UgMC0zMjc2NyBpbmNsdXNpdmUgWy4uLl0NCg0KDQpiZXR0 ZXI/Og0KLS0tLS0tLS0tLS0NClsuLi5dIFR5cGUgTnVtYmVyIChSRVFVSVJFRCk6IEFuIDE1IGJp dCBpbnRlZ2VyIGluIHRoZSByYW5nZSAwLTMyNzY3IGluY2x1c2l2ZSBbLi4uXQ0KDQouLi4ubm90 IDE2IGJpdCwgYmVjYXVzZSB3ZSB1c2UgYSBjcml0aWNhbCBiaXQgaW4gb3VyIHJlY29yZHMgKGZp cnN0IGJpdCkNCg0KDQoNCg0KDQoNCjYuIHNvbWUgcHJvYmxlbXMgd2l0aCAnVGhlIE5UUyBBdXRo ZW50aWNhdG9yIGFuZCBFbmNyeXB0ZWQgRXh0ZW5zaW9ucyBleHRlbnNpb24nIChwYWdlIDE0LCBj aGFwdGVyIDYuNikNCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PQ0KDQpmaWVsZCBkZXNjcmlwdGlvbjoNCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQonTm9uY2UgbGVuZ2h0JzogV2Ugc2hvdWxkIG1lbnRp b24gdGhhdCB0aGUgdmFsdWUgaXMgdG8gYmUgaW50ZXJwcmV0ZWQgYXMgJ3Vuc2lnbmVkIGludCcu DQoNCidOb25jZSc6IEF0IGZpcnN0IEkgaGFkIHNvbWUgdHJvdWJsZSB0byB1bmRlcnN0YW5kIHdo ZXJlIHRoZSBub25jZSBjb21lcyBmcm9tIGFuZCB3aGljaCBsZW5ndGggd2UgdXNlLiBOb3cgSSBr bm93IGl0LCBidXQgbWF5YmUgd2Ugc2hvdWxkIGFkZCBzb21lIG1vcmUgaW5mb3JtYXRpb24gdG8g dGhpcyBmaWVsZC4NCnBlcmhhcHMgZnJvbSB0aGVzZTogICBbLi4uXSBOb25jZTogYSBub25jZSBh cyByZXF1aXJlZCBieSB0aGUgbmVnb3RpYXRlZCBBRUFEIEFsZ29yaXRobS4gWy4uLl0gICB0byB0 aGVzZTogICBbLi4uXSBOb25jZTogYSBuZXcgZ2VuZXJhdGVkIG5vbmNlIHdob3NlIGxlbmd0aCBh bmQgZm9ybWF0IGlzIGRldGVybWluZWQgYnkgdGhlIG5lZ290aWF0ZWQgQUVBRCBhbGdvcml0aG0g KFJGQyA1MTE2LCBjaGFwdGVyIDMuMikuIFsuLi5dDQoNCg0KJ0NoaXBlcnRleHQnOiBTb21lIHJl YWRlcnMgKHN0dWRlbnRzIGluIG15IHRlYW0pIGhhZCBkaWZmaWN1bHRpZXMgdG8gdW5kZXJzdGFu ZCB0aGlzIGZpZWxkLiBBbGwgb2YgdGhlbSB0aG91Z2h0LCB0aGF0IHRoaXMgZmllbGQgY29udGFp bnMgYW4gZW5jcnlwdGVkIHZlcnNpb24gb2YgdGhlIHdob2xlIE5UUCBwYWNrYWdlLiBBbmQgdGhp cyBpcyB3cm9uZy4gSSB0aGluayB0aGUgcHJvYmxlbSBpcyB0aGlzIGxpbmU6IFsuLi5dIGF1dGhl bnRpY2F0aW9uIHRhZyBpbiBhZGRpdGlvbiB0byB0aGUgYWN0dWFsIGNpcGhlcnRleHQuIFsuLi5d LiBXZWxsLCBpZiByZWFkZXJzIGRvIG5vdCBrbm93IGV4YWN0bHkgaG93IEFFQUQgd29ya3MsIHRo ZW4gdGhpcyBsZWFkcyB0byBzdHJvbmcgdW5kZXJzdGFuZGluZyBwcm9ibGVtcyBhdCB0aGlzIHBv aW50LCBzaW5jZSB0aGUgdGVybXMgJ2F1dGhlbnRpY2F0aW9uIHRhZycgYW5kICdjaXBoZXJ0ZXh0 JyBzZWVtIG5vdCBrbm93bi4gSSB0aGluayB3ZSBzaG91bGQgYWRkIGEgcmVmZXJlbmNlIChSRkMg NTExNiAtLT4gQUVBRCkgb3Igc29tZSBpbmZvcm1hdGlvbiBhYm91dCB0aGlzIHRlcm1zICgnYXV0 aGVudGljYXRpb24gdGFnJyBpcyBsaWtlIGEgTUFDIGFuZCAnY2lwaGVydGV4dCcgY29udGFpbnMg b3B0aW9uYWwgRXh0ZW5zaW9uIEZpZWxkcyBhbmQgY2FuIGJlIGFic2VudCBpZiBubyBFeHRlbnNp b24gRmllbGRzIGFyZSBlbmNyeXB0ZWQuKS4gTWF5YmUgY29uZnVzZXMgdGhlIGZpZWxkIG5hbWUg J0NoaXBlcnRleHQnIHRvby4NCg0KDQonUGFkZGluZzonICBUaGlzIGxpbmU6IFsuLi5dIHNvIHRo YXQgaW1wbGVtZW50YXRpb25zIGNhbiB1bmFtYmlndW91c2x5IGRlbGltaXQgdGhlIGVuZCBvZiB0 aGUgY2lwaGVydGV4dCBmcm9tIHRoZSBzdGFydCBvZiB0aGUgcGFkZGluZyBbLi4uXSBjYW4gYmUg ZGlmZmljdWx0IHRvLiBJbiB0aGUgYmVnaW5uaW5nIEkgZGlkIG5vdCBrbm93IGhvdyB0aGlzIHNo b3VsZCB3b3JrLiBXZSBzaG91bGQgc2F5IHRoYXQgaW1wbGVtZW50YXRpb25zIGNhbiByZWFkIHRo ZSBsYXN0IG9jdGV0IG9mIHRoaXMgZXh0ZW5zaW9uIGNvbnRlbnQsIHRvIGZpbmQgb3V0IGhvdyBi aWcgdGhlIHBhZGRpbmcgaXMuDQoNCkZ1cnRoZXJtb3JlIHdlIHNob3VsZCBjaGFuZ2UgdGhpcyBs aW5lOg0KWy4uLl0gcmVxdWlyZW1lbnQgdGhhdCAoaW4gdGhlIGFic2VuY2Ugb2YgYSBsZWdhY3kg TUFDKSBleHRlbnNpb25zIGhhdmUgYSB0b3RhbCBsZW5ndGggaW4gb2N0ZXRzIChpbmNsdWRpbmcg dGhlIGZvdXIgb2N0ZXRzIGZvciB0aGUgdHlwZSBhbmQgbGVuZ3RoIGZpZWxkcykgIFsuLi5dDQoN CmluIHRoaXM6DQpbLi4uXSByZXF1aXJlbWVudCB0aGF0IChpbiB0aGUgYWJzZW5jZSBvZiBhIGxl Z2FjeSBNQUMpIE5UUCBleHRlbnNpb25zIGhhdmUgYSB0b3RhbCBsZW5ndGggaW4gb2N0ZXRzIChp bmNsdWRpbmcgdGhlIGZvdXIgb2N0ZXRzIGZvciB0aGUgdHlwZSBhbmQgbGVuZ3RoIGZpZWxkcykg Wy4uLl0NCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpbLi4uXSBQOiBU aGUgcGxhaW50ZXh0IFNIQUxMIGNvbnNpc3Qgb2YgYWxsIChpZiBhbnkpIGV4dGVuc2lvbnMgdG8g YmUgZW5jcnlwdGVkLiBbLi4uXQ0KDQpXaGljaCBmb3JtYXQ/IFR5cGljYWwgTlRQdjQgRXh0ZW5z aW9uIEZpZWxkcyBvciBhbm90aGVyIGZvcm1hdD8gV2Ugc2hvdWxkIGRlZmluZSB0aGF0LiBXZSBz aG91bGQgYWxzbyBtZW50aW9uIHRoYXQgb25seSB0aGlzIGNvbnRlbnQgaXMgZW5jcnlwdGVkIChu b3QgdGhlIGNvbnRlbnQgb2YgcGFyYW1ldGVyICdBJykuDQpJZiB3ZSBkb24ndCB3YW50IGVuY3J5 cHQgYW55dGhpbmcgKGRlZmF1bHQgY2FzZSksIHRoZW4gdGhpcyBwYXJhbWV0ZXIgaXMgZW1wdHku DQoNCg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09DQoNClBsZWFzZSBsZXQgbWUga25vdyBpZiB5b3UgaGF2ZSBwcm9ibGVtcyB0byB1 bmRlcnN0YW5kIG15ICplbmdsaXNoKi4NCg0KDQpCZXN0IHJlZ2FyZHMsDQpNYXJ0aW4NCg== --_000_DB3PR05MB1725F35D5353CF4038E7E37B39F0DB3PR05MB172eurprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBz cGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBs aS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7 DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEyLjBw dDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLkUtTWFpbEZv cm1hdHZvcmxhZ2UxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBE ZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJbXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0K CW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgMi4wY20gNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24x DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94 bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2 OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFw ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkRFIiBsaW5r PSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjttc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+SSB3YW50IGRyYXcgYXR0ZW50aW9uIHRvIE1hcnRpbiBMYW5n ZXLigJlzIHRlY2huaWNhbCBxdWVzdGlvbiBvbiBkcmFmdC1pZXRmLW50cC11c2luZy1udHMtZm9y LW50cCwgd2hpY2ggaGUgc2VudCBhdCAxMTxzdXA+dGg8L3N1cD4gQXVndXN0LjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9z ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9hPjwvcD4NCjxzcGFuIHN0eWxlPSJtc28tYm9v a21hcms6X01haWxFbmRDb21wb3NlIj48L3NwYW4+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+IG50cCBbbWFpbHRvOm50cC1ib3VuY2VzQGlldGYub3JnXQ0KPGI+ T24gQmVoYWxmIE9mIDwvYj5NYXJ0aW4gTGFuZ2VyPGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwg QXVndXN0IDExLCAyMDE3IDExOjM1IEFNPGJyPg0KPGI+VG86PC9iPiBudHBAaWV0Zi5vcmc8YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gW050cF0gc29tZSBjb21tZW50cyBvbiB0aGUgTlRTNE5UUC1EcmFm dDA5PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPkhpIGFs bCw8YnI+DQo8YnI+DQpBdCBmaXJzdCwgSSB3YW50ZWQgdG8gdGVsbCB5b3UgYnJpZWZseSB0aGF0 IHRoZSBuZXcgTlRTIGltcGxlbWVudGF0aW9uIHdpbGwgc3RhcnQgbmV4dCB3ZWVrLiBJIGhhdmUg c29tZSBwb2ludHMvY29tbWVudHMgb24gdGhlIE5UUzROVFAtRHJhZnQwOSB0aGF0IEkgd2FudGVk IHRvIG1lbnRpb24gaW4gdGhpcyB3YXkuIFRoZXJlZm9yZSwgdGhlIGNvbnRlbnQgaXMgcHJpbWFy aWx5IGRpcmVjdGVkIGF0IERhbmllbCBGcmFua2UuPGJyPg0KSW4gYWR2YW5jZSwgSSdtIGluIEph cGFuIGZvciB0aGUgbmV4dCAzIHdlZWtzIGFuZCB3aWxsIHByb2JhYmx5IG5vdCBiZSBhYmxlIHRv IHJlc3BvbmQgdG8gY29tbWVudHMgb3IgZW1haWxzLiBJIGFzayBmb3IgdW5kZXJzdGFuZGluZy48 YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPj09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTxi cj4NCk5UUzROVFAtRHJhZnQwOTxicj4NCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTxicj4NCjxi cj4NCjxicj4NCjEuIGNvbmZ1c2luZyB0ZXJtICZxdW90O250cC80JnF1b3Q7PGJyPg0KPT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PGJy Pg0KPGJyPg0KcGFnZSAxMCAoY2hhcHRlciA1LjEuNSwgMm5kIHNlY3Rpb24pOjxicj4NCi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KWy4uLl0gSWYgdGhlIE5U UyBOZXh0IFByb3RvY29sIE5lZ290aWF0aW9uIHJlY29yZCBvZmZlcnMgJnF1b3Q7bnRwLzQmcXVv dDssdGhpcyByZWNvcmQgTVVTVCBiZSBpbmNsdWRlZCBleGFjdGx5IG9uY2UuIFsuLi5dPGJyPg0K PGJyPg0KPGJyPg0KcGFnZSAxMSAoY2hhcHRlciA1LjEuNSwgNHRoIHNlY3Rpb24pOjxicj4NCi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KWy4uLl0gYW5kIHRo ZSBzZXJ2ZXIgYWNjZXB0cyB0aGUgJnF1b3Q7bnRwLzQmcXVvdDsgcHJvdG9jb2wgaW4gaXRzIE5U UyBOZXh0IFByb3RvY29sIE5lZ290aWF0aW9uIHJlY29yZCBbLi4uXTxicj4NCjxicj4NCjxicj4N CnBhZ2UgMTEgKGNoYXB0ZXIgNi4xLCAxc3Qgc2VjdGlvbik6PGJyPg0KLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQpbLi4uXSBGb2xsb3dpbmcgYSBzdWNjZXNz ZnVsIHJ1biBvZiB0aGUgTlRTLUtFIHByb3RvY29sIHdoZXJlaW4gJnF1b3Q7bnRwLzQmcXVvdDsg aXMgc2VsZWN0ZWQgYXMgYSBOZXh0IFByb3RvY29sIFsuLi5dPGJyPg0KPGJyPg0KPGJyPg0KcmVt YXJrOjxicj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0K JnF1b3Q7bnRwLzQmcXVvdDsgaXMgdGhlIHNhbWUgdGVybSBhcyBpbiB0aGUgVExTIEFMUE4gZXh0 ZW5zaW9uIChzZWU6IHBhZ2UgMTgsIGNoYXB0ZXIgOCk6PGJyPg0KPGJyPg0KWy4uLl0gSUFOQSBp cyByZXF1ZXN0ZWQgdG8gYWxsb2NhdGUgdGhlIGZvbGxvd2luZyB0d28gZW50cmllcyBpbiB0aGUg QXBwbGljYXRpb24tTGF5ZXIgUHJvdG9jb2wgTmVnb3RhdGlvbiAoQUxQTikgUHJvdG9jb2wgSURz IHJlZ2lzdHJ5OiBbLi4uXSBQcm90b2NvbDogTmV0d29yayBUaW1lIFByb3RvY29sLCB2ZXJzaW9u IDQmbmJzcDsmbmJzcDsgSWRlbnRpZmljYXRpb24gU2VxdWVuY2U6IDB4NkUgMHg3NCAweDcwIDB4 MkYgMHgzNCAoJnF1b3Q7bnRwLzQmcXVvdDspIFsuLi5dPGJyPg0KPGJyPg0KQnV0IHRoZSBOVFMg TmV4dCBQcm90b2NvbCBOZWdvdGlhdGlvbiByZWNvcmQgY29udGFpbnMgSURzIChlLmcuIDB4MDAg Zm9yICdOZXR3b3JrIFRpbWUgUHJvdG9jb2wgdmVyc2lvbiA0Jzsgc2VlIHRhYmxlIGF0IHBhZ2Ug MjEpIGFuZCBub3QgdGhlIHRlcm0gJ250cC80Jy4gVGhpcyBjYW4gY29uZnVzaW5nIHNvbWUgcmVh ZGVycy48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQoyLiBOZXR3b3JrIEJ5dGUg T3JkZXIgLyBIb3N0IEJ5dGUgT3JkZXI8YnI+DQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08YnI+DQo8YnI+DQpwYWdlIDggKGNoYXB0 ZXIgNSwgNXRoIHNlY3Rpb24pOjxicj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tPGJyPg0KWy4uLl0gUmVjb3JkIFR5cGU6IEEgMTUtYml0IGludGVnZXIgaW4gbmV0 d29yayBieXRlIG9yZGVyIChmcm9tIG1vc3QtdG8tbGVhc3Qgc2lnbmlmaWNhbnQsIGl0cyBiaXRz IGFyZSByZWNvcmQgYml0cyA3LTEgYW5kIHRoZW4gMTUtOCkuIFsuLi5dPGJyPg0KPGJyPg0KPGJy Pg0KcmVtYXJrOjxicj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t IDxicj4NCldoeSA3LTEgYW5kIHRoZW4gMTUtOD8gQXJlIHdlIHVzZSB0aGUgTGl0dGxlIEVuZGlh biBmb3JtYXQgZm9yIHRoZSAnUmVjb3JkIFR5cGUnIG9ubHkgb3IgZm9yIHRoZSB3aG9sZSByZWNv cmQ/IFdoeSB3ZSBkb24ndCB1c2UgQmlnIEVuZGlhbj88YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8 YnI+DQo8YnI+DQo8YnI+DQozLiBnZW5lcmFsIGNvbW1lbnQ8YnI+DQo9PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08YnI+DQo8YnI+DQpw YWdlIDEyIChjaGFwdGVyIDYuMSwgMm5kIHNlY3Rpb24pOjxicj4NCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KWy4uLl0gVGhlIHBlci1hc3NvY2lhdGlvbiBj b250ZXh0IHZhbHVlIFNIQUxMIGNvbnNpc3Qgb2YgdGhlIGZvbGxvd2luZyBmaXZlIG9jdGV0czog VGhlIGZpcnN0IHR3byBvY3RldHMgU0hBTEwgYmUgemVyby5bLi4uXTxicj4NCjxicj4NCjxicj4N CnJlbWFyazo8YnI+DQotLS0tLS0tLS0tLSA8YnI+DQpNeSBmaXJzdCB0aG91Z2h0IHdhczogd2h5 PyBBdCBmaXJzdCBpdCB3YXMgYSBtYWdpYyBudW1iZXIgZm9yIG1lLiBUaGUgc29sdXRpb24gaXMg aGVyZTogY2hhcHRlciA1LjI6DQo8YnI+DQpbLi4uXSBhbmQgTVVTVCBiZWdpbiB3aXRoIHRoZSB0 d28tb2N0ZXQgUHJvdG9jb2wgSUQgd2hpY2ggd2FzIG5lZ290aWF0ZWQgYXMgYSBOZXh0IFByb3Rv Y29sLiBbLi4uXTxicj4NCjxicj4NCkkgdGhpbmsgdGhpcyBzaG91bGQgYmUgbWVudGlvbmVkIGFn YWluIG9yIHJlZmVyZW5jZWQgdG8gdGhlIGNvcnJlc3BvbmRpbmcgdGFibGUgKGNoYXB0ZXIgOCku PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KNC4gZ2VuZXJhbCBjb21tZW50PGJy Pg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PGJyPg0KPGJyPg0KcGFnZSAxMyAoY2hhcHRlciA2LjUsIDJuZCBzZWN0aW9uKTo8YnI+ DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NClsuLi5dIFRo aXMgbGVuZ3RoIHJlcXVpcmVtZW50IHNlcnZlcyB0byBlbnN1cmUgdGhhdCB0aGUgcmVzcG9uc2Ug d2lsbCBub3QgYmUgbGFyZ2VyIHRoYW4gdGhlIHJlcXVlc3QsIGluIG9yZGVyIHRvIGltcHJvdmUg dGltZWtlZXBpbmcgcHJlY2lzaW9uIGFuZCBbLi4uXTxicj4NCjxicj4NCjxicj4NCnJlbWFyazo8 YnI+DQotLS0tLS0tLS0tLSA8YnI+DQpEb2VzIGl0IHJlYWxseSBpbXByb3ZlIHRoZSB0aW1la2Vl cGluZz8gSSB0aGluayB0aGUgaWRlYSBpcyB0byByZWR1Y2UgdGhlIGFzeW1tZXRyeSBpZiB0aGUg cmVxdWVzdCBhbmQgcmVzcG9uc2UgbWVzc2FnZSBoYXZlIHRoZSBzYW1lIHNpemUuDQo8YnI+DQpC dXQgY2xpZW50IGFuZCBzZXJ2ZXIgbWF5IGhhdmUgZGlmZmVyZW50IHBlcmZvcm1hbmNlIGFuZCB0 aGVyZWZvcmUgdGhlIHByb2Nlc3Npbmcgc3BlZWQgcGVyIE5UUCBQYWNrYWdlIGlzIGRpZmZlcmVu dCB0b28uJm5ic3A7IC4uLml0J3MganVzdCBhIHRob3VnaHQ8YnI+DQo8YnI+DQo8YnI+DQo8YnI+ DQo8YnI+DQo8YnI+DQo1LiBhbHRlcm5hdGl2ZSBwcm9wb3NhbDxicj4NCj09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTxicj4NCjxicj4N CnBhZ2UgMjAgKGNoYXB0ZXIgOCwgMXN0IHNlY3Rpb24pOjxicj4NCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KWy4uLl0gVHlwZSBOdW1iZXIgKFJFUVVJUkVE KTogQW4gaW50ZWdlciBpbiB0aGUgcmFuZ2UgMC0zMjc2NyBpbmNsdXNpdmUgWy4uLl08YnI+DQo8 YnI+DQo8YnI+DQpiZXR0ZXI/Ojxicj4NCi0tLS0tLS0tLS0tIDxicj4NClsuLi5dIFR5cGUgTnVt YmVyIChSRVFVSVJFRCk6IEFuIDxiPjE1IGJpdDwvYj4gaW50ZWdlciBpbiB0aGUgcmFuZ2UgMC0z Mjc2NyBpbmNsdXNpdmUgWy4uLl08YnI+DQo8YnI+DQouLi4ubm90IDE2IGJpdCwgYmVjYXVzZSB3 ZSB1c2UgYSBjcml0aWNhbCBiaXQgaW4gb3VyIHJlY29yZHMgKGZpcnN0IGJpdCk8YnI+DQo8YnI+ DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo2LiBzb21lIHByb2JsZW1zIHdpdGggJ1Ro ZSBOVFMgQXV0aGVudGljYXRvciBhbmQgRW5jcnlwdGVkIEV4dGVuc2lvbnMgZXh0ZW5zaW9uJyAo cGFnZSAxNCwgY2hhcHRlciA2LjYpPGJyPg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PGJyPg0KPGJyPg0KZmllbGQgZGVzY3JpcHRp b246PGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQon Tm9uY2UgbGVuZ2h0JzogV2Ugc2hvdWxkIG1lbnRpb24gdGhhdCB0aGUgdmFsdWUgaXMgdG8gYmUg aW50ZXJwcmV0ZWQgYXMgJ3Vuc2lnbmVkIGludCcuPGJyPg0KPGJyPg0KJ05vbmNlJzogQXQgZmly c3QgSSBoYWQgc29tZSB0cm91YmxlIHRvIHVuZGVyc3RhbmQgd2hlcmUgdGhlIG5vbmNlIGNvbWVz IGZyb20gYW5kIHdoaWNoIGxlbmd0aCB3ZSB1c2UuIE5vdyBJIGtub3cgaXQsIGJ1dCBtYXliZSB3 ZSBzaG91bGQgYWRkIHNvbWUgbW9yZSBpbmZvcm1hdGlvbiB0byB0aGlzIGZpZWxkLjxicj4NCnBl cmhhcHMgZnJvbSB0aGVzZTombmJzcDsmbmJzcDsgWy4uLl0gTm9uY2U6IGEgbm9uY2UgYXMgcmVx dWlyZWQgYnkgdGhlIG5lZ290aWF0ZWQgQUVBRCBBbGdvcml0aG0uIFsuLi5dJm5ic3A7Jm5ic3A7 IHRvIHRoZXNlOiZuYnNwOyZuYnNwOyBbLi4uXSBOb25jZTogYSBuZXcgZ2VuZXJhdGVkIG5vbmNl IHdob3NlIGxlbmd0aCBhbmQgZm9ybWF0IGlzIGRldGVybWluZWQgYnkgdGhlIG5lZ290aWF0ZWQg QUVBRCBhbGdvcml0aG0gKFJGQyA1MTE2LCBjaGFwdGVyIDMuMikuIFsuLi5dPGJyPg0KPGJyPg0K PGJyPg0KJ0NoaXBlcnRleHQnOiBTb21lIHJlYWRlcnMgKHN0dWRlbnRzIGluIG15IHRlYW0pIGhh ZCBkaWZmaWN1bHRpZXMgdG8gdW5kZXJzdGFuZCB0aGlzIGZpZWxkLiBBbGwgb2YgdGhlbSB0aG91 Z2h0LCB0aGF0IHRoaXMgZmllbGQgY29udGFpbnMgYW4gZW5jcnlwdGVkIHZlcnNpb24gb2YgdGhl IHdob2xlIE5UUCBwYWNrYWdlLiBBbmQgdGhpcyBpcyB3cm9uZy4gSSB0aGluayB0aGUgcHJvYmxl bSBpcyB0aGlzIGxpbmU6IFsuLi5dIGF1dGhlbnRpY2F0aW9uDQogdGFnIGluIGFkZGl0aW9uIHRv IHRoZSBhY3R1YWwgY2lwaGVydGV4dC4gWy4uLl0uIFdlbGwsIGlmIHJlYWRlcnMgZG8gbm90IGtu b3cgZXhhY3RseSBob3cgQUVBRCB3b3JrcywgdGhlbiB0aGlzIGxlYWRzIHRvIHN0cm9uZyB1bmRl cnN0YW5kaW5nIHByb2JsZW1zIGF0IHRoaXMgcG9pbnQsIHNpbmNlIHRoZSB0ZXJtcyAnYXV0aGVu dGljYXRpb24gdGFnJyBhbmQgJ2NpcGhlcnRleHQnIHNlZW0gbm90IGtub3duLiBJIHRoaW5rIHdl IHNob3VsZCBhZGQNCiBhIHJlZmVyZW5jZSAoUkZDIDUxMTYgLS0mZ3Q7IEFFQUQpIG9yIHNvbWUg aW5mb3JtYXRpb24gYWJvdXQgdGhpcyB0ZXJtcyAoJ2F1dGhlbnRpY2F0aW9uIHRhZycgaXMgbGlr ZSBhIE1BQyBhbmQgJ2NpcGhlcnRleHQnIGNvbnRhaW5zIG9wdGlvbmFsIEV4dGVuc2lvbiBGaWVs ZHMgYW5kIGNhbiBiZSBhYnNlbnQgaWYgbm8gRXh0ZW5zaW9uIEZpZWxkcyBhcmUgZW5jcnlwdGVk LikuIE1heWJlIGNvbmZ1c2VzIHRoZSBmaWVsZCBuYW1lICdDaGlwZXJ0ZXh0Jw0KIHRvby48YnI+ DQo8YnI+DQo8YnI+DQonUGFkZGluZzonJm5ic3A7IFRoaXMgbGluZTogWy4uLl0gc28gdGhhdCBp bXBsZW1lbnRhdGlvbnMgY2FuIHVuYW1iaWd1b3VzbHkgZGVsaW1pdCB0aGUgZW5kIG9mIHRoZSBj aXBoZXJ0ZXh0IGZyb20gdGhlIHN0YXJ0IG9mIHRoZSBwYWRkaW5nIFsuLi5dIGNhbiBiZSBkaWZm aWN1bHQgdG8uIEluIHRoZSBiZWdpbm5pbmcgSSBkaWQgbm90IGtub3cgaG93IHRoaXMgc2hvdWxk IHdvcmsuIFdlIHNob3VsZCBzYXkgdGhhdCBpbXBsZW1lbnRhdGlvbnMgY2FuIHJlYWQNCiB0aGUg bGFzdCBvY3RldCBvZiB0aGlzIGV4dGVuc2lvbiBjb250ZW50LCB0byBmaW5kIG91dCBob3cgYmln IHRoZSBwYWRkaW5nIGlzLjxicj4NCjxicj4NCkZ1cnRoZXJtb3JlIHdlIHNob3VsZCBjaGFuZ2Ug dGhpcyBsaW5lOjxicj4NClsuLi5dIHJlcXVpcmVtZW50IHRoYXQgKGluIHRoZSBhYnNlbmNlIG9m IGEgbGVnYWN5IE1BQykgZXh0ZW5zaW9ucyBoYXZlIGEgdG90YWwgbGVuZ3RoIGluIG9jdGV0cyAo aW5jbHVkaW5nIHRoZSBmb3VyIG9jdGV0cyBmb3IgdGhlIHR5cGUgYW5kIGxlbmd0aCBmaWVsZHMp Jm5ic3A7IFsuLi5dPGJyPg0KPGJyPg0KaW4gdGhpczo8YnI+DQpbLi4uXSByZXF1aXJlbWVudCB0 aGF0IChpbiB0aGUgYWJzZW5jZSBvZiBhIGxlZ2FjeSBNQUMpIDxiPk5UUDwvYj4gZXh0ZW5zaW9u cyBoYXZlIGEgdG90YWwgbGVuZ3RoIGluIG9jdGV0cyAoaW5jbHVkaW5nIHRoZSBmb3VyIG9jdGV0 cyBmb3IgdGhlIHR5cGUgYW5kIGxlbmd0aCBmaWVsZHMpIFsuLi5dPGJyPg0KPGJyPg0KPGJyPg0K LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQo8YnI+DQpbLi4uXSBQOiBUaGUg cGxhaW50ZXh0IFNIQUxMIGNvbnNpc3Qgb2YgYWxsIChpZiBhbnkpIGV4dGVuc2lvbnMgdG8gYmUg ZW5jcnlwdGVkLiBbLi4uXQ0KPGJyPg0KPGJyPg0KV2hpY2ggZm9ybWF0PyBUeXBpY2FsIE5UUHY0 IEV4dGVuc2lvbiBGaWVsZHMgb3IgYW5vdGhlciBmb3JtYXQ/IFdlIHNob3VsZCBkZWZpbmUgdGhh dC4gV2Ugc2hvdWxkIGFsc28gbWVudGlvbiB0aGF0IG9ubHkgdGhpcyBjb250ZW50IGlzIGVuY3J5 cHRlZCAobm90IHRoZSBjb250ZW50IG9mIHBhcmFtZXRlciAnQScpLg0KPGJyPg0KSWYgd2UgZG9u J3Qgd2FudCBlbmNyeXB0IGFueXRoaW5nIChkZWZhdWx0IGNhc2UpLCB0aGVuIHRoaXMgcGFyYW1l dGVyIGlzIGVtcHR5Ljxicj4NCjxicj4NCjxicj4NCj09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTxicj4NCjxicj4NClBsZWFzZSBsZXQg bWUga25vdyBpZiB5b3UgaGF2ZSBwcm9ibGVtcyB0byB1bmRlcnN0YW5kIG15ICplbmdsaXNoKi48 YnI+DQo8YnI+DQo8YnI+DQo8L3NwYW4+QmVzdCByZWdhcmRzLDxicj4NCk1hcnRpbjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_DB3PR05MB1725F35D5353CF4038E7E37B39F0DB3PR05MB172eurprd_-- --_004_DB3PR05MB1725F35D5353CF4038E7E37B39F0DB3PR05MB172eurprd_ Content-Type: text/plain; name="ATT00001.txt" Content-Description: ATT00001.txt Content-Disposition: attachment; filename="ATT00001.txt"; size=124; creation-date="Fri, 11 Aug 2017 09:35:09 GMT"; modification-date="Fri, 11 Aug 2017 09:35:09 GMT" Content-ID: <0535E245A8D2DE45B3709FA9FC562C3C@eurprd05.prod.outlook.com> Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm50cCBtYWls aW5nIGxpc3QNCm50cEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9udHANCg== --_004_DB3PR05MB1725F35D5353CF4038E7E37B39F0DB3PR05MB172eurprd_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp --_004_DB3PR05MB1725F35D5353CF4038E7E37B39F0DB3PR05MB172eurprd_-- From nobody Tue Aug 29 06:16:45 2017 Return-Path: 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 0ADB313217D for ; Tue, 29 Aug 2017 06:16:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 jWOu92QAl_Md for ; Tue, 29 Aug 2017 06:16:41 -0700 (PDT) Received: from mx1.bs.ptb.de (mx1.bs.ptb.de [IPv6:2001:638:610:bd01::120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD65E13292D for ; Tue, 29 Aug 2017 06:16:40 -0700 (PDT) Received: from smtp-hub.bs.ptb.de (smtpint01.bs.ptb.de [141.25.87.32]) by mx1.bs.ptb.de with ESMTP id v7TDGbrE019282-v7TDGbrG019282 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 29 Aug 2017 15:16:38 +0200 Received: from lotus.bs.ptb.de (lotus.bs.ptb.de [141.25.85.200]) by smtp-hub.bs.ptb.de (Postfix) with ESMTPS id 51ECC533A88; Tue, 29 Aug 2017 15:16:37 +0200 (CEST) In-Reply-To: <59A52683020000A100027A58@gwsmtp1.uni-regensburg.de> References: <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> <47b5b4e3-41c9-6779-4a96-b11650483499@nwtime.org> <59A52683020000A100027A58@gwsmtp1.uni-regensburg.de> To: "Ulrich Windl" Cc: ntp@ietf.org MIME-Version: 1.0 Message-ID: From: kristof.teichel@ptb.de Date: Tue, 29 Aug 2017 15:16:34 +0200 Content-Type: multipart/alternative; boundary="=_alternative 0048EEC7C125818B_=" Archived-At: Subject: Re: [Ntp] Antw: [NTP] WGLC for draft-ietf-ntp-using-nts-for-ntp (Objectives Subsection) X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Aug 2017 13:16:44 -0000 Dies ist eine mehrteilige Nachricht im MIME-Format. --=_alternative 0048EEC7C125818B_= Content-Type: text/plain; charset="US-ASCII" "Ulrich Windl" schrieb am 29.08.2017 10:32:03: > Von: "Ulrich Windl" > An: > Datum: 29.08.2017 10:40 > Betreff: Antw: [Ntp] [NTP] WGLC for draft-ietf-ntp-using-nts-for-ntp > (Objectives Subsection) > > Hi! > > I'm not deep in it, but the basic discussion seems to be that Dave > Mills thinks some things are "good enough", while others think they > are not. Maybe point out more clearly where any why things are not > good enough. > I must agree that I, too, see little practical difference between a > sub-nanosecond timestamp and a random number (just to name one > example), considering that the network delay is above microseconds. > So the chances for a successful replay should be less than 1/1000th, right? I guess this specific example is a matter of perspective: consciously settling for ~1/(2^10) does not sound optimal to me when the alternative is to go for ~1/(2^128), at the cost of a few additional octets. Also, I appreciate Daniel's point that it is simply good practice to make the securtiy properties of a protection mechanism independent from the content of the protected protocol. Additionally: do we have any argument that introducing a nonce (as per good general practice) would actively be a significant detriment? Because I don't see it, and I sense a slight tendency (in the whole WG, where the NTS documents have been concerned) to mix up "we do not absolutely have to" and "we absolutely should not". > > Regards, > Ulrich > >>> schrieb am 29.08.2017 um 10:05 in Nachricht > : > > Hello all, > > > > I am going to attempt a rundown of Harlan's input, trying to avoid too > > much overlap with responses that Daniel already gave. > > I want to treat the "Objectives" subsection separately, ASAP, because > > consensus here is really essential for consensus anywhere else. > > > > > >> [...] > >> > >> TL;DR version: > >> > >> There are some parts of the proposal that are wrong, and some other > >> parts are misleading. There are sections of the proposal that are > >> confusing, and there are sections of the proposal that are inadequately > >> described. > >> > >> Long version: > >> > >> 1.1. Objectives > >> > >> - Confidentiality: Under what conditions is this actually useful? If > >> confidentiality is a need for some, in those situations why not just > >> send the NTP traffic over an encrypted VPN? > > > > The need for confidentiality (for fresh keys) is derived from the need for > > unlinkability (see Daniel's response). > > Editorial: I believe that for better logical structure, confidentiality > > should therefore be listed after unlinkability, and be given a short > > comment acknowledging this derivation. > > Content: I think necessity is proven and I see no significant downside. > > > > > >> > >> - Replay prevention: The core NTP specification already has replay > >> prevention. The proposed language is misleading, implying that without > >> NTS there is no replay protection. If the existing core protection > >> against replay is inadequate, please describe the problem(s). You could > >> also say "NTS offers another, additional layer of replay prevention > >> beyond what NTP already provides." > > > > I don't see how it is helpful to read the NTS proposal as a critique of > > NTPv4. > > Content: Relying on timestamps for replay protection simply offers much > > less entropy than relying on random values. Also, see Daniel's response. > > Personally, I see necessity for this objective. Also, I cannot see any > > significant downside. > > > > > >> > >> - Request-response consistency: The core NTP protocol already has > >> request-response consistency checks, where useful. The proposed > >> language is misleading, implying that without NTS there is no > >> request-response consistency checking. If the existing checks for > >> request-response consistency is inadequate, please describe the > >> problem(s). You could also say "NTS offers another, additional layer of > >> request-response consistency checks beyond what NTP already provides." > > > > See replay prevention. > > > > > >> - Unlinkability: The stated threat seems extraordinarily unlikely to be > >> possible if more than several networks are involved. Even if such a > >> threat was possible and used, if the client/server model for NTS is to > >> use NTP packets with NTS extension fields, an outside observer can still > >> see that there is a client sending requests to a set of servers that > >> some other client has used before. How is that traffic not "linkable"? > >> This "feature" seems to be a red-herring. > > > > I don't think there is much merit to re-evaluating general IETF policy for > > our special case. > > Editorial: can we have a citation for where this policy is stated? > > Content: > > - Necessity is derived from general policy. So we will do the best we can. > > An argument along the lines of "but it might not good enough" should not > > influence that policy. > > - This is item 1/2 where we are facing a kind of categorical imperative. > > The overall system only works if all protocols follow a certain ruleset. > > Therefore, we must follow that ruleset. In this case, the rule is: do not > > introduce new ways for an observer to recognize you by your traffic. > > > > > >> - Non-amplification: The core problem is DDoS. Amplification is a > >> secondary problem. Sure, the avoidance of amplification is a useful > >> interim step. But the target protocol isn't the place to solve the > >> DDoS problem. DDoS is basically an "overcommit" problem. BCP38, > > anyone? > > > > See unlinkability. > > - This is item 2/2 where categorical imperative comes into play. The rule > > here is: do not introduce new ways for an attacker to direct to a target a > > message larger than the one sent by the attacker. > > > > > >> - Scalability: The way this is phrased is confusing. If this goal is > >> specific to NTS, then it should say so. > > > > It's a little more complex: NTS must not *introduce a need for* per-client > > state. > > But I don't think that level of detail would be helpful here. > > > >> Given the subsequent > >> discussions about C2S, S2C, etc., it also seems disingenuous. > > > > Do I understand correctly that you don't believe the objective is being > > fulfilled? > > If so, I disagree. But in any event, this question should not influence > > our policy of having scalability as an objective. > > > >> Aside > >> from these things, it seems to be another red-herring. More detail > > below. > > > > No, scalability is not a "red herring". On the contrary, it is a major > > reason why we need a new standard (because scalability is a huge drawback > > of using symmetric key protection). > > > > > > > > My take-away for the "Objectives" subsection is this: > > > > I believe it could be clearer. Specifically, I would suggest we add some > > language linking to RFC 7384 (Tal's "Security Requirements...") for the > > objectives that are derived from there, and some other language for > > objectives that are derived from generic IETF goals for security > > protocols. > > I would like to stress that all of this is solvable by small amounts of > > editorial work. > > > > I also believe that nothing in this subsection is wrong or misleading. > > (Confirmation from other reviewers welcome - again, consensus here is > > needed as a basis for all other discussion) > > > --=_alternative 0048EEC7C125818B_= Content-Type: text/html; charset="US-ASCII" "Ulrich Windl" <Ulrich.Windl@rz.uni-regensburg.de> schrieb am 29.08.2017 10:32:03:
> Von: "Ulrich Windl" <Ulrich.Windl@rz.uni-regensburg.de>
> An: <kristof.teichel@ptb.de>
> Datum: 29.08.2017 10:40
> Betreff: Antw: [Ntp] [NTP] WGLC for draft-ietf-ntp-using-nts-for-ntp
> (Objectives Subsection)
>
> Hi!
>
> I'm not deep in it, but the basic discussion seems to be that Dave
> Mills thinks some things are "good enough", while others think they
> are not. Maybe point out more clearly where any why things are not
> good enough.
> I must agree that I, too, see little practical difference between  a
> sub-nanosecond timestamp and a random number (just to name one
> example), considering that the network delay is above microseconds.
> So the chances for a successful replay should be less than 1/1000th, right?

I guess this specific example is a matter of perspective: consciously settling for ~1/(2^10) does not sound optimal to me when the alternative is to go for ~1/(2^128), at the cost of a few additional octets.
Also, I appreciate Daniel's point that it is simply good practice to make the securtiy properties of a protection mechanism independent from the content of the protected protocol.

Additionally: do we have any argument that introducing a nonce (as per good general practice) would actively be a significant detriment?
Because I don't see it, and I sense a slight tendency (in the whole WG, where the NTS documents have been concerned) to mix up "we do not absolutely have to" and "we absolutely should not".

>
> Regards,
> Ulrich



> >>> <kristof.teichel@ptb.de> schrieb am 29.08.2017 um 10:05 in Nachricht
> <OF9C2B40AB.526EBB61-ONC125818B.0026970E-C125818B.002C711C@ptb.de>:
> > Hello all,
> >
> > I am going to attempt a rundown of Harlan's input, trying to avoid too
> > much overlap with responses that Daniel already gave.
> > I want to treat the "Objectives" subsection separately, ASAP, because
> > consensus here is really essential for consensus anywhere else.
> >
> >
> >> [...]
> >>
> >> TL;DR version:
> >>
> >> There are some parts of the proposal that are wrong, and some other
> >> parts are misleading.  There are sections of the proposal that are
> >> confusing, and there are sections of the proposal that are inadequately
> >> described.
> >>
> >> Long version:
> >>
> >> 1.1. Objectives
> >>
> >> - Confidentiality: Under what conditions is this actually useful?  If
> >> confidentiality is a need for some, in those situations why not just
> >> send the NTP traffic over an encrypted VPN?
> >
> > The need for confidentiality (for fresh keys) is derived from the need for
> > unlinkability (see Daniel's response).
> > Editorial: I believe that for better logical structure, confidentiality
> > should therefore be listed after unlinkability, and be given a short
> > comment acknowledging this derivation.
> > Content: I think necessity is proven and I see no significant downside.
> >
> >
> >>
> >> - Replay prevention: The core NTP specification already has replay
> >> prevention.  The proposed language is misleading, implying that without
> >> NTS there is no replay protection.  If the existing core protection
> >> against replay is inadequate, please describe the problem(s).  You could
> >> also say "NTS offers another, additional layer of replay prevention
> >> beyond what NTP already provides."
> >
> > I don't see how it is helpful to read the NTS proposal as a critique of
> > NTPv4.
> > Content: Relying on timestamps for replay protection simply offers much
> > less entropy than relying on random values. Also, see Daniel's response.
> > Personally, I see necessity for this objective. Also, I cannot see any
> > significant downside.
> >
> >
> >>
> >> - Request-response consistency: The core NTP protocol already has
> >> request-response consistency checks, where useful.  The proposed
> >> language is misleading, implying that without NTS there is no
> >> request-response consistency checking.  If the existing checks for
> >> request-response consistency is inadequate, please describe the
> >> problem(s).  You could also say "NTS offers another, additional layer of
> >> request-response consistency checks beyond what NTP already provides."
> >
> > See replay prevention.
> >
> >
> >> - Unlinkability: The stated threat seems extraordinarily unlikely to be
> >> possible if more than several networks are involved.  Even if such a
> >> threat was possible and used, if the client/server model for NTS is to
> >> use NTP packets with NTS extension fields, an outside observer can still
> >> see that there is a client sending requests to a set of servers that
> >> some other client has used before.  How is that traffic not "linkable"?
> >> This "feature" seems to be a red-herring.
> >
> > I don't think there is much merit to re-evaluating general IETF policy for
> > our special case.
> > Editorial: can we have a citation for where this policy is stated?
> > Content:
> > - Necessity is derived from general policy. So we will do the best we can.
> > An argument along the lines of "but it might not good enough" should not
> > influence that policy.
> > - This is item 1/2 where we are facing a kind of categorical imperative.
> > The overall system only works if all protocols follow a certain ruleset.
> > Therefore, we must follow that ruleset. In this case, the rule is: do not
> > introduce new ways for an observer to recognize you by your traffic.
> >
> >
> >> - Non-amplification: The core problem is DDoS.  Amplification is a
> >> secondary problem.  Sure, the avoidance of amplification is a useful
> >> interim step.  But the target protocol isn't the place to solve the
> >> DDoS problem.  DDoS is basically an "overcommit" problem.  BCP38,
> > anyone?
> >
> > See unlinkability.
> > - This is item 2/2 where categorical imperative comes into play. The rule
> > here is: do not introduce new ways for an attacker to direct to a target a
> > message larger than the one sent by the attacker.
> >
> >
> >> - Scalability: The way this is phrased is confusing.  If this goal is
> >> specific to NTS, then it should say so.
> >
> > It's a little more complex: NTS must not *introduce a need for* per-client
> > state.
> > But I don't think that level of detail would be helpful here.
> >
> >> Given the subsequent
> >> discussions about C2S, S2C, etc., it also seems disingenuous.
> >
> > Do I understand correctly that you don't believe the objective is being
> > fulfilled?
> > If so, I disagree. But in any event, this question should not influence
> > our policy of having scalability as an objective.
> >
> >> Aside
> >> from these things, it seems to be another red-herring.  More detail
> > below.
> >
> > No, scalability is not a "red herring". On the contrary, it is a major
> > reason why we need a new standard (because scalability is a huge drawback
> > of using symmetric key protection).
> >
> >
> >
> > My take-away for the "Objectives" subsection is this:
> >
> > I believe it could be clearer. Specifically, I would suggest we add some
> > language linking to RFC 7384 (Tal's "Security Requirements...") for the
> > objectives that are derived from there, and some other language for
> > objectives that are derived from generic IETF goals for security
> > protocols.
> > I would like to stress that all of this is solvable by small amounts of
> > editorial work.
> >
> > I also believe that nothing in this subsection is wrong or misleading.
> > (Confirmation from other reviewers welcome - again, consensus here is
> > needed as a basis for all other discussion)
>
>
>
--=_alternative 0048EEC7C125818B_=-- From ntp-bounces@ietf.org Tue Aug 29 06:16:46 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 05C5113292D; Tue, 29 Aug 2017 06:16:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1504012606; bh=17ZzryQjrIz5c8f9VsuY/3eQleZb1we67FtLIRKxuJQ=; h=In-Reply-To:References:To:From:Date:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc; b=J55wUGUkCkXBXb4KbEZgh/XtIp+fkvl3L+APZXkJmVH4dLfy4d+fFSDUuMHZOhqDk nqYce9DRIlh4y0x1wky+NUw9mmSpAzag6MqEIJvlIXDhE2HjMbbP4Ki5OtVc9ioGiw RIWtFdO4SOJKhEeFebgWAqxY4d998B6m7Am5MNQw= 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 0ADB313217D for ; Tue, 29 Aug 2017 06:16:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 jWOu92QAl_Md for ; Tue, 29 Aug 2017 06:16:41 -0700 (PDT) Received: from mx1.bs.ptb.de (mx1.bs.ptb.de [IPv6:2001:638:610:bd01::120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD65E13292D for ; Tue, 29 Aug 2017 06:16:40 -0700 (PDT) Received: from smtp-hub.bs.ptb.de (smtpint01.bs.ptb.de [141.25.87.32]) by mx1.bs.ptb.de with ESMTP id v7TDGbrE019282-v7TDGbrG019282 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 29 Aug 2017 15:16:38 +0200 Received: from lotus.bs.ptb.de (lotus.bs.ptb.de [141.25.85.200]) by smtp-hub.bs.ptb.de (Postfix) with ESMTPS id 51ECC533A88; Tue, 29 Aug 2017 15:16:37 +0200 (CEST) In-Reply-To: <59A52683020000A100027A58@gwsmtp1.uni-regensburg.de> References: <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> <47b5b4e3-41c9-6779-4a96-b11650483499@nwtime.org> <59A52683020000A100027A58@gwsmtp1.uni-regensburg.de> To: "Ulrich Windl" MIME-Version: 1.0 Message-ID: From: kristof.teichel@ptb.de Date: Tue, 29 Aug 2017 15:16:34 +0200 Archived-At: Subject: Re: [Ntp] Antw: [NTP] WGLC for draft-ietf-ntp-using-nts-for-ntp (Objectives Subsection) X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: ntp@ietf.org Content-Type: multipart/mixed; boundary="===============5101112575889559889==" Errors-To: ntp-bounces@ietf.org Sender: "ntp" Dies ist eine mehrteilige Nachricht im MIME-Format. --===============5101112575889559889== Content-Type: multipart/alternative; boundary="=_alternative 0048EEC7C125818B_=" Dies ist eine mehrteilige Nachricht im MIME-Format. --=_alternative 0048EEC7C125818B_= Content-Type: text/plain; charset="US-ASCII" "Ulrich Windl" schrieb am 29.08.2017 10:32:03: > Von: "Ulrich Windl" > An: > Datum: 29.08.2017 10:40 > Betreff: Antw: [Ntp] [NTP] WGLC for draft-ietf-ntp-using-nts-for-ntp > (Objectives Subsection) > > Hi! > > I'm not deep in it, but the basic discussion seems to be that Dave > Mills thinks some things are "good enough", while others think they > are not. Maybe point out more clearly where any why things are not > good enough. > I must agree that I, too, see little practical difference between a > sub-nanosecond timestamp and a random number (just to name one > example), considering that the network delay is above microseconds. > So the chances for a successful replay should be less than 1/1000th, right? I guess this specific example is a matter of perspective: consciously settling for ~1/(2^10) does not sound optimal to me when the alternative is to go for ~1/(2^128), at the cost of a few additional octets. Also, I appreciate Daniel's point that it is simply good practice to make the securtiy properties of a protection mechanism independent from the content of the protected protocol. Additionally: do we have any argument that introducing a nonce (as per good general practice) would actively be a significant detriment? Because I don't see it, and I sense a slight tendency (in the whole WG, where the NTS documents have been concerned) to mix up "we do not absolutely have to" and "we absolutely should not". > > Regards, > Ulrich > >>> schrieb am 29.08.2017 um 10:05 in Nachricht > : > > Hello all, > > > > I am going to attempt a rundown of Harlan's input, trying to avoid too > > much overlap with responses that Daniel already gave. > > I want to treat the "Objectives" subsection separately, ASAP, because > > consensus here is really essential for consensus anywhere else. > > > > > >> [...] > >> > >> TL;DR version: > >> > >> There are some parts of the proposal that are wrong, and some other > >> parts are misleading. There are sections of the proposal that are > >> confusing, and there are sections of the proposal that are inadequately > >> described. > >> > >> Long version: > >> > >> 1.1. Objectives > >> > >> - Confidentiality: Under what conditions is this actually useful? If > >> confidentiality is a need for some, in those situations why not just > >> send the NTP traffic over an encrypted VPN? > > > > The need for confidentiality (for fresh keys) is derived from the need for > > unlinkability (see Daniel's response). > > Editorial: I believe that for better logical structure, confidentiality > > should therefore be listed after unlinkability, and be given a short > > comment acknowledging this derivation. > > Content: I think necessity is proven and I see no significant downside. > > > > > >> > >> - Replay prevention: The core NTP specification already has replay > >> prevention. The proposed language is misleading, implying that without > >> NTS there is no replay protection. If the existing core protection > >> against replay is inadequate, please describe the problem(s). You could > >> also say "NTS offers another, additional layer of replay prevention > >> beyond what NTP already provides." > > > > I don't see how it is helpful to read the NTS proposal as a critique of > > NTPv4. > > Content: Relying on timestamps for replay protection simply offers much > > less entropy than relying on random values. Also, see Daniel's response. > > Personally, I see necessity for this objective. Also, I cannot see any > > significant downside. > > > > > >> > >> - Request-response consistency: The core NTP protocol already has > >> request-response consistency checks, where useful. The proposed > >> language is misleading, implying that without NTS there is no > >> request-response consistency checking. If the existing checks for > >> request-response consistency is inadequate, please describe the > >> problem(s). You could also say "NTS offers another, additional layer of > >> request-response consistency checks beyond what NTP already provides." > > > > See replay prevention. > > > > > >> - Unlinkability: The stated threat seems extraordinarily unlikely to be > >> possible if more than several networks are involved. Even if such a > >> threat was possible and used, if the client/server model for NTS is to > >> use NTP packets with NTS extension fields, an outside observer can still > >> see that there is a client sending requests to a set of servers that > >> some other client has used before. How is that traffic not "linkable"? > >> This "feature" seems to be a red-herring. > > > > I don't think there is much merit to re-evaluating general IETF policy for > > our special case. > > Editorial: can we have a citation for where this policy is stated? > > Content: > > - Necessity is derived from general policy. So we will do the best we can. > > An argument along the lines of "but it might not good enough" should not > > influence that policy. > > - This is item 1/2 where we are facing a kind of categorical imperative. > > The overall system only works if all protocols follow a certain ruleset. > > Therefore, we must follow that ruleset. In this case, the rule is: do not > > introduce new ways for an observer to recognize you by your traffic. > > > > > >> - Non-amplification: The core problem is DDoS. Amplification is a > >> secondary problem. Sure, the avoidance of amplification is a useful > >> interim step. But the target protocol isn't the place to solve the > >> DDoS problem. DDoS is basically an "overcommit" problem. BCP38, > > anyone? > > > > See unlinkability. > > - This is item 2/2 where categorical imperative comes into play. The rule > > here is: do not introduce new ways for an attacker to direct to a target a > > message larger than the one sent by the attacker. > > > > > >> - Scalability: The way this is phrased is confusing. If this goal is > >> specific to NTS, then it should say so. > > > > It's a little more complex: NTS must not *introduce a need for* per-client > > state. > > But I don't think that level of detail would be helpful here. > > > >> Given the subsequent > >> discussions about C2S, S2C, etc., it also seems disingenuous. > > > > Do I understand correctly that you don't believe the objective is being > > fulfilled? > > If so, I disagree. But in any event, this question should not influence > > our policy of having scalability as an objective. > > > >> Aside > >> from these things, it seems to be another red-herring. More detail > > below. > > > > No, scalability is not a "red herring". On the contrary, it is a major > > reason why we need a new standard (because scalability is a huge drawback > > of using symmetric key protection). > > > > > > > > My take-away for the "Objectives" subsection is this: > > > > I believe it could be clearer. Specifically, I would suggest we add some > > language linking to RFC 7384 (Tal's "Security Requirements...") for the > > objectives that are derived from there, and some other language for > > objectives that are derived from generic IETF goals for security > > protocols. > > I would like to stress that all of this is solvable by small amounts of > > editorial work. > > > > I also believe that nothing in this subsection is wrong or misleading. > > (Confirmation from other reviewers welcome - again, consensus here is > > needed as a basis for all other discussion) > > > --=_alternative 0048EEC7C125818B_= Content-Type: text/html; charset="US-ASCII" "Ulrich Windl" <Ulrich.Windl@rz.uni-regensburg.de> schrieb am 29.08.2017 10:32:03:
> Von: "Ulrich Windl" <Ulrich.Windl@rz.uni-regensburg.de>
> An: <kristof.teichel@ptb.de>
> Datum: 29.08.2017 10:40
> Betreff: Antw: [Ntp] [NTP] WGLC for draft-ietf-ntp-using-nts-for-ntp
> (Objectives Subsection)
>
> Hi!
>
> I'm not deep in it, but the basic discussion seems to be that Dave
> Mills thinks some things are "good enough", while others think they
> are not. Maybe point out more clearly where any why things are not
> good enough.
> I must agree that I, too, see little practical difference between  a
> sub-nanosecond timestamp and a random number (just to name one
> example), considering that the network delay is above microseconds.
> So the chances for a successful replay should be less than 1/1000th, right?

I guess this specific example is a matter of perspective: consciously settling for ~1/(2^10) does not sound optimal to me when the alternative is to go for ~1/(2^128), at the cost of a few additional octets.
Also, I appreciate Daniel's point that it is simply good practice to make the securtiy properties of a protection mechanism independent from the content of the protected protocol.

Additionally: do we have any argument that introducing a nonce (as per good general practice) would actively be a significant detriment?
Because I don't see it, and I sense a slight tendency (in the whole WG, where the NTS documents have been concerned) to mix up "we do not absolutely have to" and "we absolutely should not".

>
> Regards,
> Ulrich



> >>> <kristof.teichel@ptb.de> schrieb am 29.08.2017 um 10:05 in Nachricht
> <OF9C2B40AB.526EBB61-ONC125818B.0026970E-C125818B.002C711C@ptb.de>:
> > Hello all,
> >
> > I am going to attempt a rundown of Harlan's input, trying to avoid too
> > much overlap with responses that Daniel already gave.
> > I want to treat the "Objectives" subsection separately, ASAP, because
> > consensus here is really essential for consensus anywhere else.
> >
> >
> >> [...]
> >>
> >> TL;DR version:
> >>
> >> There are some parts of the proposal that are wrong, and some other
> >> parts are misleading.  There are sections of the proposal that are
> >> confusing, and there are sections of the proposal that are inadequately
> >> described.
> >>
> >> Long version:
> >>
> >> 1.1. Objectives
> >>
> >> - Confidentiality: Under what conditions is this actually useful?  If
> >> confidentiality is a need for some, in those situations why not just
> >> send the NTP traffic over an encrypted VPN?
> >
> > The need for confidentiality (for fresh keys) is derived from the need for
> > unlinkability (see Daniel's response).
> > Editorial: I believe that for better logical structure, confidentiality
> > should therefore be listed after unlinkability, and be given a short
> > comment acknowledging this derivation.
> > Content: I think necessity is proven and I see no significant downside.
> >
> >
> >>
> >> - Replay prevention: The core NTP specification already has replay
> >> prevention.  The proposed language is misleading, implying that without
> >> NTS there is no replay protection.  If the existing core protection
> >> against replay is inadequate, please describe the problem(s).  You could
> >> also say "NTS offers another, additional layer of replay prevention
> >> beyond what NTP already provides."
> >
> > I don't see how it is helpful to read the NTS proposal as a critique of
> > NTPv4.
> > Content: Relying on timestamps for replay protection simply offers much
> > less entropy than relying on random values. Also, see Daniel's response.
> > Personally, I see necessity for this objective. Also, I cannot see any
> > significant downside.
> >
> >
> >>
> >> - Request-response consistency: The core NTP protocol already has
> >> request-response consistency checks, where useful.  The proposed
> >> language is misleading, implying that without NTS there is no
> >> request-response consistency checking.  If the existing checks for
> >> request-response consistency is inadequate, please describe the
> >> problem(s).  You could also say "NTS offers another, additional layer of
> >> request-response consistency checks beyond what NTP already provides."
> >
> > See replay prevention.
> >
> >
> >> - Unlinkability: The stated threat seems extraordinarily unlikely to be
> >> possible if more than several networks are involved.  Even if such a
> >> threat was possible and used, if the client/server model for NTS is to
> >> use NTP packets with NTS extension fields, an outside observer can still
> >> see that there is a client sending requests to a set of servers that
> >> some other client has used before.  How is that traffic not "linkable"?
> >> This "feature" seems to be a red-herring.
> >
> > I don't think there is much merit to re-evaluating general IETF policy for
> > our special case.
> > Editorial: can we have a citation for where this policy is stated?
> > Content:
> > - Necessity is derived from general policy. So we will do the best we can.
> > An argument along the lines of "but it might not good enough" should not
> > influence that policy.
> > - This is item 1/2 where we are facing a kind of categorical imperative.
> > The overall system only works if all protocols follow a certain ruleset.
> > Therefore, we must follow that ruleset. In this case, the rule is: do not
> > introduce new ways for an observer to recognize you by your traffic.
> >
> >
> >> - Non-amplification: The core problem is DDoS.  Amplification is a
> >> secondary problem.  Sure, the avoidance of amplification is a useful
> >> interim step.  But the target protocol isn't the place to solve the
> >> DDoS problem.  DDoS is basically an "overcommit" problem.  BCP38,
> > anyone?
> >
> > See unlinkability.
> > - This is item 2/2 where categorical imperative comes into play. The rule
> > here is: do not introduce new ways for an attacker to direct to a target a
> > message larger than the one sent by the attacker.
> >
> >
> >> - Scalability: The way this is phrased is confusing.  If this goal is
> >> specific to NTS, then it should say so.
> >
> > It's a little more complex: NTS must not *introduce a need for* per-client
> > state.
> > But I don't think that level of detail would be helpful here.
> >
> >> Given the subsequent
> >> discussions about C2S, S2C, etc., it also seems disingenuous.
> >
> > Do I understand correctly that you don't believe the objective is being
> > fulfilled?
> > If so, I disagree. But in any event, this question should not influence
> > our policy of having scalability as an objective.
> >
> >> Aside
> >> from these things, it seems to be another red-herring.  More detail
> > below.
> >
> > No, scalability is not a "red herring". On the contrary, it is a major
> > reason why we need a new standard (because scalability is a huge drawback
> > of using symmetric key protection).
> >
> >
> >
> > My take-away for the "Objectives" subsection is this:
> >
> > I believe it could be clearer. Specifically, I would suggest we add some
> > language linking to RFC 7384 (Tal's "Security Requirements...") for the
> > objectives that are derived from there, and some other language for
> > objectives that are derived from generic IETF goals for security
> > protocols.
> > I would like to stress that all of this is solvable by small amounts of
> > editorial work.
> >
> > I also believe that nothing in this subsection is wrong or misleading.
> > (Confirmation from other reviewers welcome - again, consensus here is
> > needed as a basis for all other discussion)
>
>
>
--=_alternative 0048EEC7C125818B_=-- --===============5101112575889559889== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp --===============5101112575889559889==-- From nobody Tue Aug 29 06:52:31 2017 Return-Path: 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 75D22132C31 for ; Tue, 29 Aug 2017 06:52:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 3_6N8fHve8Zg for ; Tue, 29 Aug 2017 06:52:27 -0700 (PDT) Received: from mail.nt.tuwien.ac.at (mail.nt.tuwien.ac.at [128.131.67.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE6DB13293C for ; Tue, 29 Aug 2017 06:52:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.nt.tuwien.ac.at (Postfix) with ESMTP id B13FA24BDC62 for ; Tue, 29 Aug 2017 15:52:22 +0200 (CEST) X-Virus-Scanned: amavisd-new at mydomain = nt.tuwien.ac.at Received: from mail.nt.tuwien.ac.at ([127.0.0.1]) by localhost (mail.nt.tuwien.ac.at [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9T4wkUnyfoXp for ; Tue, 29 Aug 2017 15:52:22 +0200 (CEST) Received: from eris.localnet (eris.nt.tuwien.ac.at [128.131.67.115]) by mail.nt.tuwien.ac.at (Postfix) with ESMTPSA id 190A324BDC58 for ; Tue, 29 Aug 2017 15:52:22 +0200 (CEST) From: Robert Annessi To: ntp@ietf.org Date: Tue, 29 Aug 2017 15:52:21 +0200 Message-ID: <19062708.TpRPKSgBD8@eris> In-Reply-To: <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> References: <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Archived-At: Subject: Re: [Ntp] WGLC for draft-ietf-ntp-using-nts-for-ntp X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Aug 2017 13:52:30 -0000 Hi all, On Wednesday 09 August 2017 04:41:25 Karen O'Donoghue wrote: > This begins a three week working group last call (WGLC) for "Network = Time > Security for the Network Time Protocol=E2=80=9D. =20 > https://datatracker.ietf.org/doc/draft-ietf-ntp-using-nts-for-ntp/ >=20 > Please review and provide comments to the mailing list by no later th= an 31 > August 2017. Earlier comments and discussion would be appreciated. Pl= ease > note that the chairs will be using this WGLC to determine consensus t= o move > this document forward to the IESG.=20 I have a minor remark/question: The introduction states that certain sections of the draft may be appli= cable=20 to other time synchronization protocols, PTP specifically. In Section 1= .2 this=20 idea is presented slightly more detailed saying that the NTS Key Establ= ishment=20 might be extended to PTP. Considering that NTS does not support broadca= st=20 communication (as stated in Section 1.2) and PTP by default relies on=20= multicast communication, I am wondering why this vague future extension= is=20 included in the draft, although it may not even be feasible.=20 Best, Robert From ntp-bounces@ietf.org Tue Aug 29 06:52:32 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 58471132C31; Tue, 29 Aug 2017 06:52:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1504014752; bh=b1Sjkj3A46lBO2i3gsYz5PLVAO+eagI0J71KF3OAmIo=; h=From:To:Date:In-Reply-To:References:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe; b=RY8oJ7zsa3GU7PSFnIL0IyTQnu5592Us+m/E0wTB+7MLywYNb5xgxCJhufPHS/Y2i s8v34i9MgWbhN90ScOriqKthu4LWaNkR/STbUAPvxWbppcU/bcUVwSU1ZzI3DgwwTZ EEZxP9xi23YC4kZaQFS1fC0IGb81BZMmJp0CUlmo= 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 75D22132C31 for ; Tue, 29 Aug 2017 06:52:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 3_6N8fHve8Zg for ; Tue, 29 Aug 2017 06:52:27 -0700 (PDT) Received: from mail.nt.tuwien.ac.at (mail.nt.tuwien.ac.at [128.131.67.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE6DB13293C for ; Tue, 29 Aug 2017 06:52:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.nt.tuwien.ac.at (Postfix) with ESMTP id B13FA24BDC62 for ; Tue, 29 Aug 2017 15:52:22 +0200 (CEST) X-Virus-Scanned: amavisd-new at mydomain = nt.tuwien.ac.at Received: from mail.nt.tuwien.ac.at ([127.0.0.1]) by localhost (mail.nt.tuwien.ac.at [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9T4wkUnyfoXp for ; Tue, 29 Aug 2017 15:52:22 +0200 (CEST) Received: from eris.localnet (eris.nt.tuwien.ac.at [128.131.67.115]) by mail.nt.tuwien.ac.at (Postfix) with ESMTPSA id 190A324BDC58 for ; Tue, 29 Aug 2017 15:52:22 +0200 (CEST) From: Robert Annessi To: ntp@ietf.org Date: Tue, 29 Aug 2017 15:52:21 +0200 Message-ID: <19062708.TpRPKSgBD8@eris> In-Reply-To: <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> References: <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> MIME-Version: 1.0 Archived-At: Subject: Re: [Ntp] WGLC for draft-ietf-ntp-using-nts-for-ntp X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Errors-To: ntp-bounces@ietf.org Sender: "ntp" SGkgYWxsLAoKT24gV2VkbmVzZGF5IDA5IEF1Z3VzdCAyMDE3IDA0OjQxOjI1IEthcmVuIE8nRG9u b2dodWUgd3JvdGU6Cj4gVGhpcyBiZWdpbnMgYSB0aHJlZSB3ZWVrIHdvcmtpbmcgZ3JvdXAgbGFz dCBjYWxsIChXR0xDKSBmb3IgIk5ldHdvcmsgVGltZQo+IFNlY3VyaXR5IGZvciB0aGUgTmV0d29y ayBUaW1lIFByb3RvY29s4oCdLgogCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtaWV0Zi1udHAtdXNpbmctbnRzLWZvci1udHAvCj4gCj4gUGxlYXNlIHJldmlldyBhbmQg cHJvdmlkZSBjb21tZW50cyB0byB0aGUgbWFpbGluZyBsaXN0IGJ5IG5vIGxhdGVyIHRoYW4gMzEK PiBBdWd1c3QgMjAxNy4gRWFybGllciBjb21tZW50cyBhbmQgZGlzY3Vzc2lvbiB3b3VsZCBiZSBh cHByZWNpYXRlZC4gUGxlYXNlCj4gbm90ZSB0aGF0IHRoZSBjaGFpcnMgd2lsbCBiZSB1c2luZyB0 aGlzIFdHTEMgdG8gZGV0ZXJtaW5lIGNvbnNlbnN1cyB0byBtb3ZlCj4gdGhpcyBkb2N1bWVudCBm b3J3YXJkIHRvIHRoZSBJRVNHLiAKCkkgaGF2ZSBhIG1pbm9yIHJlbWFyay9xdWVzdGlvbjoKVGhl IGludHJvZHVjdGlvbiBzdGF0ZXMgdGhhdCBjZXJ0YWluIHNlY3Rpb25zIG9mIHRoZSBkcmFmdCBt YXkgYmUgYXBwbGljYWJsZSAKdG8gb3RoZXIgdGltZSBzeW5jaHJvbml6YXRpb24gcHJvdG9jb2xz LCBQVFAgc3BlY2lmaWNhbGx5LiBJbiBTZWN0aW9uIDEuMiB0aGlzIAppZGVhIGlzIHByZXNlbnRl ZCBzbGlnaHRseSBtb3JlIGRldGFpbGVkIHNheWluZyB0aGF0IHRoZSBOVFMgS2V5IEVzdGFibGlz aG1lbnQgCm1pZ2h0IGJlIGV4dGVuZGVkIHRvIFBUUC4gQ29uc2lkZXJpbmcgdGhhdCBOVFMgZG9l cyBub3Qgc3VwcG9ydCBicm9hZGNhc3QgCmNvbW11bmljYXRpb24gKGFzIHN0YXRlZCBpbiBTZWN0 aW9uIDEuMikgYW5kIFBUUCBieSBkZWZhdWx0IHJlbGllcyBvbiAKbXVsdGljYXN0IGNvbW11bmlj YXRpb24sIEkgYW0gd29uZGVyaW5nIHdoeSB0aGlzIHZhZ3VlIGZ1dHVyZSBleHRlbnNpb24gaXMg CmluY2x1ZGVkIGluIHRoZSBkcmFmdCwgYWx0aG91Z2ggaXQgbWF5IG5vdCBldmVuIGJlIGZlYXNp YmxlLiAKCgpCZXN0LApSb2JlcnQKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fCm50cCBtYWlsaW5nIGxpc3QKbnRwQGlldGYub3JnCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbnRwCg== From nobody Tue Aug 29 11:26:04 2017 Return-Path: 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 7B1DC132D76 for ; Tue, 29 Aug 2017 11:26:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 S6OXizFAxnia for ; Tue, 29 Aug 2017 11:26:00 -0700 (PDT) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (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 F0976132C48 for ; Tue, 29 Aug 2017 11:25:59 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id a80so2535034wma.0 for ; Tue, 29 Aug 2017 11:25:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=gErojGuckUH2k/kQF0HJ2BrezO/iTB2qhG1sBp3xgQY=; b=gGtJtU1j4z8CoqvMmM6g5vcVaEZpq1Q//P/V0Tn0/GDEGuVR18pBpjtALQAUvFvenT MPLUQK3tMudCW4k+v0JXtjiJKBOznPN1CrbnrUhX4Uwq4QjmDunrMugbwwrsIP7xoOs5 eolx3peSbHU7AGukbsj9DCs4lOP6n+HWwdrIWp5UE8w8mU57lZzy66RAwbYJvwrPGyTg /5dPkvWmsxaERwx6tBUqf81b8+I/wbNhwJheslbAb4x7yxk7nL4tf+faI23YH2RG19oP 1zimyYTRGD/92KkTQnOax+iQ4ugzDBkdjgAcPhy8VetTOr/Rej5o47CrBC+/bCW/WBbw 80aw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=gErojGuckUH2k/kQF0HJ2BrezO/iTB2qhG1sBp3xgQY=; b=p7DeIRE5z9kBcBbAxLpuZWtMUKd0X7zM2msVOToNUl+88bADDaAK5tZUddAY+zZnTy KK1hZcJn5gvBa5/vuWx+Vn2rf2+6PH1+juuWYL+88ihMdzy9CLAIGKx0117jBG0O2jBQ 4BsQjVtVAul+flHAQFILQxPwO9dpWX21TqVe5n+zVz0dYZoclUN4LYCUXLEUYm7N8JgH /9Q3uEtMgSocVvc5T1/gGHDGChfrLPFNF/enDscTHAWMKUBRfhgCxzLNhE6Jyzj70/aL SHbJAxApvg7VuNZuT2vObS3ZP6gpSz35rx8ghTar6vkYrlHXF6lL3YETJviKh4d87VFT equQ== X-Gm-Message-State: AHYfb5inYAJx6WFE19LW0qbK91T2qQTBlHkXMX1JXSzcvGkqNU83hbvV R3pAAqxa/4LdGYXv56oOAAER1xZSwjBS X-Received: by 10.80.240.149 with SMTP id v21mr4447318edl.54.1504031158161; Tue, 29 Aug 2017 11:25:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.157.140 with HTTP; Tue, 29 Aug 2017 11:25:57 -0700 (PDT) In-Reply-To: <70a0c971b2978.598d965e@ostfalia.de> References: <70a0c971b2978.598d965e@ostfalia.de> From: Daniel Franke Date: Tue, 29 Aug 2017 14:25:57 -0400 Message-ID: To: Martin Langer Cc: ntp@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Ntp] some comments on the NTS4NTP-Draft09 X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Aug 2017 18:26:02 -0000 Sorry for overlooking this earlier. On 8/11/17, Martin Langer wrote: > 1. confusing term "ntp/4" > ----------------------------------------- > "ntp/4" is the same term as in the TLS ALPN extension (see: page 18, chapter > 8): > > [...] IANA is requested to allocate the following two entries in the > Application-Layer Protocol Negotation (ALPN) Protocol IDs registry: [...] > Protocol: Network Time Protocol, version 4 Identification Sequence: 0x6E > 0x74 0x70 0x2F 0x34 ("ntp/4") [...] > > But the NTS Next Protocol Negotiation record contains IDs (e.g. 0x00 for > 'Network Time Protocol version 4'; see table at page 21) and not the term > 'ntp/4'. This can confusing some readers. Yup, this is an outright error. I'll fix it in Git momentarily. > 2. Network Byte Order / Host Byte Order > 3. general comment > ----------- > My first thought was: why? At first it was a magic number for me. The > solution is here: chapter 5.2: > [...] and MUST begin with the two-octet Protocol ID which was negotiated as > a Next Protocol. [...] > > I think this should be mentioned again or referenced to the corresponding > table (chapter 8). I'll edit to clarify these. > 4. general comment > ============================================================ > > page 13 (chapter 6.5, 2nd section): > ----------------------------------------- > [...] This length requirement serves to ensure that the response will not be > larger than the request, in order to improve timekeeping precision and > [...] > > > remark: > ----------- > Does it really improve the timekeeping? I think the idea is to reduce the > asymmetry if the request and response message have the same size. > But client and server may have different performance and therefore the > processing speed per NTP Package is different too. ...it's just a thought I'm led to believe Prof. Mills did some experiments at one point and found a non-zero impact from using asymmetrically-sized packets. I guess a citation here would help. Harlan/Dave, do you know of any academic reference I can point at to support this claim? > 5. alternative proposal > ============================================================ > > page 20 (chapter 8, 1st section): > ----------------------------------------- > [...] Type Number (REQUIRED): An integer in the range 0-32767 inclusive > [...] > > > better?: > ----------- > [...] Type Number (REQUIRED): An 15 bit integer in the range 0-32767 > inclusive [...] > > ....not 16 bit, because we use a critical bit in our records (first bit) I disagree that this is an improvement. At best it's redundant since 0-32767 already covers the full range of possible 15-bit values. But more importantly, we should be maintaining separation of concerns between the IANA registry and the protocol specs which make reference to it. IANA is just recording the number. It's up to protocol specification to define how it should be encoded. > 6. some problems with 'The NTS Authenticator and Encrypted Extensions > extension' (page 14, chapter 6.6) > ============================================================ > > field description: > ----------------------------------------- > 'Nonce lenght': We should mention that the value is to be interpreted as > 'unsigned int'. I agree. I've just changed this in git. > 'Nonce': At first I had some trouble to understand where the nonce comes > from and which length we use. Now I know it, but maybe we should add some > more information to this field. > perhaps from these: [...] Nonce: a nonce as required by the negotiated AEAD > Algorithm. [...] to these: [...] Nonce: a new generated nonce whose length > and format is determined by the negotiated AEAD algorithm (RFC 5116, chapter > 3.2). [...] I don't quite like the wording you propose but I'll see if I can make some clarification along those lines. > 'Chipertext': Some readers (students in my team) had difficulties to > understand this field. All of them thought, that this field contains an > encrypted version of the whole NTP package. And this is wrong. I think the > problem is this line: [...] authentication tag in addition to the actual > ciphertext. [...]. Well, if readers do not know exactly how AEAD works, then > this leads to strong understanding problems at this point, since the terms > 'authentication tag' and 'ciphertext' seem not known. I think we should add > a reference (RFC 5116 --> AEAD) or some information about this terms > ('authentication tag' is like a MAC and 'ciphertext' contains optional > Extension Fields and can be absent if no Extension Fields are encrypted.). > Maybe confuses the field name 'Chipertext' too. The use of 'ciphertext' here comes straight out of RFC 5116, which in turn comes out of Rogaway's 2002 paper in which he coins "AEAD". I agree it's a little confusing if you're not steeped in the relevant literature but I think any departure from the RFC 5116 terminology would do more harm than good. > > > 'Padding:' This line: [...] so that implementations can unambiguously > delimit the end of the ciphertext from the start of the padding [...] can be > difficult to. In the beginning I did not know how this should work. We > should say that implementations can read the last octet of this extension > content, to find out how big the padding is. Fair enough. > Furthermore we should change this line: > [...] requirement that (in the absence of a legacy MAC) extensions have a > total length in octets (including the four octets for the type and length > fields) [...] > > in this: > [...] requirement that (in the absence of a legacy MAC) NTP extensions have > a total length in octets (including the four octets for the type and length > fields) [...] This interacts somewhat with Harlan's request to say "extension field" rather than just "extension". I've done that now, and I'll go through RFC 7822 again to make sure we're using consistent terminology in this and other places. > [...] P: The plaintext SHALL consist of all (if any) extensions to be > encrypted. [...] > > Which format? Typical NTPv4 Extension Fields or another format? We should > define that. We should also mention that only this content is encrypted (not > the content of parameter 'A'). > If we don't want encrypt anything (default case), then this parameter is > empty. Typcial NTPv4 EFs. I'll add a sentence or two to clarify this. > Please let me know if you have problems to understand my *english*. Your English is completely fine. From ntp-bounces@ietf.org Tue Aug 29 11:26:05 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D34AB132D76; Tue, 29 Aug 2017 11:26:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1504031164; bh=jImU+C6618MuRAoPrfApSYHiu76xWqk+NJ3UMhQtNlk=; h=In-Reply-To:References:From:Date:To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc; b=C5sUPysmKTpQ7bwR4n3JdLhJbeCqcEe4GtnOZNXrXd9JAB7YNQLfLw3SfMVE2gQjZ tcBhloB+IHmloFse660PvXI6VsiG53KTW75IjHKQ1luu70RRq1xIfpAMGTjQwx3z6g 9yZqexBO6qHywXfZIm3o5EmmSlLskMWxng0WohB8= 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 7B1DC132D76 for ; Tue, 29 Aug 2017 11:26:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 S6OXizFAxnia for ; Tue, 29 Aug 2017 11:26:00 -0700 (PDT) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (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 F0976132C48 for ; Tue, 29 Aug 2017 11:25:59 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id a80so2535034wma.0 for ; Tue, 29 Aug 2017 11:25:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=gErojGuckUH2k/kQF0HJ2BrezO/iTB2qhG1sBp3xgQY=; b=gGtJtU1j4z8CoqvMmM6g5vcVaEZpq1Q//P/V0Tn0/GDEGuVR18pBpjtALQAUvFvenT MPLUQK3tMudCW4k+v0JXtjiJKBOznPN1CrbnrUhX4Uwq4QjmDunrMugbwwrsIP7xoOs5 eolx3peSbHU7AGukbsj9DCs4lOP6n+HWwdrIWp5UE8w8mU57lZzy66RAwbYJvwrPGyTg /5dPkvWmsxaERwx6tBUqf81b8+I/wbNhwJheslbAb4x7yxk7nL4tf+faI23YH2RG19oP 1zimyYTRGD/92KkTQnOax+iQ4ugzDBkdjgAcPhy8VetTOr/Rej5o47CrBC+/bCW/WBbw 80aw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=gErojGuckUH2k/kQF0HJ2BrezO/iTB2qhG1sBp3xgQY=; b=p7DeIRE5z9kBcBbAxLpuZWtMUKd0X7zM2msVOToNUl+88bADDaAK5tZUddAY+zZnTy KK1hZcJn5gvBa5/vuWx+Vn2rf2+6PH1+juuWYL+88ihMdzy9CLAIGKx0117jBG0O2jBQ 4BsQjVtVAul+flHAQFILQxPwO9dpWX21TqVe5n+zVz0dYZoclUN4LYCUXLEUYm7N8JgH /9Q3uEtMgSocVvc5T1/gGHDGChfrLPFNF/enDscTHAWMKUBRfhgCxzLNhE6Jyzj70/aL SHbJAxApvg7VuNZuT2vObS3ZP6gpSz35rx8ghTar6vkYrlHXF6lL3YETJviKh4d87VFT equQ== X-Gm-Message-State: AHYfb5inYAJx6WFE19LW0qbK91T2qQTBlHkXMX1JXSzcvGkqNU83hbvV R3pAAqxa/4LdGYXv56oOAAER1xZSwjBS X-Received: by 10.80.240.149 with SMTP id v21mr4447318edl.54.1504031158161; Tue, 29 Aug 2017 11:25:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.157.140 with HTTP; Tue, 29 Aug 2017 11:25:57 -0700 (PDT) In-Reply-To: <70a0c971b2978.598d965e@ostfalia.de> References: <70a0c971b2978.598d965e@ostfalia.de> From: Daniel Franke Date: Tue, 29 Aug 2017 14:25:57 -0400 Message-ID: To: Martin Langer Archived-At: Subject: Re: [Ntp] some comments on the NTS4NTP-Draft09 X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: ntp@ietf.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ntp-bounces@ietf.org Sender: "ntp" Sorry for overlooking this earlier. On 8/11/17, Martin Langer wrote: > 1. confusing term "ntp/4" > ----------------------------------------- > "ntp/4" is the same term as in the TLS ALPN extension (see: page 18, chapter > 8): > > [...] IANA is requested to allocate the following two entries in the > Application-Layer Protocol Negotation (ALPN) Protocol IDs registry: [...] > Protocol: Network Time Protocol, version 4 Identification Sequence: 0x6E > 0x74 0x70 0x2F 0x34 ("ntp/4") [...] > > But the NTS Next Protocol Negotiation record contains IDs (e.g. 0x00 for > 'Network Time Protocol version 4'; see table at page 21) and not the term > 'ntp/4'. This can confusing some readers. Yup, this is an outright error. I'll fix it in Git momentarily. > 2. Network Byte Order / Host Byte Order > 3. general comment > ----------- > My first thought was: why? At first it was a magic number for me. The > solution is here: chapter 5.2: > [...] and MUST begin with the two-octet Protocol ID which was negotiated as > a Next Protocol. [...] > > I think this should be mentioned again or referenced to the corresponding > table (chapter 8). I'll edit to clarify these. > 4. general comment > ============================================================ > > page 13 (chapter 6.5, 2nd section): > ----------------------------------------- > [...] This length requirement serves to ensure that the response will not be > larger than the request, in order to improve timekeeping precision and > [...] > > > remark: > ----------- > Does it really improve the timekeeping? I think the idea is to reduce the > asymmetry if the request and response message have the same size. > But client and server may have different performance and therefore the > processing speed per NTP Package is different too. ...it's just a thought I'm led to believe Prof. Mills did some experiments at one point and found a non-zero impact from using asymmetrically-sized packets. I guess a citation here would help. Harlan/Dave, do you know of any academic reference I can point at to support this claim? > 5. alternative proposal > ============================================================ > > page 20 (chapter 8, 1st section): > ----------------------------------------- > [...] Type Number (REQUIRED): An integer in the range 0-32767 inclusive > [...] > > > better?: > ----------- > [...] Type Number (REQUIRED): An 15 bit integer in the range 0-32767 > inclusive [...] > > ....not 16 bit, because we use a critical bit in our records (first bit) I disagree that this is an improvement. At best it's redundant since 0-32767 already covers the full range of possible 15-bit values. But more importantly, we should be maintaining separation of concerns between the IANA registry and the protocol specs which make reference to it. IANA is just recording the number. It's up to protocol specification to define how it should be encoded. > 6. some problems with 'The NTS Authenticator and Encrypted Extensions > extension' (page 14, chapter 6.6) > ============================================================ > > field description: > ----------------------------------------- > 'Nonce lenght': We should mention that the value is to be interpreted as > 'unsigned int'. I agree. I've just changed this in git. > 'Nonce': At first I had some trouble to understand where the nonce comes > from and which length we use. Now I know it, but maybe we should add some > more information to this field. > perhaps from these: [...] Nonce: a nonce as required by the negotiated AEAD > Algorithm. [...] to these: [...] Nonce: a new generated nonce whose length > and format is determined by the negotiated AEAD algorithm (RFC 5116, chapter > 3.2). [...] I don't quite like the wording you propose but I'll see if I can make some clarification along those lines. > 'Chipertext': Some readers (students in my team) had difficulties to > understand this field. All of them thought, that this field contains an > encrypted version of the whole NTP package. And this is wrong. I think the > problem is this line: [...] authentication tag in addition to the actual > ciphertext. [...]. Well, if readers do not know exactly how AEAD works, then > this leads to strong understanding problems at this point, since the terms > 'authentication tag' and 'ciphertext' seem not known. I think we should add > a reference (RFC 5116 --> AEAD) or some information about this terms > ('authentication tag' is like a MAC and 'ciphertext' contains optional > Extension Fields and can be absent if no Extension Fields are encrypted.). > Maybe confuses the field name 'Chipertext' too. The use of 'ciphertext' here comes straight out of RFC 5116, which in turn comes out of Rogaway's 2002 paper in which he coins "AEAD". I agree it's a little confusing if you're not steeped in the relevant literature but I think any departure from the RFC 5116 terminology would do more harm than good. > > > 'Padding:' This line: [...] so that implementations can unambiguously > delimit the end of the ciphertext from the start of the padding [...] can be > difficult to. In the beginning I did not know how this should work. We > should say that implementations can read the last octet of this extension > content, to find out how big the padding is. Fair enough. > Furthermore we should change this line: > [...] requirement that (in the absence of a legacy MAC) extensions have a > total length in octets (including the four octets for the type and length > fields) [...] > > in this: > [...] requirement that (in the absence of a legacy MAC) NTP extensions have > a total length in octets (including the four octets for the type and length > fields) [...] This interacts somewhat with Harlan's request to say "extension field" rather than just "extension". I've done that now, and I'll go through RFC 7822 again to make sure we're using consistent terminology in this and other places. > [...] P: The plaintext SHALL consist of all (if any) extensions to be > encrypted. [...] > > Which format? Typical NTPv4 Extension Fields or another format? We should > define that. We should also mention that only this content is encrypted (not > the content of parameter 'A'). > If we don't want encrypt anything (default case), then this parameter is > empty. Typcial NTPv4 EFs. I'll add a sentence or two to clarify this. > Please let me know if you have problems to understand my *english*. Your English is completely fine. _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp From nobody Tue Aug 29 12:39:58 2017 Return-Path: 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 80AB7132D7D for ; Tue, 29 Aug 2017 12:39:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.799 X-Spam-Level: X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.377, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 PT5F5auS3SrN for ; Tue, 29 Aug 2017 12:39:54 -0700 (PDT) Received: from mx1.bs.ptb.de (mx1.bs.ptb.de [IPv6:2001:638:610:bd01::120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45D5C1329E3 for ; Tue, 29 Aug 2017 12:39:54 -0700 (PDT) Received: from smtp-hub.bs.ptb.de (smtpint01.bs.ptb.de [141.25.87.32]) by mx1.bs.ptb.de with ESMTP id v7TJdqoT012789-v7TJdqoV012789 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 29 Aug 2017 21:39:52 +0200 Received: from rose.bs.ptb.de (rose.bs.ptb.de [141.25.85.201]) by smtp-hub.bs.ptb.de (Postfix) with ESMTPS id 6C280533D09; Tue, 29 Aug 2017 21:39:52 +0200 (CEST) X-Disclaimed: 1 MIME-Version: 1.0 Sensitivity: Importance: Normal X-Priority: 3 (Normal) In-Reply-To: <19062708.TpRPKSgBD8@eris> References: <19062708.TpRPKSgBD8@eris>, <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> From: kristof.teichel@ptb.de To: Robert Annessi Cc: ntp@ietf.org Message-ID: Date: Tue, 29 Aug 2017 21:39:50 +0200 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Archived-At: Subject: [Ntp] Antwort: Re: WGLC for draft-ietf-ntp-using-nts-for-ntp X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Aug 2017 19:39:57 -0000

-----"ntp" <ntp-bounces@ietf.org> schrieb= : -----

>An: ntp@ietf.org
>Von: Robert Annessi
>Gesendet von: "n= tp"
>Datum: 29.08.2017 15:52
>Betreff: Re: [Ntp] WGLC for draf= t-ietf-ntp-using-nts-for-ntp
>
>Hi all,
>
>On Wedne= sday 09 August 2017 04:41:25 Karen O'Donoghue wrote:
>> This begin= s a three week working group last call (WGLC) for
>"Network Time
&= gt;> Security for the Network Time Protocol”.
>
>>= https://datatracker.ietf.org/doc/draft-ietf-ntp-us= ing-nts-for-ntp/
>>
>> Please review and provide com= ments to the mailing list by no later
>than 31
>> August 201= 7. Earlier comments and discussion would be appreciated.
>Please
&= gt;> note that the chairs will be using this WGLC to determine consensus=
>to move
>> this document forward to the IESG.
>
= >I have a minor remark/question:
>The introduction states that cer= tain sections of the draft may be
>applicable
>to other time s= ynchronization protocols, PTP specifically. In Section
>1.2 this
= >idea is presented slightly more detailed saying that the NTS Key
>= ;Establishment
>might be extended to PTP. Considering that NTS does = not support
>broadcast
>communication (as stated in Section 1.= 2) and PTP by default relies on
>
>multicast communication, I a= m wondering why this vague future
>extension is
>included in t= he draft, although it may not even be feasible.
>
>
>Bes= t,
>Robert

I knew there was something that I had w= anted to contribute to the discussion for a long time but just kind of forg= otten.
This was it. 

I agree that t= his is a problem in the text, and I vote for taking out all passages that s= pecifically mention PTP in this context.

>
>=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
>ntp mai= ling list
>ntp@ie= tf.org
>https://www.ietf.org/mailman/listinfo/ntp
>
 From ntp-bounces@ietf.org Tue Aug 29 12:39:58 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 642BF132D7D; Tue, 29 Aug 2017 12:39:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1504035598; bh=T2Jf19+4aLO8649MlUX6D3GPW7sT/dz+XIyVnTa0ezo=; h=In-Reply-To:References:From:To:Date:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc; b=bF9P4TyoCrrf3SryVkT+BLwFUF5GDHf0b2xkcIF/uxBQF1LdUWel9bgC7SuBkMOdt bsmZ4waXXxOvEYk/tPjX03m/cYM4nA8xCxHyRnaCupkOCrp6YwYToBal2NxIofr6LY 68DogJyfnjTcSs7jMjQbb10Oxh25/PibDE1gQKlg= 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 80AB7132D7D for ; Tue, 29 Aug 2017 12:39:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.799 X-Spam-Level: X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.377, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 PT5F5auS3SrN for ; Tue, 29 Aug 2017 12:39:54 -0700 (PDT) Received: from mx1.bs.ptb.de (mx1.bs.ptb.de [IPv6:2001:638:610:bd01::120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45D5C1329E3 for ; Tue, 29 Aug 2017 12:39:54 -0700 (PDT) Received: from smtp-hub.bs.ptb.de (smtpint01.bs.ptb.de [141.25.87.32]) by mx1.bs.ptb.de with ESMTP id v7TJdqoT012789-v7TJdqoV012789 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 29 Aug 2017 21:39:52 +0200 Received: from rose.bs.ptb.de (rose.bs.ptb.de [141.25.85.201]) by smtp-hub.bs.ptb.de (Postfix) with ESMTPS id 6C280533D09; Tue, 29 Aug 2017 21:39:52 +0200 (CEST) X-Disclaimed: 1 MIME-Version: 1.0 Sensitivity: Importance: Normal X-Priority: 3 (Normal) In-Reply-To: <19062708.TpRPKSgBD8@eris> References: <19062708.TpRPKSgBD8@eris>, <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> From: kristof.teichel@ptb.de To: Robert Annessi Message-ID: Date: Tue, 29 Aug 2017 21:39:50 +0200 Archived-At: Subject: [Ntp] Antwort: Re: WGLC for draft-ietf-ntp-using-nts-for-ntp X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: ntp@ietf.org Content-Type: multipart/mixed; boundary="===============4402832909413919573==" Errors-To: ntp-bounces@ietf.org Sender: "ntp" --===============4402832909413919573== Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1

-----"ntp" <ntp-bounces@ietf.org> schrieb= : -----

>An: ntp@ietf.org
>Von: Robert Annessi
>Gesendet von: "n= tp"
>Datum: 29.08.2017 15:52
>Betreff: Re: [Ntp] WGLC for draf= t-ietf-ntp-using-nts-for-ntp
>
>Hi all,
>
>On Wedne= sday 09 August 2017 04:41:25 Karen O'Donoghue wrote:
>> This begin= s a three week working group last call (WGLC) for
>"Network Time
&= gt;> Security for the Network Time Protocol”.
>
>>= https://datatracker.ietf.org/doc/draft-ietf-ntp-us= ing-nts-for-ntp/
>>
>> Please review and provide com= ments to the mailing list by no later
>than 31
>> August 201= 7. Earlier comments and discussion would be appreciated.
>Please
&= gt;> note that the chairs will be using this WGLC to determine consensus=
>to move
>> this document forward to the IESG.
>
= >I have a minor remark/question:
>The introduction states that cer= tain sections of the draft may be
>applicable
>to other time s= ynchronization protocols, PTP specifically. In Section
>1.2 this
= >idea is presented slightly more detailed saying that the NTS Key
>= ;Establishment
>might be extended to PTP. Considering that NTS does = not support
>broadcast
>communication (as stated in Section 1.= 2) and PTP by default relies on
>
>multicast communication, I a= m wondering why this vague future
>extension is
>included in t= he draft, although it may not even be feasible.
>
>
>Bes= t,
>Robert

I knew there was something that I had w= anted to contribute to the discussion for a long time but just kind of forg= otten.
This was it. 

I agree that t= his is a problem in the text, and I vote for taking out all passages that s= pecifically mention PTP in this context.

>
>=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
>ntp mai= ling list
>ntp@ie= tf.org
>https://www.ietf.org/mailman/listinfo/ntp
>
 --===============4402832909413919573== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp --===============4402832909413919573==-- From ntp-bounces@ietf.org Tue Aug 29 12:55:57 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 23B7D132C47; Tue, 29 Aug 2017 12:55:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1504036557; bh=dqM452ua4dvSD2bQ7pnAZt0GIMPj08xyAEsevv05ee4=; h=In-Reply-To:References:From:Date:To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc; b=XTTbt5uWGmTQKwunBsVhACdhMo1BYronpkck774REKXXAq+8vPUZx1mSPM5SkPZqH wOepfACTUx1boyDkI+/1/0zMuJE7e7cT8qBxjc7fu9cba4NYMOfZt/J4mOa2sWBv/+ 6F1/WlFR0yk/HS132S3KftXwJnpl4fKxoAeSRO4A= 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 E6613132C47 for ; Tue, 29 Aug 2017 12:55:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 Fq29RUJyktYG for ; Tue, 29 Aug 2017 12:55:54 -0700 (PDT) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (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 F12F6132812 for ; Tue, 29 Aug 2017 12:55:53 -0700 (PDT) Received: by mail-wm0-x22a.google.com with SMTP id u26so4296462wma.0 for ; Tue, 29 Aug 2017 12:55:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tKB9xVONgAH5O860s6S/pEhC0emFSjWr62MvXGA9HFw=; b=PysD1BehtDVWifx5scH03hKPToc7fflH6wNuohjmspk+OvtmAFT/rFN4K48osOmEA4 sCShJ07Fg5E6TupYtofzJkMK6l/8u3CgcGvkypkdTqBWpqltSImvaBOlv+zljtRWlNt7 Fx5z9MYXRHu3r9smz2sbv25gPnGm7ZdFp14SFRXZQYHzE0FoLtoCRjGaBOedh6AVLjc2 Y5xXikHccitLfoeg4tnfDqAps3giAH+4GiSJXNtT0lBTqiCY5jRLBi6Tbm1X+2h1RSIl bj3jWKow+lYSqciQbqgF2pNvHWU06IbVwCLqZFGm3quy9xiwkWvuL+JhC3bsYMYp9O/y lPZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tKB9xVONgAH5O860s6S/pEhC0emFSjWr62MvXGA9HFw=; b=bLdGfTqpxKzS7XlQDtoZ/ieTP/hhXB3dQugrTEQoj+B7HWs/lo/IdUVFUJAyHorFxg PAX2vu0u5bmTAgWvhAbkHYD9v39NxMlOXzfNsL9+prrbCmuPTKY72AKwpplooCZ5RtKD Ra3jBWjgQlnP7XR85+o2w0hs6d58Qbb10S2UoCaKklQFMexqB4dahcnddCYBh9NEGa4r JzWX7t7zFGQFbS4quyfwKUYtsgZDKFiQ++hdLC/Iju3ZdRgrxWeLWUXe7xaFC0Fr397l WcBv3SW112rQ4zIp9Kn60Kt8923qTI0tuW7j1QW93v7a7N68vE/gaT3K9IC6ZoIlcP2z sKmw== X-Gm-Message-State: AHYfb5g/HBV3wbgD/mExneQt4iVyCF1feUxXkKUE8mcj2qQZARQmbY73 v/LvbN+FPnZ3OT9xxFxmqFNBvwc9dw== X-Received: by 10.80.240.207 with SMTP id a15mr4444699edm.294.1504036552381; Tue, 29 Aug 2017 12:55:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.157.140 with HTTP; Tue, 29 Aug 2017 12:55:51 -0700 (PDT) In-Reply-To: References: <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> <19062708.TpRPKSgBD8@eris> From: Daniel Franke Date: Tue, 29 Aug 2017 15:55:51 -0400 Message-ID: To: kristof.teichel@ptb.de Archived-At: Subject: Re: [Ntp] Antwort: Re: WGLC for draft-ietf-ntp-using-nts-for-ntp X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: ntp@ietf.org, Robert Annessi Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ntp-bounces@ietf.org Sender: "ntp" On 8/29/17, kristof.teichel@ptb.de wrote: > I knew there was something that I had wanted to contribute to the discussion > for a long time but just kind of forgotten. > This was it. > > I agree that this is a problem in the text, and I vote for taking out all > passages that specifically mention PTP in this context. Well, you're the reason I had it there to begin with. I thought you and Dieter still had ambitions to get something working wrt PTP. If that's no longer the case then, without objection, I'll remove that reference from the intro. Besides the Terms and Abbreviations appendix, the only other reference to PTP is an IANA request to reserve NTS Next Protocol code 1 for use with PTP. Since we changed these codes from textual to numeric I guess there's no reason to keep that either; we can always request a new allocation once there's something concrete to attach to it. _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp From nobody Tue Aug 29 12:55:57 2017 Return-Path: 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 E6613132C47 for ; Tue, 29 Aug 2017 12:55:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 Fq29RUJyktYG for ; Tue, 29 Aug 2017 12:55:54 -0700 (PDT) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (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 F12F6132812 for ; Tue, 29 Aug 2017 12:55:53 -0700 (PDT) Received: by mail-wm0-x22a.google.com with SMTP id u26so4296462wma.0 for ; Tue, 29 Aug 2017 12:55:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tKB9xVONgAH5O860s6S/pEhC0emFSjWr62MvXGA9HFw=; b=PysD1BehtDVWifx5scH03hKPToc7fflH6wNuohjmspk+OvtmAFT/rFN4K48osOmEA4 sCShJ07Fg5E6TupYtofzJkMK6l/8u3CgcGvkypkdTqBWpqltSImvaBOlv+zljtRWlNt7 Fx5z9MYXRHu3r9smz2sbv25gPnGm7ZdFp14SFRXZQYHzE0FoLtoCRjGaBOedh6AVLjc2 Y5xXikHccitLfoeg4tnfDqAps3giAH+4GiSJXNtT0lBTqiCY5jRLBi6Tbm1X+2h1RSIl bj3jWKow+lYSqciQbqgF2pNvHWU06IbVwCLqZFGm3quy9xiwkWvuL+JhC3bsYMYp9O/y lPZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tKB9xVONgAH5O860s6S/pEhC0emFSjWr62MvXGA9HFw=; b=bLdGfTqpxKzS7XlQDtoZ/ieTP/hhXB3dQugrTEQoj+B7HWs/lo/IdUVFUJAyHorFxg PAX2vu0u5bmTAgWvhAbkHYD9v39NxMlOXzfNsL9+prrbCmuPTKY72AKwpplooCZ5RtKD Ra3jBWjgQlnP7XR85+o2w0hs6d58Qbb10S2UoCaKklQFMexqB4dahcnddCYBh9NEGa4r JzWX7t7zFGQFbS4quyfwKUYtsgZDKFiQ++hdLC/Iju3ZdRgrxWeLWUXe7xaFC0Fr397l WcBv3SW112rQ4zIp9Kn60Kt8923qTI0tuW7j1QW93v7a7N68vE/gaT3K9IC6ZoIlcP2z sKmw== X-Gm-Message-State: AHYfb5g/HBV3wbgD/mExneQt4iVyCF1feUxXkKUE8mcj2qQZARQmbY73 v/LvbN+FPnZ3OT9xxFxmqFNBvwc9dw== X-Received: by 10.80.240.207 with SMTP id a15mr4444699edm.294.1504036552381; Tue, 29 Aug 2017 12:55:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.157.140 with HTTP; Tue, 29 Aug 2017 12:55:51 -0700 (PDT) In-Reply-To: References: <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> <19062708.TpRPKSgBD8@eris> From: Daniel Franke Date: Tue, 29 Aug 2017 15:55:51 -0400 Message-ID: To: kristof.teichel@ptb.de Cc: Robert Annessi , ntp@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Ntp] Antwort: Re: WGLC for draft-ietf-ntp-using-nts-for-ntp X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Aug 2017 19:55:56 -0000 On 8/29/17, kristof.teichel@ptb.de wrote: > I knew there was something that I had wanted to contribute to the discussion > for a long time but just kind of forgotten. > This was it. > > I agree that this is a problem in the text, and I vote for taking out all > passages that specifically mention PTP in this context. Well, you're the reason I had it there to begin with. I thought you and Dieter still had ambitions to get something working wrt PTP. If that's no longer the case then, without objection, I'll remove that reference from the intro. Besides the Terms and Abbreviations appendix, the only other reference to PTP is an IANA request to reserve NTS Next Protocol code 1 for use with PTP. Since we changed these codes from textual to numeric I guess there's no reason to keep that either; we can always request a new allocation once there's something concrete to attach to it. From nobody Tue Aug 29 12:58:38 2017 Return-Path: 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 3BFB11329E3 for ; Tue, 29 Aug 2017 12:58:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 dNOGn_Wbqgw5 for ; Tue, 29 Aug 2017 12:58:35 -0700 (PDT) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (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 C708F132812 for ; Tue, 29 Aug 2017 12:58:34 -0700 (PDT) Received: by mail-wm0-x22a.google.com with SMTP id u26so4336715wma.0 for ; Tue, 29 Aug 2017 12:58:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fLoqwt30e5wj3QPaUZgoOL0SPn5DhlIpd1IDbSNQ5yo=; b=FHXfxUECM6+3fNMFNno2SeuHr+HMBw2HmY2a7fpNCSs2djGbjB3T1v0AIYFoDX3FyX 2EbPk43USREHLIJr5Oi2OmzOFSAT3Plew738xvQtWccgQ7uZtlWRz5MwXQnvlFAop3mj ubstibqKlguLWH2D277U1Hb530QCs7LGZhYh5RDoGi7BcsvwUaYmA5lLCqK0p7MF/lUw S/2iYPS05dmn9jZF52G6gJO+O05AxzBXU+yoLkzm2HHVlkbu0Xuic7BqTny6qSIC7Jj9 6MALkIpimYpCwiwe+FgJ1mLAU75zM9SNj998k9oeBCRmD54jjYWmYmwgf4qBobpGPfo0 bvZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=fLoqwt30e5wj3QPaUZgoOL0SPn5DhlIpd1IDbSNQ5yo=; b=Zw8nGtSKz5cAsNJcRNnj4gF1ukH13ToQ6marw4N7x3f1t/BtusIZL2U2wkBbyw2NbG AL7WahswByP3N0u4D7+dZgk5isHzqn8RUlycdktR4LwQ9D2Ubkh9yJ3Q+NxAT/WHF8Sa d+iFPtnPxWenkFawl+47It156C2Trz5driDOaRhtzOZ449PZYp6B82RcwhWvdXFzhh/L uadnveNc+16z4P3Fda/t3LzOkmgtBxxBtFyov/0lf+aQKbxMB2sxuxR95ulQzRYnVWD8 xEm1u1kyV0V7aDty8y9niZPGqYgsmXyrtaEBsPr0s+7mp2tnure2QFcWockVNCF+hDfL aoYQ== X-Gm-Message-State: AHYfb5gs0pBg3rTJwJmw5IWiqHoK4hG+GFCFCzOnBaKjpsnkDuTsRJae ttSZ/7T2uNPV9sQG40ZhvKJgtOnZWdMM X-Received: by 10.80.159.138 with SMTP id c10mr4532279edf.257.1504036713248; Tue, 29 Aug 2017 12:58:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.157.140 with HTTP; Tue, 29 Aug 2017 12:58:32 -0700 (PDT) In-Reply-To: References: <70a0c971b2978.598d965e@ostfalia.de> From: Daniel Franke Date: Tue, 29 Aug 2017 15:58:32 -0400 Message-ID: To: Martin Langer Cc: ntp@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Ntp] some comments on the NTS4NTP-Draft09 X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Aug 2017 19:58:37 -0000 On 8/29/17, Daniel Franke wrote: > I disagree that this is an improvement. At best it's redundant since > 0-32767 already covers the full range of possible 15-bit values. But > more importantly, we should be maintaining separation of concerns > between the IANA registry and the protocol specs which make reference > to it. IANA is just recording the number. It's up to protocol > specification to define how it should be encoded. I just realized that in some other entries I'm not following my own advice. I'll change those. From ntp-bounces@ietf.org Tue Aug 29 12:58:39 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 29BC11329E3; Tue, 29 Aug 2017 12:58:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1504036719; bh=suzXKqQkjYzr0BQ9Co7SVTl+nrxQOSJI+5UUBemGL9U=; h=In-Reply-To:References:From:Date:To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc; b=ije3TB2ThhITg18AJ6N+N6x5ePzea2F2UhxzshXL49yYj2b/TwiKkNenH5+hOYI4f 0Z/zc/OmbOr4YlKtAFhxjadyjb54bIbCocIujwlgt8hNHDqGIOer2ZphuZhIaPcxmZ lRpVUd6N9Gddlv4Wz3dPtiD1VlxRih5zjucqu0vE= 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 3BFB11329E3 for ; Tue, 29 Aug 2017 12:58:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 dNOGn_Wbqgw5 for ; Tue, 29 Aug 2017 12:58:35 -0700 (PDT) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (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 C708F132812 for ; Tue, 29 Aug 2017 12:58:34 -0700 (PDT) Received: by mail-wm0-x22a.google.com with SMTP id u26so4336715wma.0 for ; Tue, 29 Aug 2017 12:58:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fLoqwt30e5wj3QPaUZgoOL0SPn5DhlIpd1IDbSNQ5yo=; b=FHXfxUECM6+3fNMFNno2SeuHr+HMBw2HmY2a7fpNCSs2djGbjB3T1v0AIYFoDX3FyX 2EbPk43USREHLIJr5Oi2OmzOFSAT3Plew738xvQtWccgQ7uZtlWRz5MwXQnvlFAop3mj ubstibqKlguLWH2D277U1Hb530QCs7LGZhYh5RDoGi7BcsvwUaYmA5lLCqK0p7MF/lUw S/2iYPS05dmn9jZF52G6gJO+O05AxzBXU+yoLkzm2HHVlkbu0Xuic7BqTny6qSIC7Jj9 6MALkIpimYpCwiwe+FgJ1mLAU75zM9SNj998k9oeBCRmD54jjYWmYmwgf4qBobpGPfo0 bvZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=fLoqwt30e5wj3QPaUZgoOL0SPn5DhlIpd1IDbSNQ5yo=; b=Zw8nGtSKz5cAsNJcRNnj4gF1ukH13ToQ6marw4N7x3f1t/BtusIZL2U2wkBbyw2NbG AL7WahswByP3N0u4D7+dZgk5isHzqn8RUlycdktR4LwQ9D2Ubkh9yJ3Q+NxAT/WHF8Sa d+iFPtnPxWenkFawl+47It156C2Trz5driDOaRhtzOZ449PZYp6B82RcwhWvdXFzhh/L uadnveNc+16z4P3Fda/t3LzOkmgtBxxBtFyov/0lf+aQKbxMB2sxuxR95ulQzRYnVWD8 xEm1u1kyV0V7aDty8y9niZPGqYgsmXyrtaEBsPr0s+7mp2tnure2QFcWockVNCF+hDfL aoYQ== X-Gm-Message-State: AHYfb5gs0pBg3rTJwJmw5IWiqHoK4hG+GFCFCzOnBaKjpsnkDuTsRJae ttSZ/7T2uNPV9sQG40ZhvKJgtOnZWdMM X-Received: by 10.80.159.138 with SMTP id c10mr4532279edf.257.1504036713248; Tue, 29 Aug 2017 12:58:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.157.140 with HTTP; Tue, 29 Aug 2017 12:58:32 -0700 (PDT) In-Reply-To: References: <70a0c971b2978.598d965e@ostfalia.de> From: Daniel Franke Date: Tue, 29 Aug 2017 15:58:32 -0400 Message-ID: To: Martin Langer Archived-At: Subject: Re: [Ntp] some comments on the NTS4NTP-Draft09 X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: ntp@ietf.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ntp-bounces@ietf.org Sender: "ntp" On 8/29/17, Daniel Franke wrote: > I disagree that this is an improvement. At best it's redundant since > 0-32767 already covers the full range of possible 15-bit values. But > more importantly, we should be maintaining separation of concerns > between the IANA registry and the protocol specs which make reference > to it. IANA is just recording the number. It's up to protocol > specification to define how it should be encoded. I just realized that in some other entries I'm not following my own advice. I'll change those. _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp From nobody Tue Aug 29 13:08:00 2017 Return-Path: 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 03ECE1321D8 for ; Tue, 29 Aug 2017 13:07:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.8 X-Spam-Level: X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.377, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no 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 FfP4brIDFjw5 for ; Tue, 29 Aug 2017 13:07:58 -0700 (PDT) Received: from mx1.bs.ptb.de (mx1.bs.ptb.de [IPv6:2001:638:610:bd01::120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05C9E1321B0 for ; Tue, 29 Aug 2017 13:07:57 -0700 (PDT) Received: from smtp-hub.bs.ptb.de (smtpint01.bs.ptb.de [141.25.87.32]) by mx1.bs.ptb.de with ESMTP id v7TK7t56013947-v7TK7t58013947 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 29 Aug 2017 22:07:55 +0200 Received: from rose.bs.ptb.de (rose.bs.ptb.de [141.25.85.201]) by smtp-hub.bs.ptb.de (Postfix) with ESMTPS id DF0E9533D0F; Tue, 29 Aug 2017 22:07:54 +0200 (CEST) MIME-Version: 1.0 X-Disclaimed: 1 Sensitivity: Importance: Normal X-Priority: 3 (Normal) In-Reply-To: References: , <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> <47b5b4e3-41c9-6779-4a96-b11650483499@nwtime.org> From: kristof.teichel@ptb.de To: Daniel Franke Cc: Harlan Stenn , ntp@ietf.org Message-ID: Date: Tue, 29 Aug 2017 22:07:52 +0200 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Archived-At: Subject: [Ntp] Antwort: Re: WGLC for draft-ietf-ntp-using-nts-for-ntp X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Aug 2017 20:07:59 -0000 Hello all,=

<= /font>
= please forgive my patchwork approach to this discussion. 
=
I am having = some trouble making time for an extensive wall of text.

(Harlan)
>> - "As previously stated, DTLS-encapsulated NTPv4 is trivial= ."  Again,
>> please note exactly what mode(s) are using= this method, and expressly
>> note that DTLS-encapsulated NTP tra= ffic will show more timing jitter and
>> be less accurate than nor= mal NTPv4 UDP traffic.  While interleave mode
>> was inadvert= ently left out of RFC5905, it is likely the best way to
>> attempt= to mitigate the jitter problems created by DTLS-encapsulated
>> N= TPv4.  However, it is not yet clear that there is any way to easily>> capture the packet receive or transmit timestamps in a DTLS-encap= sulated
>> transport.
>
(Daniel)
>DTLS doesn't do = any flow control or group or split any
>packets. Getting timestamps f= or a DTLS packet is literally no
>different than for any other.

Historically, encapsulation is an overall con= cept that has been argued against a lot in the course of NTS (as far as I'v= e witnessed it).
Therefore, I thin= k that a paragraph of discussion on the presumed negligibiliy of the precis= ion loss with DTLS-encapsulation is warranted.

Especially in the case of transmit timestamps (where every = cryptographic operation takes place between the reading of the timestamp an= d the actual time of transmission that the timestamp was supposed to measur= e), perhaps it should at least be mentioned why this encapsulation is not s= ignificantly more expensive than e.g. adding a MAC/AEAD value.
=

One thing I really don't know, however, is where such a piece of text shou= ld be placed in order to not distort the core specification text (I don't t= hink anyone wants to or should have to read a passage about the design deci= sion process in the middle of the instructions on how to do the DTLS-encaps= ulation).
From ntp-bounces@ietf.org Tue Aug 29 13:08:00 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CC662132A89; Tue, 29 Aug 2017 13:08:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1504037280; bh=/Bi8jAD3vNiDnDQh/6KoZp/ctaa4BtE6+BmWG0jn9u0=; h=In-Reply-To:References:From:To:Date:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc; b=aAJq4LerSuAlZp7IOqZe2vBqQldJFMuTKbA17mIgdqEL2ZofhlB5WtWVDdkRUCXuc IVcGzBLba03NM6IAdprcKaZ9NeF1shNwTcSyIbCgJD23nBveghLLJKAdF/zbk9o6z/ 3GgoM8HZ8Se/CIGO0a/qUYqhMdTfu0C3nj1t9Mvw= 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 03ECE1321D8 for ; Tue, 29 Aug 2017 13:07:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.8 X-Spam-Level: X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.377, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no 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 FfP4brIDFjw5 for ; Tue, 29 Aug 2017 13:07:58 -0700 (PDT) Received: from mx1.bs.ptb.de (mx1.bs.ptb.de [IPv6:2001:638:610:bd01::120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05C9E1321B0 for ; Tue, 29 Aug 2017 13:07:57 -0700 (PDT) Received: from smtp-hub.bs.ptb.de (smtpint01.bs.ptb.de [141.25.87.32]) by mx1.bs.ptb.de with ESMTP id v7TK7t56013947-v7TK7t58013947 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 29 Aug 2017 22:07:55 +0200 Received: from rose.bs.ptb.de (rose.bs.ptb.de [141.25.85.201]) by smtp-hub.bs.ptb.de (Postfix) with ESMTPS id DF0E9533D0F; Tue, 29 Aug 2017 22:07:54 +0200 (CEST) MIME-Version: 1.0 X-Disclaimed: 1 Sensitivity: Importance: Normal X-Priority: 3 (Normal) In-Reply-To: References: , <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> <47b5b4e3-41c9-6779-4a96-b11650483499@nwtime.org> From: kristof.teichel@ptb.de To: Daniel Franke Message-ID: Date: Tue, 29 Aug 2017 22:07:52 +0200 Archived-At: Subject: [Ntp] Antwort: Re: WGLC for draft-ietf-ntp-using-nts-for-ntp X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: ntp@ietf.org, Harlan Stenn Content-Type: multipart/mixed; boundary="===============3532010224979568839==" Errors-To: ntp-bounces@ietf.org Sender: "ntp" --===============3532010224979568839== Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Hello all,=

<= /font>
= please forgive my patchwork approach to this discussion. 
=
I am having = some trouble making time for an extensive wall of text.

(Harlan)
>> - "As previously stated, DTLS-encapsulated NTPv4 is trivial= ."  Again,
>> please note exactly what mode(s) are using= this method, and expressly
>> note that DTLS-encapsulated NTP tra= ffic will show more timing jitter and
>> be less accurate than nor= mal NTPv4 UDP traffic.  While interleave mode
>> was inadvert= ently left out of RFC5905, it is likely the best way to
>> attempt= to mitigate the jitter problems created by DTLS-encapsulated
>> N= TPv4.  However, it is not yet clear that there is any way to easily>> capture the packet receive or transmit timestamps in a DTLS-encap= sulated
>> transport.
>
(Daniel)
>DTLS doesn't do = any flow control or group or split any
>packets. Getting timestamps f= or a DTLS packet is literally no
>different than for any other.

Historically, encapsulation is an overall con= cept that has been argued against a lot in the course of NTS (as far as I'v= e witnessed it).
Therefore, I thin= k that a paragraph of discussion on the presumed negligibiliy of the precis= ion loss with DTLS-encapsulation is warranted.

Especially in the case of transmit timestamps (where every = cryptographic operation takes place between the reading of the timestamp an= d the actual time of transmission that the timestamp was supposed to measur= e), perhaps it should at least be mentioned why this encapsulation is not s= ignificantly more expensive than e.g. adding a MAC/AEAD value.
=

One thing I really don't know, however, is where such a piece of text shou= ld be placed in order to not distort the core specification text (I don't t= hink anyone wants to or should have to read a passage about the design deci= sion process in the middle of the instructions on how to do the DTLS-encaps= ulation).
--===============3532010224979568839== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp --===============3532010224979568839==-- From ntp-bounces@ietf.org Tue Aug 29 13:12:25 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D2255132D8D; Tue, 29 Aug 2017 13:12:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1504037544; bh=zSzEHq5gNhqt9JNa2uGQDQOaQQG44baz38cFRsIpjww=; h=In-Reply-To:References:From:To:Date:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc; b=gzgKDW+tNcvoW6it57dHA1EOJqfB8LKdF4C17eT5qNmKTt51sBIZPeJgRxV39tgFh moog+IJtEk2/Q1vIrwzJDwVQuXPQ8KCMib1cVaQkfW7ysj5BSOFZuv+yi5yYpFIqk/ fJsOyhwOxLAxbtnJgnkAP38u0OVqUoY+E6CwLj6o= 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 BAF00132D8D for ; Tue, 29 Aug 2017 13:12:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.799 X-Spam-Level: X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.377, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 ZJe96YnpCo5i for ; Tue, 29 Aug 2017 13:12:22 -0700 (PDT) Received: from mx1.bs.ptb.de (mx1.bs.ptb.de [IPv6:2001:638:610:bd01::120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8B40132D8E for ; Tue, 29 Aug 2017 13:12:21 -0700 (PDT) Received: from smtp-hub.bs.ptb.de (smtpint01.bs.ptb.de [141.25.87.32]) by mx1.bs.ptb.de with ESMTP id v7TKCJDW014060-v7TKCJDY014060 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 29 Aug 2017 22:12:20 +0200 Received: from rose.bs.ptb.de (rose.bs.ptb.de [141.25.85.201]) by smtp-hub.bs.ptb.de (Postfix) with ESMTPS id D3030533D10; Tue, 29 Aug 2017 22:12:19 +0200 (CEST) X-Disclaimed: 1 MIME-Version: 1.0 Sensitivity: Importance: Normal X-Priority: 3 (Normal) In-Reply-To: References: , <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> <19062708.TpRPKSgBD8@eris> From: kristof.teichel@ptb.de To: Daniel Franke Message-ID: Date: Tue, 29 Aug 2017 22:12:18 +0200 Archived-At: Subject: [Ntp] Antwort: Re: Antwort: Re: WGLC for draft-ietf-ntp-using-nts-for-ntp X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: ntp@ietf.org, Robert Annessi Content-Type: multipart/mixed; boundary="===============5747625290665913722==" Errors-To: ntp-bounces@ietf.org Sender: "ntp" --===============5747625290665913722== Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
-----"ntp"= <ntp-bounce= s@ietf.org> schrieb: -----
An: kristof.teichel@ptb.de
Vo= n: Daniel Franke 
Gesendet von: "ntp" 
Datum: 29.08.2017 21:55
Kopie: ntp@ietf.org, Robert Annessi <robert.a= nnessi@nt.tuwien.ac.at>
Betreff: Re: [Ntp] Antwort: Re: WGLC for = draft-ietf-ntp-using-nts-for-ntp

On 8/29/17, kristof.teichel@ptb.de <kristof.teichel@ptb.de> w= rote:
> I knew there was something that I had wanted to contribute to= the discussion
> for a long time but just kind of forgotten.
>= This was it.
>
> I agree that this is a problem in the text, a= nd I vote for taking out all
> passages that specifically mention PTP= in this context.

Well, you're the reason I had it there to begin wi= th. I thought you
and Dieter still had ambitions to get something workin= g wrt PTP. If
that's no longer the case then, without objection, I'll re= move that
reference from the intro.
<= /dfoxfranke@gmail.com>

While we do still ha= ve those ambitions you speak of, the measures that have made it into the cu= rrent NTS draft simply do not cover the essentials of what is needed for PT= P.
Therefore any mention of it could be seen as misleading and I believ= e we should avoid it.

Besides th= e Terms and Abbreviations appendix, the only other reference
to PTP is an IANA request to reserve NTS Next Pro= tocol code 1 for use
with PTP. Sinc= e we changed these codes from textual to numeric I guess
there's no reason to keep that either; we can always = request a new
allocation once there= 's something concrete to attach to it.

= Sounds good to me. Thanks.
 --===============5747625290665913722== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp --===============5747625290665913722==-- From nobody Tue Aug 29 13:12:25 2017 Return-Path: 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 BAF00132D8D for ; Tue, 29 Aug 2017 13:12:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.799 X-Spam-Level: X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.377, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 ZJe96YnpCo5i for ; Tue, 29 Aug 2017 13:12:22 -0700 (PDT) Received: from mx1.bs.ptb.de (mx1.bs.ptb.de [IPv6:2001:638:610:bd01::120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8B40132D8E for ; Tue, 29 Aug 2017 13:12:21 -0700 (PDT) Received: from smtp-hub.bs.ptb.de (smtpint01.bs.ptb.de [141.25.87.32]) by mx1.bs.ptb.de with ESMTP id v7TKCJDW014060-v7TKCJDY014060 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 29 Aug 2017 22:12:20 +0200 Received: from rose.bs.ptb.de (rose.bs.ptb.de [141.25.85.201]) by smtp-hub.bs.ptb.de (Postfix) with ESMTPS id D3030533D10; Tue, 29 Aug 2017 22:12:19 +0200 (CEST) X-Disclaimed: 1 MIME-Version: 1.0 Sensitivity: Importance: Normal X-Priority: 3 (Normal) In-Reply-To: References: , <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> <19062708.TpRPKSgBD8@eris> From: kristof.teichel@ptb.de To: Daniel Franke Cc: ntp@ietf.org, Robert Annessi Message-ID: Date: Tue, 29 Aug 2017 22:12:18 +0200 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Archived-At: Subject: [Ntp] Antwort: Re: Antwort: Re: WGLC for draft-ietf-ntp-using-nts-for-ntp X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Aug 2017 20:12:24 -0000
-----"ntp"= <ntp-bounce= s@ietf.org> schrieb: -----
An: kristof.teichel@ptb.de
Vo= n: Daniel Franke 
Gesendet von: "ntp" 
Datum: 29.08.2017 21:55
Kopie: ntp@ietf.org, Robert Annessi <robert.a= nnessi@nt.tuwien.ac.at>
Betreff: Re: [Ntp] Antwort: Re: WGLC for = draft-ietf-ntp-using-nts-for-ntp

On 8/29/17, kristof.teichel@ptb.de <kristof.teichel@ptb.de> w= rote:
> I knew there was something that I had wanted to contribute to= the discussion
> for a long time but just kind of forgotten.
>= This was it.
>
> I agree that this is a problem in the text, a= nd I vote for taking out all
> passages that specifically mention PTP= in this context.

Well, you're the reason I had it there to begin wi= th. I thought you
and Dieter still had ambitions to get something workin= g wrt PTP. If
that's no longer the case then, without objection, I'll re= move that
reference from the intro.
<= /dfoxfranke@gmail.com>

While we do still ha= ve those ambitions you speak of, the measures that have made it into the cu= rrent NTS draft simply do not cover the essentials of what is needed for PT= P.
Therefore any mention of it could be seen as misleading and I believ= e we should avoid it.

Besides th= e Terms and Abbreviations appendix, the only other reference
to PTP is an IANA request to reserve NTS Next Pro= tocol code 1 for use
with PTP. Sinc= e we changed these codes from textual to numeric I guess
there's no reason to keep that either; we can always = request a new
allocation once there= 's something concrete to attach to it.

= Sounds good to me. Thanks.
 From ntp-bounces@ietf.org Tue Aug 29 15:45:03 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DC15132B9B; Tue, 29 Aug 2017 15:45:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1504046703; bh=b1aOIfISuMNIlVejU8p9LWDN0r3rriQrdPRCjt4YFWA=; h=In-Reply-To:References:From:Date:To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc; b=N4qt6dreLzNWonPNk/SQmOxfUc8mGrwlS8XscGda45HkeZnrEIewUeQSCAvzxAKiL hi0wt/XLLIaIB+swfKixpI3FYIl+oBstDEQdvLVheHcS84c6iy+xuZF/lPjVHQwNln vhQHMhhpcFf6BVd2qfEf2KEO/v93t5CKNXD3/j1A= 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 64717132D9B for ; Tue, 29 Aug 2017 15:45:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 VvKmk7xzWW8q for ; Tue, 29 Aug 2017 15:44:59 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (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 6610F132D91 for ; Tue, 29 Aug 2017 15:44:56 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id t201so18644wmt.1 for ; Tue, 29 Aug 2017 15:44:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2JeSqfDA88k4z1IXgFeQe2awGFPQG4n02KL4aYOKC4g=; b=FBW20NpX+WmDEqVBI4SqsSfC203fuIoxOQkwKhpZzAdjehSLghcnDXwFglVkvrw35Z NsTKZ0DAiD+KAk+hzlkk+cjNiHlxMfZGyMSClA0qKifdyHLyjNffjYMjraV0GzlLiXGf 13RAgzvnTkCRRs5kUyKARB5kSA8ssruZ7EsR3NZxfM1wOTKa8nmVbe0/vYFRyh00fYye P6wVzX0PjSd6Pumd21Xmgjo3cxo8aoxjavVt5z1WJ4k2qEr5I+va1LNNX/wKb1HTOx+i VQQl67vCREW2vjnG25SiOT/649UtvI2D+JV0HdcolMPtx04OEAgU/D4eaZ56+BsJZotq U2Sw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=2JeSqfDA88k4z1IXgFeQe2awGFPQG4n02KL4aYOKC4g=; b=mxkEkOIbLy+4rVqkEwWDZngYmovoxQGs5l1qLXV4R377l5vbag67I1Ljgkf0ymUITT 1JnWmapV6aPk9qghuTsTySqc2ToFsE6k/T3IxPSQnfJgk64aWCCqH5TH6/GqygcG9qKX I2hhQprKNYDEOwKgOJU58QgGo5Txd3a1C+7xSIe20GEU0DBlfelA+kgMEAi2TUOnJfIn VYOa3vCPhc/nGX23R4zqVlRPXnI97KSyeoV6trOXOrFIKhJpCMdIG9Vjvn+BrtSw1IwA o71+tOo8BEzYV0YzTbQJgeT/98kEq9+FRBakeSrs0punUuNaA0AWFcu2R9xP9XhQ7Ftr DnPw== X-Gm-Message-State: AHYfb5jRQZINBGVkJQ9ajNdlnupqvop2wiweNszdZlWzVK7T89x9sag1 YKEuYU2NAbqwrB/oehCjCfIlIwSvob6sZIw= X-Received: by 10.80.240.207 with SMTP id a15mr4721902edm.294.1504046694731; Tue, 29 Aug 2017 15:44:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.157.140 with HTTP; Tue, 29 Aug 2017 15:44:53 -0700 (PDT) In-Reply-To: References: <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> <47b5b4e3-41c9-6779-4a96-b11650483499@nwtime.org> From: Daniel Franke Date: Tue, 29 Aug 2017 18:44:53 -0400 Message-ID: To: kristof.teichel@ptb.de Archived-At: Subject: Re: [Ntp] WGLC for draft-ietf-ntp-using-nts-for-ntp X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: ntp@ietf.org, Harlan Stenn Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ntp-bounces@ietf.org Sender: "ntp" On 8/29/17, kristof.teichel@ptb.de wrote: > Historically, encapsulation is an overall concept that has been argued > against a lot in the course of NTS (as far as I've witnessed it). > Therefore, I think that a paragraph of discussion on the presumed > negligibiliy of the precision loss with DTLS-encapsulation is warranted. > > Especially in the case of transmit timestamps (where every cryptographic > operation takes place between the reading of the timestamp and the actual > time of transmission that the timestamp was supposed to measure), perhaps it > should at least be mentioned why this encapsulation is not significantly > more expensive than e.g. adding a MAC/AEAD value. > > One thing I really don't know, however, is where such a piece of text should > be placed in order to not distort the core specification text (I don't think > anyone wants to or should have to read a passage about the design decision > process in the middle of the instructions on how to do the > DTLS-encapsulation). I don't think performance analysis needs to go in the RFC at all. I can't call to mind any other RFC that has included such a thing, and I'm certain I've never seen it out of the TLS WG. But for any skeptics, here's the math. Let's start by looking at legacy MD5(K||M). Computing MD5 over 64 bytes ( 16-byte key, 48-byte NTP header) takes about 900 cycles on my Broadwell system. Now let's look at the AES-CMAC draft and at DTLS encapsulation with AES-GCM. For these, a couple optimizations are possible to minimize the time that elapses between when you call clock_gettime() (or whatever your OS's equivalent) for the transmit timestamp, and when the authenticated (and possibly encrypted) packet is ready to send. The first optimization is straightforward. AES-CMAC supports incremental, one-pass computation, as do all (D)TLS ciphers. That means it's possible to precompute the crypto for every block preceding the one that holds the transmit timestamp, before the transmit timestamp is obtained. (This is possible with MD5 too, but it doesn't buy you anything because MD5's internal block size is larger than the data being hashed.) The second optimization only works in DTLS, and it's *conceptually* straightforward but probably a pain to implement just on account of API limitations in TLS libraries. With AES-GCM, as well as with any stream cipher, you can precompute encryption of the transmit timestamp even before you have it, because all the expensive parts of encryption don't depend on the plaintext -- you use your cipher algorithm to compute a pseudorandom stream of bits and then the combination with the plaintext is a simple xor (a single CPU cycle, which I'll neglect). An NTP header is 48 octets, which conveniently works out to exactly three AES blocks. In this situation, AES-CMAC basically acts like AES-CBC with one extra XOR thrown in and outputting just the final block. On my Broadwell system, AES-CBC takes about 75 cycles per block. On Skylake it's somewhat faster. So, to get from capturing the transmit timestamp to a ready message, you need about 75 CPU cycles if you optimize or about 225 if you don't. Both of these figures assume you're at least doing AES key setup before you get the transmit timestamp. I'm not sure exactly how much key setup adds, probably another few hundred cycles, but I'm not going to bother measuring it because not doing that in advance is just dumb. Now let's look at DTLS with AES-GCM. A DTLS record consists of a 12-octet header, treated as associated data, followed by ciphertext which is internally structured as the actual encrypted payload followed by a 16-octet authenticator. AES-GCM is rather complex, but at high level you can think of it as a combination of AES-CTR with a non-cryptographic hash called GHASH. Its cost comes down to the cost of computing AES-CTR over the plaintext, plus the cost of computing GHASH over the associated data and the output of AES-CTR, plus the cost of one additional AES operation at the end. AES-CTR allows you use CPU pipelining to encrypt a few blocks in parallel on a single core. Encrypting one block costs about the same as one block with AES-CBC (about 75 cycles), but you can do three blocks for about the same cost as one. GHASH adds about 5 cycles per block. Regardless, computing the authenticator adds another 75 cycles or so at the end. So with no optimization, we're looking at 75 cycles for AES-CTR, 20 cycles for GHASH, 75 cycles for the authenticator. Basic optimization saves 15 cycles on GHASH, but because of parallelism doesn't buy anything else. Clever optimization cuts out everything except the final authenticator computation. So here's how it roughly works out: MD5: 900 cycles AES-CMAC, no optimization: 225 cycles AES-CMAC, basic optimization: 75 cycles DTLS, no optimization: 170 cycles DTLS, basic optimization: 155 cycles DTLS, clever optimization: 75 cycles 900 cycles for MD5 at 3.5GHz is 257 nanoseconds. In the worst case, the resulting timing asymmetry throws off your accuracy by half that, or 128 nanoseconds. That is several orders magnitude smaller than anything NTP can possibly promise you. If you want to measure the impact of adding the MD5 step in real world conditions, you will have an extremely difficult time distinguishing it from zero. AES-CMAC and DTLS each cut this performance impact by an additional order of magnitude. If you try measuring the impact of either one and tell me that you were able to do so, I will tell you that there is either something wrong with your experiment or something wrong with your crypto implementation. DTLS encapsulation is *just fine*. _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp From nobody Tue Aug 29 15:45:12 2017 Return-Path: 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 64717132D9B for ; Tue, 29 Aug 2017 15:45:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 VvKmk7xzWW8q for ; Tue, 29 Aug 2017 15:44:59 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (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 6610F132D91 for ; Tue, 29 Aug 2017 15:44:56 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id t201so18644wmt.1 for ; Tue, 29 Aug 2017 15:44:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2JeSqfDA88k4z1IXgFeQe2awGFPQG4n02KL4aYOKC4g=; b=FBW20NpX+WmDEqVBI4SqsSfC203fuIoxOQkwKhpZzAdjehSLghcnDXwFglVkvrw35Z NsTKZ0DAiD+KAk+hzlkk+cjNiHlxMfZGyMSClA0qKifdyHLyjNffjYMjraV0GzlLiXGf 13RAgzvnTkCRRs5kUyKARB5kSA8ssruZ7EsR3NZxfM1wOTKa8nmVbe0/vYFRyh00fYye P6wVzX0PjSd6Pumd21Xmgjo3cxo8aoxjavVt5z1WJ4k2qEr5I+va1LNNX/wKb1HTOx+i VQQl67vCREW2vjnG25SiOT/649UtvI2D+JV0HdcolMPtx04OEAgU/D4eaZ56+BsJZotq U2Sw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=2JeSqfDA88k4z1IXgFeQe2awGFPQG4n02KL4aYOKC4g=; b=mxkEkOIbLy+4rVqkEwWDZngYmovoxQGs5l1qLXV4R377l5vbag67I1Ljgkf0ymUITT 1JnWmapV6aPk9qghuTsTySqc2ToFsE6k/T3IxPSQnfJgk64aWCCqH5TH6/GqygcG9qKX I2hhQprKNYDEOwKgOJU58QgGo5Txd3a1C+7xSIe20GEU0DBlfelA+kgMEAi2TUOnJfIn VYOa3vCPhc/nGX23R4zqVlRPXnI97KSyeoV6trOXOrFIKhJpCMdIG9Vjvn+BrtSw1IwA o71+tOo8BEzYV0YzTbQJgeT/98kEq9+FRBakeSrs0punUuNaA0AWFcu2R9xP9XhQ7Ftr DnPw== X-Gm-Message-State: AHYfb5jRQZINBGVkJQ9ajNdlnupqvop2wiweNszdZlWzVK7T89x9sag1 YKEuYU2NAbqwrB/oehCjCfIlIwSvob6sZIw= X-Received: by 10.80.240.207 with SMTP id a15mr4721902edm.294.1504046694731; Tue, 29 Aug 2017 15:44:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.157.140 with HTTP; Tue, 29 Aug 2017 15:44:53 -0700 (PDT) In-Reply-To: References: <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> <47b5b4e3-41c9-6779-4a96-b11650483499@nwtime.org> From: Daniel Franke Date: Tue, 29 Aug 2017 18:44:53 -0400 Message-ID: To: kristof.teichel@ptb.de Cc: Harlan Stenn , ntp@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Ntp] WGLC for draft-ietf-ntp-using-nts-for-ntp X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Aug 2017 22:45:01 -0000 On 8/29/17, kristof.teichel@ptb.de wrote: > Historically, encapsulation is an overall concept that has been argued > against a lot in the course of NTS (as far as I've witnessed it). > Therefore, I think that a paragraph of discussion on the presumed > negligibiliy of the precision loss with DTLS-encapsulation is warranted. > > Especially in the case of transmit timestamps (where every cryptographic > operation takes place between the reading of the timestamp and the actual > time of transmission that the timestamp was supposed to measure), perhaps it > should at least be mentioned why this encapsulation is not significantly > more expensive than e.g. adding a MAC/AEAD value. > > One thing I really don't know, however, is where such a piece of text should > be placed in order to not distort the core specification text (I don't think > anyone wants to or should have to read a passage about the design decision > process in the middle of the instructions on how to do the > DTLS-encapsulation). I don't think performance analysis needs to go in the RFC at all. I can't call to mind any other RFC that has included such a thing, and I'm certain I've never seen it out of the TLS WG. But for any skeptics, here's the math. Let's start by looking at legacy MD5(K||M). Computing MD5 over 64 bytes ( 16-byte key, 48-byte NTP header) takes about 900 cycles on my Broadwell system. Now let's look at the AES-CMAC draft and at DTLS encapsulation with AES-GCM. For these, a couple optimizations are possible to minimize the time that elapses between when you call clock_gettime() (or whatever your OS's equivalent) for the transmit timestamp, and when the authenticated (and possibly encrypted) packet is ready to send. The first optimization is straightforward. AES-CMAC supports incremental, one-pass computation, as do all (D)TLS ciphers. That means it's possible to precompute the crypto for every block preceding the one that holds the transmit timestamp, before the transmit timestamp is obtained. (This is possible with MD5 too, but it doesn't buy you anything because MD5's internal block size is larger than the data being hashed.) The second optimization only works in DTLS, and it's *conceptually* straightforward but probably a pain to implement just on account of API limitations in TLS libraries. With AES-GCM, as well as with any stream cipher, you can precompute encryption of the transmit timestamp even before you have it, because all the expensive parts of encryption don't depend on the plaintext -- you use your cipher algorithm to compute a pseudorandom stream of bits and then the combination with the plaintext is a simple xor (a single CPU cycle, which I'll neglect). An NTP header is 48 octets, which conveniently works out to exactly three AES blocks. In this situation, AES-CMAC basically acts like AES-CBC with one extra XOR thrown in and outputting just the final block. On my Broadwell system, AES-CBC takes about 75 cycles per block. On Skylake it's somewhat faster. So, to get from capturing the transmit timestamp to a ready message, you need about 75 CPU cycles if you optimize or about 225 if you don't. Both of these figures assume you're at least doing AES key setup before you get the transmit timestamp. I'm not sure exactly how much key setup adds, probably another few hundred cycles, but I'm not going to bother measuring it because not doing that in advance is just dumb. Now let's look at DTLS with AES-GCM. A DTLS record consists of a 12-octet header, treated as associated data, followed by ciphertext which is internally structured as the actual encrypted payload followed by a 16-octet authenticator. AES-GCM is rather complex, but at high level you can think of it as a combination of AES-CTR with a non-cryptographic hash called GHASH. Its cost comes down to the cost of computing AES-CTR over the plaintext, plus the cost of computing GHASH over the associated data and the output of AES-CTR, plus the cost of one additional AES operation at the end. AES-CTR allows you use CPU pipelining to encrypt a few blocks in parallel on a single core. Encrypting one block costs about the same as one block with AES-CBC (about 75 cycles), but you can do three blocks for about the same cost as one. GHASH adds about 5 cycles per block. Regardless, computing the authenticator adds another 75 cycles or so at the end. So with no optimization, we're looking at 75 cycles for AES-CTR, 20 cycles for GHASH, 75 cycles for the authenticator. Basic optimization saves 15 cycles on GHASH, but because of parallelism doesn't buy anything else. Clever optimization cuts out everything except the final authenticator computation. So here's how it roughly works out: MD5: 900 cycles AES-CMAC, no optimization: 225 cycles AES-CMAC, basic optimization: 75 cycles DTLS, no optimization: 170 cycles DTLS, basic optimization: 155 cycles DTLS, clever optimization: 75 cycles 900 cycles for MD5 at 3.5GHz is 257 nanoseconds. In the worst case, the resulting timing asymmetry throws off your accuracy by half that, or 128 nanoseconds. That is several orders magnitude smaller than anything NTP can possibly promise you. If you want to measure the impact of adding the MD5 step in real world conditions, you will have an extremely difficult time distinguishing it from zero. AES-CMAC and DTLS each cut this performance impact by an additional order of magnitude. If you try measuring the impact of either one and tell me that you were able to do so, I will tell you that there is either something wrong with your experiment or something wrong with your crypto implementation. DTLS encapsulation is *just fine*. From nobody Tue Aug 29 15:49:14 2017 Return-Path: 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 6ECCF132452; Mon, 28 Aug 2017 23:06:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 2dxfIozd5YFY; Mon, 28 Aug 2017 23:06:19 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C0941320BB; Mon, 28 Aug 2017 23:06:18 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DNM91049; Tue, 29 Aug 2017 06:06:16 +0000 (GMT) Received: from DGGEML404-HUB.china.huawei.com (10.3.17.39) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 29 Aug 2017 07:06:14 +0100 Received: from DGGEML507-MBX.china.huawei.com ([169.254.2.7]) by DGGEML404-HUB.china.huawei.com ([fe80::b177:a243:7a69:5ab8%31]) with mapi id 14.03.0301.000; Tue, 29 Aug 2017 14:06:04 +0800 From: Jiangyuanlong To: "Karen O'Donoghue" , "ntp@ietf.org" CC: "tictoc@ietf.org" Thread-Topic: WGLC for draft-ietf-ntp-mac Thread-Index: AQHTEMt6dgTCyuPEXEODOT5Gsnqn3aKawq4A Date: Tue, 29 Aug 2017 06:06:04 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68BBB599924@dggeml507-mbx.china.huawei.com> References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.74.202.215] Content-Type: multipart/alternative; boundary="_000_3B0A1BED22CAD649A1B3E97BE5DDD68BBB599924dggeml507mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090205.59A50458.007B, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.2.7, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 042ac782f4d1e66b19b97e247fe5f230 Archived-At: X-Mailman-Approved-At: Tue, 29 Aug 2017 15:49:12 -0700 Subject: Re: [Ntp] WGLC for draft-ietf-ntp-mac X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Aug 2017 06:06:27 -0000 --_000_3B0A1BED22CAD649A1B3E97BE5DDD68BBB599924dggeml507mbxchi_ Content-Type: text/plain; charset="utf-7" Content-Transfer-Encoding: quoted-printable Hi, I support the publication of this draft, though I have several suggesti= ons for the texts: 1. +IBw-If authentication is implemented, then AES-CMAC as specified = in RFC 4493 +AFs-RFC4493+AF0- should be computed+ICYgHQ- in Section 3. This is a requirement, so I think it should use +IBw-SHOULD+IB0- instead of= +IBw-should+IB0-. But if this AES-CMAC is the only authentication mechanism, it is better to = use +IBw-MUST+IB0-. 2. +IBw-We recommend that the MAC key for NTP SHOULD be 128 bits long= AES-128 key+ICYgHQ- in Section 3. To be more formal, maybe it can be rephrased into +IBw-It is RECOMMENDED th= at the MAC key for NTP SHOULD be 128 bits long AES-128 key+ICYgHQ- 3. +ACI-FOr test vectors and their outputs refer to Section 4 of RFC = 4493 +AFs-RFC4493+AF0AIg- in Section 5 should be +IBw-For test vectors and = their outputs refer to Section 4 of RFC 4493.+IB0- Thanks, Yuanlong From: TICTOC +AFs-mailto:tictoc-bounces+AEA-ietf.org+AF0- On Behalf Of Kare= n O'Donoghue Sent: Wednesday, August 09, 2017 12:54 PM To: ntp+AEA-ietf.org Cc: tictoc+AEA-ietf.org Subject: +AFs-TICTOC+AF0- WGLC for draft-ietf-ntp-mac Folks, This begins a three week working group last call (WGLC) for +ACI-Message Au= thentication Code for the Network Time Protocol+ACI- https://datatracker.ietf.org/doc/draft-ietf-ntp-mac/ Please review and provide comments to the mailing list by no later than 31 = August 2017. Earlier comments and discussion would be appreciated. Please n= ote that the chairs will be using this WGLC to determine consensus to move = this document forward to the IESG. Also, as a reminder, we have migrated the working group mailing list to IET= F infrastructure. Please respond to ntp+AEA-ietf.org+ADw-mailto:ntp+AEA-iet= f.org+AD4-. Regards, Karen and Dieter --_000_3B0A1BED22CAD649A1B3E97BE5DDD68BBB599924dggeml507mbxchi_ Content-Type: text/html; charset="utf-7" Content-Transfer-Encoding: quoted-printable +ADw-html xmlns:v+AD0AIg-urn:schemas-microsoft-com:vml+ACI- xmlns:o+AD0AIg-= urn:schemas-microsoft-com:office:office+ACI- xmlns:w+AD0AIg-urn:schemas-mic= rosoft-com:office:word+ACI- xmlns:m+AD0AIg-http://schemas.microsoft.com/off= ice/2004/12/omml+ACI- xmlns+AD0AIg-http://www.w3.org/TR/REC-html40+ACIAPg- +ADw-head+AD4- +ADw-meta name+AD0AIg-Generator+ACI- content+AD0AIg-Microsoft Word 12 (filt= ered medium)+ACIAPg- +ADw-style+AD4- +ADwAIQ--- /+ACo- Font Definitions +ACo-/ +AEA-font-face +AHs-font-family:+W4tPUwA7- panose-1:2 1 6 0 3 1 1 1 1 1+ADsAfQ- +AEA-font-face +AHs-font-family:+ACI-Cambria Math+ACIAOw- panose-1:2 4 5 3 5 4 6 3 2 4+ADsAfQ- +AEA-font-face +AHs-font-family:Calibri+ADs- panose-1:2 15 5 2 2 2 4 3 2 4+ADsAfQ- +AEA-font-face +AHs-font-family:+ACIAXABAW4tPUwAiADs- panose-1:2 1 6 0 3 1 1 1 1 1+ADsAfQ- +AEA-font-face +AHs-font-family:Tahoma+ADs- panose-1:2 11 6 4 3 5 4 4 2 4+ADsAfQ- /+ACo- Style Definitions +ACo-/ p.MsoNormal, li.MsoNormal, div.MsoNormal +AHs-margin:0cm+ADs- margin-bottom:.0001pt+ADs- font-size:12.0pt+ADs- font-family:+ACI-Times New Roman+ACI-,+ACI-serif+ACIAOwB9- a:link, span.MsoHyperlink +AHs-mso-style-priority:99+ADs- color:blue+ADs- text-decoration:underline+ADsAfQ- a:visited, span.MsoHyperlinkFollowed +AHs-mso-style-priority:99+ADs- color:purple+ADs- text-decoration:underline+ADsAfQ- p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph +AHs-mso-style-priority:34+ADs- margin:0cm+ADs- margin-bottom:.0001pt+ADs- text-indent:21.0pt+ADs- font-size:12.0pt+ADs- font-family:+ACI-Times New Roman+ACI-,+ACI-serif+ACIAOwB9- span.EmailStyle17 +AHs-mso-style-type:personal-reply+ADs- font-family:+ACI-Calibri+ACI-,+ACI-sans-serif+ACIAOw- color:+ACM-1F497D+ADsAfQ- .MsoChpDefault +AHs-mso-style-type:export-only+ADs- font-size:10.0pt+ADsAfQ- +AEA-page WordSection1 +AHs-size:612.0pt 792.0pt+ADs- margin:72.0pt 90.0pt 72.0pt 90.0pt+ADsAfQ- div.WordSection1 +AHs-page:WordSection1+ADsAfQ- /+ACo- List Definitions +ACo-/ +AEA-list l0 +AHs-mso-list-id:1450392097+ADs- mso-list-type:hybrid+ADs- mso-list-template-ids:500718642 -1169397514 67698713 67698715 67698703 676= 98713 67698715 67698703 67698713 67698715+ADsAfQ- +AEA-list l0:level1 +AHs-mso-level-tab-stop:none+ADs- mso-level-number-position:left+ADs- margin-left:18.0pt+ADs- text-indent:-18.0pt+ADsAfQ- ol +AHs-margin-bottom:0cm+ADsAfQ- ul +AHs-margin-bottom:0cm+ADsAfQ- --+AD4- +ADw-/style+AD4APAAh---+AFs-if gte mso 9+AF0APgA8-xml+AD4- +ADw-o:shapedefaults v:ext+AD0AIg-edit+ACI- spidmax+AD0AIg-1026+ACI- /+AD4= - +ADw-/xml+AD4APAAhAFs-endif+AF0---+AD4APAAh---+AFs-if gte mso 9+AF0APgA8-xm= l+AD4- +ADw-o:shapelayout v:ext+AD0AIg-edit+ACIAPg- +ADw-o:idmap v:ext+AD0AIg-edit+ACI- data+AD0AIg-1+ACI- /+AD4- +ADw-/o:shapelayout+AD4APA-/xml+AD4APAAhAFs-endif+AF0---+AD4- +ADw-/head+AD4- +ADw-body lang+AD0AIg-ZH-CN+ACI- link+AD0AIg-blue+ACI- vlink+AD0AIg-purple+= ACIAPg- +ADw-div class+AD0AIg-WordSection1+ACIAPg- +ADw-p class+AD0AIg-MsoNormal+ACIAPgA8-span lang+AD0AIg-EN-US+ACI- style+AD= 0AIg-font-size:10.5pt+ADs-font-family:+ACY-quot+ADs-Calibri+ACY-quot+ADs-,+= ACY-quot+ADs-sans-serif+ACY-quot+ADsAOw- color:+ACM-1F497D+ACIAPg-Hi, I support the publication of this draft, thoug= h I have several suggestions for the texts:+ADw-o:p+AD4APA-/o:p+AD4APA-/spa= n+AD4APA-/p+AD4- +ADw-p class+AD0AIg-MsoNormal+ACIAPgA8-span lang+AD0AIg-EN-US+ACI- style+AD= 0AIg-font-size:10.5pt+ADs-font-family:+ACY-quot+ADs-Calibri+ACY-quot+ADs-,+= ACY-quot+ADs-sans-serif+ACY-quot+ADsAOw- color:+ACM-1F497D+ACIAPgA8-o:p+AD4AJg-nbsp+ADsAPA-/o:p+AD4APA-/span+AD4APA-= /p+AD4- +ADw-p class+AD0AIg-MsoListParagraph+ACI- style+AD0AIg-margin-left:18.0pt+A= Ds-text-indent:-18.0pt+ADs- mso-list:l0 level1 lfo1+ACIAPg- +ADwAIQBb-if +ACE-supportLists+AF0APgA8-span lang+AD0AIg-EN-US+ACI- style+A= D0AIg-font-size:10.5pt+ADs-font-family:+ACY-quot+ADs-Calibri+ACY-quot+ADs-,= +ACY-quot+ADs-sans-serif+ACY-quot+ADsAOw-color:+ACM-1F497D+ACIAPgA8-span st= yle+AD0AIg-mso-list:Ignore+ACIAPg-1.+ADw-span style+AD0AIg-font:7.0pt +ACY-= quot+ADs-Times New Roman+ACY-quot+ADsAIgA+ACY-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+= ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADs- +ADw-/span+AD4APA-/span+AD4APA-/span+AD4APAAhAFs-endif+AF0APgA8-span lang+A= D0AIg-EN-US+ACI- style+AD0AIg-font-size:10.5pt+ADs- font-family:+ACY-quot+ADs-Calibri+ACY-quot+ADs-,+ACY-quot+ADs-sans-serif+AC= Y-quot+ADsAOw-color:+ACM-1F497D+ACIAPiAc-If authentication is implemented, = then AES-CMAC as specified in RFC+ADw-o:p+AD4APA-/o:p+AD4APA-/span+AD4APA-/= p+AD4- +ADw-p class+AD0AIg-MsoNormal+ACIAPgA8-span lang+AD0AIg-EN-US+ACI- style+AD= 0AIg-font-size:10.5pt+ADs-font-family:+ACY-quot+ADs-Calibri+ACY-quot+ADs-,+= ACY-quot+ADs-sans-serif+ACY-quot+ADsAOw- color:+ACM-1F497D+ACIAPgAm-nbsp+ADsAJg-nbsp+ADs- +ACY-nbsp+ADsAJg-nbsp+ADsA= Jg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADs-4493 +AFs-RFC4493+AF0- should be comput= ed+ICYgHQ- in Section 3.+ADw-o:p+AD4APA-/o:p+AD4APA-/span+AD4APA-/p+AD4- +ADw-p class+AD0AIg-MsoNormal+ACIAPgA8-span lang+AD0AIg-EN-US+ACI- style+AD= 0AIg-font-size:10.5pt+ADs-font-family:+ACY-quot+ADs-Calibri+ACY-quot+ADs-,+= ACY-quot+ADs-sans-serif+ACY-quot+ADsAOw- color:+ACM-1F497D+ACIAPg-This is a requirement, so I think it should use +I= Bw-SHOULD+IB0- instead of +IBw-should+IB0-. +ADw-o:p+AD4APA-/o:p+AD4APA-/span+AD4APA-/p+AD4- +ADw-p class+AD0AIg-MsoNormal+ACIAPgA8-span lang+AD0AIg-EN-US+ACI- style+AD= 0AIg-font-size:10.5pt+ADs-font-family:+ACY-quot+ADs-Calibri+ACY-quot+ADs-,+= ACY-quot+ADs-sans-serif+ACY-quot+ADsAOw- color:+ACM-1F497D+ACIAPg-But if this AES-CMAC is the only authentication me= chanism, it is better to use +IBw-MUST+IB0-.+ADw-o:p+AD4APA-/o:p+AD4APA-/sp= an+AD4APA-/p+AD4- +ADw-p class+AD0AIg-MsoNormal+ACIAPgA8-span lang+AD0AIg-EN-US+ACI- style+AD= 0AIg-font-size:10.5pt+ADs-font-family:+ACY-quot+ADs-Calibri+ACY-quot+ADs-,+= ACY-quot+ADs-sans-serif+ACY-quot+ADsAOw- color:+ACM-1F497D+ACIAPgA8-o:p+AD4AJg-nbsp+ADsAPA-/o:p+AD4APA-/span+AD4APA-= /p+AD4- +ADw-p class+AD0AIg-MsoListParagraph+ACI- style+AD0AIg-margin-left:18.0pt+A= Ds-text-indent:-18.0pt+ADs- mso-list:l0 level1 lfo1+ACIAPg- +ADwAIQBb-if +ACE-supportLists+AF0APgA8-span lang+AD0AIg-EN-US+ACI- style+A= D0AIg-font-size:10.5pt+ADs-font-family:+ACY-quot+ADs-Calibri+ACY-quot+ADs-,= +ACY-quot+ADs-sans-serif+ACY-quot+ADsAOw-color:+ACM-1F497D+ACIAPgA8-span st= yle+AD0AIg-mso-list:Ignore+ACIAPg-2.+ADw-span style+AD0AIg-font:7.0pt +ACY-= quot+ADs-Times New Roman+ACY-quot+ADsAIgA+ACY-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+= ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADs- +ADw-/span+AD4APA-/span+AD4APA-/span+AD4APAAhAFs-endif+AF0APgA8-span lang+A= D0AIg-EN-US+ACI- style+AD0AIg-font-size:10.5pt+ADs- font-family:+ACY-quot+ADs-Calibri+ACY-quot+ADs-,+ACY-quot+ADs-sans-serif+AC= Y-quot+ADsAOw-color:+ACM-1F497D+ACIAPiAc-We recommend that the MAC key for = NTP SHOULD be 128 bits long AES-128 key+ICYgHQ- in Section 3.+ADw-o:p+AD4AP= A-/o:p+AD4APA-/span+AD4APA-/p+AD4- +ADw-p class+AD0AIg-MsoNormal+ACIAPgA8-span lang+AD0AIg-EN-US+ACI- style+AD= 0AIg-font-size:10.5pt+ADs-font-family:+ACY-quot+ADs-Calibri+ACY-quot+ADs-,+= ACY-quot+ADs-sans-serif+ACY-quot+ADsAOw- color:+ACM-1F497D+ACIAPg-To be more formal, maybe it can be rephrased into = +IBw-It is RECOMMENDED that the MAC key for NTP SHOULD be 128 bits long AES= -128 key+ICYgHQA8-o:p+AD4APA-/o:p+AD4APA-/span+AD4APA-/p+AD4- +ADw-p class+AD0AIg-MsoNormal+ACIAPgA8-span lang+AD0AIg-EN-US+ACI- style+AD= 0AIg-font-size:10.5pt+ADs-font-family:+ACY-quot+ADs-Calibri+ACY-quot+ADs-,+= ACY-quot+ADs-sans-serif+ACY-quot+ADsAOw- color:+ACM-1F497D+ACIAPgA8-o:p+AD4AJg-nbsp+ADsAPA-/o:p+AD4APA-/span+AD4APA-= /p+AD4- +ADw-p class+AD0AIg-MsoListParagraph+ACI- style+AD0AIg-margin-left:18.0pt+A= Ds-text-indent:-18.0pt+ADs- mso-list:l0 level1 lfo1+ACIAPg- +ADwAIQBb-if +ACE-supportLists+AF0APgA8-span lang+AD0AIg-EN-US+ACI- style+A= D0AIg-font-size:10.5pt+ADs-font-family:+ACY-quot+ADs-Calibri+ACY-quot+ADs-,= +ACY-quot+ADs-sans-serif+ACY-quot+ADsAOw-color:+ACM-1F497D+ACIAPgA8-span st= yle+AD0AIg-mso-list:Ignore+ACIAPg-3.+ADw-span style+AD0AIg-font:7.0pt +ACY-= quot+ADs-Times New Roman+ACY-quot+ADsAIgA+ACY-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+= ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADs- +ADw-/span+AD4APA-/span+AD4APA-/span+AD4APAAhAFs-endif+AF0APgA8-span lang+A= D0AIg-EN-US+ACI- style+AD0AIg-font-size:10.5pt+ADs- font-family:+ACY-quot+ADs-Calibri+ACY-quot+ADs-,+ACY-quot+ADs-sans-serif+AC= Y-quot+ADsAOw-color:+ACM-1F497D+ACIAPgAm-quot+ADs-FOr test vectors and thei= r outputs refer to Section 4 of RFC 4493 +AFs-RFC4493+AF0AJg-quot+ADs- in S= ection 5 should be +IBw-For test vectors and their outputs refer to Section 4 of RFC 4493.+IB0APA-o:p+AD4APA-/o:p+AD4APA-/span+AD4APA= -/p+AD4- +ADw-p class+AD0AIg-MsoListParagraph+ACI- style+AD0AIg-margin-left:18.0pt+A= Ds-text-indent:0cm+ACIAPgA8-span lang+AD0AIg-EN-US+ACI- style+AD0AIg-font-s= ize:10.5pt+ADs-font-family:+ACY-quot+ADs-Calibri+ACY-quot+ADs-,+ACY-quot+AD= s-sans-serif+ACY-quot+ADsAOw- color:+ACM-1F497D+ACIAPgA8-o:p+AD4AJg-nbsp+ADsAPA-/o:p+AD4APA-/span+AD4APA-= /p+AD4- +ADw-p class+AD0AIg-MsoNormal+ACIAPgA8-span lang+AD0AIg-EN-US+ACI- style+AD= 0AIg-font-size:10.5pt+ADs-font-family:+ACY-quot+ADs-Calibri+ACY-quot+ADs-,+= ACY-quot+ADs-sans-serif+ACY-quot+ADsAOw- color:+ACM-1F497D+ACIAPg-Thanks,+ADw-o:p+AD4APA-/o:p+AD4APA-/span+AD4APA-/p= +AD4- +ADw-p class+AD0AIg-MsoNormal+ACIAPgA8-span lang+AD0AIg-EN-US+ACI- style+AD= 0AIg-font-size:10.5pt+ADs-font-family:+ACY-quot+ADs-Calibri+ACY-quot+ADs-,+= ACY-quot+ADs-sans-serif+ACY-quot+ADsAOw- color:+ACM-1F497D+ACIAPg-Yuanlong+ADw-o:p+AD4APA-/o:p+AD4APA-/span+AD4APA-/= p+AD4- +ADw-p class+AD0AIg-MsoNormal+ACIAPgA8-span lang+AD0AIg-EN-US+ACI- style+AD= 0AIg-font-size:10.5pt+ADs-font-family:+ACY-quot+ADs-Calibri+ACY-quot+ADs-,+= ACY-quot+ADs-sans-serif+ACY-quot+ADsAOw- color:+ACM-1F497D+ACIAPgA8-o:p+AD4AJg-nbsp+ADsAPA-/o:p+AD4APA-/span+AD4APA-= /p+AD4- +ADw-div+AD4- +ADw-div style+AD0AIg-border:none+ADs-border-top:solid +ACM-B5C4DF 1.0pt+AD= s-padding:3.0pt 0cm 0cm 0cm+ACIAPg- +ADw-p class+AD0AIg-MsoNormal+ACIAPgA8-b+AD4APA-span lang+AD0AIg-EN-US+ACI-= style+AD0AIg-font-size:10.0pt+ADs-font-family: +ACY-quot+ADs-Tahoma+ACY-quot+ADs-,+ACY-quot+ADs-sans-serif+ACY-quot+ADsAIg= A+-From:+ADw-/span+AD4APA-/b+AD4APA-span lang+AD0AIg-EN-US+ACI- style+AD0AI= g-font-size:10.0pt+ADs- font-family:+ACY-quot+ADs-Tahoma+ACY-quot+ADs-,+ACY-quot+ADs-sans-serif+ACY= -quot+ADsAIgA+- TICTOC +AFs-mailto:tictoc-bounces+AEA-ietf.org+AF0- +ADw-b+AD4-On Behalf Of +ADw-/b+AD4-Karen O'Donoghue+ADw-br+AD4- +ADw-b+AD4-Sent:+ADw-/b+AD4- Wednesday, August 09, 2017 12:54 PM+ADw-br+AD4= - +ADw-b+AD4-To:+ADw-/b+AD4- ntp+AEA-ietf.org+ADw-br+AD4- +ADw-b+AD4-Cc:+ADw-/b+AD4- tictoc+AEA-ietf.org+ADw-br+AD4- +ADw-b+AD4-Subject:+ADw-/b+AD4- +AFs-TICTOC+AF0- WGLC for draft-ietf-ntp-ma= c+ADw-o:p+AD4APA-/o:p+AD4APA-/span+AD4APA-/p+AD4- +ADw-/div+AD4- +ADw-/div+AD4- +ADw-p class+AD0AIg-MsoNormal+ACIAPgA8-span lang+AD0AIg-EN-US+ACIAPgA8-o:p+= AD4AJg-nbsp+ADsAPA-/o:p+AD4APA-/span+AD4APA-/p+AD4- +ADw-p class+AD0AIg-MsoNormal+ACIAPgA8-span lang+AD0AIg-EN-US+ACIAPg-Folks,= +ADw-br+AD4- +ADw-br+AD4- This begins a three week working group last call (WGLC) for +ACY-quot+ADs-M= essage Authentication Code for the Network Time Protocol+ACY-quot+ADsAPA-br= +AD4- +ADw-a href+AD0AIg-https://datatracker.ietf.org/doc/draft-ietf-ntp-mac/+ACI= APg-https://datatracker.ietf.org/doc/draft-ietf-ntp-mac/+ADw-/a+AD4- +ADw-o:p+AD4APA-/o:p+AD4APA-/span+AD4APA-/p+AD4- +ADw-div+AD4- +ADw-p class+AD0AIg-MsoNormal+ACIAPgA8-span lang+AD0AIg-EN-US+ACIAPgA8-br+A= D4- Please review and provide comments to the mailing list by no later than 31 = August 2017. Earlier comments and discussion would be appreciated. Please n= ote that the chairs will be using this WGLC to determine consensus to move = this document forward to the IESG.+ACY-nbsp+ADsAPA-br+AD4- +ADw-br+AD4- Also, as a reminder, we have migrated the working group mailing list to IET= F infrastructure. Please respond to+ACY-nbsp+ADsAPA-a href+AD0AIg-mailto:nt= p+AEA-ietf.org+ACIAPg-ntp+AEA-ietf.org+ADw-/a+AD4-.+ACY-nbsp+ADsAPA-br+AD4- +ADw-br+AD4- Regards,+ADw-br+AD4- Karen and Dieter+ADw-o:p+AD4APA-/o:p+AD4APA-/span+AD4APA-/p+AD4- +ADw-/div+AD4- +ADw-/div+AD4- +ADw-/body+AD4- +ADw-/html+AD4- --_000_3B0A1BED22CAD649A1B3E97BE5DDD68BBB599924dggeml507mbxchi_-- From ntp-bounces@ietf.org Tue Aug 29 15:49:14 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 95EFA132494; Tue, 29 Aug 2017 15:49:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1504046954; bh=/qGEVcuJj4YORXgLDPD0vad30XjZNJM4XCkL5VB7/wg=; h=From:To:Date:References:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc; b=gRdW6ijTDtKfaybg3smEEZtekl8x28vBpt31UZKvjgtnfgTgg1UsCITkWcBQB8RAW gTXJm/EBH6w8OarFCOhVI/lFRALcAwhfWxVdnF8CE+tSTpzOK7zMetUYyweGdcRN2Z mHlPKT3zpKJDdH3jREEuxXdH13tR5/DxKgaBjjj0= 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 6ECCF132452; Mon, 28 Aug 2017 23:06:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 2dxfIozd5YFY; Mon, 28 Aug 2017 23:06:19 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C0941320BB; Mon, 28 Aug 2017 23:06:18 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DNM91049; Tue, 29 Aug 2017 06:06:16 +0000 (GMT) Received: from DGGEML404-HUB.china.huawei.com (10.3.17.39) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 29 Aug 2017 07:06:14 +0100 Received: from DGGEML507-MBX.china.huawei.com ([169.254.2.7]) by DGGEML404-HUB.china.huawei.com ([fe80::b177:a243:7a69:5ab8%31]) with mapi id 14.03.0301.000; Tue, 29 Aug 2017 14:06:04 +0800 From: Jiangyuanlong To: "Karen O'Donoghue" , "ntp@ietf.org" Thread-Topic: WGLC for draft-ietf-ntp-mac Thread-Index: AQHTEMt6dgTCyuPEXEODOT5Gsnqn3aKawq4A Date: Tue, 29 Aug 2017 06:06:04 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68BBB599924@dggeml507-mbx.china.huawei.com> References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.74.202.215] MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090205.59A50458.007B, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.2.7, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 042ac782f4d1e66b19b97e247fe5f230 Archived-At: X-Mailman-Approved-At: Tue, 29 Aug 2017 15:49:12 -0700 Subject: Re: [Ntp] WGLC for draft-ietf-ntp-mac X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "tictoc@ietf.org" Content-Type: multipart/mixed; boundary="===============8499278290473167402==" Errors-To: ntp-bounces@ietf.org Sender: "ntp" --===============8499278290473167402== Content-Language: zh-CN Content-Type: multipart/alternative; boundary="_000_3B0A1BED22CAD649A1B3E97BE5DDD68BBB599924dggeml507mbxchi_" --_000_3B0A1BED22CAD649A1B3E97BE5DDD68BBB599924dggeml507mbxchi_ Content-Type: text/plain; charset="utf-7" Content-Transfer-Encoding: quoted-printable Hi, I support the publication of this draft, though I have several suggesti= ons for the texts: 1. +IBw-If authentication is implemented, then AES-CMAC as specified = in RFC 4493 +AFs-RFC4493+AF0- should be computed+ICYgHQ- in Section 3. This is a requirement, so I think it should use +IBw-SHOULD+IB0- instead of= +IBw-should+IB0-. But if this AES-CMAC is the only authentication mechanism, it is better to = use +IBw-MUST+IB0-. 2. +IBw-We recommend that the MAC key for NTP SHOULD be 128 bits long= AES-128 key+ICYgHQ- in Section 3. To be more formal, maybe it can be rephrased into +IBw-It is RECOMMENDED th= at the MAC key for NTP SHOULD be 128 bits long AES-128 key+ICYgHQ- 3. +ACI-FOr test vectors and their outputs refer to Section 4 of RFC = 4493 +AFs-RFC4493+AF0AIg- in Section 5 should be +IBw-For test vectors and = their outputs refer to Section 4 of RFC 4493.+IB0- Thanks, Yuanlong From: TICTOC +AFs-mailto:tictoc-bounces+AEA-ietf.org+AF0- On Behalf Of Kare= n O'Donoghue Sent: Wednesday, August 09, 2017 12:54 PM To: ntp+AEA-ietf.org Cc: tictoc+AEA-ietf.org Subject: +AFs-TICTOC+AF0- WGLC for draft-ietf-ntp-mac Folks, This begins a three week working group last call (WGLC) for +ACI-Message Au= thentication Code for the Network Time Protocol+ACI- https://datatracker.ietf.org/doc/draft-ietf-ntp-mac/ Please review and provide comments to the mailing list by no later than 31 = August 2017. Earlier comments and discussion would be appreciated. Please n= ote that the chairs will be using this WGLC to determine consensus to move = this document forward to the IESG. Also, as a reminder, we have migrated the working group mailing list to IET= F infrastructure. Please respond to ntp+AEA-ietf.org+ADw-mailto:ntp+AEA-iet= f.org+AD4-. Regards, Karen and Dieter --_000_3B0A1BED22CAD649A1B3E97BE5DDD68BBB599924dggeml507mbxchi_ Content-Type: text/html; charset="utf-7" Content-Transfer-Encoding: quoted-printable +ADw-html xmlns:v+AD0AIg-urn:schemas-microsoft-com:vml+ACI- xmlns:o+AD0AIg-= urn:schemas-microsoft-com:office:office+ACI- xmlns:w+AD0AIg-urn:schemas-mic= rosoft-com:office:word+ACI- xmlns:m+AD0AIg-http://schemas.microsoft.com/off= ice/2004/12/omml+ACI- xmlns+AD0AIg-http://www.w3.org/TR/REC-html40+ACIAPg- +ADw-head+AD4- +ADw-meta name+AD0AIg-Generator+ACI- content+AD0AIg-Microsoft Word 12 (filt= ered medium)+ACIAPg- +ADw-style+AD4- +ADwAIQ--- /+ACo- Font Definitions +ACo-/ +AEA-font-face +AHs-font-family:+W4tPUwA7- panose-1:2 1 6 0 3 1 1 1 1 1+ADsAfQ- +AEA-font-face +AHs-font-family:+ACI-Cambria Math+ACIAOw- panose-1:2 4 5 3 5 4 6 3 2 4+ADsAfQ- +AEA-font-face +AHs-font-family:Calibri+ADs- panose-1:2 15 5 2 2 2 4 3 2 4+ADsAfQ- +AEA-font-face +AHs-font-family:+ACIAXABAW4tPUwAiADs- panose-1:2 1 6 0 3 1 1 1 1 1+ADsAfQ- +AEA-font-face +AHs-font-family:Tahoma+ADs- panose-1:2 11 6 4 3 5 4 4 2 4+ADsAfQ- /+ACo- Style Definitions +ACo-/ p.MsoNormal, li.MsoNormal, div.MsoNormal +AHs-margin:0cm+ADs- margin-bottom:.0001pt+ADs- font-size:12.0pt+ADs- font-family:+ACI-Times New Roman+ACI-,+ACI-serif+ACIAOwB9- a:link, span.MsoHyperlink +AHs-mso-style-priority:99+ADs- color:blue+ADs- text-decoration:underline+ADsAfQ- a:visited, span.MsoHyperlinkFollowed +AHs-mso-style-priority:99+ADs- color:purple+ADs- text-decoration:underline+ADsAfQ- p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph +AHs-mso-style-priority:34+ADs- margin:0cm+ADs- margin-bottom:.0001pt+ADs- text-indent:21.0pt+ADs- font-size:12.0pt+ADs- font-family:+ACI-Times New Roman+ACI-,+ACI-serif+ACIAOwB9- span.EmailStyle17 +AHs-mso-style-type:personal-reply+ADs- font-family:+ACI-Calibri+ACI-,+ACI-sans-serif+ACIAOw- color:+ACM-1F497D+ADsAfQ- .MsoChpDefault +AHs-mso-style-type:export-only+ADs- font-size:10.0pt+ADsAfQ- +AEA-page WordSection1 +AHs-size:612.0pt 792.0pt+ADs- margin:72.0pt 90.0pt 72.0pt 90.0pt+ADsAfQ- div.WordSection1 +AHs-page:WordSection1+ADsAfQ- /+ACo- List Definitions +ACo-/ +AEA-list l0 +AHs-mso-list-id:1450392097+ADs- mso-list-type:hybrid+ADs- mso-list-template-ids:500718642 -1169397514 67698713 67698715 67698703 676= 98713 67698715 67698703 67698713 67698715+ADsAfQ- +AEA-list l0:level1 +AHs-mso-level-tab-stop:none+ADs- mso-level-number-position:left+ADs- margin-left:18.0pt+ADs- text-indent:-18.0pt+ADsAfQ- ol +AHs-margin-bottom:0cm+ADsAfQ- ul +AHs-margin-bottom:0cm+ADsAfQ- --+AD4- +ADw-/style+AD4APAAh---+AFs-if gte mso 9+AF0APgA8-xml+AD4- +ADw-o:shapedefaults v:ext+AD0AIg-edit+ACI- spidmax+AD0AIg-1026+ACI- /+AD4= - +ADw-/xml+AD4APAAhAFs-endif+AF0---+AD4APAAh---+AFs-if gte mso 9+AF0APgA8-xm= l+AD4- +ADw-o:shapelayout v:ext+AD0AIg-edit+ACIAPg- +ADw-o:idmap v:ext+AD0AIg-edit+ACI- data+AD0AIg-1+ACI- /+AD4- +ADw-/o:shapelayout+AD4APA-/xml+AD4APAAhAFs-endif+AF0---+AD4- +ADw-/head+AD4- +ADw-body lang+AD0AIg-ZH-CN+ACI- link+AD0AIg-blue+ACI- vlink+AD0AIg-purple+= ACIAPg- +ADw-div class+AD0AIg-WordSection1+ACIAPg- +ADw-p class+AD0AIg-MsoNormal+ACIAPgA8-span lang+AD0AIg-EN-US+ACI- style+AD= 0AIg-font-size:10.5pt+ADs-font-family:+ACY-quot+ADs-Calibri+ACY-quot+ADs-,+= ACY-quot+ADs-sans-serif+ACY-quot+ADsAOw- color:+ACM-1F497D+ACIAPg-Hi, I support the publication of this draft, thoug= h I have several suggestions for the texts:+ADw-o:p+AD4APA-/o:p+AD4APA-/spa= n+AD4APA-/p+AD4- +ADw-p class+AD0AIg-MsoNormal+ACIAPgA8-span lang+AD0AIg-EN-US+ACI- style+AD= 0AIg-font-size:10.5pt+ADs-font-family:+ACY-quot+ADs-Calibri+ACY-quot+ADs-,+= ACY-quot+ADs-sans-serif+ACY-quot+ADsAOw- color:+ACM-1F497D+ACIAPgA8-o:p+AD4AJg-nbsp+ADsAPA-/o:p+AD4APA-/span+AD4APA-= /p+AD4- +ADw-p class+AD0AIg-MsoListParagraph+ACI- style+AD0AIg-margin-left:18.0pt+A= Ds-text-indent:-18.0pt+ADs- mso-list:l0 level1 lfo1+ACIAPg- +ADwAIQBb-if +ACE-supportLists+AF0APgA8-span lang+AD0AIg-EN-US+ACI- style+A= D0AIg-font-size:10.5pt+ADs-font-family:+ACY-quot+ADs-Calibri+ACY-quot+ADs-,= +ACY-quot+ADs-sans-serif+ACY-quot+ADsAOw-color:+ACM-1F497D+ACIAPgA8-span st= yle+AD0AIg-mso-list:Ignore+ACIAPg-1.+ADw-span style+AD0AIg-font:7.0pt +ACY-= quot+ADs-Times New Roman+ACY-quot+ADsAIgA+ACY-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+= ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADs- +ADw-/span+AD4APA-/span+AD4APA-/span+AD4APAAhAFs-endif+AF0APgA8-span lang+A= D0AIg-EN-US+ACI- style+AD0AIg-font-size:10.5pt+ADs- font-family:+ACY-quot+ADs-Calibri+ACY-quot+ADs-,+ACY-quot+ADs-sans-serif+AC= Y-quot+ADsAOw-color:+ACM-1F497D+ACIAPiAc-If authentication is implemented, = then AES-CMAC as specified in RFC+ADw-o:p+AD4APA-/o:p+AD4APA-/span+AD4APA-/= p+AD4- +ADw-p class+AD0AIg-MsoNormal+ACIAPgA8-span lang+AD0AIg-EN-US+ACI- style+AD= 0AIg-font-size:10.5pt+ADs-font-family:+ACY-quot+ADs-Calibri+ACY-quot+ADs-,+= ACY-quot+ADs-sans-serif+ACY-quot+ADsAOw- color:+ACM-1F497D+ACIAPgAm-nbsp+ADsAJg-nbsp+ADs- +ACY-nbsp+ADsAJg-nbsp+ADsA= Jg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADs-4493 +AFs-RFC4493+AF0- should be comput= ed+ICYgHQ- in Section 3.+ADw-o:p+AD4APA-/o:p+AD4APA-/span+AD4APA-/p+AD4- +ADw-p class+AD0AIg-MsoNormal+ACIAPgA8-span lang+AD0AIg-EN-US+ACI- style+AD= 0AIg-font-size:10.5pt+ADs-font-family:+ACY-quot+ADs-Calibri+ACY-quot+ADs-,+= ACY-quot+ADs-sans-serif+ACY-quot+ADsAOw- color:+ACM-1F497D+ACIAPg-This is a requirement, so I think it should use +I= Bw-SHOULD+IB0- instead of +IBw-should+IB0-. +ADw-o:p+AD4APA-/o:p+AD4APA-/span+AD4APA-/p+AD4- +ADw-p class+AD0AIg-MsoNormal+ACIAPgA8-span lang+AD0AIg-EN-US+ACI- style+AD= 0AIg-font-size:10.5pt+ADs-font-family:+ACY-quot+ADs-Calibri+ACY-quot+ADs-,+= ACY-quot+ADs-sans-serif+ACY-quot+ADsAOw- color:+ACM-1F497D+ACIAPg-But if this AES-CMAC is the only authentication me= chanism, it is better to use +IBw-MUST+IB0-.+ADw-o:p+AD4APA-/o:p+AD4APA-/sp= an+AD4APA-/p+AD4- +ADw-p class+AD0AIg-MsoNormal+ACIAPgA8-span lang+AD0AIg-EN-US+ACI- style+AD= 0AIg-font-size:10.5pt+ADs-font-family:+ACY-quot+ADs-Calibri+ACY-quot+ADs-,+= ACY-quot+ADs-sans-serif+ACY-quot+ADsAOw- color:+ACM-1F497D+ACIAPgA8-o:p+AD4AJg-nbsp+ADsAPA-/o:p+AD4APA-/span+AD4APA-= /p+AD4- +ADw-p class+AD0AIg-MsoListParagraph+ACI- style+AD0AIg-margin-left:18.0pt+A= Ds-text-indent:-18.0pt+ADs- mso-list:l0 level1 lfo1+ACIAPg- +ADwAIQBb-if +ACE-supportLists+AF0APgA8-span lang+AD0AIg-EN-US+ACI- style+A= D0AIg-font-size:10.5pt+ADs-font-family:+ACY-quot+ADs-Calibri+ACY-quot+ADs-,= +ACY-quot+ADs-sans-serif+ACY-quot+ADsAOw-color:+ACM-1F497D+ACIAPgA8-span st= yle+AD0AIg-mso-list:Ignore+ACIAPg-2.+ADw-span style+AD0AIg-font:7.0pt +ACY-= quot+ADs-Times New Roman+ACY-quot+ADsAIgA+ACY-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+= ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADs- +ADw-/span+AD4APA-/span+AD4APA-/span+AD4APAAhAFs-endif+AF0APgA8-span lang+A= D0AIg-EN-US+ACI- style+AD0AIg-font-size:10.5pt+ADs- font-family:+ACY-quot+ADs-Calibri+ACY-quot+ADs-,+ACY-quot+ADs-sans-serif+AC= Y-quot+ADsAOw-color:+ACM-1F497D+ACIAPiAc-We recommend that the MAC key for = NTP SHOULD be 128 bits long AES-128 key+ICYgHQ- in Section 3.+ADw-o:p+AD4AP= A-/o:p+AD4APA-/span+AD4APA-/p+AD4- +ADw-p class+AD0AIg-MsoNormal+ACIAPgA8-span lang+AD0AIg-EN-US+ACI- style+AD= 0AIg-font-size:10.5pt+ADs-font-family:+ACY-quot+ADs-Calibri+ACY-quot+ADs-,+= ACY-quot+ADs-sans-serif+ACY-quot+ADsAOw- color:+ACM-1F497D+ACIAPg-To be more formal, maybe it can be rephrased into = +IBw-It is RECOMMENDED that the MAC key for NTP SHOULD be 128 bits long AES= -128 key+ICYgHQA8-o:p+AD4APA-/o:p+AD4APA-/span+AD4APA-/p+AD4- +ADw-p class+AD0AIg-MsoNormal+ACIAPgA8-span lang+AD0AIg-EN-US+ACI- style+AD= 0AIg-font-size:10.5pt+ADs-font-family:+ACY-quot+ADs-Calibri+ACY-quot+ADs-,+= ACY-quot+ADs-sans-serif+ACY-quot+ADsAOw- color:+ACM-1F497D+ACIAPgA8-o:p+AD4AJg-nbsp+ADsAPA-/o:p+AD4APA-/span+AD4APA-= /p+AD4- +ADw-p class+AD0AIg-MsoListParagraph+ACI- style+AD0AIg-margin-left:18.0pt+A= Ds-text-indent:-18.0pt+ADs- mso-list:l0 level1 lfo1+ACIAPg- +ADwAIQBb-if +ACE-supportLists+AF0APgA8-span lang+AD0AIg-EN-US+ACI- style+A= D0AIg-font-size:10.5pt+ADs-font-family:+ACY-quot+ADs-Calibri+ACY-quot+ADs-,= +ACY-quot+ADs-sans-serif+ACY-quot+ADsAOw-color:+ACM-1F497D+ACIAPgA8-span st= yle+AD0AIg-mso-list:Ignore+ACIAPg-3.+ADw-span style+AD0AIg-font:7.0pt +ACY-= quot+ADs-Times New Roman+ACY-quot+ADsAIgA+ACY-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+= ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADs- +ADw-/span+AD4APA-/span+AD4APA-/span+AD4APAAhAFs-endif+AF0APgA8-span lang+A= D0AIg-EN-US+ACI- style+AD0AIg-font-size:10.5pt+ADs- font-family:+ACY-quot+ADs-Calibri+ACY-quot+ADs-,+ACY-quot+ADs-sans-serif+AC= Y-quot+ADsAOw-color:+ACM-1F497D+ACIAPgAm-quot+ADs-FOr test vectors and thei= r outputs refer to Section 4 of RFC 4493 +AFs-RFC4493+AF0AJg-quot+ADs- in S= ection 5 should be +IBw-For test vectors and their outputs refer to Section 4 of RFC 4493.+IB0APA-o:p+AD4APA-/o:p+AD4APA-/span+AD4APA= -/p+AD4- +ADw-p class+AD0AIg-MsoListParagraph+ACI- style+AD0AIg-margin-left:18.0pt+A= Ds-text-indent:0cm+ACIAPgA8-span lang+AD0AIg-EN-US+ACI- style+AD0AIg-font-s= ize:10.5pt+ADs-font-family:+ACY-quot+ADs-Calibri+ACY-quot+ADs-,+ACY-quot+AD= s-sans-serif+ACY-quot+ADsAOw- color:+ACM-1F497D+ACIAPgA8-o:p+AD4AJg-nbsp+ADsAPA-/o:p+AD4APA-/span+AD4APA-= /p+AD4- +ADw-p class+AD0AIg-MsoNormal+ACIAPgA8-span lang+AD0AIg-EN-US+ACI- style+AD= 0AIg-font-size:10.5pt+ADs-font-family:+ACY-quot+ADs-Calibri+ACY-quot+ADs-,+= ACY-quot+ADs-sans-serif+ACY-quot+ADsAOw- color:+ACM-1F497D+ACIAPg-Thanks,+ADw-o:p+AD4APA-/o:p+AD4APA-/span+AD4APA-/p= +AD4- +ADw-p class+AD0AIg-MsoNormal+ACIAPgA8-span lang+AD0AIg-EN-US+ACI- style+AD= 0AIg-font-size:10.5pt+ADs-font-family:+ACY-quot+ADs-Calibri+ACY-quot+ADs-,+= ACY-quot+ADs-sans-serif+ACY-quot+ADsAOw- color:+ACM-1F497D+ACIAPg-Yuanlong+ADw-o:p+AD4APA-/o:p+AD4APA-/span+AD4APA-/= p+AD4- +ADw-p class+AD0AIg-MsoNormal+ACIAPgA8-span lang+AD0AIg-EN-US+ACI- style+AD= 0AIg-font-size:10.5pt+ADs-font-family:+ACY-quot+ADs-Calibri+ACY-quot+ADs-,+= ACY-quot+ADs-sans-serif+ACY-quot+ADsAOw- color:+ACM-1F497D+ACIAPgA8-o:p+AD4AJg-nbsp+ADsAPA-/o:p+AD4APA-/span+AD4APA-= /p+AD4- +ADw-div+AD4- +ADw-div style+AD0AIg-border:none+ADs-border-top:solid +ACM-B5C4DF 1.0pt+AD= s-padding:3.0pt 0cm 0cm 0cm+ACIAPg- +ADw-p class+AD0AIg-MsoNormal+ACIAPgA8-b+AD4APA-span lang+AD0AIg-EN-US+ACI-= style+AD0AIg-font-size:10.0pt+ADs-font-family: +ACY-quot+ADs-Tahoma+ACY-quot+ADs-,+ACY-quot+ADs-sans-serif+ACY-quot+ADsAIg= A+-From:+ADw-/span+AD4APA-/b+AD4APA-span lang+AD0AIg-EN-US+ACI- style+AD0AI= g-font-size:10.0pt+ADs- font-family:+ACY-quot+ADs-Tahoma+ACY-quot+ADs-,+ACY-quot+ADs-sans-serif+ACY= -quot+ADsAIgA+- TICTOC +AFs-mailto:tictoc-bounces+AEA-ietf.org+AF0- +ADw-b+AD4-On Behalf Of +ADw-/b+AD4-Karen O'Donoghue+ADw-br+AD4- +ADw-b+AD4-Sent:+ADw-/b+AD4- Wednesday, August 09, 2017 12:54 PM+ADw-br+AD4= - +ADw-b+AD4-To:+ADw-/b+AD4- ntp+AEA-ietf.org+ADw-br+AD4- +ADw-b+AD4-Cc:+ADw-/b+AD4- tictoc+AEA-ietf.org+ADw-br+AD4- +ADw-b+AD4-Subject:+ADw-/b+AD4- +AFs-TICTOC+AF0- WGLC for draft-ietf-ntp-ma= c+ADw-o:p+AD4APA-/o:p+AD4APA-/span+AD4APA-/p+AD4- +ADw-/div+AD4- +ADw-/div+AD4- +ADw-p class+AD0AIg-MsoNormal+ACIAPgA8-span lang+AD0AIg-EN-US+ACIAPgA8-o:p+= AD4AJg-nbsp+ADsAPA-/o:p+AD4APA-/span+AD4APA-/p+AD4- +ADw-p class+AD0AIg-MsoNormal+ACIAPgA8-span lang+AD0AIg-EN-US+ACIAPg-Folks,= +ADw-br+AD4- +ADw-br+AD4- This begins a three week working group last call (WGLC) for +ACY-quot+ADs-M= essage Authentication Code for the Network Time Protocol+ACY-quot+ADsAPA-br= +AD4- +ADw-a href+AD0AIg-https://datatracker.ietf.org/doc/draft-ietf-ntp-mac/+ACI= APg-https://datatracker.ietf.org/doc/draft-ietf-ntp-mac/+ADw-/a+AD4- +ADw-o:p+AD4APA-/o:p+AD4APA-/span+AD4APA-/p+AD4- +ADw-div+AD4- +ADw-p class+AD0AIg-MsoNormal+ACIAPgA8-span lang+AD0AIg-EN-US+ACIAPgA8-br+A= D4- Please review and provide comments to the mailing list by no later than 31 = August 2017. Earlier comments and discussion would be appreciated. Please n= ote that the chairs will be using this WGLC to determine consensus to move = this document forward to the IESG.+ACY-nbsp+ADsAPA-br+AD4- +ADw-br+AD4- Also, as a reminder, we have migrated the working group mailing list to IET= F infrastructure. Please respond to+ACY-nbsp+ADsAPA-a href+AD0AIg-mailto:nt= p+AEA-ietf.org+ACIAPg-ntp+AEA-ietf.org+ADw-/a+AD4-.+ACY-nbsp+ADsAPA-br+AD4- +ADw-br+AD4- Regards,+ADw-br+AD4- Karen and Dieter+ADw-o:p+AD4APA-/o:p+AD4APA-/span+AD4APA-/p+AD4- +ADw-/div+AD4- +ADw-/div+AD4- +ADw-/body+AD4- +ADw-/html+AD4- --_000_3B0A1BED22CAD649A1B3E97BE5DDD68BBB599924dggeml507mbxchi_-- --===============8499278290473167402== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp --===============8499278290473167402==-- From nobody Tue Aug 29 16:49:55 2017 Return-Path: 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 3A44C132D91 for ; Tue, 29 Aug 2017 16:49:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=libertysys.com.au 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 9mJwKq21LBxA for ; Tue, 29 Aug 2017 16:49:51 -0700 (PDT) Received: from mail.libertysys.com.au (ppp178-79.static.internode.on.net [150.101.178.79]) (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 1EC07132113 for ; Tue, 29 Aug 2017 16:49:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.libertysys.com.au (Postfix) with ESMTP id 3A5DF9245A for ; Wed, 30 Aug 2017 09:49:49 +1000 (AEST) X-Virus-Scanned: Debian amavisd-new at mail2.gear.dyndns.org Received: from mail.libertysys.com.au ([127.0.0.1]) by localhost (mail.gear.dyndns.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uGJDT-Qf80R3 for ; Wed, 30 Aug 2017 09:49:42 +1000 (AEST) Received: from [172.22.64.102] (eber-home.gear.dyndns.org [172.22.64.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.libertysys.com.au (Postfix) with ESMTPSA id 9572C920C2 for ; Wed, 30 Aug 2017 09:49:42 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=libertysys.com.au; s=2016; t=1504050582; bh=7vV+dhSUK77kBz7ui3/TS5Io/aK2SAF7sxY3RuDBmjQ=; h=From:Subject:To:References:Date:In-Reply-To; b=J0HqxhfMIeMhhi3Ks6VopJ7dU/R0yjmRNcF6KVW/Q4lZCWptcT+y+mMLWZbgZ03ug Ewu9t2vtiM8eAbgHsJsJHNUfjnMJ6l3+Kzi/UEctSrKow/x2ymBNnFKhGEjgUHimnm Ke7ouFSRnEi9hKmq87y1WFC9cxeuEg1+DufsCmew= From: Paul Gear To: ntp@ietf.org References: <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> <766290C1-0828-4DAC-9437-4FF1EE5DC02E@isoc.org> Message-ID: <83807079-2798-8de3-c683-39db32693f2f@libertysys.com.au> Date: Wed, 30 Aug 2017 09:49:42 +1000 MIME-Version: 1.0 In-Reply-To: <766290C1-0828-4DAC-9437-4FF1EE5DC02E@isoc.org> Content-Type: multipart/alternative; boundary="------------82F1D689D69D9E1DF3117B56" Content-Language: en-AU Archived-At: Subject: Re: [Ntp] REMINDER: WGLC for draft-ietf-ntp-using-nts-for-ntp X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Aug 2017 23:49:54 -0000 This is a multi-part message in MIME format. --------------82F1D689D69D9E1DF3117B56 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Hi everyone, I sent a few minor comments to the list on 2017-08-11 but it looks like I sent from the wrong address. Here they are again. Point 2 has already been covered. 1. There are a number of non-capitalised occurrences of "may", "should", and "should not" on page 6 - is this intentional, or should they be capitalised as RFC 2119 references? 2. The phrase "symmetry active peer" towards the end of page 6 presumably should read "symmetric active peer". 3. Is "Cookie placeholder" (sect 6.5) the best name for this extension? It's intended to function as a cookie request, so wouldn't "Cookie request" be a better name for it? 4. Section 7 also contains some non-capitalised "should" references, which may need to be replaced with RFC 2119 references. Similarly, it uses the language "it need not be the same as the one that was negotiated with the client" - should "need not" be reworded in terms of MAY or OPTIONAL? 5. Section 9.3 states that "Pools in existence as of 2017 are volunteer-run, with ... no organized effort to monitor pool servers for misbehavior." I'm not sure how this can be considered accurate for pool.ntp.org - a centrally-maintained host checks the reachability and offset in for every participating host in the pool, removes them from DNS if they misbehave, and publishes public results of this process. That is clearly an "organized effort to monitor". I've been working on a talk for AusNOG 2017 in Melbourne which covers the outstanding drafts, and have really learned a lot from going through them repeatedly over the past couple of weeks. I have a few technical comments which are more appropriate as replies to other threads so I'll make those comments separately. Regards, Paul On 29/08/17 12:25, Karen O'Donoghue wrote: > Folks, > > The working group last call for this document has been out for almost three weeks now. Please respond immediately with technical comments and an indication of whether or not you approve the advancement of this document. > > Regards, > Karen > >> On Aug 9, 2017, at 12:41 AM, Karen O'Donoghue wrote: >> >> Folks, >> >> This begins a three week working group last call (WGLC) for "Network Time Security for the Network Time Protocolâ€. >> >> https://datatracker.ietf.org/doc/draft-ietf-ntp-using-nts-for-ntp/ >> >> Please review and provide comments to the mailing list by no later than 31 August 2017. Earlier comments and discussion would be appreciated. Please note that the chairs will be using this WGLC to determine consensus to move this document forward to the IESG. >> >> Also, as a reminder, we have migrated the working group mailing list to IETF infrastructure. Please respond to ntp@ietf.org. ] >> >> Regards, >> Karen and Dieter >> _______________________________________________ >> ntp mailing list >> ntp@ietf.org >> https://www.ietf.org/mailman/listinfo/ntp > _______________________________________________ > ntp mailing list > ntp@ietf.org > https://www.ietf.org/mailman/listinfo/ntp --------------82F1D689D69D9E1DF3117B56 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi everyone,

I sent a few minor comments to the list on 2017-08-11 but it looks like I sent from the wrong address.  Here they are again.  Point 2 has already been covered.

  1. There are a number of non-capitalised occurrences of "may", "should", and "should not" on page 6 - is this intentional, or should they be capitalised as RFC 2119 references?
  2. The phrase "symmetry active peer" towards the end of page 6 presumably should read "symmetric active peer".
  3. Is "Cookie placeholder" (sect 6.5) the best name for this extension?  It's intended to function as a cookie request, so wouldn't "Cookie request" be a better name for it?
  4. Section 7 also contains some non-capitalised "should" references, which may need to be replaced with RFC 2119 references.  Similarly, it uses the language "it need not be the same as the one that was negotiated with the client" - should "need not" be reworded in terms of MAY or OPTIONAL?
  5. Section 9.3 states that "Pools in existence as of 2017 are volunteer-run, with ... no organized effort to monitor pool servers for misbehavior."  I'm not sure how this can be considered accurate for pool.ntp.org - a centrally-maintained host checks the reachability and offset in for every participating host in the pool, removes them from DNS if they misbehave, and publishes public results of this process.  That is clearly an "organized effort to monitor".
I've been working on a talk for AusNOG 2017 in Melbourne which covers the outstanding drafts, and have really learned a lot from going through them repeatedly over the past couple of weeks.  I have a few technical comments which are more appropriate as replies to other threads so I'll make those comments separately.

Regards,
Paul

On 29/08/17 12:25, Karen O'Donoghue wrote:
Folks,

The working group last call for this document has been out for almost three weeks now. Please respond immediately with technical comments and an indication of whether or not you approve the advancement of this document. 

Regards,
Karen


On Aug 9, 2017, at 12:41 AM, Karen O'Donoghue <odonoghue@isoc.org> wrote:

Folks,

This begins a three week working group last call (WGLC) for "Network Time Security for the Network Time Protocolâ€.

https://datatracker.ietf.org/doc/draft-ietf-ntp-using-nts-for-ntp/

Please review and provide comments to the mailing list by no later than 31 August 2017. Earlier comments and discussion would be appreciated. Please note that the chairs will be using this WGLC to determine consensus to move this document forward to the IESG. 

Also, as a reminder, we have migrated the working group mailing list to IETF infrastructure. Please respond to ntp@ietf.org. ]

Regards,
Karen and Dieter
_______________________________________________
ntp mailing list
ntp@ietf.org
https://www.ietf.org/mailman/listinfo/ntp

_______________________________________________
ntp mailing list
ntp@ietf.org
https://www.ietf.org/mailman/listinfo/ntp

--------------82F1D689D69D9E1DF3117B56-- From ntp-bounces@ietf.org Tue Aug 29 16:49:55 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B0012132B9B; Tue, 29 Aug 2017 16:49:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1504050595; bh=DIv+NDzyXMiZxI5RMElFNkWrt0LlMTlcIrfFsoMUFmc=; h=From:To:References:Date:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe; b=JZ/U53i3orghTPcBOtlx4aQOM9z+5uOMGg9qBpRtjxDCdMroOplq2q1rRDdHGygha n28uBvKDrpsezV8UcREfM+U+rK/4nlLFF+lQyCCzx057JhICjA9qDlM2qFhUWBDMCK fltSLiLhEgWiwbPhUQWD/fQcqc2cJrp0qXA0S7wY= 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 3A44C132D91 for ; Tue, 29 Aug 2017 16:49:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=libertysys.com.au 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 9mJwKq21LBxA for ; Tue, 29 Aug 2017 16:49:51 -0700 (PDT) Received: from mail.libertysys.com.au (ppp178-79.static.internode.on.net [150.101.178.79]) (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 1EC07132113 for ; Tue, 29 Aug 2017 16:49:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.libertysys.com.au (Postfix) with ESMTP id 3A5DF9245A for ; Wed, 30 Aug 2017 09:49:49 +1000 (AEST) X-Virus-Scanned: Debian amavisd-new at mail2.gear.dyndns.org Received: from mail.libertysys.com.au ([127.0.0.1]) by localhost (mail.gear.dyndns.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uGJDT-Qf80R3 for ; Wed, 30 Aug 2017 09:49:42 +1000 (AEST) Received: from [172.22.64.102] (eber-home.gear.dyndns.org [172.22.64.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.libertysys.com.au (Postfix) with ESMTPSA id 9572C920C2 for ; Wed, 30 Aug 2017 09:49:42 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=libertysys.com.au; s=2016; t=1504050582; bh=7vV+dhSUK77kBz7ui3/TS5Io/aK2SAF7sxY3RuDBmjQ=; h=From:Subject:To:References:Date:In-Reply-To; b=J0HqxhfMIeMhhi3Ks6VopJ7dU/R0yjmRNcF6KVW/Q4lZCWptcT+y+mMLWZbgZ03ug Ewu9t2vtiM8eAbgHsJsJHNUfjnMJ6l3+Kzi/UEctSrKow/x2ymBNnFKhGEjgUHimnm Ke7ouFSRnEi9hKmq87y1WFC9cxeuEg1+DufsCmew= From: Paul Gear To: ntp@ietf.org References: <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> <766290C1-0828-4DAC-9437-4FF1EE5DC02E@isoc.org> Message-ID: <83807079-2798-8de3-c683-39db32693f2f@libertysys.com.au> Date: Wed, 30 Aug 2017 09:49:42 +1000 MIME-Version: 1.0 In-Reply-To: <766290C1-0828-4DAC-9437-4FF1EE5DC02E@isoc.org> Content-Language: en-AU Archived-At: Subject: Re: [Ntp] REMINDER: WGLC for draft-ietf-ntp-using-nts-for-ntp X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============5091640641026386879==" Errors-To: ntp-bounces@ietf.org Sender: "ntp" This is a multi-part message in MIME format. --===============5091640641026386879== Content-Type: multipart/alternative; boundary="------------82F1D689D69D9E1DF3117B56" Content-Language: en-AU This is a multi-part message in MIME format. --------------82F1D689D69D9E1DF3117B56 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Hi everyone, I sent a few minor comments to the list on 2017-08-11 but it looks like I sent from the wrong address. Here they are again. Point 2 has already been covered. 1. There are a number of non-capitalised occurrences of "may", "should", and "should not" on page 6 - is this intentional, or should they be capitalised as RFC 2119 references? 2. The phrase "symmetry active peer" towards the end of page 6 presumably should read "symmetric active peer". 3. Is "Cookie placeholder" (sect 6.5) the best name for this extension? It's intended to function as a cookie request, so wouldn't "Cookie request" be a better name for it? 4. Section 7 also contains some non-capitalised "should" references, which may need to be replaced with RFC 2119 references. Similarly, it uses the language "it need not be the same as the one that was negotiated with the client" - should "need not" be reworded in terms of MAY or OPTIONAL? 5. Section 9.3 states that "Pools in existence as of 2017 are volunteer-run, with ... no organized effort to monitor pool servers for misbehavior." I'm not sure how this can be considered accurate for pool.ntp.org - a centrally-maintained host checks the reachability and offset in for every participating host in the pool, removes them from DNS if they misbehave, and publishes public results of this process. That is clearly an "organized effort to monitor". I've been working on a talk for AusNOG 2017 in Melbourne which covers the outstanding drafts, and have really learned a lot from going through them repeatedly over the past couple of weeks. I have a few technical comments which are more appropriate as replies to other threads so I'll make those comments separately. Regards, Paul On 29/08/17 12:25, Karen O'Donoghue wrote: > Folks, > > The working group last call for this document has been out for almost three weeks now. Please respond immediately with technical comments and an indication of whether or not you approve the advancement of this document. > > Regards, > Karen > >> On Aug 9, 2017, at 12:41 AM, Karen O'Donoghue wrote: >> >> Folks, >> >> This begins a three week working group last call (WGLC) for "Network Time Security for the Network Time Protocolâ€. >> >> https://datatracker.ietf.org/doc/draft-ietf-ntp-using-nts-for-ntp/ >> >> Please review and provide comments to the mailing list by no later than 31 August 2017. Earlier comments and discussion would be appreciated. Please note that the chairs will be using this WGLC to determine consensus to move this document forward to the IESG. >> >> Also, as a reminder, we have migrated the working group mailing list to IETF infrastructure. Please respond to ntp@ietf.org. ] >> >> Regards, >> Karen and Dieter >> _______________________________________________ >> ntp mailing list >> ntp@ietf.org >> https://www.ietf.org/mailman/listinfo/ntp > _______________________________________________ > ntp mailing list > ntp@ietf.org > https://www.ietf.org/mailman/listinfo/ntp --------------82F1D689D69D9E1DF3117B56 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi everyone,

I sent a few minor comments to the list on 2017-08-11 but it looks like I sent from the wrong address.  Here they are again.  Point 2 has already been covered.

  1. There are a number of non-capitalised occurrences of "may", "should", and "should not" on page 6 - is this intentional, or should they be capitalised as RFC 2119 references?
  2. The phrase "symmetry active peer" towards the end of page 6 presumably should read "symmetric active peer".
  3. Is "Cookie placeholder" (sect 6.5) the best name for this extension?  It's intended to function as a cookie request, so wouldn't "Cookie request" be a better name for it?
  4. Section 7 also contains some non-capitalised "should" references, which may need to be replaced with RFC 2119 references.  Similarly, it uses the language "it need not be the same as the one that was negotiated with the client" - should "need not" be reworded in terms of MAY or OPTIONAL?
  5. Section 9.3 states that "Pools in existence as of 2017 are volunteer-run, with ... no organized effort to monitor pool servers for misbehavior."  I'm not sure how this can be considered accurate for pool.ntp.org - a centrally-maintained host checks the reachability and offset in for every participating host in the pool, removes them from DNS if they misbehave, and publishes public results of this process.  That is clearly an "organized effort to monitor".
I've been working on a talk for AusNOG 2017 in Melbourne which covers the outstanding drafts, and have really learned a lot from going through them repeatedly over the past couple of weeks.  I have a few technical comments which are more appropriate as replies to other threads so I'll make those comments separately.

Regards,
Paul

On 29/08/17 12:25, Karen O'Donoghue wrote:
Folks,

The working group last call for this document has been out for almost three weeks now. Please respond immediately with technical comments and an indication of whether or not you approve the advancement of this document. 

Regards,
Karen


On Aug 9, 2017, at 12:41 AM, Karen O'Donoghue <odonoghue@isoc.org> wrote:

Folks,

This begins a three week working group last call (WGLC) for "Network Time Security for the Network Time Protocolâ€.

https://datatracker.ietf.org/doc/draft-ietf-ntp-using-nts-for-ntp/

Please review and provide comments to the mailing list by no later than 31 August 2017. Earlier comments and discussion would be appreciated. Please note that the chairs will be using this WGLC to determine consensus to move this document forward to the IESG. 

Also, as a reminder, we have migrated the working group mailing list to IETF infrastructure. Please respond to ntp@ietf.org. ]

Regards,
Karen and Dieter
_______________________________________________
ntp mailing list
ntp@ietf.org
https://www.ietf.org/mailman/listinfo/ntp

_______________________________________________
ntp mailing list
ntp@ietf.org
https://www.ietf.org/mailman/listinfo/ntp

--------------82F1D689D69D9E1DF3117B56-- --===============5091640641026386879== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp --===============5091640641026386879==-- From ntp-bounces@ietf.org Tue Aug 29 16:52:21 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FBB6132A94; Tue, 29 Aug 2017 16:52:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1504050741; bh=0ux4N4DSiYuvQqFgWDzA4jSfulc5L1FyBjN58sPuPQI=; h=From:To:Date:References:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc; b=EDHCqt5Wu8rSwiUtw667IlPTzQF1hiYLHK9WNl85be0evp5IqkhL7ulLBoNCqTEfj u1jsF/hHzA7unN9+rVC6jaUmGoKW+YtayyG5SVByljzbOLlouH7mf5LUx3dGX/4TtG 1vzNqUaunYdq8svBML6c2XS9E+VjU3PfuuEGewdI= 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 B4068132A94; Tue, 29 Aug 2017 16:52:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.699 X-Spam-Level: X-Spam-Status: No, score=-4.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mscc365.onmicrosoft.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 E2FWvxTZjxJk; Tue, 29 Aug 2017 16:52:16 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0065.outbound.protection.outlook.com [104.47.40.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8668C132113; Tue, 29 Aug 2017 16:52:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mscc365.onmicrosoft.com; s=selector1-microsemi-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=d90r7ICy62H9nn55PLEcwHglm+Z9LZ1LGOGt6bGLdVA=; b=dd+G8VKFoDKHGWHfwOh6BcYoURMnUNMPtPJm6acFpoHjLO/FhSBxBPLDngbfv97LW1djS4zjPbgjYJ8ZpmosVD5U7ky36xndqO03EtjXSWW5tkiyvuJhy5CoUFfCW2nSIBbyEYYhNDi5fc3sagS9QUOsXMdvQsOjKg/bBg/soP0= Received: from CY4PR02CA0002.namprd02.prod.outlook.com (10.169.188.12) by CY1PR0201MB1498.namprd02.prod.outlook.com (10.163.139.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.13.10; Tue, 29 Aug 2017 23:52:15 +0000 Received: from BL2FFO11FD031.protection.gbl (2a01:111:f400:7c09::146) by CY4PR02CA0002.outlook.office365.com (2603:10b6:903:18::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.13.10 via Frontend Transport; Tue, 29 Aug 2017 23:52:15 +0000 Authentication-Results: spf=pass (sender IP is 208.19.100.21) smtp.mailfrom=microsemi.com; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=microsemi.com; Received-SPF: Pass (protection.outlook.com: domain of microsemi.com designates 208.19.100.21 as permitted sender) receiver=protection.outlook.com; client-ip=208.19.100.21; helo=avsrvexchhts1.microsemi.net; Received: from avsrvexchhts1.microsemi.net (208.19.100.21) by BL2FFO11FD031.mail.protection.outlook.com (10.173.160.71) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.1341.15 via Frontend Transport; Tue, 29 Aug 2017 23:52:14 +0000 Received: from SJSRVEXCHHTS1.microsemi.net (10.241.34.105) by avsrvexchhts1.microsemi.net (10.100.34.105) with Microsoft SMTP Server (TLS) id 14.3.361.1; Tue, 29 Aug 2017 16:52:13 -0700 Received: from SJSRVEXCHMBX1.microsemi.net ([fe80::19b5:ac43:d8de:5120]) by sjsrvexchhts1.microsemi.net ([::1]) with mapi id 14.03.0361.001; Tue, 29 Aug 2017 16:52:12 -0700 From: Greg Dowd To: Karen O'Donoghue , "ntp@ietf.org" Thread-Topic: REMINDER: WGLC for draft-ietf-ntp-mac Thread-Index: AQHTEMt6dgTCyuPEXEODOT5Gsnqn3aKbMBOAgADx5oA= Date: Tue, 29 Aug 2017 23:52:13 +0000 Message-ID: <8D2BF679AAC7C346848A489074F9F8BFD2830065@sjsrvexchmbx1.microsemi.net> References: <80E159E7-17F1-4B0E-8DA1-07581DF7FC6C@isoc.org> In-Reply-To: <80E159E7-17F1-4B0E-8DA1-07581DF7FC6C@isoc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.241.128.48] MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:208.19.100.21; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10009020)(39860400002)(2980300002)(438002)(189002)(24454002)(199003)(12213003)(377454003)(53416004)(6246003)(189998001)(55846006)(260700001)(478600001)(72206003)(4326008)(76176999)(54356999)(50986999)(626005)(9686003)(2920100001)(2900100001)(2950100002)(2501003)(5250100002)(69596002)(512954002)(236005)(54896002)(6306002)(8666007)(106466001)(53936002)(229853002)(33656002)(230783001)(2906002)(8936002)(5660300001)(356003)(53546010)(68736007)(606006)(102836003)(6116002)(790700001)(966005)(81166006)(7696004)(81156014)(7736002)(8676002)(3846002)(97736004)(84326002)(86362001); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR0201MB1498; H:avsrvexchhts1.microsemi.net; FPR:; SPF:Pass; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11FD031; 1:sDjK5SaMRpDCy+46ouuAygJiUH25DhXl1IC0CIRRJdf6sqU8n0u4SDDQM9GHL5tFUl964aoMMmaD2iBkv+6LpbCGWontQqkN6bLm9TDh8R5yuiVkKQpOIZHeBciBlq9w X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: a5fe372a-98ce-464c-e4b2-08d4ef38f937 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(8251501002)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY1PR0201MB1498; X-Microsoft-Exchange-Diagnostics: 1; CY1PR0201MB1498; 3:tWCWig0PoKM8NF7YAdcUNxNbg74rlNUTuBb+W5jUChk1uC1npc7eOLjXZI/Zccmip/HeS2/geRZP1fkxSWPTabEHAAIkG3maYxpSE6xHtmVBI9IoJpCM2PBH1ZCHi9O3GpoVraaPpjBk4zVA5Vk712xHXZV1p5NJDeMC4JQGSZ72E1wbdJETA8nJpu+GLsIxSCjmtWYbUyHWZxyIYPo7YxKLKf2oMlq6d1/uFm7sV5v7NH1vlRRhR8fa8Tq49E29a0s6fAPmOQPYhJmiBodPRONouOQTOBw49tlWSxsRQ3OABP/5w7oaKLkBiJ3boDetoVotsT3OypktBZ8dDcFGWtxWp+YA7uZjZVDe5tNtyWU=; 25:nONDDzKsJMGGQlnxbINAgU/mcB1W3BCyfjTUoidcUqpB47jaD0xxGNnKxmMe8Fix1MY4GO4eodVdK31Nucvs/ptMojKeTxQUeHM3h0nxJl474ti4YPJBSZvJVi6JCWguBp0hrdL3xluovagjbTFMyQJtYOLmLeTCFfCizaNUhzGGkRMkJN3rDjRY0TimpNrXrSZ7dMfd9J0q0MQ5HiWt8pXxRflZRXmW959VoJlHTdoQTv3sOXbcmZza7lEgDw7jD9I2UHKHCxPTjfWH+moGqnVFhfT8MSSyZjiXSf9MwOCnPqwpdmP3J7MDhRXzGK6yVktb+ub48AOxdNSGAT1Xng== X-MS-TrafficTypeDiagnostic: CY1PR0201MB1498: X-Microsoft-Exchange-Diagnostics: 1; CY1PR0201MB1498; 31:8UHjohTFA10fCnU5U3sZXYpUE3pRNm9GudXcwwBfJULazxOBKx+zSOdVwOORgk7+OVjHpCMYRQiM3DfClIHRv7AIRmkiRWAu/29s+TTdiuFXlzmwrltIveXbZHAuWeUSIYox/XTHvhGNIrs84AZxMOTag80USsA2opRsM+YPaVM3uKdisjimPoDDiWO9wqHlDp1Jywad6WyccsFLTyOy6QTI7GNm0qdHmzh5yKD1OtM=; 20:c6O3qz5Gc/VFLAn1AuC6+fhaBZQ50EjQizdrEG9czHB48kOtVOa8UT6XKhFX4bEZXbqQg/D0XgAo984+3EjkOhGNL3DrkIAe2ve890wHfRarA+PvdKgs8NCPNM6gkc0IUnLfnhndynEkBn3wJMpmf3v3NQGMnn5zi8FmjvjkvvFMnlDS2HC9qiivl6PY7/haMwfXOyMmLNI8CsmIIjUMuxWpeT5Crhth7bMUzANUd2ikdRZmt/h1aK3dwlIWySalBPUgbW3VnCpYBajjixmz+/nem8oIuM6znbWVREdQ8SMzmqpcc9MImB1It0S1mcAuC3FzWOMNiSL0VEZ6DTEhYvdA+zb6oyihCo7b9uGrtwVj1LOZ3kxKSp/NUZhb0gl4DKFiNewG91hkj83pnV3Fw3/2faR5CWMsZwAdh8uQKAAv0T3sJAOTjdnc13DP/RbcxiC09+H6Av8naZgOHVg+2wGkyV8IjTmlRQyCU6NEnCvwmax43OWoey5YwXaEZyet X-Exchange-Antispam-Report-Test: UriScan:(120809045254105)(100405760836317)(21748063052155); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(13016025)(13018025)(8121501046)(5005006)(100000703101)(100105400095)(3002001)(93006095)(93004095)(10201501046)(6055026)(6041248)(20161123564025)(20161123558100)(20161123562025)(20161123560025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY1PR0201MB1498; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY1PR0201MB1498; X-Microsoft-Exchange-Diagnostics: 1; CY1PR0201MB1498; 4:C3YAJ3Jh54mItQKvs6UyiLwXMyLcUwxOAmZKwZikOkT3TyJ20DU6Mt7kEIR44gljcbmlfFTB49BE044SJcuzimo7dhYRNpczppIDsG0iAhV0XfFVVsedI6QYLxY9TvPmQ8ZKyf/TIj3MV3xiaKicwq/UeoIofp8efaf+gfiAHw5gljoqDSCe/uftnnpTiBa+vNw0qd7ybyi/gJw0Cmmmuc4jrVSf9Xhy4irFNj6mQ3sIr2RzIg3S1hfwRw1qWBJbiC9yAIHJ+bUEDLc61YI3SK1N6mnjsF298q7yWhomoxqdKDB7ShHNQrYbcHlE/HwYcBCSRfEwxFOoI5vP18Rzsd3uXGJfL9+gYYGw9ljERlNeuWSXaNjOFmFQ1MNjLLpT X-Forefront-PRVS: 0414DF926F X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR0201MB1498; 23:kPZyd0ahI3xEIoZJLIne50cl+6xZ71oZDscMUCv?= =?us-ascii?Q?+b/CEziS2ROUv392mFM4nAcl+dbfA2aIL7UeAbL9+G0qoKrdorZOga0arC7+?= =?us-ascii?Q?vlv3uFyvNCgie3O6dQYrF040WMwJOiZvtJ+yjWkXBBrsIFcfgGDBynA3Z9M9?= =?us-ascii?Q?AjK3A+UD6CApHHQxaVFz4cZHxcj4n7/7RJWamgQr4ZkSIDLTFUu86QY01pqP?= =?us-ascii?Q?f4gfqEKW2LoCYy48z/Zp2jPxjXG11oRCBwHRCS7IK5EQp/zoVUITv04Hxcqp?= =?us-ascii?Q?YFTULF5z2wBnWisFcDY9MwoRXhL+fCkuiNnb3DhzbUTfvPGZgcgpHBOPC1eQ?= =?us-ascii?Q?s4XOLUtMZG1PXeBGvdsHzEC8xtWYOClvfEbUxrQFwNdvQOyPFy6aN4NUz642?= =?us-ascii?Q?yRYbM5crLZAMGEaIcaKH5FNh6EGJC1FR9CZMfGMZ3XBNiqbI/zpEo1+OXqUS?= =?us-ascii?Q?LkcR74d+y2/1+oBsgj+TEr3PyUE8sP83pC/vHyV5bT4j23MqQH+MeDE7/bW0?= =?us-ascii?Q?G6vxW2zDu9zt5g13Go0OBL+l3Z1rz1aW8lmwmLIkNX2keSCXrRG9MW46aAUE?= =?us-ascii?Q?MV0C/4mr3KCzUjIENd1e5KtXrQzf2bqcOoyC9/KUzmg4wyQjw7nzSObwrzYx?= =?us-ascii?Q?3z8Edx5isPoseH88EDC8RSZn5cv9zgpYKhJKvM2mZH/N/L5cvhIYZFHaOHyR?= =?us-ascii?Q?gOSbeS5bH3AMNLQnU8BGsiN4ZiBHSQkhdQ2XGxjaefAjZvWgjJpPG/+5VRoH?= =?us-ascii?Q?5QwHG7LcMOCJ0DFOTQKg9GiYegubXW78mm/TRaYFUqAQ9KHO5+kDDm9Y5wsa?= =?us-ascii?Q?ZyqHE1ttiBnlKS9ECML78A4HHwn7gvgRrwXIJbJCEBtG65vMV8jqEBPmrwJn?= =?us-ascii?Q?pt7CfGvNN855vZGkHEAr/pVNgORAnM0/25MjlYlL7TU6UoyjiEl3f6mMrUw7?= =?us-ascii?Q?o3CFGDBH9L3AOIGLHDF7ceL0iEVcKYxmQJwkyxNE0+dHEJmMiPv46aM0mbkt?= =?us-ascii?Q?iP8B2KWoRwPVFelpr565sedjPlfhmq2J0NFbECe8KSHd252E3nJH50OCWrfi?= =?us-ascii?Q?cyEiZ7vhKkLRCb1O5k9nD2leDeI+v5ivbHFZE9+ZwgEf38j98YVeKc/e0dHf?= =?us-ascii?Q?fLi73D6HaFhtpeLMVcoxuwOvERT0P9zIUilwa73VUT7oli6Dy0udRg7MCkFz?= =?us-ascii?Q?RO0tS1X660HlQBbenqHwtBRUIqOB/bs8KpVOcIIgkOhnzClonboWyHBwqZ3b?= =?us-ascii?Q?JnwxWsWI10QnzUtToKQByR2QcNQOraNDqvVIp8oxUPwny2qUU1dgSBs5TWsP?= =?us-ascii?Q?RCZajnhFmCg7i8dG4pjgtvik=3D?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR0201MB1498; 6:+ZZJAxDA1dEoZO2NHDJFP+66aqeUOYS5vzoX9klIEHZFjCOPnYjjYRV+khg5rspX9qK9E7rxU6HlLvODsVPTS9Uw5fbvMFGOLW7mFiOdIYwBPvpkMSm9/K7Ld1iPmFz35+DtOLB7yRAPjcV3FcrGTSXEaHnDBh1VzP2cPL6M23uXxSa7gT1Z0iY6JUjojHBM5STXeJW0TzMQ8gW0vrvC4j4YLFya1M9mL4Vg0UE3mQqDcosBWPCnaYCk+YAG6LsraYsCPKU8e1UQuBxR6LMGueUZVxU4ZOccDzi22KiGki9f2OJdBs2ksp0UPvPbzyLEiMMYara5FoTOQWPfhEfGBQ==; 5:LWTmNFFGjtFXlNREhlkf9joQnnBnAw3vE3pOYrwWOdhH/8hwa6k5TPUgYjWZ9ttIm33RwgPCeTH5+4YHN23/dXyjjyVfkeCbA1tJm5uFrU9lex4CgBhihD9Pb+DZAnAS/KkvxZNIlHF5vZC1sKqBoA==; 24:xX0UXqiVzkpQyrObdFhbJL0k/CqjEiBMY6LwF7YxurWZQ1ck373aW8BdM93O7/lkQIcw05ueayHSfTHq6bZOS6uKw0oonBre0K1xAlLU/lg=; 7:M7I01UcATP51NOtNRZ9uhJ8lg/tb+MvjhFNuPnmjn4tIwfFUrx5E+S7eSrLjJ1gCOI0mqA4WmgnpUZkl4FPXMDFIgNvhKGge6Boa1Fc/mVsP0w7ZMLh+vY4l+yBQ8/0JBXbrOMqEuRCC/sL2SsfYyxw5KSsWyeKKeHP7ex5XqYQIc9nh4YVA4iM+wc5GT+rxdzpIeN9ZJmmQJm12RRen1rEwiv9vLTbZvEqEGP63XNY= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: microsemi.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Aug 2017 23:52:14.0579 (UTC) X-MS-Exchange-CrossTenant-Id: f267a5c8-86d8-4cc9-af71-1fd2c67c8fad X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f267a5c8-86d8-4cc9-af71-1fd2c67c8fad; Ip=[208.19.100.21]; Helo=[avsrvexchhts1.microsemi.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0201MB1498 Archived-At: Subject: Re: [Ntp] REMINDER: WGLC for draft-ietf-ntp-mac X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "tictoc@ietf.org" Content-Type: multipart/mixed; boundary="===============1587603915889627539==" Errors-To: ntp-bounces@ietf.org Sender: "ntp" --===============1587603915889627539== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_8D2BF679AAC7C346848A489074F9F8BFD2830065sjsrvexchmbx1mi_" --_000_8D2BF679AAC7C346848A489074F9F8BFD2830065sjsrvexchmbx1mi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I approve of advancing this draft. Thanks...Greg From: ntp [mailto:ntp-bounces@ietf.org] On Behalf Of Karen O'Donoghue Sent: Monday, August 28, 2017 7:26 PM To: ntp@ietf.org Cc: tictoc@ietf.org Subject: [Ntp] REMINDER: WGLC for draft-ietf-ntp-mac EXTERNAL EMAIL Folks, The working group last call for this document has been out for almost three= weeks now. Please respond immediately with technical comments and an indic= ation of whether or not you approve the advancement of this document. Regards, Karen On Aug 9, 2017, at 12:53 AM, Karen O'Donoghue > wrote: Folks, This begins a three week working group last call (WGLC) for "Message Authen= tication Code for the Network Time Protocol" https://datatracker.ietf.org/doc/draft-ietf-ntp-mac/ Please review and provide comments to the mailing list by no later than 31 = August 2017. Earlier comments and discussion would be appreciated. Please n= ote that the chairs will be using this WGLC to determine consensus to move = this document forward to the IESG. Also, as a reminder, we have migrated the working group mailing list to IET= F infrastructure. Please respond to ntp@ietf.org. Regards, Karen and Dieter _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp --_000_8D2BF679AAC7C346848A489074F9F8BFD2830065sjsrvexchmbx1mi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I approve of advancing this draft.  Thanks̷= 0;Greg

 

 

From: ntp [mailto:ntp-bounces@ietf.org] On= Behalf Of Karen O'Donoghue
Sent: Monday, August 28, 2017 7:26 PM
To: ntp@ietf.org
Cc: tictoc@ietf.org
Subject: [Ntp] REMINDER: WGLC for draft-ietf-ntp-mac

 

EXTERNAL EMAIL<= /span>

Folks,


The working group last call for this document has been out for almost three= weeks now. Please respond immediately with technical comments and an indic= ation of whether or not you approve the advancement of this document. =

Regards,
Karen

 

On Aug 9, 2017, at 12:53 AM, Karen O'Donoghue <odonoghue@isoc.org> wrote:<= /o:p>

 

Folks,

This begins a three week working group last call (WGLC) for "Message A= uthentication Code for the Network Time Protocol"
https://da= tatracker.ietf.org/doc/draft-ietf-ntp-mac/


Please review and provide comments to the mailing list by no later than 31 = August 2017. Earlier comments and discussion would be appreciated. Please n= ote that the chairs will be using this WGLC to determine consensus to move = this document forward to the IESG. 

Also, as a reminder, we have migrated the working group mailing list to IET= F infrastructure. Please respond to nt= p@ietf.org. 

Regards,
Karen and Dieter

_______________________________________________
ntp mailing list
ntp@ietf.org
https://www.ietf.org/= mailman/listinfo/ntp

 

--_000_8D2BF679AAC7C346848A489074F9F8BFD2830065sjsrvexchmbx1mi_-- --===============1587603915889627539== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp --===============1587603915889627539==-- From nobody Tue Aug 29 16:52:22 2017 Return-Path: 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 B4068132A94; Tue, 29 Aug 2017 16:52:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.699 X-Spam-Level: X-Spam-Status: No, score=-4.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mscc365.onmicrosoft.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 E2FWvxTZjxJk; Tue, 29 Aug 2017 16:52:16 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0065.outbound.protection.outlook.com [104.47.40.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8668C132113; Tue, 29 Aug 2017 16:52:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mscc365.onmicrosoft.com; s=selector1-microsemi-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=d90r7ICy62H9nn55PLEcwHglm+Z9LZ1LGOGt6bGLdVA=; b=dd+G8VKFoDKHGWHfwOh6BcYoURMnUNMPtPJm6acFpoHjLO/FhSBxBPLDngbfv97LW1djS4zjPbgjYJ8ZpmosVD5U7ky36xndqO03EtjXSWW5tkiyvuJhy5CoUFfCW2nSIBbyEYYhNDi5fc3sagS9QUOsXMdvQsOjKg/bBg/soP0= Received: from CY4PR02CA0002.namprd02.prod.outlook.com (10.169.188.12) by CY1PR0201MB1498.namprd02.prod.outlook.com (10.163.139.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.13.10; Tue, 29 Aug 2017 23:52:15 +0000 Received: from BL2FFO11FD031.protection.gbl (2a01:111:f400:7c09::146) by CY4PR02CA0002.outlook.office365.com (2603:10b6:903:18::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.13.10 via Frontend Transport; Tue, 29 Aug 2017 23:52:15 +0000 Authentication-Results: spf=pass (sender IP is 208.19.100.21) smtp.mailfrom=microsemi.com; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=microsemi.com; Received-SPF: Pass (protection.outlook.com: domain of microsemi.com designates 208.19.100.21 as permitted sender) receiver=protection.outlook.com; client-ip=208.19.100.21; helo=avsrvexchhts1.microsemi.net; Received: from avsrvexchhts1.microsemi.net (208.19.100.21) by BL2FFO11FD031.mail.protection.outlook.com (10.173.160.71) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.1341.15 via Frontend Transport; Tue, 29 Aug 2017 23:52:14 +0000 Received: from SJSRVEXCHHTS1.microsemi.net (10.241.34.105) by avsrvexchhts1.microsemi.net (10.100.34.105) with Microsoft SMTP Server (TLS) id 14.3.361.1; Tue, 29 Aug 2017 16:52:13 -0700 Received: from SJSRVEXCHMBX1.microsemi.net ([fe80::19b5:ac43:d8de:5120]) by sjsrvexchhts1.microsemi.net ([::1]) with mapi id 14.03.0361.001; Tue, 29 Aug 2017 16:52:12 -0700 From: Greg Dowd To: Karen O'Donoghue , "ntp@ietf.org" CC: "tictoc@ietf.org" Thread-Topic: REMINDER: WGLC for draft-ietf-ntp-mac Thread-Index: AQHTEMt6dgTCyuPEXEODOT5Gsnqn3aKbMBOAgADx5oA= Date: Tue, 29 Aug 2017 23:52:13 +0000 Message-ID: <8D2BF679AAC7C346848A489074F9F8BFD2830065@sjsrvexchmbx1.microsemi.net> References: <80E159E7-17F1-4B0E-8DA1-07581DF7FC6C@isoc.org> In-Reply-To: <80E159E7-17F1-4B0E-8DA1-07581DF7FC6C@isoc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.241.128.48] Content-Type: multipart/alternative; boundary="_000_8D2BF679AAC7C346848A489074F9F8BFD2830065sjsrvexchmbx1mi_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:208.19.100.21; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10009020)(39860400002)(2980300002)(438002)(189002)(24454002)(199003)(12213003)(377454003)(53416004)(6246003)(189998001)(55846006)(260700001)(478600001)(72206003)(4326008)(76176999)(54356999)(50986999)(626005)(9686003)(2920100001)(2900100001)(2950100002)(2501003)(5250100002)(69596002)(512954002)(236005)(54896002)(6306002)(8666007)(106466001)(53936002)(229853002)(33656002)(230783001)(2906002)(8936002)(5660300001)(356003)(53546010)(68736007)(606006)(102836003)(6116002)(790700001)(966005)(81166006)(7696004)(81156014)(7736002)(8676002)(3846002)(97736004)(84326002)(86362001); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR0201MB1498; H:avsrvexchhts1.microsemi.net; FPR:; SPF:Pass; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11FD031; 1:sDjK5SaMRpDCy+46ouuAygJiUH25DhXl1IC0CIRRJdf6sqU8n0u4SDDQM9GHL5tFUl964aoMMmaD2iBkv+6LpbCGWontQqkN6bLm9TDh8R5yuiVkKQpOIZHeBciBlq9w X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: a5fe372a-98ce-464c-e4b2-08d4ef38f937 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(8251501002)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY1PR0201MB1498; X-Microsoft-Exchange-Diagnostics: 1; CY1PR0201MB1498; 3:tWCWig0PoKM8NF7YAdcUNxNbg74rlNUTuBb+W5jUChk1uC1npc7eOLjXZI/Zccmip/HeS2/geRZP1fkxSWPTabEHAAIkG3maYxpSE6xHtmVBI9IoJpCM2PBH1ZCHi9O3GpoVraaPpjBk4zVA5Vk712xHXZV1p5NJDeMC4JQGSZ72E1wbdJETA8nJpu+GLsIxSCjmtWYbUyHWZxyIYPo7YxKLKf2oMlq6d1/uFm7sV5v7NH1vlRRhR8fa8Tq49E29a0s6fAPmOQPYhJmiBodPRONouOQTOBw49tlWSxsRQ3OABP/5w7oaKLkBiJ3boDetoVotsT3OypktBZ8dDcFGWtxWp+YA7uZjZVDe5tNtyWU=; 25:nONDDzKsJMGGQlnxbINAgU/mcB1W3BCyfjTUoidcUqpB47jaD0xxGNnKxmMe8Fix1MY4GO4eodVdK31Nucvs/ptMojKeTxQUeHM3h0nxJl474ti4YPJBSZvJVi6JCWguBp0hrdL3xluovagjbTFMyQJtYOLmLeTCFfCizaNUhzGGkRMkJN3rDjRY0TimpNrXrSZ7dMfd9J0q0MQ5HiWt8pXxRflZRXmW959VoJlHTdoQTv3sOXbcmZza7lEgDw7jD9I2UHKHCxPTjfWH+moGqnVFhfT8MSSyZjiXSf9MwOCnPqwpdmP3J7MDhRXzGK6yVktb+ub48AOxdNSGAT1Xng== X-MS-TrafficTypeDiagnostic: CY1PR0201MB1498: X-Microsoft-Exchange-Diagnostics: 1; CY1PR0201MB1498; 31:8UHjohTFA10fCnU5U3sZXYpUE3pRNm9GudXcwwBfJULazxOBKx+zSOdVwOORgk7+OVjHpCMYRQiM3DfClIHRv7AIRmkiRWAu/29s+TTdiuFXlzmwrltIveXbZHAuWeUSIYox/XTHvhGNIrs84AZxMOTag80USsA2opRsM+YPaVM3uKdisjimPoDDiWO9wqHlDp1Jywad6WyccsFLTyOy6QTI7GNm0qdHmzh5yKD1OtM=; 20:c6O3qz5Gc/VFLAn1AuC6+fhaBZQ50EjQizdrEG9czHB48kOtVOa8UT6XKhFX4bEZXbqQg/D0XgAo984+3EjkOhGNL3DrkIAe2ve890wHfRarA+PvdKgs8NCPNM6gkc0IUnLfnhndynEkBn3wJMpmf3v3NQGMnn5zi8FmjvjkvvFMnlDS2HC9qiivl6PY7/haMwfXOyMmLNI8CsmIIjUMuxWpeT5Crhth7bMUzANUd2ikdRZmt/h1aK3dwlIWySalBPUgbW3VnCpYBajjixmz+/nem8oIuM6znbWVREdQ8SMzmqpcc9MImB1It0S1mcAuC3FzWOMNiSL0VEZ6DTEhYvdA+zb6oyihCo7b9uGrtwVj1LOZ3kxKSp/NUZhb0gl4DKFiNewG91hkj83pnV3Fw3/2faR5CWMsZwAdh8uQKAAv0T3sJAOTjdnc13DP/RbcxiC09+H6Av8naZgOHVg+2wGkyV8IjTmlRQyCU6NEnCvwmax43OWoey5YwXaEZyet X-Exchange-Antispam-Report-Test: UriScan:(120809045254105)(100405760836317)(21748063052155); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(13016025)(13018025)(8121501046)(5005006)(100000703101)(100105400095)(3002001)(93006095)(93004095)(10201501046)(6055026)(6041248)(20161123564025)(20161123558100)(20161123562025)(20161123560025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY1PR0201MB1498; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY1PR0201MB1498; X-Microsoft-Exchange-Diagnostics: 1; CY1PR0201MB1498; 4:C3YAJ3Jh54mItQKvs6UyiLwXMyLcUwxOAmZKwZikOkT3TyJ20DU6Mt7kEIR44gljcbmlfFTB49BE044SJcuzimo7dhYRNpczppIDsG0iAhV0XfFVVsedI6QYLxY9TvPmQ8ZKyf/TIj3MV3xiaKicwq/UeoIofp8efaf+gfiAHw5gljoqDSCe/uftnnpTiBa+vNw0qd7ybyi/gJw0Cmmmuc4jrVSf9Xhy4irFNj6mQ3sIr2RzIg3S1hfwRw1qWBJbiC9yAIHJ+bUEDLc61YI3SK1N6mnjsF298q7yWhomoxqdKDB7ShHNQrYbcHlE/HwYcBCSRfEwxFOoI5vP18Rzsd3uXGJfL9+gYYGw9ljERlNeuWSXaNjOFmFQ1MNjLLpT X-Forefront-PRVS: 0414DF926F X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR0201MB1498; 23:kPZyd0ahI3xEIoZJLIne50cl+6xZ71oZDscMUCv?= =?us-ascii?Q?+b/CEziS2ROUv392mFM4nAcl+dbfA2aIL7UeAbL9+G0qoKrdorZOga0arC7+?= =?us-ascii?Q?vlv3uFyvNCgie3O6dQYrF040WMwJOiZvtJ+yjWkXBBrsIFcfgGDBynA3Z9M9?= =?us-ascii?Q?AjK3A+UD6CApHHQxaVFz4cZHxcj4n7/7RJWamgQr4ZkSIDLTFUu86QY01pqP?= =?us-ascii?Q?f4gfqEKW2LoCYy48z/Zp2jPxjXG11oRCBwHRCS7IK5EQp/zoVUITv04Hxcqp?= =?us-ascii?Q?YFTULF5z2wBnWisFcDY9MwoRXhL+fCkuiNnb3DhzbUTfvPGZgcgpHBOPC1eQ?= =?us-ascii?Q?s4XOLUtMZG1PXeBGvdsHzEC8xtWYOClvfEbUxrQFwNdvQOyPFy6aN4NUz642?= =?us-ascii?Q?yRYbM5crLZAMGEaIcaKH5FNh6EGJC1FR9CZMfGMZ3XBNiqbI/zpEo1+OXqUS?= =?us-ascii?Q?LkcR74d+y2/1+oBsgj+TEr3PyUE8sP83pC/vHyV5bT4j23MqQH+MeDE7/bW0?= =?us-ascii?Q?G6vxW2zDu9zt5g13Go0OBL+l3Z1rz1aW8lmwmLIkNX2keSCXrRG9MW46aAUE?= =?us-ascii?Q?MV0C/4mr3KCzUjIENd1e5KtXrQzf2bqcOoyC9/KUzmg4wyQjw7nzSObwrzYx?= =?us-ascii?Q?3z8Edx5isPoseH88EDC8RSZn5cv9zgpYKhJKvM2mZH/N/L5cvhIYZFHaOHyR?= =?us-ascii?Q?gOSbeS5bH3AMNLQnU8BGsiN4ZiBHSQkhdQ2XGxjaefAjZvWgjJpPG/+5VRoH?= =?us-ascii?Q?5QwHG7LcMOCJ0DFOTQKg9GiYegubXW78mm/TRaYFUqAQ9KHO5+kDDm9Y5wsa?= =?us-ascii?Q?ZyqHE1ttiBnlKS9ECML78A4HHwn7gvgRrwXIJbJCEBtG65vMV8jqEBPmrwJn?= =?us-ascii?Q?pt7CfGvNN855vZGkHEAr/pVNgORAnM0/25MjlYlL7TU6UoyjiEl3f6mMrUw7?= =?us-ascii?Q?o3CFGDBH9L3AOIGLHDF7ceL0iEVcKYxmQJwkyxNE0+dHEJmMiPv46aM0mbkt?= =?us-ascii?Q?iP8B2KWoRwPVFelpr565sedjPlfhmq2J0NFbECe8KSHd252E3nJH50OCWrfi?= =?us-ascii?Q?cyEiZ7vhKkLRCb1O5k9nD2leDeI+v5ivbHFZE9+ZwgEf38j98YVeKc/e0dHf?= =?us-ascii?Q?fLi73D6HaFhtpeLMVcoxuwOvERT0P9zIUilwa73VUT7oli6Dy0udRg7MCkFz?= =?us-ascii?Q?RO0tS1X660HlQBbenqHwtBRUIqOB/bs8KpVOcIIgkOhnzClonboWyHBwqZ3b?= =?us-ascii?Q?JnwxWsWI10QnzUtToKQByR2QcNQOraNDqvVIp8oxUPwny2qUU1dgSBs5TWsP?= =?us-ascii?Q?RCZajnhFmCg7i8dG4pjgtvik=3D?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR0201MB1498; 6:+ZZJAxDA1dEoZO2NHDJFP+66aqeUOYS5vzoX9klIEHZFjCOPnYjjYRV+khg5rspX9qK9E7rxU6HlLvODsVPTS9Uw5fbvMFGOLW7mFiOdIYwBPvpkMSm9/K7Ld1iPmFz35+DtOLB7yRAPjcV3FcrGTSXEaHnDBh1VzP2cPL6M23uXxSa7gT1Z0iY6JUjojHBM5STXeJW0TzMQ8gW0vrvC4j4YLFya1M9mL4Vg0UE3mQqDcosBWPCnaYCk+YAG6LsraYsCPKU8e1UQuBxR6LMGueUZVxU4ZOccDzi22KiGki9f2OJdBs2ksp0UPvPbzyLEiMMYara5FoTOQWPfhEfGBQ==; 5:LWTmNFFGjtFXlNREhlkf9joQnnBnAw3vE3pOYrwWOdhH/8hwa6k5TPUgYjWZ9ttIm33RwgPCeTH5+4YHN23/dXyjjyVfkeCbA1tJm5uFrU9lex4CgBhihD9Pb+DZAnAS/KkvxZNIlHF5vZC1sKqBoA==; 24:xX0UXqiVzkpQyrObdFhbJL0k/CqjEiBMY6LwF7YxurWZQ1ck373aW8BdM93O7/lkQIcw05ueayHSfTHq6bZOS6uKw0oonBre0K1xAlLU/lg=; 7:M7I01UcATP51NOtNRZ9uhJ8lg/tb+MvjhFNuPnmjn4tIwfFUrx5E+S7eSrLjJ1gCOI0mqA4WmgnpUZkl4FPXMDFIgNvhKGge6Boa1Fc/mVsP0w7ZMLh+vY4l+yBQ8/0JBXbrOMqEuRCC/sL2SsfYyxw5KSsWyeKKeHP7ex5XqYQIc9nh4YVA4iM+wc5GT+rxdzpIeN9ZJmmQJm12RRen1rEwiv9vLTbZvEqEGP63XNY= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: microsemi.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Aug 2017 23:52:14.0579 (UTC) X-MS-Exchange-CrossTenant-Id: f267a5c8-86d8-4cc9-af71-1fd2c67c8fad X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f267a5c8-86d8-4cc9-af71-1fd2c67c8fad; Ip=[208.19.100.21]; Helo=[avsrvexchhts1.microsemi.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0201MB1498 Archived-At: Subject: Re: [Ntp] REMINDER: WGLC for draft-ietf-ntp-mac X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Aug 2017 23:52:20 -0000 --_000_8D2BF679AAC7C346848A489074F9F8BFD2830065sjsrvexchmbx1mi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I approve of advancing this draft. Thanks...Greg From: ntp [mailto:ntp-bounces@ietf.org] On Behalf Of Karen O'Donoghue Sent: Monday, August 28, 2017 7:26 PM To: ntp@ietf.org Cc: tictoc@ietf.org Subject: [Ntp] REMINDER: WGLC for draft-ietf-ntp-mac EXTERNAL EMAIL Folks, The working group last call for this document has been out for almost three= weeks now. Please respond immediately with technical comments and an indic= ation of whether or not you approve the advancement of this document. Regards, Karen On Aug 9, 2017, at 12:53 AM, Karen O'Donoghue > wrote: Folks, This begins a three week working group last call (WGLC) for "Message Authen= tication Code for the Network Time Protocol" https://datatracker.ietf.org/doc/draft-ietf-ntp-mac/ Please review and provide comments to the mailing list by no later than 31 = August 2017. Earlier comments and discussion would be appreciated. Please n= ote that the chairs will be using this WGLC to determine consensus to move = this document forward to the IESG. Also, as a reminder, we have migrated the working group mailing list to IET= F infrastructure. Please respond to ntp@ietf.org. Regards, Karen and Dieter _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp --_000_8D2BF679AAC7C346848A489074F9F8BFD2830065sjsrvexchmbx1mi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I approve of advancing this draft.  Thanks̷= 0;Greg

 

 

From: ntp [mailto:ntp-bounces@ietf.org] On= Behalf Of Karen O'Donoghue
Sent: Monday, August 28, 2017 7:26 PM
To: ntp@ietf.org
Cc: tictoc@ietf.org
Subject: [Ntp] REMINDER: WGLC for draft-ietf-ntp-mac

 

EXTERNAL EMAIL<= /span>

Folks,


The working group last call for this document has been out for almost three= weeks now. Please respond immediately with technical comments and an indic= ation of whether or not you approve the advancement of this document. =

Regards,
Karen

 

On Aug 9, 2017, at 12:53 AM, Karen O'Donoghue <odonoghue@isoc.org> wrote:<= /o:p>

 

Folks,

This begins a three week working group last call (WGLC) for "Message A= uthentication Code for the Network Time Protocol"
https://da= tatracker.ietf.org/doc/draft-ietf-ntp-mac/


Please review and provide comments to the mailing list by no later than 31 = August 2017. Earlier comments and discussion would be appreciated. Please n= ote that the chairs will be using this WGLC to determine consensus to move = this document forward to the IESG. 

Also, as a reminder, we have migrated the working group mailing list to IET= F infrastructure. Please respond to nt= p@ietf.org. 

Regards,
Karen and Dieter

_______________________________________________
ntp mailing list
ntp@ietf.org
https://www.ietf.org/= mailman/listinfo/ntp

 

--_000_8D2BF679AAC7C346848A489074F9F8BFD2830065sjsrvexchmbx1mi_-- From nobody Tue Aug 29 23:50:53 2017 Return-Path: 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 EEE4A13238E for ; Tue, 29 Aug 2017 23:50:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 iqHUfEbAVA-I for ; Tue, 29 Aug 2017 23:50:49 -0700 (PDT) Received: from mx1.bs.ptb.de (mx1.bs.ptb.de [IPv6:2001:638:610:bd01::120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED3F0132377 for ; Tue, 29 Aug 2017 23:50:48 -0700 (PDT) Received: from smtp-hub.bs.ptb.de (smtpint01.bs.ptb.de [141.25.87.32]) by mx1.bs.ptb.de with ESMTP id v7U6ok3u009453-v7U6ok3w009453 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 30 Aug 2017 08:50:46 +0200 Received: from lotus.bs.ptb.de (lotus.bs.ptb.de [141.25.85.200]) by smtp-hub.bs.ptb.de (Postfix) with ESMTPS id 4E451533E6B for ; Wed, 30 Aug 2017 08:50:45 +0200 (CEST) To: ntp@ietf.org MIME-Version: 1.0 Message-ID: From: kristof.teichel@ptb.de Date: Wed, 30 Aug 2017 08:50:42 +0200 Content-Type: multipart/alternative; boundary="=_alternative 00259B47C125818C_=" Archived-At: Subject: [Ntp] [NTP] WGLC for draft-ietf-ntp-using-nts-for-ntp (Requirements Language / NTP Pools) X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 06:50:52 -0000 Dies ist eine mehrteilige Nachricht im MIME-Format. --=_alternative 00259B47C125818C_= Content-Type: text/plain; charset="US-ASCII" Hi all, thanks to Yuanlong, Paul and Greg for their feedback. In response to Paul's feedback: 1./4.) (Covers Yuanlong's feedback as well): I second the notion that we should adapt as much of the normative language in the document as possible into requirements language as per RFC 2119. 3.) I like the current name "cookie placeholder" over the suggestion "cookie request", simply because the former is more descriptive with regard to the same-length notion. I do, however, not have a strong opinion on this. 5.) (Also goes to an issue raised implicitly by Harlan & Dave) Concerning the NTP pools passage, I think there is something to the raised concerns, but I would approach the issue via the phrasing of the paragraph. I suggest instead of simply saying "pool operators" or "pools" (which does silently imply ALL of them). we move to saying "some pool operators / pools", since the problem persists even if it does not concern all instances. My text suggestion is: "[...] A more important matter, however, is that not all pool operators have procedures for establishing and maintaining trust in their members. Pools in existence as of 2017 are often volunteer-run, some of them with minimal requirements for admission and/or with no organized effort to monitor pool servers for misbehavior. [...]" I think this text does the same thing for the conclusion (in general, using pools with NTS is a bad idea), but hopefully more people will view it as factually correct. Best regards --=_alternative 00259B47C125818C_= Content-Type: text/html; charset="US-ASCII" Hi all,

thanks to Yuanlong, Paul and Greg for their feedback.
In response to Paul's feedback:

1./4.) (Covers Yuanlong's feedback as well):
 I second the notion that we should adapt as much of the normative language in the document as possible into requirements language as per RFC 2119.

3.)
I like the current name "cookie placeholder" over the suggestion "cookie request", simply because the former is more descriptive with regard to the same-length notion.
I do, however, not have a strong opinion on this.

5.) (Also goes to an issue raised implicitly by Harlan & Dave)
Concerning the NTP pools passage, I think there is something to the raised concerns, but I would approach the issue via the phrasing of the paragraph.
I suggest instead of simply saying "pool operators" or "pools" (which does silently imply ALL of them). we move to saying "some pool operators / pools", since the problem persists even if it does not concern all instances.
My text suggestion is:

        "[...] A more important matter, however, is that not all pool operators have procedures for establishing and maintaining trust in their members.
        Pools in existence as of 2017 are often volunteer-run, some of them with minimal requirements for admission and/or with no organized effort to monitor pool servers for misbehavior. [...]"

I think this text does the same thing for the conclusion (in general, using pools with NTS is a bad idea), but hopefully more people will view it as factually correct.



Best regards --=_alternative 00259B47C125818C_=-- From ntp-bounces@ietf.org Tue Aug 29 23:50:53 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C27A813238E; Tue, 29 Aug 2017 23:50:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1504075853; bh=2SHKv7M2XxWAqnYtGQnIKwODy4sAQaPhxYlRFCWcRM8=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=TIKqHbexwPoCeBdQs2A7IZ6gVA9UNVyUlIiqegUdnk3dET60sM3+b2w/BMNBXa+Cr 7vmJPHcZ2AMIkSsCjpCa83j0YjQu7PzwYSpmf6Iu7MlvStJ931jWgdpmS8QiLrFsrz wQuxN/TyuaHLsEebHLbUddF5YOF2vxerPmSDBLZo= 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 EEE4A13238E for ; Tue, 29 Aug 2017 23:50:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 iqHUfEbAVA-I for ; Tue, 29 Aug 2017 23:50:49 -0700 (PDT) Received: from mx1.bs.ptb.de (mx1.bs.ptb.de [IPv6:2001:638:610:bd01::120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED3F0132377 for ; Tue, 29 Aug 2017 23:50:48 -0700 (PDT) Received: from smtp-hub.bs.ptb.de (smtpint01.bs.ptb.de [141.25.87.32]) by mx1.bs.ptb.de with ESMTP id v7U6ok3u009453-v7U6ok3w009453 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 30 Aug 2017 08:50:46 +0200 Received: from lotus.bs.ptb.de (lotus.bs.ptb.de [141.25.85.200]) by smtp-hub.bs.ptb.de (Postfix) with ESMTPS id 4E451533E6B for ; Wed, 30 Aug 2017 08:50:45 +0200 (CEST) To: ntp@ietf.org MIME-Version: 1.0 Message-ID: From: kristof.teichel@ptb.de Date: Wed, 30 Aug 2017 08:50:42 +0200 Archived-At: Subject: [Ntp] [NTP] WGLC for draft-ietf-ntp-using-nts-for-ntp (Requirements Language / NTP Pools) X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============4856843203374788227==" Errors-To: ntp-bounces@ietf.org Sender: "ntp" Dies ist eine mehrteilige Nachricht im MIME-Format. --===============4856843203374788227== Content-Type: multipart/alternative; boundary="=_alternative 00259B47C125818C_=" Dies ist eine mehrteilige Nachricht im MIME-Format. --=_alternative 00259B47C125818C_= Content-Type: text/plain; charset="US-ASCII" Hi all, thanks to Yuanlong, Paul and Greg for their feedback. In response to Paul's feedback: 1./4.) (Covers Yuanlong's feedback as well): I second the notion that we should adapt as much of the normative language in the document as possible into requirements language as per RFC 2119. 3.) I like the current name "cookie placeholder" over the suggestion "cookie request", simply because the former is more descriptive with regard to the same-length notion. I do, however, not have a strong opinion on this. 5.) (Also goes to an issue raised implicitly by Harlan & Dave) Concerning the NTP pools passage, I think there is something to the raised concerns, but I would approach the issue via the phrasing of the paragraph. I suggest instead of simply saying "pool operators" or "pools" (which does silently imply ALL of them). we move to saying "some pool operators / pools", since the problem persists even if it does not concern all instances. My text suggestion is: "[...] A more important matter, however, is that not all pool operators have procedures for establishing and maintaining trust in their members. Pools in existence as of 2017 are often volunteer-run, some of them with minimal requirements for admission and/or with no organized effort to monitor pool servers for misbehavior. [...]" I think this text does the same thing for the conclusion (in general, using pools with NTS is a bad idea), but hopefully more people will view it as factually correct. Best regards --=_alternative 00259B47C125818C_= Content-Type: text/html; charset="US-ASCII" Hi all,

thanks to Yuanlong, Paul and Greg for their feedback.
In response to Paul's feedback:

1./4.) (Covers Yuanlong's feedback as well):
 I second the notion that we should adapt as much of the normative language in the document as possible into requirements language as per RFC 2119.

3.)
I like the current name "cookie placeholder" over the suggestion "cookie request", simply because the former is more descriptive with regard to the same-length notion.
I do, however, not have a strong opinion on this.

5.) (Also goes to an issue raised implicitly by Harlan & Dave)
Concerning the NTP pools passage, I think there is something to the raised concerns, but I would approach the issue via the phrasing of the paragraph.
I suggest instead of simply saying "pool operators" or "pools" (which does silently imply ALL of them). we move to saying "some pool operators / pools", since the problem persists even if it does not concern all instances.
My text suggestion is:

        "[...] A more important matter, however, is that not all pool operators have procedures for establishing and maintaining trust in their members.
        Pools in existence as of 2017 are often volunteer-run, some of them with minimal requirements for admission and/or with no organized effort to monitor pool servers for misbehavior. [...]"

I think this text does the same thing for the conclusion (in general, using pools with NTS is a bad idea), but hopefully more people will view it as factually correct.



Best regards --=_alternative 00259B47C125818C_=-- --===============4856843203374788227== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp --===============4856843203374788227==-- From nobody Wed Aug 30 00:24:15 2017 Return-Path: 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 C5A1A132DD8; Wed, 30 Aug 2017 00:24:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no 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 qkH-KKi1w3EK; Wed, 30 Aug 2017 00:24:11 -0700 (PDT) Received: from rrzmta1.uni-regensburg.de (rrzmta1.uni-regensburg.de [194.94.155.51]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6BDF1323B6; Wed, 30 Aug 2017 00:24:11 -0700 (PDT) Received: from rrzmta1.uni-regensburg.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 385B25750F; Wed, 30 Aug 2017 09:24:10 +0200 (CEST) Received: from gwsmtp1.uni-regensburg.de (gwsmtp1.uni-regensburg.de [132.199.5.51]) by rrzmta1.uni-regensburg.de (Postfix) with ESMTP id DF6714F08B; Wed, 30 Aug 2017 09:24:09 +0200 (CEST) Received: from uni-regensburg-smtp1-MTA by gwsmtp1.uni-regensburg.de with Novell_GroupWise; Wed, 30 Aug 2017 09:24:09 +0200 Message-Id: <59A66816020000A100027A91@gwsmtp1.uni-regensburg.de> X-Mailer: Novell GroupWise Internet Agent 14.2.2 Date: Wed, 30 Aug 2017 09:24:06 +0200 From: "Ulrich Windl" To: "Jiangyuanlong" , "ntp@ietf.org" , Cc: "tictoc@ietf.org" References: <3B0A1BED22CAD649A1B3E97BE5DDD68BBB599924@dggeml507-mbx.china.huawei.com> In-Reply-To: <3B0A1BED22CAD649A1B3E97BE5DDD68BBB599924@dggeml507-mbx.china.huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Content-Disposition: inline Archived-At: Subject: [Ntp] Antw: Re: WGLC for draft-ietf-ntp-mac X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 07:24:14 -0000 >>> Jiangyuanlong schrieb am 29.08.2017 um 08:06 in Nachricht <3B0A1BED22CAD649A1B3E97BE5DDD68BBB599924@dggeml507-mbx.china.huawei.com>: > Hi, I support the publication of this draft, though I have several > suggestions for the texts: > > > 1. “If authentication is implemented, then AES-CMAC as specified in > RFC > 4493 [RFC4493] should be computed…†in Section 3. > This is a requirement, so I think it should use “SHOULD†instead of > “shouldâ€. > But if this AES-CMAC is the only authentication mechanism, it is better to > use “MUSTâ€. > > > 2. “We recommend that the MAC key for NTP SHOULD be 128 bits long > AES-128 key…†in Section 3. > To be more formal, maybe it can be rephrased into “It is RECOMMENDED that > the MAC key for NTP SHOULD be 128 bits long AES-128 key…†Why not: "The MAC key for NTP SHOULD be a 128 bits long AES-128 key…"? [...] Regards, Ulrich From ntp-bounces@ietf.org Wed Aug 30 00:24:15 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E688132DD8; Wed, 30 Aug 2017 00:24:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1504077855; bh=4e6TzKFaWQrYoxAieGTsJI96JPVWBd4NraYj9F2DpRM=; h=Date:From:To:References:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc; b=S9U19iWxcRZ7XYc1P5kCFMiyISyFT19iZw8eyVPbIHD1GCuyJg5gSl8ahjP5SkBqB tNxhsfTU/YHagxv8NpIqy+9wg+2owl72fSwF8Niudkq3zQobpLEB9m9D9Qf6uEOZpg ki6Mi2ZuEO1cD+LYUvelf8G8ZfEceDA1VNQWox+c= 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 C5A1A132DD8; Wed, 30 Aug 2017 00:24:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no 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 qkH-KKi1w3EK; Wed, 30 Aug 2017 00:24:11 -0700 (PDT) Received: from rrzmta1.uni-regensburg.de (rrzmta1.uni-regensburg.de [194.94.155.51]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6BDF1323B6; Wed, 30 Aug 2017 00:24:11 -0700 (PDT) Received: from rrzmta1.uni-regensburg.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 385B25750F; Wed, 30 Aug 2017 09:24:10 +0200 (CEST) Received: from gwsmtp1.uni-regensburg.de (gwsmtp1.uni-regensburg.de [132.199.5.51]) by rrzmta1.uni-regensburg.de (Postfix) with ESMTP id DF6714F08B; Wed, 30 Aug 2017 09:24:09 +0200 (CEST) Received: from uni-regensburg-smtp1-MTA by gwsmtp1.uni-regensburg.de with Novell_GroupWise; Wed, 30 Aug 2017 09:24:09 +0200 Message-Id: <59A66816020000A100027A91@gwsmtp1.uni-regensburg.de> X-Mailer: Novell GroupWise Internet Agent 14.2.2 Date: Wed, 30 Aug 2017 09:24:06 +0200 From: "Ulrich Windl" To: "Jiangyuanlong" , "ntp@ietf.org" , References: <3B0A1BED22CAD649A1B3E97BE5DDD68BBB599924@dggeml507-mbx.china.huawei.com> In-Reply-To: <3B0A1BED22CAD649A1B3E97BE5DDD68BBB599924@dggeml507-mbx.china.huawei.com> Mime-Version: 1.0 Content-Disposition: inline Archived-At: Subject: [Ntp] Antw: Re: WGLC for draft-ietf-ntp-mac X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "tictoc@ietf.org" Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Errors-To: ntp-bounces@ietf.org Sender: "ntp" Pj4+IEppYW5neXVhbmxvbmcgPGppYW5neXVhbmxvbmdAaHVhd2VpLmNvbT4gc2NocmllYiBhbSAy OS4wOC4yMDE3IHVtIDA4OjA2IGluCk5hY2hyaWNodAo8M0IwQTFCRUQyMkNBRDY0OUExQjNFOTdC RTVEREQ2OEJCQjU5OTkyNEBkZ2dlbWw1MDctbWJ4LmNoaW5hLmh1YXdlaS5jb20+Ogo+IEhpLCBJ IHN1cHBvcnQgdGhlIHB1YmxpY2F0aW9uIG9mIHRoaXMgZHJhZnQsIHRob3VnaCBJIGhhdmUgc2V2 ZXJhbCAKPiBzdWdnZXN0aW9ucyBmb3IgdGhlIHRleHRzOgo+IAo+IAo+IDEuICAgICAgIOKAnElm IGF1dGhlbnRpY2F0aW9uIGlzIGltcGxlbWVudGVkLCB0aGVuIEFFUy1DTUFDIGFzIHNwZWNpZmll ZCBpbgoKPiBSRkMKPiAgICAgICAgIDQ0OTMgW1JGQzQ0OTNdIHNob3VsZCBiZSBjb21wdXRlZOKA puKAnSBpbiBTZWN0aW9uIDMuCj4gVGhpcyBpcyBhIHJlcXVpcmVtZW50LCBzbyBJIHRoaW5rIGl0 IHNob3VsZCB1c2Ug4oCcU0hPVUxE4oCdIGluc3RlYWQgb2YgCj4g4oCcc2hvdWxk4oCdLgo+IEJ1 dCBpZiB0aGlzIEFFUy1DTUFDIGlzIHRoZSBvbmx5IGF1dGhlbnRpY2F0aW9uIG1lY2hhbmlzbSwg aXQgaXMgYmV0dGVyIHRvIAo+IHVzZSDigJxNVVNU4oCdLgo+IAo+IAo+IDIuICAgICAgIOKAnFdl IHJlY29tbWVuZCB0aGF0IHRoZSBNQUMga2V5IGZvciBOVFAgU0hPVUxEIGJlIDEyOCBiaXRzIGxv bmcgCj4gQUVTLTEyOCBrZXnigKbigJ0gaW4gU2VjdGlvbiAzLgo+IFRvIGJlIG1vcmUgZm9ybWFs LCBtYXliZSBpdCBjYW4gYmUgcmVwaHJhc2VkIGludG8g4oCcSXQgaXMgUkVDT01NRU5ERUQgdGhh dAoKPiB0aGUgTUFDIGtleSBmb3IgTlRQIFNIT1VMRCBiZSAxMjggYml0cyBsb25nIEFFUy0xMjgg a2V54oCm4oCdCgpXaHkgbm90OiAiVGhlIE1BQyBrZXkgZm9yIE5UUCBTSE9VTEQgYmUgYSAxMjgg Yml0cyBsb25nIEFFUy0xMjgga2V54oCmIj8KClsuLi5dCgpSZWdhcmRzLApVbHJpY2gKCgpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpudHAgbWFpbGluZyBs aXN0Cm50cEBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL250 cAo= From ntp-bounces@ietf.org Wed Aug 30 00:49:53 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E8CA132710; Wed, 30 Aug 2017 00:49:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1504079393; bh=Wvud9TGQZqqsWvL9ih9+HPS4zHQMXosK/ONJz08ONKM=; h=From:To:Date:References:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc; b=MrH9rmsqWhufqqQHjrKiydgLgROT/FDyX/C7BsMc2OYnxumb0aO3vzN78j9pYCFqJ BUsoqgVetY2Ajzf7FsHP9qCQu/F4als7mBSa65E5as93FlZqnaKXBk224sBg92FVl6 6JfM99y3yotB0MMaWdsrgwsZuOegwqdBegsW93VU= 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 C0A94132386; Wed, 30 Aug 2017 00:49:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 nAFBR6duCVzS; Wed, 30 Aug 2017 00:49:49 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E21AF1323B5; Wed, 30 Aug 2017 00:49:42 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DUK93719; Wed, 30 Aug 2017 07:49:40 +0000 (GMT) Received: from DGGEML403-HUB.china.huawei.com (10.3.17.33) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 30 Aug 2017 08:48:56 +0100 Received: from DGGEML507-MBX.china.huawei.com ([169.254.2.7]) by DGGEML403-HUB.china.huawei.com ([fe80::74d9:c659:fbec:21fa%31]) with mapi id 14.03.0301.000; Wed, 30 Aug 2017 15:48:40 +0800 From: Jiangyuanlong To: Ulrich Windl , "ntp@ietf.org" , "odonoghue@isoc.org" Thread-Topic: Antw: Re: [Ntp] WGLC for draft-ietf-ntp-mac Thread-Index: AQHTEMt6dgTCyuPEXEODOT5Gsnqn3aKawq4AgAFXiwCAAIuc8A== Date: Wed, 30 Aug 2017 07:48:40 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68BBB599FEF@dggeml507-mbx.china.huawei.com> References: <3B0A1BED22CAD649A1B3E97BE5DDD68BBB599924@dggeml507-mbx.china.huawei.com> <59A66816020000A100027A91@gwsmtp1.uni-regensburg.de> In-Reply-To: <59A66816020000A100027A91@gwsmtp1.uni-regensburg.de> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.74.202.215] MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.59A66E15.004F, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.2.7, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: c26ea7528d0d4faaa80e7ab448b23255 Archived-At: Subject: Re: [Ntp] Antw: Re: WGLC for draft-ietf-ntp-mac X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "tictoc@ietf.org" Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Errors-To: ntp-bounces@ietf.org Sender: "ntp" RGVmaW5pdGVseSwgaXQgd29ya3MgZm9yIG1lOykNCg0KQ2hlZXJzLA0KWXVhbmxvbmcNCg0KLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFVscmljaCBXaW5kbCBbbWFpbHRvOlVscmlj aC5XaW5kbEByei51bmktcmVnZW5zYnVyZy5kZV0gDQpTZW50OiBXZWRuZXNkYXksIEF1Z3VzdCAz MCwgMjAxNyAzOjI0IFBNDQpUbzogSmlhbmd5dWFubG9uZzsgbnRwQGlldGYub3JnOyBvZG9ub2do dWVAaXNvYy5vcmcNCkNjOiB0aWN0b2NAaWV0Zi5vcmcNClN1YmplY3Q6IEFudHc6IFJlOiBbTnRw XSBXR0xDIGZvciBkcmFmdC1pZXRmLW50cC1tYWMNCg0KPj4+IEppYW5neXVhbmxvbmcgPGppYW5n eXVhbmxvbmdAaHVhd2VpLmNvbT4gc2NocmllYiBhbSAyOS4wOC4yMDE3IHVtIA0KPj4+IDA4OjA2 IGluDQpOYWNocmljaHQNCjwzQjBBMUJFRDIyQ0FENjQ5QTFCM0U5N0JFNURERDY4QkJCNTk5OTI0 QGRnZ2VtbDUwNy1tYnguY2hpbmEuaHVhd2VpLmNvbT46DQo+IEhpLCBJIHN1cHBvcnQgdGhlIHB1 YmxpY2F0aW9uIG9mIHRoaXMgZHJhZnQsIHRob3VnaCBJIGhhdmUgc2V2ZXJhbCANCj4gc3VnZ2Vz dGlvbnMgZm9yIHRoZSB0ZXh0czoNCj4gDQo+IA0KPiAxLiAgICAgICDigJxJZiBhdXRoZW50aWNh dGlvbiBpcyBpbXBsZW1lbnRlZCwgdGhlbiBBRVMtQ01BQyBhcyBzcGVjaWZpZWQgaW4NCg0KPiBS RkMNCj4gICAgICAgICA0NDkzIFtSRkM0NDkzXSBzaG91bGQgYmUgY29tcHV0ZWTigKbigJ0gaW4g U2VjdGlvbiAzLg0KPiBUaGlzIGlzIGEgcmVxdWlyZW1lbnQsIHNvIEkgdGhpbmsgaXQgc2hvdWxk IHVzZSDigJxTSE9VTETigJ0gaW5zdGVhZCBvZiANCj4g4oCcc2hvdWxk4oCdLg0KPiBCdXQgaWYg dGhpcyBBRVMtQ01BQyBpcyB0aGUgb25seSBhdXRoZW50aWNhdGlvbiBtZWNoYW5pc20sIGl0IGlz IA0KPiBiZXR0ZXIgdG8gdXNlIOKAnE1VU1TigJ0uDQo+IA0KPiANCj4gMi4gICAgICAg4oCcV2Ug cmVjb21tZW5kIHRoYXQgdGhlIE1BQyBrZXkgZm9yIE5UUCBTSE9VTEQgYmUgMTI4IGJpdHMgbG9u ZyANCj4gQUVTLTEyOCBrZXnigKbigJ0gaW4gU2VjdGlvbiAzLg0KPiBUbyBiZSBtb3JlIGZvcm1h bCwgbWF5YmUgaXQgY2FuIGJlIHJlcGhyYXNlZCBpbnRvIOKAnEl0IGlzIFJFQ09NTUVOREVEIA0K PiB0aGF0DQoNCj4gdGhlIE1BQyBrZXkgZm9yIE5UUCBTSE9VTEQgYmUgMTI4IGJpdHMgbG9uZyBB RVMtMTI4IGtleeKApuKAnQ0KDQpXaHkgbm90OiAiVGhlIE1BQyBrZXkgZm9yIE5UUCBTSE9VTEQg YmUgYSAxMjggYml0cyBsb25nIEFFUy0xMjgga2V54oCmIj8NCg0KWy4uLl0NCg0KUmVnYXJkcywN ClVscmljaA0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fCm50cCBtYWlsaW5nIGxpc3QKbnRwQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbnRwCg== From nobody Wed Aug 30 00:49:58 2017 Return-Path: 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 C0A94132386; Wed, 30 Aug 2017 00:49:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 nAFBR6duCVzS; Wed, 30 Aug 2017 00:49:49 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E21AF1323B5; Wed, 30 Aug 2017 00:49:42 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DUK93719; Wed, 30 Aug 2017 07:49:40 +0000 (GMT) Received: from DGGEML403-HUB.china.huawei.com (10.3.17.33) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 30 Aug 2017 08:48:56 +0100 Received: from DGGEML507-MBX.china.huawei.com ([169.254.2.7]) by DGGEML403-HUB.china.huawei.com ([fe80::74d9:c659:fbec:21fa%31]) with mapi id 14.03.0301.000; Wed, 30 Aug 2017 15:48:40 +0800 From: Jiangyuanlong To: Ulrich Windl , "ntp@ietf.org" , "odonoghue@isoc.org" CC: "tictoc@ietf.org" Thread-Topic: Antw: Re: [Ntp] WGLC for draft-ietf-ntp-mac Thread-Index: AQHTEMt6dgTCyuPEXEODOT5Gsnqn3aKawq4AgAFXiwCAAIuc8A== Date: Wed, 30 Aug 2017 07:48:40 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68BBB599FEF@dggeml507-mbx.china.huawei.com> References: <3B0A1BED22CAD649A1B3E97BE5DDD68BBB599924@dggeml507-mbx.china.huawei.com> <59A66816020000A100027A91@gwsmtp1.uni-regensburg.de> In-Reply-To: <59A66816020000A100027A91@gwsmtp1.uni-regensburg.de> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.74.202.215] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.59A66E15.004F, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.2.7, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: c26ea7528d0d4faaa80e7ab448b23255 Archived-At: Subject: Re: [Ntp] Antw: Re: WGLC for draft-ietf-ntp-mac X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 07:49:51 -0000 RGVmaW5pdGVseSwgaXQgd29ya3MgZm9yIG1lOykNCg0KQ2hlZXJzLA0KWXVhbmxvbmcNCg0KLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFVscmljaCBXaW5kbCBbbWFpbHRvOlVscmlj aC5XaW5kbEByei51bmktcmVnZW5zYnVyZy5kZV0gDQpTZW50OiBXZWRuZXNkYXksIEF1Z3VzdCAz MCwgMjAxNyAzOjI0IFBNDQpUbzogSmlhbmd5dWFubG9uZzsgbnRwQGlldGYub3JnOyBvZG9ub2do dWVAaXNvYy5vcmcNCkNjOiB0aWN0b2NAaWV0Zi5vcmcNClN1YmplY3Q6IEFudHc6IFJlOiBbTnRw XSBXR0xDIGZvciBkcmFmdC1pZXRmLW50cC1tYWMNCg0KPj4+IEppYW5neXVhbmxvbmcgPGppYW5n eXVhbmxvbmdAaHVhd2VpLmNvbT4gc2NocmllYiBhbSAyOS4wOC4yMDE3IHVtIA0KPj4+IDA4OjA2 IGluDQpOYWNocmljaHQNCjwzQjBBMUJFRDIyQ0FENjQ5QTFCM0U5N0JFNURERDY4QkJCNTk5OTI0 QGRnZ2VtbDUwNy1tYnguY2hpbmEuaHVhd2VpLmNvbT46DQo+IEhpLCBJIHN1cHBvcnQgdGhlIHB1 YmxpY2F0aW9uIG9mIHRoaXMgZHJhZnQsIHRob3VnaCBJIGhhdmUgc2V2ZXJhbCANCj4gc3VnZ2Vz dGlvbnMgZm9yIHRoZSB0ZXh0czoNCj4gDQo+IA0KPiAxLiAgICAgICDigJxJZiBhdXRoZW50aWNh dGlvbiBpcyBpbXBsZW1lbnRlZCwgdGhlbiBBRVMtQ01BQyBhcyBzcGVjaWZpZWQgaW4NCg0KPiBS RkMNCj4gICAgICAgICA0NDkzIFtSRkM0NDkzXSBzaG91bGQgYmUgY29tcHV0ZWTigKbigJ0gaW4g U2VjdGlvbiAzLg0KPiBUaGlzIGlzIGEgcmVxdWlyZW1lbnQsIHNvIEkgdGhpbmsgaXQgc2hvdWxk IHVzZSDigJxTSE9VTETigJ0gaW5zdGVhZCBvZiANCj4g4oCcc2hvdWxk4oCdLg0KPiBCdXQgaWYg dGhpcyBBRVMtQ01BQyBpcyB0aGUgb25seSBhdXRoZW50aWNhdGlvbiBtZWNoYW5pc20sIGl0IGlz IA0KPiBiZXR0ZXIgdG8gdXNlIOKAnE1VU1TigJ0uDQo+IA0KPiANCj4gMi4gICAgICAg4oCcV2Ug cmVjb21tZW5kIHRoYXQgdGhlIE1BQyBrZXkgZm9yIE5UUCBTSE9VTEQgYmUgMTI4IGJpdHMgbG9u ZyANCj4gQUVTLTEyOCBrZXnigKbigJ0gaW4gU2VjdGlvbiAzLg0KPiBUbyBiZSBtb3JlIGZvcm1h bCwgbWF5YmUgaXQgY2FuIGJlIHJlcGhyYXNlZCBpbnRvIOKAnEl0IGlzIFJFQ09NTUVOREVEIA0K PiB0aGF0DQoNCj4gdGhlIE1BQyBrZXkgZm9yIE5UUCBTSE9VTEQgYmUgMTI4IGJpdHMgbG9uZyBB RVMtMTI4IGtleeKApuKAnQ0KDQpXaHkgbm90OiAiVGhlIE1BQyBrZXkgZm9yIE5UUCBTSE9VTEQg YmUgYSAxMjggYml0cyBsb25nIEFFUy0xMjgga2V54oCmIj8NCg0KWy4uLl0NCg0KUmVnYXJkcywN ClVscmljaA0KDQoNCg== From nobody Wed Aug 30 00:53:37 2017 Return-Path: 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 A09311323B5 for ; Wed, 30 Aug 2017 00:53:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no 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 miO8rywspQ5P for ; Wed, 30 Aug 2017 00:53:32 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEE071326FE for ; Wed, 30 Aug 2017 00:53:29 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 705983A245; Wed, 30 Aug 2017 07:53:29 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 705983A245 Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=mlichvar@redhat.com Received: from localhost (unknown [10.43.2.117]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 755FE8E15E; Wed, 30 Aug 2017 07:53:28 +0000 (UTC) Date: Wed, 30 Aug 2017 09:53:31 +0200 From: Miroslav Lichvar To: Daniel Franke Cc: Martin Langer , ntp@ietf.org Message-ID: <20170830075331.GN11067@localhost> References: <70a0c971b2978.598d965e@ostfalia.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.0 (2017-02-23) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Wed, 30 Aug 2017 07:53:29 +0000 (UTC) Archived-At: Subject: Re: [Ntp] some comments on the NTS4NTP-Draft09 X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 07:53:35 -0000 On Tue, Aug 29, 2017 at 02:25:57PM -0400, Daniel Franke wrote: > On 8/11/17, Martin Langer wrote: > > Does it really improve the timekeeping? I think the idea is to reduce the > > asymmetry if the request and response message have the same size. > > But client and server may have different performance and therefore the > > processing speed per NTP Package is different too. ...it's just a thought > > I'm led to believe Prof. Mills did some experiments at one point and > found a non-zero impact from using asymmetrically-sized packets. I > guess a citation here would help. Harlan/Dave, do you know of any > academic reference I can point at to support this claim? If no citation is found, I think it is safe to say that a fundamental property of most networks is that longer packets take longer to transmit and receive. NTP assumes that network delay is symmetric, so the packet size must be symmetric. For instance, on 1Gb ethernet the delay should increase by 1 nanosecond per bit after reaching the minimum frame size. If the size is asymmetric, the asymmetry in delay will multiply with the number of transmissions (including all routers and switches not using cut-through switching) on the path between the client and server. Of course, this would normally not be the only source of asymmetry and symmetric size alone doesn't guarantee accurate measurements. It is possible to measure the asymmetry. Here is a graph of offset of a client directly connected to a server on 1Gb ethernet. The clock was synchronized using symmetric NTP packets. The client also had a "noselect" association with the server, which had requests longer by 28 octets (a dummy extension field) than responses. The expected offset between the two associations is 28 * 8 / 2 = 112 nanoseconds. http://i.imgur.com/hCP9rU2.png -- Miroslav Lichvar From ntp-bounces@ietf.org Wed Aug 30 00:53:37 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F3151323B5; Wed, 30 Aug 2017 00:53:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1504079617; bh=XDvR41Q0NXWYlCd1aS95raODqLYGqGm+E7MUQkT52GY=; h=Date:From:To:References:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc; b=lHOpYuC9UzR3S/lIKUUqlqxh2tCDD1S1Yo7LO5uMGGbiVxqc5RvEjz4yZ4+5FmV63 pEneu8Q+Jy1LKPuIKW9wAdNs3MlZi1Zsq+h38ZjUqK/tQn75LhIOi938yE21SEYX5P um2x2BVYgJG41wTw8Ho7ZFkIpT59ByBRgw77SMeY= 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 A09311323B5 for ; Wed, 30 Aug 2017 00:53:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no 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 miO8rywspQ5P for ; Wed, 30 Aug 2017 00:53:32 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEE071326FE for ; Wed, 30 Aug 2017 00:53:29 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 705983A245; Wed, 30 Aug 2017 07:53:29 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 705983A245 Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=mlichvar@redhat.com Received: from localhost (unknown [10.43.2.117]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 755FE8E15E; Wed, 30 Aug 2017 07:53:28 +0000 (UTC) Date: Wed, 30 Aug 2017 09:53:31 +0200 From: Miroslav Lichvar To: Daniel Franke Message-ID: <20170830075331.GN11067@localhost> References: <70a0c971b2978.598d965e@ostfalia.de> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.0 (2017-02-23) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Wed, 30 Aug 2017 07:53:29 +0000 (UTC) Archived-At: Subject: Re: [Ntp] some comments on the NTS4NTP-Draft09 X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: ntp@ietf.org, Martin Langer Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ntp-bounces@ietf.org Sender: "ntp" On Tue, Aug 29, 2017 at 02:25:57PM -0400, Daniel Franke wrote: > On 8/11/17, Martin Langer wrote: > > Does it really improve the timekeeping? I think the idea is to reduce the > > asymmetry if the request and response message have the same size. > > But client and server may have different performance and therefore the > > processing speed per NTP Package is different too. ...it's just a thought > > I'm led to believe Prof. Mills did some experiments at one point and > found a non-zero impact from using asymmetrically-sized packets. I > guess a citation here would help. Harlan/Dave, do you know of any > academic reference I can point at to support this claim? If no citation is found, I think it is safe to say that a fundamental property of most networks is that longer packets take longer to transmit and receive. NTP assumes that network delay is symmetric, so the packet size must be symmetric. For instance, on 1Gb ethernet the delay should increase by 1 nanosecond per bit after reaching the minimum frame size. If the size is asymmetric, the asymmetry in delay will multiply with the number of transmissions (including all routers and switches not using cut-through switching) on the path between the client and server. Of course, this would normally not be the only source of asymmetry and symmetric size alone doesn't guarantee accurate measurements. It is possible to measure the asymmetry. Here is a graph of offset of a client directly connected to a server on 1Gb ethernet. The clock was synchronized using symmetric NTP packets. The client also had a "noselect" association with the server, which had requests longer by 28 octets (a dummy extension field) than responses. The expected offset between the two associations is 28 * 8 / 2 = 112 nanoseconds. http://i.imgur.com/hCP9rU2.png -- Miroslav Lichvar _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp From nobody Wed Aug 30 02:25:55 2017 Return-Path: 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 12444132D44; Wed, 30 Aug 2017 02:25:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no 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 mmf1N0fVYJZE; Wed, 30 Aug 2017 02:25:51 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6435913235C; Wed, 30 Aug 2017 02:25:51 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 07C18800A4; Wed, 30 Aug 2017 09:25:51 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 07C18800A4 Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=mlichvar@redhat.com Received: from localhost (unknown [10.43.2.117]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 324EA91537; Wed, 30 Aug 2017 09:25:50 +0000 (UTC) Date: Wed, 30 Aug 2017 11:25:53 +0200 From: Miroslav Lichvar To: Karen O'Donoghue Cc: "ntp@ietf.org" , "tictoc@ietf.org" Message-ID: <20170830092553.GO11067@localhost> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.0 (2017-02-23) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Wed, 30 Aug 2017 09:25:51 +0000 (UTC) Archived-At: Subject: Re: [Ntp] WGLC for draft-ietf-ntp-mac X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 09:25:53 -0000 On Wed, Aug 09, 2017 at 04:53:43AM +0000, Karen O'Donoghue wrote: > This begins a three week working group last call (WGLC) for "Message Authentication Code for the Network Time Protocol" > https://datatracker.ietf.org/doc/draft-ietf-ntp-mac/ I approve the advancement of the document. My only suggestion would be remove or modify the sentence: "These are important considerations for NTP, since latency directly affects jitter and therefore the accuracy of time synchronization.". I think it's the stability of the latency what directly affects jitter, not the latency itself. Transmit timestamps can be corrected for a stable latency in the MAC calculation to minimize the effect it has on accuracy. With a shorter latency that becomes less important. -- Miroslav Lichvar From ntp-bounces@ietf.org Wed Aug 30 02:25:55 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 16B7813293A; Wed, 30 Aug 2017 02:25:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1504085155; bh=sucf7aLiHVfak1F8rbnVSO5cFiUHQ9RtQZo7hTkF33Q=; h=Date:From:To:References:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc; b=frB+JC97COcgyVsjXSlqrhfPPEVwp6rPfeBJtGzkaFNkuRr9Ue/bEZBlhlKukUQ9A EgRFOriGhPzwcRho60SqsSAWRGQ/mlEeGN9pqZKDNgmbTZ1KEboP2S8sx9NE9E12pM aEST6eyDIyfDxk5xbCiQDsM4XwiN5FLUSTGLo6Us= 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 12444132D44; Wed, 30 Aug 2017 02:25:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no 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 mmf1N0fVYJZE; Wed, 30 Aug 2017 02:25:51 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6435913235C; Wed, 30 Aug 2017 02:25:51 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 07C18800A4; Wed, 30 Aug 2017 09:25:51 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 07C18800A4 Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=mlichvar@redhat.com Received: from localhost (unknown [10.43.2.117]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 324EA91537; Wed, 30 Aug 2017 09:25:50 +0000 (UTC) Date: Wed, 30 Aug 2017 11:25:53 +0200 From: Miroslav Lichvar To: Karen O'Donoghue Message-ID: <20170830092553.GO11067@localhost> References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.0 (2017-02-23) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Wed, 30 Aug 2017 09:25:51 +0000 (UTC) Archived-At: Subject: Re: [Ntp] WGLC for draft-ietf-ntp-mac X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "ntp@ietf.org" , "tictoc@ietf.org" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ntp-bounces@ietf.org Sender: "ntp" On Wed, Aug 09, 2017 at 04:53:43AM +0000, Karen O'Donoghue wrote: > This begins a three week working group last call (WGLC) for "Message Authentication Code for the Network Time Protocol" > https://datatracker.ietf.org/doc/draft-ietf-ntp-mac/ I approve the advancement of the document. My only suggestion would be remove or modify the sentence: "These are important considerations for NTP, since latency directly affects jitter and therefore the accuracy of time synchronization.". I think it's the stability of the latency what directly affects jitter, not the latency itself. Transmit timestamps can be corrected for a stable latency in the MAC calculation to minimize the effect it has on accuracy. With a shorter latency that becomes less important. -- Miroslav Lichvar _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp From nobody Wed Aug 30 02:40:43 2017 Return-Path: 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 272B61323F7 for ; Wed, 30 Aug 2017 02:40:41 -0700 (PDT) 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=libertysys.com.au 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 WwZSCcPljOGC for ; Wed, 30 Aug 2017 02:40:39 -0700 (PDT) Received: from mail.libertysys.com.au (ppp178-79.static.internode.on.net [150.101.178.79]) (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 1C41B13235C for ; Wed, 30 Aug 2017 02:40:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.libertysys.com.au (Postfix) with ESMTP id 5DFF392243 for ; Wed, 30 Aug 2017 19:40:36 +1000 (AEST) X-Virus-Scanned: Debian amavisd-new at mail2.gear.dyndns.org Received: from mail.libertysys.com.au ([127.0.0.1]) by localhost (mail.gear.dyndns.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pgj3soYaqRW3 for ; Wed, 30 Aug 2017 19:40:28 +1000 (AEST) Received: from [172.22.64.102] (eber-home.gear.dyndns.org [172.22.64.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.libertysys.com.au (Postfix) with ESMTPSA id A3BA6920C2 for ; Wed, 30 Aug 2017 19:40:27 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=libertysys.com.au; s=2016; t=1504086027; bh=SJmhZ/B5IZ4X93eDTdXzuCDc2OwGM5nUSUNf2l4i6MA=; h=Subject:To:References:From:Date:In-Reply-To; b=boKl/Y9Z4xG4Nch3MQcHZj/vJxGoXjxmqjydHVvvub6ZUAqZp6qqzcPedPiVBKHLk +eQhr099OF0BIoyprcsPcKRZQvY2p0iipBW1Qo2a6HLBKS0CWtJTAYuAAQvnqeiVTj il+F5Mv5sc8xA6p/oEZnIMDVPjN2VdLyglaPFP4s= To: ntp@ietf.org References: From: Paul Gear Message-ID: <9b9c364b-22d5-ca8f-aa80-6f99f632749d@libertysys.com.au> Date: Wed, 30 Aug 2017 19:40:26 +1000 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Content-Language: en-AU Archived-At: Subject: Re: [Ntp] [NTP] WGLC for draft-ietf-ntp-using-nts-for-ntp (Requirements Language / NTP Pools) X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 09:40:41 -0000 On 30/08/17 16:50, kristof.teichel@ptb.de wrote: > > 3.) > I like the current name "cookie placeholder" over the suggestion > "cookie request", simply because the former is more descriptive with > regard to the same-length notion. > I do, however, not have a strong opinion on this. I don't have a strong opinion on this either; I just found that on initial reading it made more sense to think of it in this way - especially when viewed in light of the fact that the number of cookie placeholders normally indicates to the server the number of missed replies since the last exchange. > > 5.) (Also goes to an issue raised implicitly by Harlan & Dave) > Concerning the NTP pools passage, I think there is something to the > raised concerns, but I would approach the issue via the phrasing of > the paragraph. > I suggest instead of simply saying "pool operators" or "pools" (which > does silently imply ALL of them). we move to saying "some pool > operators / pools", since the problem persists even if it does not > concern all instances. > My text suggestion is: > > "[...] A more important matter, however, is that not all pool > operators have procedures for establishing and maintaining trust in > their members. > Pools in existence as of 2017 are often volunteer-run, some of > them with minimal requirements for admission and/or with no organized > effort to monitor pool servers for misbehavior. [...]" Is there more than one pool? I'm only aware of pool.ntp.org, which is volunteer-run and has minimal requirements for admission, but certainly monitors its members. Results of this monitoring are publicly available at http://www.pool.ntp.org/scores/[IP address] (e.g. here's one of mine: http://www.pool.ntp.org/scores/2001:44b8:2100:3f00::7b). I think this qualifies as "an organised effort to monitor pool servers for misbehavior". > I think this text does the same thing for the conclusion (in general, > using pools with NTS is a bad idea), but hopefully more people will > view it as factually correct. I would hope that this conclusion is specifically what NTS is aiming to avoid. With respect to NTS' privacy/unlinkability aims, I would have thought that the most common use case would be with garden variety phones, tablets, PCs, & IoT devices, many (most?) of which use the NTP pool. Aiming for a system which works with the pool would bring the greatest privacy benefit to the greatest number of users. (And I would argue that the pool requiring NTS support from participants could become a useful tool in driving NTS adoption, once the questions about certificate validation are answered.) Regards, Paul From ntp-bounces@ietf.org Wed Aug 30 02:40:43 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E06813235C; Wed, 30 Aug 2017 02:40:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1504086043; bh=LOAs8dOnp7zDfErQs4690CV3SjezAX7twzb6TdiUSiw=; h=To:References:From:Date:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe; b=ryQO5SOYJpv1CinVu55liODlZft/sMfQ5KHc+Loy88ytMITPlO+QVdU0ZrHuFnPV+ GdMcEGssj+oH1X3172hfo6UqHalYeIP5/lwI5xpraLbvtxDFjajtHx0CCirZBPYcqk XdIwx2v/Z0T8UeJSWmGISA8hxI3KXezSCmlhxtD4= 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 272B61323F7 for ; Wed, 30 Aug 2017 02:40:41 -0700 (PDT) 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=libertysys.com.au 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 WwZSCcPljOGC for ; Wed, 30 Aug 2017 02:40:39 -0700 (PDT) Received: from mail.libertysys.com.au (ppp178-79.static.internode.on.net [150.101.178.79]) (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 1C41B13235C for ; Wed, 30 Aug 2017 02:40:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.libertysys.com.au (Postfix) with ESMTP id 5DFF392243 for ; Wed, 30 Aug 2017 19:40:36 +1000 (AEST) X-Virus-Scanned: Debian amavisd-new at mail2.gear.dyndns.org Received: from mail.libertysys.com.au ([127.0.0.1]) by localhost (mail.gear.dyndns.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pgj3soYaqRW3 for ; Wed, 30 Aug 2017 19:40:28 +1000 (AEST) Received: from [172.22.64.102] (eber-home.gear.dyndns.org [172.22.64.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.libertysys.com.au (Postfix) with ESMTPSA id A3BA6920C2 for ; Wed, 30 Aug 2017 19:40:27 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=libertysys.com.au; s=2016; t=1504086027; bh=SJmhZ/B5IZ4X93eDTdXzuCDc2OwGM5nUSUNf2l4i6MA=; h=Subject:To:References:From:Date:In-Reply-To; b=boKl/Y9Z4xG4Nch3MQcHZj/vJxGoXjxmqjydHVvvub6ZUAqZp6qqzcPedPiVBKHLk +eQhr099OF0BIoyprcsPcKRZQvY2p0iipBW1Qo2a6HLBKS0CWtJTAYuAAQvnqeiVTj il+F5Mv5sc8xA6p/oEZnIMDVPjN2VdLyglaPFP4s= To: ntp@ietf.org References: From: Paul Gear Message-ID: <9b9c364b-22d5-ca8f-aa80-6f99f632749d@libertysys.com.au> Date: Wed, 30 Aug 2017 19:40:26 +1000 MIME-Version: 1.0 In-Reply-To: Content-Language: en-AU Archived-At: Subject: Re: [Ntp] [NTP] WGLC for draft-ietf-ntp-using-nts-for-ntp (Requirements Language / NTP Pools) X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ntp-bounces@ietf.org Sender: "ntp" On 30/08/17 16:50, kristof.teichel@ptb.de wrote: > > 3.) > I like the current name "cookie placeholder" over the suggestion > "cookie request", simply because the former is more descriptive with > regard to the same-length notion. > I do, however, not have a strong opinion on this. I don't have a strong opinion on this either; I just found that on initial reading it made more sense to think of it in this way - especially when viewed in light of the fact that the number of cookie placeholders normally indicates to the server the number of missed replies since the last exchange. > > 5.) (Also goes to an issue raised implicitly by Harlan & Dave) > Concerning the NTP pools passage, I think there is something to the > raised concerns, but I would approach the issue via the phrasing of > the paragraph. > I suggest instead of simply saying "pool operators" or "pools" (which > does silently imply ALL of them). we move to saying "some pool > operators / pools", since the problem persists even if it does not > concern all instances. > My text suggestion is: > > "[...] A more important matter, however, is that not all pool > operators have procedures for establishing and maintaining trust in > their members. > Pools in existence as of 2017 are often volunteer-run, some of > them with minimal requirements for admission and/or with no organized > effort to monitor pool servers for misbehavior. [...]" Is there more than one pool? I'm only aware of pool.ntp.org, which is volunteer-run and has minimal requirements for admission, but certainly monitors its members. Results of this monitoring are publicly available at http://www.pool.ntp.org/scores/[IP address] (e.g. here's one of mine: http://www.pool.ntp.org/scores/2001:44b8:2100:3f00::7b). I think this qualifies as "an organised effort to monitor pool servers for misbehavior". > I think this text does the same thing for the conclusion (in general, > using pools with NTS is a bad idea), but hopefully more people will > view it as factually correct. I would hope that this conclusion is specifically what NTS is aiming to avoid. With respect to NTS' privacy/unlinkability aims, I would have thought that the most common use case would be with garden variety phones, tablets, PCs, & IoT devices, many (most?) of which use the NTP pool. Aiming for a system which works with the pool would bring the greatest privacy benefit to the greatest number of users. (And I would argue that the pool requiring NTS support from participants could become a useful tool in driving NTS adoption, once the questions about certificate validation are answered.) Regards, Paul _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp From ntp-bounces@ietf.org Wed Aug 30 08:07:15 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 67BC0132D4E; Wed, 30 Aug 2017 08:07:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1504105635; bh=dWWnHtk1mSHUBCtV/HOCDP4/pb/pVNVt30HKy1iFB+Y=; h=From:To:Date:References:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc; b=lqIcQrl6HoPSda+99S0tWpm1FH3+xoZpqXg+00O6PjCAGnKS0ju8YnTeMXqKFWe4S X05ruaXHXeNRId+5jnN27U3Sm+y0t8o7enhB2dqpHEE9FivtkhqMXAIVnQh1whb3Vd FC8OhV9vp9I7U7owI9BgvtwIBEQ+qzfM18iW6elo= 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 ED473132D42 for ; Wed, 30 Aug 2017 08:07:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ptbde.onmicrosoft.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 y2UEGzQ8UQIX for ; Wed, 30 Aug 2017 08:07:10 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0096.outbound.protection.outlook.com [104.47.1.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F808132D01 for ; Wed, 30 Aug 2017 08:07:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ptbde.onmicrosoft.com; s=selector1-ptbde-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=hNx/iF9YeLtY422A+r+TFItU7Y+L83lKWZuGcTLYKPE=; b=aqfg1zzVb7SR8AGAFbU7lFUcWLHxPohUmkdtAzi7atOaN3rcLE9SoXfFbL+v3GftCFPsZgtzkQH+ZaWjDKGZ3gG9CL8Vikoql5HgjqtPrnU8haHUmc4YjVkne8c/TwZ7R1tZii6LDtPHvvIBoNNHwhMvGvoWhvWZ4OYf46ERPBo= Received: from DB3PR05MB172.eurprd05.prod.outlook.com (10.242.132.18) by DB3PR05MB0844.eurprd05.prod.outlook.com (10.161.58.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1385.9; Wed, 30 Aug 2017 15:07:06 +0000 Received: from DB3PR05MB172.eurprd05.prod.outlook.com ([fe80::cf:70d1:53e0:1a6a]) by DB3PR05MB172.eurprd05.prod.outlook.com ([fe80::cf:70d1:53e0:1a6a%17]) with mapi id 15.01.1385.014; Wed, 30 Aug 2017 15:07:06 +0000 From: Dieter Sibold To: Daniel Franke , "kristof.teichel@ptb.de" Thread-Topic: [Ntp] Antwort: Re: WGLC for draft-ietf-ntp-using-nts-for-ntp Thread-Index: AQHTIQDYxp1/LqaM6UCjJ3QzxPPPcqKdADwA Date: Wed, 30 Aug 2017 15:07:06 +0000 Message-ID: References: <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> <19062708.TpRPKSgBD8@eris> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=dieter.sibold@ptbde.onmicrosoft.com; x-originating-ip: [92.77.23.158] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB3PR05MB0844; 6:nhwEXSlogXZe8Fchp4504LPwYBNNq2A3O7SGhMhkWHCq9i5s5I2My3Ugc6bbQEOFKPpcid+Ifti2uyJtM3a3DCI6asl3hv68KkReWh871iiA8+dw7IatjMSR9wRiqwt+8J4USKbndp77+akbis+IC3+tnl0Akm91OG8eoa1SAvCLvciVRoz+eh7ZXKnrFMRqZuhQK37uSquy4ieL8qivttqpugPQH0KG2OFDTxQKYDr0kjY3ulJzDeAus5r3ft92yI7dCzQm/5fLLt2osPvthzd9whSJf7Ouqx4VroRKsenP/dKdY+aMaJZBJ4ikXU6f2F83JxiDmSUPWLDCh8qVbg==; 5:jhnMxAppt1Bn3mvYU9jBF81WY/w+DFe3/G1UvfXnfS0fM8hxVRjw0MA5ZJ5R7F8O2XvTacBqIib12+udE5iL0WObsD5XTgI25MxkBWbDhZZwfzsn8FNtqqzrmJZqXbk3GSazwQK0Q1I3UiA5IEeKJg==; 24:CmjjFjMZeOjfPLC+RO6RcKpNRtCucEy4baqfEkqDjj54pE0GvjDOuDmQZjcbM6NK1ykZoEQC5O2IQghkifv5XoiCHmAj8v6P79JDkyciJug=; 7:usMQDpY+k7fLWWO+lhc+NqnY2JxzJ4LD3cNK3DDRwTwmEd7/3xXozlr9u1v7tZwT8ZvqTX1yXlOs6+fG5masrW8CXlQk/qAQtE7+pP97QvrQh462eTfcFuSoIcczrp9iQD50vP9oCGqEX13Dc5gYgDMgcsJrF215yV9ndF60QbLQt6RNB8Ei983h/p+QB6n9jz4Sh96glwYYGgGF1ZDwuazeNlLX9ZfWtJkLMVPS1lU= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 6614de9e-e2cf-450f-42c5-08d4efb8c772 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(2017082002075)(300000503095)(300135400095)(2017052603199)(201703131423075)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DB3PR05MB0844; x-ms-traffictypediagnostic: DB3PR05MB0844: x-exchange-antispam-report-test: UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3002001)(100000703101)(100105400095)(6041248)(20161123562025)(2016111802025)(20161123564025)(20161123558100)(201703131423075)(201703061421075)(20161123555025)(20161123560025)(6043046)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DB3PR05MB0844; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DB3PR05MB0844; x-forefront-prvs: 041517DFAB x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(24454002)(377454003)(189002)(199003)(53546010)(2501003)(2906002)(86902001)(2950100002)(9686003)(7696004)(54906002)(99286003)(86442002)(55016002)(6306002)(50986999)(3846002)(66066001)(102836003)(6506006)(6116002)(53936002)(42882006)(3660700001)(14454004)(5250100002)(97736004)(5890100001)(2900100001)(6456002)(6436002)(229853002)(25786009)(39060400002)(81166006)(93886005)(8676002)(105586002)(64872007)(86362001)(8936002)(106356001)(33656002)(508600001)(3280700002)(7736002)(305945005)(6246003)(74316002)(101416001)(5660300001)(76176999)(54356999)(68736007)(230783001)(189998001)(4326008)(966005)(81156014); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR05MB0844; H:DB3PR05MB172.eurprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; received-spf: None (protection.outlook.com: ptbde.onmicrosoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: ptbde.onmicrosoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Aug 2017 15:07:06.3226 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 463cf4b2-037b-4a7c-a75c-ae2c1aef241a X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR05MB0844 Archived-At: Subject: Re: [Ntp] Antwort: Re: WGLC for draft-ietf-ntp-using-nts-for-ntp X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "ntp@ietf.org" , Robert Annessi Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ntp-bounces@ietf.org Sender: "ntp" As Robert pointed out with the lack of broadcast support we cannot protect PTP's timing messages. The only input of this draft to PTP could be the key exchange. Therefore, I also agree to drop PTP from this draft. Dieter -----Original Message----- From: ntp [mailto:ntp-bounces@ietf.org] On Behalf Of Daniel Franke Sent: Tuesday, August 29, 2017 9:56 PM To: kristof.teichel@ptb.de Cc: ntp@ietf.org; Robert Annessi Subject: Re: [Ntp] Antwort: Re: WGLC for draft-ietf-ntp-using-nts-for-ntp On 8/29/17, kristof.teichel@ptb.de wrote: > I knew there was something that I had wanted to contribute to the > discussion for a long time but just kind of forgotten. > This was it. > > I agree that this is a problem in the text, and I vote for taking out > all passages that specifically mention PTP in this context. Well, you're the reason I had it there to begin with. I thought you and Dieter still had ambitions to get something working wrt PTP. If that's no longer the case then, without objection, I'll remove that reference from the intro. Besides the Terms and Abbreviations appendix, the only other reference to PTP is an IANA request to reserve NTS Next Protocol code 1 for use with PTP. Since we changed these codes from textual to numeric I guess there's no reason to keep that either; we can always request a new allocation once there's something concrete to attach to it. _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp From nobody Wed Aug 30 08:07:15 2017 Return-Path: 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 ED473132D42 for ; Wed, 30 Aug 2017 08:07:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ptbde.onmicrosoft.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 y2UEGzQ8UQIX for ; Wed, 30 Aug 2017 08:07:10 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0096.outbound.protection.outlook.com [104.47.1.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F808132D01 for ; Wed, 30 Aug 2017 08:07:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ptbde.onmicrosoft.com; s=selector1-ptbde-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=hNx/iF9YeLtY422A+r+TFItU7Y+L83lKWZuGcTLYKPE=; b=aqfg1zzVb7SR8AGAFbU7lFUcWLHxPohUmkdtAzi7atOaN3rcLE9SoXfFbL+v3GftCFPsZgtzkQH+ZaWjDKGZ3gG9CL8Vikoql5HgjqtPrnU8haHUmc4YjVkne8c/TwZ7R1tZii6LDtPHvvIBoNNHwhMvGvoWhvWZ4OYf46ERPBo= Received: from DB3PR05MB172.eurprd05.prod.outlook.com (10.242.132.18) by DB3PR05MB0844.eurprd05.prod.outlook.com (10.161.58.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1385.9; Wed, 30 Aug 2017 15:07:06 +0000 Received: from DB3PR05MB172.eurprd05.prod.outlook.com ([fe80::cf:70d1:53e0:1a6a]) by DB3PR05MB172.eurprd05.prod.outlook.com ([fe80::cf:70d1:53e0:1a6a%17]) with mapi id 15.01.1385.014; Wed, 30 Aug 2017 15:07:06 +0000 From: Dieter Sibold To: Daniel Franke , "kristof.teichel@ptb.de" CC: "ntp@ietf.org" , Robert Annessi Thread-Topic: [Ntp] Antwort: Re: WGLC for draft-ietf-ntp-using-nts-for-ntp Thread-Index: AQHTIQDYxp1/LqaM6UCjJ3QzxPPPcqKdADwA Date: Wed, 30 Aug 2017 15:07:06 +0000 Message-ID: References: <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> <19062708.TpRPKSgBD8@eris> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=dieter.sibold@ptbde.onmicrosoft.com; x-originating-ip: [92.77.23.158] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB3PR05MB0844; 6:nhwEXSlogXZe8Fchp4504LPwYBNNq2A3O7SGhMhkWHCq9i5s5I2My3Ugc6bbQEOFKPpcid+Ifti2uyJtM3a3DCI6asl3hv68KkReWh871iiA8+dw7IatjMSR9wRiqwt+8J4USKbndp77+akbis+IC3+tnl0Akm91OG8eoa1SAvCLvciVRoz+eh7ZXKnrFMRqZuhQK37uSquy4ieL8qivttqpugPQH0KG2OFDTxQKYDr0kjY3ulJzDeAus5r3ft92yI7dCzQm/5fLLt2osPvthzd9whSJf7Ouqx4VroRKsenP/dKdY+aMaJZBJ4ikXU6f2F83JxiDmSUPWLDCh8qVbg==; 5:jhnMxAppt1Bn3mvYU9jBF81WY/w+DFe3/G1UvfXnfS0fM8hxVRjw0MA5ZJ5R7F8O2XvTacBqIib12+udE5iL0WObsD5XTgI25MxkBWbDhZZwfzsn8FNtqqzrmJZqXbk3GSazwQK0Q1I3UiA5IEeKJg==; 24:CmjjFjMZeOjfPLC+RO6RcKpNRtCucEy4baqfEkqDjj54pE0GvjDOuDmQZjcbM6NK1ykZoEQC5O2IQghkifv5XoiCHmAj8v6P79JDkyciJug=; 7:usMQDpY+k7fLWWO+lhc+NqnY2JxzJ4LD3cNK3DDRwTwmEd7/3xXozlr9u1v7tZwT8ZvqTX1yXlOs6+fG5masrW8CXlQk/qAQtE7+pP97QvrQh462eTfcFuSoIcczrp9iQD50vP9oCGqEX13Dc5gYgDMgcsJrF215yV9ndF60QbLQt6RNB8Ei983h/p+QB6n9jz4Sh96glwYYGgGF1ZDwuazeNlLX9ZfWtJkLMVPS1lU= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 6614de9e-e2cf-450f-42c5-08d4efb8c772 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(2017082002075)(300000503095)(300135400095)(2017052603199)(201703131423075)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DB3PR05MB0844; x-ms-traffictypediagnostic: DB3PR05MB0844: x-exchange-antispam-report-test: UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3002001)(100000703101)(100105400095)(6041248)(20161123562025)(2016111802025)(20161123564025)(20161123558100)(201703131423075)(201703061421075)(20161123555025)(20161123560025)(6043046)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DB3PR05MB0844; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DB3PR05MB0844; x-forefront-prvs: 041517DFAB x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(24454002)(377454003)(189002)(199003)(53546010)(2501003)(2906002)(86902001)(2950100002)(9686003)(7696004)(54906002)(99286003)(86442002)(55016002)(6306002)(50986999)(3846002)(66066001)(102836003)(6506006)(6116002)(53936002)(42882006)(3660700001)(14454004)(5250100002)(97736004)(5890100001)(2900100001)(6456002)(6436002)(229853002)(25786009)(39060400002)(81166006)(93886005)(8676002)(105586002)(64872007)(86362001)(8936002)(106356001)(33656002)(508600001)(3280700002)(7736002)(305945005)(6246003)(74316002)(101416001)(5660300001)(76176999)(54356999)(68736007)(230783001)(189998001)(4326008)(966005)(81156014); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR05MB0844; H:DB3PR05MB172.eurprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; received-spf: None (protection.outlook.com: ptbde.onmicrosoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ptbde.onmicrosoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Aug 2017 15:07:06.3226 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 463cf4b2-037b-4a7c-a75c-ae2c1aef241a X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR05MB0844 Archived-At: Subject: Re: [Ntp] Antwort: Re: WGLC for draft-ietf-ntp-using-nts-for-ntp X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 15:07:14 -0000 As Robert pointed out with the lack of broadcast support we cannot protect = PTP's timing messages. The only input of this draft to PTP could be the key= exchange. Therefore, I also agree to drop PTP from this draft. Dieter -----Original Message----- From: ntp [mailto:ntp-bounces@ietf.org] On Behalf Of Daniel Franke Sent: Tuesday, August 29, 2017 9:56 PM To: kristof.teichel@ptb.de Cc: ntp@ietf.org; Robert Annessi Subject: Re: [Ntp] Antwort: Re: WGLC for draft-ietf-ntp-using-nts-for-ntp On 8/29/17, kristof.teichel@ptb.de wrote: > I knew there was something that I had wanted to contribute to the=20 > discussion for a long time but just kind of forgotten. > This was it. > > I agree that this is a problem in the text, and I vote for taking out=20 > all passages that specifically mention PTP in this context. Well, you're the reason I had it there to begin with. I thought you and Die= ter still had ambitions to get something working wrt PTP. If that's no long= er the case then, without objection, I'll remove that reference from the in= tro. Besides the Terms and Abbreviations appendix, the only other reference to P= TP is an IANA request to reserve NTS Next Protocol code 1 for use with PTP.= Since we changed these codes from textual to numeric I guess there's no re= ason to keep that either; we can always request a new allocation once there= 's something concrete to attach to it. _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp From nobody Wed Aug 30 08:14:13 2017 Return-Path: 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 1B95013219E; Wed, 30 Aug 2017 08:14:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 QS5o5Nt_A88z; Wed, 30 Aug 2017 08:14:06 -0700 (PDT) Received: from mx1.bs.ptb.de (mx1.bs.ptb.de [IPv6:2001:638:610:bd01::120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0B90132CEA; Wed, 30 Aug 2017 08:14:04 -0700 (PDT) Received: from smtp-hub.bs.ptb.de (smtpint01.bs.ptb.de [141.25.87.32]) by mx1.bs.ptb.de with ESMTP id v7UFE2iS009808-v7UFE2iU009808 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 30 Aug 2017 17:14:02 +0200 Received: from rose.bs.ptb.de (rose.bs.ptb.de [141.25.85.201]) by smtp-hub.bs.ptb.de (Postfix) with ESMTPS id 3566553469F; Wed, 30 Aug 2017 17:14:01 +0200 (CEST) In-Reply-To: References: <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> <47b5b4e3-41c9-6779-4a96-b11650483499@nwtime.org> To: Daniel Franke Cc: kristof.teichel@ptb.de, ntp@ietf.org, "ntp" , Harlan Stenn MIME-Version: 1.0 Message-ID: From: dieter.sibold@ptb.de Date: Wed, 30 Aug 2017 17:13:59 +0200 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha-256; boundary=-------z16761_boundary_sign Archived-At: Subject: [Ntp] Antwort: Re: WGLC for draft-ietf-ntp-using-nts-for-ntp X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 15:14:10 -0000 This is an S/MIME signed message. ---------z16761_boundary_sign Content-Type: multipart/alternative; boundary="=_alternative 0053AD94C125818C_=" Dies ist eine mehrteilige Nachricht im MIME-Format. --=_alternative 0053AD94C125818C_= Content-Type: text/plain; charset="US-ASCII" "ntp" schrieb am 30.08.2017 00:44:53: > Von: Daniel Franke > An: kristof.teichel@ptb.de > Kopie: ntp@ietf.org, Harlan Stenn > Datum: 30.08.2017 00:45 > Betreff: Re: [Ntp] WGLC for draft-ietf-ntp-using-nts-for-ntp > Gesendet von: "ntp" > > On 8/29/17, kristof.teichel@ptb.de wrote: > > Historically, encapsulation is an overall concept that has been argued > > against a lot in the course of NTS (as far as I've witnessed it). > > Therefore, I think that a paragraph of discussion on the presumed > > negligibiliy of the precision loss with DTLS-encapsulation is warranted. > > > > Especially in the case of transmit timestamps (where every cryptographic > > operation takes place between the reading of the timestamp and the actual > > time of transmission that the timestamp was supposed to measure), perhaps it > > should at least be mentioned why this encapsulation is not significantly > > more expensive than e.g. adding a MAC/AEAD value. > > > > One thing I really don't know, however, is where such a piece of text should > > be placed in order to not distort the core specification text (I don't think > > anyone wants to or should have to read a passage about the design decision > > process in the middle of the instructions on how to do the > > DTLS-encapsulation). > > I don't think performance analysis needs to go in the RFC at all. I > can't call to mind any other RFC that has included such a thing, and > I'm certain I've never seen it out of the TLS WG. I agree with Daniel. A standards document is not the appropriate place for a performance analysis. > > But for any skeptics, here's the math. > > Let's start by looking at legacy MD5(K||M). Computing MD5 over 64 > bytes ( 16-byte key, 48-byte NTP header) takes about 900 cycles on my > Broadwell system. > > Now let's look at the AES-CMAC draft and at DTLS encapsulation with AES-GCM. > > For these, a couple optimizations are possible to minimize the time > that elapses between when you call clock_gettime() (or whatever your > OS's equivalent) for the transmit timestamp, and when the > authenticated (and possibly encrypted) packet is ready to send. > > The first optimization is straightforward. AES-CMAC supports > incremental, one-pass computation, as do all (D)TLS ciphers. That > means it's possible to precompute the crypto for every block preceding > the one that holds the transmit timestamp, before the transmit > timestamp is obtained. (This is possible with MD5 too, but it doesn't > buy you anything because MD5's internal block size is larger than the > data being hashed.) > > The second optimization only works in DTLS, and it's *conceptually* > straightforward but probably a pain to implement just on account of > API limitations in TLS libraries. With AES-GCM, as well as with any > stream cipher, you can precompute encryption of the transmit timestamp > even before you have it, because all the expensive parts of encryption > don't depend on the plaintext -- you use your cipher algorithm to > compute a pseudorandom stream of bits and then the combination with > the plaintext is a simple xor (a single CPU cycle, which I'll > neglect). > > An NTP header is 48 octets, which conveniently works out to exactly > three AES blocks. In this situation, AES-CMAC basically acts like > AES-CBC with one extra XOR thrown in and outputting just the final > block. On my Broadwell system, AES-CBC takes about 75 cycles per > block. On Skylake it's somewhat faster. So, to get from capturing the > transmit timestamp to a ready message, you need about 75 CPU cycles if > you optimize or about 225 if you don't. Both of these figures assume > you're at least doing AES key setup before you get the transmit > timestamp. I'm not sure exactly how much key setup adds, probably > another few hundred cycles, but I'm not going to bother measuring it > because not doing that in advance is just dumb. > > Now let's look at DTLS with AES-GCM. A DTLS record consists of a > 12-octet header, treated as associated data, followed by ciphertext > which is internally structured as the > actual encrypted payload followed by a 16-octet authenticator. > > AES-GCM is rather complex, but at high level you can think of it as a > combination of AES-CTR with a non-cryptographic hash called GHASH. Its > cost comes down to the cost of computing AES-CTR over the plaintext, > plus the cost of computing GHASH over the associated data and the > output of AES-CTR, plus the cost of one additional AES operation at > the end. > > AES-CTR allows you use CPU pipelining to encrypt a few blocks in > parallel on a single core. Encrypting one block costs about the same > as one block with AES-CBC (about 75 cycles), but you can do three > blocks for about the same cost as one. GHASH adds about 5 cycles per > block. Regardless, computing the authenticator adds another 75 cycles > or so at the end. > > So with no optimization, we're looking at 75 cycles for AES-CTR, 20 > cycles for GHASH, 75 cycles for the authenticator. > > Basic optimization saves 15 cycles on GHASH, but because of > parallelism doesn't buy anything else. > > Clever optimization cuts out everything except the final authenticator > computation. > > So here's how it roughly works out: > > MD5: 900 cycles > AES-CMAC, no optimization: 225 cycles > AES-CMAC, basic optimization: 75 cycles > DTLS, no optimization: 170 cycles > DTLS, basic optimization: 155 cycles > DTLS, clever optimization: 75 cycles > > 900 cycles for MD5 at 3.5GHz is 257 nanoseconds. In the worst case, > the resulting timing asymmetry throws off your accuracy by half that, > or 128 nanoseconds. That is several orders magnitude smaller than > anything NTP can possibly promise you. If you want to measure the > impact of adding the MD5 step in real world conditions, you will have > an extremely difficult time distinguishing it from zero. > > AES-CMAC and DTLS each cut this performance impact by an additional > order of magnitude. If you try measuring the impact of either one and > tell me that you were able to do so, I will tell you that there is > either something wrong with your experiment or something wrong with > your crypto implementation. > > DTLS encapsulation is *just fine*. > > _______________________________________________ > ntp mailing list > ntp@ietf.org > https://www.ietf.org/mailman/listinfo/ntp --=_alternative 0053AD94C125818C_= Content-Type: text/html; charset="US-ASCII"


"ntp" <ntp-bounces@ietf.org> schrieb am 30.08.2017 00:44:53:

> Von: Daniel Franke <dfoxfranke@gmail.com>
> An: kristof.teichel@ptb.de
> Kopie: ntp@ietf.org, Harlan Stenn <stenn@nwtime.org>
> Datum: 30.08.2017 00:45
> Betreff: Re: [Ntp] WGLC for draft-ietf-ntp-using-nts-for-ntp
> Gesendet von: "ntp" <ntp-bounces@ietf.org>
>
> On 8/29/17, kristof.teichel@ptb.de <kristof.teichel@ptb.de> wrote:
> > Historically, encapsulation is an overall concept that has been argued
> > against a lot in the course of NTS (as far as I've witnessed it).
> > Therefore, I think that a paragraph of discussion on the presumed
> > negligibiliy of the precision loss with DTLS-encapsulation is warranted.
> >
> > Especially in the case of transmit timestamps (where every cryptographic
> > operation takes place between the reading of the timestamp and the actual
> > time of transmission that the timestamp was supposed to measure), perhaps it
> > should at least be mentioned why this encapsulation is not significantly
> > more expensive than e.g. adding a MAC/AEAD value.
> >
> > One thing I really don't know, however, is where such a piece of text should
> > be placed in order to not distort the core specification text (I don't think
> > anyone wants to or should have to read a passage about the design decision
> > process in the middle of the instructions on how to do the
> > DTLS-encapsulation).
>
> I don't think performance analysis needs to go in the RFC at all. I
> can't call to mind any other RFC that has included such a thing, and
> I'm certain I've never seen it out of the TLS WG.

I agree with Daniel. A standards document is not the appropriate place for a performance analysis.


>
> But for any skeptics, here's the math.
>
> Let's start by looking at legacy MD5(K||M). Computing MD5 over 64
> bytes ( 16-byte key, 48-byte NTP header) takes about 900 cycles on my
> Broadwell system.
>
> Now let's look at the AES-CMAC draft and at DTLS encapsulation with AES-GCM.
>
> For these, a couple optimizations are possible to minimize the time
> that elapses between when you call clock_gettime() (or whatever your
> OS's equivalent) for the transmit timestamp, and when the
> authenticated (and possibly encrypted) packet is ready to send.
>
> The first optimization is straightforward. AES-CMAC supports
> incremental, one-pass computation, as do all (D)TLS ciphers. That
> means it's possible to precompute the crypto for every block preceding
> the one that holds the transmit timestamp, before the transmit
> timestamp is obtained. (This is possible with MD5 too, but it doesn't
> buy you anything because MD5's internal block size is larger than the
> data being hashed.)
>
> The second optimization only works in DTLS, and it's *conceptually*
> straightforward but probably a pain to implement just on account of
> API limitations in TLS libraries. With AES-GCM, as well as with any
> stream cipher, you can precompute encryption of the transmit timestamp
> even before you have it, because all the expensive parts of encryption
> don't depend on the plaintext -- you use your cipher algorithm to
> compute a pseudorandom stream of bits and then the combination with
> the plaintext is a simple xor (a single CPU cycle, which I'll
> neglect).
>
> An NTP header is 48 octets, which conveniently works out to exactly
> three AES blocks. In this situation, AES-CMAC basically acts like
> AES-CBC with one extra XOR thrown in and outputting just the final
> block. On my Broadwell system, AES-CBC takes about 75 cycles per
> block. On Skylake it's somewhat faster. So, to get from capturing the
> transmit timestamp to a ready message, you need about 75 CPU cycles if
> you optimize or about 225 if you don't. Both of these figures assume
> you're at least doing AES key setup before you get the transmit
> timestamp. I'm not sure exactly how much key setup adds, probably
> another few hundred cycles, but I'm not going to bother measuring it
> because not doing that in advance is just dumb.
>
> Now let's look at DTLS with AES-GCM. A DTLS record consists of a
> 12-octet header, treated as associated data, followed by ciphertext
> which is internally structured as the
> actual encrypted payload followed by a 16-octet authenticator.
>
> AES-GCM is rather complex, but at high level you can think of it as a
> combination of AES-CTR with a non-cryptographic hash called GHASH. Its
> cost comes down to the cost of computing AES-CTR over the plaintext,
> plus the cost of computing GHASH over the associated data and the
> output of AES-CTR, plus the cost of one additional AES operation at
> the end.
>
> AES-CTR allows you use CPU pipelining to encrypt a few blocks in
> parallel on a single core. Encrypting one block costs about the same
> as one block with AES-CBC (about 75 cycles), but you can do three
> blocks for about the same cost as one. GHASH adds about 5 cycles per
> block. Regardless, computing the authenticator adds another 75 cycles
> or so at the end.
>
> So with no optimization, we're looking at 75 cycles for AES-CTR, 20
> cycles for GHASH, 75 cycles for the authenticator.
>
> Basic optimization saves 15 cycles on GHASH, but because of
> parallelism doesn't buy anything else.
>
> Clever optimization cuts out everything except the final authenticator
> computation.
>
> So here's how it roughly works out:
>
> MD5: 900 cycles
> AES-CMAC, no optimization: 225 cycles
> AES-CMAC, basic optimization: 75 cycles
> DTLS, no optimization: 170 cycles
> DTLS, basic optimization: 155 cycles
> DTLS, clever optimization: 75 cycles
>
> 900 cycles for MD5 at 3.5GHz is 257 nanoseconds. In the worst case,
> the resulting timing asymmetry throws off your accuracy by half that,
> or 128 nanoseconds. That is several orders magnitude smaller than
> anything NTP can possibly promise you. If you want to measure the
> impact of adding the MD5 step in real world conditions, you will have
> an extremely difficult time distinguishing it from zero.
>
> AES-CMAC and DTLS each cut this performance impact by an additional
> order of magnitude. If you try measuring the impact of either one and
> tell me that you were able to do so, I will tell you that there is
> either something wrong with your experiment or something wrong with
> your crypto implementation.
>
> DTLS encapsulation is *just fine*.
>
> _______________________________________________
> ntp mailing list
> ntp@ietf.org
> https://www.ietf.org/mailman/listinfo/ntp
 --=_alternative 0053AD94C125818C_=-- ---------z16761_boundary_sign Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIIp0gIBATEPMA0GCWCGSAFlAwQCAQUAMAsGCSqGSIb3DQEHAaCCJsYw ggOfMIICh6ADAgECAgEmMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNE ZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYD VQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw05OTA3MDkxMjExMDBaFw0xOTA3MDky MzU5MDBaMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYD VQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJv b3QgQ0EgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKsLozXgiykUsRSFrzwQ5Dlv NV1Krt3qYY2VSfRvZKMaYGakqUAihNnUpeV4kw5oAa25TVw6ztO4qEJA38+juoJZapIbrBya2ggr JSf5aSNH8eDrLHqb9RMC0H40fMKePABZq/XaDPUyPCusUNrWw96DlMqoDJkyDghIVltq+9rhWFgB SV9yQTwVBgGOXa2quJO0zZ7rp+hqLVI02zrvXHVR2tvzMfnucZgyxFQVRAz5m1Xtrd8YCKCjhopJ 7lMFjxlM1d5YeZvSahxCq8XVp89oD5bk4WGYdmHIkXzWPgDikVCH4Z0K5q2X0h3GOn3LvNoDNNWO WwH1age3FrZuSn8CAwEAAaNCMEAwHQYDVR0OBBYEFDHDeRu69VPXF+CJei0XbAqzK50zMA8GA1Ud EwQIMAYBAf8CAQUwDgYDVR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBBQUAA4IBAQCUZFmtOWTnKesT /lrDixNXyAQk8HR3wGDjZ/vpiaaDv5aCfG7Uwz3vnoBuuym0mHqxO1TrORdHfhqOC/wfMVkxBLLO F/Msx2I2VeIi2IlVtJhIqmT61hw22ER4WlojOleX9XowT66fakxLK46gA+M+4KnU0nvSs6jicjyt nv+AWeSbRbT2O7DNORmYMuXqIWGQ5DEhjjSx9y81SoUQ2ueKNyG+WWPg8oWIMVPUVBSFcHn0LgZ3 J3UvH7iK+f7Futg25IPs52W3v2Na80avgZQ31EGM1iPWHs/1aBtEY6Jauqc1WaHlcAWbDiNXmZQK bbo5YyiGkvMYhNj70c8FVmRXMIIDnzCCAoegAwIBAgIBJjANBgkqhkiG9w0BAQUFADBxMQswCQYD VQQGEwJERTEcMBoGA1UEChMTRGV1dHNjaGUgVGVsZWtvbSBBRzEfMB0GA1UECxMWVC1UZWxlU2Vj IFRydXN0IENlbnRlcjEjMCEGA1UEAxMaRGV1dHNjaGUgVGVsZWtvbSBSb290IENBIDIwHhcNOTkw NzA5MTIxMTAwWhcNMTkwNzA5MjM1OTAwWjBxMQswCQYDVQQGEwJERTEcMBoGA1UEChMTRGV1dHNj aGUgVGVsZWtvbSBBRzEfMB0GA1UECxMWVC1UZWxlU2VjIFRydXN0IENlbnRlcjEjMCEGA1UEAxMa RGV1dHNjaGUgVGVsZWtvbSBSb290IENBIDIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCrC6M14IspFLEUha88EOQ5bzVdSq7d6mGNlUn0b2SjGmBmpKlAIoTZ1KXleJMOaAGtuU1cOs7T uKhCQN/Po7qCWWqSG6wcmtoIKyUn+WkjR/Hg6yx6m/UTAtB+NHzCnjwAWav12gz1MjwrrFDa1sPe g5TKqAyZMg4ISFZbavva4VhYAUlfckE8FQYBjl2tqriTtM2e66foai1SNNs671x1Udrb8zH57nGY MsRUFUQM+ZtV7a3fGAigo4aKSe5TBY8ZTNXeWHmb0mocQqvF1afPaA+W5OFhmHZhyJF81j4A4pFQ h+GdCuatl9Idxjp9y7zaAzTVjlsB9WoHtxa2bkp/AgMBAAGjQjBAMB0GA1UdDgQWBBQxw3kbuvVT 1xfgiXotF2wKsyudMzAPBgNVHRMECDAGAQH/AgEFMA4GA1UdDwEB/wQEAwIBBjANBgkqhkiG9w0B AQUFAAOCAQEAlGRZrTlk5ynrE/5aw4sTV8gEJPB0d8Bg42f76Ymmg7+Wgnxu1MM9756AbrsptJh6 sTtU6zkXR34ajgv8HzFZMQSyzhfzLMdiNlXiItiJVbSYSKpk+tYcNthEeFpaIzpXl/V6ME+un2pM SyuOoAPjPuCp1NJ70rOo4nI8rZ7/gFnkm0W09juwzTkZmDLl6iFhkOQxIY40sfcvNUqFENrnijch vllj4PKFiDFT1FQUhXB59C4Gdyd1Lx+4ivn+xbrYNuSD7Odlt79jWvNGr4GUN9RBjNYj1h7P9Wgb RGOiWrqnNVmh5XAFmw4jV5mUCm26OWMohpLzGITY+9HPBVZkVzCCBNUwggO9oAMCAQICCFBOxvU9 EbRkMA0GCSqGSIb3DQEBCwUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNEZXV0c2NoZSBUZWxl a29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYDVQQDExpEZXV0c2No ZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0xNDA3MjIxMjA4MjZaFw0xOTA3MDkyMzU5MDBaMFoxCzAJ BgNVBAYTAkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQD ExtERk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U1wBblSJ01CDrNI/W7MAxBAuZgeKmFNJSoCgjhIt0 iQReW+DieMF4yxbLKDU5ey2QRdDtoAB6fL9KDhsAw4bpXCsxEXsM84IkQ4wcOItqaACa7txPeKvS xhObdq3u3ibo7wGvdA/BCaL2a869080UME/15eOkyGKbghoDJzANAmVgTe3RCSMqljVYJ9N2xnG2 kB3E7f81hn1vM7PbD8URwoqDoZRdQWvY0hD1TP3KUazZve+Sg7va64sWVlZDz+HVEz2mHycwzUlU 28kTNJpxdcVs6qcLmPkhnSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjggGGMIIBgjAOBgNVHQ8BAf8E BAMCAQYwHQYDVR0OBBYEFEm3xs/oPR9/6kR7Eyn38QpwPt5kMB8GA1UdIwQYMBaAFDHDeRu69VPX F+CJei0XbAqzK50zMBIGA1UdEwEB/wQIMAYBAf8CAQIwYgYDVR0gBFswWTARBg8rBgEEAYGtIYIs AQEEAgIwEQYPKwYBBAGBrSGCLAEBBAMAMBEGDysGAQQBga0hgiwBAQQDATAPBg0rBgEEAYGtIYIs AQEEMA0GCysGAQQBga0hgiweMD4GA1UdHwQ3MDUwM6AxoC+GLWh0dHA6Ly9wa2kwMzM2LnRlbGVz ZWMuZGUvcmwvRFRfUk9PVF9DQV8yLmNybDB4BggrBgEFBQcBAQRsMGowLAYIKwYBBQUHMAGGIGh0 dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMDoGCCsGAQUFBzAChi5odHRwOi8vcGtpMDMz Ni50ZWxlc2VjLmRlL2NydC9EVF9ST09UX0NBXzIuY2VyMA0GCSqGSIb3DQEBCwUAA4IBAQBjICj9 nCGGcr45Rlk5MiW8qQGbDczKfUGchm0KbiyzE1l1sTOSG2EnFv/DstU1gvuEKgFJvWa7Zi+ywgZd bj9u4wFaW8pDY1yVtuExpx/VB19N5mWCTjL5w3x6S81NXHTuIfJ1AuxSPtLJatOQI25JZzW+f01W pOzML8+3oZeocj7JvEDWWqQIPda8gsO3tzKOsSyOam23NQIZz/U5RFhjpyQAELC7/E6vbi84u6VX ST/YblBvLJeW3B1GmmWJz67M8uXZn1OzPqEvkqnYC8aEHwTG6x7on321e6UC8STFJGMRNMxakyAq eYg6JUKQqWU7fIbTEhUjKfws2sw5W1QXMIIE1TCCA72gAwIBAgIIUE7G9T0RtGQwDQYJKoZIhvcN AQELBQAwcTELMAkGA1UEBhMCREUxHDAaBgNVBAoTE0RldXRzY2hlIFRlbGVrb20gQUcxHzAdBgNV BAsTFlQtVGVsZVNlYyBUcnVzdCBDZW50ZXIxIzAhBgNVBAMTGkRldXRzY2hlIFRlbGVrb20gUm9v dCBDQSAyMB4XDTE0MDcyMjEyMDgyNloXDTE5MDcwOTIzNTkwMFowWjELMAkGA1UEBhMCREUxEzAR BgNVBAoTCkRGTi1WZXJlaW4xEDAOBgNVBAsTB0RGTi1QS0kxJDAiBgNVBAMTG0RGTi1WZXJlaW4g UENBIEdsb2JhbCAtIEcwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOmbw2eF+Q2u 9Y1Uw5ZQNT1i6W5M7ZTXAFuVInTUIOs0j9bswDEEC5mB4qYU0lKgKCOEi3SJBF5b4OJ4wXjLFsso NTl7LZBF0O2gAHp8v0oOGwDDhulcKzERewzzgiRDjBw4i2poAJru3E94q9LGE5t2re7eJujvAa90 D8EJovZrzr3TzRQwT/Xl46TIYpuCGgMnMA0CZWBN7dEJIyqWNVgn03bGcbaQHcTt/zWGfW8zs9sP xRHCioOhlF1Ba9jSEPVM/cpRrNm975KDu9rrixZWVkPP4dUTPaYfJzDNSVTbyRM0mnF1xWzqpwuY +SGdJ68+ozk5SGqMrcmZ+8MS8r0CAwEAAaOCAYYwggGCMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4E FgQUSbfGz+g9H3/qRHsTKffxCnA+3mQwHwYDVR0jBBgwFoAUMcN5G7r1U9cX4Il6LRdsCrMrnTMw EgYDVR0TAQH/BAgwBgEB/wIBAjBiBgNVHSAEWzBZMBEGDysGAQQBga0hgiwBAQQCAjARBg8rBgEE AYGtIYIsAQEEAwAwEQYPKwYBBAGBrSGCLAEBBAMBMA8GDSsGAQQBga0hgiwBAQQwDQYLKwYBBAGB rSGCLB4wPgYDVR0fBDcwNTAzoDGgL4YtaHR0cDovL3BraTAzMzYudGVsZXNlYy5kZS9ybC9EVF9S T09UX0NBXzIuY3JsMHgGCCsGAQUFBwEBBGwwajAsBggrBgEFBQcwAYYgaHR0cDovL29jc3AwMzM2 LnRlbGVzZWMuZGUvb2NzcHIwOgYIKwYBBQUHMAKGLmh0dHA6Ly9wa2kwMzM2LnRlbGVzZWMuZGUv Y3J0L0RUX1JPT1RfQ0FfMi5jZXIwDQYJKoZIhvcNAQELBQADggEBAGMgKP2cIYZyvjlGWTkyJbyp AZsNzMp9QZyGbQpuLLMTWXWxM5IbYScW/8Oy1TWC+4QqAUm9ZrtmL7LCBl1uP27jAVpbykNjXJW2 4TGnH9UHX03mZYJOMvnDfHpLzU1cdO4h8nUC7FI+0slq05AjbklnNb5/TVak7Mwvz7ehl6hyPsm8 QNZapAg91ryCw7e3Mo6xLI5qbbc1AhnP9TlEWGOnJAAQsLv8Tq9uLzi7pVdJP9huUG8sl5bcHUaa ZYnPrszy5dmfU7M+oS+SqdgLxoQfBMbrHuiffbV7pQLxJMUkYxE0zFqTICp5iDolQpCpZTt8htMS FSMp/CzazDlbVBcwggU9MIIEJaADAgECAgcXr/adVkv+MA0GCSqGSIb3DQEBCwUAMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtE Rk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwHhcNMTQwNjA1MTQwNTAyWhcNMTkwNzA5MjM1OTAw WjBpMQswCQYDVQQGEwJERTEuMCwGA1UEChMlUGh5c2lrYWxpc2NoLVRlY2huaXNjaGUgQnVuZGVz YW5zdGFsdDEPMA0GA1UEAxMGUFRCIENBMRkwFwYJKoZIhvcNAQkBFgpwa2lAcHRiLmRlMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvArCgzkqw2LMAYuU38VJTgyGBC+Pp+uvw52LmtI6 MEMiFr0xY6SEzYcDG3z5NSohZisdnL7bu8Ee7MFD3TZX1jVBie//UNAJqXbHnUzE8hbJYCR5ydb9 WqIzoT5PzG07qJWblbidcrZVcCQEef9V1CaRyfXuqiSTOgibqODLP98N7jMIImz2ipUgMdoGyOgS h/qds5SM6CUgwMeuJ42QpYNot9ri1IKAweyhIIa3TANsu56scy+Fc2+XWOfsuImeeLcaiu6HJPk6 X55QT+kWaAoQf6qJyJXv8b/n6l1nmTIU2AY2B5EnO/rIT+DW+MJy77/HO+7rtwaznuntXMgytwID AQABo4IB9zCCAfMwEgYDVR0TAQH/BAgwBgEB/wIBATAOBgNVHQ8BAf8EBAMCAQYwEQYDVR0gBAow CDAGBgRVHSAAMB0GA1UdDgQWBBTEgNBuKBVoMVrscF94juEwQzjqNDAfBgNVHSMEGDAWgBRJt8bP 6D0ff+pEexMp9/EKcD7eZDAVBgNVHREEDjAMgQpwa2lAcHRiLmRlMIGIBgNVHR8EgYAwfjA9oDug OYY3aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY3JsL2NhY3JsLmNy bDA9oDugOYY3aHR0cDovL2NkcDIucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY3JsL2Nh Y3JsLmNybDCB1wYIKwYBBQUHAQEEgcowgccwMwYIKwYBBQUHMAGGJ2h0dHA6Ly9vY3NwLnBjYS5k Zm4uZGUvT0NTUC1TZXJ2ZXIvT0NTUDBHBggrBgEFBQcwAoY7aHR0cDovL2NkcDEucGNhLmRmbi5k ZS9nbG9iYWwtcm9vdC1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwRwYIKwYBBQUHMAKGO2h0dHA6 Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MA0G CSqGSIb3DQEBCwUAA4IBAQCo3hebMpEocLPJTOlDMAmSzpxK3SA1ftaQqodbMncOi9WkeICQlmIv rQxGCq8Be/6hKtIrbFOhRtSzQi870glJRj7dhZaHC+WOgT5tP5Nkgwpgl4k4pQDXPPrwmaI6cSYD a/LpprQzBNjEQMdQqkeanpD0WU9U1pOPFIMfIrxh2cy8mBpIAMuZqMHbMyPNDZk/YN4r3b2DcBrQ wL/tHerp6Vc7n9WqO+3cm7Fa4AxL9q2KeItyYe0Cws2KZNz4IuiMjQAclNL0PhTEqIzkD/EiK6Ag 1qcH7o3ktpmakvL2RzSZA71irCfONRgh/+ixfuMu6YA5uzyA8SYfwyFQcABdMIIFPTCCBCWgAwIB AgIHF6/2nVZL/jANBgkqhkiG9w0BAQsFADBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZOLVZl cmVpbjEQMA4GA1UECxMHREZOLVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xvYmFsIC0g RzAxMB4XDTE0MDYwNTE0MDUwMloXDTE5MDcwOTIzNTkwMFowaTELMAkGA1UEBhMCREUxLjAsBgNV BAoTJVBoeXNpa2FsaXNjaC1UZWNobmlzY2hlIEJ1bmRlc2Fuc3RhbHQxDzANBgNVBAMTBlBUQiBD QTEZMBcGCSqGSIb3DQEJARYKcGtpQHB0Yi5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALwKwoM5KsNizAGLlN/FSU4MhgQvj6frr8Odi5rSOjBDIha9MWOkhM2HAxt8+TUqIWYrHZy+ 27vBHuzBQ902V9Y1QYnv/1DQCal2x51MxPIWyWAkecnW/VqiM6E+T8xtO6iVm5W4nXK2VXAkBHn/ VdQmkcn17qokkzoIm6jgyz/fDe4zCCJs9oqVIDHaBsjoEof6nbOUjOglIMDHrieNkKWDaLfa4tSC gMHsoSCGt0wDbLuerHMvhXNvl1jn7LiJnni3GoruhyT5Ol+eUE/pFmgKEH+qiciV7/G/5+pdZ5ky FNgGNgeRJzv6yE/g1vjCcu+/xzvu67cGs57p7VzIMrcCAwEAAaOCAfcwggHzMBIGA1UdEwEB/wQI MAYBAf8CAQEwDgYDVR0PAQH/BAQDAgEGMBEGA1UdIAQKMAgwBgYEVR0gADAdBgNVHQ4EFgQUxIDQ bigVaDFa7HBfeI7hMEM46jQwHwYDVR0jBBgwFoAUSbfGz+g9H3/qRHsTKffxCnA+3mQwFQYDVR0R BA4wDIEKcGtpQHB0Yi5kZTCBiAYDVR0fBIGAMH4wPaA7oDmGN2h0dHA6Ly9jZHAxLnBjYS5kZm4u ZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NybC9jYWNybC5jcmwwPaA7oDmGN2h0dHA6Ly9jZHAyLnBj YS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NybC9jYWNybC5jcmwwgdcGCCsGAQUFBwEBBIHK MIHHMDMGCCsGAQUFBzABhidodHRwOi8vb2NzcC5wY2EuZGZuLmRlL09DU1AtU2VydmVyL09DU1Aw RwYIKwYBBQUHMAKGO2h0dHA6Ly9jZHAxLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2Nh Y2VydC9jYWNlcnQuY3J0MEcGCCsGAQUFBzAChjtodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2dsb2Jh bC1yb290LWNhL3B1Yi9jYWNlcnQvY2FjZXJ0LmNydDANBgkqhkiG9w0BAQsFAAOCAQEAqN4XmzKR KHCzyUzpQzAJks6cSt0gNX7WkKqHWzJ3DovVpHiAkJZiL60MRgqvAXv+oSrSK2xToUbUs0IvO9IJ SUY+3YWWhwvljoE+bT+TZIMKYJeJOKUA1zz68JmiOnEmA2vy6aa0MwTYxEDHUKpHmp6Q9FlPVNaT jxSDHyK8YdnMvJgaSADLmajB2zMjzQ2ZP2DeK929g3Aa0MC/7R3q6elXO5/Vqjvt3JuxWuAMS/at iniLcmHtAsLNimTc+CLojI0AHJTS9D4UxKiM5A/xIiugINanB+6N5LaZmpLy9kc0mQO9YqwnzjUY If/osX7jLumAObs8gPEmH8MhUHAAXTCCBaIwggSKoAMCAQICDBxmO6qdufc5yhZ6iDANBgkqhkiG 9w0BAQsFADBpMQswCQYDVQQGEwJERTEuMCwGA1UEChMlUGh5c2lrYWxpc2NoLVRlY2huaXNjaGUg QnVuZGVzYW5zdGFsdDEPMA0GA1UEAxMGUFRCIENBMRkwFwYJKoZIhvcNAQkBFgpwa2lAcHRiLmRl MB4XDTE2MTIwNjEzMzMxNFoXDTE5MDcwOTIzNTkwMFowaDELMAkGA1UEBhMCREUxLjAsBgNVBAoM JVBoeXNpa2FsaXNjaC1UZWNobmlzY2hlIEJ1bmRlc2Fuc3RhbHQxDTALBgNVBAsMBFEuNDIxGjAY BgNVBAMMEURyLiBEaWV0ZXIgU2lib2xkMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA +AOQrmrEQ2k8s9su/TVvmdF46YbL2MuF6OvnrjjKaJIkBvchop87cCwv80aZEbmU3as54egQEMGn NFkp1fF4bics4TJdEpND116l+jbi5DCtA3hHP/spV1aQZBDc/BDkm1Nl5WYKh/DxN6sUhZxorbb4 Y0nmSxnK2ctIwuF4Qdibsw7GE2YLvWF4tlzSCGbDjSy2agSn1wYHMsC+tAcFflcMXF2sDMZHkYuq 5IHwng8GBQFhsldYl1fk2sB2/hVRLYU205qaj13H94WjfDLuB22sT17XPJ2U/9tuFN/sxAPR0/N4 y4/IgMnOaP30VU0FMmULd7qJg0WST5D5kwgMhwIDAQABo4ICSTCCAkUwQAYDVR0gBDkwNzARBg8r BgEEAYGtIYIsAQEEAwUwEQYPKwYBBAGBrSGCLAIBBAMBMA8GDSsGAQQBga0hgiwBAQQwCQYDVR0T BAIwADAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1Ud DgQWBBQHn42zKDpvJi1bsJ4OVk2A9liUFjAfBgNVHSMEGDAWgBTEgNBuKBVoMVrscF94juEwQzjq NDBEBgNVHREEPTA7gRRkaWV0ZXIuc2lib2xkQHB0Yi5kZaAjBgorBgEEAYI3FAIDoBUME3NpYm9s ZDAxQHBhZC5wdGIuZGUwdwYDVR0fBHAwbjA1oDOgMYYvaHR0cDovL2NkcDEucGNhLmRmbi5kZS9w dGItY2EvcHViL2NybC9jYWNybC5jcmwwNaAzoDGGL2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvcHRi LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIHHBggrBgEFBQcBAQSBujCBtzAzBggrBgEFBQcwAYYnaHR0 cDovL29jc3AucGNhLmRmbi5kZS9PQ1NQLVNlcnZlci9PQ1NQMD8GCCsGAQUFBzAChjNodHRwOi8v Y2RwMS5wY2EuZGZuLmRlL3B0Yi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwPwYIKwYBBQUHMAKG M2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvcHRiLWNhL3B1Yi9jYWNlcnQvY2FjZXJ0LmNydDANBgkq hkiG9w0BAQsFAAOCAQEADaSfgrrQZx9eiQrCK7kgJMpLstro5OgIcWSpW4i4AQ1wEwyDUrdB1XWK GjA8/KwExSBP9a+dcdW+ACjX7TyURQPLqRTOkoPc9dafRx327mV4K8PE8z7fg5l2ittYNs0nXlOB QevRbYYP4XUOMYohFWfHpDwEg3ExmoArb2HaQCzKhq/2VcIIXTwaN6AVr2NVKEuH3qwpgOUSlJJ1 5ORb6TD4p1G2W6XT3jk3tOa8nRaOkI5hqpPvLfbPEibn+Bfqm6GWqpXfQ6NLAvWYcI8ltSKgdnCw Rmqdh1Ba/KWGdm41PDtQIx58vgbZGfN5GKJrp+OwS5D+/e/r296qoKUBRDCCBaIwggSKoAMCAQIC DBxmO6qdufc5yhZ6iDANBgkqhkiG9w0BAQsFADBpMQswCQYDVQQGEwJERTEuMCwGA1UEChMlUGh5 c2lrYWxpc2NoLVRlY2huaXNjaGUgQnVuZGVzYW5zdGFsdDEPMA0GA1UEAxMGUFRCIENBMRkwFwYJ KoZIhvcNAQkBFgpwa2lAcHRiLmRlMB4XDTE2MTIwNjEzMzMxNFoXDTE5MDcwOTIzNTkwMFowaDEL MAkGA1UEBhMCREUxLjAsBgNVBAoMJVBoeXNpa2FsaXNjaC1UZWNobmlzY2hlIEJ1bmRlc2Fuc3Rh bHQxDTALBgNVBAsMBFEuNDIxGjAYBgNVBAMMEURyLiBEaWV0ZXIgU2lib2xkMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA+AOQrmrEQ2k8s9su/TVvmdF46YbL2MuF6OvnrjjKaJIkBvch op87cCwv80aZEbmU3as54egQEMGnNFkp1fF4bics4TJdEpND116l+jbi5DCtA3hHP/spV1aQZBDc /BDkm1Nl5WYKh/DxN6sUhZxorbb4Y0nmSxnK2ctIwuF4Qdibsw7GE2YLvWF4tlzSCGbDjSy2agSn 1wYHMsC+tAcFflcMXF2sDMZHkYuq5IHwng8GBQFhsldYl1fk2sB2/hVRLYU205qaj13H94WjfDLu B22sT17XPJ2U/9tuFN/sxAPR0/N4y4/IgMnOaP30VU0FMmULd7qJg0WST5D5kwgMhwIDAQABo4IC STCCAkUwQAYDVR0gBDkwNzARBg8rBgEEAYGtIYIsAQEEAwUwEQYPKwYBBAGBrSGCLAIBBAMBMA8G DSsGAQQBga0hgiwBAQQwCQYDVR0TBAIwADAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYB BQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQHn42zKDpvJi1bsJ4OVk2A9liUFjAfBgNVHSMEGDAW gBTEgNBuKBVoMVrscF94juEwQzjqNDBEBgNVHREEPTA7gRRkaWV0ZXIuc2lib2xkQHB0Yi5kZaAj BgorBgEEAYI3FAIDoBUME3NpYm9sZDAxQHBhZC5wdGIuZGUwdwYDVR0fBHAwbjA1oDOgMYYvaHR0 cDovL2NkcDEucGNhLmRmbi5kZS9wdGItY2EvcHViL2NybC9jYWNybC5jcmwwNaAzoDGGL2h0dHA6 Ly9jZHAyLnBjYS5kZm4uZGUvcHRiLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIHHBggrBgEFBQcBAQSB ujCBtzAzBggrBgEFBQcwAYYnaHR0cDovL29jc3AucGNhLmRmbi5kZS9PQ1NQLVNlcnZlci9PQ1NQ MD8GCCsGAQUFBzAChjNodHRwOi8vY2RwMS5wY2EuZGZuLmRlL3B0Yi1jYS9wdWIvY2FjZXJ0L2Nh Y2VydC5jcnQwPwYIKwYBBQUHMAKGM2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvcHRiLWNhL3B1Yi9j YWNlcnQvY2FjZXJ0LmNydDANBgkqhkiG9w0BAQsFAAOCAQEADaSfgrrQZx9eiQrCK7kgJMpLstro 5OgIcWSpW4i4AQ1wEwyDUrdB1XWKGjA8/KwExSBP9a+dcdW+ACjX7TyURQPLqRTOkoPc9dafRx32 7mV4K8PE8z7fg5l2ittYNs0nXlOBQevRbYYP4XUOMYohFWfHpDwEg3ExmoArb2HaQCzKhq/2VcII XTwaN6AVr2NVKEuH3qwpgOUSlJJ15ORb6TD4p1G2W6XT3jk3tOa8nRaOkI5hqpPvLfbPEibn+Bfq m6GWqpXfQ6NLAvWYcI8ltSKgdnCwRmqdh1Ba/KWGdm41PDtQIx58vgbZGfN5GKJrp+OwS5D+/e/r 296qoKUBRDGCAuMwggLfAgEBMHkwaTELMAkGA1UEBhMCREUxLjAsBgNVBAoTJVBoeXNpa2FsaXNj aC1UZWNobmlzY2hlIEJ1bmRlc2Fuc3RhbHQxDzANBgNVBAMTBlBUQiBDQTEZMBcGCSqGSIb3DQEJ ARYKcGtpQHB0Yi5kZQIMHGY7qp259znKFnqIMA0GCWCGSAFlAwQCAQUAoIIBOzAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzA4MzAxNTEzNTlaMC8GCSqGSIb3DQEJ BDEiBCAXBDYLhwap0dDIeKJnkjp/MjZIf/BBxqsJPUOX4BVIsjBDBgkqhkiG9w0BCQ8xNjA0MAcG BSsOAwIdMA4GCCqGSIb3DQMCAgIAgDAKBggqhkiG9w0DBzANBggqhkiG9w0DAgIBKDCBigYLKoZI hvcNAQkQAgsxe6B5MGkxCzAJBgNVBAYTAkRFMS4wLAYDVQQKEyVQaHlzaWthbGlzY2gtVGVjaG5p c2NoZSBCdW5kZXNhbnN0YWx0MQ8wDQYDVQQDEwZQVEIgQ0ExGTAXBgkqhkiG9w0BCQEWCnBraUBw dGIuZGUCDBxmO6qdufc5yhZ6iDANBgkqhkiG9w0BAQEFAASCAQA5KU9Eh8CcY//LBHunSTRg8Wgf 9iImWkkUu0OFmssn3HjbagoYu2cJelBv3vzMv7ZFc4iXkq/TRZZsV4weQhPxZJ8iwemtnNeIgL7O HhvZfSF/W08WAnDWfIUHZQ1h3KEjKiYaVysC/wjLTfmyYHGJhgmiwo8HchRHaZ5sxi8gAtqDfzCA YyDR5I6NQvtTomQRGM7llsFsxTqhtVv8f/hq2jvm1q/+ZHYzZQZC6iXdoV9/QJSPr0YsZ8B6fPgg knbtC2UQQE+AWoJ7FoOehxCliJ1aQv7QTUJlP0yt2k7LgVMBCM7xF46Rie2ac86+iVJiUMBTwA4I G5vcqKPXyf0cAAAAAA== ---------z16761_boundary_sign-- From ntp-bounces@ietf.org Wed Aug 30 08:14:13 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F5A0132CFA; Wed, 30 Aug 2017 08:14:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1504106053; bh=k3z1yL+ZCDwHtppPSuhp2U5UY8y7+g/bo1GnwpKw5zM=; h=In-Reply-To:References:To:From:Date:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc; b=JiIC9czpQRyVaHVKm3BGf505ox+n1BlgsPsC8UEyfJlEd8MsCRbCAJrRnDOpFG0KT N6fl2OVw53bFh5aqplz88KX1keYHEaohfyNVk4oRhvTzY9G9pUhtHb1bcfcXLZnBBl rFGk631gLPgCEVTbSaET5FQRbJcehCgWw5uO1Br8= 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 1B95013219E; Wed, 30 Aug 2017 08:14:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 QS5o5Nt_A88z; Wed, 30 Aug 2017 08:14:06 -0700 (PDT) Received: from mx1.bs.ptb.de (mx1.bs.ptb.de [IPv6:2001:638:610:bd01::120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0B90132CEA; Wed, 30 Aug 2017 08:14:04 -0700 (PDT) Received: from smtp-hub.bs.ptb.de (smtpint01.bs.ptb.de [141.25.87.32]) by mx1.bs.ptb.de with ESMTP id v7UFE2iS009808-v7UFE2iU009808 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 30 Aug 2017 17:14:02 +0200 Received: from rose.bs.ptb.de (rose.bs.ptb.de [141.25.85.201]) by smtp-hub.bs.ptb.de (Postfix) with ESMTPS id 3566553469F; Wed, 30 Aug 2017 17:14:01 +0200 (CEST) In-Reply-To: References: <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> <47b5b4e3-41c9-6779-4a96-b11650483499@nwtime.org> To: Daniel Franke MIME-Version: 1.0 Message-ID: From: dieter.sibold@ptb.de Date: Wed, 30 Aug 2017 17:13:59 +0200 Archived-At: Subject: [Ntp] Antwort: Re: WGLC for draft-ietf-ntp-using-nts-for-ntp X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: ntp@ietf.org, kristof.teichel@ptb.de, Harlan Stenn , ntp Content-Type: multipart/mixed; boundary="===============3293666846650183441==" Errors-To: ntp-bounces@ietf.org Sender: "ntp" This is an S/MIME signed message. --===============3293666846650183441== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha-256; boundary=-------z16761_boundary_sign This is an S/MIME signed message. ---------z16761_boundary_sign Content-Type: multipart/alternative; boundary="=_alternative 0053AD94C125818C_=" Dies ist eine mehrteilige Nachricht im MIME-Format. --=_alternative 0053AD94C125818C_= Content-Type: text/plain; charset="US-ASCII" "ntp" schrieb am 30.08.2017 00:44:53: > Von: Daniel Franke > An: kristof.teichel@ptb.de > Kopie: ntp@ietf.org, Harlan Stenn > Datum: 30.08.2017 00:45 > Betreff: Re: [Ntp] WGLC for draft-ietf-ntp-using-nts-for-ntp > Gesendet von: "ntp" > > On 8/29/17, kristof.teichel@ptb.de wrote: > > Historically, encapsulation is an overall concept that has been argued > > against a lot in the course of NTS (as far as I've witnessed it). > > Therefore, I think that a paragraph of discussion on the presumed > > negligibiliy of the precision loss with DTLS-encapsulation is warranted. > > > > Especially in the case of transmit timestamps (where every cryptographic > > operation takes place between the reading of the timestamp and the actual > > time of transmission that the timestamp was supposed to measure), perhaps it > > should at least be mentioned why this encapsulation is not significantly > > more expensive than e.g. adding a MAC/AEAD value. > > > > One thing I really don't know, however, is where such a piece of text should > > be placed in order to not distort the core specification text (I don't think > > anyone wants to or should have to read a passage about the design decision > > process in the middle of the instructions on how to do the > > DTLS-encapsulation). > > I don't think performance analysis needs to go in the RFC at all. I > can't call to mind any other RFC that has included such a thing, and > I'm certain I've never seen it out of the TLS WG. I agree with Daniel. A standards document is not the appropriate place for a performance analysis. > > But for any skeptics, here's the math. > > Let's start by looking at legacy MD5(K||M). Computing MD5 over 64 > bytes ( 16-byte key, 48-byte NTP header) takes about 900 cycles on my > Broadwell system. > > Now let's look at the AES-CMAC draft and at DTLS encapsulation with AES-GCM. > > For these, a couple optimizations are possible to minimize the time > that elapses between when you call clock_gettime() (or whatever your > OS's equivalent) for the transmit timestamp, and when the > authenticated (and possibly encrypted) packet is ready to send. > > The first optimization is straightforward. AES-CMAC supports > incremental, one-pass computation, as do all (D)TLS ciphers. That > means it's possible to precompute the crypto for every block preceding > the one that holds the transmit timestamp, before the transmit > timestamp is obtained. (This is possible with MD5 too, but it doesn't > buy you anything because MD5's internal block size is larger than the > data being hashed.) > > The second optimization only works in DTLS, and it's *conceptually* > straightforward but probably a pain to implement just on account of > API limitations in TLS libraries. With AES-GCM, as well as with any > stream cipher, you can precompute encryption of the transmit timestamp > even before you have it, because all the expensive parts of encryption > don't depend on the plaintext -- you use your cipher algorithm to > compute a pseudorandom stream of bits and then the combination with > the plaintext is a simple xor (a single CPU cycle, which I'll > neglect). > > An NTP header is 48 octets, which conveniently works out to exactly > three AES blocks. In this situation, AES-CMAC basically acts like > AES-CBC with one extra XOR thrown in and outputting just the final > block. On my Broadwell system, AES-CBC takes about 75 cycles per > block. On Skylake it's somewhat faster. So, to get from capturing the > transmit timestamp to a ready message, you need about 75 CPU cycles if > you optimize or about 225 if you don't. Both of these figures assume > you're at least doing AES key setup before you get the transmit > timestamp. I'm not sure exactly how much key setup adds, probably > another few hundred cycles, but I'm not going to bother measuring it > because not doing that in advance is just dumb. > > Now let's look at DTLS with AES-GCM. A DTLS record consists of a > 12-octet header, treated as associated data, followed by ciphertext > which is internally structured as the > actual encrypted payload followed by a 16-octet authenticator. > > AES-GCM is rather complex, but at high level you can think of it as a > combination of AES-CTR with a non-cryptographic hash called GHASH. Its > cost comes down to the cost of computing AES-CTR over the plaintext, > plus the cost of computing GHASH over the associated data and the > output of AES-CTR, plus the cost of one additional AES operation at > the end. > > AES-CTR allows you use CPU pipelining to encrypt a few blocks in > parallel on a single core. Encrypting one block costs about the same > as one block with AES-CBC (about 75 cycles), but you can do three > blocks for about the same cost as one. GHASH adds about 5 cycles per > block. Regardless, computing the authenticator adds another 75 cycles > or so at the end. > > So with no optimization, we're looking at 75 cycles for AES-CTR, 20 > cycles for GHASH, 75 cycles for the authenticator. > > Basic optimization saves 15 cycles on GHASH, but because of > parallelism doesn't buy anything else. > > Clever optimization cuts out everything except the final authenticator > computation. > > So here's how it roughly works out: > > MD5: 900 cycles > AES-CMAC, no optimization: 225 cycles > AES-CMAC, basic optimization: 75 cycles > DTLS, no optimization: 170 cycles > DTLS, basic optimization: 155 cycles > DTLS, clever optimization: 75 cycles > > 900 cycles for MD5 at 3.5GHz is 257 nanoseconds. In the worst case, > the resulting timing asymmetry throws off your accuracy by half that, > or 128 nanoseconds. That is several orders magnitude smaller than > anything NTP can possibly promise you. If you want to measure the > impact of adding the MD5 step in real world conditions, you will have > an extremely difficult time distinguishing it from zero. > > AES-CMAC and DTLS each cut this performance impact by an additional > order of magnitude. If you try measuring the impact of either one and > tell me that you were able to do so, I will tell you that there is > either something wrong with your experiment or something wrong with > your crypto implementation. > > DTLS encapsulation is *just fine*. > > _______________________________________________ > ntp mailing list > ntp@ietf.org > https://www.ietf.org/mailman/listinfo/ntp --=_alternative 0053AD94C125818C_= Content-Type: text/html; charset="US-ASCII"


"ntp" <ntp-bounces@ietf.org> schrieb am 30.08.2017 00:44:53:

> Von: Daniel Franke <dfoxfranke@gmail.com>
> An: kristof.teichel@ptb.de
> Kopie: ntp@ietf.org, Harlan Stenn <stenn@nwtime.org>
> Datum: 30.08.2017 00:45
> Betreff: Re: [Ntp] WGLC for draft-ietf-ntp-using-nts-for-ntp
> Gesendet von: "ntp" <ntp-bounces@ietf.org>
>
> On 8/29/17, kristof.teichel@ptb.de <kristof.teichel@ptb.de> wrote:
> > Historically, encapsulation is an overall concept that has been argued
> > against a lot in the course of NTS (as far as I've witnessed it).
> > Therefore, I think that a paragraph of discussion on the presumed
> > negligibiliy of the precision loss with DTLS-encapsulation is warranted.
> >
> > Especially in the case of transmit timestamps (where every cryptographic
> > operation takes place between the reading of the timestamp and the actual
> > time of transmission that the timestamp was supposed to measure), perhaps it
> > should at least be mentioned why this encapsulation is not significantly
> > more expensive than e.g. adding a MAC/AEAD value.
> >
> > One thing I really don't know, however, is where such a piece of text should
> > be placed in order to not distort the core specification text (I don't think
> > anyone wants to or should have to read a passage about the design decision
> > process in the middle of the instructions on how to do the
> > DTLS-encapsulation).
>
> I don't think performance analysis needs to go in the RFC at all. I
> can't call to mind any other RFC that has included such a thing, and
> I'm certain I've never seen it out of the TLS WG.

I agree with Daniel. A standards document is not the appropriate place for a performance analysis.


>
> But for any skeptics, here's the math.
>
> Let's start by looking at legacy MD5(K||M). Computing MD5 over 64
> bytes ( 16-byte key, 48-byte NTP header) takes about 900 cycles on my
> Broadwell system.
>
> Now let's look at the AES-CMAC draft and at DTLS encapsulation with AES-GCM.
>
> For these, a couple optimizations are possible to minimize the time
> that elapses between when you call clock_gettime() (or whatever your
> OS's equivalent) for the transmit timestamp, and when the
> authenticated (and possibly encrypted) packet is ready to send.
>
> The first optimization is straightforward. AES-CMAC supports
> incremental, one-pass computation, as do all (D)TLS ciphers. That
> means it's possible to precompute the crypto for every block preceding
> the one that holds the transmit timestamp, before the transmit
> timestamp is obtained. (This is possible with MD5 too, but it doesn't
> buy you anything because MD5's internal block size is larger than the
> data being hashed.)
>
> The second optimization only works in DTLS, and it's *conceptually*
> straightforward but probably a pain to implement just on account of
> API limitations in TLS libraries. With AES-GCM, as well as with any
> stream cipher, you can precompute encryption of the transmit timestamp
> even before you have it, because all the expensive parts of encryption
> don't depend on the plaintext -- you use your cipher algorithm to
> compute a pseudorandom stream of bits and then the combination with
> the plaintext is a simple xor (a single CPU cycle, which I'll
> neglect).
>
> An NTP header is 48 octets, which conveniently works out to exactly
> three AES blocks. In this situation, AES-CMAC basically acts like
> AES-CBC with one extra XOR thrown in and outputting just the final
> block. On my Broadwell system, AES-CBC takes about 75 cycles per
> block. On Skylake it's somewhat faster. So, to get from capturing the
> transmit timestamp to a ready message, you need about 75 CPU cycles if
> you optimize or about 225 if you don't. Both of these figures assume
> you're at least doing AES key setup before you get the transmit
> timestamp. I'm not sure exactly how much key setup adds, probably
> another few hundred cycles, but I'm not going to bother measuring it
> because not doing that in advance is just dumb.
>
> Now let's look at DTLS with AES-GCM. A DTLS record consists of a
> 12-octet header, treated as associated data, followed by ciphertext
> which is internally structured as the
> actual encrypted payload followed by a 16-octet authenticator.
>
> AES-GCM is rather complex, but at high level you can think of it as a
> combination of AES-CTR with a non-cryptographic hash called GHASH. Its
> cost comes down to the cost of computing AES-CTR over the plaintext,
> plus the cost of computing GHASH over the associated data and the
> output of AES-CTR, plus the cost of one additional AES operation at
> the end.
>
> AES-CTR allows you use CPU pipelining to encrypt a few blocks in
> parallel on a single core. Encrypting one block costs about the same
> as one block with AES-CBC (about 75 cycles), but you can do three
> blocks for about the same cost as one. GHASH adds about 5 cycles per
> block. Regardless, computing the authenticator adds another 75 cycles
> or so at the end.
>
> So with no optimization, we're looking at 75 cycles for AES-CTR, 20
> cycles for GHASH, 75 cycles for the authenticator.
>
> Basic optimization saves 15 cycles on GHASH, but because of
> parallelism doesn't buy anything else.
>
> Clever optimization cuts out everything except the final authenticator
> computation.
>
> So here's how it roughly works out:
>
> MD5: 900 cycles
> AES-CMAC, no optimization: 225 cycles
> AES-CMAC, basic optimization: 75 cycles
> DTLS, no optimization: 170 cycles
> DTLS, basic optimization: 155 cycles
> DTLS, clever optimization: 75 cycles
>
> 900 cycles for MD5 at 3.5GHz is 257 nanoseconds. In the worst case,
> the resulting timing asymmetry throws off your accuracy by half that,
> or 128 nanoseconds. That is several orders magnitude smaller than
> anything NTP can possibly promise you. If you want to measure the
> impact of adding the MD5 step in real world conditions, you will have
> an extremely difficult time distinguishing it from zero.
>
> AES-CMAC and DTLS each cut this performance impact by an additional
> order of magnitude. If you try measuring the impact of either one and
> tell me that you were able to do so, I will tell you that there is
> either something wrong with your experiment or something wrong with
> your crypto implementation.
>
> DTLS encapsulation is *just fine*.
>
> _______________________________________________
> ntp mailing list
> ntp@ietf.org
> https://www.ietf.org/mailman/listinfo/ntp
 --=_alternative 0053AD94C125818C_=-- ---------z16761_boundary_sign Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIIp0gIBATEPMA0GCWCGSAFlAwQCAQUAMAsGCSqGSIb3DQEHAaCCJsYw ggOfMIICh6ADAgECAgEmMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNE ZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYD VQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw05OTA3MDkxMjExMDBaFw0xOTA3MDky MzU5MDBaMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYD VQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJv b3QgQ0EgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKsLozXgiykUsRSFrzwQ5Dlv NV1Krt3qYY2VSfRvZKMaYGakqUAihNnUpeV4kw5oAa25TVw6ztO4qEJA38+juoJZapIbrBya2ggr JSf5aSNH8eDrLHqb9RMC0H40fMKePABZq/XaDPUyPCusUNrWw96DlMqoDJkyDghIVltq+9rhWFgB SV9yQTwVBgGOXa2quJO0zZ7rp+hqLVI02zrvXHVR2tvzMfnucZgyxFQVRAz5m1Xtrd8YCKCjhopJ 7lMFjxlM1d5YeZvSahxCq8XVp89oD5bk4WGYdmHIkXzWPgDikVCH4Z0K5q2X0h3GOn3LvNoDNNWO WwH1age3FrZuSn8CAwEAAaNCMEAwHQYDVR0OBBYEFDHDeRu69VPXF+CJei0XbAqzK50zMA8GA1Ud EwQIMAYBAf8CAQUwDgYDVR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBBQUAA4IBAQCUZFmtOWTnKesT /lrDixNXyAQk8HR3wGDjZ/vpiaaDv5aCfG7Uwz3vnoBuuym0mHqxO1TrORdHfhqOC/wfMVkxBLLO F/Msx2I2VeIi2IlVtJhIqmT61hw22ER4WlojOleX9XowT66fakxLK46gA+M+4KnU0nvSs6jicjyt nv+AWeSbRbT2O7DNORmYMuXqIWGQ5DEhjjSx9y81SoUQ2ueKNyG+WWPg8oWIMVPUVBSFcHn0LgZ3 J3UvH7iK+f7Futg25IPs52W3v2Na80avgZQ31EGM1iPWHs/1aBtEY6Jauqc1WaHlcAWbDiNXmZQK bbo5YyiGkvMYhNj70c8FVmRXMIIDnzCCAoegAwIBAgIBJjANBgkqhkiG9w0BAQUFADBxMQswCQYD VQQGEwJERTEcMBoGA1UEChMTRGV1dHNjaGUgVGVsZWtvbSBBRzEfMB0GA1UECxMWVC1UZWxlU2Vj IFRydXN0IENlbnRlcjEjMCEGA1UEAxMaRGV1dHNjaGUgVGVsZWtvbSBSb290IENBIDIwHhcNOTkw NzA5MTIxMTAwWhcNMTkwNzA5MjM1OTAwWjBxMQswCQYDVQQGEwJERTEcMBoGA1UEChMTRGV1dHNj aGUgVGVsZWtvbSBBRzEfMB0GA1UECxMWVC1UZWxlU2VjIFRydXN0IENlbnRlcjEjMCEGA1UEAxMa RGV1dHNjaGUgVGVsZWtvbSBSb290IENBIDIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCrC6M14IspFLEUha88EOQ5bzVdSq7d6mGNlUn0b2SjGmBmpKlAIoTZ1KXleJMOaAGtuU1cOs7T uKhCQN/Po7qCWWqSG6wcmtoIKyUn+WkjR/Hg6yx6m/UTAtB+NHzCnjwAWav12gz1MjwrrFDa1sPe g5TKqAyZMg4ISFZbavva4VhYAUlfckE8FQYBjl2tqriTtM2e66foai1SNNs671x1Udrb8zH57nGY MsRUFUQM+ZtV7a3fGAigo4aKSe5TBY8ZTNXeWHmb0mocQqvF1afPaA+W5OFhmHZhyJF81j4A4pFQ h+GdCuatl9Idxjp9y7zaAzTVjlsB9WoHtxa2bkp/AgMBAAGjQjBAMB0GA1UdDgQWBBQxw3kbuvVT 1xfgiXotF2wKsyudMzAPBgNVHRMECDAGAQH/AgEFMA4GA1UdDwEB/wQEAwIBBjANBgkqhkiG9w0B AQUFAAOCAQEAlGRZrTlk5ynrE/5aw4sTV8gEJPB0d8Bg42f76Ymmg7+Wgnxu1MM9756AbrsptJh6 sTtU6zkXR34ajgv8HzFZMQSyzhfzLMdiNlXiItiJVbSYSKpk+tYcNthEeFpaIzpXl/V6ME+un2pM SyuOoAPjPuCp1NJ70rOo4nI8rZ7/gFnkm0W09juwzTkZmDLl6iFhkOQxIY40sfcvNUqFENrnijch vllj4PKFiDFT1FQUhXB59C4Gdyd1Lx+4ivn+xbrYNuSD7Odlt79jWvNGr4GUN9RBjNYj1h7P9Wgb RGOiWrqnNVmh5XAFmw4jV5mUCm26OWMohpLzGITY+9HPBVZkVzCCBNUwggO9oAMCAQICCFBOxvU9 EbRkMA0GCSqGSIb3DQEBCwUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNEZXV0c2NoZSBUZWxl a29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYDVQQDExpEZXV0c2No ZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0xNDA3MjIxMjA4MjZaFw0xOTA3MDkyMzU5MDBaMFoxCzAJ BgNVBAYTAkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQD ExtERk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U1wBblSJ01CDrNI/W7MAxBAuZgeKmFNJSoCgjhIt0 iQReW+DieMF4yxbLKDU5ey2QRdDtoAB6fL9KDhsAw4bpXCsxEXsM84IkQ4wcOItqaACa7txPeKvS xhObdq3u3ibo7wGvdA/BCaL2a869080UME/15eOkyGKbghoDJzANAmVgTe3RCSMqljVYJ9N2xnG2 kB3E7f81hn1vM7PbD8URwoqDoZRdQWvY0hD1TP3KUazZve+Sg7va64sWVlZDz+HVEz2mHycwzUlU 28kTNJpxdcVs6qcLmPkhnSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjggGGMIIBgjAOBgNVHQ8BAf8E BAMCAQYwHQYDVR0OBBYEFEm3xs/oPR9/6kR7Eyn38QpwPt5kMB8GA1UdIwQYMBaAFDHDeRu69VPX F+CJei0XbAqzK50zMBIGA1UdEwEB/wQIMAYBAf8CAQIwYgYDVR0gBFswWTARBg8rBgEEAYGtIYIs AQEEAgIwEQYPKwYBBAGBrSGCLAEBBAMAMBEGDysGAQQBga0hgiwBAQQDATAPBg0rBgEEAYGtIYIs AQEEMA0GCysGAQQBga0hgiweMD4GA1UdHwQ3MDUwM6AxoC+GLWh0dHA6Ly9wa2kwMzM2LnRlbGVz ZWMuZGUvcmwvRFRfUk9PVF9DQV8yLmNybDB4BggrBgEFBQcBAQRsMGowLAYIKwYBBQUHMAGGIGh0 dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMDoGCCsGAQUFBzAChi5odHRwOi8vcGtpMDMz Ni50ZWxlc2VjLmRlL2NydC9EVF9ST09UX0NBXzIuY2VyMA0GCSqGSIb3DQEBCwUAA4IBAQBjICj9 nCGGcr45Rlk5MiW8qQGbDczKfUGchm0KbiyzE1l1sTOSG2EnFv/DstU1gvuEKgFJvWa7Zi+ywgZd bj9u4wFaW8pDY1yVtuExpx/VB19N5mWCTjL5w3x6S81NXHTuIfJ1AuxSPtLJatOQI25JZzW+f01W pOzML8+3oZeocj7JvEDWWqQIPda8gsO3tzKOsSyOam23NQIZz/U5RFhjpyQAELC7/E6vbi84u6VX ST/YblBvLJeW3B1GmmWJz67M8uXZn1OzPqEvkqnYC8aEHwTG6x7on321e6UC8STFJGMRNMxakyAq eYg6JUKQqWU7fIbTEhUjKfws2sw5W1QXMIIE1TCCA72gAwIBAgIIUE7G9T0RtGQwDQYJKoZIhvcN AQELBQAwcTELMAkGA1UEBhMCREUxHDAaBgNVBAoTE0RldXRzY2hlIFRlbGVrb20gQUcxHzAdBgNV BAsTFlQtVGVsZVNlYyBUcnVzdCBDZW50ZXIxIzAhBgNVBAMTGkRldXRzY2hlIFRlbGVrb20gUm9v dCBDQSAyMB4XDTE0MDcyMjEyMDgyNloXDTE5MDcwOTIzNTkwMFowWjELMAkGA1UEBhMCREUxEzAR BgNVBAoTCkRGTi1WZXJlaW4xEDAOBgNVBAsTB0RGTi1QS0kxJDAiBgNVBAMTG0RGTi1WZXJlaW4g UENBIEdsb2JhbCAtIEcwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOmbw2eF+Q2u 9Y1Uw5ZQNT1i6W5M7ZTXAFuVInTUIOs0j9bswDEEC5mB4qYU0lKgKCOEi3SJBF5b4OJ4wXjLFsso NTl7LZBF0O2gAHp8v0oOGwDDhulcKzERewzzgiRDjBw4i2poAJru3E94q9LGE5t2re7eJujvAa90 D8EJovZrzr3TzRQwT/Xl46TIYpuCGgMnMA0CZWBN7dEJIyqWNVgn03bGcbaQHcTt/zWGfW8zs9sP xRHCioOhlF1Ba9jSEPVM/cpRrNm975KDu9rrixZWVkPP4dUTPaYfJzDNSVTbyRM0mnF1xWzqpwuY +SGdJ68+ozk5SGqMrcmZ+8MS8r0CAwEAAaOCAYYwggGCMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4E FgQUSbfGz+g9H3/qRHsTKffxCnA+3mQwHwYDVR0jBBgwFoAUMcN5G7r1U9cX4Il6LRdsCrMrnTMw EgYDVR0TAQH/BAgwBgEB/wIBAjBiBgNVHSAEWzBZMBEGDysGAQQBga0hgiwBAQQCAjARBg8rBgEE AYGtIYIsAQEEAwAwEQYPKwYBBAGBrSGCLAEBBAMBMA8GDSsGAQQBga0hgiwBAQQwDQYLKwYBBAGB rSGCLB4wPgYDVR0fBDcwNTAzoDGgL4YtaHR0cDovL3BraTAzMzYudGVsZXNlYy5kZS9ybC9EVF9S T09UX0NBXzIuY3JsMHgGCCsGAQUFBwEBBGwwajAsBggrBgEFBQcwAYYgaHR0cDovL29jc3AwMzM2 LnRlbGVzZWMuZGUvb2NzcHIwOgYIKwYBBQUHMAKGLmh0dHA6Ly9wa2kwMzM2LnRlbGVzZWMuZGUv Y3J0L0RUX1JPT1RfQ0FfMi5jZXIwDQYJKoZIhvcNAQELBQADggEBAGMgKP2cIYZyvjlGWTkyJbyp AZsNzMp9QZyGbQpuLLMTWXWxM5IbYScW/8Oy1TWC+4QqAUm9ZrtmL7LCBl1uP27jAVpbykNjXJW2 4TGnH9UHX03mZYJOMvnDfHpLzU1cdO4h8nUC7FI+0slq05AjbklnNb5/TVak7Mwvz7ehl6hyPsm8 QNZapAg91ryCw7e3Mo6xLI5qbbc1AhnP9TlEWGOnJAAQsLv8Tq9uLzi7pVdJP9huUG8sl5bcHUaa ZYnPrszy5dmfU7M+oS+SqdgLxoQfBMbrHuiffbV7pQLxJMUkYxE0zFqTICp5iDolQpCpZTt8htMS FSMp/CzazDlbVBcwggU9MIIEJaADAgECAgcXr/adVkv+MA0GCSqGSIb3DQEBCwUAMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtE Rk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwHhcNMTQwNjA1MTQwNTAyWhcNMTkwNzA5MjM1OTAw WjBpMQswCQYDVQQGEwJERTEuMCwGA1UEChMlUGh5c2lrYWxpc2NoLVRlY2huaXNjaGUgQnVuZGVz YW5zdGFsdDEPMA0GA1UEAxMGUFRCIENBMRkwFwYJKoZIhvcNAQkBFgpwa2lAcHRiLmRlMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvArCgzkqw2LMAYuU38VJTgyGBC+Pp+uvw52LmtI6 MEMiFr0xY6SEzYcDG3z5NSohZisdnL7bu8Ee7MFD3TZX1jVBie//UNAJqXbHnUzE8hbJYCR5ydb9 WqIzoT5PzG07qJWblbidcrZVcCQEef9V1CaRyfXuqiSTOgibqODLP98N7jMIImz2ipUgMdoGyOgS h/qds5SM6CUgwMeuJ42QpYNot9ri1IKAweyhIIa3TANsu56scy+Fc2+XWOfsuImeeLcaiu6HJPk6 X55QT+kWaAoQf6qJyJXv8b/n6l1nmTIU2AY2B5EnO/rIT+DW+MJy77/HO+7rtwaznuntXMgytwID AQABo4IB9zCCAfMwEgYDVR0TAQH/BAgwBgEB/wIBATAOBgNVHQ8BAf8EBAMCAQYwEQYDVR0gBAow CDAGBgRVHSAAMB0GA1UdDgQWBBTEgNBuKBVoMVrscF94juEwQzjqNDAfBgNVHSMEGDAWgBRJt8bP 6D0ff+pEexMp9/EKcD7eZDAVBgNVHREEDjAMgQpwa2lAcHRiLmRlMIGIBgNVHR8EgYAwfjA9oDug OYY3aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY3JsL2NhY3JsLmNy bDA9oDugOYY3aHR0cDovL2NkcDIucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY3JsL2Nh Y3JsLmNybDCB1wYIKwYBBQUHAQEEgcowgccwMwYIKwYBBQUHMAGGJ2h0dHA6Ly9vY3NwLnBjYS5k Zm4uZGUvT0NTUC1TZXJ2ZXIvT0NTUDBHBggrBgEFBQcwAoY7aHR0cDovL2NkcDEucGNhLmRmbi5k ZS9nbG9iYWwtcm9vdC1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwRwYIKwYBBQUHMAKGO2h0dHA6 Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MA0G CSqGSIb3DQEBCwUAA4IBAQCo3hebMpEocLPJTOlDMAmSzpxK3SA1ftaQqodbMncOi9WkeICQlmIv rQxGCq8Be/6hKtIrbFOhRtSzQi870glJRj7dhZaHC+WOgT5tP5Nkgwpgl4k4pQDXPPrwmaI6cSYD a/LpprQzBNjEQMdQqkeanpD0WU9U1pOPFIMfIrxh2cy8mBpIAMuZqMHbMyPNDZk/YN4r3b2DcBrQ wL/tHerp6Vc7n9WqO+3cm7Fa4AxL9q2KeItyYe0Cws2KZNz4IuiMjQAclNL0PhTEqIzkD/EiK6Ag 1qcH7o3ktpmakvL2RzSZA71irCfONRgh/+ixfuMu6YA5uzyA8SYfwyFQcABdMIIFPTCCBCWgAwIB AgIHF6/2nVZL/jANBgkqhkiG9w0BAQsFADBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZOLVZl cmVpbjEQMA4GA1UECxMHREZOLVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xvYmFsIC0g RzAxMB4XDTE0MDYwNTE0MDUwMloXDTE5MDcwOTIzNTkwMFowaTELMAkGA1UEBhMCREUxLjAsBgNV BAoTJVBoeXNpa2FsaXNjaC1UZWNobmlzY2hlIEJ1bmRlc2Fuc3RhbHQxDzANBgNVBAMTBlBUQiBD QTEZMBcGCSqGSIb3DQEJARYKcGtpQHB0Yi5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALwKwoM5KsNizAGLlN/FSU4MhgQvj6frr8Odi5rSOjBDIha9MWOkhM2HAxt8+TUqIWYrHZy+ 27vBHuzBQ902V9Y1QYnv/1DQCal2x51MxPIWyWAkecnW/VqiM6E+T8xtO6iVm5W4nXK2VXAkBHn/ VdQmkcn17qokkzoIm6jgyz/fDe4zCCJs9oqVIDHaBsjoEof6nbOUjOglIMDHrieNkKWDaLfa4tSC gMHsoSCGt0wDbLuerHMvhXNvl1jn7LiJnni3GoruhyT5Ol+eUE/pFmgKEH+qiciV7/G/5+pdZ5ky FNgGNgeRJzv6yE/g1vjCcu+/xzvu67cGs57p7VzIMrcCAwEAAaOCAfcwggHzMBIGA1UdEwEB/wQI MAYBAf8CAQEwDgYDVR0PAQH/BAQDAgEGMBEGA1UdIAQKMAgwBgYEVR0gADAdBgNVHQ4EFgQUxIDQ bigVaDFa7HBfeI7hMEM46jQwHwYDVR0jBBgwFoAUSbfGz+g9H3/qRHsTKffxCnA+3mQwFQYDVR0R BA4wDIEKcGtpQHB0Yi5kZTCBiAYDVR0fBIGAMH4wPaA7oDmGN2h0dHA6Ly9jZHAxLnBjYS5kZm4u ZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NybC9jYWNybC5jcmwwPaA7oDmGN2h0dHA6Ly9jZHAyLnBj YS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NybC9jYWNybC5jcmwwgdcGCCsGAQUFBwEBBIHK MIHHMDMGCCsGAQUFBzABhidodHRwOi8vb2NzcC5wY2EuZGZuLmRlL09DU1AtU2VydmVyL09DU1Aw RwYIKwYBBQUHMAKGO2h0dHA6Ly9jZHAxLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2Nh Y2VydC9jYWNlcnQuY3J0MEcGCCsGAQUFBzAChjtodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2dsb2Jh bC1yb290LWNhL3B1Yi9jYWNlcnQvY2FjZXJ0LmNydDANBgkqhkiG9w0BAQsFAAOCAQEAqN4XmzKR KHCzyUzpQzAJks6cSt0gNX7WkKqHWzJ3DovVpHiAkJZiL60MRgqvAXv+oSrSK2xToUbUs0IvO9IJ SUY+3YWWhwvljoE+bT+TZIMKYJeJOKUA1zz68JmiOnEmA2vy6aa0MwTYxEDHUKpHmp6Q9FlPVNaT jxSDHyK8YdnMvJgaSADLmajB2zMjzQ2ZP2DeK929g3Aa0MC/7R3q6elXO5/Vqjvt3JuxWuAMS/at iniLcmHtAsLNimTc+CLojI0AHJTS9D4UxKiM5A/xIiugINanB+6N5LaZmpLy9kc0mQO9YqwnzjUY If/osX7jLumAObs8gPEmH8MhUHAAXTCCBaIwggSKoAMCAQICDBxmO6qdufc5yhZ6iDANBgkqhkiG 9w0BAQsFADBpMQswCQYDVQQGEwJERTEuMCwGA1UEChMlUGh5c2lrYWxpc2NoLVRlY2huaXNjaGUg QnVuZGVzYW5zdGFsdDEPMA0GA1UEAxMGUFRCIENBMRkwFwYJKoZIhvcNAQkBFgpwa2lAcHRiLmRl MB4XDTE2MTIwNjEzMzMxNFoXDTE5MDcwOTIzNTkwMFowaDELMAkGA1UEBhMCREUxLjAsBgNVBAoM JVBoeXNpa2FsaXNjaC1UZWNobmlzY2hlIEJ1bmRlc2Fuc3RhbHQxDTALBgNVBAsMBFEuNDIxGjAY BgNVBAMMEURyLiBEaWV0ZXIgU2lib2xkMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA +AOQrmrEQ2k8s9su/TVvmdF46YbL2MuF6OvnrjjKaJIkBvchop87cCwv80aZEbmU3as54egQEMGn NFkp1fF4bics4TJdEpND116l+jbi5DCtA3hHP/spV1aQZBDc/BDkm1Nl5WYKh/DxN6sUhZxorbb4 Y0nmSxnK2ctIwuF4Qdibsw7GE2YLvWF4tlzSCGbDjSy2agSn1wYHMsC+tAcFflcMXF2sDMZHkYuq 5IHwng8GBQFhsldYl1fk2sB2/hVRLYU205qaj13H94WjfDLuB22sT17XPJ2U/9tuFN/sxAPR0/N4 y4/IgMnOaP30VU0FMmULd7qJg0WST5D5kwgMhwIDAQABo4ICSTCCAkUwQAYDVR0gBDkwNzARBg8r BgEEAYGtIYIsAQEEAwUwEQYPKwYBBAGBrSGCLAIBBAMBMA8GDSsGAQQBga0hgiwBAQQwCQYDVR0T BAIwADAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1Ud DgQWBBQHn42zKDpvJi1bsJ4OVk2A9liUFjAfBgNVHSMEGDAWgBTEgNBuKBVoMVrscF94juEwQzjq NDBEBgNVHREEPTA7gRRkaWV0ZXIuc2lib2xkQHB0Yi5kZaAjBgorBgEEAYI3FAIDoBUME3NpYm9s ZDAxQHBhZC5wdGIuZGUwdwYDVR0fBHAwbjA1oDOgMYYvaHR0cDovL2NkcDEucGNhLmRmbi5kZS9w dGItY2EvcHViL2NybC9jYWNybC5jcmwwNaAzoDGGL2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvcHRi LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIHHBggrBgEFBQcBAQSBujCBtzAzBggrBgEFBQcwAYYnaHR0 cDovL29jc3AucGNhLmRmbi5kZS9PQ1NQLVNlcnZlci9PQ1NQMD8GCCsGAQUFBzAChjNodHRwOi8v Y2RwMS5wY2EuZGZuLmRlL3B0Yi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwPwYIKwYBBQUHMAKG M2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvcHRiLWNhL3B1Yi9jYWNlcnQvY2FjZXJ0LmNydDANBgkq hkiG9w0BAQsFAAOCAQEADaSfgrrQZx9eiQrCK7kgJMpLstro5OgIcWSpW4i4AQ1wEwyDUrdB1XWK GjA8/KwExSBP9a+dcdW+ACjX7TyURQPLqRTOkoPc9dafRx327mV4K8PE8z7fg5l2ittYNs0nXlOB QevRbYYP4XUOMYohFWfHpDwEg3ExmoArb2HaQCzKhq/2VcIIXTwaN6AVr2NVKEuH3qwpgOUSlJJ1 5ORb6TD4p1G2W6XT3jk3tOa8nRaOkI5hqpPvLfbPEibn+Bfqm6GWqpXfQ6NLAvWYcI8ltSKgdnCw Rmqdh1Ba/KWGdm41PDtQIx58vgbZGfN5GKJrp+OwS5D+/e/r296qoKUBRDCCBaIwggSKoAMCAQIC DBxmO6qdufc5yhZ6iDANBgkqhkiG9w0BAQsFADBpMQswCQYDVQQGEwJERTEuMCwGA1UEChMlUGh5 c2lrYWxpc2NoLVRlY2huaXNjaGUgQnVuZGVzYW5zdGFsdDEPMA0GA1UEAxMGUFRCIENBMRkwFwYJ KoZIhvcNAQkBFgpwa2lAcHRiLmRlMB4XDTE2MTIwNjEzMzMxNFoXDTE5MDcwOTIzNTkwMFowaDEL MAkGA1UEBhMCREUxLjAsBgNVBAoMJVBoeXNpa2FsaXNjaC1UZWNobmlzY2hlIEJ1bmRlc2Fuc3Rh bHQxDTALBgNVBAsMBFEuNDIxGjAYBgNVBAMMEURyLiBEaWV0ZXIgU2lib2xkMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA+AOQrmrEQ2k8s9su/TVvmdF46YbL2MuF6OvnrjjKaJIkBvch op87cCwv80aZEbmU3as54egQEMGnNFkp1fF4bics4TJdEpND116l+jbi5DCtA3hHP/spV1aQZBDc /BDkm1Nl5WYKh/DxN6sUhZxorbb4Y0nmSxnK2ctIwuF4Qdibsw7GE2YLvWF4tlzSCGbDjSy2agSn 1wYHMsC+tAcFflcMXF2sDMZHkYuq5IHwng8GBQFhsldYl1fk2sB2/hVRLYU205qaj13H94WjfDLu B22sT17XPJ2U/9tuFN/sxAPR0/N4y4/IgMnOaP30VU0FMmULd7qJg0WST5D5kwgMhwIDAQABo4IC STCCAkUwQAYDVR0gBDkwNzARBg8rBgEEAYGtIYIsAQEEAwUwEQYPKwYBBAGBrSGCLAIBBAMBMA8G DSsGAQQBga0hgiwBAQQwCQYDVR0TBAIwADAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYB BQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQHn42zKDpvJi1bsJ4OVk2A9liUFjAfBgNVHSMEGDAW gBTEgNBuKBVoMVrscF94juEwQzjqNDBEBgNVHREEPTA7gRRkaWV0ZXIuc2lib2xkQHB0Yi5kZaAj BgorBgEEAYI3FAIDoBUME3NpYm9sZDAxQHBhZC5wdGIuZGUwdwYDVR0fBHAwbjA1oDOgMYYvaHR0 cDovL2NkcDEucGNhLmRmbi5kZS9wdGItY2EvcHViL2NybC9jYWNybC5jcmwwNaAzoDGGL2h0dHA6 Ly9jZHAyLnBjYS5kZm4uZGUvcHRiLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIHHBggrBgEFBQcBAQSB ujCBtzAzBggrBgEFBQcwAYYnaHR0cDovL29jc3AucGNhLmRmbi5kZS9PQ1NQLVNlcnZlci9PQ1NQ MD8GCCsGAQUFBzAChjNodHRwOi8vY2RwMS5wY2EuZGZuLmRlL3B0Yi1jYS9wdWIvY2FjZXJ0L2Nh Y2VydC5jcnQwPwYIKwYBBQUHMAKGM2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvcHRiLWNhL3B1Yi9j YWNlcnQvY2FjZXJ0LmNydDANBgkqhkiG9w0BAQsFAAOCAQEADaSfgrrQZx9eiQrCK7kgJMpLstro 5OgIcWSpW4i4AQ1wEwyDUrdB1XWKGjA8/KwExSBP9a+dcdW+ACjX7TyURQPLqRTOkoPc9dafRx32 7mV4K8PE8z7fg5l2ittYNs0nXlOBQevRbYYP4XUOMYohFWfHpDwEg3ExmoArb2HaQCzKhq/2VcII XTwaN6AVr2NVKEuH3qwpgOUSlJJ15ORb6TD4p1G2W6XT3jk3tOa8nRaOkI5hqpPvLfbPEibn+Bfq m6GWqpXfQ6NLAvWYcI8ltSKgdnCwRmqdh1Ba/KWGdm41PDtQIx58vgbZGfN5GKJrp+OwS5D+/e/r 296qoKUBRDGCAuMwggLfAgEBMHkwaTELMAkGA1UEBhMCREUxLjAsBgNVBAoTJVBoeXNpa2FsaXNj aC1UZWNobmlzY2hlIEJ1bmRlc2Fuc3RhbHQxDzANBgNVBAMTBlBUQiBDQTEZMBcGCSqGSIb3DQEJ ARYKcGtpQHB0Yi5kZQIMHGY7qp259znKFnqIMA0GCWCGSAFlAwQCAQUAoIIBOzAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzA4MzAxNTEzNTlaMC8GCSqGSIb3DQEJ BDEiBCAXBDYLhwap0dDIeKJnkjp/MjZIf/BBxqsJPUOX4BVIsjBDBgkqhkiG9w0BCQ8xNjA0MAcG BSsOAwIdMA4GCCqGSIb3DQMCAgIAgDAKBggqhkiG9w0DBzANBggqhkiG9w0DAgIBKDCBigYLKoZI hvcNAQkQAgsxe6B5MGkxCzAJBgNVBAYTAkRFMS4wLAYDVQQKEyVQaHlzaWthbGlzY2gtVGVjaG5p c2NoZSBCdW5kZXNhbnN0YWx0MQ8wDQYDVQQDEwZQVEIgQ0ExGTAXBgkqhkiG9w0BCQEWCnBraUBw dGIuZGUCDBxmO6qdufc5yhZ6iDANBgkqhkiG9w0BAQEFAASCAQA5KU9Eh8CcY//LBHunSTRg8Wgf 9iImWkkUu0OFmssn3HjbagoYu2cJelBv3vzMv7ZFc4iXkq/TRZZsV4weQhPxZJ8iwemtnNeIgL7O HhvZfSF/W08WAnDWfIUHZQ1h3KEjKiYaVysC/wjLTfmyYHGJhgmiwo8HchRHaZ5sxi8gAtqDfzCA YyDR5I6NQvtTomQRGM7llsFsxTqhtVv8f/hq2jvm1q/+ZHYzZQZC6iXdoV9/QJSPr0YsZ8B6fPgg knbtC2UQQE+AWoJ7FoOehxCliJ1aQv7QTUJlP0yt2k7LgVMBCM7xF46Rie2ac86+iVJiUMBTwA4I G5vcqKPXyf0cAAAAAA== ---------z16761_boundary_sign-- --===============3293666846650183441== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp --===============3293666846650183441==-- From ntp-bounces@ietf.org Wed Aug 30 08:21:47 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0186F1321B7; Wed, 30 Aug 2017 08:21:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1504106507; bh=9ufHEf84VACj8X2rWfbac0bP2Ei0tcAUEFw3Mc1s9ig=; h=In-Reply-To:References:To:From:Date:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc; b=l+72Rb3JX2YwT459bPgMIUUHJUUZj6YC3s9RadQOh06dYWIOSlomUdvRrQOw8+q+g HJvnCJPZxIn73h0F7gkWARwEFNbkjmRU1V0EJNKB2GK4dJO7uN/E9bvHEE5cKQfnRG wM9fWS4t4wX21f6YM5e9w9lvAWoZDNMvvpUyNdoU= 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 3311F13213D; Wed, 30 Aug 2017 08:21:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 SG644yCkb2_w; Wed, 30 Aug 2017 08:21:43 -0700 (PDT) Received: from mx1.bs.ptb.de (mx1.bs.ptb.de [IPv6:2001:638:610:bd01::120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57846132396; Wed, 30 Aug 2017 08:21:42 -0700 (PDT) Received: from smtp-hub.bs.ptb.de (smtpint01.bs.ptb.de [141.25.87.32]) by mx1.bs.ptb.de with ESMTP id v7UFLdEP010410-v7UFLdER010410 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 30 Aug 2017 17:21:39 +0200 Received: from rose.bs.ptb.de (rose.bs.ptb.de [141.25.85.201]) by smtp-hub.bs.ptb.de (Postfix) with ESMTPS id C7F125346B9; Wed, 30 Aug 2017 17:21:39 +0200 (CEST) In-Reply-To: <20170830075331.GN11067@localhost> References: <70a0c971b2978.598d965e@ostfalia.de> <20170830075331.GN11067@localhost> To: Miroslav Lichvar MIME-Version: 1.0 Message-ID: From: dieter.sibold@ptb.de Date: Wed, 30 Aug 2017 17:21:36 +0200 Archived-At: Subject: [Ntp] Antwort: Re: some comments on the NTS4NTP-Draft09 X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: ntp , ntp@ietf.org, Martin Langer , Daniel Franke Content-Type: multipart/mixed; boundary="===============8708031419649445877==" Errors-To: ntp-bounces@ietf.org Sender: "ntp" This is an S/MIME signed message. --===============8708031419649445877== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha-256; boundary=-------z36748_boundary_sign This is an S/MIME signed message. ---------z36748_boundary_sign Content-Type: multipart/alternative; boundary="=_alternative 00546072C125818C_=" Dies ist eine mehrteilige Nachricht im MIME-Format. --=_alternative 00546072C125818C_= Content-Type: text/plain; charset="US-ASCII" I agree with Miroslav. Symmetric packets sizes are also helpful if you want to calibrate dedicated network connection for systematic offsets. Dieter "ntp" schrieb am 30.08.2017 09:53:31: > Von: Miroslav Lichvar > An: Daniel Franke > Kopie: ntp@ietf.org, Martin Langer > Datum: 30.08.2017 09:53 > Betreff: Re: [Ntp] some comments on the NTS4NTP-Draft09 > Gesendet von: "ntp" > > On Tue, Aug 29, 2017 at 02:25:57PM -0400, Daniel Franke wrote: > > On 8/11/17, Martin Langer wrote: > > > Does it really improve the timekeeping? I think the idea is to reduce the > > > asymmetry if the request and response message have the same size. > > > But client and server may have different performance and therefore the > > > processing speed per NTP Package is different too. ...it's just a thought > > > > I'm led to believe Prof. Mills did some experiments at one point and > > found a non-zero impact from using asymmetrically-sized packets. I > > guess a citation here would help. Harlan/Dave, do you know of any > > academic reference I can point at to support this claim? > > If no citation is found, I think it is safe to say that a fundamental > property of most networks is that longer packets take longer to > transmit and receive. NTP assumes that network delay is symmetric, so > the packet size must be symmetric. > > For instance, on 1Gb ethernet the delay should increase by 1 > nanosecond per bit after reaching the minimum frame size. If the size > is asymmetric, the asymmetry in delay will multiply with the number of > transmissions (including all routers and switches not using > cut-through switching) on the path between the client and server. Of > course, this would normally not be the only source of asymmetry and > symmetric size alone doesn't guarantee accurate measurements. > > It is possible to measure the asymmetry. Here is a graph of offset > of a client directly connected to a server on 1Gb ethernet. The clock > was synchronized using symmetric NTP packets. The client also had a > "noselect" association with the server, which had requests longer by > 28 octets (a dummy extension field) than responses. The expected > offset between the two associations is 28 * 8 / 2 = 112 nanoseconds. > > http://i.imgur.com/hCP9rU2.png > > -- > Miroslav Lichvar > > _______________________________________________ > ntp mailing list > ntp@ietf.org > https://www.ietf.org/mailman/listinfo/ntp --=_alternative 00546072C125818C_= Content-Type: text/html; charset="US-ASCII" I agree with Miroslav. Symmetric packets sizes are also helpful if you want to calibrate dedicated network connection for systematic offsets.

Dieter

"ntp" <ntp-bounces@ietf.org> schrieb am 30.08.2017 09:53:31:

> Von: Miroslav Lichvar <mlichvar@redhat.com>
> An: Daniel Franke <dfoxfranke@gmail.com>
> Kopie: ntp@ietf.org, Martin Langer <mart.langer@ostfalia.de>
> Datum: 30.08.2017 09:53
> Betreff: Re: [Ntp] some comments on the NTS4NTP-Draft09
> Gesendet von: "ntp" <ntp-bounces@ietf.org>
>
> On Tue, Aug 29, 2017 at 02:25:57PM -0400, Daniel Franke wrote:
> > On 8/11/17, Martin Langer <mart.langer@ostfalia.de> wrote:
> > > Does it really improve the timekeeping? I think the idea is to reduce the
> > > asymmetry if the request and response message have the same size.
> > > But client and server may have different performance and therefore the
> > > processing speed per NTP Package is different too. ...it's just a thought
> >
> > I'm led to believe Prof. Mills did some experiments at one point and
> > found a non-zero impact from using asymmetrically-sized packets. I
> > guess a citation here would help. Harlan/Dave, do you know of any
> > academic reference I can point at to support this claim?
>
> If no citation is found, I think it is safe to say that a fundamental
> property of most networks is that longer packets take longer to
> transmit and receive. NTP assumes that network delay is symmetric, so
> the packet size must be symmetric.
>
> For instance, on 1Gb ethernet the delay should increase by 1
> nanosecond per bit after reaching the minimum frame size. If the size
> is asymmetric, the asymmetry in delay will multiply with the number of
> transmissions (including all routers and switches not using
> cut-through switching) on the path between the client and server. Of
> course, this would normally not be the only source of asymmetry and
> symmetric size alone doesn't guarantee accurate measurements.
>
> It is possible to measure the asymmetry. Here is a graph of offset
> of a client directly connected to a server on 1Gb ethernet. The clock
> was synchronized using symmetric NTP packets. The client also had a
> "noselect" association with the server, which had requests longer by
> 28 octets (a dummy extension field) than responses. The expected
> offset between the two associations is 28 * 8 / 2 = 112 nanoseconds.
>
> http://i.imgur.com/hCP9rU2.png
>
> --
> Miroslav Lichvar
>
> _______________________________________________
> ntp mailing list
> ntp@ietf.org
> https://www.ietf.org/mailman/listinfo/ntp
 --=_alternative 00546072C125818C_=-- ---------z36748_boundary_sign Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIIp0gIBATEPMA0GCWCGSAFlAwQCAQUAMAsGCSqGSIb3DQEHAaCCJsYw ggOfMIICh6ADAgECAgEmMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNE ZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYD VQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw05OTA3MDkxMjExMDBaFw0xOTA3MDky MzU5MDBaMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYD VQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJv b3QgQ0EgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKsLozXgiykUsRSFrzwQ5Dlv NV1Krt3qYY2VSfRvZKMaYGakqUAihNnUpeV4kw5oAa25TVw6ztO4qEJA38+juoJZapIbrBya2ggr JSf5aSNH8eDrLHqb9RMC0H40fMKePABZq/XaDPUyPCusUNrWw96DlMqoDJkyDghIVltq+9rhWFgB SV9yQTwVBgGOXa2quJO0zZ7rp+hqLVI02zrvXHVR2tvzMfnucZgyxFQVRAz5m1Xtrd8YCKCjhopJ 7lMFjxlM1d5YeZvSahxCq8XVp89oD5bk4WGYdmHIkXzWPgDikVCH4Z0K5q2X0h3GOn3LvNoDNNWO WwH1age3FrZuSn8CAwEAAaNCMEAwHQYDVR0OBBYEFDHDeRu69VPXF+CJei0XbAqzK50zMA8GA1Ud EwQIMAYBAf8CAQUwDgYDVR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBBQUAA4IBAQCUZFmtOWTnKesT /lrDixNXyAQk8HR3wGDjZ/vpiaaDv5aCfG7Uwz3vnoBuuym0mHqxO1TrORdHfhqOC/wfMVkxBLLO F/Msx2I2VeIi2IlVtJhIqmT61hw22ER4WlojOleX9XowT66fakxLK46gA+M+4KnU0nvSs6jicjyt nv+AWeSbRbT2O7DNORmYMuXqIWGQ5DEhjjSx9y81SoUQ2ueKNyG+WWPg8oWIMVPUVBSFcHn0LgZ3 J3UvH7iK+f7Futg25IPs52W3v2Na80avgZQ31EGM1iPWHs/1aBtEY6Jauqc1WaHlcAWbDiNXmZQK bbo5YyiGkvMYhNj70c8FVmRXMIIDnzCCAoegAwIBAgIBJjANBgkqhkiG9w0BAQUFADBxMQswCQYD VQQGEwJERTEcMBoGA1UEChMTRGV1dHNjaGUgVGVsZWtvbSBBRzEfMB0GA1UECxMWVC1UZWxlU2Vj IFRydXN0IENlbnRlcjEjMCEGA1UEAxMaRGV1dHNjaGUgVGVsZWtvbSBSb290IENBIDIwHhcNOTkw NzA5MTIxMTAwWhcNMTkwNzA5MjM1OTAwWjBxMQswCQYDVQQGEwJERTEcMBoGA1UEChMTRGV1dHNj aGUgVGVsZWtvbSBBRzEfMB0GA1UECxMWVC1UZWxlU2VjIFRydXN0IENlbnRlcjEjMCEGA1UEAxMa RGV1dHNjaGUgVGVsZWtvbSBSb290IENBIDIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCrC6M14IspFLEUha88EOQ5bzVdSq7d6mGNlUn0b2SjGmBmpKlAIoTZ1KXleJMOaAGtuU1cOs7T uKhCQN/Po7qCWWqSG6wcmtoIKyUn+WkjR/Hg6yx6m/UTAtB+NHzCnjwAWav12gz1MjwrrFDa1sPe g5TKqAyZMg4ISFZbavva4VhYAUlfckE8FQYBjl2tqriTtM2e66foai1SNNs671x1Udrb8zH57nGY MsRUFUQM+ZtV7a3fGAigo4aKSe5TBY8ZTNXeWHmb0mocQqvF1afPaA+W5OFhmHZhyJF81j4A4pFQ h+GdCuatl9Idxjp9y7zaAzTVjlsB9WoHtxa2bkp/AgMBAAGjQjBAMB0GA1UdDgQWBBQxw3kbuvVT 1xfgiXotF2wKsyudMzAPBgNVHRMECDAGAQH/AgEFMA4GA1UdDwEB/wQEAwIBBjANBgkqhkiG9w0B AQUFAAOCAQEAlGRZrTlk5ynrE/5aw4sTV8gEJPB0d8Bg42f76Ymmg7+Wgnxu1MM9756AbrsptJh6 sTtU6zkXR34ajgv8HzFZMQSyzhfzLMdiNlXiItiJVbSYSKpk+tYcNthEeFpaIzpXl/V6ME+un2pM SyuOoAPjPuCp1NJ70rOo4nI8rZ7/gFnkm0W09juwzTkZmDLl6iFhkOQxIY40sfcvNUqFENrnijch vllj4PKFiDFT1FQUhXB59C4Gdyd1Lx+4ivn+xbrYNuSD7Odlt79jWvNGr4GUN9RBjNYj1h7P9Wgb RGOiWrqnNVmh5XAFmw4jV5mUCm26OWMohpLzGITY+9HPBVZkVzCCBNUwggO9oAMCAQICCFBOxvU9 EbRkMA0GCSqGSIb3DQEBCwUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNEZXV0c2NoZSBUZWxl a29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYDVQQDExpEZXV0c2No ZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0xNDA3MjIxMjA4MjZaFw0xOTA3MDkyMzU5MDBaMFoxCzAJ BgNVBAYTAkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQD ExtERk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U1wBblSJ01CDrNI/W7MAxBAuZgeKmFNJSoCgjhIt0 iQReW+DieMF4yxbLKDU5ey2QRdDtoAB6fL9KDhsAw4bpXCsxEXsM84IkQ4wcOItqaACa7txPeKvS xhObdq3u3ibo7wGvdA/BCaL2a869080UME/15eOkyGKbghoDJzANAmVgTe3RCSMqljVYJ9N2xnG2 kB3E7f81hn1vM7PbD8URwoqDoZRdQWvY0hD1TP3KUazZve+Sg7va64sWVlZDz+HVEz2mHycwzUlU 28kTNJpxdcVs6qcLmPkhnSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjggGGMIIBgjAOBgNVHQ8BAf8E BAMCAQYwHQYDVR0OBBYEFEm3xs/oPR9/6kR7Eyn38QpwPt5kMB8GA1UdIwQYMBaAFDHDeRu69VPX F+CJei0XbAqzK50zMBIGA1UdEwEB/wQIMAYBAf8CAQIwYgYDVR0gBFswWTARBg8rBgEEAYGtIYIs AQEEAgIwEQYPKwYBBAGBrSGCLAEBBAMAMBEGDysGAQQBga0hgiwBAQQDATAPBg0rBgEEAYGtIYIs AQEEMA0GCysGAQQBga0hgiweMD4GA1UdHwQ3MDUwM6AxoC+GLWh0dHA6Ly9wa2kwMzM2LnRlbGVz ZWMuZGUvcmwvRFRfUk9PVF9DQV8yLmNybDB4BggrBgEFBQcBAQRsMGowLAYIKwYBBQUHMAGGIGh0 dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMDoGCCsGAQUFBzAChi5odHRwOi8vcGtpMDMz Ni50ZWxlc2VjLmRlL2NydC9EVF9ST09UX0NBXzIuY2VyMA0GCSqGSIb3DQEBCwUAA4IBAQBjICj9 nCGGcr45Rlk5MiW8qQGbDczKfUGchm0KbiyzE1l1sTOSG2EnFv/DstU1gvuEKgFJvWa7Zi+ywgZd bj9u4wFaW8pDY1yVtuExpx/VB19N5mWCTjL5w3x6S81NXHTuIfJ1AuxSPtLJatOQI25JZzW+f01W pOzML8+3oZeocj7JvEDWWqQIPda8gsO3tzKOsSyOam23NQIZz/U5RFhjpyQAELC7/E6vbi84u6VX ST/YblBvLJeW3B1GmmWJz67M8uXZn1OzPqEvkqnYC8aEHwTG6x7on321e6UC8STFJGMRNMxakyAq eYg6JUKQqWU7fIbTEhUjKfws2sw5W1QXMIIE1TCCA72gAwIBAgIIUE7G9T0RtGQwDQYJKoZIhvcN AQELBQAwcTELMAkGA1UEBhMCREUxHDAaBgNVBAoTE0RldXRzY2hlIFRlbGVrb20gQUcxHzAdBgNV BAsTFlQtVGVsZVNlYyBUcnVzdCBDZW50ZXIxIzAhBgNVBAMTGkRldXRzY2hlIFRlbGVrb20gUm9v dCBDQSAyMB4XDTE0MDcyMjEyMDgyNloXDTE5MDcwOTIzNTkwMFowWjELMAkGA1UEBhMCREUxEzAR BgNVBAoTCkRGTi1WZXJlaW4xEDAOBgNVBAsTB0RGTi1QS0kxJDAiBgNVBAMTG0RGTi1WZXJlaW4g UENBIEdsb2JhbCAtIEcwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOmbw2eF+Q2u 9Y1Uw5ZQNT1i6W5M7ZTXAFuVInTUIOs0j9bswDEEC5mB4qYU0lKgKCOEi3SJBF5b4OJ4wXjLFsso NTl7LZBF0O2gAHp8v0oOGwDDhulcKzERewzzgiRDjBw4i2poAJru3E94q9LGE5t2re7eJujvAa90 D8EJovZrzr3TzRQwT/Xl46TIYpuCGgMnMA0CZWBN7dEJIyqWNVgn03bGcbaQHcTt/zWGfW8zs9sP xRHCioOhlF1Ba9jSEPVM/cpRrNm975KDu9rrixZWVkPP4dUTPaYfJzDNSVTbyRM0mnF1xWzqpwuY +SGdJ68+ozk5SGqMrcmZ+8MS8r0CAwEAAaOCAYYwggGCMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4E FgQUSbfGz+g9H3/qRHsTKffxCnA+3mQwHwYDVR0jBBgwFoAUMcN5G7r1U9cX4Il6LRdsCrMrnTMw EgYDVR0TAQH/BAgwBgEB/wIBAjBiBgNVHSAEWzBZMBEGDysGAQQBga0hgiwBAQQCAjARBg8rBgEE AYGtIYIsAQEEAwAwEQYPKwYBBAGBrSGCLAEBBAMBMA8GDSsGAQQBga0hgiwBAQQwDQYLKwYBBAGB rSGCLB4wPgYDVR0fBDcwNTAzoDGgL4YtaHR0cDovL3BraTAzMzYudGVsZXNlYy5kZS9ybC9EVF9S T09UX0NBXzIuY3JsMHgGCCsGAQUFBwEBBGwwajAsBggrBgEFBQcwAYYgaHR0cDovL29jc3AwMzM2 LnRlbGVzZWMuZGUvb2NzcHIwOgYIKwYBBQUHMAKGLmh0dHA6Ly9wa2kwMzM2LnRlbGVzZWMuZGUv Y3J0L0RUX1JPT1RfQ0FfMi5jZXIwDQYJKoZIhvcNAQELBQADggEBAGMgKP2cIYZyvjlGWTkyJbyp AZsNzMp9QZyGbQpuLLMTWXWxM5IbYScW/8Oy1TWC+4QqAUm9ZrtmL7LCBl1uP27jAVpbykNjXJW2 4TGnH9UHX03mZYJOMvnDfHpLzU1cdO4h8nUC7FI+0slq05AjbklnNb5/TVak7Mwvz7ehl6hyPsm8 QNZapAg91ryCw7e3Mo6xLI5qbbc1AhnP9TlEWGOnJAAQsLv8Tq9uLzi7pVdJP9huUG8sl5bcHUaa ZYnPrszy5dmfU7M+oS+SqdgLxoQfBMbrHuiffbV7pQLxJMUkYxE0zFqTICp5iDolQpCpZTt8htMS FSMp/CzazDlbVBcwggU9MIIEJaADAgECAgcXr/adVkv+MA0GCSqGSIb3DQEBCwUAMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtE Rk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwHhcNMTQwNjA1MTQwNTAyWhcNMTkwNzA5MjM1OTAw WjBpMQswCQYDVQQGEwJERTEuMCwGA1UEChMlUGh5c2lrYWxpc2NoLVRlY2huaXNjaGUgQnVuZGVz YW5zdGFsdDEPMA0GA1UEAxMGUFRCIENBMRkwFwYJKoZIhvcNAQkBFgpwa2lAcHRiLmRlMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvArCgzkqw2LMAYuU38VJTgyGBC+Pp+uvw52LmtI6 MEMiFr0xY6SEzYcDG3z5NSohZisdnL7bu8Ee7MFD3TZX1jVBie//UNAJqXbHnUzE8hbJYCR5ydb9 WqIzoT5PzG07qJWblbidcrZVcCQEef9V1CaRyfXuqiSTOgibqODLP98N7jMIImz2ipUgMdoGyOgS h/qds5SM6CUgwMeuJ42QpYNot9ri1IKAweyhIIa3TANsu56scy+Fc2+XWOfsuImeeLcaiu6HJPk6 X55QT+kWaAoQf6qJyJXv8b/n6l1nmTIU2AY2B5EnO/rIT+DW+MJy77/HO+7rtwaznuntXMgytwID AQABo4IB9zCCAfMwEgYDVR0TAQH/BAgwBgEB/wIBATAOBgNVHQ8BAf8EBAMCAQYwEQYDVR0gBAow CDAGBgRVHSAAMB0GA1UdDgQWBBTEgNBuKBVoMVrscF94juEwQzjqNDAfBgNVHSMEGDAWgBRJt8bP 6D0ff+pEexMp9/EKcD7eZDAVBgNVHREEDjAMgQpwa2lAcHRiLmRlMIGIBgNVHR8EgYAwfjA9oDug OYY3aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY3JsL2NhY3JsLmNy bDA9oDugOYY3aHR0cDovL2NkcDIucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY3JsL2Nh Y3JsLmNybDCB1wYIKwYBBQUHAQEEgcowgccwMwYIKwYBBQUHMAGGJ2h0dHA6Ly9vY3NwLnBjYS5k Zm4uZGUvT0NTUC1TZXJ2ZXIvT0NTUDBHBggrBgEFBQcwAoY7aHR0cDovL2NkcDEucGNhLmRmbi5k ZS9nbG9iYWwtcm9vdC1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwRwYIKwYBBQUHMAKGO2h0dHA6 Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MA0G CSqGSIb3DQEBCwUAA4IBAQCo3hebMpEocLPJTOlDMAmSzpxK3SA1ftaQqodbMncOi9WkeICQlmIv rQxGCq8Be/6hKtIrbFOhRtSzQi870glJRj7dhZaHC+WOgT5tP5Nkgwpgl4k4pQDXPPrwmaI6cSYD a/LpprQzBNjEQMdQqkeanpD0WU9U1pOPFIMfIrxh2cy8mBpIAMuZqMHbMyPNDZk/YN4r3b2DcBrQ wL/tHerp6Vc7n9WqO+3cm7Fa4AxL9q2KeItyYe0Cws2KZNz4IuiMjQAclNL0PhTEqIzkD/EiK6Ag 1qcH7o3ktpmakvL2RzSZA71irCfONRgh/+ixfuMu6YA5uzyA8SYfwyFQcABdMIIFPTCCBCWgAwIB AgIHF6/2nVZL/jANBgkqhkiG9w0BAQsFADBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZOLVZl cmVpbjEQMA4GA1UECxMHREZOLVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xvYmFsIC0g RzAxMB4XDTE0MDYwNTE0MDUwMloXDTE5MDcwOTIzNTkwMFowaTELMAkGA1UEBhMCREUxLjAsBgNV BAoTJVBoeXNpa2FsaXNjaC1UZWNobmlzY2hlIEJ1bmRlc2Fuc3RhbHQxDzANBgNVBAMTBlBUQiBD QTEZMBcGCSqGSIb3DQEJARYKcGtpQHB0Yi5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALwKwoM5KsNizAGLlN/FSU4MhgQvj6frr8Odi5rSOjBDIha9MWOkhM2HAxt8+TUqIWYrHZy+ 27vBHuzBQ902V9Y1QYnv/1DQCal2x51MxPIWyWAkecnW/VqiM6E+T8xtO6iVm5W4nXK2VXAkBHn/ VdQmkcn17qokkzoIm6jgyz/fDe4zCCJs9oqVIDHaBsjoEof6nbOUjOglIMDHrieNkKWDaLfa4tSC gMHsoSCGt0wDbLuerHMvhXNvl1jn7LiJnni3GoruhyT5Ol+eUE/pFmgKEH+qiciV7/G/5+pdZ5ky FNgGNgeRJzv6yE/g1vjCcu+/xzvu67cGs57p7VzIMrcCAwEAAaOCAfcwggHzMBIGA1UdEwEB/wQI MAYBAf8CAQEwDgYDVR0PAQH/BAQDAgEGMBEGA1UdIAQKMAgwBgYEVR0gADAdBgNVHQ4EFgQUxIDQ bigVaDFa7HBfeI7hMEM46jQwHwYDVR0jBBgwFoAUSbfGz+g9H3/qRHsTKffxCnA+3mQwFQYDVR0R BA4wDIEKcGtpQHB0Yi5kZTCBiAYDVR0fBIGAMH4wPaA7oDmGN2h0dHA6Ly9jZHAxLnBjYS5kZm4u ZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NybC9jYWNybC5jcmwwPaA7oDmGN2h0dHA6Ly9jZHAyLnBj YS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NybC9jYWNybC5jcmwwgdcGCCsGAQUFBwEBBIHK MIHHMDMGCCsGAQUFBzABhidodHRwOi8vb2NzcC5wY2EuZGZuLmRlL09DU1AtU2VydmVyL09DU1Aw RwYIKwYBBQUHMAKGO2h0dHA6Ly9jZHAxLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2Nh Y2VydC9jYWNlcnQuY3J0MEcGCCsGAQUFBzAChjtodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2dsb2Jh bC1yb290LWNhL3B1Yi9jYWNlcnQvY2FjZXJ0LmNydDANBgkqhkiG9w0BAQsFAAOCAQEAqN4XmzKR KHCzyUzpQzAJks6cSt0gNX7WkKqHWzJ3DovVpHiAkJZiL60MRgqvAXv+oSrSK2xToUbUs0IvO9IJ SUY+3YWWhwvljoE+bT+TZIMKYJeJOKUA1zz68JmiOnEmA2vy6aa0MwTYxEDHUKpHmp6Q9FlPVNaT jxSDHyK8YdnMvJgaSADLmajB2zMjzQ2ZP2DeK929g3Aa0MC/7R3q6elXO5/Vqjvt3JuxWuAMS/at iniLcmHtAsLNimTc+CLojI0AHJTS9D4UxKiM5A/xIiugINanB+6N5LaZmpLy9kc0mQO9YqwnzjUY If/osX7jLumAObs8gPEmH8MhUHAAXTCCBaIwggSKoAMCAQICDBxmO6qdufc5yhZ6iDANBgkqhkiG 9w0BAQsFADBpMQswCQYDVQQGEwJERTEuMCwGA1UEChMlUGh5c2lrYWxpc2NoLVRlY2huaXNjaGUg QnVuZGVzYW5zdGFsdDEPMA0GA1UEAxMGUFRCIENBMRkwFwYJKoZIhvcNAQkBFgpwa2lAcHRiLmRl MB4XDTE2MTIwNjEzMzMxNFoXDTE5MDcwOTIzNTkwMFowaDELMAkGA1UEBhMCREUxLjAsBgNVBAoM JVBoeXNpa2FsaXNjaC1UZWNobmlzY2hlIEJ1bmRlc2Fuc3RhbHQxDTALBgNVBAsMBFEuNDIxGjAY BgNVBAMMEURyLiBEaWV0ZXIgU2lib2xkMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA +AOQrmrEQ2k8s9su/TVvmdF46YbL2MuF6OvnrjjKaJIkBvchop87cCwv80aZEbmU3as54egQEMGn NFkp1fF4bics4TJdEpND116l+jbi5DCtA3hHP/spV1aQZBDc/BDkm1Nl5WYKh/DxN6sUhZxorbb4 Y0nmSxnK2ctIwuF4Qdibsw7GE2YLvWF4tlzSCGbDjSy2agSn1wYHMsC+tAcFflcMXF2sDMZHkYuq 5IHwng8GBQFhsldYl1fk2sB2/hVRLYU205qaj13H94WjfDLuB22sT17XPJ2U/9tuFN/sxAPR0/N4 y4/IgMnOaP30VU0FMmULd7qJg0WST5D5kwgMhwIDAQABo4ICSTCCAkUwQAYDVR0gBDkwNzARBg8r BgEEAYGtIYIsAQEEAwUwEQYPKwYBBAGBrSGCLAIBBAMBMA8GDSsGAQQBga0hgiwBAQQwCQYDVR0T BAIwADAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1Ud DgQWBBQHn42zKDpvJi1bsJ4OVk2A9liUFjAfBgNVHSMEGDAWgBTEgNBuKBVoMVrscF94juEwQzjq NDBEBgNVHREEPTA7gRRkaWV0ZXIuc2lib2xkQHB0Yi5kZaAjBgorBgEEAYI3FAIDoBUME3NpYm9s ZDAxQHBhZC5wdGIuZGUwdwYDVR0fBHAwbjA1oDOgMYYvaHR0cDovL2NkcDEucGNhLmRmbi5kZS9w dGItY2EvcHViL2NybC9jYWNybC5jcmwwNaAzoDGGL2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvcHRi LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIHHBggrBgEFBQcBAQSBujCBtzAzBggrBgEFBQcwAYYnaHR0 cDovL29jc3AucGNhLmRmbi5kZS9PQ1NQLVNlcnZlci9PQ1NQMD8GCCsGAQUFBzAChjNodHRwOi8v Y2RwMS5wY2EuZGZuLmRlL3B0Yi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwPwYIKwYBBQUHMAKG M2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvcHRiLWNhL3B1Yi9jYWNlcnQvY2FjZXJ0LmNydDANBgkq hkiG9w0BAQsFAAOCAQEADaSfgrrQZx9eiQrCK7kgJMpLstro5OgIcWSpW4i4AQ1wEwyDUrdB1XWK GjA8/KwExSBP9a+dcdW+ACjX7TyURQPLqRTOkoPc9dafRx327mV4K8PE8z7fg5l2ittYNs0nXlOB QevRbYYP4XUOMYohFWfHpDwEg3ExmoArb2HaQCzKhq/2VcIIXTwaN6AVr2NVKEuH3qwpgOUSlJJ1 5ORb6TD4p1G2W6XT3jk3tOa8nRaOkI5hqpPvLfbPEibn+Bfqm6GWqpXfQ6NLAvWYcI8ltSKgdnCw Rmqdh1Ba/KWGdm41PDtQIx58vgbZGfN5GKJrp+OwS5D+/e/r296qoKUBRDCCBaIwggSKoAMCAQIC DBxmO6qdufc5yhZ6iDANBgkqhkiG9w0BAQsFADBpMQswCQYDVQQGEwJERTEuMCwGA1UEChMlUGh5 c2lrYWxpc2NoLVRlY2huaXNjaGUgQnVuZGVzYW5zdGFsdDEPMA0GA1UEAxMGUFRCIENBMRkwFwYJ KoZIhvcNAQkBFgpwa2lAcHRiLmRlMB4XDTE2MTIwNjEzMzMxNFoXDTE5MDcwOTIzNTkwMFowaDEL MAkGA1UEBhMCREUxLjAsBgNVBAoMJVBoeXNpa2FsaXNjaC1UZWNobmlzY2hlIEJ1bmRlc2Fuc3Rh bHQxDTALBgNVBAsMBFEuNDIxGjAYBgNVBAMMEURyLiBEaWV0ZXIgU2lib2xkMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA+AOQrmrEQ2k8s9su/TVvmdF46YbL2MuF6OvnrjjKaJIkBvch op87cCwv80aZEbmU3as54egQEMGnNFkp1fF4bics4TJdEpND116l+jbi5DCtA3hHP/spV1aQZBDc /BDkm1Nl5WYKh/DxN6sUhZxorbb4Y0nmSxnK2ctIwuF4Qdibsw7GE2YLvWF4tlzSCGbDjSy2agSn 1wYHMsC+tAcFflcMXF2sDMZHkYuq5IHwng8GBQFhsldYl1fk2sB2/hVRLYU205qaj13H94WjfDLu B22sT17XPJ2U/9tuFN/sxAPR0/N4y4/IgMnOaP30VU0FMmULd7qJg0WST5D5kwgMhwIDAQABo4IC STCCAkUwQAYDVR0gBDkwNzARBg8rBgEEAYGtIYIsAQEEAwUwEQYPKwYBBAGBrSGCLAIBBAMBMA8G DSsGAQQBga0hgiwBAQQwCQYDVR0TBAIwADAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYB BQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQHn42zKDpvJi1bsJ4OVk2A9liUFjAfBgNVHSMEGDAW gBTEgNBuKBVoMVrscF94juEwQzjqNDBEBgNVHREEPTA7gRRkaWV0ZXIuc2lib2xkQHB0Yi5kZaAj BgorBgEEAYI3FAIDoBUME3NpYm9sZDAxQHBhZC5wdGIuZGUwdwYDVR0fBHAwbjA1oDOgMYYvaHR0 cDovL2NkcDEucGNhLmRmbi5kZS9wdGItY2EvcHViL2NybC9jYWNybC5jcmwwNaAzoDGGL2h0dHA6 Ly9jZHAyLnBjYS5kZm4uZGUvcHRiLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIHHBggrBgEFBQcBAQSB ujCBtzAzBggrBgEFBQcwAYYnaHR0cDovL29jc3AucGNhLmRmbi5kZS9PQ1NQLVNlcnZlci9PQ1NQ MD8GCCsGAQUFBzAChjNodHRwOi8vY2RwMS5wY2EuZGZuLmRlL3B0Yi1jYS9wdWIvY2FjZXJ0L2Nh Y2VydC5jcnQwPwYIKwYBBQUHMAKGM2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvcHRiLWNhL3B1Yi9j YWNlcnQvY2FjZXJ0LmNydDANBgkqhkiG9w0BAQsFAAOCAQEADaSfgrrQZx9eiQrCK7kgJMpLstro 5OgIcWSpW4i4AQ1wEwyDUrdB1XWKGjA8/KwExSBP9a+dcdW+ACjX7TyURQPLqRTOkoPc9dafRx32 7mV4K8PE8z7fg5l2ittYNs0nXlOBQevRbYYP4XUOMYohFWfHpDwEg3ExmoArb2HaQCzKhq/2VcII XTwaN6AVr2NVKEuH3qwpgOUSlJJ15ORb6TD4p1G2W6XT3jk3tOa8nRaOkI5hqpPvLfbPEibn+Bfq m6GWqpXfQ6NLAvWYcI8ltSKgdnCwRmqdh1Ba/KWGdm41PDtQIx58vgbZGfN5GKJrp+OwS5D+/e/r 296qoKUBRDGCAuMwggLfAgEBMHkwaTELMAkGA1UEBhMCREUxLjAsBgNVBAoTJVBoeXNpa2FsaXNj aC1UZWNobmlzY2hlIEJ1bmRlc2Fuc3RhbHQxDzANBgNVBAMTBlBUQiBDQTEZMBcGCSqGSIb3DQEJ ARYKcGtpQHB0Yi5kZQIMHGY7qp259znKFnqIMA0GCWCGSAFlAwQCAQUAoIIBOzAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzA4MzAxNTIxMzdaMC8GCSqGSIb3DQEJ BDEiBCAmCK6US8R1utt+E4qm2bcqPs6fXRc3lnFtd7ZVoSBVgzBDBgkqhkiG9w0BCQ8xNjA0MAcG BSsOAwIdMA4GCCqGSIb3DQMCAgIAgDAKBggqhkiG9w0DBzANBggqhkiG9w0DAgIBKDCBigYLKoZI hvcNAQkQAgsxe6B5MGkxCzAJBgNVBAYTAkRFMS4wLAYDVQQKEyVQaHlzaWthbGlzY2gtVGVjaG5p c2NoZSBCdW5kZXNhbnN0YWx0MQ8wDQYDVQQDEwZQVEIgQ0ExGTAXBgkqhkiG9w0BCQEWCnBraUBw dGIuZGUCDBxmO6qdufc5yhZ6iDANBgkqhkiG9w0BAQEFAASCAQDWvXCj6gq66cD7fD3CqfaJPtvK pPD+X94eU2T95v2BD2Vk05ScSpC/rpW3H8I1aKZpYehoPNe5xTYRa14xKvUVWjOIzDS1H2gjXsrw OQ7BGDGWctTKNYOk968ekWVlth0Jfc55mGiSGZSIKCZnybRE6TAuSk3yyuaG72Z6OyLdrrZue6Bw t9fZhRhuzKYI1Tb6jCqUkeoPlJqZBJGRtxhkA3fBAPGOC/7ZN1fF+ReVmstOid0xxBw3c3LOXNAs 6d0SGmRu4fAS/l9w8n9QwLNoKtgyU49Cnghh+v0z/YukcngVy+SNUW3FiG7U/lW4VEY00iOyQKxG N1p0ggfByz4YAAAAAA== ---------z36748_boundary_sign-- --===============8708031419649445877== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp --===============8708031419649445877==-- From nobody Wed Aug 30 08:21:53 2017 Return-Path: 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 3311F13213D; Wed, 30 Aug 2017 08:21:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 SG644yCkb2_w; Wed, 30 Aug 2017 08:21:43 -0700 (PDT) Received: from mx1.bs.ptb.de (mx1.bs.ptb.de [IPv6:2001:638:610:bd01::120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57846132396; Wed, 30 Aug 2017 08:21:42 -0700 (PDT) Received: from smtp-hub.bs.ptb.de (smtpint01.bs.ptb.de [141.25.87.32]) by mx1.bs.ptb.de with ESMTP id v7UFLdEP010410-v7UFLdER010410 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 30 Aug 2017 17:21:39 +0200 Received: from rose.bs.ptb.de (rose.bs.ptb.de [141.25.85.201]) by smtp-hub.bs.ptb.de (Postfix) with ESMTPS id C7F125346B9; Wed, 30 Aug 2017 17:21:39 +0200 (CEST) In-Reply-To: <20170830075331.GN11067@localhost> References: <70a0c971b2978.598d965e@ostfalia.de> <20170830075331.GN11067@localhost> To: Miroslav Lichvar Cc: Daniel Franke , Martin Langer , ntp@ietf.org, "ntp" MIME-Version: 1.0 Message-ID: From: dieter.sibold@ptb.de Date: Wed, 30 Aug 2017 17:21:36 +0200 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha-256; boundary=-------z36748_boundary_sign Archived-At: Subject: [Ntp] Antwort: Re: some comments on the NTS4NTP-Draft09 X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 15:21:45 -0000 This is an S/MIME signed message. ---------z36748_boundary_sign Content-Type: multipart/alternative; boundary="=_alternative 00546072C125818C_=" Dies ist eine mehrteilige Nachricht im MIME-Format. --=_alternative 00546072C125818C_= Content-Type: text/plain; charset="US-ASCII" I agree with Miroslav. Symmetric packets sizes are also helpful if you want to calibrate dedicated network connection for systematic offsets. Dieter "ntp" schrieb am 30.08.2017 09:53:31: > Von: Miroslav Lichvar > An: Daniel Franke > Kopie: ntp@ietf.org, Martin Langer > Datum: 30.08.2017 09:53 > Betreff: Re: [Ntp] some comments on the NTS4NTP-Draft09 > Gesendet von: "ntp" > > On Tue, Aug 29, 2017 at 02:25:57PM -0400, Daniel Franke wrote: > > On 8/11/17, Martin Langer wrote: > > > Does it really improve the timekeeping? I think the idea is to reduce the > > > asymmetry if the request and response message have the same size. > > > But client and server may have different performance and therefore the > > > processing speed per NTP Package is different too. ...it's just a thought > > > > I'm led to believe Prof. Mills did some experiments at one point and > > found a non-zero impact from using asymmetrically-sized packets. I > > guess a citation here would help. Harlan/Dave, do you know of any > > academic reference I can point at to support this claim? > > If no citation is found, I think it is safe to say that a fundamental > property of most networks is that longer packets take longer to > transmit and receive. NTP assumes that network delay is symmetric, so > the packet size must be symmetric. > > For instance, on 1Gb ethernet the delay should increase by 1 > nanosecond per bit after reaching the minimum frame size. If the size > is asymmetric, the asymmetry in delay will multiply with the number of > transmissions (including all routers and switches not using > cut-through switching) on the path between the client and server. Of > course, this would normally not be the only source of asymmetry and > symmetric size alone doesn't guarantee accurate measurements. > > It is possible to measure the asymmetry. Here is a graph of offset > of a client directly connected to a server on 1Gb ethernet. The clock > was synchronized using symmetric NTP packets. The client also had a > "noselect" association with the server, which had requests longer by > 28 octets (a dummy extension field) than responses. The expected > offset between the two associations is 28 * 8 / 2 = 112 nanoseconds. > > http://i.imgur.com/hCP9rU2.png > > -- > Miroslav Lichvar > > _______________________________________________ > ntp mailing list > ntp@ietf.org > https://www.ietf.org/mailman/listinfo/ntp --=_alternative 00546072C125818C_= Content-Type: text/html; charset="US-ASCII" I agree with Miroslav. Symmetric packets sizes are also helpful if you want to calibrate dedicated network connection for systematic offsets.

Dieter

"ntp" <ntp-bounces@ietf.org> schrieb am 30.08.2017 09:53:31:

> Von: Miroslav Lichvar <mlichvar@redhat.com>
> An: Daniel Franke <dfoxfranke@gmail.com>
> Kopie: ntp@ietf.org, Martin Langer <mart.langer@ostfalia.de>
> Datum: 30.08.2017 09:53
> Betreff: Re: [Ntp] some comments on the NTS4NTP-Draft09
> Gesendet von: "ntp" <ntp-bounces@ietf.org>
>
> On Tue, Aug 29, 2017 at 02:25:57PM -0400, Daniel Franke wrote:
> > On 8/11/17, Martin Langer <mart.langer@ostfalia.de> wrote:
> > > Does it really improve the timekeeping? I think the idea is to reduce the
> > > asymmetry if the request and response message have the same size.
> > > But client and server may have different performance and therefore the
> > > processing speed per NTP Package is different too. ...it's just a thought
> >
> > I'm led to believe Prof. Mills did some experiments at one point and
> > found a non-zero impact from using asymmetrically-sized packets. I
> > guess a citation here would help. Harlan/Dave, do you know of any
> > academic reference I can point at to support this claim?
>
> If no citation is found, I think it is safe to say that a fundamental
> property of most networks is that longer packets take longer to
> transmit and receive. NTP assumes that network delay is symmetric, so
> the packet size must be symmetric.
>
> For instance, on 1Gb ethernet the delay should increase by 1
> nanosecond per bit after reaching the minimum frame size. If the size
> is asymmetric, the asymmetry in delay will multiply with the number of
> transmissions (including all routers and switches not using
> cut-through switching) on the path between the client and server. Of
> course, this would normally not be the only source of asymmetry and
> symmetric size alone doesn't guarantee accurate measurements.
>
> It is possible to measure the asymmetry. Here is a graph of offset
> of a client directly connected to a server on 1Gb ethernet. The clock
> was synchronized using symmetric NTP packets. The client also had a
> "noselect" association with the server, which had requests longer by
> 28 octets (a dummy extension field) than responses. The expected
> offset between the two associations is 28 * 8 / 2 = 112 nanoseconds.
>
> http://i.imgur.com/hCP9rU2.png
>
> --
> Miroslav Lichvar
>
> _______________________________________________
> ntp mailing list
> ntp@ietf.org
> https://www.ietf.org/mailman/listinfo/ntp
 --=_alternative 00546072C125818C_=-- ---------z36748_boundary_sign Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIIp0gIBATEPMA0GCWCGSAFlAwQCAQUAMAsGCSqGSIb3DQEHAaCCJsYw ggOfMIICh6ADAgECAgEmMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNE ZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYD VQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw05OTA3MDkxMjExMDBaFw0xOTA3MDky MzU5MDBaMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYD VQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJv b3QgQ0EgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKsLozXgiykUsRSFrzwQ5Dlv NV1Krt3qYY2VSfRvZKMaYGakqUAihNnUpeV4kw5oAa25TVw6ztO4qEJA38+juoJZapIbrBya2ggr JSf5aSNH8eDrLHqb9RMC0H40fMKePABZq/XaDPUyPCusUNrWw96DlMqoDJkyDghIVltq+9rhWFgB SV9yQTwVBgGOXa2quJO0zZ7rp+hqLVI02zrvXHVR2tvzMfnucZgyxFQVRAz5m1Xtrd8YCKCjhopJ 7lMFjxlM1d5YeZvSahxCq8XVp89oD5bk4WGYdmHIkXzWPgDikVCH4Z0K5q2X0h3GOn3LvNoDNNWO WwH1age3FrZuSn8CAwEAAaNCMEAwHQYDVR0OBBYEFDHDeRu69VPXF+CJei0XbAqzK50zMA8GA1Ud EwQIMAYBAf8CAQUwDgYDVR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBBQUAA4IBAQCUZFmtOWTnKesT /lrDixNXyAQk8HR3wGDjZ/vpiaaDv5aCfG7Uwz3vnoBuuym0mHqxO1TrORdHfhqOC/wfMVkxBLLO F/Msx2I2VeIi2IlVtJhIqmT61hw22ER4WlojOleX9XowT66fakxLK46gA+M+4KnU0nvSs6jicjyt nv+AWeSbRbT2O7DNORmYMuXqIWGQ5DEhjjSx9y81SoUQ2ueKNyG+WWPg8oWIMVPUVBSFcHn0LgZ3 J3UvH7iK+f7Futg25IPs52W3v2Na80avgZQ31EGM1iPWHs/1aBtEY6Jauqc1WaHlcAWbDiNXmZQK bbo5YyiGkvMYhNj70c8FVmRXMIIDnzCCAoegAwIBAgIBJjANBgkqhkiG9w0BAQUFADBxMQswCQYD VQQGEwJERTEcMBoGA1UEChMTRGV1dHNjaGUgVGVsZWtvbSBBRzEfMB0GA1UECxMWVC1UZWxlU2Vj IFRydXN0IENlbnRlcjEjMCEGA1UEAxMaRGV1dHNjaGUgVGVsZWtvbSBSb290IENBIDIwHhcNOTkw NzA5MTIxMTAwWhcNMTkwNzA5MjM1OTAwWjBxMQswCQYDVQQGEwJERTEcMBoGA1UEChMTRGV1dHNj aGUgVGVsZWtvbSBBRzEfMB0GA1UECxMWVC1UZWxlU2VjIFRydXN0IENlbnRlcjEjMCEGA1UEAxMa RGV1dHNjaGUgVGVsZWtvbSBSb290IENBIDIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCrC6M14IspFLEUha88EOQ5bzVdSq7d6mGNlUn0b2SjGmBmpKlAIoTZ1KXleJMOaAGtuU1cOs7T uKhCQN/Po7qCWWqSG6wcmtoIKyUn+WkjR/Hg6yx6m/UTAtB+NHzCnjwAWav12gz1MjwrrFDa1sPe g5TKqAyZMg4ISFZbavva4VhYAUlfckE8FQYBjl2tqriTtM2e66foai1SNNs671x1Udrb8zH57nGY MsRUFUQM+ZtV7a3fGAigo4aKSe5TBY8ZTNXeWHmb0mocQqvF1afPaA+W5OFhmHZhyJF81j4A4pFQ h+GdCuatl9Idxjp9y7zaAzTVjlsB9WoHtxa2bkp/AgMBAAGjQjBAMB0GA1UdDgQWBBQxw3kbuvVT 1xfgiXotF2wKsyudMzAPBgNVHRMECDAGAQH/AgEFMA4GA1UdDwEB/wQEAwIBBjANBgkqhkiG9w0B AQUFAAOCAQEAlGRZrTlk5ynrE/5aw4sTV8gEJPB0d8Bg42f76Ymmg7+Wgnxu1MM9756AbrsptJh6 sTtU6zkXR34ajgv8HzFZMQSyzhfzLMdiNlXiItiJVbSYSKpk+tYcNthEeFpaIzpXl/V6ME+un2pM SyuOoAPjPuCp1NJ70rOo4nI8rZ7/gFnkm0W09juwzTkZmDLl6iFhkOQxIY40sfcvNUqFENrnijch vllj4PKFiDFT1FQUhXB59C4Gdyd1Lx+4ivn+xbrYNuSD7Odlt79jWvNGr4GUN9RBjNYj1h7P9Wgb RGOiWrqnNVmh5XAFmw4jV5mUCm26OWMohpLzGITY+9HPBVZkVzCCBNUwggO9oAMCAQICCFBOxvU9 EbRkMA0GCSqGSIb3DQEBCwUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNEZXV0c2NoZSBUZWxl a29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYDVQQDExpEZXV0c2No ZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0xNDA3MjIxMjA4MjZaFw0xOTA3MDkyMzU5MDBaMFoxCzAJ BgNVBAYTAkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQD ExtERk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U1wBblSJ01CDrNI/W7MAxBAuZgeKmFNJSoCgjhIt0 iQReW+DieMF4yxbLKDU5ey2QRdDtoAB6fL9KDhsAw4bpXCsxEXsM84IkQ4wcOItqaACa7txPeKvS xhObdq3u3ibo7wGvdA/BCaL2a869080UME/15eOkyGKbghoDJzANAmVgTe3RCSMqljVYJ9N2xnG2 kB3E7f81hn1vM7PbD8URwoqDoZRdQWvY0hD1TP3KUazZve+Sg7va64sWVlZDz+HVEz2mHycwzUlU 28kTNJpxdcVs6qcLmPkhnSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjggGGMIIBgjAOBgNVHQ8BAf8E BAMCAQYwHQYDVR0OBBYEFEm3xs/oPR9/6kR7Eyn38QpwPt5kMB8GA1UdIwQYMBaAFDHDeRu69VPX F+CJei0XbAqzK50zMBIGA1UdEwEB/wQIMAYBAf8CAQIwYgYDVR0gBFswWTARBg8rBgEEAYGtIYIs AQEEAgIwEQYPKwYBBAGBrSGCLAEBBAMAMBEGDysGAQQBga0hgiwBAQQDATAPBg0rBgEEAYGtIYIs AQEEMA0GCysGAQQBga0hgiweMD4GA1UdHwQ3MDUwM6AxoC+GLWh0dHA6Ly9wa2kwMzM2LnRlbGVz ZWMuZGUvcmwvRFRfUk9PVF9DQV8yLmNybDB4BggrBgEFBQcBAQRsMGowLAYIKwYBBQUHMAGGIGh0 dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMDoGCCsGAQUFBzAChi5odHRwOi8vcGtpMDMz Ni50ZWxlc2VjLmRlL2NydC9EVF9ST09UX0NBXzIuY2VyMA0GCSqGSIb3DQEBCwUAA4IBAQBjICj9 nCGGcr45Rlk5MiW8qQGbDczKfUGchm0KbiyzE1l1sTOSG2EnFv/DstU1gvuEKgFJvWa7Zi+ywgZd bj9u4wFaW8pDY1yVtuExpx/VB19N5mWCTjL5w3x6S81NXHTuIfJ1AuxSPtLJatOQI25JZzW+f01W pOzML8+3oZeocj7JvEDWWqQIPda8gsO3tzKOsSyOam23NQIZz/U5RFhjpyQAELC7/E6vbi84u6VX ST/YblBvLJeW3B1GmmWJz67M8uXZn1OzPqEvkqnYC8aEHwTG6x7on321e6UC8STFJGMRNMxakyAq eYg6JUKQqWU7fIbTEhUjKfws2sw5W1QXMIIE1TCCA72gAwIBAgIIUE7G9T0RtGQwDQYJKoZIhvcN AQELBQAwcTELMAkGA1UEBhMCREUxHDAaBgNVBAoTE0RldXRzY2hlIFRlbGVrb20gQUcxHzAdBgNV BAsTFlQtVGVsZVNlYyBUcnVzdCBDZW50ZXIxIzAhBgNVBAMTGkRldXRzY2hlIFRlbGVrb20gUm9v dCBDQSAyMB4XDTE0MDcyMjEyMDgyNloXDTE5MDcwOTIzNTkwMFowWjELMAkGA1UEBhMCREUxEzAR BgNVBAoTCkRGTi1WZXJlaW4xEDAOBgNVBAsTB0RGTi1QS0kxJDAiBgNVBAMTG0RGTi1WZXJlaW4g UENBIEdsb2JhbCAtIEcwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOmbw2eF+Q2u 9Y1Uw5ZQNT1i6W5M7ZTXAFuVInTUIOs0j9bswDEEC5mB4qYU0lKgKCOEi3SJBF5b4OJ4wXjLFsso NTl7LZBF0O2gAHp8v0oOGwDDhulcKzERewzzgiRDjBw4i2poAJru3E94q9LGE5t2re7eJujvAa90 D8EJovZrzr3TzRQwT/Xl46TIYpuCGgMnMA0CZWBN7dEJIyqWNVgn03bGcbaQHcTt/zWGfW8zs9sP xRHCioOhlF1Ba9jSEPVM/cpRrNm975KDu9rrixZWVkPP4dUTPaYfJzDNSVTbyRM0mnF1xWzqpwuY +SGdJ68+ozk5SGqMrcmZ+8MS8r0CAwEAAaOCAYYwggGCMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4E FgQUSbfGz+g9H3/qRHsTKffxCnA+3mQwHwYDVR0jBBgwFoAUMcN5G7r1U9cX4Il6LRdsCrMrnTMw EgYDVR0TAQH/BAgwBgEB/wIBAjBiBgNVHSAEWzBZMBEGDysGAQQBga0hgiwBAQQCAjARBg8rBgEE AYGtIYIsAQEEAwAwEQYPKwYBBAGBrSGCLAEBBAMBMA8GDSsGAQQBga0hgiwBAQQwDQYLKwYBBAGB rSGCLB4wPgYDVR0fBDcwNTAzoDGgL4YtaHR0cDovL3BraTAzMzYudGVsZXNlYy5kZS9ybC9EVF9S T09UX0NBXzIuY3JsMHgGCCsGAQUFBwEBBGwwajAsBggrBgEFBQcwAYYgaHR0cDovL29jc3AwMzM2 LnRlbGVzZWMuZGUvb2NzcHIwOgYIKwYBBQUHMAKGLmh0dHA6Ly9wa2kwMzM2LnRlbGVzZWMuZGUv Y3J0L0RUX1JPT1RfQ0FfMi5jZXIwDQYJKoZIhvcNAQELBQADggEBAGMgKP2cIYZyvjlGWTkyJbyp AZsNzMp9QZyGbQpuLLMTWXWxM5IbYScW/8Oy1TWC+4QqAUm9ZrtmL7LCBl1uP27jAVpbykNjXJW2 4TGnH9UHX03mZYJOMvnDfHpLzU1cdO4h8nUC7FI+0slq05AjbklnNb5/TVak7Mwvz7ehl6hyPsm8 QNZapAg91ryCw7e3Mo6xLI5qbbc1AhnP9TlEWGOnJAAQsLv8Tq9uLzi7pVdJP9huUG8sl5bcHUaa ZYnPrszy5dmfU7M+oS+SqdgLxoQfBMbrHuiffbV7pQLxJMUkYxE0zFqTICp5iDolQpCpZTt8htMS FSMp/CzazDlbVBcwggU9MIIEJaADAgECAgcXr/adVkv+MA0GCSqGSIb3DQEBCwUAMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtE Rk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwHhcNMTQwNjA1MTQwNTAyWhcNMTkwNzA5MjM1OTAw WjBpMQswCQYDVQQGEwJERTEuMCwGA1UEChMlUGh5c2lrYWxpc2NoLVRlY2huaXNjaGUgQnVuZGVz YW5zdGFsdDEPMA0GA1UEAxMGUFRCIENBMRkwFwYJKoZIhvcNAQkBFgpwa2lAcHRiLmRlMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvArCgzkqw2LMAYuU38VJTgyGBC+Pp+uvw52LmtI6 MEMiFr0xY6SEzYcDG3z5NSohZisdnL7bu8Ee7MFD3TZX1jVBie//UNAJqXbHnUzE8hbJYCR5ydb9 WqIzoT5PzG07qJWblbidcrZVcCQEef9V1CaRyfXuqiSTOgibqODLP98N7jMIImz2ipUgMdoGyOgS h/qds5SM6CUgwMeuJ42QpYNot9ri1IKAweyhIIa3TANsu56scy+Fc2+XWOfsuImeeLcaiu6HJPk6 X55QT+kWaAoQf6qJyJXv8b/n6l1nmTIU2AY2B5EnO/rIT+DW+MJy77/HO+7rtwaznuntXMgytwID AQABo4IB9zCCAfMwEgYDVR0TAQH/BAgwBgEB/wIBATAOBgNVHQ8BAf8EBAMCAQYwEQYDVR0gBAow CDAGBgRVHSAAMB0GA1UdDgQWBBTEgNBuKBVoMVrscF94juEwQzjqNDAfBgNVHSMEGDAWgBRJt8bP 6D0ff+pEexMp9/EKcD7eZDAVBgNVHREEDjAMgQpwa2lAcHRiLmRlMIGIBgNVHR8EgYAwfjA9oDug OYY3aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY3JsL2NhY3JsLmNy bDA9oDugOYY3aHR0cDovL2NkcDIucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY3JsL2Nh Y3JsLmNybDCB1wYIKwYBBQUHAQEEgcowgccwMwYIKwYBBQUHMAGGJ2h0dHA6Ly9vY3NwLnBjYS5k Zm4uZGUvT0NTUC1TZXJ2ZXIvT0NTUDBHBggrBgEFBQcwAoY7aHR0cDovL2NkcDEucGNhLmRmbi5k ZS9nbG9iYWwtcm9vdC1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwRwYIKwYBBQUHMAKGO2h0dHA6 Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MA0G CSqGSIb3DQEBCwUAA4IBAQCo3hebMpEocLPJTOlDMAmSzpxK3SA1ftaQqodbMncOi9WkeICQlmIv rQxGCq8Be/6hKtIrbFOhRtSzQi870glJRj7dhZaHC+WOgT5tP5Nkgwpgl4k4pQDXPPrwmaI6cSYD a/LpprQzBNjEQMdQqkeanpD0WU9U1pOPFIMfIrxh2cy8mBpIAMuZqMHbMyPNDZk/YN4r3b2DcBrQ wL/tHerp6Vc7n9WqO+3cm7Fa4AxL9q2KeItyYe0Cws2KZNz4IuiMjQAclNL0PhTEqIzkD/EiK6Ag 1qcH7o3ktpmakvL2RzSZA71irCfONRgh/+ixfuMu6YA5uzyA8SYfwyFQcABdMIIFPTCCBCWgAwIB AgIHF6/2nVZL/jANBgkqhkiG9w0BAQsFADBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZOLVZl cmVpbjEQMA4GA1UECxMHREZOLVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xvYmFsIC0g RzAxMB4XDTE0MDYwNTE0MDUwMloXDTE5MDcwOTIzNTkwMFowaTELMAkGA1UEBhMCREUxLjAsBgNV BAoTJVBoeXNpa2FsaXNjaC1UZWNobmlzY2hlIEJ1bmRlc2Fuc3RhbHQxDzANBgNVBAMTBlBUQiBD QTEZMBcGCSqGSIb3DQEJARYKcGtpQHB0Yi5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALwKwoM5KsNizAGLlN/FSU4MhgQvj6frr8Odi5rSOjBDIha9MWOkhM2HAxt8+TUqIWYrHZy+ 27vBHuzBQ902V9Y1QYnv/1DQCal2x51MxPIWyWAkecnW/VqiM6E+T8xtO6iVm5W4nXK2VXAkBHn/ VdQmkcn17qokkzoIm6jgyz/fDe4zCCJs9oqVIDHaBsjoEof6nbOUjOglIMDHrieNkKWDaLfa4tSC gMHsoSCGt0wDbLuerHMvhXNvl1jn7LiJnni3GoruhyT5Ol+eUE/pFmgKEH+qiciV7/G/5+pdZ5ky FNgGNgeRJzv6yE/g1vjCcu+/xzvu67cGs57p7VzIMrcCAwEAAaOCAfcwggHzMBIGA1UdEwEB/wQI MAYBAf8CAQEwDgYDVR0PAQH/BAQDAgEGMBEGA1UdIAQKMAgwBgYEVR0gADAdBgNVHQ4EFgQUxIDQ bigVaDFa7HBfeI7hMEM46jQwHwYDVR0jBBgwFoAUSbfGz+g9H3/qRHsTKffxCnA+3mQwFQYDVR0R BA4wDIEKcGtpQHB0Yi5kZTCBiAYDVR0fBIGAMH4wPaA7oDmGN2h0dHA6Ly9jZHAxLnBjYS5kZm4u ZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NybC9jYWNybC5jcmwwPaA7oDmGN2h0dHA6Ly9jZHAyLnBj YS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NybC9jYWNybC5jcmwwgdcGCCsGAQUFBwEBBIHK MIHHMDMGCCsGAQUFBzABhidodHRwOi8vb2NzcC5wY2EuZGZuLmRlL09DU1AtU2VydmVyL09DU1Aw RwYIKwYBBQUHMAKGO2h0dHA6Ly9jZHAxLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2Nh Y2VydC9jYWNlcnQuY3J0MEcGCCsGAQUFBzAChjtodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2dsb2Jh bC1yb290LWNhL3B1Yi9jYWNlcnQvY2FjZXJ0LmNydDANBgkqhkiG9w0BAQsFAAOCAQEAqN4XmzKR KHCzyUzpQzAJks6cSt0gNX7WkKqHWzJ3DovVpHiAkJZiL60MRgqvAXv+oSrSK2xToUbUs0IvO9IJ SUY+3YWWhwvljoE+bT+TZIMKYJeJOKUA1zz68JmiOnEmA2vy6aa0MwTYxEDHUKpHmp6Q9FlPVNaT jxSDHyK8YdnMvJgaSADLmajB2zMjzQ2ZP2DeK929g3Aa0MC/7R3q6elXO5/Vqjvt3JuxWuAMS/at iniLcmHtAsLNimTc+CLojI0AHJTS9D4UxKiM5A/xIiugINanB+6N5LaZmpLy9kc0mQO9YqwnzjUY If/osX7jLumAObs8gPEmH8MhUHAAXTCCBaIwggSKoAMCAQICDBxmO6qdufc5yhZ6iDANBgkqhkiG 9w0BAQsFADBpMQswCQYDVQQGEwJERTEuMCwGA1UEChMlUGh5c2lrYWxpc2NoLVRlY2huaXNjaGUg QnVuZGVzYW5zdGFsdDEPMA0GA1UEAxMGUFRCIENBMRkwFwYJKoZIhvcNAQkBFgpwa2lAcHRiLmRl MB4XDTE2MTIwNjEzMzMxNFoXDTE5MDcwOTIzNTkwMFowaDELMAkGA1UEBhMCREUxLjAsBgNVBAoM JVBoeXNpa2FsaXNjaC1UZWNobmlzY2hlIEJ1bmRlc2Fuc3RhbHQxDTALBgNVBAsMBFEuNDIxGjAY BgNVBAMMEURyLiBEaWV0ZXIgU2lib2xkMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA +AOQrmrEQ2k8s9su/TVvmdF46YbL2MuF6OvnrjjKaJIkBvchop87cCwv80aZEbmU3as54egQEMGn NFkp1fF4bics4TJdEpND116l+jbi5DCtA3hHP/spV1aQZBDc/BDkm1Nl5WYKh/DxN6sUhZxorbb4 Y0nmSxnK2ctIwuF4Qdibsw7GE2YLvWF4tlzSCGbDjSy2agSn1wYHMsC+tAcFflcMXF2sDMZHkYuq 5IHwng8GBQFhsldYl1fk2sB2/hVRLYU205qaj13H94WjfDLuB22sT17XPJ2U/9tuFN/sxAPR0/N4 y4/IgMnOaP30VU0FMmULd7qJg0WST5D5kwgMhwIDAQABo4ICSTCCAkUwQAYDVR0gBDkwNzARBg8r BgEEAYGtIYIsAQEEAwUwEQYPKwYBBAGBrSGCLAIBBAMBMA8GDSsGAQQBga0hgiwBAQQwCQYDVR0T BAIwADAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1Ud DgQWBBQHn42zKDpvJi1bsJ4OVk2A9liUFjAfBgNVHSMEGDAWgBTEgNBuKBVoMVrscF94juEwQzjq NDBEBgNVHREEPTA7gRRkaWV0ZXIuc2lib2xkQHB0Yi5kZaAjBgorBgEEAYI3FAIDoBUME3NpYm9s ZDAxQHBhZC5wdGIuZGUwdwYDVR0fBHAwbjA1oDOgMYYvaHR0cDovL2NkcDEucGNhLmRmbi5kZS9w dGItY2EvcHViL2NybC9jYWNybC5jcmwwNaAzoDGGL2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvcHRi LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIHHBggrBgEFBQcBAQSBujCBtzAzBggrBgEFBQcwAYYnaHR0 cDovL29jc3AucGNhLmRmbi5kZS9PQ1NQLVNlcnZlci9PQ1NQMD8GCCsGAQUFBzAChjNodHRwOi8v Y2RwMS5wY2EuZGZuLmRlL3B0Yi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwPwYIKwYBBQUHMAKG M2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvcHRiLWNhL3B1Yi9jYWNlcnQvY2FjZXJ0LmNydDANBgkq hkiG9w0BAQsFAAOCAQEADaSfgrrQZx9eiQrCK7kgJMpLstro5OgIcWSpW4i4AQ1wEwyDUrdB1XWK GjA8/KwExSBP9a+dcdW+ACjX7TyURQPLqRTOkoPc9dafRx327mV4K8PE8z7fg5l2ittYNs0nXlOB QevRbYYP4XUOMYohFWfHpDwEg3ExmoArb2HaQCzKhq/2VcIIXTwaN6AVr2NVKEuH3qwpgOUSlJJ1 5ORb6TD4p1G2W6XT3jk3tOa8nRaOkI5hqpPvLfbPEibn+Bfqm6GWqpXfQ6NLAvWYcI8ltSKgdnCw Rmqdh1Ba/KWGdm41PDtQIx58vgbZGfN5GKJrp+OwS5D+/e/r296qoKUBRDCCBaIwggSKoAMCAQIC DBxmO6qdufc5yhZ6iDANBgkqhkiG9w0BAQsFADBpMQswCQYDVQQGEwJERTEuMCwGA1UEChMlUGh5 c2lrYWxpc2NoLVRlY2huaXNjaGUgQnVuZGVzYW5zdGFsdDEPMA0GA1UEAxMGUFRCIENBMRkwFwYJ KoZIhvcNAQkBFgpwa2lAcHRiLmRlMB4XDTE2MTIwNjEzMzMxNFoXDTE5MDcwOTIzNTkwMFowaDEL MAkGA1UEBhMCREUxLjAsBgNVBAoMJVBoeXNpa2FsaXNjaC1UZWNobmlzY2hlIEJ1bmRlc2Fuc3Rh bHQxDTALBgNVBAsMBFEuNDIxGjAYBgNVBAMMEURyLiBEaWV0ZXIgU2lib2xkMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA+AOQrmrEQ2k8s9su/TVvmdF46YbL2MuF6OvnrjjKaJIkBvch op87cCwv80aZEbmU3as54egQEMGnNFkp1fF4bics4TJdEpND116l+jbi5DCtA3hHP/spV1aQZBDc /BDkm1Nl5WYKh/DxN6sUhZxorbb4Y0nmSxnK2ctIwuF4Qdibsw7GE2YLvWF4tlzSCGbDjSy2agSn 1wYHMsC+tAcFflcMXF2sDMZHkYuq5IHwng8GBQFhsldYl1fk2sB2/hVRLYU205qaj13H94WjfDLu B22sT17XPJ2U/9tuFN/sxAPR0/N4y4/IgMnOaP30VU0FMmULd7qJg0WST5D5kwgMhwIDAQABo4IC STCCAkUwQAYDVR0gBDkwNzARBg8rBgEEAYGtIYIsAQEEAwUwEQYPKwYBBAGBrSGCLAIBBAMBMA8G DSsGAQQBga0hgiwBAQQwCQYDVR0TBAIwADAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYB BQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQHn42zKDpvJi1bsJ4OVk2A9liUFjAfBgNVHSMEGDAW gBTEgNBuKBVoMVrscF94juEwQzjqNDBEBgNVHREEPTA7gRRkaWV0ZXIuc2lib2xkQHB0Yi5kZaAj BgorBgEEAYI3FAIDoBUME3NpYm9sZDAxQHBhZC5wdGIuZGUwdwYDVR0fBHAwbjA1oDOgMYYvaHR0 cDovL2NkcDEucGNhLmRmbi5kZS9wdGItY2EvcHViL2NybC9jYWNybC5jcmwwNaAzoDGGL2h0dHA6 Ly9jZHAyLnBjYS5kZm4uZGUvcHRiLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIHHBggrBgEFBQcBAQSB ujCBtzAzBggrBgEFBQcwAYYnaHR0cDovL29jc3AucGNhLmRmbi5kZS9PQ1NQLVNlcnZlci9PQ1NQ MD8GCCsGAQUFBzAChjNodHRwOi8vY2RwMS5wY2EuZGZuLmRlL3B0Yi1jYS9wdWIvY2FjZXJ0L2Nh Y2VydC5jcnQwPwYIKwYBBQUHMAKGM2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvcHRiLWNhL3B1Yi9j YWNlcnQvY2FjZXJ0LmNydDANBgkqhkiG9w0BAQsFAAOCAQEADaSfgrrQZx9eiQrCK7kgJMpLstro 5OgIcWSpW4i4AQ1wEwyDUrdB1XWKGjA8/KwExSBP9a+dcdW+ACjX7TyURQPLqRTOkoPc9dafRx32 7mV4K8PE8z7fg5l2ittYNs0nXlOBQevRbYYP4XUOMYohFWfHpDwEg3ExmoArb2HaQCzKhq/2VcII XTwaN6AVr2NVKEuH3qwpgOUSlJJ15ORb6TD4p1G2W6XT3jk3tOa8nRaOkI5hqpPvLfbPEibn+Bfq m6GWqpXfQ6NLAvWYcI8ltSKgdnCwRmqdh1Ba/KWGdm41PDtQIx58vgbZGfN5GKJrp+OwS5D+/e/r 296qoKUBRDGCAuMwggLfAgEBMHkwaTELMAkGA1UEBhMCREUxLjAsBgNVBAoTJVBoeXNpa2FsaXNj aC1UZWNobmlzY2hlIEJ1bmRlc2Fuc3RhbHQxDzANBgNVBAMTBlBUQiBDQTEZMBcGCSqGSIb3DQEJ ARYKcGtpQHB0Yi5kZQIMHGY7qp259znKFnqIMA0GCWCGSAFlAwQCAQUAoIIBOzAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzA4MzAxNTIxMzdaMC8GCSqGSIb3DQEJ BDEiBCAmCK6US8R1utt+E4qm2bcqPs6fXRc3lnFtd7ZVoSBVgzBDBgkqhkiG9w0BCQ8xNjA0MAcG BSsOAwIdMA4GCCqGSIb3DQMCAgIAgDAKBggqhkiG9w0DBzANBggqhkiG9w0DAgIBKDCBigYLKoZI hvcNAQkQAgsxe6B5MGkxCzAJBgNVBAYTAkRFMS4wLAYDVQQKEyVQaHlzaWthbGlzY2gtVGVjaG5p c2NoZSBCdW5kZXNhbnN0YWx0MQ8wDQYDVQQDEwZQVEIgQ0ExGTAXBgkqhkiG9w0BCQEWCnBraUBw dGIuZGUCDBxmO6qdufc5yhZ6iDANBgkqhkiG9w0BAQEFAASCAQDWvXCj6gq66cD7fD3CqfaJPtvK pPD+X94eU2T95v2BD2Vk05ScSpC/rpW3H8I1aKZpYehoPNe5xTYRa14xKvUVWjOIzDS1H2gjXsrw OQ7BGDGWctTKNYOk968ekWVlth0Jfc55mGiSGZSIKCZnybRE6TAuSk3yyuaG72Z6OyLdrrZue6Bw t9fZhRhuzKYI1Tb6jCqUkeoPlJqZBJGRtxhkA3fBAPGOC/7ZN1fF+ReVmstOid0xxBw3c3LOXNAs 6d0SGmRu4fAS/l9w8n9QwLNoKtgyU49Cnghh+v0z/YukcngVy+SNUW3FiG7U/lW4VEY00iOyQKxG N1p0ggfByz4YAAAAAA== ---------z36748_boundary_sign-- From nobody Wed Aug 30 08:38:27 2017 Return-Path: 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 89A331201F8 for ; Wed, 30 Aug 2017 08:38:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mscc365.onmicrosoft.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 xA2cdTU4rg4o for ; Wed, 30 Aug 2017 08:38:23 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0084.outbound.protection.outlook.com [104.47.42.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E9F5124B18 for ; Wed, 30 Aug 2017 08:38:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mscc365.onmicrosoft.com; s=selector1-microsemi-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=YfxvGHhKt4amRovGmCSFoKc1t5jrmhwMTU8dHYlImTU=; b=IW2cb1iOG8WeuyOlfbc4yNrG3TzG3phVoPpfLr0r5s8QLH/jdfnsTrRbVCnlNZakDPN6SV8zWHam0rlxQOgyNYteMzsAPD8grSbVkEOXuIhMNsNqsh/10nMty0E7K41m6Or1f9lbBokZalIMfFF7bY+bbooTuyKM01kb0eSVk/4= Received: from BN6PR02CA0095.namprd02.prod.outlook.com (10.161.158.36) by CY1PR0201MB1451.namprd02.prod.outlook.com (10.163.139.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.13.10; Wed, 30 Aug 2017 15:38:21 +0000 Received: from BN1BFFO11FD047.protection.gbl (2a01:111:f400:7c10::1:107) by BN6PR02CA0095.outlook.office365.com (2603:10b6:405:60::36) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.13.10 via Frontend Transport; Wed, 30 Aug 2017 15:38:21 +0000 Authentication-Results: spf=pass (sender IP is 208.19.100.20) smtp.mailfrom=microsemi.com; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=microsemi.com; Received-SPF: Pass (protection.outlook.com: domain of microsemi.com designates 208.19.100.20 as permitted sender) receiver=protection.outlook.com; client-ip=208.19.100.20; helo=avsrvexchhts2.microsemi.net; Received: from avsrvexchhts2.microsemi.net (208.19.100.20) by BN1BFFO11FD047.mail.protection.outlook.com (10.58.145.2) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.1341.15 via Frontend Transport; Wed, 30 Aug 2017 15:38:20 +0000 Received: from AVMBX2.microsemi.net (10.100.34.32) by avsrvexchhts2.microsemi.net (10.100.34.106) with Microsoft SMTP Server (TLS) id 14.3.361.1; Wed, 30 Aug 2017 08:38:20 -0700 Received: from AVMBX2.microsemi.net (10.100.34.32) by AVMBX2.microsemi.net (10.100.34.32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1034.26; Wed, 30 Aug 2017 08:38:19 -0700 Received: from SJSRVEXCHHTS1.microsemi.net (10.241.34.105) by AVMBX2.microsemi.net (10.100.34.32) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1034.26 via Frontend Transport; Wed, 30 Aug 2017 08:38:19 -0700 Received: from SJSRVEXCHMBX1.microsemi.net ([fe80::19b5:ac43:d8de:5120]) by sjsrvexchhts1.microsemi.net ([::1]) with mapi id 14.03.0361.001; Wed, 30 Aug 2017 08:38:19 -0700 From: Greg Dowd To: Dieter Sibold , Daniel Franke , "kristof.teichel@ptb.de" CC: "ntp@ietf.org" , Robert Annessi Thread-Topic: [Ntp] Antwort: Re: WGLC for draft-ietf-ntp-using-nts-for-ntp Thread-Index: AQHTIQDYt6BY6EXSKkSxTrxhVNsqhKKddqAA//+S4LA= Date: Wed, 30 Aug 2017 15:38:19 +0000 Message-ID: <8D2BF679AAC7C346848A489074F9F8BFD283080E@sjsrvexchmbx1.microsemi.net> References: <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> <19062708.TpRPKSgBD8@eris> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.241.128.48] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:208.19.100.20; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10009020)(6009001)(39860400002)(2980300002)(438002)(13464003)(24454002)(189002)(199003)(377454003)(53416004)(97756001)(68736007)(33656002)(5660300001)(2950100002)(7696004)(55846006)(39060400002)(106466001)(6306002)(2920100001)(2900100001)(54906002)(9686003)(230783001)(69596002)(54356999)(229853002)(53936002)(50986999)(6246003)(76176999)(189998001)(53546010)(7736002)(305945005)(49446005)(50466002)(2501003)(102836003)(23726003)(356003)(626005)(3846002)(5890100001)(2906002)(72206003)(4326008)(5250100002)(966005)(81156014)(6116002)(86362001)(46406003)(97736004)(93886005)(47776003)(81166006)(8676002)(8746002)(478600001)(8936002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR0201MB1451; H:avsrvexchhts2.microsemi.net; FPR:; SPF:Pass; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BN1BFFO11FD047; 1:zJ7OeA4r3mW1YprOzBj+Z+4lZEa6o4xH60t0iucJ8UMq3FMol8nQOigLOGHpoaPhVTqJko0GzsiF7nT9KNPc08OmSoI+bTrBnzdd+5FJ8RS1M8JgLcvOfU6PY+YiZsaj X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: b4b587bb-7dba-4f28-affe-08d4efbd24c3 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(8251501002)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY1PR0201MB1451; X-Microsoft-Exchange-Diagnostics: 1; CY1PR0201MB1451; 3:hRaO6Lvz1p4sIHOz2WVLEyBTV0UQbgZxWlTe9BvTXexFCidk+8IOr8svPHdHuPlKwaYU1sGqgw05eYJF/p8FWJUmJ/O0unQpBYkDUdp+IszBZbtpjfj4YSYS4wK+0vxmueurzky9AwlaLWEBQDXzrEkWHF9gOhRw8Qsz+mxyHPeqsg9FLksROsX5tMl4vep1jC2ZNBlHdX1rR4AGNciRGPbp6X1ABmRQjs54rd39E9shIlzOwcjhwnioGzGdCNiTT7lfSXstT4r5IsFkPbC32EI3x2x+zVKw7SJZ3/mEFs65P9A25KcDFUfKLZez9Tcf6SWHmWF9rHUVpRca7yBUBDAcXbhTIxvOKKpYFfejPOw=; 25:JYRaOKPgJDKbh71yQwB0X9+7+T51mpPNMP1e0jickPInhlUigwZ6jyvxNlhJiA3gzcnK7MeBZ1tHztj2kHVImWzWNFmCf1DRfhpuVWZEn7aDFFM//OCfB3iuGFqGKeeNTwT7QJraUsoQtJko227Kq69SPz26nvmhNPxApbdP3POGzAh5OHTp+NW4CDhRsA/DtFZk7TKAfKHIHbVFDf/yXICUpSLiM/uuRlRA2qHlNo2Ufw8jA/YzDivRbGxMQiKWGpbDu3HUkej5sqbpDVs4jLH/eEZy0aFmMCVMwRXeLRL5Zvmzr5wDJZ5O8IhRWNVAb7BQTqQpwpeTm+HVfdmJKA== X-MS-TrafficTypeDiagnostic: CY1PR0201MB1451: X-Microsoft-Exchange-Diagnostics: 1; CY1PR0201MB1451; 31:WjldVf9WwzYRqsdtLqUsaaaJ/XgUy5J17juwBSOBIuw4297fSx47387jtL3qRcdSwh/CJP8o+08diNTBP3FWQsbM3pMPwEvDaACpKtCKqxy3T/8dJfCYjSQGWFQ6rP+8PeTbZTGP0OqspUnGCq/B7xyimVXRyeP0tQuqVWAQ3Q00scayzIAiDh0+bEnmNAV9yO4quDtMNXhV0NtoQZiXpFXGffKf20sp4MeMbwvY8qk=; 20:MfHwaPuYGPAVBMGi2xC5gDhOSa2qMjGO3W8nt2qpjYn8bmYPCYPnboEWKqyB2FDQAGKjr9ezrzx8dnnvXzw16OzYdNxPlFHwBQfxKXusis9gQugmqBaDf53Q+u1Tpa8fa88uB7VW93PF9sJ1v1ma/1cYsvXOIds9Yxsw/e+HYcEsBgumpGG9Bba9Br/hfJ8tpGb3HTr/5yWji5PDflDpibK1ZQh+HV//nLpbKnRQ0V0IO+63lfufuybWL08aWKAw8mJxdDWjB3HyKAry6E/XItJTMQ5iS7bEvNTWphm27JWJnT4ujfdoZJ6LmPu9ekHsiY8DLKf/vqZoZbcFJyjeyUFbRqkCaktcCf5hClknyzRpVBR0aezRSSFbE8NorvCQ7thKfdxF0xoCoKuXAbZ75ByqNErvKh2f7v/wP+PAwM0cDrgsacCzLo/uDSzI36tvzKZXhvJzEIVdfg/jV9n6yx+tyJ5+HHwAFxa1rLsAErG/U0lJju/hSXZzab590gPi X-Exchange-Antispam-Report-Test: UriScan:; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(13018025)(13016025)(10201501046)(93006095)(93004095)(3002001)(100000703101)(100105400095)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123562025)(20161123555025)(20161123564025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY1PR0201MB1451; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY1PR0201MB1451; X-Microsoft-Exchange-Diagnostics: 1; CY1PR0201MB1451; 4:EUSGe9MdBryrjeB8XT3v5VE0yeX15tgiZKkMJt+H4ATmngyuJLU4AyaN/SkOhsx8ILyAUA05iepYxYSyaXOplSCK2wpzyVZTq5b0h3cF7y7jf1YVLlvSFHbThul6rcIXj5HnnvZGxt96XWAlOGwFR+ENs4U3/A1+ifMVDHSgbCNVphmRAwiQ6zxVzqpP5BgrObLh8WmJpGQF9QymhuasEE4pVkV0k9XJGxZioX3xolXf4z5l70J/d7pwRTSYKRWK X-Forefront-PRVS: 041517DFAB X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR0201MB1451; 23:cb0ZJvrBvXoUlL20Ttu/qT3FIhRQy9hvLKC9N8T?= =?us-ascii?Q?JpXfMi2G9WZN3/dUrD4mnMDCfQyBVDuJDH12Y33JnBhi6cLtLizYRAZ0/Mcx?= =?us-ascii?Q?XnQwjZLtggyL4wvcC2FRYbq236T+X/omc149J/EIKvuPMODeiV3/mORq8Grr?= =?us-ascii?Q?S0BgTDUZU71jRyd0s0rllzO6dqvGYJaL8iEEheXw2rU1lOg9bj/ksGQVRDEx?= =?us-ascii?Q?IVDdSsfa0Uj6q0s5P6YTBY/L0M/8pz8k///DbtjLznCYzp1jkQN8jCRQaY2H?= =?us-ascii?Q?uniDTk3kvr7ymVXHQox1HyVWLv3H0MM9IHBhavR0b8uFfOV6CDp6cahSJMqI?= =?us-ascii?Q?4XwU5Z6X1ipCyeZli1THYYj6zHPGi8QLXngC+36KcRNcoqouXVhhbpEvr+im?= =?us-ascii?Q?YFDIa5em9ELIHyffHFzzc0kOb//eIw6hO0qpxWudEBTDRVB/g+sdZbpOK03S?= =?us-ascii?Q?0yzK7yOwHzLzaNshWvXK4NK/uTNwQTRDKd/V5TrMArwRRkHx+5p11NyORT0P?= =?us-ascii?Q?8PGomPLGl/psmehge2jC1tDXKn1U8GQfgPjAwKGZA5p7gJBi/VblW9ckHv3v?= =?us-ascii?Q?6UL2o/chRtbTMLluQW69OZbY3npLO54H+w0nrggCufNK+87oYoTAKsqOSoyg?= =?us-ascii?Q?Zqh7PpYgrFYprk6T0rkM5w3iw33K6qyVljXKMKry26A/JqqJYsOOv0oaZcfL?= =?us-ascii?Q?z3HQV5sMqZq05XG1FG2psCpqFDviN7vJTd07IipgU4ybN884nGBjy3u3n5yl?= =?us-ascii?Q?8XxnY0/5GImFEQPOWSmnu4evs0D22xK/ru8+oTAY9fUuBDCgNg7B9GI2eeQN?= =?us-ascii?Q?LMMyZgd1pyiEmrCRGMTTxW+gZEdLpHCMAKODfmCbpt30NtP/CJetx7w4QE1P?= =?us-ascii?Q?UIRO6jKWWX3IcFIubWYltVQXt8rx6AsJL7+N2w+IDKh7uZZN5yJ0HcBovrtG?= =?us-ascii?Q?+tPnmpPQxLgQuDDFRM5cL5bbx8V0XjHVgiXEePB8LVljyfWyMAqLVw3o5mnv?= =?us-ascii?Q?m5TP0j79eISuymRiODG5Ub8kUqY4W+spJ2OFbWzhAuczS2MRjoquc4QaAHSR?= =?us-ascii?Q?zU+fTCKu+S1gUmSr6HwCJ9cKb4pvN8gdG9k4SJpBt77xjgFRD++L7LO/sD0w?= =?us-ascii?Q?oZwtLeD7h8LG9jXr+a0dZuk3b6LTYtTAHnSzliazPZBpOeCuNk+gZusv++O6?= =?us-ascii?Q?bbMZxiCpC3N4S6V7HggRCfRKOM+OtlpLAhAqy0ZJaL7SRN576CGbSpkFZ3k4?= =?us-ascii?Q?RFsDnx4PuJmxf3OqJaKwt5XWPRtbgZC79jQT808Wtklx9xEkVTY2M+Rd2U+Q?= =?us-ascii?Q?Z2uFVP/mxGolIh4YNtUQ0KH/f3WVeLO9CIWhR2dXQs4BgnFGyWm1bzCoA3pK?= =?us-ascii?Q?6imHH+V9QZjaqyfSZEmAukm6lPe8WJVh74o2o25sY/APE5BxjdjzXLpfHYv2?= =?us-ascii?Q?vo4k78hRJxXtWWwEipZFkAwoOTrXqcKE=3D?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR0201MB1451; 6:8XaHQTSQYnk491Hk0DUhDNDjHh7oEIIZca3PPzm0tpeM1E0UOrShGyFtcvGh/Y5nByA2/64m7QoCEJS1QTu/DXknGZRp6/IhbnOnbW4JSjjem4TFCr7yIsIj4E53rmPvq+HjSIMt9DQz7O0tksGVOkAk58pVK3sUrz845DIoZ8QZsAIRwQ9fzVhCawCTSFXyA8X5X2UK/A4qEbXfY0FT799PeKNTa8NCiFOSFaA7292fOBX5u94eA5dFJT3df9sdXY6Qn4iUwNCeENt3vW5dEozpybw/4zc7pjhUjLt1oxxEhDNlntPS+m1bl/lMNRsuTWdw7KFopt9MdnZL38wgtw==; 5:DnEFxUbj20F0KLnSwwdmp+g6wTf+4oPmc88gh1/AFBHy3ffewQFCQSDJr7zjzl/nEgFWgQaJTVctPdUm6Qkpw4zwJZJZL2jUmNmOqheqApFmiO8mTfFb7qojlB1hDG+nGIeVVxUHPq80JeBj3UKKdw==; 24:de9pzyduvrbaedB9coan8FqF6Pdj139CJY4rjsq7B9nXEx5H1dX1zKFOmpnySSk8+BqMWTeAWgqSicQ9MvWXGZa8GWvsnWkE0eTbz9Duh4A=; 7:LBN5QkqZ4pq8lLtF2viOlNOkTQqHGq+wXx/Ug01YgsiPG/WW1yPgUnvH9uwenWrQNMLi5b55wZWiHbqwFA9ATMTiEE4lpF6aFiUKrDSeDtcuKo/6WYAs44wi0Yjf8DL3R6l9aAEBj2WF2jbx8l1wb5jhYqGuhyZxhhgdD3ULZwvW7Q4V9foU6YtTnpfS60P6KLRrwe0qCNqmS0twX4Ggve3/iilFVI4xr82awUNDCrE= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: microsemi.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Aug 2017 15:38:20.7312 (UTC) X-MS-Exchange-CrossTenant-Id: f267a5c8-86d8-4cc9-af71-1fd2c67c8fad X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f267a5c8-86d8-4cc9-af71-1fd2c67c8fad; Ip=[208.19.100.20]; Helo=[avsrvexchhts2.microsemi.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0201MB1451 Archived-At: Subject: Re: [Ntp] Antwort: Re: WGLC for draft-ietf-ntp-using-nts-for-ntp X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 15:38:26 -0000 While I don't profess to know anything about the mapping of NTS to PTP, I w= ould note that the telecom industry does use unicast flows for synchronizat= ion (PTP Profiles G.8265.1 for frequency and G.8275.2 for phase/tod). =20 -----Original Message----- From: ntp [mailto:ntp-bounces@ietf.org] On Behalf Of Dieter Sibold Sent: Wednesday, August 30, 2017 8:07 AM To: Daniel Franke ; kristof.teichel@ptb.de Cc: ntp@ietf.org; Robert Annessi Subject: Re: [Ntp] Antwort: Re: WGLC for draft-ietf-ntp-using-nts-for-ntp EXTERNAL EMAIL As Robert pointed out with the lack of broadcast support we cannot protect = PTP's timing messages. The only input of this draft to PTP could be the key= exchange. Therefore, I also agree to drop PTP from this draft. Dieter -----Original Message----- From: ntp [mailto:ntp-bounces@ietf.org] On Behalf Of Daniel Franke Sent: Tuesday, August 29, 2017 9:56 PM To: kristof.teichel@ptb.de Cc: ntp@ietf.org; Robert Annessi Subject: Re: [Ntp] Antwort: Re: WGLC for draft-ietf-ntp-using-nts-for-ntp On 8/29/17, kristof.teichel@ptb.de wrote: > I knew there was something that I had wanted to contribute to the=20 > discussion for a long time but just kind of forgotten. > This was it. > > I agree that this is a problem in the text, and I vote for taking out=20 > all passages that specifically mention PTP in this context. Well, you're the reason I had it there to begin with. I thought you and Die= ter still had ambitions to get something working wrt PTP. If that's no long= er the case then, without objection, I'll remove that reference from the in= tro. Besides the Terms and Abbreviations appendix, the only other reference to P= TP is an IANA request to reserve NTS Next Protocol code 1 for use with PTP.= Since we changed these codes from textual to numeric I guess there's no re= ason to keep that either; we can always request a new allocation once there= 's something concrete to attach to it. _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp From ntp-bounces@ietf.org Wed Aug 30 08:38:28 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D2416124B18; Wed, 30 Aug 2017 08:38:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1504107507; bh=Y0C1z0AphTgzcdmI1qPuBIdbwQj87jANIxoNkt10NRA=; h=From:To:Date:References:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc; b=JP5u1qpBxmDNZlWn91fMow3Pxp/NHqLXOWKlcON3bttmrTszSnJctwef/9qr8/1M3 ndXZjGAxuuc47271WaEF5vbA5KdKwVafPY8sVLb1V+T0Xv82hMlpyG387U0C+UC8hR w4JfqNv7UDI1e0r72xi5HOq5EM+VtXtM9sTPQToo= 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 89A331201F8 for ; Wed, 30 Aug 2017 08:38:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mscc365.onmicrosoft.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 xA2cdTU4rg4o for ; Wed, 30 Aug 2017 08:38:23 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0084.outbound.protection.outlook.com [104.47.42.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E9F5124B18 for ; Wed, 30 Aug 2017 08:38:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mscc365.onmicrosoft.com; s=selector1-microsemi-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=YfxvGHhKt4amRovGmCSFoKc1t5jrmhwMTU8dHYlImTU=; b=IW2cb1iOG8WeuyOlfbc4yNrG3TzG3phVoPpfLr0r5s8QLH/jdfnsTrRbVCnlNZakDPN6SV8zWHam0rlxQOgyNYteMzsAPD8grSbVkEOXuIhMNsNqsh/10nMty0E7K41m6Or1f9lbBokZalIMfFF7bY+bbooTuyKM01kb0eSVk/4= Received: from BN6PR02CA0095.namprd02.prod.outlook.com (10.161.158.36) by CY1PR0201MB1451.namprd02.prod.outlook.com (10.163.139.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.13.10; Wed, 30 Aug 2017 15:38:21 +0000 Received: from BN1BFFO11FD047.protection.gbl (2a01:111:f400:7c10::1:107) by BN6PR02CA0095.outlook.office365.com (2603:10b6:405:60::36) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.13.10 via Frontend Transport; Wed, 30 Aug 2017 15:38:21 +0000 Authentication-Results: spf=pass (sender IP is 208.19.100.20) smtp.mailfrom=microsemi.com; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=microsemi.com; Received-SPF: Pass (protection.outlook.com: domain of microsemi.com designates 208.19.100.20 as permitted sender) receiver=protection.outlook.com; client-ip=208.19.100.20; helo=avsrvexchhts2.microsemi.net; Received: from avsrvexchhts2.microsemi.net (208.19.100.20) by BN1BFFO11FD047.mail.protection.outlook.com (10.58.145.2) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.1341.15 via Frontend Transport; Wed, 30 Aug 2017 15:38:20 +0000 Received: from AVMBX2.microsemi.net (10.100.34.32) by avsrvexchhts2.microsemi.net (10.100.34.106) with Microsoft SMTP Server (TLS) id 14.3.361.1; Wed, 30 Aug 2017 08:38:20 -0700 Received: from AVMBX2.microsemi.net (10.100.34.32) by AVMBX2.microsemi.net (10.100.34.32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1034.26; Wed, 30 Aug 2017 08:38:19 -0700 Received: from SJSRVEXCHHTS1.microsemi.net (10.241.34.105) by AVMBX2.microsemi.net (10.100.34.32) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1034.26 via Frontend Transport; Wed, 30 Aug 2017 08:38:19 -0700 Received: from SJSRVEXCHMBX1.microsemi.net ([fe80::19b5:ac43:d8de:5120]) by sjsrvexchhts1.microsemi.net ([::1]) with mapi id 14.03.0361.001; Wed, 30 Aug 2017 08:38:19 -0700 From: Greg Dowd To: Dieter Sibold , Daniel Franke , "kristof.teichel@ptb.de" Thread-Topic: [Ntp] Antwort: Re: WGLC for draft-ietf-ntp-using-nts-for-ntp Thread-Index: AQHTIQDYt6BY6EXSKkSxTrxhVNsqhKKddqAA//+S4LA= Date: Wed, 30 Aug 2017 15:38:19 +0000 Message-ID: <8D2BF679AAC7C346848A489074F9F8BFD283080E@sjsrvexchmbx1.microsemi.net> References: <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> <19062708.TpRPKSgBD8@eris> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.241.128.48] MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:208.19.100.20; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10009020)(6009001)(39860400002)(2980300002)(438002)(13464003)(24454002)(189002)(199003)(377454003)(53416004)(97756001)(68736007)(33656002)(5660300001)(2950100002)(7696004)(55846006)(39060400002)(106466001)(6306002)(2920100001)(2900100001)(54906002)(9686003)(230783001)(69596002)(54356999)(229853002)(53936002)(50986999)(6246003)(76176999)(189998001)(53546010)(7736002)(305945005)(49446005)(50466002)(2501003)(102836003)(23726003)(356003)(626005)(3846002)(5890100001)(2906002)(72206003)(4326008)(5250100002)(966005)(81156014)(6116002)(86362001)(46406003)(97736004)(93886005)(47776003)(81166006)(8676002)(8746002)(478600001)(8936002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR0201MB1451; H:avsrvexchhts2.microsemi.net; FPR:; SPF:Pass; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BN1BFFO11FD047; 1:zJ7OeA4r3mW1YprOzBj+Z+4lZEa6o4xH60t0iucJ8UMq3FMol8nQOigLOGHpoaPhVTqJko0GzsiF7nT9KNPc08OmSoI+bTrBnzdd+5FJ8RS1M8JgLcvOfU6PY+YiZsaj X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: b4b587bb-7dba-4f28-affe-08d4efbd24c3 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(8251501002)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY1PR0201MB1451; X-Microsoft-Exchange-Diagnostics: 1; CY1PR0201MB1451; 3:hRaO6Lvz1p4sIHOz2WVLEyBTV0UQbgZxWlTe9BvTXexFCidk+8IOr8svPHdHuPlKwaYU1sGqgw05eYJF/p8FWJUmJ/O0unQpBYkDUdp+IszBZbtpjfj4YSYS4wK+0vxmueurzky9AwlaLWEBQDXzrEkWHF9gOhRw8Qsz+mxyHPeqsg9FLksROsX5tMl4vep1jC2ZNBlHdX1rR4AGNciRGPbp6X1ABmRQjs54rd39E9shIlzOwcjhwnioGzGdCNiTT7lfSXstT4r5IsFkPbC32EI3x2x+zVKw7SJZ3/mEFs65P9A25KcDFUfKLZez9Tcf6SWHmWF9rHUVpRca7yBUBDAcXbhTIxvOKKpYFfejPOw=; 25:JYRaOKPgJDKbh71yQwB0X9+7+T51mpPNMP1e0jickPInhlUigwZ6jyvxNlhJiA3gzcnK7MeBZ1tHztj2kHVImWzWNFmCf1DRfhpuVWZEn7aDFFM//OCfB3iuGFqGKeeNTwT7QJraUsoQtJko227Kq69SPz26nvmhNPxApbdP3POGzAh5OHTp+NW4CDhRsA/DtFZk7TKAfKHIHbVFDf/yXICUpSLiM/uuRlRA2qHlNo2Ufw8jA/YzDivRbGxMQiKWGpbDu3HUkej5sqbpDVs4jLH/eEZy0aFmMCVMwRXeLRL5Zvmzr5wDJZ5O8IhRWNVAb7BQTqQpwpeTm+HVfdmJKA== X-MS-TrafficTypeDiagnostic: CY1PR0201MB1451: X-Microsoft-Exchange-Diagnostics: 1; CY1PR0201MB1451; 31:WjldVf9WwzYRqsdtLqUsaaaJ/XgUy5J17juwBSOBIuw4297fSx47387jtL3qRcdSwh/CJP8o+08diNTBP3FWQsbM3pMPwEvDaACpKtCKqxy3T/8dJfCYjSQGWFQ6rP+8PeTbZTGP0OqspUnGCq/B7xyimVXRyeP0tQuqVWAQ3Q00scayzIAiDh0+bEnmNAV9yO4quDtMNXhV0NtoQZiXpFXGffKf20sp4MeMbwvY8qk=; 20:MfHwaPuYGPAVBMGi2xC5gDhOSa2qMjGO3W8nt2qpjYn8bmYPCYPnboEWKqyB2FDQAGKjr9ezrzx8dnnvXzw16OzYdNxPlFHwBQfxKXusis9gQugmqBaDf53Q+u1Tpa8fa88uB7VW93PF9sJ1v1ma/1cYsvXOIds9Yxsw/e+HYcEsBgumpGG9Bba9Br/hfJ8tpGb3HTr/5yWji5PDflDpibK1ZQh+HV//nLpbKnRQ0V0IO+63lfufuybWL08aWKAw8mJxdDWjB3HyKAry6E/XItJTMQ5iS7bEvNTWphm27JWJnT4ujfdoZJ6LmPu9ekHsiY8DLKf/vqZoZbcFJyjeyUFbRqkCaktcCf5hClknyzRpVBR0aezRSSFbE8NorvCQ7thKfdxF0xoCoKuXAbZ75ByqNErvKh2f7v/wP+PAwM0cDrgsacCzLo/uDSzI36tvzKZXhvJzEIVdfg/jV9n6yx+tyJ5+HHwAFxa1rLsAErG/U0lJju/hSXZzab590gPi X-Exchange-Antispam-Report-Test: UriScan:; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(13018025)(13016025)(10201501046)(93006095)(93004095)(3002001)(100000703101)(100105400095)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123562025)(20161123555025)(20161123564025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY1PR0201MB1451; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY1PR0201MB1451; X-Microsoft-Exchange-Diagnostics: 1; CY1PR0201MB1451; 4:EUSGe9MdBryrjeB8XT3v5VE0yeX15tgiZKkMJt+H4ATmngyuJLU4AyaN/SkOhsx8ILyAUA05iepYxYSyaXOplSCK2wpzyVZTq5b0h3cF7y7jf1YVLlvSFHbThul6rcIXj5HnnvZGxt96XWAlOGwFR+ENs4U3/A1+ifMVDHSgbCNVphmRAwiQ6zxVzqpP5BgrObLh8WmJpGQF9QymhuasEE4pVkV0k9XJGxZioX3xolXf4z5l70J/d7pwRTSYKRWK X-Forefront-PRVS: 041517DFAB X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR0201MB1451; 23:cb0ZJvrBvXoUlL20Ttu/qT3FIhRQy9hvLKC9N8T?= =?us-ascii?Q?JpXfMi2G9WZN3/dUrD4mnMDCfQyBVDuJDH12Y33JnBhi6cLtLizYRAZ0/Mcx?= =?us-ascii?Q?XnQwjZLtggyL4wvcC2FRYbq236T+X/omc149J/EIKvuPMODeiV3/mORq8Grr?= =?us-ascii?Q?S0BgTDUZU71jRyd0s0rllzO6dqvGYJaL8iEEheXw2rU1lOg9bj/ksGQVRDEx?= =?us-ascii?Q?IVDdSsfa0Uj6q0s5P6YTBY/L0M/8pz8k///DbtjLznCYzp1jkQN8jCRQaY2H?= =?us-ascii?Q?uniDTk3kvr7ymVXHQox1HyVWLv3H0MM9IHBhavR0b8uFfOV6CDp6cahSJMqI?= =?us-ascii?Q?4XwU5Z6X1ipCyeZli1THYYj6zHPGi8QLXngC+36KcRNcoqouXVhhbpEvr+im?= =?us-ascii?Q?YFDIa5em9ELIHyffHFzzc0kOb//eIw6hO0qpxWudEBTDRVB/g+sdZbpOK03S?= =?us-ascii?Q?0yzK7yOwHzLzaNshWvXK4NK/uTNwQTRDKd/V5TrMArwRRkHx+5p11NyORT0P?= =?us-ascii?Q?8PGomPLGl/psmehge2jC1tDXKn1U8GQfgPjAwKGZA5p7gJBi/VblW9ckHv3v?= =?us-ascii?Q?6UL2o/chRtbTMLluQW69OZbY3npLO54H+w0nrggCufNK+87oYoTAKsqOSoyg?= =?us-ascii?Q?Zqh7PpYgrFYprk6T0rkM5w3iw33K6qyVljXKMKry26A/JqqJYsOOv0oaZcfL?= =?us-ascii?Q?z3HQV5sMqZq05XG1FG2psCpqFDviN7vJTd07IipgU4ybN884nGBjy3u3n5yl?= =?us-ascii?Q?8XxnY0/5GImFEQPOWSmnu4evs0D22xK/ru8+oTAY9fUuBDCgNg7B9GI2eeQN?= =?us-ascii?Q?LMMyZgd1pyiEmrCRGMTTxW+gZEdLpHCMAKODfmCbpt30NtP/CJetx7w4QE1P?= =?us-ascii?Q?UIRO6jKWWX3IcFIubWYltVQXt8rx6AsJL7+N2w+IDKh7uZZN5yJ0HcBovrtG?= =?us-ascii?Q?+tPnmpPQxLgQuDDFRM5cL5bbx8V0XjHVgiXEePB8LVljyfWyMAqLVw3o5mnv?= =?us-ascii?Q?m5TP0j79eISuymRiODG5Ub8kUqY4W+spJ2OFbWzhAuczS2MRjoquc4QaAHSR?= =?us-ascii?Q?zU+fTCKu+S1gUmSr6HwCJ9cKb4pvN8gdG9k4SJpBt77xjgFRD++L7LO/sD0w?= =?us-ascii?Q?oZwtLeD7h8LG9jXr+a0dZuk3b6LTYtTAHnSzliazPZBpOeCuNk+gZusv++O6?= =?us-ascii?Q?bbMZxiCpC3N4S6V7HggRCfRKOM+OtlpLAhAqy0ZJaL7SRN576CGbSpkFZ3k4?= =?us-ascii?Q?RFsDnx4PuJmxf3OqJaKwt5XWPRtbgZC79jQT808Wtklx9xEkVTY2M+Rd2U+Q?= =?us-ascii?Q?Z2uFVP/mxGolIh4YNtUQ0KH/f3WVeLO9CIWhR2dXQs4BgnFGyWm1bzCoA3pK?= =?us-ascii?Q?6imHH+V9QZjaqyfSZEmAukm6lPe8WJVh74o2o25sY/APE5BxjdjzXLpfHYv2?= =?us-ascii?Q?vo4k78hRJxXtWWwEipZFkAwoOTrXqcKE=3D?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR0201MB1451; 6:8XaHQTSQYnk491Hk0DUhDNDjHh7oEIIZca3PPzm0tpeM1E0UOrShGyFtcvGh/Y5nByA2/64m7QoCEJS1QTu/DXknGZRp6/IhbnOnbW4JSjjem4TFCr7yIsIj4E53rmPvq+HjSIMt9DQz7O0tksGVOkAk58pVK3sUrz845DIoZ8QZsAIRwQ9fzVhCawCTSFXyA8X5X2UK/A4qEbXfY0FT799PeKNTa8NCiFOSFaA7292fOBX5u94eA5dFJT3df9sdXY6Qn4iUwNCeENt3vW5dEozpybw/4zc7pjhUjLt1oxxEhDNlntPS+m1bl/lMNRsuTWdw7KFopt9MdnZL38wgtw==; 5:DnEFxUbj20F0KLnSwwdmp+g6wTf+4oPmc88gh1/AFBHy3ffewQFCQSDJr7zjzl/nEgFWgQaJTVctPdUm6Qkpw4zwJZJZL2jUmNmOqheqApFmiO8mTfFb7qojlB1hDG+nGIeVVxUHPq80JeBj3UKKdw==; 24:de9pzyduvrbaedB9coan8FqF6Pdj139CJY4rjsq7B9nXEx5H1dX1zKFOmpnySSk8+BqMWTeAWgqSicQ9MvWXGZa8GWvsnWkE0eTbz9Duh4A=; 7:LBN5QkqZ4pq8lLtF2viOlNOkTQqHGq+wXx/Ug01YgsiPG/WW1yPgUnvH9uwenWrQNMLi5b55wZWiHbqwFA9ATMTiEE4lpF6aFiUKrDSeDtcuKo/6WYAs44wi0Yjf8DL3R6l9aAEBj2WF2jbx8l1wb5jhYqGuhyZxhhgdD3ULZwvW7Q4V9foU6YtTnpfS60P6KLRrwe0qCNqmS0twX4Ggve3/iilFVI4xr82awUNDCrE= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: microsemi.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Aug 2017 15:38:20.7312 (UTC) X-MS-Exchange-CrossTenant-Id: f267a5c8-86d8-4cc9-af71-1fd2c67c8fad X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f267a5c8-86d8-4cc9-af71-1fd2c67c8fad; Ip=[208.19.100.20]; Helo=[avsrvexchhts2.microsemi.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0201MB1451 Archived-At: Subject: Re: [Ntp] Antwort: Re: WGLC for draft-ietf-ntp-using-nts-for-ntp X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "ntp@ietf.org" , Robert Annessi Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ntp-bounces@ietf.org Sender: "ntp" While I don't profess to know anything about the mapping of NTS to PTP, I would note that the telecom industry does use unicast flows for synchronization (PTP Profiles G.8265.1 for frequency and G.8275.2 for phase/tod). -----Original Message----- From: ntp [mailto:ntp-bounces@ietf.org] On Behalf Of Dieter Sibold Sent: Wednesday, August 30, 2017 8:07 AM To: Daniel Franke ; kristof.teichel@ptb.de Cc: ntp@ietf.org; Robert Annessi Subject: Re: [Ntp] Antwort: Re: WGLC for draft-ietf-ntp-using-nts-for-ntp EXTERNAL EMAIL As Robert pointed out with the lack of broadcast support we cannot protect PTP's timing messages. The only input of this draft to PTP could be the key exchange. Therefore, I also agree to drop PTP from this draft. Dieter -----Original Message----- From: ntp [mailto:ntp-bounces@ietf.org] On Behalf Of Daniel Franke Sent: Tuesday, August 29, 2017 9:56 PM To: kristof.teichel@ptb.de Cc: ntp@ietf.org; Robert Annessi Subject: Re: [Ntp] Antwort: Re: WGLC for draft-ietf-ntp-using-nts-for-ntp On 8/29/17, kristof.teichel@ptb.de wrote: > I knew there was something that I had wanted to contribute to the > discussion for a long time but just kind of forgotten. > This was it. > > I agree that this is a problem in the text, and I vote for taking out > all passages that specifically mention PTP in this context. Well, you're the reason I had it there to begin with. I thought you and Dieter still had ambitions to get something working wrt PTP. If that's no longer the case then, without objection, I'll remove that reference from the intro. Besides the Terms and Abbreviations appendix, the only other reference to PTP is an IANA request to reserve NTS Next Protocol code 1 for use with PTP. Since we changed these codes from textual to numeric I guess there's no reason to keep that either; we can always request a new allocation once there's something concrete to attach to it. _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp From nobody Wed Aug 30 08:42:47 2017 Return-Path: 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 13E44124B18 for ; Wed, 30 Aug 2017 08:42:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 3eYdvBoEFZL2 for ; Wed, 30 Aug 2017 08:42:44 -0700 (PDT) Received: from mx1.bs.ptb.de (mx1.bs.ptb.de [IPv6:2001:638:610:bd01::120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D328C1201F8 for ; Wed, 30 Aug 2017 08:42:43 -0700 (PDT) Received: from smtp-hub.bs.ptb.de (smtpint01.bs.ptb.de [141.25.87.32]) by mx1.bs.ptb.de with ESMTP id v7UFggvI012360-v7UFggvK012360 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 30 Aug 2017 17:42:42 +0200 Received: from rose.bs.ptb.de (rose.bs.ptb.de [141.25.85.201]) by smtp-hub.bs.ptb.de (Postfix) with ESMTPS id 009325346E4; Wed, 30 Aug 2017 17:42:41 +0200 (CEST) In-Reply-To: <9b9c364b-22d5-ca8f-aa80-6f99f632749d@libertysys.com.au> References: <9b9c364b-22d5-ca8f-aa80-6f99f632749d@libertysys.com.au> To: Paul Gear Cc: ntp@ietf.org MIME-Version: 1.0 Message-ID: From: dieter.sibold@ptb.de Date: Wed, 30 Aug 2017 17:42:39 +0200 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha-256; boundary=-------z35023_boundary_sign Archived-At: Subject: [Ntp] Antwort: Re: [NTP] WGLC for draft-ietf-ntp-using-nts-for-ntp (Requirements Language / NTP Pools) X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 15:42:46 -0000 This is an S/MIME signed message. ---------z35023_boundary_sign Content-Type: multipart/alternative; boundary="=_alternative 00564DB1C125818C_=" Dies ist eine mehrteilige Nachricht im MIME-Format. --=_alternative 00564DB1C125818C_= Content-Type: text/plain; charset="US-ASCII" Hi Paul, thanks for your input. Please, see my replies below. Dieter "ntp" schrieb am 30.08.2017 11:40:26: > Von: Paul Gear > An: ntp@ietf.org > Datum: 30.08.2017 11:40 > Betreff: Re: [Ntp] [NTP] WGLC for draft-ietf-ntp-using-nts-for-ntp > (Requirements Language / NTP Pools) > Gesendet von: "ntp" > > On 30/08/17 16:50, kristof.teichel@ptb.de wrote: > > > > 3.) > > I like the current name "cookie placeholder" over the suggestion > > "cookie request", simply because the former is more descriptive with > > regard to the same-length notion. > > I do, however, not have a strong opinion on this. > > I don't have a strong opinion on this either; I just found that on > initial reading it made more sense to think of it in this way - > especially when viewed in light of the fact that the number of cookie > placeholders normally indicates to the server the number of missed > replies since the last exchange. > > > > > 5.) (Also goes to an issue raised implicitly by Harlan & Dave) > > Concerning the NTP pools passage, I think there is something to the > > raised concerns, but I would approach the issue via the phrasing of > > the paragraph. > > I suggest instead of simply saying "pool operators" or "pools" (which > > does silently imply ALL of them). we move to saying "some pool > > operators / pools", since the problem persists even if it does not > > concern all instances. > > My text suggestion is: > > > > "[...] A more important matter, however, is that not all pool > > operators have procedures for establishing and maintaining trust in > > their members. > > Pools in existence as of 2017 are often volunteer-run, some of > > them with minimal requirements for admission and/or with no organized > > effort to monitor pool servers for misbehavior. [...]" > > Is there more than one pool? I'm only aware of pool.ntp.org, which is > volunteer-run and has minimal requirements for admission, but certainly > monitors its members. Results of this monitoring are publicly available > at http://www.pool.ntp.org/scores/[IP address] (e.g. here's one of mine: > http://www.pool.ntp.org/scores/2001:44b8:2100:3f00::7b). I think this > qualifies as "an organised effort to monitor pool servers for misbehavior". > > > I think this text does the same thing for the conclusion (in general, > > using pools with NTS is a bad idea), but hopefully more people will > > view it as factually correct. > > I would hope that this conclusion is specifically what NTS is aiming to > avoid. With respect to NTS' privacy/unlinkability aims, I would have > thought that the most common use case would be with garden variety > phones, tablets, PCs, & IoT devices, many (most?) of which use the NTP > pool. Aiming for a system which works with the pool would bring the > greatest privacy benefit to the greatest number of users. (And I would > argue that the pool requiring NTS support from participants could become > a useful tool in driving NTS adoption, once the questions about > certificate validation are answered.) I acknowledge that the usage of pools would be very helpful. And don't understand me wrong. I like the pools and honor there work. But I still see problems with the trust of a pool. As far as I know pools it is pretty easy to become a member of a pool. Therefore, a malicious NTP-Server can become a member of the pool, he can perfectly synchronized to UTC and still send me false timestamps. The monitoring done by the ntp pool volunteers is great but it is not sufficient to establish trust in the pool members. That would be different if the pool representatives could guarantee that all of there members are trustworthy. Currently, I think this is not possible. But perhaps I'm wrong. I'd like to learn better. > > Regards, > Paul > > _______________________________________________ > ntp mailing list > ntp@ietf.org > https://www.ietf.org/mailman/listinfo/ntp --=_alternative 00564DB1C125818C_= Content-Type: text/html; charset="US-ASCII" Hi Paul, thanks for your input. Please, see my replies below.

Dieter

"ntp" <ntp-bounces@ietf.org> schrieb am 30.08.2017 11:40:26:

> Von: Paul Gear <ntp@libertysys.com.au>
> An: ntp@ietf.org
> Datum: 30.08.2017 11:40
> Betreff: Re: [Ntp] [NTP] WGLC for draft-ietf-ntp-using-nts-for-ntp
> (Requirements Language / NTP Pools)
> Gesendet von: "ntp" <ntp-bounces@ietf.org>
>
> On 30/08/17 16:50, kristof.teichel@ptb.de wrote:
> >
> > 3.)
> > I like the current name "cookie placeholder" over the suggestion
> > "cookie request", simply because the former is more descriptive with
> > regard to the same-length notion.
> > I do, however, not have a strong opinion on this.
>
> I don't have a strong opinion on this either; I just found that on
> initial reading it made more sense to think of it in this way -
> especially when viewed in light of the fact that the number of cookie
> placeholders normally indicates to the server the number of missed
> replies since the last exchange.
>
> >
> > 5.) (Also goes to an issue raised implicitly by Harlan & Dave)
> > Concerning the NTP pools passage, I think there is something to the
> > raised concerns, but I would approach the issue via the phrasing of
> > the paragraph.
> > I suggest instead of simply saying "pool operators" or "pools" (which
> > does silently imply ALL of them). we move to saying "some pool
> > operators / pools", since the problem persists even if it does not
> > concern all instances.
> > My text suggestion is:
> >
> >         "[...] A more important matter, however, is that not all pool
> > operators have procedures for establishing and maintaining trust in
> > their members.
> >         Pools in existence as of 2017 are often volunteer-run, some of
> > them with minimal requirements for admission and/or with no organized
> > effort to monitor pool servers for misbehavior. [...]"
>
> Is there more than one pool?  I'm only aware of pool.ntp.org, which is
> volunteer-run and has minimal requirements for admission, but certainly
> monitors its members.  Results of this monitoring are publicly available
> at http://www.pool.ntp.org/scores/[IP address] (e.g. here's one of mine:
> http://www.pool.ntp.org/scores/2001:44b8:2100:3f00::7b).  I think this
> qualifies as "an organised effort to monitor pool servers for misbehavior".
>
> > I think this text does the same thing for the conclusion (in general,
> > using pools with NTS is a bad idea), but hopefully more people will
> > view it as factually correct.
>
> I would hope that this conclusion is specifically what NTS is aiming to
> avoid.  With respect to NTS' privacy/unlinkability aims, I would have
> thought that the most common use case would be with garden variety
> phones, tablets, PCs, & IoT devices, many (most?) of which use the NTP
> pool.  Aiming for a system which works with the pool would bring the
> greatest privacy benefit to the greatest number of users.  (And I would
> argue that the pool requiring NTS support from participants could become
> a useful tool in driving NTS adoption, once the questions about
> certificate validation are answered.)

I acknowledge that the usage of pools would be very helpful. And  don't understand me wrong. I like the pools and honor there work. But I still see problems with the trust of a pool. As far as I know pools it is pretty easy to become a member of a pool. Therefore, a malicious NTP-Server can become a member of the pool, he can perfectly synchronized to UTC and still send me false timestamps. The monitoring done by the ntp pool volunteers  is great but it is not sufficient to establish trust in the pool members. That would be different if the pool representatives could guarantee that all of there members are trustworthy. Currently, I think this is not possible. But perhaps I'm wrong. I'd like to learn better.



>
> Regards,
> Paul
>
> _______________________________________________
> ntp mailing list
> ntp@ietf.org
> https://www.ietf.org/mailman/listinfo/ntp
 --=_alternative 00564DB1C125818C_=-- ---------z35023_boundary_sign Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIIp0gIBATEPMA0GCWCGSAFlAwQCAQUAMAsGCSqGSIb3DQEHAaCCJsYw ggOfMIICh6ADAgECAgEmMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNE ZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYD VQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw05OTA3MDkxMjExMDBaFw0xOTA3MDky MzU5MDBaMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYD VQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJv b3QgQ0EgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKsLozXgiykUsRSFrzwQ5Dlv NV1Krt3qYY2VSfRvZKMaYGakqUAihNnUpeV4kw5oAa25TVw6ztO4qEJA38+juoJZapIbrBya2ggr JSf5aSNH8eDrLHqb9RMC0H40fMKePABZq/XaDPUyPCusUNrWw96DlMqoDJkyDghIVltq+9rhWFgB SV9yQTwVBgGOXa2quJO0zZ7rp+hqLVI02zrvXHVR2tvzMfnucZgyxFQVRAz5m1Xtrd8YCKCjhopJ 7lMFjxlM1d5YeZvSahxCq8XVp89oD5bk4WGYdmHIkXzWPgDikVCH4Z0K5q2X0h3GOn3LvNoDNNWO WwH1age3FrZuSn8CAwEAAaNCMEAwHQYDVR0OBBYEFDHDeRu69VPXF+CJei0XbAqzK50zMA8GA1Ud EwQIMAYBAf8CAQUwDgYDVR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBBQUAA4IBAQCUZFmtOWTnKesT /lrDixNXyAQk8HR3wGDjZ/vpiaaDv5aCfG7Uwz3vnoBuuym0mHqxO1TrORdHfhqOC/wfMVkxBLLO F/Msx2I2VeIi2IlVtJhIqmT61hw22ER4WlojOleX9XowT66fakxLK46gA+M+4KnU0nvSs6jicjyt nv+AWeSbRbT2O7DNORmYMuXqIWGQ5DEhjjSx9y81SoUQ2ueKNyG+WWPg8oWIMVPUVBSFcHn0LgZ3 J3UvH7iK+f7Futg25IPs52W3v2Na80avgZQ31EGM1iPWHs/1aBtEY6Jauqc1WaHlcAWbDiNXmZQK bbo5YyiGkvMYhNj70c8FVmRXMIIDnzCCAoegAwIBAgIBJjANBgkqhkiG9w0BAQUFADBxMQswCQYD VQQGEwJERTEcMBoGA1UEChMTRGV1dHNjaGUgVGVsZWtvbSBBRzEfMB0GA1UECxMWVC1UZWxlU2Vj IFRydXN0IENlbnRlcjEjMCEGA1UEAxMaRGV1dHNjaGUgVGVsZWtvbSBSb290IENBIDIwHhcNOTkw NzA5MTIxMTAwWhcNMTkwNzA5MjM1OTAwWjBxMQswCQYDVQQGEwJERTEcMBoGA1UEChMTRGV1dHNj aGUgVGVsZWtvbSBBRzEfMB0GA1UECxMWVC1UZWxlU2VjIFRydXN0IENlbnRlcjEjMCEGA1UEAxMa RGV1dHNjaGUgVGVsZWtvbSBSb290IENBIDIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCrC6M14IspFLEUha88EOQ5bzVdSq7d6mGNlUn0b2SjGmBmpKlAIoTZ1KXleJMOaAGtuU1cOs7T uKhCQN/Po7qCWWqSG6wcmtoIKyUn+WkjR/Hg6yx6m/UTAtB+NHzCnjwAWav12gz1MjwrrFDa1sPe g5TKqAyZMg4ISFZbavva4VhYAUlfckE8FQYBjl2tqriTtM2e66foai1SNNs671x1Udrb8zH57nGY MsRUFUQM+ZtV7a3fGAigo4aKSe5TBY8ZTNXeWHmb0mocQqvF1afPaA+W5OFhmHZhyJF81j4A4pFQ h+GdCuatl9Idxjp9y7zaAzTVjlsB9WoHtxa2bkp/AgMBAAGjQjBAMB0GA1UdDgQWBBQxw3kbuvVT 1xfgiXotF2wKsyudMzAPBgNVHRMECDAGAQH/AgEFMA4GA1UdDwEB/wQEAwIBBjANBgkqhkiG9w0B AQUFAAOCAQEAlGRZrTlk5ynrE/5aw4sTV8gEJPB0d8Bg42f76Ymmg7+Wgnxu1MM9756AbrsptJh6 sTtU6zkXR34ajgv8HzFZMQSyzhfzLMdiNlXiItiJVbSYSKpk+tYcNthEeFpaIzpXl/V6ME+un2pM SyuOoAPjPuCp1NJ70rOo4nI8rZ7/gFnkm0W09juwzTkZmDLl6iFhkOQxIY40sfcvNUqFENrnijch vllj4PKFiDFT1FQUhXB59C4Gdyd1Lx+4ivn+xbrYNuSD7Odlt79jWvNGr4GUN9RBjNYj1h7P9Wgb RGOiWrqnNVmh5XAFmw4jV5mUCm26OWMohpLzGITY+9HPBVZkVzCCBNUwggO9oAMCAQICCFBOxvU9 EbRkMA0GCSqGSIb3DQEBCwUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNEZXV0c2NoZSBUZWxl a29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYDVQQDExpEZXV0c2No ZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0xNDA3MjIxMjA4MjZaFw0xOTA3MDkyMzU5MDBaMFoxCzAJ BgNVBAYTAkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQD ExtERk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U1wBblSJ01CDrNI/W7MAxBAuZgeKmFNJSoCgjhIt0 iQReW+DieMF4yxbLKDU5ey2QRdDtoAB6fL9KDhsAw4bpXCsxEXsM84IkQ4wcOItqaACa7txPeKvS xhObdq3u3ibo7wGvdA/BCaL2a869080UME/15eOkyGKbghoDJzANAmVgTe3RCSMqljVYJ9N2xnG2 kB3E7f81hn1vM7PbD8URwoqDoZRdQWvY0hD1TP3KUazZve+Sg7va64sWVlZDz+HVEz2mHycwzUlU 28kTNJpxdcVs6qcLmPkhnSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjggGGMIIBgjAOBgNVHQ8BAf8E BAMCAQYwHQYDVR0OBBYEFEm3xs/oPR9/6kR7Eyn38QpwPt5kMB8GA1UdIwQYMBaAFDHDeRu69VPX F+CJei0XbAqzK50zMBIGA1UdEwEB/wQIMAYBAf8CAQIwYgYDVR0gBFswWTARBg8rBgEEAYGtIYIs AQEEAgIwEQYPKwYBBAGBrSGCLAEBBAMAMBEGDysGAQQBga0hgiwBAQQDATAPBg0rBgEEAYGtIYIs AQEEMA0GCysGAQQBga0hgiweMD4GA1UdHwQ3MDUwM6AxoC+GLWh0dHA6Ly9wa2kwMzM2LnRlbGVz ZWMuZGUvcmwvRFRfUk9PVF9DQV8yLmNybDB4BggrBgEFBQcBAQRsMGowLAYIKwYBBQUHMAGGIGh0 dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMDoGCCsGAQUFBzAChi5odHRwOi8vcGtpMDMz Ni50ZWxlc2VjLmRlL2NydC9EVF9ST09UX0NBXzIuY2VyMA0GCSqGSIb3DQEBCwUAA4IBAQBjICj9 nCGGcr45Rlk5MiW8qQGbDczKfUGchm0KbiyzE1l1sTOSG2EnFv/DstU1gvuEKgFJvWa7Zi+ywgZd bj9u4wFaW8pDY1yVtuExpx/VB19N5mWCTjL5w3x6S81NXHTuIfJ1AuxSPtLJatOQI25JZzW+f01W pOzML8+3oZeocj7JvEDWWqQIPda8gsO3tzKOsSyOam23NQIZz/U5RFhjpyQAELC7/E6vbi84u6VX ST/YblBvLJeW3B1GmmWJz67M8uXZn1OzPqEvkqnYC8aEHwTG6x7on321e6UC8STFJGMRNMxakyAq eYg6JUKQqWU7fIbTEhUjKfws2sw5W1QXMIIE1TCCA72gAwIBAgIIUE7G9T0RtGQwDQYJKoZIhvcN AQELBQAwcTELMAkGA1UEBhMCREUxHDAaBgNVBAoTE0RldXRzY2hlIFRlbGVrb20gQUcxHzAdBgNV BAsTFlQtVGVsZVNlYyBUcnVzdCBDZW50ZXIxIzAhBgNVBAMTGkRldXRzY2hlIFRlbGVrb20gUm9v dCBDQSAyMB4XDTE0MDcyMjEyMDgyNloXDTE5MDcwOTIzNTkwMFowWjELMAkGA1UEBhMCREUxEzAR BgNVBAoTCkRGTi1WZXJlaW4xEDAOBgNVBAsTB0RGTi1QS0kxJDAiBgNVBAMTG0RGTi1WZXJlaW4g UENBIEdsb2JhbCAtIEcwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOmbw2eF+Q2u 9Y1Uw5ZQNT1i6W5M7ZTXAFuVInTUIOs0j9bswDEEC5mB4qYU0lKgKCOEi3SJBF5b4OJ4wXjLFsso NTl7LZBF0O2gAHp8v0oOGwDDhulcKzERewzzgiRDjBw4i2poAJru3E94q9LGE5t2re7eJujvAa90 D8EJovZrzr3TzRQwT/Xl46TIYpuCGgMnMA0CZWBN7dEJIyqWNVgn03bGcbaQHcTt/zWGfW8zs9sP xRHCioOhlF1Ba9jSEPVM/cpRrNm975KDu9rrixZWVkPP4dUTPaYfJzDNSVTbyRM0mnF1xWzqpwuY +SGdJ68+ozk5SGqMrcmZ+8MS8r0CAwEAAaOCAYYwggGCMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4E FgQUSbfGz+g9H3/qRHsTKffxCnA+3mQwHwYDVR0jBBgwFoAUMcN5G7r1U9cX4Il6LRdsCrMrnTMw EgYDVR0TAQH/BAgwBgEB/wIBAjBiBgNVHSAEWzBZMBEGDysGAQQBga0hgiwBAQQCAjARBg8rBgEE AYGtIYIsAQEEAwAwEQYPKwYBBAGBrSGCLAEBBAMBMA8GDSsGAQQBga0hgiwBAQQwDQYLKwYBBAGB rSGCLB4wPgYDVR0fBDcwNTAzoDGgL4YtaHR0cDovL3BraTAzMzYudGVsZXNlYy5kZS9ybC9EVF9S T09UX0NBXzIuY3JsMHgGCCsGAQUFBwEBBGwwajAsBggrBgEFBQcwAYYgaHR0cDovL29jc3AwMzM2 LnRlbGVzZWMuZGUvb2NzcHIwOgYIKwYBBQUHMAKGLmh0dHA6Ly9wa2kwMzM2LnRlbGVzZWMuZGUv Y3J0L0RUX1JPT1RfQ0FfMi5jZXIwDQYJKoZIhvcNAQELBQADggEBAGMgKP2cIYZyvjlGWTkyJbyp AZsNzMp9QZyGbQpuLLMTWXWxM5IbYScW/8Oy1TWC+4QqAUm9ZrtmL7LCBl1uP27jAVpbykNjXJW2 4TGnH9UHX03mZYJOMvnDfHpLzU1cdO4h8nUC7FI+0slq05AjbklnNb5/TVak7Mwvz7ehl6hyPsm8 QNZapAg91ryCw7e3Mo6xLI5qbbc1AhnP9TlEWGOnJAAQsLv8Tq9uLzi7pVdJP9huUG8sl5bcHUaa ZYnPrszy5dmfU7M+oS+SqdgLxoQfBMbrHuiffbV7pQLxJMUkYxE0zFqTICp5iDolQpCpZTt8htMS FSMp/CzazDlbVBcwggU9MIIEJaADAgECAgcXr/adVkv+MA0GCSqGSIb3DQEBCwUAMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtE Rk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwHhcNMTQwNjA1MTQwNTAyWhcNMTkwNzA5MjM1OTAw WjBpMQswCQYDVQQGEwJERTEuMCwGA1UEChMlUGh5c2lrYWxpc2NoLVRlY2huaXNjaGUgQnVuZGVz YW5zdGFsdDEPMA0GA1UEAxMGUFRCIENBMRkwFwYJKoZIhvcNAQkBFgpwa2lAcHRiLmRlMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvArCgzkqw2LMAYuU38VJTgyGBC+Pp+uvw52LmtI6 MEMiFr0xY6SEzYcDG3z5NSohZisdnL7bu8Ee7MFD3TZX1jVBie//UNAJqXbHnUzE8hbJYCR5ydb9 WqIzoT5PzG07qJWblbidcrZVcCQEef9V1CaRyfXuqiSTOgibqODLP98N7jMIImz2ipUgMdoGyOgS h/qds5SM6CUgwMeuJ42QpYNot9ri1IKAweyhIIa3TANsu56scy+Fc2+XWOfsuImeeLcaiu6HJPk6 X55QT+kWaAoQf6qJyJXv8b/n6l1nmTIU2AY2B5EnO/rIT+DW+MJy77/HO+7rtwaznuntXMgytwID AQABo4IB9zCCAfMwEgYDVR0TAQH/BAgwBgEB/wIBATAOBgNVHQ8BAf8EBAMCAQYwEQYDVR0gBAow CDAGBgRVHSAAMB0GA1UdDgQWBBTEgNBuKBVoMVrscF94juEwQzjqNDAfBgNVHSMEGDAWgBRJt8bP 6D0ff+pEexMp9/EKcD7eZDAVBgNVHREEDjAMgQpwa2lAcHRiLmRlMIGIBgNVHR8EgYAwfjA9oDug OYY3aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY3JsL2NhY3JsLmNy bDA9oDugOYY3aHR0cDovL2NkcDIucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY3JsL2Nh Y3JsLmNybDCB1wYIKwYBBQUHAQEEgcowgccwMwYIKwYBBQUHMAGGJ2h0dHA6Ly9vY3NwLnBjYS5k Zm4uZGUvT0NTUC1TZXJ2ZXIvT0NTUDBHBggrBgEFBQcwAoY7aHR0cDovL2NkcDEucGNhLmRmbi5k ZS9nbG9iYWwtcm9vdC1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwRwYIKwYBBQUHMAKGO2h0dHA6 Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MA0G CSqGSIb3DQEBCwUAA4IBAQCo3hebMpEocLPJTOlDMAmSzpxK3SA1ftaQqodbMncOi9WkeICQlmIv rQxGCq8Be/6hKtIrbFOhRtSzQi870glJRj7dhZaHC+WOgT5tP5Nkgwpgl4k4pQDXPPrwmaI6cSYD a/LpprQzBNjEQMdQqkeanpD0WU9U1pOPFIMfIrxh2cy8mBpIAMuZqMHbMyPNDZk/YN4r3b2DcBrQ wL/tHerp6Vc7n9WqO+3cm7Fa4AxL9q2KeItyYe0Cws2KZNz4IuiMjQAclNL0PhTEqIzkD/EiK6Ag 1qcH7o3ktpmakvL2RzSZA71irCfONRgh/+ixfuMu6YA5uzyA8SYfwyFQcABdMIIFPTCCBCWgAwIB AgIHF6/2nVZL/jANBgkqhkiG9w0BAQsFADBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZOLVZl cmVpbjEQMA4GA1UECxMHREZOLVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xvYmFsIC0g RzAxMB4XDTE0MDYwNTE0MDUwMloXDTE5MDcwOTIzNTkwMFowaTELMAkGA1UEBhMCREUxLjAsBgNV BAoTJVBoeXNpa2FsaXNjaC1UZWNobmlzY2hlIEJ1bmRlc2Fuc3RhbHQxDzANBgNVBAMTBlBUQiBD QTEZMBcGCSqGSIb3DQEJARYKcGtpQHB0Yi5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALwKwoM5KsNizAGLlN/FSU4MhgQvj6frr8Odi5rSOjBDIha9MWOkhM2HAxt8+TUqIWYrHZy+ 27vBHuzBQ902V9Y1QYnv/1DQCal2x51MxPIWyWAkecnW/VqiM6E+T8xtO6iVm5W4nXK2VXAkBHn/ VdQmkcn17qokkzoIm6jgyz/fDe4zCCJs9oqVIDHaBsjoEof6nbOUjOglIMDHrieNkKWDaLfa4tSC gMHsoSCGt0wDbLuerHMvhXNvl1jn7LiJnni3GoruhyT5Ol+eUE/pFmgKEH+qiciV7/G/5+pdZ5ky FNgGNgeRJzv6yE/g1vjCcu+/xzvu67cGs57p7VzIMrcCAwEAAaOCAfcwggHzMBIGA1UdEwEB/wQI MAYBAf8CAQEwDgYDVR0PAQH/BAQDAgEGMBEGA1UdIAQKMAgwBgYEVR0gADAdBgNVHQ4EFgQUxIDQ bigVaDFa7HBfeI7hMEM46jQwHwYDVR0jBBgwFoAUSbfGz+g9H3/qRHsTKffxCnA+3mQwFQYDVR0R BA4wDIEKcGtpQHB0Yi5kZTCBiAYDVR0fBIGAMH4wPaA7oDmGN2h0dHA6Ly9jZHAxLnBjYS5kZm4u ZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NybC9jYWNybC5jcmwwPaA7oDmGN2h0dHA6Ly9jZHAyLnBj YS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NybC9jYWNybC5jcmwwgdcGCCsGAQUFBwEBBIHK MIHHMDMGCCsGAQUFBzABhidodHRwOi8vb2NzcC5wY2EuZGZuLmRlL09DU1AtU2VydmVyL09DU1Aw RwYIKwYBBQUHMAKGO2h0dHA6Ly9jZHAxLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2Nh Y2VydC9jYWNlcnQuY3J0MEcGCCsGAQUFBzAChjtodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2dsb2Jh bC1yb290LWNhL3B1Yi9jYWNlcnQvY2FjZXJ0LmNydDANBgkqhkiG9w0BAQsFAAOCAQEAqN4XmzKR KHCzyUzpQzAJks6cSt0gNX7WkKqHWzJ3DovVpHiAkJZiL60MRgqvAXv+oSrSK2xToUbUs0IvO9IJ SUY+3YWWhwvljoE+bT+TZIMKYJeJOKUA1zz68JmiOnEmA2vy6aa0MwTYxEDHUKpHmp6Q9FlPVNaT jxSDHyK8YdnMvJgaSADLmajB2zMjzQ2ZP2DeK929g3Aa0MC/7R3q6elXO5/Vqjvt3JuxWuAMS/at iniLcmHtAsLNimTc+CLojI0AHJTS9D4UxKiM5A/xIiugINanB+6N5LaZmpLy9kc0mQO9YqwnzjUY If/osX7jLumAObs8gPEmH8MhUHAAXTCCBaIwggSKoAMCAQICDBxmO6qdufc5yhZ6iDANBgkqhkiG 9w0BAQsFADBpMQswCQYDVQQGEwJERTEuMCwGA1UEChMlUGh5c2lrYWxpc2NoLVRlY2huaXNjaGUg QnVuZGVzYW5zdGFsdDEPMA0GA1UEAxMGUFRCIENBMRkwFwYJKoZIhvcNAQkBFgpwa2lAcHRiLmRl MB4XDTE2MTIwNjEzMzMxNFoXDTE5MDcwOTIzNTkwMFowaDELMAkGA1UEBhMCREUxLjAsBgNVBAoM JVBoeXNpa2FsaXNjaC1UZWNobmlzY2hlIEJ1bmRlc2Fuc3RhbHQxDTALBgNVBAsMBFEuNDIxGjAY BgNVBAMMEURyLiBEaWV0ZXIgU2lib2xkMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA +AOQrmrEQ2k8s9su/TVvmdF46YbL2MuF6OvnrjjKaJIkBvchop87cCwv80aZEbmU3as54egQEMGn NFkp1fF4bics4TJdEpND116l+jbi5DCtA3hHP/spV1aQZBDc/BDkm1Nl5WYKh/DxN6sUhZxorbb4 Y0nmSxnK2ctIwuF4Qdibsw7GE2YLvWF4tlzSCGbDjSy2agSn1wYHMsC+tAcFflcMXF2sDMZHkYuq 5IHwng8GBQFhsldYl1fk2sB2/hVRLYU205qaj13H94WjfDLuB22sT17XPJ2U/9tuFN/sxAPR0/N4 y4/IgMnOaP30VU0FMmULd7qJg0WST5D5kwgMhwIDAQABo4ICSTCCAkUwQAYDVR0gBDkwNzARBg8r BgEEAYGtIYIsAQEEAwUwEQYPKwYBBAGBrSGCLAIBBAMBMA8GDSsGAQQBga0hgiwBAQQwCQYDVR0T BAIwADAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1Ud DgQWBBQHn42zKDpvJi1bsJ4OVk2A9liUFjAfBgNVHSMEGDAWgBTEgNBuKBVoMVrscF94juEwQzjq NDBEBgNVHREEPTA7gRRkaWV0ZXIuc2lib2xkQHB0Yi5kZaAjBgorBgEEAYI3FAIDoBUME3NpYm9s ZDAxQHBhZC5wdGIuZGUwdwYDVR0fBHAwbjA1oDOgMYYvaHR0cDovL2NkcDEucGNhLmRmbi5kZS9w dGItY2EvcHViL2NybC9jYWNybC5jcmwwNaAzoDGGL2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvcHRi LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIHHBggrBgEFBQcBAQSBujCBtzAzBggrBgEFBQcwAYYnaHR0 cDovL29jc3AucGNhLmRmbi5kZS9PQ1NQLVNlcnZlci9PQ1NQMD8GCCsGAQUFBzAChjNodHRwOi8v Y2RwMS5wY2EuZGZuLmRlL3B0Yi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwPwYIKwYBBQUHMAKG M2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvcHRiLWNhL3B1Yi9jYWNlcnQvY2FjZXJ0LmNydDANBgkq hkiG9w0BAQsFAAOCAQEADaSfgrrQZx9eiQrCK7kgJMpLstro5OgIcWSpW4i4AQ1wEwyDUrdB1XWK GjA8/KwExSBP9a+dcdW+ACjX7TyURQPLqRTOkoPc9dafRx327mV4K8PE8z7fg5l2ittYNs0nXlOB QevRbYYP4XUOMYohFWfHpDwEg3ExmoArb2HaQCzKhq/2VcIIXTwaN6AVr2NVKEuH3qwpgOUSlJJ1 5ORb6TD4p1G2W6XT3jk3tOa8nRaOkI5hqpPvLfbPEibn+Bfqm6GWqpXfQ6NLAvWYcI8ltSKgdnCw Rmqdh1Ba/KWGdm41PDtQIx58vgbZGfN5GKJrp+OwS5D+/e/r296qoKUBRDCCBaIwggSKoAMCAQIC DBxmO6qdufc5yhZ6iDANBgkqhkiG9w0BAQsFADBpMQswCQYDVQQGEwJERTEuMCwGA1UEChMlUGh5 c2lrYWxpc2NoLVRlY2huaXNjaGUgQnVuZGVzYW5zdGFsdDEPMA0GA1UEAxMGUFRCIENBMRkwFwYJ KoZIhvcNAQkBFgpwa2lAcHRiLmRlMB4XDTE2MTIwNjEzMzMxNFoXDTE5MDcwOTIzNTkwMFowaDEL MAkGA1UEBhMCREUxLjAsBgNVBAoMJVBoeXNpa2FsaXNjaC1UZWNobmlzY2hlIEJ1bmRlc2Fuc3Rh bHQxDTALBgNVBAsMBFEuNDIxGjAYBgNVBAMMEURyLiBEaWV0ZXIgU2lib2xkMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA+AOQrmrEQ2k8s9su/TVvmdF46YbL2MuF6OvnrjjKaJIkBvch op87cCwv80aZEbmU3as54egQEMGnNFkp1fF4bics4TJdEpND116l+jbi5DCtA3hHP/spV1aQZBDc /BDkm1Nl5WYKh/DxN6sUhZxorbb4Y0nmSxnK2ctIwuF4Qdibsw7GE2YLvWF4tlzSCGbDjSy2agSn 1wYHMsC+tAcFflcMXF2sDMZHkYuq5IHwng8GBQFhsldYl1fk2sB2/hVRLYU205qaj13H94WjfDLu B22sT17XPJ2U/9tuFN/sxAPR0/N4y4/IgMnOaP30VU0FMmULd7qJg0WST5D5kwgMhwIDAQABo4IC STCCAkUwQAYDVR0gBDkwNzARBg8rBgEEAYGtIYIsAQEEAwUwEQYPKwYBBAGBrSGCLAIBBAMBMA8G DSsGAQQBga0hgiwBAQQwCQYDVR0TBAIwADAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYB BQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQHn42zKDpvJi1bsJ4OVk2A9liUFjAfBgNVHSMEGDAW gBTEgNBuKBVoMVrscF94juEwQzjqNDBEBgNVHREEPTA7gRRkaWV0ZXIuc2lib2xkQHB0Yi5kZaAj BgorBgEEAYI3FAIDoBUME3NpYm9sZDAxQHBhZC5wdGIuZGUwdwYDVR0fBHAwbjA1oDOgMYYvaHR0 cDovL2NkcDEucGNhLmRmbi5kZS9wdGItY2EvcHViL2NybC9jYWNybC5jcmwwNaAzoDGGL2h0dHA6 Ly9jZHAyLnBjYS5kZm4uZGUvcHRiLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIHHBggrBgEFBQcBAQSB ujCBtzAzBggrBgEFBQcwAYYnaHR0cDovL29jc3AucGNhLmRmbi5kZS9PQ1NQLVNlcnZlci9PQ1NQ MD8GCCsGAQUFBzAChjNodHRwOi8vY2RwMS5wY2EuZGZuLmRlL3B0Yi1jYS9wdWIvY2FjZXJ0L2Nh Y2VydC5jcnQwPwYIKwYBBQUHMAKGM2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvcHRiLWNhL3B1Yi9j YWNlcnQvY2FjZXJ0LmNydDANBgkqhkiG9w0BAQsFAAOCAQEADaSfgrrQZx9eiQrCK7kgJMpLstro 5OgIcWSpW4i4AQ1wEwyDUrdB1XWKGjA8/KwExSBP9a+dcdW+ACjX7TyURQPLqRTOkoPc9dafRx32 7mV4K8PE8z7fg5l2ittYNs0nXlOBQevRbYYP4XUOMYohFWfHpDwEg3ExmoArb2HaQCzKhq/2VcII XTwaN6AVr2NVKEuH3qwpgOUSlJJ15ORb6TD4p1G2W6XT3jk3tOa8nRaOkI5hqpPvLfbPEibn+Bfq m6GWqpXfQ6NLAvWYcI8ltSKgdnCwRmqdh1Ba/KWGdm41PDtQIx58vgbZGfN5GKJrp+OwS5D+/e/r 296qoKUBRDGCAuMwggLfAgEBMHkwaTELMAkGA1UEBhMCREUxLjAsBgNVBAoTJVBoeXNpa2FsaXNj aC1UZWNobmlzY2hlIEJ1bmRlc2Fuc3RhbHQxDzANBgNVBAMTBlBUQiBDQTEZMBcGCSqGSIb3DQEJ ARYKcGtpQHB0Yi5kZQIMHGY7qp259znKFnqIMA0GCWCGSAFlAwQCAQUAoIIBOzAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzA4MzAxNTQyNDBaMC8GCSqGSIb3DQEJ BDEiBCAfOKAgLAKgERnBgYA4rd6RDGUm2Nh9bbdhaurMVoJqDDBDBgkqhkiG9w0BCQ8xNjA0MAcG BSsOAwIdMA4GCCqGSIb3DQMCAgIAgDAKBggqhkiG9w0DBzANBggqhkiG9w0DAgIBKDCBigYLKoZI hvcNAQkQAgsxe6B5MGkxCzAJBgNVBAYTAkRFMS4wLAYDVQQKEyVQaHlzaWthbGlzY2gtVGVjaG5p c2NoZSBCdW5kZXNhbnN0YWx0MQ8wDQYDVQQDEwZQVEIgQ0ExGTAXBgkqhkiG9w0BCQEWCnBraUBw dGIuZGUCDBxmO6qdufc5yhZ6iDANBgkqhkiG9w0BAQEFAASCAQAi9dHAOeRavasjmd9K6Kb8dSaQ LQI4XvZlSp1G+/7BDLOFGmIhKFV7cQeGIMlT4L758hhi5VySAYExRaOyRvywdxgXWRyxDi8+5BUT RXvRh7TmIFvQweoovl0MJuwPVPKV7/1g+zaI3xTTVQuuOO0flHrz8qHuXBrMVQOvLF9I2agwgFqf qrfumMsEMmwS/MeTlQnytaRsaMeXaheGTJ7PGH6z3oFIPo525+D59qHrjTpYdolYWdmIGk4UoLAg qJLRL+gZcAH9JpHQz5zqWebARy6qtQu93FO3rakJQz3yCwiGVVBDQron03EjP8B6hQaeSHXQThVP TyoH9HW5GQb/AAAAAA== ---------z35023_boundary_sign-- From ntp-bounces@ietf.org Wed Aug 30 08:42:47 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C0BBE124B18; Wed, 30 Aug 2017 08:42:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1504107767; bh=wvpUV2Cu1oSj54HBMoaO76RvZEF6HDbSeqM90ntP/bQ=; h=In-Reply-To:References:To:From:Date:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc; b=KWirgAjqDXgkkysaJmlaWuvFuJYB39TXv5v2exr9FO660TJAGLCGpPRciPsFqZYCx iiRAhRsohusoT069632y5fBhVYg55X5ygIpgWSIIW1/hQh0CPGhUKCSy1Inz1qxr4s ocPM1H8yXpnGk28ACN4s7D+FywEsqc6Bb4EGLA+U= 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 13E44124B18 for ; Wed, 30 Aug 2017 08:42:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 3eYdvBoEFZL2 for ; Wed, 30 Aug 2017 08:42:44 -0700 (PDT) Received: from mx1.bs.ptb.de (mx1.bs.ptb.de [IPv6:2001:638:610:bd01::120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D328C1201F8 for ; Wed, 30 Aug 2017 08:42:43 -0700 (PDT) Received: from smtp-hub.bs.ptb.de (smtpint01.bs.ptb.de [141.25.87.32]) by mx1.bs.ptb.de with ESMTP id v7UFggvI012360-v7UFggvK012360 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 30 Aug 2017 17:42:42 +0200 Received: from rose.bs.ptb.de (rose.bs.ptb.de [141.25.85.201]) by smtp-hub.bs.ptb.de (Postfix) with ESMTPS id 009325346E4; Wed, 30 Aug 2017 17:42:41 +0200 (CEST) In-Reply-To: <9b9c364b-22d5-ca8f-aa80-6f99f632749d@libertysys.com.au> References: <9b9c364b-22d5-ca8f-aa80-6f99f632749d@libertysys.com.au> To: Paul Gear MIME-Version: 1.0 Message-ID: From: dieter.sibold@ptb.de Date: Wed, 30 Aug 2017 17:42:39 +0200 Archived-At: Subject: [Ntp] Antwort: Re: [NTP] WGLC for draft-ietf-ntp-using-nts-for-ntp (Requirements Language / NTP Pools) X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: ntp@ietf.org Content-Type: multipart/mixed; boundary="===============2602513876093389461==" Errors-To: ntp-bounces@ietf.org Sender: "ntp" This is an S/MIME signed message. --===============2602513876093389461== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha-256; boundary=-------z35023_boundary_sign This is an S/MIME signed message. ---------z35023_boundary_sign Content-Type: multipart/alternative; boundary="=_alternative 00564DB1C125818C_=" Dies ist eine mehrteilige Nachricht im MIME-Format. --=_alternative 00564DB1C125818C_= Content-Type: text/plain; charset="US-ASCII" Hi Paul, thanks for your input. Please, see my replies below. Dieter "ntp" schrieb am 30.08.2017 11:40:26: > Von: Paul Gear > An: ntp@ietf.org > Datum: 30.08.2017 11:40 > Betreff: Re: [Ntp] [NTP] WGLC for draft-ietf-ntp-using-nts-for-ntp > (Requirements Language / NTP Pools) > Gesendet von: "ntp" > > On 30/08/17 16:50, kristof.teichel@ptb.de wrote: > > > > 3.) > > I like the current name "cookie placeholder" over the suggestion > > "cookie request", simply because the former is more descriptive with > > regard to the same-length notion. > > I do, however, not have a strong opinion on this. > > I don't have a strong opinion on this either; I just found that on > initial reading it made more sense to think of it in this way - > especially when viewed in light of the fact that the number of cookie > placeholders normally indicates to the server the number of missed > replies since the last exchange. > > > > > 5.) (Also goes to an issue raised implicitly by Harlan & Dave) > > Concerning the NTP pools passage, I think there is something to the > > raised concerns, but I would approach the issue via the phrasing of > > the paragraph. > > I suggest instead of simply saying "pool operators" or "pools" (which > > does silently imply ALL of them). we move to saying "some pool > > operators / pools", since the problem persists even if it does not > > concern all instances. > > My text suggestion is: > > > > "[...] A more important matter, however, is that not all pool > > operators have procedures for establishing and maintaining trust in > > their members. > > Pools in existence as of 2017 are often volunteer-run, some of > > them with minimal requirements for admission and/or with no organized > > effort to monitor pool servers for misbehavior. [...]" > > Is there more than one pool? I'm only aware of pool.ntp.org, which is > volunteer-run and has minimal requirements for admission, but certainly > monitors its members. Results of this monitoring are publicly available > at http://www.pool.ntp.org/scores/[IP address] (e.g. here's one of mine: > http://www.pool.ntp.org/scores/2001:44b8:2100:3f00::7b). I think this > qualifies as "an organised effort to monitor pool servers for misbehavior". > > > I think this text does the same thing for the conclusion (in general, > > using pools with NTS is a bad idea), but hopefully more people will > > view it as factually correct. > > I would hope that this conclusion is specifically what NTS is aiming to > avoid. With respect to NTS' privacy/unlinkability aims, I would have > thought that the most common use case would be with garden variety > phones, tablets, PCs, & IoT devices, many (most?) of which use the NTP > pool. Aiming for a system which works with the pool would bring the > greatest privacy benefit to the greatest number of users. (And I would > argue that the pool requiring NTS support from participants could become > a useful tool in driving NTS adoption, once the questions about > certificate validation are answered.) I acknowledge that the usage of pools would be very helpful. And don't understand me wrong. I like the pools and honor there work. But I still see problems with the trust of a pool. As far as I know pools it is pretty easy to become a member of a pool. Therefore, a malicious NTP-Server can become a member of the pool, he can perfectly synchronized to UTC and still send me false timestamps. The monitoring done by the ntp pool volunteers is great but it is not sufficient to establish trust in the pool members. That would be different if the pool representatives could guarantee that all of there members are trustworthy. Currently, I think this is not possible. But perhaps I'm wrong. I'd like to learn better. > > Regards, > Paul > > _______________________________________________ > ntp mailing list > ntp@ietf.org > https://www.ietf.org/mailman/listinfo/ntp --=_alternative 00564DB1C125818C_= Content-Type: text/html; charset="US-ASCII" Hi Paul, thanks for your input. Please, see my replies below.

Dieter

"ntp" <ntp-bounces@ietf.org> schrieb am 30.08.2017 11:40:26:

> Von: Paul Gear <ntp@libertysys.com.au>
> An: ntp@ietf.org
> Datum: 30.08.2017 11:40
> Betreff: Re: [Ntp] [NTP] WGLC for draft-ietf-ntp-using-nts-for-ntp
> (Requirements Language / NTP Pools)
> Gesendet von: "ntp" <ntp-bounces@ietf.org>
>
> On 30/08/17 16:50, kristof.teichel@ptb.de wrote:
> >
> > 3.)
> > I like the current name "cookie placeholder" over the suggestion
> > "cookie request", simply because the former is more descriptive with
> > regard to the same-length notion.
> > I do, however, not have a strong opinion on this.
>
> I don't have a strong opinion on this either; I just found that on
> initial reading it made more sense to think of it in this way -
> especially when viewed in light of the fact that the number of cookie
> placeholders normally indicates to the server the number of missed
> replies since the last exchange.
>
> >
> > 5.) (Also goes to an issue raised implicitly by Harlan & Dave)
> > Concerning the NTP pools passage, I think there is something to the
> > raised concerns, but I would approach the issue via the phrasing of
> > the paragraph.
> > I suggest instead of simply saying "pool operators" or "pools" (which
> > does silently imply ALL of them). we move to saying "some pool
> > operators / pools", since the problem persists even if it does not
> > concern all instances.
> > My text suggestion is:
> >
> >         "[...] A more important matter, however, is that not all pool
> > operators have procedures for establishing and maintaining trust in
> > their members.
> >         Pools in existence as of 2017 are often volunteer-run, some of
> > them with minimal requirements for admission and/or with no organized
> > effort to monitor pool servers for misbehavior. [...]"
>
> Is there more than one pool?  I'm only aware of pool.ntp.org, which is
> volunteer-run and has minimal requirements for admission, but certainly
> monitors its members.  Results of this monitoring are publicly available
> at http://www.pool.ntp.org/scores/[IP address] (e.g. here's one of mine:
> http://www.pool.ntp.org/scores/2001:44b8:2100:3f00::7b).  I think this
> qualifies as "an organised effort to monitor pool servers for misbehavior".
>
> > I think this text does the same thing for the conclusion (in general,
> > using pools with NTS is a bad idea), but hopefully more people will
> > view it as factually correct.
>
> I would hope that this conclusion is specifically what NTS is aiming to
> avoid.  With respect to NTS' privacy/unlinkability aims, I would have
> thought that the most common use case would be with garden variety
> phones, tablets, PCs, & IoT devices, many (most?) of which use the NTP
> pool.  Aiming for a system which works with the pool would bring the
> greatest privacy benefit to the greatest number of users.  (And I would
> argue that the pool requiring NTS support from participants could become
> a useful tool in driving NTS adoption, once the questions about
> certificate validation are answered.)

I acknowledge that the usage of pools would be very helpful. And  don't understand me wrong. I like the pools and honor there work. But I still see problems with the trust of a pool. As far as I know pools it is pretty easy to become a member of a pool. Therefore, a malicious NTP-Server can become a member of the pool, he can perfectly synchronized to UTC and still send me false timestamps. The monitoring done by the ntp pool volunteers  is great but it is not sufficient to establish trust in the pool members. That would be different if the pool representatives could guarantee that all of there members are trustworthy. Currently, I think this is not possible. But perhaps I'm wrong. I'd like to learn better.



>
> Regards,
> Paul
>
> _______________________________________________
> ntp mailing list
> ntp@ietf.org
> https://www.ietf.org/mailman/listinfo/ntp
 --=_alternative 00564DB1C125818C_=-- ---------z35023_boundary_sign Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIIp0gIBATEPMA0GCWCGSAFlAwQCAQUAMAsGCSqGSIb3DQEHAaCCJsYw ggOfMIICh6ADAgECAgEmMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNE ZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYD VQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw05OTA3MDkxMjExMDBaFw0xOTA3MDky MzU5MDBaMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYD VQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJv b3QgQ0EgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKsLozXgiykUsRSFrzwQ5Dlv NV1Krt3qYY2VSfRvZKMaYGakqUAihNnUpeV4kw5oAa25TVw6ztO4qEJA38+juoJZapIbrBya2ggr JSf5aSNH8eDrLHqb9RMC0H40fMKePABZq/XaDPUyPCusUNrWw96DlMqoDJkyDghIVltq+9rhWFgB SV9yQTwVBgGOXa2quJO0zZ7rp+hqLVI02zrvXHVR2tvzMfnucZgyxFQVRAz5m1Xtrd8YCKCjhopJ 7lMFjxlM1d5YeZvSahxCq8XVp89oD5bk4WGYdmHIkXzWPgDikVCH4Z0K5q2X0h3GOn3LvNoDNNWO WwH1age3FrZuSn8CAwEAAaNCMEAwHQYDVR0OBBYEFDHDeRu69VPXF+CJei0XbAqzK50zMA8GA1Ud EwQIMAYBAf8CAQUwDgYDVR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBBQUAA4IBAQCUZFmtOWTnKesT /lrDixNXyAQk8HR3wGDjZ/vpiaaDv5aCfG7Uwz3vnoBuuym0mHqxO1TrORdHfhqOC/wfMVkxBLLO F/Msx2I2VeIi2IlVtJhIqmT61hw22ER4WlojOleX9XowT66fakxLK46gA+M+4KnU0nvSs6jicjyt nv+AWeSbRbT2O7DNORmYMuXqIWGQ5DEhjjSx9y81SoUQ2ueKNyG+WWPg8oWIMVPUVBSFcHn0LgZ3 J3UvH7iK+f7Futg25IPs52W3v2Na80avgZQ31EGM1iPWHs/1aBtEY6Jauqc1WaHlcAWbDiNXmZQK bbo5YyiGkvMYhNj70c8FVmRXMIIDnzCCAoegAwIBAgIBJjANBgkqhkiG9w0BAQUFADBxMQswCQYD VQQGEwJERTEcMBoGA1UEChMTRGV1dHNjaGUgVGVsZWtvbSBBRzEfMB0GA1UECxMWVC1UZWxlU2Vj IFRydXN0IENlbnRlcjEjMCEGA1UEAxMaRGV1dHNjaGUgVGVsZWtvbSBSb290IENBIDIwHhcNOTkw NzA5MTIxMTAwWhcNMTkwNzA5MjM1OTAwWjBxMQswCQYDVQQGEwJERTEcMBoGA1UEChMTRGV1dHNj aGUgVGVsZWtvbSBBRzEfMB0GA1UECxMWVC1UZWxlU2VjIFRydXN0IENlbnRlcjEjMCEGA1UEAxMa RGV1dHNjaGUgVGVsZWtvbSBSb290IENBIDIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCrC6M14IspFLEUha88EOQ5bzVdSq7d6mGNlUn0b2SjGmBmpKlAIoTZ1KXleJMOaAGtuU1cOs7T uKhCQN/Po7qCWWqSG6wcmtoIKyUn+WkjR/Hg6yx6m/UTAtB+NHzCnjwAWav12gz1MjwrrFDa1sPe g5TKqAyZMg4ISFZbavva4VhYAUlfckE8FQYBjl2tqriTtM2e66foai1SNNs671x1Udrb8zH57nGY MsRUFUQM+ZtV7a3fGAigo4aKSe5TBY8ZTNXeWHmb0mocQqvF1afPaA+W5OFhmHZhyJF81j4A4pFQ h+GdCuatl9Idxjp9y7zaAzTVjlsB9WoHtxa2bkp/AgMBAAGjQjBAMB0GA1UdDgQWBBQxw3kbuvVT 1xfgiXotF2wKsyudMzAPBgNVHRMECDAGAQH/AgEFMA4GA1UdDwEB/wQEAwIBBjANBgkqhkiG9w0B AQUFAAOCAQEAlGRZrTlk5ynrE/5aw4sTV8gEJPB0d8Bg42f76Ymmg7+Wgnxu1MM9756AbrsptJh6 sTtU6zkXR34ajgv8HzFZMQSyzhfzLMdiNlXiItiJVbSYSKpk+tYcNthEeFpaIzpXl/V6ME+un2pM SyuOoAPjPuCp1NJ70rOo4nI8rZ7/gFnkm0W09juwzTkZmDLl6iFhkOQxIY40sfcvNUqFENrnijch vllj4PKFiDFT1FQUhXB59C4Gdyd1Lx+4ivn+xbrYNuSD7Odlt79jWvNGr4GUN9RBjNYj1h7P9Wgb RGOiWrqnNVmh5XAFmw4jV5mUCm26OWMohpLzGITY+9HPBVZkVzCCBNUwggO9oAMCAQICCFBOxvU9 EbRkMA0GCSqGSIb3DQEBCwUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNEZXV0c2NoZSBUZWxl a29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYDVQQDExpEZXV0c2No ZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0xNDA3MjIxMjA4MjZaFw0xOTA3MDkyMzU5MDBaMFoxCzAJ BgNVBAYTAkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQD ExtERk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U1wBblSJ01CDrNI/W7MAxBAuZgeKmFNJSoCgjhIt0 iQReW+DieMF4yxbLKDU5ey2QRdDtoAB6fL9KDhsAw4bpXCsxEXsM84IkQ4wcOItqaACa7txPeKvS xhObdq3u3ibo7wGvdA/BCaL2a869080UME/15eOkyGKbghoDJzANAmVgTe3RCSMqljVYJ9N2xnG2 kB3E7f81hn1vM7PbD8URwoqDoZRdQWvY0hD1TP3KUazZve+Sg7va64sWVlZDz+HVEz2mHycwzUlU 28kTNJpxdcVs6qcLmPkhnSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjggGGMIIBgjAOBgNVHQ8BAf8E BAMCAQYwHQYDVR0OBBYEFEm3xs/oPR9/6kR7Eyn38QpwPt5kMB8GA1UdIwQYMBaAFDHDeRu69VPX F+CJei0XbAqzK50zMBIGA1UdEwEB/wQIMAYBAf8CAQIwYgYDVR0gBFswWTARBg8rBgEEAYGtIYIs AQEEAgIwEQYPKwYBBAGBrSGCLAEBBAMAMBEGDysGAQQBga0hgiwBAQQDATAPBg0rBgEEAYGtIYIs AQEEMA0GCysGAQQBga0hgiweMD4GA1UdHwQ3MDUwM6AxoC+GLWh0dHA6Ly9wa2kwMzM2LnRlbGVz ZWMuZGUvcmwvRFRfUk9PVF9DQV8yLmNybDB4BggrBgEFBQcBAQRsMGowLAYIKwYBBQUHMAGGIGh0 dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMDoGCCsGAQUFBzAChi5odHRwOi8vcGtpMDMz Ni50ZWxlc2VjLmRlL2NydC9EVF9ST09UX0NBXzIuY2VyMA0GCSqGSIb3DQEBCwUAA4IBAQBjICj9 nCGGcr45Rlk5MiW8qQGbDczKfUGchm0KbiyzE1l1sTOSG2EnFv/DstU1gvuEKgFJvWa7Zi+ywgZd bj9u4wFaW8pDY1yVtuExpx/VB19N5mWCTjL5w3x6S81NXHTuIfJ1AuxSPtLJatOQI25JZzW+f01W pOzML8+3oZeocj7JvEDWWqQIPda8gsO3tzKOsSyOam23NQIZz/U5RFhjpyQAELC7/E6vbi84u6VX ST/YblBvLJeW3B1GmmWJz67M8uXZn1OzPqEvkqnYC8aEHwTG6x7on321e6UC8STFJGMRNMxakyAq eYg6JUKQqWU7fIbTEhUjKfws2sw5W1QXMIIE1TCCA72gAwIBAgIIUE7G9T0RtGQwDQYJKoZIhvcN AQELBQAwcTELMAkGA1UEBhMCREUxHDAaBgNVBAoTE0RldXRzY2hlIFRlbGVrb20gQUcxHzAdBgNV BAsTFlQtVGVsZVNlYyBUcnVzdCBDZW50ZXIxIzAhBgNVBAMTGkRldXRzY2hlIFRlbGVrb20gUm9v dCBDQSAyMB4XDTE0MDcyMjEyMDgyNloXDTE5MDcwOTIzNTkwMFowWjELMAkGA1UEBhMCREUxEzAR BgNVBAoTCkRGTi1WZXJlaW4xEDAOBgNVBAsTB0RGTi1QS0kxJDAiBgNVBAMTG0RGTi1WZXJlaW4g UENBIEdsb2JhbCAtIEcwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOmbw2eF+Q2u 9Y1Uw5ZQNT1i6W5M7ZTXAFuVInTUIOs0j9bswDEEC5mB4qYU0lKgKCOEi3SJBF5b4OJ4wXjLFsso NTl7LZBF0O2gAHp8v0oOGwDDhulcKzERewzzgiRDjBw4i2poAJru3E94q9LGE5t2re7eJujvAa90 D8EJovZrzr3TzRQwT/Xl46TIYpuCGgMnMA0CZWBN7dEJIyqWNVgn03bGcbaQHcTt/zWGfW8zs9sP xRHCioOhlF1Ba9jSEPVM/cpRrNm975KDu9rrixZWVkPP4dUTPaYfJzDNSVTbyRM0mnF1xWzqpwuY +SGdJ68+ozk5SGqMrcmZ+8MS8r0CAwEAAaOCAYYwggGCMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4E FgQUSbfGz+g9H3/qRHsTKffxCnA+3mQwHwYDVR0jBBgwFoAUMcN5G7r1U9cX4Il6LRdsCrMrnTMw EgYDVR0TAQH/BAgwBgEB/wIBAjBiBgNVHSAEWzBZMBEGDysGAQQBga0hgiwBAQQCAjARBg8rBgEE AYGtIYIsAQEEAwAwEQYPKwYBBAGBrSGCLAEBBAMBMA8GDSsGAQQBga0hgiwBAQQwDQYLKwYBBAGB rSGCLB4wPgYDVR0fBDcwNTAzoDGgL4YtaHR0cDovL3BraTAzMzYudGVsZXNlYy5kZS9ybC9EVF9S T09UX0NBXzIuY3JsMHgGCCsGAQUFBwEBBGwwajAsBggrBgEFBQcwAYYgaHR0cDovL29jc3AwMzM2 LnRlbGVzZWMuZGUvb2NzcHIwOgYIKwYBBQUHMAKGLmh0dHA6Ly9wa2kwMzM2LnRlbGVzZWMuZGUv Y3J0L0RUX1JPT1RfQ0FfMi5jZXIwDQYJKoZIhvcNAQELBQADggEBAGMgKP2cIYZyvjlGWTkyJbyp AZsNzMp9QZyGbQpuLLMTWXWxM5IbYScW/8Oy1TWC+4QqAUm9ZrtmL7LCBl1uP27jAVpbykNjXJW2 4TGnH9UHX03mZYJOMvnDfHpLzU1cdO4h8nUC7FI+0slq05AjbklnNb5/TVak7Mwvz7ehl6hyPsm8 QNZapAg91ryCw7e3Mo6xLI5qbbc1AhnP9TlEWGOnJAAQsLv8Tq9uLzi7pVdJP9huUG8sl5bcHUaa ZYnPrszy5dmfU7M+oS+SqdgLxoQfBMbrHuiffbV7pQLxJMUkYxE0zFqTICp5iDolQpCpZTt8htMS FSMp/CzazDlbVBcwggU9MIIEJaADAgECAgcXr/adVkv+MA0GCSqGSIb3DQEBCwUAMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtE Rk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwHhcNMTQwNjA1MTQwNTAyWhcNMTkwNzA5MjM1OTAw WjBpMQswCQYDVQQGEwJERTEuMCwGA1UEChMlUGh5c2lrYWxpc2NoLVRlY2huaXNjaGUgQnVuZGVz YW5zdGFsdDEPMA0GA1UEAxMGUFRCIENBMRkwFwYJKoZIhvcNAQkBFgpwa2lAcHRiLmRlMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvArCgzkqw2LMAYuU38VJTgyGBC+Pp+uvw52LmtI6 MEMiFr0xY6SEzYcDG3z5NSohZisdnL7bu8Ee7MFD3TZX1jVBie//UNAJqXbHnUzE8hbJYCR5ydb9 WqIzoT5PzG07qJWblbidcrZVcCQEef9V1CaRyfXuqiSTOgibqODLP98N7jMIImz2ipUgMdoGyOgS h/qds5SM6CUgwMeuJ42QpYNot9ri1IKAweyhIIa3TANsu56scy+Fc2+XWOfsuImeeLcaiu6HJPk6 X55QT+kWaAoQf6qJyJXv8b/n6l1nmTIU2AY2B5EnO/rIT+DW+MJy77/HO+7rtwaznuntXMgytwID AQABo4IB9zCCAfMwEgYDVR0TAQH/BAgwBgEB/wIBATAOBgNVHQ8BAf8EBAMCAQYwEQYDVR0gBAow CDAGBgRVHSAAMB0GA1UdDgQWBBTEgNBuKBVoMVrscF94juEwQzjqNDAfBgNVHSMEGDAWgBRJt8bP 6D0ff+pEexMp9/EKcD7eZDAVBgNVHREEDjAMgQpwa2lAcHRiLmRlMIGIBgNVHR8EgYAwfjA9oDug OYY3aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY3JsL2NhY3JsLmNy bDA9oDugOYY3aHR0cDovL2NkcDIucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY3JsL2Nh Y3JsLmNybDCB1wYIKwYBBQUHAQEEgcowgccwMwYIKwYBBQUHMAGGJ2h0dHA6Ly9vY3NwLnBjYS5k Zm4uZGUvT0NTUC1TZXJ2ZXIvT0NTUDBHBggrBgEFBQcwAoY7aHR0cDovL2NkcDEucGNhLmRmbi5k ZS9nbG9iYWwtcm9vdC1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwRwYIKwYBBQUHMAKGO2h0dHA6 Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MA0G CSqGSIb3DQEBCwUAA4IBAQCo3hebMpEocLPJTOlDMAmSzpxK3SA1ftaQqodbMncOi9WkeICQlmIv rQxGCq8Be/6hKtIrbFOhRtSzQi870glJRj7dhZaHC+WOgT5tP5Nkgwpgl4k4pQDXPPrwmaI6cSYD a/LpprQzBNjEQMdQqkeanpD0WU9U1pOPFIMfIrxh2cy8mBpIAMuZqMHbMyPNDZk/YN4r3b2DcBrQ wL/tHerp6Vc7n9WqO+3cm7Fa4AxL9q2KeItyYe0Cws2KZNz4IuiMjQAclNL0PhTEqIzkD/EiK6Ag 1qcH7o3ktpmakvL2RzSZA71irCfONRgh/+ixfuMu6YA5uzyA8SYfwyFQcABdMIIFPTCCBCWgAwIB AgIHF6/2nVZL/jANBgkqhkiG9w0BAQsFADBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZOLVZl cmVpbjEQMA4GA1UECxMHREZOLVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xvYmFsIC0g RzAxMB4XDTE0MDYwNTE0MDUwMloXDTE5MDcwOTIzNTkwMFowaTELMAkGA1UEBhMCREUxLjAsBgNV BAoTJVBoeXNpa2FsaXNjaC1UZWNobmlzY2hlIEJ1bmRlc2Fuc3RhbHQxDzANBgNVBAMTBlBUQiBD QTEZMBcGCSqGSIb3DQEJARYKcGtpQHB0Yi5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALwKwoM5KsNizAGLlN/FSU4MhgQvj6frr8Odi5rSOjBDIha9MWOkhM2HAxt8+TUqIWYrHZy+ 27vBHuzBQ902V9Y1QYnv/1DQCal2x51MxPIWyWAkecnW/VqiM6E+T8xtO6iVm5W4nXK2VXAkBHn/ VdQmkcn17qokkzoIm6jgyz/fDe4zCCJs9oqVIDHaBsjoEof6nbOUjOglIMDHrieNkKWDaLfa4tSC gMHsoSCGt0wDbLuerHMvhXNvl1jn7LiJnni3GoruhyT5Ol+eUE/pFmgKEH+qiciV7/G/5+pdZ5ky FNgGNgeRJzv6yE/g1vjCcu+/xzvu67cGs57p7VzIMrcCAwEAAaOCAfcwggHzMBIGA1UdEwEB/wQI MAYBAf8CAQEwDgYDVR0PAQH/BAQDAgEGMBEGA1UdIAQKMAgwBgYEVR0gADAdBgNVHQ4EFgQUxIDQ bigVaDFa7HBfeI7hMEM46jQwHwYDVR0jBBgwFoAUSbfGz+g9H3/qRHsTKffxCnA+3mQwFQYDVR0R BA4wDIEKcGtpQHB0Yi5kZTCBiAYDVR0fBIGAMH4wPaA7oDmGN2h0dHA6Ly9jZHAxLnBjYS5kZm4u ZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NybC9jYWNybC5jcmwwPaA7oDmGN2h0dHA6Ly9jZHAyLnBj YS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NybC9jYWNybC5jcmwwgdcGCCsGAQUFBwEBBIHK MIHHMDMGCCsGAQUFBzABhidodHRwOi8vb2NzcC5wY2EuZGZuLmRlL09DU1AtU2VydmVyL09DU1Aw RwYIKwYBBQUHMAKGO2h0dHA6Ly9jZHAxLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2Nh Y2VydC9jYWNlcnQuY3J0MEcGCCsGAQUFBzAChjtodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2dsb2Jh bC1yb290LWNhL3B1Yi9jYWNlcnQvY2FjZXJ0LmNydDANBgkqhkiG9w0BAQsFAAOCAQEAqN4XmzKR KHCzyUzpQzAJks6cSt0gNX7WkKqHWzJ3DovVpHiAkJZiL60MRgqvAXv+oSrSK2xToUbUs0IvO9IJ SUY+3YWWhwvljoE+bT+TZIMKYJeJOKUA1zz68JmiOnEmA2vy6aa0MwTYxEDHUKpHmp6Q9FlPVNaT jxSDHyK8YdnMvJgaSADLmajB2zMjzQ2ZP2DeK929g3Aa0MC/7R3q6elXO5/Vqjvt3JuxWuAMS/at iniLcmHtAsLNimTc+CLojI0AHJTS9D4UxKiM5A/xIiugINanB+6N5LaZmpLy9kc0mQO9YqwnzjUY If/osX7jLumAObs8gPEmH8MhUHAAXTCCBaIwggSKoAMCAQICDBxmO6qdufc5yhZ6iDANBgkqhkiG 9w0BAQsFADBpMQswCQYDVQQGEwJERTEuMCwGA1UEChMlUGh5c2lrYWxpc2NoLVRlY2huaXNjaGUg QnVuZGVzYW5zdGFsdDEPMA0GA1UEAxMGUFRCIENBMRkwFwYJKoZIhvcNAQkBFgpwa2lAcHRiLmRl MB4XDTE2MTIwNjEzMzMxNFoXDTE5MDcwOTIzNTkwMFowaDELMAkGA1UEBhMCREUxLjAsBgNVBAoM JVBoeXNpa2FsaXNjaC1UZWNobmlzY2hlIEJ1bmRlc2Fuc3RhbHQxDTALBgNVBAsMBFEuNDIxGjAY BgNVBAMMEURyLiBEaWV0ZXIgU2lib2xkMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA +AOQrmrEQ2k8s9su/TVvmdF46YbL2MuF6OvnrjjKaJIkBvchop87cCwv80aZEbmU3as54egQEMGn NFkp1fF4bics4TJdEpND116l+jbi5DCtA3hHP/spV1aQZBDc/BDkm1Nl5WYKh/DxN6sUhZxorbb4 Y0nmSxnK2ctIwuF4Qdibsw7GE2YLvWF4tlzSCGbDjSy2agSn1wYHMsC+tAcFflcMXF2sDMZHkYuq 5IHwng8GBQFhsldYl1fk2sB2/hVRLYU205qaj13H94WjfDLuB22sT17XPJ2U/9tuFN/sxAPR0/N4 y4/IgMnOaP30VU0FMmULd7qJg0WST5D5kwgMhwIDAQABo4ICSTCCAkUwQAYDVR0gBDkwNzARBg8r BgEEAYGtIYIsAQEEAwUwEQYPKwYBBAGBrSGCLAIBBAMBMA8GDSsGAQQBga0hgiwBAQQwCQYDVR0T BAIwADAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1Ud DgQWBBQHn42zKDpvJi1bsJ4OVk2A9liUFjAfBgNVHSMEGDAWgBTEgNBuKBVoMVrscF94juEwQzjq NDBEBgNVHREEPTA7gRRkaWV0ZXIuc2lib2xkQHB0Yi5kZaAjBgorBgEEAYI3FAIDoBUME3NpYm9s ZDAxQHBhZC5wdGIuZGUwdwYDVR0fBHAwbjA1oDOgMYYvaHR0cDovL2NkcDEucGNhLmRmbi5kZS9w dGItY2EvcHViL2NybC9jYWNybC5jcmwwNaAzoDGGL2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvcHRi LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIHHBggrBgEFBQcBAQSBujCBtzAzBggrBgEFBQcwAYYnaHR0 cDovL29jc3AucGNhLmRmbi5kZS9PQ1NQLVNlcnZlci9PQ1NQMD8GCCsGAQUFBzAChjNodHRwOi8v Y2RwMS5wY2EuZGZuLmRlL3B0Yi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwPwYIKwYBBQUHMAKG M2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvcHRiLWNhL3B1Yi9jYWNlcnQvY2FjZXJ0LmNydDANBgkq hkiG9w0BAQsFAAOCAQEADaSfgrrQZx9eiQrCK7kgJMpLstro5OgIcWSpW4i4AQ1wEwyDUrdB1XWK GjA8/KwExSBP9a+dcdW+ACjX7TyURQPLqRTOkoPc9dafRx327mV4K8PE8z7fg5l2ittYNs0nXlOB QevRbYYP4XUOMYohFWfHpDwEg3ExmoArb2HaQCzKhq/2VcIIXTwaN6AVr2NVKEuH3qwpgOUSlJJ1 5ORb6TD4p1G2W6XT3jk3tOa8nRaOkI5hqpPvLfbPEibn+Bfqm6GWqpXfQ6NLAvWYcI8ltSKgdnCw Rmqdh1Ba/KWGdm41PDtQIx58vgbZGfN5GKJrp+OwS5D+/e/r296qoKUBRDCCBaIwggSKoAMCAQIC DBxmO6qdufc5yhZ6iDANBgkqhkiG9w0BAQsFADBpMQswCQYDVQQGEwJERTEuMCwGA1UEChMlUGh5 c2lrYWxpc2NoLVRlY2huaXNjaGUgQnVuZGVzYW5zdGFsdDEPMA0GA1UEAxMGUFRCIENBMRkwFwYJ KoZIhvcNAQkBFgpwa2lAcHRiLmRlMB4XDTE2MTIwNjEzMzMxNFoXDTE5MDcwOTIzNTkwMFowaDEL MAkGA1UEBhMCREUxLjAsBgNVBAoMJVBoeXNpa2FsaXNjaC1UZWNobmlzY2hlIEJ1bmRlc2Fuc3Rh bHQxDTALBgNVBAsMBFEuNDIxGjAYBgNVBAMMEURyLiBEaWV0ZXIgU2lib2xkMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA+AOQrmrEQ2k8s9su/TVvmdF46YbL2MuF6OvnrjjKaJIkBvch op87cCwv80aZEbmU3as54egQEMGnNFkp1fF4bics4TJdEpND116l+jbi5DCtA3hHP/spV1aQZBDc /BDkm1Nl5WYKh/DxN6sUhZxorbb4Y0nmSxnK2ctIwuF4Qdibsw7GE2YLvWF4tlzSCGbDjSy2agSn 1wYHMsC+tAcFflcMXF2sDMZHkYuq5IHwng8GBQFhsldYl1fk2sB2/hVRLYU205qaj13H94WjfDLu B22sT17XPJ2U/9tuFN/sxAPR0/N4y4/IgMnOaP30VU0FMmULd7qJg0WST5D5kwgMhwIDAQABo4IC STCCAkUwQAYDVR0gBDkwNzARBg8rBgEEAYGtIYIsAQEEAwUwEQYPKwYBBAGBrSGCLAIBBAMBMA8G DSsGAQQBga0hgiwBAQQwCQYDVR0TBAIwADAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYB BQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQHn42zKDpvJi1bsJ4OVk2A9liUFjAfBgNVHSMEGDAW gBTEgNBuKBVoMVrscF94juEwQzjqNDBEBgNVHREEPTA7gRRkaWV0ZXIuc2lib2xkQHB0Yi5kZaAj BgorBgEEAYI3FAIDoBUME3NpYm9sZDAxQHBhZC5wdGIuZGUwdwYDVR0fBHAwbjA1oDOgMYYvaHR0 cDovL2NkcDEucGNhLmRmbi5kZS9wdGItY2EvcHViL2NybC9jYWNybC5jcmwwNaAzoDGGL2h0dHA6 Ly9jZHAyLnBjYS5kZm4uZGUvcHRiLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIHHBggrBgEFBQcBAQSB ujCBtzAzBggrBgEFBQcwAYYnaHR0cDovL29jc3AucGNhLmRmbi5kZS9PQ1NQLVNlcnZlci9PQ1NQ MD8GCCsGAQUFBzAChjNodHRwOi8vY2RwMS5wY2EuZGZuLmRlL3B0Yi1jYS9wdWIvY2FjZXJ0L2Nh Y2VydC5jcnQwPwYIKwYBBQUHMAKGM2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvcHRiLWNhL3B1Yi9j YWNlcnQvY2FjZXJ0LmNydDANBgkqhkiG9w0BAQsFAAOCAQEADaSfgrrQZx9eiQrCK7kgJMpLstro 5OgIcWSpW4i4AQ1wEwyDUrdB1XWKGjA8/KwExSBP9a+dcdW+ACjX7TyURQPLqRTOkoPc9dafRx32 7mV4K8PE8z7fg5l2ittYNs0nXlOBQevRbYYP4XUOMYohFWfHpDwEg3ExmoArb2HaQCzKhq/2VcII XTwaN6AVr2NVKEuH3qwpgOUSlJJ15ORb6TD4p1G2W6XT3jk3tOa8nRaOkI5hqpPvLfbPEibn+Bfq m6GWqpXfQ6NLAvWYcI8ltSKgdnCwRmqdh1Ba/KWGdm41PDtQIx58vgbZGfN5GKJrp+OwS5D+/e/r 296qoKUBRDGCAuMwggLfAgEBMHkwaTELMAkGA1UEBhMCREUxLjAsBgNVBAoTJVBoeXNpa2FsaXNj aC1UZWNobmlzY2hlIEJ1bmRlc2Fuc3RhbHQxDzANBgNVBAMTBlBUQiBDQTEZMBcGCSqGSIb3DQEJ ARYKcGtpQHB0Yi5kZQIMHGY7qp259znKFnqIMA0GCWCGSAFlAwQCAQUAoIIBOzAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzA4MzAxNTQyNDBaMC8GCSqGSIb3DQEJ BDEiBCAfOKAgLAKgERnBgYA4rd6RDGUm2Nh9bbdhaurMVoJqDDBDBgkqhkiG9w0BCQ8xNjA0MAcG BSsOAwIdMA4GCCqGSIb3DQMCAgIAgDAKBggqhkiG9w0DBzANBggqhkiG9w0DAgIBKDCBigYLKoZI hvcNAQkQAgsxe6B5MGkxCzAJBgNVBAYTAkRFMS4wLAYDVQQKEyVQaHlzaWthbGlzY2gtVGVjaG5p c2NoZSBCdW5kZXNhbnN0YWx0MQ8wDQYDVQQDEwZQVEIgQ0ExGTAXBgkqhkiG9w0BCQEWCnBraUBw dGIuZGUCDBxmO6qdufc5yhZ6iDANBgkqhkiG9w0BAQEFAASCAQAi9dHAOeRavasjmd9K6Kb8dSaQ LQI4XvZlSp1G+/7BDLOFGmIhKFV7cQeGIMlT4L758hhi5VySAYExRaOyRvywdxgXWRyxDi8+5BUT RXvRh7TmIFvQweoovl0MJuwPVPKV7/1g+zaI3xTTVQuuOO0flHrz8qHuXBrMVQOvLF9I2agwgFqf qrfumMsEMmwS/MeTlQnytaRsaMeXaheGTJ7PGH6z3oFIPo525+D59qHrjTpYdolYWdmIGk4UoLAg qJLRL+gZcAH9JpHQz5zqWebARy6qtQu93FO3rakJQz3yCwiGVVBDQron03EjP8B6hQaeSHXQThVP TyoH9HW5GQb/AAAAAA== ---------z35023_boundary_sign-- --===============2602513876093389461== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp --===============2602513876093389461==-- From ntp-bounces@ietf.org Wed Aug 30 08:43:44 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8380B124B18; Wed, 30 Aug 2017 08:43:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1504107824; bh=mX+lYGbstTtkZWiMqN1HmS8mx/6gX3LRIGdyf3wZCgQ=; h=In-Reply-To:References:From:Date:To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc; b=UewnNBWt0D4PyVxOwuHFTURr8wekpxMXf5e4kBI0tyLgLCac9gLzWDzvGB4U/Eemj 7M6u9y/jhSveTuK84rHYAiavyCRupzXpcjSvc+iRy04QWRNBgWTSDaDyOWRHIipQQ+ htZL9XwDJX4GX/YPzEjIGuCEH9IT621xhmtkd6eE= 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 2014E124B18 for ; Wed, 30 Aug 2017 08:43:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 MqSC4ruLbAJV for ; Wed, 30 Aug 2017 08:43:41 -0700 (PDT) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (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 498491201F8 for ; Wed, 30 Aug 2017 08:43:41 -0700 (PDT) Received: by mail-wm0-x229.google.com with SMTP id a80so12619150wma.0 for ; Wed, 30 Aug 2017 08:43:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mUglkY1lxYNs8k7u2R0HWlBYeC1dh90UbkNdUXPfqe4=; b=kqRxAzLNAPtXaoTUwJeC89xc5R5PzVBVrR8pjCiqGdaws/0naNcbSsRUas9xebl71I inFhKd0jN7eWSpqelxoHsKuFTCTH3GxoX9q5F5xMiWAYFBzwW62XLsIF4Olhvt/YM9BC pxdBSwHDu7rZMB7/+s7zis3gmDpKyAlc4BKzVn/GJdz7l4r9Xvq2npvG+6mEY7MGLcqu Eug1dOge6YEjVQlHFwh6opN4cGfwUcqRGXFiALZm8KPF5Os50mR1BmK5p/PVsWw3GDD4 z4Q3Z3Q47C8Q3eoIY4P0MgPIOZoTJDWaKJq3vwr5LMwKGChfLPHZ3hxK8MYSb5pmN1Ql 4QKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=mUglkY1lxYNs8k7u2R0HWlBYeC1dh90UbkNdUXPfqe4=; b=suqwyAR4cxTeEEtMmiX3jvtE9apUosAY43CkRa8tVQ9g1Xv8kb/vBIz3790sAgphIM 16fM53iEzCCg9KV9wLcGiXo0wiRrYoP2cHDMc9uDCGl9xdGrzX65pUixIT/u+h2LzOWw 8Lg5Zm7xKr3kC4McSvO6dT2wbfwqRHkHn2xiBc2NUqQ9CSObLkLQRvSSKAbyWXlJNoMX toEuNWoBo4bdYJM4d/4pP2xWkidd2zKqPOWSjdR4O0FE2J4VzGV7/jqH+eT9HIINRMAR 43UcxCCGjZJFKnJRW5/IAE8sqbpt5Lu5i9Jjg049QnpJwe5iFHO5vpsM9Fxio3FggUhr NmNA== X-Gm-Message-State: AHYfb5j77VwJ9ciYkkX+fX55QBSZzErzKtZul7AX+xnAXl1IB5ZaPdk0 oHhBN+PCfggqxB7ralI2qX9077Aqq69F X-Received: by 10.80.186.82 with SMTP id 18mr1694862eds.86.1504107819669; Wed, 30 Aug 2017 08:43:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.157.140 with HTTP; Wed, 30 Aug 2017 08:43:38 -0700 (PDT) In-Reply-To: <9b9c364b-22d5-ca8f-aa80-6f99f632749d@libertysys.com.au> References: <9b9c364b-22d5-ca8f-aa80-6f99f632749d@libertysys.com.au> From: Daniel Franke Date: Wed, 30 Aug 2017 11:43:38 -0400 Message-ID: To: Paul Gear Archived-At: Subject: Re: [Ntp] [NTP] WGLC for draft-ietf-ntp-using-nts-for-ntp (Requirements Language / NTP Pools) X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: ntp@ietf.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ntp-bounces@ietf.org Sender: "ntp" On 8/30/17, Paul Gear wrote: > Is there more than one pool? I'm only aware of pool.ntp.org, which is > volunteer-run and has minimal requirements for admission, but certainly > monitors its members. Results of this monitoring are publicly available > at http://www.pool.ntp.org/scores/[IP address] (e.g. here's one of mine: > http://www.pool.ntp.org/scores/2001:44b8:2100:3f00::7b). I think this > qualifies as "an organised effort to monitor pool servers for misbehavior". I hadn't seen this. I'll drop that phrase. > I would hope that this conclusion is specifically what NTS is aiming to > avoid. With respect to NTS' privacy/unlinkability aims, I would have > thought that the most common use case would be with garden variety > phones, tablets, PCs, & IoT devices, many (most?) of which use the NTP > pool. Aiming for a system which works with the pool would bring the > greatest privacy benefit to the greatest number of users. (And I would > argue that the pool requiring NTS support from participants could become > a useful tool in driving NTS adoption, once the questions about > certificate validation are answered.) Oh, certainly, I eventually want us to get us to a point where you can just put something like 'nts-pool.ntp.org' in your config and get NTS-secured time. The purpose of that section is just to highlight the work that still needs doing before we can get there. _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp From nobody Wed Aug 30 08:43:45 2017 Return-Path: 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 2014E124B18 for ; Wed, 30 Aug 2017 08:43:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 MqSC4ruLbAJV for ; Wed, 30 Aug 2017 08:43:41 -0700 (PDT) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (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 498491201F8 for ; Wed, 30 Aug 2017 08:43:41 -0700 (PDT) Received: by mail-wm0-x229.google.com with SMTP id a80so12619150wma.0 for ; Wed, 30 Aug 2017 08:43:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mUglkY1lxYNs8k7u2R0HWlBYeC1dh90UbkNdUXPfqe4=; b=kqRxAzLNAPtXaoTUwJeC89xc5R5PzVBVrR8pjCiqGdaws/0naNcbSsRUas9xebl71I inFhKd0jN7eWSpqelxoHsKuFTCTH3GxoX9q5F5xMiWAYFBzwW62XLsIF4Olhvt/YM9BC pxdBSwHDu7rZMB7/+s7zis3gmDpKyAlc4BKzVn/GJdz7l4r9Xvq2npvG+6mEY7MGLcqu Eug1dOge6YEjVQlHFwh6opN4cGfwUcqRGXFiALZm8KPF5Os50mR1BmK5p/PVsWw3GDD4 z4Q3Z3Q47C8Q3eoIY4P0MgPIOZoTJDWaKJq3vwr5LMwKGChfLPHZ3hxK8MYSb5pmN1Ql 4QKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=mUglkY1lxYNs8k7u2R0HWlBYeC1dh90UbkNdUXPfqe4=; b=suqwyAR4cxTeEEtMmiX3jvtE9apUosAY43CkRa8tVQ9g1Xv8kb/vBIz3790sAgphIM 16fM53iEzCCg9KV9wLcGiXo0wiRrYoP2cHDMc9uDCGl9xdGrzX65pUixIT/u+h2LzOWw 8Lg5Zm7xKr3kC4McSvO6dT2wbfwqRHkHn2xiBc2NUqQ9CSObLkLQRvSSKAbyWXlJNoMX toEuNWoBo4bdYJM4d/4pP2xWkidd2zKqPOWSjdR4O0FE2J4VzGV7/jqH+eT9HIINRMAR 43UcxCCGjZJFKnJRW5/IAE8sqbpt5Lu5i9Jjg049QnpJwe5iFHO5vpsM9Fxio3FggUhr NmNA== X-Gm-Message-State: AHYfb5j77VwJ9ciYkkX+fX55QBSZzErzKtZul7AX+xnAXl1IB5ZaPdk0 oHhBN+PCfggqxB7ralI2qX9077Aqq69F X-Received: by 10.80.186.82 with SMTP id 18mr1694862eds.86.1504107819669; Wed, 30 Aug 2017 08:43:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.157.140 with HTTP; Wed, 30 Aug 2017 08:43:38 -0700 (PDT) In-Reply-To: <9b9c364b-22d5-ca8f-aa80-6f99f632749d@libertysys.com.au> References: <9b9c364b-22d5-ca8f-aa80-6f99f632749d@libertysys.com.au> From: Daniel Franke Date: Wed, 30 Aug 2017 11:43:38 -0400 Message-ID: To: Paul Gear Cc: ntp@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Ntp] [NTP] WGLC for draft-ietf-ntp-using-nts-for-ntp (Requirements Language / NTP Pools) X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 15:43:43 -0000 On 8/30/17, Paul Gear wrote: > Is there more than one pool? I'm only aware of pool.ntp.org, which is > volunteer-run and has minimal requirements for admission, but certainly > monitors its members. Results of this monitoring are publicly available > at http://www.pool.ntp.org/scores/[IP address] (e.g. here's one of mine: > http://www.pool.ntp.org/scores/2001:44b8:2100:3f00::7b). I think this > qualifies as "an organised effort to monitor pool servers for misbehavior". I hadn't seen this. I'll drop that phrase. > I would hope that this conclusion is specifically what NTS is aiming to > avoid. With respect to NTS' privacy/unlinkability aims, I would have > thought that the most common use case would be with garden variety > phones, tablets, PCs, & IoT devices, many (most?) of which use the NTP > pool. Aiming for a system which works with the pool would bring the > greatest privacy benefit to the greatest number of users. (And I would > argue that the pool requiring NTS support from participants could become > a useful tool in driving NTS adoption, once the questions about > certificate validation are answered.) Oh, certainly, I eventually want us to get us to a point where you can just put something like 'nts-pool.ntp.org' in your config and get NTS-secured time. The purpose of that section is just to highlight the work that still needs doing before we can get there. From nobody Wed Aug 30 08:59:09 2017 Return-Path: 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 2844E1320D8 for ; Wed, 30 Aug 2017 08:59:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 XVuI55-f_NNv for ; Wed, 30 Aug 2017 08:58:49 -0700 (PDT) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (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 62BAC132320 for ; Wed, 30 Aug 2017 08:58:48 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id u26so13428981wma.0 for ; Wed, 30 Aug 2017 08:58:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=67NNVBXovbUIQuiNrE5eFjG8DKRY4Tp0isl4KGkQLdc=; b=SxvowK6VOM5jke+iGfSAMh6skioOAtn7vAkEYPzhBlxqOSwIvNfp+YH8Y73D2JFmJa MI/t7occjI+5pgTf4aSRyUJFgmGXem5b82Wf1MikIyBmabiw+QvdqhDKt+6eoo2290rC ndui11XKEdQxY9APHjVauom75ddWXe+elasN9JV0TV1PX7gOhLjpGmxYw7zIeFIgu/is +t6aLd0HLtkHuQaBEaitpxUzB1e0BC2T/TNYsvAtx6OBf2ML5p81zR0mNNLZtmlgETqu /UCqPcYdYh/SAgp7AFol18YrDdEIK3ZiqB8xTEHpEEqwlH7oDQtJGsP7rFO40uA5t3Je Dasg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=67NNVBXovbUIQuiNrE5eFjG8DKRY4Tp0isl4KGkQLdc=; b=gRIbt60k+kii7y1yNqET8KpT6UFUG2Dx7DDSvGGgBQUzqLUSwlIQj4Qyo8akJuE12u KPey2Aen9cREVYH48Ur8a92nLn5ZQToEPjmkXMC67LfwGcemAAY5V1A5kCXCHcTsKXe2 nqigiASUHn+UKBYS78jncgf2Yfqtvbo+5NoDS8q2cpjMfaebgZLR8tO8gIMq2n1kZm+b f1yNtWZL8E2np68Ae4l9B6zViwT5gON0Mvd6o4+g51uahuhPWFtFKCmEXe/aT1A25t5V zGkEi3pR4DOKbb7zhG4MQ0Amf+Z0Ugf9G91o78vFHKaIKgaKkho1CjL9pzOKUEtDdsAK kfJw== X-Gm-Message-State: AHYfb5juk7cOpEv7c0TvaavFf43DJBQ32xEwyw4KHtTwiy/28gu+YtiF h0EAQEXkjfJL32/qa5kIek2Rnq8Tow== X-Received: by 10.80.240.149 with SMTP id v21mr2268463edl.54.1504108726815; Wed, 30 Aug 2017 08:58:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.157.140 with HTTP; Wed, 30 Aug 2017 08:58:46 -0700 (PDT) In-Reply-To: References: <9b9c364b-22d5-ca8f-aa80-6f99f632749d@libertysys.com.au> From: Daniel Franke Date: Wed, 30 Aug 2017 11:58:46 -0400 Message-ID: To: Paul Gear Cc: ntp@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Ntp] [NTP] WGLC for draft-ietf-ntp-using-nts-for-ntp (Requirements Language / NTP Pools) X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 15:59:04 -0000 New language for that section: Additional standardization work and infrastructure development is necessary before NTS can be used with public NTP server pools. First, a scheme will need to be specified for determining what constitutes an acceptable certificate for a pool server, such as establishing a value required to be contained in its Extended Key Usage attribute, and how to determine, given the DNS name of a pool, what Subject Alternative Name to expect in the certificates of its members. Implementing any such specification will necessitate infrastructure work: pool organizers will need to act as certificate authorities, regularly monitor the behavior of servers to which certificates have been issued, and promptly revoke the certificate of any server found to be serving incorrect time. On 8/30/17, Daniel Franke wrote: > On 8/30/17, Paul Gear wrote: >> Is there more than one pool? I'm only aware of pool.ntp.org, which is >> volunteer-run and has minimal requirements for admission, but certainly >> monitors its members. Results of this monitoring are publicly available >> at http://www.pool.ntp.org/scores/[IP address] (e.g. here's one of mine: >> http://www.pool.ntp.org/scores/2001:44b8:2100:3f00::7b). I think this >> qualifies as "an organised effort to monitor pool servers for >> misbehavior". > > I hadn't seen this. I'll drop that phrase. > >> I would hope that this conclusion is specifically what NTS is aiming to >> avoid. With respect to NTS' privacy/unlinkability aims, I would have >> thought that the most common use case would be with garden variety >> phones, tablets, PCs, & IoT devices, many (most?) of which use the NTP >> pool. Aiming for a system which works with the pool would bring the >> greatest privacy benefit to the greatest number of users. (And I would >> argue that the pool requiring NTS support from participants could become >> a useful tool in driving NTS adoption, once the questions about >> certificate validation are answered.) > > Oh, certainly, I eventually want us to get us to a point where you can > just put something like 'nts-pool.ntp.org' in your config and get > NTS-secured time. The purpose of that section is just to highlight the > work that still needs doing before we can get there. > From ntp-bounces@ietf.org Wed Aug 30 08:59:09 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DA8C13213F; Wed, 30 Aug 2017 08:59:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1504108749; bh=TGW/3K4upid0EB6xz1aFN38CrjICFdV/ZuHacL1kRvU=; h=In-Reply-To:References:From:Date:To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc; b=Sub9DtxGrHDqTnQV31Ef1gfHcxyByx8b6S7NbwVqkE3Esv0bx6f5hGRygXJ+Gw9iH bYpW4hJbP3h4BIbEzELCqzz1MQAbK5GakBgwyzfdvdlN7VwhZBLFuOW7JP3YwfzKzB ux8yU0GVAdjgNx2+Kcn4+XH4t9SmTioF1K4fJOXw= 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 2844E1320D8 for ; Wed, 30 Aug 2017 08:59:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 XVuI55-f_NNv for ; Wed, 30 Aug 2017 08:58:49 -0700 (PDT) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (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 62BAC132320 for ; Wed, 30 Aug 2017 08:58:48 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id u26so13428981wma.0 for ; Wed, 30 Aug 2017 08:58:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=67NNVBXovbUIQuiNrE5eFjG8DKRY4Tp0isl4KGkQLdc=; b=SxvowK6VOM5jke+iGfSAMh6skioOAtn7vAkEYPzhBlxqOSwIvNfp+YH8Y73D2JFmJa MI/t7occjI+5pgTf4aSRyUJFgmGXem5b82Wf1MikIyBmabiw+QvdqhDKt+6eoo2290rC ndui11XKEdQxY9APHjVauom75ddWXe+elasN9JV0TV1PX7gOhLjpGmxYw7zIeFIgu/is +t6aLd0HLtkHuQaBEaitpxUzB1e0BC2T/TNYsvAtx6OBf2ML5p81zR0mNNLZtmlgETqu /UCqPcYdYh/SAgp7AFol18YrDdEIK3ZiqB8xTEHpEEqwlH7oDQtJGsP7rFO40uA5t3Je Dasg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=67NNVBXovbUIQuiNrE5eFjG8DKRY4Tp0isl4KGkQLdc=; b=gRIbt60k+kii7y1yNqET8KpT6UFUG2Dx7DDSvGGgBQUzqLUSwlIQj4Qyo8akJuE12u KPey2Aen9cREVYH48Ur8a92nLn5ZQToEPjmkXMC67LfwGcemAAY5V1A5kCXCHcTsKXe2 nqigiASUHn+UKBYS78jncgf2Yfqtvbo+5NoDS8q2cpjMfaebgZLR8tO8gIMq2n1kZm+b f1yNtWZL8E2np68Ae4l9B6zViwT5gON0Mvd6o4+g51uahuhPWFtFKCmEXe/aT1A25t5V zGkEi3pR4DOKbb7zhG4MQ0Amf+Z0Ugf9G91o78vFHKaIKgaKkho1CjL9pzOKUEtDdsAK kfJw== X-Gm-Message-State: AHYfb5juk7cOpEv7c0TvaavFf43DJBQ32xEwyw4KHtTwiy/28gu+YtiF h0EAQEXkjfJL32/qa5kIek2Rnq8Tow== X-Received: by 10.80.240.149 with SMTP id v21mr2268463edl.54.1504108726815; Wed, 30 Aug 2017 08:58:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.157.140 with HTTP; Wed, 30 Aug 2017 08:58:46 -0700 (PDT) In-Reply-To: References: <9b9c364b-22d5-ca8f-aa80-6f99f632749d@libertysys.com.au> From: Daniel Franke Date: Wed, 30 Aug 2017 11:58:46 -0400 Message-ID: To: Paul Gear Archived-At: Subject: Re: [Ntp] [NTP] WGLC for draft-ietf-ntp-using-nts-for-ntp (Requirements Language / NTP Pools) X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: ntp@ietf.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ntp-bounces@ietf.org Sender: "ntp" New language for that section: Additional standardization work and infrastructure development is necessary before NTS can be used with public NTP server pools. First, a scheme will need to be specified for determining what constitutes an acceptable certificate for a pool server, such as establishing a value required to be contained in its Extended Key Usage attribute, and how to determine, given the DNS name of a pool, what Subject Alternative Name to expect in the certificates of its members. Implementing any such specification will necessitate infrastructure work: pool organizers will need to act as certificate authorities, regularly monitor the behavior of servers to which certificates have been issued, and promptly revoke the certificate of any server found to be serving incorrect time. On 8/30/17, Daniel Franke wrote: > On 8/30/17, Paul Gear wrote: >> Is there more than one pool? I'm only aware of pool.ntp.org, which is >> volunteer-run and has minimal requirements for admission, but certainly >> monitors its members. Results of this monitoring are publicly available >> at http://www.pool.ntp.org/scores/[IP address] (e.g. here's one of mine: >> http://www.pool.ntp.org/scores/2001:44b8:2100:3f00::7b). I think this >> qualifies as "an organised effort to monitor pool servers for >> misbehavior". > > I hadn't seen this. I'll drop that phrase. > >> I would hope that this conclusion is specifically what NTS is aiming to >> avoid. With respect to NTS' privacy/unlinkability aims, I would have >> thought that the most common use case would be with garden variety >> phones, tablets, PCs, & IoT devices, many (most?) of which use the NTP >> pool. Aiming for a system which works with the pool would bring the >> greatest privacy benefit to the greatest number of users. (And I would >> argue that the pool requiring NTS support from participants could become >> a useful tool in driving NTS adoption, once the questions about >> certificate validation are answered.) > > Oh, certainly, I eventually want us to get us to a point where you can > just put something like 'nts-pool.ntp.org' in your config and get > NTS-secured time. The purpose of that section is just to highlight the > work that still needs doing before we can get there. > _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp From nobody Wed Aug 30 10:02:53 2017 Return-Path: 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 855421321B7 for ; Wed, 30 Aug 2017 10:02:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 3OB5z8gi-k2r for ; Wed, 30 Aug 2017 10:02:51 -0700 (PDT) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (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 C5CE51321A6 for ; Wed, 30 Aug 2017 10:02:50 -0700 (PDT) Received: by mail-wm0-x236.google.com with SMTP id u126so13758518wmg.1 for ; Wed, 30 Aug 2017 10:02:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=fDE4SKdKQXMgxQqaEBvWlAEOLBrm/2hX8M08B+JGvlk=; b=TPUmJ+ofFqdSZI35172J8OnJ0M63xtJjktyN+CBZM0yJtHfWYV0atE0aJGfJ44RUeo fXMGSozTTpl6P64CrLT5Izo1FI5ALQftrKDMJ3UiVycMhBDTEDLCtlle63bnvWroMP8v EG+eUwxiJtV14ceqPK2E3ITXK9DFkiGP/kKtLupzbDte7HckyImJzYPUmDbnxZl0ZZcR EQaEcRnyn7BwvJ50nwg/y3fop1PbaNhPCsJapKNe/LuCbJoYBF8oyJB3zszx9MZGgwJr HT+ndw6a/IPyitmtT5LRBWFaS1FsORP+reYQpzhCC70ILMPtpN5q7L/nKkJLm4yaKswi Fitw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=fDE4SKdKQXMgxQqaEBvWlAEOLBrm/2hX8M08B+JGvlk=; b=PIdXILb1TUXA3xK49LUa6GmYA4S02PwmLDYhvBS6KLttFdpEPQ7r0Il5/1eCAIZ6Zb ln/0wVzXVkMBb6+0mL5kCiGDl4pvpVu24zF8dfWGphlY4AuYwL8porhV3mXBf4pUpeAw 6DpeA+xioWnxhLlVXemLkWOdQVeQEgiN0s7V15VSKZDqQLzSxaqJshWGvXpiWgMV+yu2 fgCbRBskXKE9lwXRMJDtp8fO0dWJhSMm6N09QBXZtY9z/Z4y6rVwHCMziCmRAow0275P V1vd3GRX7itFVZsVIRSWM5etpl0fuGNScRH9rtUWX8wmEcMQfiFZeYWy9SheqqLEIsXD Vzmw== X-Gm-Message-State: AHYfb5i2GvgV+ElTTLjZM0tvG9pLq1M+nQ6LuKumUESuHmvK86IlZFhh rlwai4hiVgs7ygENurv1UMyxw1sOXaiA X-Received: by 10.80.159.138 with SMTP id c10mr2350493edf.257.1504112569025; Wed, 30 Aug 2017 10:02:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.157.140 with HTTP; Wed, 30 Aug 2017 10:02:48 -0700 (PDT) From: Daniel Franke Date: Wed, 30 Aug 2017 13:02:48 -0400 Message-ID: To: ntp@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [Ntp] NTS changelog since draft 9 X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 17:02:52 -0000 I've pushed some changes to the NTS git repo addressing all (and only) uncontroversial-looking feedback since last call. Summary of changes: * Fix misuse of "ntp/4" as an NTS Next Protocol ID * Fix remaining instances where DTLS-encapsulated NTPv4 was called "NTS-encapsulated NTPv4" * Rewrite the last two sentences regarding security considerations for pool servers, eliminating an inaccurate statement about present lack of monitoring. * Add several clarifications suggested by Martin Langer * Always refer to extension fields as such, not just "extensions" * Reword "user error" as "configuration error" * Fix the typo "symmetry" -> "symmetric" * Update acknowledgements section (add Scott Fluhrer and fix a typo) I'll post draft 10 on Friday morning, incorporating these changes along with anything else uncontroversial that comes up before the end of LC. From ntp-bounces@ietf.org Wed Aug 30 10:02:54 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F156E13233D; Wed, 30 Aug 2017 10:02:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1504112574; bh=H0pY8kdI8OYL1jVQ9Pz/xsAZgzuiTEsE8naWkZ+vrO0=; h=From:Date:To:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=Fi0ldMgl20VYfj9c0Okwr9Sf7ZdjliaTylzUmWmzQ2vA1WIs5OBM/ZP0W9ZGdplLh QvXY7srj/t9K8LnUpqh5EP4GctRXHbm9gpFl5QC3n9faRq0/FzEqNfk0hd0MHu4+XZ SH5NwS4SHmRDlfOpF64xp3JxnVuhQ+ByYuXr/iI8= 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 855421321B7 for ; Wed, 30 Aug 2017 10:02:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 3OB5z8gi-k2r for ; Wed, 30 Aug 2017 10:02:51 -0700 (PDT) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (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 C5CE51321A6 for ; Wed, 30 Aug 2017 10:02:50 -0700 (PDT) Received: by mail-wm0-x236.google.com with SMTP id u126so13758518wmg.1 for ; Wed, 30 Aug 2017 10:02:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=fDE4SKdKQXMgxQqaEBvWlAEOLBrm/2hX8M08B+JGvlk=; b=TPUmJ+ofFqdSZI35172J8OnJ0M63xtJjktyN+CBZM0yJtHfWYV0atE0aJGfJ44RUeo fXMGSozTTpl6P64CrLT5Izo1FI5ALQftrKDMJ3UiVycMhBDTEDLCtlle63bnvWroMP8v EG+eUwxiJtV14ceqPK2E3ITXK9DFkiGP/kKtLupzbDte7HckyImJzYPUmDbnxZl0ZZcR EQaEcRnyn7BwvJ50nwg/y3fop1PbaNhPCsJapKNe/LuCbJoYBF8oyJB3zszx9MZGgwJr HT+ndw6a/IPyitmtT5LRBWFaS1FsORP+reYQpzhCC70ILMPtpN5q7L/nKkJLm4yaKswi Fitw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=fDE4SKdKQXMgxQqaEBvWlAEOLBrm/2hX8M08B+JGvlk=; b=PIdXILb1TUXA3xK49LUa6GmYA4S02PwmLDYhvBS6KLttFdpEPQ7r0Il5/1eCAIZ6Zb ln/0wVzXVkMBb6+0mL5kCiGDl4pvpVu24zF8dfWGphlY4AuYwL8porhV3mXBf4pUpeAw 6DpeA+xioWnxhLlVXemLkWOdQVeQEgiN0s7V15VSKZDqQLzSxaqJshWGvXpiWgMV+yu2 fgCbRBskXKE9lwXRMJDtp8fO0dWJhSMm6N09QBXZtY9z/Z4y6rVwHCMziCmRAow0275P V1vd3GRX7itFVZsVIRSWM5etpl0fuGNScRH9rtUWX8wmEcMQfiFZeYWy9SheqqLEIsXD Vzmw== X-Gm-Message-State: AHYfb5i2GvgV+ElTTLjZM0tvG9pLq1M+nQ6LuKumUESuHmvK86IlZFhh rlwai4hiVgs7ygENurv1UMyxw1sOXaiA X-Received: by 10.80.159.138 with SMTP id c10mr2350493edf.257.1504112569025; Wed, 30 Aug 2017 10:02:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.157.140 with HTTP; Wed, 30 Aug 2017 10:02:48 -0700 (PDT) From: Daniel Franke Date: Wed, 30 Aug 2017 13:02:48 -0400 Message-ID: To: ntp@ietf.org Archived-At: Subject: [Ntp] NTS changelog since draft 9 X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ntp-bounces@ietf.org Sender: "ntp" I've pushed some changes to the NTS git repo addressing all (and only) uncontroversial-looking feedback since last call. Summary of changes: * Fix misuse of "ntp/4" as an NTS Next Protocol ID * Fix remaining instances where DTLS-encapsulated NTPv4 was called "NTS-encapsulated NTPv4" * Rewrite the last two sentences regarding security considerations for pool servers, eliminating an inaccurate statement about present lack of monitoring. * Add several clarifications suggested by Martin Langer * Always refer to extension fields as such, not just "extensions" * Reword "user error" as "configuration error" * Fix the typo "symmetry" -> "symmetric" * Update acknowledgements section (add Scott Fluhrer and fix a typo) I'll post draft 10 on Friday morning, incorporating these changes along with anything else uncontroversial that comes up before the end of LC. _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp From nobody Wed Aug 30 10:10:02 2017 Return-Path: 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 7EF48132396 for ; Wed, 30 Aug 2017 10:10:01 -0700 (PDT) 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=ham 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 tccGtMOVoqAb for ; Wed, 30 Aug 2017 10:09:59 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0063.outbound.protection.outlook.com [104.47.34.63]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 964FD1321E3 for ; Wed, 30 Aug 2017 10:09:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isoc.org; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Fi0qyHYTk04yC58zdM4mqb1q7GluRmN+diBqp4/EPEM=; b=w7RT3xWF/z88utDr/yT/Sxmr30UB6EmxAUOxzgoK6sm1SxPyYf+yPpC1JpcowSzmELVETBtX3DP8xIyjhGkXVfKe3CVylMQKOsP/8hP710uwShXGPDwgwP31jKxujtp7ZiuBSPwPCrCWSj2PvHCL7Q3Z30AzmFFfxC9VghvPLuI= Received: from CY4PR06MB2456.namprd06.prod.outlook.com (10.169.186.136) by CY4PR06MB2374.namprd06.prod.outlook.com (10.169.185.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.13.10; Wed, 30 Aug 2017 17:09:58 +0000 Received: from CY4PR06MB2456.namprd06.prod.outlook.com ([10.169.186.136]) by CY4PR06MB2456.namprd06.prod.outlook.com ([10.169.186.136]) with mapi id 15.20.0013.011; Wed, 30 Aug 2017 17:09:58 +0000 From: Karen O'Donoghue To: Daniel Franke CC: "ntp@ietf.org" Thread-Topic: [Ntp] NTS changelog since draft 9 Thread-Index: AQHTIbHUypF7IRCliU2Kimxf1oHFDqKdIjcA Date: Wed, 30 Aug 2017 17:09:58 +0000 Message-ID: References: In-Reply-To: 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: [12.236.17.11] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR06MB2374; 6:enaHhnjdWW0dIsd2HbgBvrrPlpNOqmH7xj+7u1Ykdn6Y2bYADwp2DkiFE7lS/KqYpm7IWUg7SRoF/XnKNNga13wZuRnPUJ1kC9A3wDk1w2OFVaXEHDiSf4hmYHvoTWmeo55+eXTf9jRbFWVN6yPNxiw+EE++gxofGQpdfZMIYVXICa+kjVsegwE7hYW86mZk96jmcNe44EqxkjSgCBKsltfLwk83+oOFEBDwF5xzUM55685elEI5iqH2t79PmQGCA5lkagIWir7yw1icYbufx911hm4/hTD+7H8UVVi8dnGHmVeCoMvHcNduVeTOv6/cQg7mDy7uY+ce09WV2Tjn7g==; 5:4TnczrrewpUvOyA5FOCv9CiWukILUFAkEQeoimtOxbB827ooaqyOgYC88fYR+g4H+Hf4rjHtTrUmqab1z8QNr9Fj6Fsu8bzNZf2m3gLLuhski47/tFUFCO2aqAgsILV7UBpIUO8A82cD0ZvceagpsQ==; 24:Su8MFU+FWBFERzRNTbLUmSPP6TbphUBoBaYscWoEOZ5E9Oa2QQ+qmwgp955k+rYSObapv+fXnrsKMtKLzHMgle3kpIovxOuoYGnRY47C7qE=; 7:lAES+phE7J3yuAr8QS90oL2d++qNZOVhlVwtYbRUrYk4aey1ocPXNWThfX8ZEfb84+WhfryZDz4qkb7U8LP/JikYCx/QCohw64PtyhOHMmeI1iNkWN3OjwVr4bAL0YVnyx8fJ4+mTsdn9JlQJIapE05IN67N+a4BT0rbvkIWBmTY9MEOZCQVqLEyf87HSUQk9Fzm/ANyEmYmWS4lpRl1h7xf2ArPDCSt0z7VII6rnB4= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 8ac719f2-a6fa-428f-4e02-08d4efc9f150 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY4PR06MB2374; x-ms-traffictypediagnostic: CY4PR06MB2374: x-exchange-antispam-report-test: UriScan:(166708455590820)(192374486261705); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(10201501046)(3002001)(93006095)(93001095)(6041248)(20161123562025)(20161123555025)(20161123564025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR06MB2374; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR06MB2374; x-forefront-prvs: 041517DFAB x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39830400002)(189002)(377454003)(199003)(24454002)(76176999)(189998001)(2950100002)(6916009)(7736002)(36756003)(229853002)(81166006)(101416001)(81156014)(2900100001)(25786009)(50986999)(54356999)(97736004)(82746002)(6512007)(8676002)(53546010)(6306002)(83716003)(53936002)(2906002)(68736007)(478600001)(6506006)(33656002)(99286003)(110136004)(14454004)(966005)(5660300001)(77096006)(6486002)(6436002)(105586002)(86362001)(6116002)(102836003)(3660700001)(106356001)(3846002)(1411001)(66066001)(6246003)(305945005)(3280700002)(8936002)(39060400002)(4326008)(59356010)(207903002)(219803003); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR06MB2374; H:CY4PR06MB2456.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: isoc.org does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Aug 2017 17:09:58.0869 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR06MB2374 Archived-At: Subject: Re: [Ntp] NTS changelog since draft 9 X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 17:10:01 -0000 Thank you Daniel. The summary is very helpful.=20 And as a reminder to the rest of the working group, all the individual chan= ges to the NTS spec are available publicly in the GitHub repository the aut= hors are using for document development.=20 https://github.com/dfoxfranke/nts Regards, Karen > On Aug 30, 2017, at 1:02 PM, Daniel Franke wrote: >=20 > I've pushed some changes to the NTS git repo addressing all (and only) > uncontroversial-looking feedback since last call. Summary of changes: >=20 > * Fix misuse of "ntp/4" as an NTS Next Protocol ID > * Fix remaining instances where DTLS-encapsulated NTPv4 was called > "NTS-encapsulated NTPv4" > * Rewrite the last two sentences regarding security considerations for > pool servers, eliminating an inaccurate statement about present lack > of monitoring. > * Add several clarifications suggested by Martin Langer > * Always refer to extension fields as such, not just "extensions" > * Reword "user error" as "configuration error" > * Fix the typo "symmetry" -> "symmetric" > * Update acknowledgements section (add Scott Fluhrer and fix a typo) >=20 > I'll post draft 10 on Friday morning, incorporating these changes > along with anything else uncontroversial that comes up before the end > of LC. >=20 > _______________________________________________ > ntp mailing list > ntp@ietf.org > https://www.ietf.org/mailman/listinfo/ntp From ntp-bounces@ietf.org Wed Aug 30 10:10:03 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3130F132396; Wed, 30 Aug 2017 10:10:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1504113003; bh=X6BP7mfYJtdlJZb2uDcEtJo+2ZOALyt3juRi85DM5H8=; h=From:To:Date:References:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc; b=yeAXyRFlIVDIzjcULk6eA6FiEF+bqdfD2bLTIwHadHVzYoHqKY3mSiVXPF3qpmn/o y1X25PluhlvuMR04lebd5uxlYxbz6pS7K/pnZ9wbR/IOr40sP+4S23WMkd63Ii+8Hf FHmonrrfggxvTTKzTJko/YImw6SkMI57MBIHUmbs= 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 7EF48132396 for ; Wed, 30 Aug 2017 10:10:01 -0700 (PDT) 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=ham 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 tccGtMOVoqAb for ; Wed, 30 Aug 2017 10:09:59 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0063.outbound.protection.outlook.com [104.47.34.63]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 964FD1321E3 for ; Wed, 30 Aug 2017 10:09:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isoc.org; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Fi0qyHYTk04yC58zdM4mqb1q7GluRmN+diBqp4/EPEM=; b=w7RT3xWF/z88utDr/yT/Sxmr30UB6EmxAUOxzgoK6sm1SxPyYf+yPpC1JpcowSzmELVETBtX3DP8xIyjhGkXVfKe3CVylMQKOsP/8hP710uwShXGPDwgwP31jKxujtp7ZiuBSPwPCrCWSj2PvHCL7Q3Z30AzmFFfxC9VghvPLuI= Received: from CY4PR06MB2456.namprd06.prod.outlook.com (10.169.186.136) by CY4PR06MB2374.namprd06.prod.outlook.com (10.169.185.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.13.10; Wed, 30 Aug 2017 17:09:58 +0000 Received: from CY4PR06MB2456.namprd06.prod.outlook.com ([10.169.186.136]) by CY4PR06MB2456.namprd06.prod.outlook.com ([10.169.186.136]) with mapi id 15.20.0013.011; Wed, 30 Aug 2017 17:09:58 +0000 From: Karen O'Donoghue To: Daniel Franke Thread-Topic: [Ntp] NTS changelog since draft 9 Thread-Index: AQHTIbHUypF7IRCliU2Kimxf1oHFDqKdIjcA Date: Wed, 30 Aug 2017 17:09:58 +0000 Message-ID: References: In-Reply-To: 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: [12.236.17.11] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR06MB2374; 6:enaHhnjdWW0dIsd2HbgBvrrPlpNOqmH7xj+7u1Ykdn6Y2bYADwp2DkiFE7lS/KqYpm7IWUg7SRoF/XnKNNga13wZuRnPUJ1kC9A3wDk1w2OFVaXEHDiSf4hmYHvoTWmeo55+eXTf9jRbFWVN6yPNxiw+EE++gxofGQpdfZMIYVXICa+kjVsegwE7hYW86mZk96jmcNe44EqxkjSgCBKsltfLwk83+oOFEBDwF5xzUM55685elEI5iqH2t79PmQGCA5lkagIWir7yw1icYbufx911hm4/hTD+7H8UVVi8dnGHmVeCoMvHcNduVeTOv6/cQg7mDy7uY+ce09WV2Tjn7g==; 5:4TnczrrewpUvOyA5FOCv9CiWukILUFAkEQeoimtOxbB827ooaqyOgYC88fYR+g4H+Hf4rjHtTrUmqab1z8QNr9Fj6Fsu8bzNZf2m3gLLuhski47/tFUFCO2aqAgsILV7UBpIUO8A82cD0ZvceagpsQ==; 24:Su8MFU+FWBFERzRNTbLUmSPP6TbphUBoBaYscWoEOZ5E9Oa2QQ+qmwgp955k+rYSObapv+fXnrsKMtKLzHMgle3kpIovxOuoYGnRY47C7qE=; 7:lAES+phE7J3yuAr8QS90oL2d++qNZOVhlVwtYbRUrYk4aey1ocPXNWThfX8ZEfb84+WhfryZDz4qkb7U8LP/JikYCx/QCohw64PtyhOHMmeI1iNkWN3OjwVr4bAL0YVnyx8fJ4+mTsdn9JlQJIapE05IN67N+a4BT0rbvkIWBmTY9MEOZCQVqLEyf87HSUQk9Fzm/ANyEmYmWS4lpRl1h7xf2ArPDCSt0z7VII6rnB4= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 8ac719f2-a6fa-428f-4e02-08d4efc9f150 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY4PR06MB2374; x-ms-traffictypediagnostic: CY4PR06MB2374: x-exchange-antispam-report-test: UriScan:(166708455590820)(192374486261705); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(10201501046)(3002001)(93006095)(93001095)(6041248)(20161123562025)(20161123555025)(20161123564025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR06MB2374; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR06MB2374; x-forefront-prvs: 041517DFAB x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39830400002)(189002)(377454003)(199003)(24454002)(76176999)(189998001)(2950100002)(6916009)(7736002)(36756003)(229853002)(81166006)(101416001)(81156014)(2900100001)(25786009)(50986999)(54356999)(97736004)(82746002)(6512007)(8676002)(53546010)(6306002)(83716003)(53936002)(2906002)(68736007)(478600001)(6506006)(33656002)(99286003)(110136004)(14454004)(966005)(5660300001)(77096006)(6486002)(6436002)(105586002)(86362001)(6116002)(102836003)(3660700001)(106356001)(3846002)(1411001)(66066001)(6246003)(305945005)(3280700002)(8936002)(39060400002)(4326008)(59356010)(207903002)(219803003); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR06MB2374; H:CY4PR06MB2456.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: isoc.org does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: MIME-Version: 1.0 X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Aug 2017 17:09:58.0869 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR06MB2374 Archived-At: Subject: Re: [Ntp] NTS changelog since draft 9 X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "ntp@ietf.org" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ntp-bounces@ietf.org Sender: "ntp" Thank you Daniel. The summary is very helpful. And as a reminder to the rest of the working group, all the individual changes to the NTS spec are available publicly in the GitHub repository the authors are using for document development. https://github.com/dfoxfranke/nts Regards, Karen > On Aug 30, 2017, at 1:02 PM, Daniel Franke wrote: > > I've pushed some changes to the NTS git repo addressing all (and only) > uncontroversial-looking feedback since last call. Summary of changes: > > * Fix misuse of "ntp/4" as an NTS Next Protocol ID > * Fix remaining instances where DTLS-encapsulated NTPv4 was called > "NTS-encapsulated NTPv4" > * Rewrite the last two sentences regarding security considerations for > pool servers, eliminating an inaccurate statement about present lack > of monitoring. > * Add several clarifications suggested by Martin Langer > * Always refer to extension fields as such, not just "extensions" > * Reword "user error" as "configuration error" > * Fix the typo "symmetry" -> "symmetric" > * Update acknowledgements section (add Scott Fluhrer and fix a typo) > > I'll post draft 10 on Friday morning, incorporating these changes > along with anything else uncontroversial that comes up before the end > of LC. > > _______________________________________________ > ntp mailing list > ntp@ietf.org > https://www.ietf.org/mailman/listinfo/ntp _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp From ntp-bounces@ietf.org Wed Aug 30 10:21:11 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 69A2C132344; Wed, 30 Aug 2017 10:21:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1504113671; bh=5Uxw7H7zOIwpwUae5NutJeGLzdIpxv7uwPrmE9n4HAQ=; h=From:To:Date:References:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc; b=xgpbDelj/BSHI7F7WeR33EPnaA5I4/GEbUKn/fvmEJj820AXx6X8fd5pBZxKOcxDz e2OiMa67aU9AV9dlNN2coWN/jo50k1UtBsCEkL3+FoFI3Mmf2Cx03yG7EBk+QVdfek PqpoDPJEh7INFBrPT0vK1XALYT1NedOeBZzlLFSM= 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 985AA13271F for ; Wed, 30 Aug 2017 10:21:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham 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 7FBLKDRJLexp for ; Wed, 30 Aug 2017 10:21:07 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0055.outbound.protection.outlook.com [104.47.37.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC5CD132705 for ; Wed, 30 Aug 2017 10:21:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isoc.org; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=bXdYGH+4XoVySSq6HWwnFnLIKp4Zkl6BRrFcYLhrWWs=; b=DfpKxiWOLiR6yThdoiy2EiTSOSrm0QI6/O5uyHHabB68eUZsXZJ++ftmQ+/RImXtc7a1f06QmKnbldRb2cIWtIqoHFdlZ5gOcmuys21WuauoRzYthsMPJeuQwgfjefRa5tUt3fhyJsXZru5T95JcuZFjyxnq1+jhP53yu+3ys0k= Received: from CY4PR06MB2456.namprd06.prod.outlook.com (10.169.186.136) by CY4PR06MB3285.namprd06.prod.outlook.com (10.171.244.36) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1385.9; Wed, 30 Aug 2017 17:21:04 +0000 Received: from CY4PR06MB2456.namprd06.prod.outlook.com ([10.169.186.136]) by CY4PR06MB2456.namprd06.prod.outlook.com ([10.169.186.136]) with mapi id 15.20.0013.011; Wed, 30 Aug 2017 17:21:04 +0000 From: Karen O'Donoghue To: Greg Dowd Thread-Topic: [Ntp] Antwort: Re: WGLC for draft-ietf-ntp-using-nts-for-ntp Thread-Index: AQHTIQDWJKBiJJ4BvEmLmpAAinUDdaKdAUcAgAAIuYCAAByzAA== Date: Wed, 30 Aug 2017 17:21:04 +0000 Message-ID: References: <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> <19062708.TpRPKSgBD8@eris> <8D2BF679AAC7C346848A489074F9F8BFD283080E@sjsrvexchmbx1.microsemi.net> In-Reply-To: <8D2BF679AAC7C346848A489074F9F8BFD283080E@sjsrvexchmbx1.microsemi.net> 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: [12.236.17.11] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR06MB3285; 6:jQihy/xPGyy7152PnYQvcs4Rs9E4zf8LYN0NeEEh3pTiEZrFsh9/5zOCr5fwbvX1hQlp1lRtfarrUUVI+ml2Ix5vGyXOuMC3Br6A7eJ+cALU1o09Pi6oerHc7qx+UkagyGD9Mle3mFuwvPTomQo67CeFWNyNDYWc+UdcPmcIg3UhOe/HIvS0tLvL4gqLGd5F+JQZFO1MmSQArqMz58zNV35DnWMi1KhRJBhWVh88MCFf2yNNRJWvjG7CUgxCjPJVCoeEr3brrV6WVEHvRKUyJzjpLk0LKFbHwbndc/+IepMddhHPisu6TdD4yBg/kKEiDJjc30t/s36dKAq8cNXFhA==; 5:VARrskCU9BT2QFQVLg8SSqNXV4MbQO1dqr8BobCKNbun/Vj2Zv1/S2Nw3xD2z78rwG3DCmRloTAyFIP+sYfFvZfjSRErXtw19cTICN/FsUiLrNyW6giA1I5tHtIi96esGD9eXpcNuyLhFR+dLbMDow==; 24:uMt0nuRcw5Nnedqx6mvRFXmQD57Gu4a6pSYn7ZNmdaIT12Mlm3QS9pS45cc9CPzHLGc8oGHXWsvtTuKqw2sttMUeQSUrAcSgE3OduVgOTU8=; 7:ahX906a/GPC2VDoulBaZ+nPTZcHJruX/713l2g4WAidtb92d8Q9ugmTMJRkpQvE4rc+4InlbUD0YXkKh1ZfOwbeU3FoNMgV2I2YMWHiqIJGdLf2ObVJh3W3c9osiWGpmkcLMJRw4b9AURo703A2KlMvz1xvG5AKxoNXkDHdIsqkz0jJCXvC3qX//alkskAqKQeZXfz0t1qWVgFYOKtYY+hYpQnnLv+dP/jbiZh3cuvw= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 8d89c052-b9bd-4db3-c14d-08d4efcb7e7c x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(300000502095)(300135100095)(22001)(2017030254152)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY4PR06MB3285; x-ms-traffictypediagnostic: CY4PR06MB3285: x-exchange-antispam-report-test: UriScan:(72170198267865); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(93006095)(93001095)(3002001)(10201501046)(6041248)(20161123560025)(20161123555025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR06MB3285; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR06MB3285; x-forefront-prvs: 041517DFAB x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39830400002)(189002)(13464003)(24454002)(199003)(377454003)(101416001)(229853002)(105586002)(230783001)(106356001)(97736004)(8676002)(8656003)(8936002)(83716003)(66066001)(2906002)(14454004)(93886005)(86362001)(25786009)(2950100002)(39060400002)(7736002)(6246003)(189998001)(110136004)(77096006)(6486002)(6506006)(81156014)(6436002)(6916009)(305945005)(68736007)(82746002)(36756003)(53936002)(4326008)(5890100001)(6306002)(5660300001)(6512007)(2900100001)(478600001)(54356999)(966005)(6116002)(54906002)(3660700001)(33656002)(102836003)(99286003)(3280700002)(81166006)(3846002)(50986999)(53546010)(76176999); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR06MB3285; H:CY4PR06MB2456.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: isoc.org does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: <929B7C289C7A934FA4FAD382A1A5CB84@namprd06.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Aug 2017 17:21:04.4486 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR06MB3285 Archived-At: Subject: Re: [Ntp] Antwort: Re: WGLC for draft-ietf-ntp-using-nts-for-ntp X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Dieter Sibold , "ntp@ietf.org" , "kristof.teichel@ptb.de" , Daniel Franke , Robert Annessi Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ntp-bounces@ietf.org Sender: "ntp" Folks, The PTP language is an artifact of when we thought we could achieve commonality between what the IETF NTP and the IEEE 1588 PTP communities were doing to address security. In the intervening time, the two approaches have diverged somewhat, and I think we need to focus here on getting an initial version of NTS out the door. I suggest we remove references to PTP in this document and revisit possible reuse or interoperation at a future time. I personally still believe it is worthwhile to work on easy interoperation between the two. Regards, Karen > On Aug 30, 2017, at 11:38 AM, Greg Dowd wrote: > > While I don't profess to know anything about the mapping of NTS to PTP, I would note that the telecom industry does use unicast flows for synchronization (PTP Profiles G.8265.1 for frequency and G.8275.2 for phase/tod). > > -----Original Message----- > From: ntp [mailto:ntp-bounces@ietf.org] On Behalf Of Dieter Sibold > Sent: Wednesday, August 30, 2017 8:07 AM > To: Daniel Franke ; kristof.teichel@ptb.de > Cc: ntp@ietf.org; Robert Annessi > Subject: Re: [Ntp] Antwort: Re: WGLC for draft-ietf-ntp-using-nts-for-ntp > > EXTERNAL EMAIL > > > As Robert pointed out with the lack of broadcast support we cannot protect PTP's timing messages. The only input of this draft to PTP could be the key exchange. Therefore, I also agree to drop PTP from this draft. > > Dieter > > -----Original Message----- > From: ntp [mailto:ntp-bounces@ietf.org] On Behalf Of Daniel Franke > Sent: Tuesday, August 29, 2017 9:56 PM > To: kristof.teichel@ptb.de > Cc: ntp@ietf.org; Robert Annessi > Subject: Re: [Ntp] Antwort: Re: WGLC for draft-ietf-ntp-using-nts-for-ntp > > On 8/29/17, kristof.teichel@ptb.de wrote: >> I knew there was something that I had wanted to contribute to the >> discussion for a long time but just kind of forgotten. >> This was it. >> >> I agree that this is a problem in the text, and I vote for taking out >> all passages that specifically mention PTP in this context. > > Well, you're the reason I had it there to begin with. I thought you and Dieter still had ambitions to get something working wrt PTP. If that's no longer the case then, without objection, I'll remove that reference from the intro. > > Besides the Terms and Abbreviations appendix, the only other reference to PTP is an IANA request to reserve NTS Next Protocol code 1 for use with PTP. Since we changed these codes from textual to numeric I guess there's no reason to keep that either; we can always request a new allocation once there's something concrete to attach to it. > > _______________________________________________ > ntp mailing list > ntp@ietf.org > https://www.ietf.org/mailman/listinfo/ntp > > _______________________________________________ > ntp mailing list > ntp@ietf.org > https://www.ietf.org/mailman/listinfo/ntp > > _______________________________________________ > ntp mailing list > ntp@ietf.org > https://www.ietf.org/mailman/listinfo/ntp _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp From nobody Wed Aug 30 10:21:23 2017 Return-Path: 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 985AA13271F for ; Wed, 30 Aug 2017 10:21:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham 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 7FBLKDRJLexp for ; Wed, 30 Aug 2017 10:21:07 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0055.outbound.protection.outlook.com [104.47.37.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC5CD132705 for ; Wed, 30 Aug 2017 10:21:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isoc.org; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=bXdYGH+4XoVySSq6HWwnFnLIKp4Zkl6BRrFcYLhrWWs=; b=DfpKxiWOLiR6yThdoiy2EiTSOSrm0QI6/O5uyHHabB68eUZsXZJ++ftmQ+/RImXtc7a1f06QmKnbldRb2cIWtIqoHFdlZ5gOcmuys21WuauoRzYthsMPJeuQwgfjefRa5tUt3fhyJsXZru5T95JcuZFjyxnq1+jhP53yu+3ys0k= Received: from CY4PR06MB2456.namprd06.prod.outlook.com (10.169.186.136) by CY4PR06MB3285.namprd06.prod.outlook.com (10.171.244.36) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1385.9; Wed, 30 Aug 2017 17:21:04 +0000 Received: from CY4PR06MB2456.namprd06.prod.outlook.com ([10.169.186.136]) by CY4PR06MB2456.namprd06.prod.outlook.com ([10.169.186.136]) with mapi id 15.20.0013.011; Wed, 30 Aug 2017 17:21:04 +0000 From: Karen O'Donoghue To: Greg Dowd CC: Dieter Sibold , Daniel Franke , "kristof.teichel@ptb.de" , "ntp@ietf.org" , Robert Annessi Thread-Topic: [Ntp] Antwort: Re: WGLC for draft-ietf-ntp-using-nts-for-ntp Thread-Index: AQHTIQDWJKBiJJ4BvEmLmpAAinUDdaKdAUcAgAAIuYCAAByzAA== Date: Wed, 30 Aug 2017 17:21:04 +0000 Message-ID: References: <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> <19062708.TpRPKSgBD8@eris> <8D2BF679AAC7C346848A489074F9F8BFD283080E@sjsrvexchmbx1.microsemi.net> In-Reply-To: <8D2BF679AAC7C346848A489074F9F8BFD283080E@sjsrvexchmbx1.microsemi.net> 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: [12.236.17.11] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR06MB3285; 6:jQihy/xPGyy7152PnYQvcs4Rs9E4zf8LYN0NeEEh3pTiEZrFsh9/5zOCr5fwbvX1hQlp1lRtfarrUUVI+ml2Ix5vGyXOuMC3Br6A7eJ+cALU1o09Pi6oerHc7qx+UkagyGD9Mle3mFuwvPTomQo67CeFWNyNDYWc+UdcPmcIg3UhOe/HIvS0tLvL4gqLGd5F+JQZFO1MmSQArqMz58zNV35DnWMi1KhRJBhWVh88MCFf2yNNRJWvjG7CUgxCjPJVCoeEr3brrV6WVEHvRKUyJzjpLk0LKFbHwbndc/+IepMddhHPisu6TdD4yBg/kKEiDJjc30t/s36dKAq8cNXFhA==; 5:VARrskCU9BT2QFQVLg8SSqNXV4MbQO1dqr8BobCKNbun/Vj2Zv1/S2Nw3xD2z78rwG3DCmRloTAyFIP+sYfFvZfjSRErXtw19cTICN/FsUiLrNyW6giA1I5tHtIi96esGD9eXpcNuyLhFR+dLbMDow==; 24:uMt0nuRcw5Nnedqx6mvRFXmQD57Gu4a6pSYn7ZNmdaIT12Mlm3QS9pS45cc9CPzHLGc8oGHXWsvtTuKqw2sttMUeQSUrAcSgE3OduVgOTU8=; 7:ahX906a/GPC2VDoulBaZ+nPTZcHJruX/713l2g4WAidtb92d8Q9ugmTMJRkpQvE4rc+4InlbUD0YXkKh1ZfOwbeU3FoNMgV2I2YMWHiqIJGdLf2ObVJh3W3c9osiWGpmkcLMJRw4b9AURo703A2KlMvz1xvG5AKxoNXkDHdIsqkz0jJCXvC3qX//alkskAqKQeZXfz0t1qWVgFYOKtYY+hYpQnnLv+dP/jbiZh3cuvw= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 8d89c052-b9bd-4db3-c14d-08d4efcb7e7c x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(300000502095)(300135100095)(22001)(2017030254152)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY4PR06MB3285; x-ms-traffictypediagnostic: CY4PR06MB3285: x-exchange-antispam-report-test: UriScan:(72170198267865); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(93006095)(93001095)(3002001)(10201501046)(6041248)(20161123560025)(20161123555025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR06MB3285; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR06MB3285; x-forefront-prvs: 041517DFAB x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39830400002)(189002)(13464003)(24454002)(199003)(377454003)(101416001)(229853002)(105586002)(230783001)(106356001)(97736004)(8676002)(8656003)(8936002)(83716003)(66066001)(2906002)(14454004)(93886005)(86362001)(25786009)(2950100002)(39060400002)(7736002)(6246003)(189998001)(110136004)(77096006)(6486002)(6506006)(81156014)(6436002)(6916009)(305945005)(68736007)(82746002)(36756003)(53936002)(4326008)(5890100001)(6306002)(5660300001)(6512007)(2900100001)(478600001)(54356999)(966005)(6116002)(54906002)(3660700001)(33656002)(102836003)(99286003)(3280700002)(81166006)(3846002)(50986999)(53546010)(76176999); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR06MB3285; H:CY4PR06MB2456.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: isoc.org does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-ID: <929B7C289C7A934FA4FAD382A1A5CB84@namprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Aug 2017 17:21:04.4486 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR06MB3285 Archived-At: Subject: Re: [Ntp] Antwort: Re: WGLC for draft-ietf-ntp-using-nts-for-ntp X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 17:21:09 -0000 Folks, The PTP language is an artifact of when we thought we could achieve commona= lity between what the IETF NTP and the IEEE 1588 PTP communities were doing= to address security. In the intervening time, the two approaches have dive= rged somewhat, and I think we need to focus here on getting an initial vers= ion of NTS out the door. I suggest we remove references to PTP in this docu= ment and revisit possible reuse or interoperation at a future time. I perso= nally still believe it is worthwhile to work on easy interoperation between= the two.=20 Regards, Karen > On Aug 30, 2017, at 11:38 AM, Greg Dowd wrote: >=20 > While I don't profess to know anything about the mapping of NTS to PTP, I= would note that the telecom industry does use unicast flows for synchroniz= ation (PTP Profiles G.8265.1 for frequency and G.8275.2 for phase/tod). =20 >=20 > -----Original Message----- > From: ntp [mailto:ntp-bounces@ietf.org] On Behalf Of Dieter Sibold > Sent: Wednesday, August 30, 2017 8:07 AM > To: Daniel Franke ; kristof.teichel@ptb.de > Cc: ntp@ietf.org; Robert Annessi > Subject: Re: [Ntp] Antwort: Re: WGLC for draft-ietf-ntp-using-nts-for-ntp >=20 > EXTERNAL EMAIL >=20 >=20 > As Robert pointed out with the lack of broadcast support we cannot protec= t PTP's timing messages. The only input of this draft to PTP could be the k= ey exchange. Therefore, I also agree to drop PTP from this draft. >=20 > Dieter >=20 > -----Original Message----- > From: ntp [mailto:ntp-bounces@ietf.org] On Behalf Of Daniel Franke > Sent: Tuesday, August 29, 2017 9:56 PM > To: kristof.teichel@ptb.de > Cc: ntp@ietf.org; Robert Annessi > Subject: Re: [Ntp] Antwort: Re: WGLC for draft-ietf-ntp-using-nts-for-ntp >=20 > On 8/29/17, kristof.teichel@ptb.de wrote: >> I knew there was something that I had wanted to contribute to the=20 >> discussion for a long time but just kind of forgotten. >> This was it. >>=20 >> I agree that this is a problem in the text, and I vote for taking out=20 >> all passages that specifically mention PTP in this context. >=20 > Well, you're the reason I had it there to begin with. I thought you and D= ieter still had ambitions to get something working wrt PTP. If that's no lo= nger the case then, without objection, I'll remove that reference from the = intro. >=20 > Besides the Terms and Abbreviations appendix, the only other reference to= PTP is an IANA request to reserve NTS Next Protocol code 1 for use with PT= P. Since we changed these codes from textual to numeric I guess there's no = reason to keep that either; we can always request a new allocation once the= re's something concrete to attach to it. >=20 > _______________________________________________ > ntp mailing list > ntp@ietf.org > https://www.ietf.org/mailman/listinfo/ntp >=20 > _______________________________________________ > ntp mailing list > ntp@ietf.org > https://www.ietf.org/mailman/listinfo/ntp >=20 > _______________________________________________ > ntp mailing list > ntp@ietf.org > https://www.ietf.org/mailman/listinfo/ntp From ntp-bounces@ietf.org Wed Aug 30 11:21:09 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0677E132355; Wed, 30 Aug 2017 11:21:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1504117269; bh=IUoW8cPmYBP+iKjn6bE6lu8r4yXAz4kS2aicaRH8hBY=; h=From:To:Date:References:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc; b=CMsDFzXSXfzauLwSNZ0tbEWJvWmpx9pRPF2aKEqrWULMbfzFik85RMgvzFcb3A5Ve aPzveglYFtHlqj31QuHF0hRHvyTflBFC8ebnm1pIQHUEyxXXDNUD/va4VxY3p2EaLP ePEgofGgmDq3Xzefj1vCp7fWrKmepQH0/lfZzDQs= 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 89372132355 for ; Wed, 30 Aug 2017 11:21:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] 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 AuPS5pN4_WO3 for ; Wed, 30 Aug 2017 11:21:06 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [67.231.149.131]) (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 241CC13217D for ; Wed, 30 Aug 2017 11:21:06 -0700 (PDT) Received: from pps.filterd (m0122332.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v7UIH1HJ026560; Wed, 30 Aug 2017 19:21:04 +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=vV4ye6xFUUlyaMg8T8grbRM/QbYEKPIzN2apYBoNDIc=; b=PK/8y4KiXWY7QFwt/wZiV3Q5yfd6xTLR6qFfI9w+hpuGT8qKWES3EsekDn+r+YxTn6Mf 1wkm+1H6vHVLZDXkM274tPmX0zuajyl3w/28FsO3ce7pf8Ypd07bsboX2Dyuhaz5J6RD LuhUSmfBkJHDjHFYafIC8cXQHuQ/w/TyBitQ+xv7jqC2VkeuttNJCZtcw2LpOjKSKUvl WyFFRAfHNxC63SdI2iOqCAJcgsOZy69d6Ks9/J8QH2QIH0cB+7j3iyBGljtnrGCTYJX6 itzlmO+T0j+jKdtk4A+bPEphf//EL54/ZlPdM1dZ3TpvfNoQ+UaAmBKtSBTQ+6SXIT31 Pw== Received: from prod-mail-ppoint4 ([96.6.114.87]) by mx0a-00190b01.pphosted.com with ESMTP id 2ck11efpqd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 30 Aug 2017 19:21:03 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v7UIKiUW008500; Wed, 30 Aug 2017 14:21:02 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint4.akamai.com with ESMTP id 2ck4avpq22-3 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 30 Aug 2017 14:21:02 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 30 Aug 2017 14:20:41 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Wed, 30 Aug 2017 14:20:39 -0400 From: "Salz, Rich" To: Karen O'Donoghue , Daniel Franke Thread-Topic: [Ntp] NTS changelog since draft 9 Thread-Index: AQHTIbHUYQo62yJ4HkOsJT6meZUHWqKdZUcA///QsQA= Date: Wed, 30 Aug 2017 18:20:38 +0000 Message-ID: <5BE6683D-396F-4FAA-B8E8-9E2C277B8A35@akamai.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1b.0.161010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.36.106] Content-ID: <1C4D2DAB80453D499498430FAA6ACD06@akamai.com> MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-30_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1708300279 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-30_08:, , 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 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1708300278 Archived-At: Subject: Re: [Ntp] NTS changelog since draft 9 X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "ntp@ietf.org" Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Errors-To: ntp-bounces@ietf.org Sender: "ntp" SSBoYXZlIGp1c3QgZmluaXNoZWQgcmVhZGluZyB0aGlzIGRvY3VtZW50LiAgSeKAmWxsIHRyeSBu b3QgdG8gZGlzY3VzcyB0aGluZ3MgdGhhdCBoYXZlIGFscmVhZHkgYmVlbiBvbiB0aGUgbWFpbGlu ZyBsaXN0ICBCdXQgc2luY2UgaXQganVzdCBjYW1lIHVwIHdoaWxlIEkgd2FzIHdyaXRpbmcgdGhp cyBlbWFpbCwgSSB3YW50IHRvIHNheSBJIGFncmVlIHRoYXQgYWxsIHJlZmVyZW5jZXMgdG8gUFRQ IHNob3VsZCBiZSByZW1vdmVkIChlLmcuIGxpbmVzIDY1LTY5KS4gSeKAmXZlIGF2b2lkZWQgd29y ZHNtaXRoaW5nIHN1Z2dlc3Rpb25zLCBhbmQgd2lsbCBtYWtlIGEgUFIgZm9yIHRob3NlIGlmIGRl c2lyZWQuDQoNClRoaXMgaXMgUkVBRFkgdG8gYmUgYWR2YW5jZWQgYW5kIEkgc3Ryb25nbHkgZW5j b3VyYWdlIGl0LiAgSSBoYXZlIHNvbWUgcXVlc3Rpb25zIGFuZCBzdWdnZXN0aW9ucyBiZWxvdywg YnV0IGlmIHRoZSBhbnN3ZXJzIGFyZSDigJxub+KAnSB0aGF0IGlzIG9rYXkgd2l0aCBtZS4NCg0K V2Ugc2hvdWxkIG5vdCBob2xkIHVwIHRoaXMgZG9jdW1lbnQgZm9yIGl0LCBidXQgUVVJQyBpcyBh bHNvIHVzaW5nIFRMUy1iYXNlZCBrZXkgZXhjaGFuZ2UuIEl04oCZcyBsaWtlbHkgdG8gYmVjb21l IGV4dHJlbWVseSBwb3B1bGFyIG9uIHRoZSBJbnRlcm5ldCwgYW5kIGEgbW9kaWZpZWQgTlRTLUtF IHRoYXQg4oCcZG9lcyB3aGF0IFFVSUMgZG9lc+KAnSBzZWVtIGxpa2VseSBpbiBhIHllYXIgb3Ig dHdvLiAgSWYgd2UgY2FuIHNvbWVob3cgY2FsbCB0aGF0IG91dCwgaW4gYSByZWFzb25hYmxlIHdh eSwgdGhhdCBtaWdodCBiZSB3b3J0aCBkb2luZy4NCg0KTlRTLUtFIHN0cmFkZGxlcyBOVFAgYW5k IFRMUyBzbyB0aGUg4oCcYXJ0d29ya+KAnSBjb3VsZCBnbyBlaXRoZXIgd2F5LiAgSSBkb27igJl0 IGtub3cgaWYgdGhlIFRMUyBwcmVzZW50YXRpb24gbGFuZ3VhZ2Ugd2FzIGNvbnNpZGVyZWQsIG9y IENCT1IuICBKU09OIHByb3RvYnVmcyBhbmQgQVNOMS9ERVIgc2hvdWxkIG5vdCBiZSBjb25zaWRl cmVkLg0KDQpFdmVyeW9uZSBsaWtlcyB0byB3cml0ZSBhIGZyYW1pbmcgcHJvdG9jb2wgdGhlc2Ug ZGF5cyDimLogIENhbiB3ZSByZXVzZSBIMiBvciwgYWdhaW4gVExTPw0KDQpQZXJoYXBzIE5UUyBO UE4sIGxpa2UgVExTIE5QTiwgc2hvdWxkIGJlIHJlbmFtZWQgdG8gYmUgbGlrZSBBTFBOLg0KDQpM aW5lIDM1NDsgaWYgeW91IGdldCBhbiBlcnJvciBhbmQgZG8gbm90IGFkdmFuY2UsIHdoYXQgc3Rh dGUgYXJlIHlvdSBpbj8gIFBlcmhhcHMgYSBzdGF0ZS9sYWRkZXIgZGlhZ3JhbSB3b3VsZCBiZSBo ZWxwZnVsLg0KDQpMaW5lIDYxNCwgaXQgZG9lc27igJl0IHNlZW0gcmlnaHQgdG8gc2F5IHRoYXQg eW91IG11c3Qgbm90IGF0dGVtcHQgdG8gaW50ZXJwcmV0IGNvb2tpZXMgYW5kIHRoZW4gaW50ZW5k IHRvIHByb3ZpZGUgYSByZWNvbW1lbmRlZCBjb25zdHJ1Y3Rpb24uICBEZWxldGUgdGhlIHJlY29t bWVuZGF0aW9uLg0KDQpEaWQgSSBtaXNzIGEgcGFydCB3aGVyZSB0aGUgY29va2llIGxlbmd0aCBp cyBkZWZpbmVkPyAgV2l0aG91dCB0aGF0LCBob3cgZG9lcyB0aGUgUGxhY2Vob2xkZXIgd29yaz8g IEFuZCB0aGUgbGVuZ3RoIG9mIHRoZSBwbGFjZWhvbGRlciBpbmRpcmVjdGx5IGluZGljYXRlcyB0 aGUgbnVtYmVyIG9mIGNvb2tpZXMgdGhlIGNsaWVudCB3YW50cz8gIFdoYXQgaWYgdGhlIHNlcnZl ciB3YW50cyB0byBnaXZlIGZld2VyIChvciBub25lKS4gIE9PSEhILCB0aGUgY2xpZW50IHJlcGVh dHMgdGhlIGV4dGVuc2lvbiBmb3IgIyBvZiBjb29raWVzIGl0IHdhbnRzLiAgVGhhdCBzaG91bGQg YmUgbWFkZSBtb3JlIGNsZWFyLiBJZiB0aGUgdmFsdWUgb2YgdGhlIGV4dGVuc2lvbiBpcyB0byBi ZSBpZ25vcmVkLCBqdXN0IHJlcXVpcmUgaXQgdG8gYmUgYWxsIHplcm/igJlzLg0KDQpMaW5lIDY4 MmZmIElzIGl0IHVzZWZ1bCB0byBoYXZlIGEgcmVmIHRoYXQgZGVzY3JpYmVzIHdoYXQgSyBBIFAg TiBtZWFuPw0KDQo3MTggTWlzc2luZyB3b3JkIGJlZm9yZSBNVVNUIE5PVA0KDQpDaGFuZ2UgdGhl IHJlY29tbWVuZGVkIGZvcm1hdCBmb3IgTlRTIGNvb2tpZXMgdG8gYmUgYSBub24tbm9ybWF0aXZl IGFwcGVuZGl4IGFuZCBjYWxsIGl0IHBvc3NpYmxlIGZvcm1hdC4NCg0KR2l2ZW4gdGhhdCBtYW55 IHJlYWRlcnMgaGVyZSBub3QgY3J5cHRvIGV4cGVydHMsIGNvbnNpZGVyIG1vcmUgZGVzY3JpcHRp dmUgbGFuZ3VhZ2UgdGhhbiDigJx1bmlmb3JtbHkgcmFuZG9t4oCdIGFuZCBzdWNoIGZvciBub25j ZSB0ZXh0Lg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18KbnRwIG1haWxpbmcgbGlzdApudHBAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9udHAK From nobody Wed Aug 30 11:21:09 2017 Return-Path: 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 89372132355 for ; Wed, 30 Aug 2017 11:21:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] 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 AuPS5pN4_WO3 for ; Wed, 30 Aug 2017 11:21:06 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [67.231.149.131]) (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 241CC13217D for ; Wed, 30 Aug 2017 11:21:06 -0700 (PDT) Received: from pps.filterd (m0122332.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v7UIH1HJ026560; Wed, 30 Aug 2017 19:21:04 +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=vV4ye6xFUUlyaMg8T8grbRM/QbYEKPIzN2apYBoNDIc=; b=PK/8y4KiXWY7QFwt/wZiV3Q5yfd6xTLR6qFfI9w+hpuGT8qKWES3EsekDn+r+YxTn6Mf 1wkm+1H6vHVLZDXkM274tPmX0zuajyl3w/28FsO3ce7pf8Ypd07bsboX2Dyuhaz5J6RD LuhUSmfBkJHDjHFYafIC8cXQHuQ/w/TyBitQ+xv7jqC2VkeuttNJCZtcw2LpOjKSKUvl WyFFRAfHNxC63SdI2iOqCAJcgsOZy69d6Ks9/J8QH2QIH0cB+7j3iyBGljtnrGCTYJX6 itzlmO+T0j+jKdtk4A+bPEphf//EL54/ZlPdM1dZ3TpvfNoQ+UaAmBKtSBTQ+6SXIT31 Pw== Received: from prod-mail-ppoint4 ([96.6.114.87]) by mx0a-00190b01.pphosted.com with ESMTP id 2ck11efpqd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 30 Aug 2017 19:21:03 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v7UIKiUW008500; Wed, 30 Aug 2017 14:21:02 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint4.akamai.com with ESMTP id 2ck4avpq22-3 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 30 Aug 2017 14:21:02 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 30 Aug 2017 14:20:41 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Wed, 30 Aug 2017 14:20:39 -0400 From: "Salz, Rich" To: Karen O'Donoghue , Daniel Franke CC: "ntp@ietf.org" Thread-Topic: [Ntp] NTS changelog since draft 9 Thread-Index: AQHTIbHUYQo62yJ4HkOsJT6meZUHWqKdZUcA///QsQA= Date: Wed, 30 Aug 2017 18:20:38 +0000 Message-ID: <5BE6683D-396F-4FAA-B8E8-9E2C277B8A35@akamai.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1b.0.161010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.36.106] Content-Type: text/plain; charset="utf-8" Content-ID: <1C4D2DAB80453D499498430FAA6ACD06@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-30_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1708300279 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-30_08:, , 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 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1708300278 Archived-At: Subject: Re: [Ntp] NTS changelog since draft 9 X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 18:21:07 -0000 SSBoYXZlIGp1c3QgZmluaXNoZWQgcmVhZGluZyB0aGlzIGRvY3VtZW50LiAgSeKAmWxsIHRyeSBu b3QgdG8gZGlzY3VzcyB0aGluZ3MgdGhhdCBoYXZlIGFscmVhZHkgYmVlbiBvbiB0aGUgbWFpbGlu ZyBsaXN0ICBCdXQgc2luY2UgaXQganVzdCBjYW1lIHVwIHdoaWxlIEkgd2FzIHdyaXRpbmcgdGhp cyBlbWFpbCwgSSB3YW50IHRvIHNheSBJIGFncmVlIHRoYXQgYWxsIHJlZmVyZW5jZXMgdG8gUFRQ IHNob3VsZCBiZSByZW1vdmVkIChlLmcuIGxpbmVzIDY1LTY5KS4gSeKAmXZlIGF2b2lkZWQgd29y ZHNtaXRoaW5nIHN1Z2dlc3Rpb25zLCBhbmQgd2lsbCBtYWtlIGEgUFIgZm9yIHRob3NlIGlmIGRl c2lyZWQuDQoNClRoaXMgaXMgUkVBRFkgdG8gYmUgYWR2YW5jZWQgYW5kIEkgc3Ryb25nbHkgZW5j b3VyYWdlIGl0LiAgSSBoYXZlIHNvbWUgcXVlc3Rpb25zIGFuZCBzdWdnZXN0aW9ucyBiZWxvdywg YnV0IGlmIHRoZSBhbnN3ZXJzIGFyZSDigJxub+KAnSB0aGF0IGlzIG9rYXkgd2l0aCBtZS4NCg0K V2Ugc2hvdWxkIG5vdCBob2xkIHVwIHRoaXMgZG9jdW1lbnQgZm9yIGl0LCBidXQgUVVJQyBpcyBh bHNvIHVzaW5nIFRMUy1iYXNlZCBrZXkgZXhjaGFuZ2UuIEl04oCZcyBsaWtlbHkgdG8gYmVjb21l IGV4dHJlbWVseSBwb3B1bGFyIG9uIHRoZSBJbnRlcm5ldCwgYW5kIGEgbW9kaWZpZWQgTlRTLUtF IHRoYXQg4oCcZG9lcyB3aGF0IFFVSUMgZG9lc+KAnSBzZWVtIGxpa2VseSBpbiBhIHllYXIgb3Ig dHdvLiAgSWYgd2UgY2FuIHNvbWVob3cgY2FsbCB0aGF0IG91dCwgaW4gYSByZWFzb25hYmxlIHdh eSwgdGhhdCBtaWdodCBiZSB3b3J0aCBkb2luZy4NCg0KTlRTLUtFIHN0cmFkZGxlcyBOVFAgYW5k IFRMUyBzbyB0aGUg4oCcYXJ0d29ya+KAnSBjb3VsZCBnbyBlaXRoZXIgd2F5LiAgSSBkb27igJl0 IGtub3cgaWYgdGhlIFRMUyBwcmVzZW50YXRpb24gbGFuZ3VhZ2Ugd2FzIGNvbnNpZGVyZWQsIG9y IENCT1IuICBKU09OIHByb3RvYnVmcyBhbmQgQVNOMS9ERVIgc2hvdWxkIG5vdCBiZSBjb25zaWRl cmVkLg0KDQpFdmVyeW9uZSBsaWtlcyB0byB3cml0ZSBhIGZyYW1pbmcgcHJvdG9jb2wgdGhlc2Ug ZGF5cyDimLogIENhbiB3ZSByZXVzZSBIMiBvciwgYWdhaW4gVExTPw0KDQpQZXJoYXBzIE5UUyBO UE4sIGxpa2UgVExTIE5QTiwgc2hvdWxkIGJlIHJlbmFtZWQgdG8gYmUgbGlrZSBBTFBOLg0KDQpM aW5lIDM1NDsgaWYgeW91IGdldCBhbiBlcnJvciBhbmQgZG8gbm90IGFkdmFuY2UsIHdoYXQgc3Rh dGUgYXJlIHlvdSBpbj8gIFBlcmhhcHMgYSBzdGF0ZS9sYWRkZXIgZGlhZ3JhbSB3b3VsZCBiZSBo ZWxwZnVsLg0KDQpMaW5lIDYxNCwgaXQgZG9lc27igJl0IHNlZW0gcmlnaHQgdG8gc2F5IHRoYXQg eW91IG11c3Qgbm90IGF0dGVtcHQgdG8gaW50ZXJwcmV0IGNvb2tpZXMgYW5kIHRoZW4gaW50ZW5k IHRvIHByb3ZpZGUgYSByZWNvbW1lbmRlZCBjb25zdHJ1Y3Rpb24uICBEZWxldGUgdGhlIHJlY29t bWVuZGF0aW9uLg0KDQpEaWQgSSBtaXNzIGEgcGFydCB3aGVyZSB0aGUgY29va2llIGxlbmd0aCBp cyBkZWZpbmVkPyAgV2l0aG91dCB0aGF0LCBob3cgZG9lcyB0aGUgUGxhY2Vob2xkZXIgd29yaz8g IEFuZCB0aGUgbGVuZ3RoIG9mIHRoZSBwbGFjZWhvbGRlciBpbmRpcmVjdGx5IGluZGljYXRlcyB0 aGUgbnVtYmVyIG9mIGNvb2tpZXMgdGhlIGNsaWVudCB3YW50cz8gIFdoYXQgaWYgdGhlIHNlcnZl ciB3YW50cyB0byBnaXZlIGZld2VyIChvciBub25lKS4gIE9PSEhILCB0aGUgY2xpZW50IHJlcGVh dHMgdGhlIGV4dGVuc2lvbiBmb3IgIyBvZiBjb29raWVzIGl0IHdhbnRzLiAgVGhhdCBzaG91bGQg YmUgbWFkZSBtb3JlIGNsZWFyLiBJZiB0aGUgdmFsdWUgb2YgdGhlIGV4dGVuc2lvbiBpcyB0byBi ZSBpZ25vcmVkLCBqdXN0IHJlcXVpcmUgaXQgdG8gYmUgYWxsIHplcm/igJlzLg0KDQpMaW5lIDY4 MmZmIElzIGl0IHVzZWZ1bCB0byBoYXZlIGEgcmVmIHRoYXQgZGVzY3JpYmVzIHdoYXQgSyBBIFAg TiBtZWFuPw0KDQo3MTggTWlzc2luZyB3b3JkIGJlZm9yZSBNVVNUIE5PVA0KDQpDaGFuZ2UgdGhl IHJlY29tbWVuZGVkIGZvcm1hdCBmb3IgTlRTIGNvb2tpZXMgdG8gYmUgYSBub24tbm9ybWF0aXZl IGFwcGVuZGl4IGFuZCBjYWxsIGl0IHBvc3NpYmxlIGZvcm1hdC4NCg0KR2l2ZW4gdGhhdCBtYW55 IHJlYWRlcnMgaGVyZSBub3QgY3J5cHRvIGV4cGVydHMsIGNvbnNpZGVyIG1vcmUgZGVzY3JpcHRp dmUgbGFuZ3VhZ2UgdGhhbiDigJx1bmlmb3JtbHkgcmFuZG9t4oCdIGFuZCBzdWNoIGZvciBub25j ZSB0ZXh0Lg0KDQoNCg0K From ntp-bounces@ietf.org Wed Aug 30 11:25:43 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 47AF213292A; Wed, 30 Aug 2017 11:25:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1504117543; bh=u+ovYyWM8bxfzNvF4GKuvYEPnPm5zcT/2ta2eUtBqio=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=FAGSdqzGsQdFwYHdangDyNYWrA0vjFR26gd/BVM949evs21N1cQ7U3MxVB9yEWtTF 29jJN+Go4KjZiLXBrprz7qdlPIAJAD4Gk+lEkfTRCtj/8Z0uZIp8dwoswVoIemJPrC t9CuJWvL8Jr7RlAteG5nO4sLVzsEud+Xg8l5qKQc= 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 EFFEB1326EA for ; Wed, 30 Aug 2017 11:25:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] 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 4BnI1u1UC_Ai for ; Wed, 30 Aug 2017 11:25:39 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [67.231.149.131]) (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 3B51D132710 for ; Wed, 30 Aug 2017 11:25:39 -0700 (PDT) Received: from pps.filterd (m0122332.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v7UILl2N030754 for ; Wed, 30 Aug 2017 19:25:39 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=6npuWq3eDwVIjJNOKpZVAR/35JWvF8Pm2cOrKkCYvKs=; b=j4OXpRo1Nzhs2dTKGP9fsu9e71XS6UISsgzFyoGOnMugayxaa22ihKIDSymNI5vuabyi pQbVorbN+GgiPODVT4acMutSOGi3Ool+FnmYNAdlhQvjErYWbw6CyOQo91ZmWDUVZ9p0 /l7+T9fcXe93LAXRmNmdR8rlvC1Tpb2Rq9dK+yhMUQQBqUAdj4/01EA77h2LqdmTsSXP CZYX30UEdiiw8COgfF+JRtydJJpCXW1reYSRZ/muI2Cs3SzXCzlOB1Kz9cJWBhkVHVY8 eppsDEoMwLLaZbWLXH9+vbaj1DzcSwyhSFidc8sJvrtXuEII2Rvp+J8nLppXODHrZH7e Sw== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by mx0a-00190b01.pphosted.com with ESMTP id 2ck11efq7n-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 30 Aug 2017 19:25:38 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v7UIPbvk013096 for ; Wed, 30 Aug 2017 14:25:37 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.30]) by prod-mail-ppoint1.akamai.com with ESMTP id 2ck4avbbn2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Wed, 30 Aug 2017 14:25:37 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 30 Aug 2017 14:25:32 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Wed, 30 Aug 2017 14:25:32 -0400 From: "Salz, Rich" To: "ntp@ietf.org" Thread-Topic: Support for draft-ietf-ntp-mac Thread-Index: AQHTIb1cb4rUmxSYuU65uJcEILDc8A== Date: Wed, 30 Aug 2017 18:25:31 +0000 Message-ID: <545DCC35-A241-4BC8-B402-AABD533A9D8B@akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1b.0.161010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.36.106] Content-ID: <82DC8C96A85B934F80BAAA55C6CF55A4@akamai.com> MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-30_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1708300281 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-30_08:, , 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 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1708300279 Archived-At: Subject: [Ntp] Support for draft-ietf-ntp-mac X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ntp-bounces@ietf.org Sender: "ntp" I am in favor of advancing this document out of WGLC and on to the IESG. Someone else raised the issue about slight mis-use of jitter in Sec 4, bullet 3. I think that can be fixed by saying something about encouraging constant-time implementations. _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp From nobody Wed Aug 30 11:25:47 2017 Return-Path: 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 EFFEB1326EA for ; Wed, 30 Aug 2017 11:25:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] 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 4BnI1u1UC_Ai for ; Wed, 30 Aug 2017 11:25:39 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [67.231.149.131]) (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 3B51D132710 for ; Wed, 30 Aug 2017 11:25:39 -0700 (PDT) Received: from pps.filterd (m0122332.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v7UILl2N030754 for ; Wed, 30 Aug 2017 19:25:39 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=6npuWq3eDwVIjJNOKpZVAR/35JWvF8Pm2cOrKkCYvKs=; b=j4OXpRo1Nzhs2dTKGP9fsu9e71XS6UISsgzFyoGOnMugayxaa22ihKIDSymNI5vuabyi pQbVorbN+GgiPODVT4acMutSOGi3Ool+FnmYNAdlhQvjErYWbw6CyOQo91ZmWDUVZ9p0 /l7+T9fcXe93LAXRmNmdR8rlvC1Tpb2Rq9dK+yhMUQQBqUAdj4/01EA77h2LqdmTsSXP CZYX30UEdiiw8COgfF+JRtydJJpCXW1reYSRZ/muI2Cs3SzXCzlOB1Kz9cJWBhkVHVY8 eppsDEoMwLLaZbWLXH9+vbaj1DzcSwyhSFidc8sJvrtXuEII2Rvp+J8nLppXODHrZH7e Sw== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by mx0a-00190b01.pphosted.com with ESMTP id 2ck11efq7n-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 30 Aug 2017 19:25:38 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v7UIPbvk013096 for ; Wed, 30 Aug 2017 14:25:37 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.30]) by prod-mail-ppoint1.akamai.com with ESMTP id 2ck4avbbn2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Wed, 30 Aug 2017 14:25:37 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 30 Aug 2017 14:25:32 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Wed, 30 Aug 2017 14:25:32 -0400 From: "Salz, Rich" To: "ntp@ietf.org" Thread-Topic: Support for draft-ietf-ntp-mac Thread-Index: AQHTIb1cb4rUmxSYuU65uJcEILDc8A== Date: Wed, 30 Aug 2017 18:25:31 +0000 Message-ID: <545DCC35-A241-4BC8-B402-AABD533A9D8B@akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1b.0.161010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.36.106] Content-Type: text/plain; charset="utf-8" Content-ID: <82DC8C96A85B934F80BAAA55C6CF55A4@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-30_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1708300281 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-30_08:, , 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 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1708300279 Archived-At: Subject: [Ntp] Support for draft-ietf-ntp-mac X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 18:25:42 -0000 SSBhbSBpbiBmYXZvciBvZiBhZHZhbmNpbmcgdGhpcyBkb2N1bWVudCBvdXQgb2YgV0dMQyBhbmQg b24gdG8gdGhlIElFU0cuDQoNClNvbWVvbmUgZWxzZSByYWlzZWQgdGhlIGlzc3VlIGFib3V0IHNs aWdodCBtaXMtdXNlIG9mIGppdHRlciBpbiBTZWMgNCwgYnVsbGV0IDMuICBJIHRoaW5rIHRoYXQg Y2FuIGJlIGZpeGVkIGJ5IHNheWluZyBzb21ldGhpbmcgYWJvdXQgZW5jb3VyYWdpbmcgY29uc3Rh bnQtdGltZSBpbXBsZW1lbnRhdGlvbnMuDQoNCg0KDQo= From nobody Wed Aug 30 12:32:02 2017 Return-Path: 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 5AA011326EA for ; Wed, 30 Aug 2017 12:32:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 drWl8aXkVGRK for ; Wed, 30 Aug 2017 12:31:59 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (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 9DFA2132968 for ; Wed, 30 Aug 2017 12:31:57 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id 137so3784874wmj.1 for ; Wed, 30 Aug 2017 12:31:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=LSLokHG5uBpORc/JZEJR23dljWwE4yot16DRNDqxzuM=; b=BowD367NU0ufdYdMp+T6GUTmikNRR/+WwgwJznDJs8zitCGMfRifDSLRjQqRavAMMv hDjpd/jpnSySv/EscG+KD2ohJnH9+Lkudw10zwNOLJNzVCloPilJu01tEC/218aFloo+ Mh0I0makj0oOxsNOLULAUmOzQmHNP7IRuwX/n94wjGcpy07dJr6708W+LZ0+EJ7cyD+G S3CniPedfxYWFFqMgez+I3rZakfhr3BDqeBvq87LJgm8CmbI4Yzj43+0dNg0jSluCY68 veu2GsPawipqffmTqwcXznXhvWPkB5xbMQX13YlDvYLOGCJEsCd9rkI/I22nAqSqFrlY tn6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=LSLokHG5uBpORc/JZEJR23dljWwE4yot16DRNDqxzuM=; b=IIXVjvE97+wFlmwpiSobLmRIX7zBtHU24QK4VucOX2skYdXXHTgaODk7UNXyfCTLs9 Yno8TkB80D1JY4P2gbDAKwBEz/oPx0HJIE4c80jTh0lo0EJ+L2ViWwMYWrT6+czX/+Rz lUoy2T2slG7TofES904+0slViYdVhDOQXrtnMcFUTct/mrwnUEbSWP+RQita+0zIPXVJ cXwMe6swKEw4dsoVfzQ1WIfChZKP9lc/E7i0uv7/WyRlTt/1O3JmWkA+YRxHx9FeJD3E t97FKkh2MUN3VsK9JJGtg/JivEcch9q8VK+ZXyx5Yj82ZBkDKc9wLHRGM/4UZpjRRWFx 28yA== X-Gm-Message-State: AHYfb5hl4prqW3/dW4569a8WrySPnksrIyh/Mgbsl7YEKhV7hg02etCL EIzq2hUsI0Y4sKMOLZVs2GKK32hi8Q== X-Received: by 10.80.159.138 with SMTP id c10mr2654984edf.257.1504121515874; Wed, 30 Aug 2017 12:31:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.157.140 with HTTP; Wed, 30 Aug 2017 12:31:54 -0700 (PDT) In-Reply-To: <5BE6683D-396F-4FAA-B8E8-9E2C277B8A35@akamai.com> References: <5BE6683D-396F-4FAA-B8E8-9E2C277B8A35@akamai.com> From: Daniel Franke Date: Wed, 30 Aug 2017 15:31:54 -0400 Message-ID: To: "Salz, Rich" Cc: "Karen O'Donoghue" , "ntp@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Ntp] NTS changelog since draft 9 X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 19:32:01 -0000 On 8/30/17, Salz, Rich wrote: > We should not hold up this document for it, but QUIC is also using TLS-ba= sed > key exchange. It=E2=80=99s likely to become extremely popular on the Inte= rnet, and a > modified NTS-KE that =E2=80=9Cdoes what QUIC does=E2=80=9D seem likely in= a year or two. If > we can somehow call that out, in a reasonable way, that might be worth > doing. Put any sort of intelligent discussion of such a thing into the NTS doc would call for citing QUIC RFCs, which aren't published yet and would therefore hold up NTS. As far as the merits go, I'm not sure I understand what you're proposing well enough to comment. Do you just mean running NTS-KE over QUIC rather than over TLS/TCP? > NTS-KE straddles NTP and TLS so the =E2=80=9Cartwork=E2=80=9D could go ei= ther way. I don=E2=80=99t > know if the TLS presentation language was considered, or CBOR. JSON > protobufs and ASN1/DER should not be considered. > > Everyone likes to write a framing protocol these days =E2=98=BA Can we r= euse H2 or, > again TLS? I tried taking the WG's temperature on this a year ago. The consensus seemed to be: 1. Good riddance to ASN.1; 2. nobody was sufficiently unhappy with my simple ad-hoc framing to propose a concrete alternative. If you'd suggested something a month ago I'd welcome PRs, but now that we're in LC I'm hesitant to make this sort of change without a compelling reason. > Perhaps NTS NPN, like TLS NPN, should be renamed to be like ALPN. NTS-KE is already at the application layer, so that name seems misleading in this case. > Line 354; if you get an error and do not advance, what state are you in? > Perhaps a state/ladder diagram would be helpful. I can't figure out what document version/format this line number is in reference to, but I think you're referring to something in section 4? PR welcome. > Line 614, it doesn=E2=80=99t seem right to say that you must not attempt = to > interpret cookies and then intend to provide a recommended construction. > Delete the recommendation. > > Change the recommended format for NTS cookies to be a non-normative appen= dix > and call it possible format. I think this section is pretty important for understanding how the protocol is supposed to work, and don't want to relegate it to an appendix. Would adding an explicit "This section is non-normative" be sufficient? > Did I miss a part where the cookie length is defined? Without that, how > does the Placeholder work? And the length of the placeholder indirectly > indicates the number of cookies the client wants? What if the server wan= ts > to give fewer (or none). OOHHH, the client repeats the extension for # o= f > cookies it wants. That should be made more clear. If the value of the > extension is to be ignored, just require it to be all zero=E2=80=99s. Can you send a PR for this? > Line 682ff Is it useful to have a ref that describes what K A P N mean? It's RFC 5116. I'll put an additional reference to it there for clarity. > 718 Missing word before MUST NOT I'm again having trouble resolving your line numbers. I can't figure out what you're pointing at here. > Given that many readers here not crypto experts, consider more descriptiv= e > language than =E2=80=9Cuniformly random=E2=80=9D and such for nonce text. Can you suggest a better phrase? ISTM that "random" will by itself be properly understood by average readers, and adding "uniformly" should satisfy mathematical pedants like me. From ntp-bounces@ietf.org Wed Aug 30 12:32:03 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B3BF132941; Wed, 30 Aug 2017 12:32:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1504121523; bh=7sF+IozWavlmiwsIn2AAiEZHzK9j8JagMr755WupQgU=; h=In-Reply-To:References:From:Date:To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc; b=ykw23ibrOJVtDbzuohwTC4MNJrkvSgrCdrMAZwJmY26E7Z0AgoJqjGbTjfTgWs2BI UBreOv+ZPZJq08zNBkK+CBqh0jTQ6YNbNaSKHPkPsrnKGOi5O4i8MhEAUsQNfdqrbz WsENn+GejtMhz4dDDfATgPl0z+VlKm6NdI4RB1BU= 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 5AA011326EA for ; Wed, 30 Aug 2017 12:32:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 drWl8aXkVGRK for ; Wed, 30 Aug 2017 12:31:59 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (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 9DFA2132968 for ; Wed, 30 Aug 2017 12:31:57 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id 137so3784874wmj.1 for ; Wed, 30 Aug 2017 12:31:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=LSLokHG5uBpORc/JZEJR23dljWwE4yot16DRNDqxzuM=; b=BowD367NU0ufdYdMp+T6GUTmikNRR/+WwgwJznDJs8zitCGMfRifDSLRjQqRavAMMv hDjpd/jpnSySv/EscG+KD2ohJnH9+Lkudw10zwNOLJNzVCloPilJu01tEC/218aFloo+ Mh0I0makj0oOxsNOLULAUmOzQmHNP7IRuwX/n94wjGcpy07dJr6708W+LZ0+EJ7cyD+G S3CniPedfxYWFFqMgez+I3rZakfhr3BDqeBvq87LJgm8CmbI4Yzj43+0dNg0jSluCY68 veu2GsPawipqffmTqwcXznXhvWPkB5xbMQX13YlDvYLOGCJEsCd9rkI/I22nAqSqFrlY tn6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=LSLokHG5uBpORc/JZEJR23dljWwE4yot16DRNDqxzuM=; b=IIXVjvE97+wFlmwpiSobLmRIX7zBtHU24QK4VucOX2skYdXXHTgaODk7UNXyfCTLs9 Yno8TkB80D1JY4P2gbDAKwBEz/oPx0HJIE4c80jTh0lo0EJ+L2ViWwMYWrT6+czX/+Rz lUoy2T2slG7TofES904+0slViYdVhDOQXrtnMcFUTct/mrwnUEbSWP+RQita+0zIPXVJ cXwMe6swKEw4dsoVfzQ1WIfChZKP9lc/E7i0uv7/WyRlTt/1O3JmWkA+YRxHx9FeJD3E t97FKkh2MUN3VsK9JJGtg/JivEcch9q8VK+ZXyx5Yj82ZBkDKc9wLHRGM/4UZpjRRWFx 28yA== X-Gm-Message-State: AHYfb5hl4prqW3/dW4569a8WrySPnksrIyh/Mgbsl7YEKhV7hg02etCL EIzq2hUsI0Y4sKMOLZVs2GKK32hi8Q== X-Received: by 10.80.159.138 with SMTP id c10mr2654984edf.257.1504121515874; Wed, 30 Aug 2017 12:31:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.157.140 with HTTP; Wed, 30 Aug 2017 12:31:54 -0700 (PDT) In-Reply-To: <5BE6683D-396F-4FAA-B8E8-9E2C277B8A35@akamai.com> References: <5BE6683D-396F-4FAA-B8E8-9E2C277B8A35@akamai.com> From: Daniel Franke Date: Wed, 30 Aug 2017 15:31:54 -0400 Message-ID: To: "Salz, Rich" Archived-At: Subject: Re: [Ntp] NTS changelog since draft 9 X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "ntp@ietf.org" , Karen O'Donoghue Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Errors-To: ntp-bounces@ietf.org Sender: "ntp" T24gOC8zMC8xNywgU2FseiwgUmljaCA8cnNhbHpAYWthbWFpLmNvbT4gd3JvdGU6Cj4gV2Ugc2hv dWxkIG5vdCBob2xkIHVwIHRoaXMgZG9jdW1lbnQgZm9yIGl0LCBidXQgUVVJQyBpcyBhbHNvIHVz aW5nIFRMUy1iYXNlZAo+IGtleSBleGNoYW5nZS4gSXTigJlzIGxpa2VseSB0byBiZWNvbWUgZXh0 cmVtZWx5IHBvcHVsYXIgb24gdGhlIEludGVybmV0LCBhbmQgYQo+IG1vZGlmaWVkIE5UUy1LRSB0 aGF0IOKAnGRvZXMgd2hhdCBRVUlDIGRvZXPigJ0gc2VlbSBsaWtlbHkgaW4gYSB5ZWFyIG9yIHR3 by4gIElmCj4gd2UgY2FuIHNvbWVob3cgY2FsbCB0aGF0IG91dCwgaW4gYSByZWFzb25hYmxlIHdh eSwgdGhhdCBtaWdodCBiZSB3b3J0aAo+IGRvaW5nLgoKUHV0IGFueSBzb3J0IG9mIGludGVsbGln ZW50IGRpc2N1c3Npb24gb2Ygc3VjaCBhIHRoaW5nIGludG8gdGhlIE5UUwpkb2Mgd291bGQgY2Fs bCBmb3IgY2l0aW5nIFFVSUMgUkZDcywgd2hpY2ggYXJlbid0IHB1Ymxpc2hlZCB5ZXQgYW5kCndv dWxkIHRoZXJlZm9yZSBob2xkIHVwIE5UUy4gQXMgZmFyIGFzIHRoZSBtZXJpdHMgZ28sIEknbSBu b3Qgc3VyZSBJCnVuZGVyc3RhbmQgd2hhdCB5b3UncmUgcHJvcG9zaW5nIHdlbGwgZW5vdWdoIHRv IGNvbW1lbnQuIERvIHlvdSBqdXN0Cm1lYW4gcnVubmluZyBOVFMtS0Ugb3ZlciBRVUlDIHJhdGhl ciB0aGFuIG92ZXIgVExTL1RDUD8KCj4gTlRTLUtFIHN0cmFkZGxlcyBOVFAgYW5kIFRMUyBzbyB0 aGUg4oCcYXJ0d29ya+KAnSBjb3VsZCBnbyBlaXRoZXIgd2F5LiAgSSBkb27igJl0Cj4ga25vdyBp ZiB0aGUgVExTIHByZXNlbnRhdGlvbiBsYW5ndWFnZSB3YXMgY29uc2lkZXJlZCwgb3IgQ0JPUi4g IEpTT04KPiBwcm90b2J1ZnMgYW5kIEFTTjEvREVSIHNob3VsZCBub3QgYmUgY29uc2lkZXJlZC4K Pgo+IEV2ZXJ5b25lIGxpa2VzIHRvIHdyaXRlIGEgZnJhbWluZyBwcm90b2NvbCB0aGVzZSBkYXlz IOKYuiAgQ2FuIHdlIHJldXNlIEgyIG9yLAo+IGFnYWluIFRMUz8KCkkgdHJpZWQgdGFraW5nIHRo ZSBXRydzIHRlbXBlcmF0dXJlIG9uIHRoaXMgYSB5ZWFyIGFnby4gVGhlIGNvbnNlbnN1cwpzZWVt ZWQgdG8gYmU6IDEuIEdvb2QgcmlkZGFuY2UgdG8gQVNOLjE7IDIuIG5vYm9keSB3YXMgc3VmZmlj aWVudGx5CnVuaGFwcHkgd2l0aCBteSBzaW1wbGUgYWQtaG9jIGZyYW1pbmcgdG8gcHJvcG9zZSBh IGNvbmNyZXRlCmFsdGVybmF0aXZlLiBJZiB5b3UnZCBzdWdnZXN0ZWQgc29tZXRoaW5nIGEgbW9u dGggYWdvIEknZCB3ZWxjb21lIFBScywKYnV0IG5vdyB0aGF0IHdlJ3JlIGluIExDIEknbSBoZXNp dGFudCB0byBtYWtlIHRoaXMgc29ydCBvZiBjaGFuZ2UKd2l0aG91dCBhIGNvbXBlbGxpbmcgcmVh c29uLgoKPiBQZXJoYXBzIE5UUyBOUE4sIGxpa2UgVExTIE5QTiwgc2hvdWxkIGJlIHJlbmFtZWQg dG8gYmUgbGlrZSBBTFBOLgoKTlRTLUtFIGlzIGFscmVhZHkgYXQgdGhlIGFwcGxpY2F0aW9uIGxh eWVyLCBzbyB0aGF0IG5hbWUgc2VlbXMKbWlzbGVhZGluZyBpbiB0aGlzIGNhc2UuCgo+IExpbmUg MzU0OyBpZiB5b3UgZ2V0IGFuIGVycm9yIGFuZCBkbyBub3QgYWR2YW5jZSwgd2hhdCBzdGF0ZSBh cmUgeW91IGluPwo+IFBlcmhhcHMgYSBzdGF0ZS9sYWRkZXIgZGlhZ3JhbSB3b3VsZCBiZSBoZWxw ZnVsLgoKSSBjYW4ndCBmaWd1cmUgb3V0IHdoYXQgZG9jdW1lbnQgdmVyc2lvbi9mb3JtYXQgdGhp cyBsaW5lIG51bWJlciBpcyBpbgpyZWZlcmVuY2UgdG8sIGJ1dCBJIHRoaW5rIHlvdSdyZSByZWZl cnJpbmcgdG8gc29tZXRoaW5nIGluIHNlY3Rpb24gND8KUFIgd2VsY29tZS4KCj4gTGluZSA2MTQs IGl0IGRvZXNu4oCZdCBzZWVtIHJpZ2h0IHRvIHNheSB0aGF0IHlvdSBtdXN0IG5vdCBhdHRlbXB0 IHRvCj4gaW50ZXJwcmV0IGNvb2tpZXMgYW5kIHRoZW4gaW50ZW5kIHRvIHByb3ZpZGUgYSByZWNv bW1lbmRlZCBjb25zdHJ1Y3Rpb24uCj4gRGVsZXRlIHRoZSByZWNvbW1lbmRhdGlvbi4KPgo+IENo YW5nZSB0aGUgcmVjb21tZW5kZWQgZm9ybWF0IGZvciBOVFMgY29va2llcyB0byBiZSBhIG5vbi1u b3JtYXRpdmUgYXBwZW5kaXgKPiBhbmQgY2FsbCBpdCBwb3NzaWJsZSBmb3JtYXQuCgpJIHRoaW5r IHRoaXMgc2VjdGlvbiBpcyBwcmV0dHkgaW1wb3J0YW50IGZvciB1bmRlcnN0YW5kaW5nIGhvdyB0 aGUKcHJvdG9jb2wgaXMgc3VwcG9zZWQgdG8gd29yaywgYW5kIGRvbid0IHdhbnQgdG8gcmVsZWdh dGUgaXQgdG8gYW4KYXBwZW5kaXguIFdvdWxkIGFkZGluZyBhbiBleHBsaWNpdCAiVGhpcyBzZWN0 aW9uIGlzIG5vbi1ub3JtYXRpdmUiIGJlCnN1ZmZpY2llbnQ/Cgo+IERpZCBJIG1pc3MgYSBwYXJ0 IHdoZXJlIHRoZSBjb29raWUgbGVuZ3RoIGlzIGRlZmluZWQ/ICBXaXRob3V0IHRoYXQsIGhvdwo+ IGRvZXMgdGhlIFBsYWNlaG9sZGVyIHdvcms/ICBBbmQgdGhlIGxlbmd0aCBvZiB0aGUgcGxhY2Vo b2xkZXIgaW5kaXJlY3RseQo+IGluZGljYXRlcyB0aGUgbnVtYmVyIG9mIGNvb2tpZXMgdGhlIGNs aWVudCB3YW50cz8gIFdoYXQgaWYgdGhlIHNlcnZlciB3YW50cwo+IHRvIGdpdmUgZmV3ZXIgKG9y IG5vbmUpLiAgT09ISEgsIHRoZSBjbGllbnQgcmVwZWF0cyB0aGUgZXh0ZW5zaW9uIGZvciAjIG9m Cj4gY29va2llcyBpdCB3YW50cy4gIFRoYXQgc2hvdWxkIGJlIG1hZGUgbW9yZSBjbGVhci4gSWYg dGhlIHZhbHVlIG9mIHRoZQo+IGV4dGVuc2lvbiBpcyB0byBiZSBpZ25vcmVkLCBqdXN0IHJlcXVp cmUgaXQgdG8gYmUgYWxsIHplcm/igJlzLgoKQ2FuIHlvdSBzZW5kIGEgUFIgZm9yIHRoaXM/Cgo+ IExpbmUgNjgyZmYgSXMgaXQgdXNlZnVsIHRvIGhhdmUgYSByZWYgdGhhdCBkZXNjcmliZXMgd2hh dCBLIEEgUCBOIG1lYW4/CgpJdCdzIFJGQyA1MTE2LiBJJ2xsIHB1dCBhbiBhZGRpdGlvbmFsIHJl ZmVyZW5jZSB0byBpdCB0aGVyZSBmb3IgY2xhcml0eS4KCj4gNzE4IE1pc3Npbmcgd29yZCBiZWZv cmUgTVVTVCBOT1QKCkknbSBhZ2FpbiBoYXZpbmcgdHJvdWJsZSByZXNvbHZpbmcgeW91ciBsaW5l IG51bWJlcnMuIEkgY2FuJ3QgZmlndXJlCm91dCB3aGF0IHlvdSdyZSBwb2ludGluZyBhdCBoZXJl LgoKPiBHaXZlbiB0aGF0IG1hbnkgcmVhZGVycyBoZXJlIG5vdCBjcnlwdG8gZXhwZXJ0cywgY29u c2lkZXIgbW9yZSBkZXNjcmlwdGl2ZQo+IGxhbmd1YWdlIHRoYW4g4oCcdW5pZm9ybWx5IHJhbmRv beKAnSBhbmQgc3VjaCBmb3Igbm9uY2UgdGV4dC4KCkNhbiB5b3Ugc3VnZ2VzdCBhIGJldHRlciBw aHJhc2U/IElTVE0gdGhhdCAicmFuZG9tIiB3aWxsIGJ5IGl0c2VsZiBiZQpwcm9wZXJseSB1bmRl cnN0b29kIGJ5IGF2ZXJhZ2UgcmVhZGVycywgYW5kIGFkZGluZyAidW5pZm9ybWx5IiBzaG91bGQK c2F0aXNmeSBtYXRoZW1hdGljYWwgcGVkYW50cyBsaWtlIG1lLgoKX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbnRwIG1haWxpbmcgbGlzdApudHBAaWV0Zi5v cmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9udHAK From nobody Wed Aug 30 12:56:30 2017 Return-Path: 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 C8B74126B7E for ; Wed, 30 Aug 2017 12:56:28 -0700 (PDT) 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=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 2VwIY5RPe8Og for ; Wed, 30 Aug 2017 12:56:26 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [67.231.157.127]) (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 9CC9C132027 for ; Wed, 30 Aug 2017 12:56:26 -0700 (PDT) Received: from pps.filterd (m0122331.ppops.net [127.0.0.1]) by m0122331.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v7UJpvgn009070; Wed, 30 Aug 2017 20:56:24 +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=0hzRbPwcpKnhzNmsSW9Iy+B326ErdKBTk8jkSE6qrw0=; b=CF14VleMAEPnoXQa1bSVLnfIa34AaQ8D9NZJSs5rq4moDDnXWeukx5jphYNOJzRDLebk j7cTaW+yfRqgjh/Lx9Iu7wJHbEV+KcMXCLvemfhdNFQ6U0ufUz+dZZKrj2xA/WY2gA7d sqJVsm8bSYLssPogdpFpiL5PclRoMfbLznXDuqywZwHsHNOvcL5y8Nd/70wOpfSLzptC OjV1Ef2Iu1CJLSQN20tgZUJEylSdBs5t59Jn7T2wZzsF0p1I7lzIVD5NZVFCJeE9J6qI Z+Uf8rSLD/l5mqwaTjw65ITKtFxNkD+iWLH/mjbTYasyfVOFPqpS0obcwjR9jRS22Zjg mw== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by mx0b-00190b01.pphosted.com with ESMTP id 2cjwuqr3x7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 30 Aug 2017 20:56:24 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v7UJp2Gd026810; Wed, 30 Aug 2017 15:56:23 -0400 Received: from email.msg.corp.akamai.com ([172.27.25.33]) by prod-mail-ppoint1.akamai.com with ESMTP id 2ck4avbxk0-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 30 Aug 2017 15:56:23 -0400 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb6.msg.corp.akamai.com (172.27.27.107) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 30 Aug 2017 12:56:23 -0700 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.6.131]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.6.131]) with mapi id 15.00.1263.000; Wed, 30 Aug 2017 14:56:23 -0500 From: "Salz, Rich" To: Daniel Franke CC: Karen O'Donoghue , "ntp@ietf.org" Thread-Topic: [Ntp] NTS changelog since draft 9 Thread-Index: AQHTIbHUYQo62yJ4HkOsJT6meZUHWqKdZUcA///QsQCAAGe7AP//w8gA Date: Wed, 30 Aug 2017 19:56:22 +0000 Message-ID: <8193E01F-8738-4A93-B0F3-22A66959CDFC@akamai.com> References: <5BE6683D-396F-4FAA-B8E8-9E2C277B8A35@akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1b.0.161010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.36.106] Content-Type: text/plain; charset="utf-8" Content-ID: <6E4ED407E2EA8C4AB5C842A0C04D9BD9@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-30_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1708300302 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-30_08:, , 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 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1708300302 Archived-At: Subject: Re: [Ntp] NTS changelog since draft 9 X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 19:56:29 -0000 TGlrZSBJIHNhaWQsIEkgYW0gZmluZSBpZiB0aGUgYW5zd2VyIGlzIOKAnHRvbyBsYXRl4oCdIG9y IOKAnG5v4oCdIHRvIGFsbCB0aGUgcG9pbnRzLg0KDQogICAgPiBMaW5lIDM1NDsgaWYgeW91IGdl dCBhbiBlcnJvciBhbmQgZG8gbm90IGFkdmFuY2UsIHdoYXQgc3RhdGUgYXJlIHlvdSBpbj8NCiAg ICA+IFBlcmhhcHMgYSBzdGF0ZS9sYWRkZXIgZGlhZ3JhbSB3b3VsZCBiZSBoZWxwZnVsLg0KICAg IA0KICAgIEkgY2FuJ3QgZmlndXJlIG91dCB3aGF0IGRvY3VtZW50IHZlcnNpb24vZm9ybWF0IHRo aXMgbGluZSBudW1iZXIgaXMgaW4NCiAgICByZWZlcmVuY2UgdG8NCg0KZ2l0aHViIG1hc3RlciBh cyBvZiB0aGlzIG1vcm5pbmcg4pi6DQoNCiAgICA+IENoYW5nZSB0aGUgcmVjb21tZW5kZWQgZm9y bWF0IGZvciBOVFMgY29va2llcyB0byBiZSBhIG5vbi1ub3JtYXRpdmUgYXBwZW5kaXgNCiAgICA+ IGFuZCBjYWxsIGl0IHBvc3NpYmxlIGZvcm1hdC4NCiAgICANCiAgICBJIHRoaW5rIHRoaXMgc2Vj dGlvbiBpcyBwcmV0dHkgaW1wb3J0YW50IGZvciB1bmRlcnN0YW5kaW5nIGhvdyB0aGUNCiAgICBw cm90b2NvbCBpcyBzdXBwb3NlZCB0byB3b3JrLCBhbmQgZG9uJ3Qgd2FudCB0byByZWxlZ2F0ZSBp dCB0byBhbg0KICAgIGFwcGVuZGl4LiBXb3VsZCBhZGRpbmcgYW4gZXhwbGljaXQgIlRoaXMgc2Vj dGlvbiBpcyBub24tbm9ybWF0aXZlIiBiZQ0KICAgIHN1ZmZpY2llbnQ/DQoNCkkgZGlzYWdyZWUu ICBJdCBtaWdodCBiZSB1c2VmdWwgdG8gdW5kZXJzdGFuZGluZyBidXQgaXQgaXMganVzdCBhIHJl Y29tbWVuZGF0aW9uIGFuZCBub24tbm9ybWF0aXZlLiAgQnV0IHNlZSBteSBvcGVuaW5nIGNvbW1l bnQuDQogICAgDQogICAgPiBEaWQgSSBtaXNzIGEgcGFydCB3aGVyZSB0aGUgY29va2llIGxlbmd0 aCBpcyBkZWZpbmVkPyAgV2l0aG91dCB0aGF0LCBob3cNCiAgICA+IGRvZXMgdGhlIFBsYWNlaG9s ZGVyIHdvcms/ICBBbmQgdGhlIGxlbmd0aCBvZiB0aGUgcGxhY2Vob2xkZXIgaW5kaXJlY3RseQ0K ICAgID4gaW5kaWNhdGVzIHRoZSBudW1iZXIgb2YgY29va2llcyB0aGUgY2xpZW50IHdhbnRzPyAg V2hhdCBpZiB0aGUgc2VydmVyIHdhbnRzDQogICAgPiB0byBnaXZlIGZld2VyIChvciBub25lKS4g IE9PSEhILCB0aGUgY2xpZW50IHJlcGVhdHMgdGhlIGV4dGVuc2lvbiBmb3IgIyBvZg0KICAgID4g Y29va2llcyBpdCB3YW50cy4gIFRoYXQgc2hvdWxkIGJlIG1hZGUgbW9yZSBjbGVhci4gSWYgdGhl IHZhbHVlIG9mIHRoZQ0KICAgID4gZXh0ZW5zaW9uIGlzIHRvIGJlIGlnbm9yZWQsIGp1c3QgcmVx dWlyZSBpdCB0byBiZSBhbGwgemVyb+KAmXMuDQogICAgDQogICAgQ2FuIHlvdSBzZW5kIGEgUFIg Zm9yIHRoaXM/DQogIA0KV2lsbCBkby4NCiAgDQogICAgPiA3MTggTWlzc2luZyB3b3JkIGJlZm9y ZSBNVVNUIE5PVA0KICAgIA0KICAgIEknbSBhZ2FpbiBoYXZpbmcgdHJvdWJsZSByZXNvbHZpbmcg eW91ciBsaW5lIG51bWJlcnMuIEkgY2FuJ3QgZmlndXJlDQogICAgb3V0IHdoYXQgeW91J3JlIHBv aW50aW5nIGF0IGhlcmUuDQoNCkdpdGh1YiBtYXN0ZXIgYXMgb2YgdGhpcyBtb3JuaW5nLg0KICAg IA0KICAgID4gR2l2ZW4gdGhhdCBtYW55IHJlYWRlcnMgaGVyZSBub3QgY3J5cHRvIGV4cGVydHMs IGNvbnNpZGVyIG1vcmUgZGVzY3JpcHRpdmUNCiAgICA+IGxhbmd1YWdlIHRoYW4g4oCcdW5pZm9y bWx5IHJhbmRvbeKAnSBhbmQgc3VjaCBmb3Igbm9uY2UgdGV4dC4NCiAgICANCiAgICBDYW4geW91 IHN1Z2dlc3QgYSBiZXR0ZXIgcGhyYXNlPyBJU1RNIHRoYXQgInJhbmRvbSIgd2lsbCBieSBpdHNl bGYgYmUNCiAgICBwcm9wZXJseSB1bmRlcnN0b29kIGJ5IGF2ZXJhZ2UgcmVhZGVycywgYW5kIGFk ZGluZyAidW5pZm9ybWx5IiBzaG91bGQNCiAgICBzYXRpc2Z5IG1hdGhlbWF0aWNhbCBwZWRhbnRz IGxpa2UgbWUuDQogICAgDQpTZWUgZmlndXJlIG9uZSDimLoNCg0K From ntp-bounces@ietf.org Wed Aug 30 12:56:30 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E114132027; Wed, 30 Aug 2017 12:56:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1504122990; bh=sTrpzbxCsofcefOCGnBwLPgdSbQGhUPwwi3CNagMi8U=; h=From:To:Date:References:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc; b=YvssiXMhfpBE+WLVLiI45P2OZWsJ9CVRZxgvTIlxq+5T7HO2pGmq0jtZtxPDl8n9y CV6IWZnGh/uqOo2V6LTAglj0GXsXQj5HefHoRiSEXAo7Cu8QdGR/Ub6TknbvWl06Nf rH8MDSijai1MUNkbxlhsRbVQBE+QKbzGWlCIk4wc= 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 C8B74126B7E for ; Wed, 30 Aug 2017 12:56:28 -0700 (PDT) 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=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 2VwIY5RPe8Og for ; Wed, 30 Aug 2017 12:56:26 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [67.231.157.127]) (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 9CC9C132027 for ; Wed, 30 Aug 2017 12:56:26 -0700 (PDT) Received: from pps.filterd (m0122331.ppops.net [127.0.0.1]) by m0122331.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v7UJpvgn009070; Wed, 30 Aug 2017 20:56:24 +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=0hzRbPwcpKnhzNmsSW9Iy+B326ErdKBTk8jkSE6qrw0=; b=CF14VleMAEPnoXQa1bSVLnfIa34AaQ8D9NZJSs5rq4moDDnXWeukx5jphYNOJzRDLebk j7cTaW+yfRqgjh/Lx9Iu7wJHbEV+KcMXCLvemfhdNFQ6U0ufUz+dZZKrj2xA/WY2gA7d sqJVsm8bSYLssPogdpFpiL5PclRoMfbLznXDuqywZwHsHNOvcL5y8Nd/70wOpfSLzptC OjV1Ef2Iu1CJLSQN20tgZUJEylSdBs5t59Jn7T2wZzsF0p1I7lzIVD5NZVFCJeE9J6qI Z+Uf8rSLD/l5mqwaTjw65ITKtFxNkD+iWLH/mjbTYasyfVOFPqpS0obcwjR9jRS22Zjg mw== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by mx0b-00190b01.pphosted.com with ESMTP id 2cjwuqr3x7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 30 Aug 2017 20:56:24 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v7UJp2Gd026810; Wed, 30 Aug 2017 15:56:23 -0400 Received: from email.msg.corp.akamai.com ([172.27.25.33]) by prod-mail-ppoint1.akamai.com with ESMTP id 2ck4avbxk0-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 30 Aug 2017 15:56:23 -0400 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb6.msg.corp.akamai.com (172.27.27.107) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 30 Aug 2017 12:56:23 -0700 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.6.131]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.6.131]) with mapi id 15.00.1263.000; Wed, 30 Aug 2017 14:56:23 -0500 From: "Salz, Rich" To: Daniel Franke Thread-Topic: [Ntp] NTS changelog since draft 9 Thread-Index: AQHTIbHUYQo62yJ4HkOsJT6meZUHWqKdZUcA///QsQCAAGe7AP//w8gA Date: Wed, 30 Aug 2017 19:56:22 +0000 Message-ID: <8193E01F-8738-4A93-B0F3-22A66959CDFC@akamai.com> References: <5BE6683D-396F-4FAA-B8E8-9E2C277B8A35@akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1b.0.161010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.36.106] Content-ID: <6E4ED407E2EA8C4AB5C842A0C04D9BD9@akamai.com> MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-30_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1708300302 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-30_08:, , 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 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1708300302 Archived-At: Subject: Re: [Ntp] NTS changelog since draft 9 X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "ntp@ietf.org" , Karen O'Donoghue Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Errors-To: ntp-bounces@ietf.org Sender: "ntp" TGlrZSBJIHNhaWQsIEkgYW0gZmluZSBpZiB0aGUgYW5zd2VyIGlzIOKAnHRvbyBsYXRl4oCdIG9y IOKAnG5v4oCdIHRvIGFsbCB0aGUgcG9pbnRzLg0KDQogICAgPiBMaW5lIDM1NDsgaWYgeW91IGdl dCBhbiBlcnJvciBhbmQgZG8gbm90IGFkdmFuY2UsIHdoYXQgc3RhdGUgYXJlIHlvdSBpbj8NCiAg ICA+IFBlcmhhcHMgYSBzdGF0ZS9sYWRkZXIgZGlhZ3JhbSB3b3VsZCBiZSBoZWxwZnVsLg0KICAg IA0KICAgIEkgY2FuJ3QgZmlndXJlIG91dCB3aGF0IGRvY3VtZW50IHZlcnNpb24vZm9ybWF0IHRo aXMgbGluZSBudW1iZXIgaXMgaW4NCiAgICByZWZlcmVuY2UgdG8NCg0KZ2l0aHViIG1hc3RlciBh cyBvZiB0aGlzIG1vcm5pbmcg4pi6DQoNCiAgICA+IENoYW5nZSB0aGUgcmVjb21tZW5kZWQgZm9y bWF0IGZvciBOVFMgY29va2llcyB0byBiZSBhIG5vbi1ub3JtYXRpdmUgYXBwZW5kaXgNCiAgICA+ IGFuZCBjYWxsIGl0IHBvc3NpYmxlIGZvcm1hdC4NCiAgICANCiAgICBJIHRoaW5rIHRoaXMgc2Vj dGlvbiBpcyBwcmV0dHkgaW1wb3J0YW50IGZvciB1bmRlcnN0YW5kaW5nIGhvdyB0aGUNCiAgICBw cm90b2NvbCBpcyBzdXBwb3NlZCB0byB3b3JrLCBhbmQgZG9uJ3Qgd2FudCB0byByZWxlZ2F0ZSBp dCB0byBhbg0KICAgIGFwcGVuZGl4LiBXb3VsZCBhZGRpbmcgYW4gZXhwbGljaXQgIlRoaXMgc2Vj dGlvbiBpcyBub24tbm9ybWF0aXZlIiBiZQ0KICAgIHN1ZmZpY2llbnQ/DQoNCkkgZGlzYWdyZWUu ICBJdCBtaWdodCBiZSB1c2VmdWwgdG8gdW5kZXJzdGFuZGluZyBidXQgaXQgaXMganVzdCBhIHJl Y29tbWVuZGF0aW9uIGFuZCBub24tbm9ybWF0aXZlLiAgQnV0IHNlZSBteSBvcGVuaW5nIGNvbW1l bnQuDQogICAgDQogICAgPiBEaWQgSSBtaXNzIGEgcGFydCB3aGVyZSB0aGUgY29va2llIGxlbmd0 aCBpcyBkZWZpbmVkPyAgV2l0aG91dCB0aGF0LCBob3cNCiAgICA+IGRvZXMgdGhlIFBsYWNlaG9s ZGVyIHdvcms/ICBBbmQgdGhlIGxlbmd0aCBvZiB0aGUgcGxhY2Vob2xkZXIgaW5kaXJlY3RseQ0K ICAgID4gaW5kaWNhdGVzIHRoZSBudW1iZXIgb2YgY29va2llcyB0aGUgY2xpZW50IHdhbnRzPyAg V2hhdCBpZiB0aGUgc2VydmVyIHdhbnRzDQogICAgPiB0byBnaXZlIGZld2VyIChvciBub25lKS4g IE9PSEhILCB0aGUgY2xpZW50IHJlcGVhdHMgdGhlIGV4dGVuc2lvbiBmb3IgIyBvZg0KICAgID4g Y29va2llcyBpdCB3YW50cy4gIFRoYXQgc2hvdWxkIGJlIG1hZGUgbW9yZSBjbGVhci4gSWYgdGhl IHZhbHVlIG9mIHRoZQ0KICAgID4gZXh0ZW5zaW9uIGlzIHRvIGJlIGlnbm9yZWQsIGp1c3QgcmVx dWlyZSBpdCB0byBiZSBhbGwgemVyb+KAmXMuDQogICAgDQogICAgQ2FuIHlvdSBzZW5kIGEgUFIg Zm9yIHRoaXM/DQogIA0KV2lsbCBkby4NCiAgDQogICAgPiA3MTggTWlzc2luZyB3b3JkIGJlZm9y ZSBNVVNUIE5PVA0KICAgIA0KICAgIEknbSBhZ2FpbiBoYXZpbmcgdHJvdWJsZSByZXNvbHZpbmcg eW91ciBsaW5lIG51bWJlcnMuIEkgY2FuJ3QgZmlndXJlDQogICAgb3V0IHdoYXQgeW91J3JlIHBv aW50aW5nIGF0IGhlcmUuDQoNCkdpdGh1YiBtYXN0ZXIgYXMgb2YgdGhpcyBtb3JuaW5nLg0KICAg IA0KICAgID4gR2l2ZW4gdGhhdCBtYW55IHJlYWRlcnMgaGVyZSBub3QgY3J5cHRvIGV4cGVydHMs IGNvbnNpZGVyIG1vcmUgZGVzY3JpcHRpdmUNCiAgICA+IGxhbmd1YWdlIHRoYW4g4oCcdW5pZm9y bWx5IHJhbmRvbeKAnSBhbmQgc3VjaCBmb3Igbm9uY2UgdGV4dC4NCiAgICANCiAgICBDYW4geW91 IHN1Z2dlc3QgYSBiZXR0ZXIgcGhyYXNlPyBJU1RNIHRoYXQgInJhbmRvbSIgd2lsbCBieSBpdHNl bGYgYmUNCiAgICBwcm9wZXJseSB1bmRlcnN0b29kIGJ5IGF2ZXJhZ2UgcmVhZGVycywgYW5kIGFk ZGluZyAidW5pZm9ybWx5IiBzaG91bGQNCiAgICBzYXRpc2Z5IG1hdGhlbWF0aWNhbCBwZWRhbnRz IGxpa2UgbWUuDQogICAgDQpTZWUgZmlndXJlIG9uZSDimLoNCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbnRwIG1haWxpbmcgbGlzdApudHBAaWV0Zi5v cmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9udHAK From nobody Wed Aug 30 14:11:29 2017 Return-Path: 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 B1A2913292C for ; Wed, 30 Aug 2017 12:23:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 T__KUS_klO9E for ; Wed, 30 Aug 2017 12:23:28 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25AA913248B for ; Wed, 30 Aug 2017 12:23:28 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 01DF8B812A2; Wed, 30 Aug 2017 12:22:51 -0700 (PDT) To: mills@udel.edu, jrmii@isc.org, jack.burbank@jhuapl.edu, william.kasch@jhuapl.edu, suresh.krishnan@gmail.com, terry.manderson@icann.org, dieter.sibold@ptb.de, odonoghue@isoc.org X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: denis@ovsienko.info, ntp@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20170830192251.01DF8B812A2@rfc-editor.org> Date: Wed, 30 Aug 2017 12:22:51 -0700 (PDT) Archived-At: X-Mailman-Approved-At: Wed, 30 Aug 2017 14:11:28 -0700 Subject: [Ntp] [Editorial Errata Reported] RFC5905 (5104) X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 19:23:30 -0000 The following errata report has been submitted for RFC5905, "Network Time Protocol Version 4: Protocol and Algorithms Specification". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5104 -------------------------------------- Type: Editorial Reported by: Denis Ovsienko Section: 7.3, Fig 8 Original Text ------------- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | dgst (128) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Corrected Text -------------- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Message Digest (128) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Notes ----- As the text before the figure explains, the last field is called "Message Digest", which is consistent with the rest of the document. In this document "dgst" and "mac" mean two protocol variables associated with this packet field. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5905 (draft-ietf-ntp-ntpv4-proto-13) -------------------------------------- Title : Network Time Protocol Version 4: Protocol and Algorithms Specification Publication Date : June 2010 Author(s) : D. Mills, J. Martin, Ed., J. Burbank, W. Kasch Category : PROPOSED STANDARD Source : Network Time Protocol Area : Internet Stream : IETF Verifying Party : IESG From ntp-bounces@ietf.org Wed Aug 30 14:11:30 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FA62132A65; Wed, 30 Aug 2017 14:11:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1504127490; bh=zg0wu4XSTJaCgCzaPQOzNb/IPIT8Z+o+10swaz0/mA8=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Cc; b=Ep3OV9kdOhOuAbLIDv9QSILl+1FzMtOZlRVos1X2C/ukqNBzrSqrO4cUCyCaPG8YN WFoESFNPe+qK9oiFtq8ZserNLAxeeWRHJLzel+sMlY4yeLyUyThfxtQZrjD/L395rO FSyG2ikvParfY1/FH5B0sItWCM7OHQsp4n//NhP0= 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 B1A2913292C for ; Wed, 30 Aug 2017 12:23:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 T__KUS_klO9E for ; Wed, 30 Aug 2017 12:23:28 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25AA913248B for ; Wed, 30 Aug 2017 12:23:28 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 01DF8B812A2; Wed, 30 Aug 2017 12:22:51 -0700 (PDT) To: mills@udel.edu, jrmii@isc.org, jack.burbank@jhuapl.edu, william.kasch@jhuapl.edu, suresh.krishnan@gmail.com, terry.manderson@icann.org, dieter.sibold@ptb.de, odonoghue@isoc.org X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20170830192251.01DF8B812A2@rfc-editor.org> Date: Wed, 30 Aug 2017 12:22:51 -0700 (PDT) Archived-At: X-Mailman-Approved-At: Wed, 30 Aug 2017 14:11:28 -0700 Subject: [Ntp] [Editorial Errata Reported] RFC5905 (5104) X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: ntp@ietf.org, denis@ovsienko.info, rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ntp-bounces@ietf.org Sender: "ntp" The following errata report has been submitted for RFC5905, "Network Time Protocol Version 4: Protocol and Algorithms Specification". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5104 -------------------------------------- Type: Editorial Reported by: Denis Ovsienko Section: 7.3, Fig 8 Original Text ------------- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | dgst (128) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Corrected Text -------------- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Message Digest (128) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Notes ----- As the text before the figure explains, the last field is called "Message Digest", which is consistent with the rest of the document. In this document "dgst" and "mac" mean two protocol variables associated with this packet field. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5905 (draft-ietf-ntp-ntpv4-proto-13) -------------------------------------- Title : Network Time Protocol Version 4: Protocol and Algorithms Specification Publication Date : June 2010 Author(s) : D. Mills, J. Martin, Ed., J. Burbank, W. Kasch Category : PROPOSED STANDARD Source : Network Time Protocol Area : Internet Stream : IETF Verifying Party : IESG _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp From nobody Wed Aug 30 15:56:07 2017 Return-Path: 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 3785613213D for ; Wed, 30 Aug 2017 15:56:05 -0700 (PDT) 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=libertysys.com.au 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 2RFkc2N_CBPY for ; Wed, 30 Aug 2017 15:56:03 -0700 (PDT) Received: from mail.libertysys.com.au (ppp178-79.static.internode.on.net [150.101.178.79]) (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 36B5F13209C for ; Wed, 30 Aug 2017 15:56:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.libertysys.com.au (Postfix) with ESMTP id E3C0892436 for ; Thu, 31 Aug 2017 08:56:00 +1000 (AEST) X-Virus-Scanned: Debian amavisd-new at mail2.gear.dyndns.org Received: from mail.libertysys.com.au ([127.0.0.1]) by localhost (mail.gear.dyndns.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wYgPKETV1MC9 for ; Thu, 31 Aug 2017 08:55:55 +1000 (AEST) Received: from [172.22.64.102] (eber-home.gear.dyndns.org [172.22.64.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.libertysys.com.au (Postfix) with ESMTPSA id 846C592103 for ; Thu, 31 Aug 2017 08:55:54 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=libertysys.com.au; s=2016; t=1504133754; bh=9NGXs2NfsehuDoLvP3XrTMmFLB9KaMWwW7tprefWJOI=; h=From:Subject:To:References:Date:In-Reply-To; b=HnO3xj5eWHlq5mlv9Z6sN5jep3a1mqn8zyndBtO+Kqlo+0EiMx/KeiejGg69bcASG EAIdAMds3zy9LKNQmU9lpxKEPN0S9GJGGlDkbx/5RWioSDtX00/gexARWJyC+HP0Au 1kR5SqVCJ5amIxhDQK/kTUgR6YFjzdAw1Q+OomkQ= From: Paul Gear To: ntp@ietf.org References: <5BE6683D-396F-4FAA-B8E8-9E2C277B8A35@akamai.com> Message-ID: <48e72bef-c8fb-2335-f469-aad1bb2f59bd@libertysys.com.au> Date: Thu, 31 Aug 2017 08:55:54 +1000 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-AU Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ntp] NTS changelog since draft 9 X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 22:56:05 -0000 On 31/08/17 05:31, Daniel Franke wrote: > On 8/30/17, Salz, Rich wrote: >> ... >> >> Line 614, it doesn’t seem right to say that you must not attempt to >> interpret cookies and then intend to provide a recommended construction. >> Delete the recommendation. >> >> Change the recommended format for NTS cookies to be a non-normative appendix >> and call it possible format. > I think this section is pretty important for understanding how the > protocol is supposed to work, and don't want to relegate it to an > appendix. Would adding an explicit "This section is non-normative" be > sufficient? Until I had spent some time with section 7 and RFC 5116, I found the cookie management rather perplexing. But now that I've read through it a few times, I think the way cookies are formed and used is vital to how NTS is expected to work in practice, and if anything I think it should be more strongly mandated rather than less (i.e. SHOULD rather than OPTIONAL). Giving protocols a toolkit to do crypto in a standardised and abstracted way is one of the primary goals of RFC 5116, and it seems to me that making the cookie format optional is an opportunity for NTS to end up with bad crypto implementations. This leads me to some questions for Rich: Why do you think it's important that the current cookie format be non-normative? Do you have in mind an alternate cookie formation process? Or are you aware of some circumstances where the current recommendation would be undesirable or unworkable? (Apologies if this should be obvious, but it's not obvious to me at present. I think documenting assumptions is valuable for those of us without a long history in the standardisation process.) >> Did I miss a part where the cookie length is defined? Without that, how >> does the Placeholder work? And the length of the placeholder indirectly >> indicates the number of cookies the client wants? What if the server wants >> to give fewer (or none). OOHHH, the client repeats the extension for # of >> cookies it wants. That should be made more clear. If the value of the >> extension is to be ignored, just require it to be all zero’s. Saying that cookie placeholders SHOULD be all zero is a good idea. It looks Daniel has changed this in draft-dfranke-nts.xml in git master, but not in draft-ietf-ntp-using-nts-for-ntp.xml. (I'm not sure whether this is intentional.) However, I don't recall seeing any language specifying whether all cookies sent by a server must be the same in length. If, for example, a server's software version were upgraded to support a new AEAD suite between a client's polls, then conceivably the next cookie could be slightly shorter or longer. So perhaps the wording should be: "... the body length of the NTS Cookie Placeholder extension MUST be the same as the body length of [the] NTS Cookie [e]xtension [most recently] received from the server." (As an aside: in this scenario, if the new suite required a longer cookie than the placeholder sent by the client, presumably a NAK and an NTS-KE renegotiation would be required. For servers with large numbers of clients, this might be problematic.) Regards, Paul From ntp-bounces@ietf.org Wed Aug 30 15:56:07 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CBFEA13213D; Wed, 30 Aug 2017 15:56:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1504133767; bh=7cy3jaist2JrWAZMGWdcznQFh7zDP68T/+h6H5dbQaM=; h=From:To:References:Date:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe; b=TAjIkcLkuw7BO9Abtveb6CGMDOH0Rg8r6LKsEjNXCfDH4SDDXgW+vYzhNlGXQxhHs wZ4e28UmFSyhB0JgAHAIDo6TC0h/RbfFJkYZXiCzCu7OJtR68VJuJ028PIuVFz0kNO Pe7fAYYMl4pl1VHUAEupmpSi3oPUpHcFZk0DUiCo= 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 3785613213D for ; Wed, 30 Aug 2017 15:56:05 -0700 (PDT) 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=libertysys.com.au 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 2RFkc2N_CBPY for ; Wed, 30 Aug 2017 15:56:03 -0700 (PDT) Received: from mail.libertysys.com.au (ppp178-79.static.internode.on.net [150.101.178.79]) (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 36B5F13209C for ; Wed, 30 Aug 2017 15:56:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.libertysys.com.au (Postfix) with ESMTP id E3C0892436 for ; Thu, 31 Aug 2017 08:56:00 +1000 (AEST) X-Virus-Scanned: Debian amavisd-new at mail2.gear.dyndns.org Received: from mail.libertysys.com.au ([127.0.0.1]) by localhost (mail.gear.dyndns.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wYgPKETV1MC9 for ; Thu, 31 Aug 2017 08:55:55 +1000 (AEST) Received: from [172.22.64.102] (eber-home.gear.dyndns.org [172.22.64.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.libertysys.com.au (Postfix) with ESMTPSA id 846C592103 for ; Thu, 31 Aug 2017 08:55:54 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=libertysys.com.au; s=2016; t=1504133754; bh=9NGXs2NfsehuDoLvP3XrTMmFLB9KaMWwW7tprefWJOI=; h=From:Subject:To:References:Date:In-Reply-To; b=HnO3xj5eWHlq5mlv9Z6sN5jep3a1mqn8zyndBtO+Kqlo+0EiMx/KeiejGg69bcASG EAIdAMds3zy9LKNQmU9lpxKEPN0S9GJGGlDkbx/5RWioSDtX00/gexARWJyC+HP0Au 1kR5SqVCJ5amIxhDQK/kTUgR6YFjzdAw1Q+OomkQ= From: Paul Gear To: ntp@ietf.org References: <5BE6683D-396F-4FAA-B8E8-9E2C277B8A35@akamai.com> Message-ID: <48e72bef-c8fb-2335-f469-aad1bb2f59bd@libertysys.com.au> Date: Thu, 31 Aug 2017 08:55:54 +1000 MIME-Version: 1.0 In-Reply-To: Content-Language: en-AU Archived-At: Subject: Re: [Ntp] NTS changelog since draft 9 X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Errors-To: ntp-bounces@ietf.org Sender: "ntp" T24gMzEvMDgvMTcgMDU6MzEsIERhbmllbCBGcmFua2Ugd3JvdGU6Cj4gT24gOC8zMC8xNywgU2Fs eiwgUmljaCA8cnNhbHpAYWthbWFpLmNvbT4gd3JvdGU6Cj4+IC4uLgo+Pgo+PiBMaW5lIDYxNCwg aXQgZG9lc27igJl0IHNlZW0gcmlnaHQgdG8gc2F5IHRoYXQgeW91IG11c3Qgbm90IGF0dGVtcHQg dG8KPj4gaW50ZXJwcmV0IGNvb2tpZXMgYW5kIHRoZW4gaW50ZW5kIHRvIHByb3ZpZGUgYSByZWNv bW1lbmRlZCBjb25zdHJ1Y3Rpb24uCj4+IERlbGV0ZSB0aGUgcmVjb21tZW5kYXRpb24uCj4+Cj4+ IENoYW5nZSB0aGUgcmVjb21tZW5kZWQgZm9ybWF0IGZvciBOVFMgY29va2llcyB0byBiZSBhIG5v bi1ub3JtYXRpdmUgYXBwZW5kaXgKPj4gYW5kIGNhbGwgaXQgcG9zc2libGUgZm9ybWF0Lgo+IEkg dGhpbmsgdGhpcyBzZWN0aW9uIGlzIHByZXR0eSBpbXBvcnRhbnQgZm9yIHVuZGVyc3RhbmRpbmcg aG93IHRoZQo+IHByb3RvY29sIGlzIHN1cHBvc2VkIHRvIHdvcmssIGFuZCBkb24ndCB3YW50IHRv IHJlbGVnYXRlIGl0IHRvIGFuCj4gYXBwZW5kaXguIFdvdWxkIGFkZGluZyBhbiBleHBsaWNpdCAi VGhpcyBzZWN0aW9uIGlzIG5vbi1ub3JtYXRpdmUiIGJlCj4gc3VmZmljaWVudD8KClVudGlsIEkg aGFkIHNwZW50IHNvbWUgdGltZSB3aXRoIHNlY3Rpb24gNyBhbmQgUkZDIDUxMTYsIEkgZm91bmQg dGhlCmNvb2tpZSBtYW5hZ2VtZW50IHJhdGhlciBwZXJwbGV4aW5nLiAgQnV0IG5vdyB0aGF0IEkn dmUgcmVhZCB0aHJvdWdoIGl0CmEgZmV3IHRpbWVzLCBJIHRoaW5rIHRoZSB3YXkgY29va2llcyBh cmUgZm9ybWVkIGFuZCB1c2VkIGlzIHZpdGFsIHRvIGhvdwpOVFMgaXMgZXhwZWN0ZWQgdG8gd29y ayBpbiBwcmFjdGljZSwgYW5kIGlmIGFueXRoaW5nIEkgdGhpbmsgaXQgc2hvdWxkCmJlIG1vcmUg c3Ryb25nbHkgbWFuZGF0ZWQgcmF0aGVyIHRoYW4gbGVzcyAoaS5lLiBTSE9VTEQgcmF0aGVyIHRo YW4KT1BUSU9OQUwpLgoKR2l2aW5nIHByb3RvY29scyBhIHRvb2xraXQgdG8gZG8gY3J5cHRvIGlu IGEgc3RhbmRhcmRpc2VkIGFuZCBhYnN0cmFjdGVkCndheSBpcyBvbmUgb2YgdGhlIHByaW1hcnkg Z29hbHMgb2YgUkZDIDUxMTYsIGFuZCBpdCBzZWVtcyB0byBtZSB0aGF0Cm1ha2luZyB0aGUgY29v a2llIGZvcm1hdCBvcHRpb25hbCBpcyBhbiBvcHBvcnR1bml0eSBmb3IgTlRTIHRvIGVuZCB1cAp3 aXRoIGJhZCBjcnlwdG8gaW1wbGVtZW50YXRpb25zLgoKVGhpcyBsZWFkcyBtZSB0byBzb21lIHF1 ZXN0aW9ucyBmb3IgUmljaDogV2h5IGRvIHlvdSB0aGluayBpdCdzCmltcG9ydGFudCB0aGF0IHRo ZSBjdXJyZW50IGNvb2tpZSBmb3JtYXQgYmUgbm9uLW5vcm1hdGl2ZT8gIERvIHlvdSBoYXZlCmlu IG1pbmQgYW4gYWx0ZXJuYXRlIGNvb2tpZSBmb3JtYXRpb24gcHJvY2Vzcz8gIE9yIGFyZSB5b3Ug YXdhcmUgb2Ygc29tZQpjaXJjdW1zdGFuY2VzIHdoZXJlIHRoZSBjdXJyZW50IHJlY29tbWVuZGF0 aW9uIHdvdWxkIGJlIHVuZGVzaXJhYmxlIG9yCnVud29ya2FibGU/ICAoQXBvbG9naWVzIGlmIHRo aXMgc2hvdWxkIGJlIG9idmlvdXMsIGJ1dCBpdCdzIG5vdCBvYnZpb3VzCnRvIG1lIGF0IHByZXNl bnQuICBJIHRoaW5rIGRvY3VtZW50aW5nIGFzc3VtcHRpb25zIGlzIHZhbHVhYmxlIGZvciB0aG9z ZQpvZiB1cyB3aXRob3V0IGEgbG9uZyBoaXN0b3J5IGluIHRoZSBzdGFuZGFyZGlzYXRpb24gcHJv Y2Vzcy4pCgo+PiBEaWQgSSBtaXNzIGEgcGFydCB3aGVyZSB0aGUgY29va2llIGxlbmd0aCBpcyBk ZWZpbmVkPyAgV2l0aG91dCB0aGF0LCBob3cKPj4gZG9lcyB0aGUgUGxhY2Vob2xkZXIgd29yaz8g IEFuZCB0aGUgbGVuZ3RoIG9mIHRoZSBwbGFjZWhvbGRlciBpbmRpcmVjdGx5Cj4+IGluZGljYXRl cyB0aGUgbnVtYmVyIG9mIGNvb2tpZXMgdGhlIGNsaWVudCB3YW50cz8gIFdoYXQgaWYgdGhlIHNl cnZlciB3YW50cwo+PiB0byBnaXZlIGZld2VyIChvciBub25lKS4gIE9PSEhILCB0aGUgY2xpZW50 IHJlcGVhdHMgdGhlIGV4dGVuc2lvbiBmb3IgIyBvZgo+PiBjb29raWVzIGl0IHdhbnRzLiAgVGhh dCBzaG91bGQgYmUgbWFkZSBtb3JlIGNsZWFyLiBJZiB0aGUgdmFsdWUgb2YgdGhlCj4+IGV4dGVu c2lvbiBpcyB0byBiZSBpZ25vcmVkLCBqdXN0IHJlcXVpcmUgaXQgdG8gYmUgYWxsIHplcm/igJlz LgoKU2F5aW5nIHRoYXQgY29va2llIHBsYWNlaG9sZGVycyBTSE9VTEQgYmUgYWxsIHplcm8gaXMg YSBnb29kIGlkZWEuICBJdApsb29rcyBEYW5pZWwgaGFzIGNoYW5nZWQgdGhpcyBpbiBkcmFmdC1k ZnJhbmtlLW50cy54bWwgaW4gZ2l0IG1hc3RlciwKYnV0IG5vdCBpbiBkcmFmdC1pZXRmLW50cC11 c2luZy1udHMtZm9yLW50cC54bWwuICAoSSdtIG5vdCBzdXJlIHdoZXRoZXIKdGhpcyBpcyBpbnRl bnRpb25hbC4pCgpIb3dldmVyLCBJIGRvbid0IHJlY2FsbCBzZWVpbmcgYW55IGxhbmd1YWdlIHNw ZWNpZnlpbmcgd2hldGhlciBhbGwKY29va2llcyBzZW50IGJ5IGEgc2VydmVyIG11c3QgYmUgdGhl IHNhbWUgaW4gbGVuZ3RoLiAgSWYsIGZvciBleGFtcGxlLAphIHNlcnZlcidzIHNvZnR3YXJlIHZl cnNpb24gd2VyZSB1cGdyYWRlZCB0byBzdXBwb3J0IGEgbmV3IEFFQUQgc3VpdGUKYmV0d2VlbiBh IGNsaWVudCdzIHBvbGxzLCB0aGVuIGNvbmNlaXZhYmx5IHRoZSBuZXh0IGNvb2tpZSBjb3VsZCBi ZQpzbGlnaHRseSBzaG9ydGVyIG9yIGxvbmdlci4gIFNvIHBlcmhhcHMgdGhlIHdvcmRpbmcgc2hv dWxkIGJlOiAiLi4uIHRoZQpib2R5IGxlbmd0aCBvZiB0aGUgTlRTIENvb2tpZSBQbGFjZWhvbGRl ciBleHRlbnNpb24gTVVTVCBiZSB0aGUgc2FtZSBhcwp0aGUgYm9keSBsZW5ndGggb2YgW3RoZV0g TlRTIENvb2tpZSBbZV14dGVuc2lvbiBbbW9zdCByZWNlbnRseV0gcmVjZWl2ZWQKZnJvbSB0aGUg c2VydmVyLiIKCihBcyBhbiBhc2lkZTogaW4gdGhpcyBzY2VuYXJpbywgaWYgdGhlIG5ldyBzdWl0 ZSByZXF1aXJlZCBhIGxvbmdlcgpjb29raWUgdGhhbiB0aGUgcGxhY2Vob2xkZXIgc2VudCBieSB0 aGUgY2xpZW50LCBwcmVzdW1hYmx5IGEgTkFLIGFuZCBhbgpOVFMtS0UgcmVuZWdvdGlhdGlvbiB3 b3VsZCBiZSByZXF1aXJlZC4gRm9yIHNlcnZlcnMgd2l0aCBsYXJnZSBudW1iZXJzCm9mIGNsaWVu dHMsIHRoaXMgbWlnaHQgYmUgcHJvYmxlbWF0aWMuKQoKUmVnYXJkcywKUGF1bAoKX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbnRwIG1haWxpbmcgbGlzdApu dHBAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9udHAK From ntp-bounces@ietf.org Wed Aug 30 16:59:54 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2864613218C; Wed, 30 Aug 2017 16:59:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1504137594; bh=j9WCxJSiVeVm/UuSnWJNyMhwdphRpHFGtqsOaV67z78=; h=From:Date:To:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=gksepCoIvFQxsT7lnBgU7JAJGdGQXwzWoXituRxJ7dHyFXw/jP31Q01lFvlRq7bKn OetVn9oP2KVYck4T4i/kZnRofbcZYLrZGP1gOufwFVUjwExbY1uHqk7mzVJiLbAykJ ZvIOwHcgGP3Iynvnnradrf9RUREeToTkCmyQZ8pQ= 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 B67B2132332 for ; Wed, 30 Aug 2017 16:59:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.7 X-Spam-Level: X-Spam-Status: No, score=-3.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 75NzsKkzE9wk for ; Wed, 30 Aug 2017 16:59:51 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C48AC13218C for ; Wed, 30 Aug 2017 16:59:51 -0700 (PDT) Received: from mail.amsl.com (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTPS id 0AFF51C4A2E for ; Wed, 30 Aug 2017 16:59:03 -0700 (PDT) Received: from mail-io0-f169.google.com (mail-io0-f169.google.com [209.85.223.169]) by c8a.amsl.com (Postfix) with ESMTPSA id DD25A1C4553 for ; Wed, 30 Aug 2017 16:59:02 -0700 (PDT) Received: by mail-io0-f169.google.com with SMTP id n71so13279974iod.1 for ; Wed, 30 Aug 2017 16:59:51 -0700 (PDT) X-Gm-Message-State: AHYfb5hhoQvi5kMnSuThzLKCG3TjFZdzGax+Bpou2ax1t5ZyoZRaRRTd /U+AmoEdwnfy7LTNptf6lppk8l36+w== X-Received: by 10.36.224.66 with SMTP id c63mr3457636ith.0.1504137591077; Wed, 30 Aug 2017 16:59:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.2.21.211 with HTTP; Wed, 30 Aug 2017 16:59:30 -0700 (PDT) From: Glen Date: Wed, 30 Aug 2017 16:59:30 -0700 X-Gmail-Original-Message-ID: Message-ID: To: ntp@ietf.org Archived-At: Subject: [Ntp] Test message, with apologies X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============4425996968249730363==" Errors-To: ntp-bounces@ietf.org Sender: "ntp" --===============4425996968249730363== Content-Type: multipart/alternative; boundary="94eb2c19c340cf40ad055801529b" --94eb2c19c340cf40ad055801529b Content-Type: text/plain; charset="UTF-8" I am sorry for the noise. At Karen's request, I am debugging a list issue. Report to hopefully follow shortly. Glen --94eb2c19c340cf40ad055801529b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I am sorry for the noise.=C2=A0 At Karen's r= equest, I am debugging a list issue.

Report to hopefully follo= w shortly.

Glen
--94eb2c19c340cf40ad055801529b-- --===============4425996968249730363== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp --===============4425996968249730363==-- From nobody Wed Aug 30 16:59:54 2017 Return-Path: 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 B67B2132332 for ; Wed, 30 Aug 2017 16:59:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.7 X-Spam-Level: X-Spam-Status: No, score=-3.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 75NzsKkzE9wk for ; Wed, 30 Aug 2017 16:59:51 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C48AC13218C for ; Wed, 30 Aug 2017 16:59:51 -0700 (PDT) Received: from mail.amsl.com (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTPS id 0AFF51C4A2E for ; Wed, 30 Aug 2017 16:59:03 -0700 (PDT) Received: from mail-io0-f169.google.com (mail-io0-f169.google.com [209.85.223.169]) by c8a.amsl.com (Postfix) with ESMTPSA id DD25A1C4553 for ; Wed, 30 Aug 2017 16:59:02 -0700 (PDT) Received: by mail-io0-f169.google.com with SMTP id n71so13279974iod.1 for ; Wed, 30 Aug 2017 16:59:51 -0700 (PDT) X-Gm-Message-State: AHYfb5hhoQvi5kMnSuThzLKCG3TjFZdzGax+Bpou2ax1t5ZyoZRaRRTd /U+AmoEdwnfy7LTNptf6lppk8l36+w== X-Received: by 10.36.224.66 with SMTP id c63mr3457636ith.0.1504137591077; Wed, 30 Aug 2017 16:59:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.2.21.211 with HTTP; Wed, 30 Aug 2017 16:59:30 -0700 (PDT) From: Glen Date: Wed, 30 Aug 2017 16:59:30 -0700 X-Gmail-Original-Message-ID: Message-ID: To: ntp@ietf.org Content-Type: multipart/alternative; boundary="94eb2c19c340cf40ad055801529b" Archived-At: Subject: [Ntp] Test message, with apologies X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 23:59:52 -0000 --94eb2c19c340cf40ad055801529b Content-Type: text/plain; charset="UTF-8" I am sorry for the noise. At Karen's request, I am debugging a list issue. Report to hopefully follow shortly. Glen --94eb2c19c340cf40ad055801529b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I am sorry for the noise.=C2=A0 At Karen's r= equest, I am debugging a list issue.

Report to hopefully follo= w shortly.

Glen
--94eb2c19c340cf40ad055801529b-- From ntp-bounces@ietf.org Wed Aug 30 17:07:03 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AE54A13218C; Wed, 30 Aug 2017 17:07:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1504138023; bh=Iv+i7UM86ciNqYXLlcu+nMwoqA3tq4KIgVg5wRT1D38=; h=In-Reply-To:References:From:Date:To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe; b=JpRzEy6kNVNYtRQiUPXw27nKM8surkUGlW0jxigfd7HjA6Wygt2FdE0QsHJi4a6L+ 5ZUd5pitm73KYEDWf+eAqqGWWIXz1GJKw4nqgTivoD72L4eZV73IX9aUycAfC3z7mV zwUOH2BeM/gsIJCM15nRNkk75KPpqrbPu1IFPqd0= 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 42ECF132332 for ; Wed, 30 Aug 2017 17:07:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.699 X-Spam-Level: X-Spam-Status: No, score=-3.699 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 V3EiXkKUvVWo for ; Wed, 30 Aug 2017 17:07:01 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 041C3126DD9 for ; Wed, 30 Aug 2017 17:07:01 -0700 (PDT) Received: from mail.amsl.com (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTPS id 3C4AB1C4A2E for ; Wed, 30 Aug 2017 17:06:12 -0700 (PDT) Received: from mail-io0-f169.google.com (mail-io0-f169.google.com [209.85.223.169]) by c8a.amsl.com (Postfix) with ESMTPSA id 19F821C4A2D for ; Wed, 30 Aug 2017 17:06:12 -0700 (PDT) Received: by mail-io0-f169.google.com with SMTP id 81so13195202ioj.5 for ; Wed, 30 Aug 2017 17:07:00 -0700 (PDT) X-Gm-Message-State: AHYfb5i8NMKuZUHMbeW/A5LKgwMYtj0jrnthS/+SClZbqawMIDCX00UD GybDgYuCzo8F31tr63GWXdEgjs4GSA== X-Received: by 10.36.139.132 with SMTP id g126mr3564133ite.135.1504138020305; Wed, 30 Aug 2017 17:07:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.2.21.211 with HTTP; Wed, 30 Aug 2017 17:06:39 -0700 (PDT) In-Reply-To: References: From: Glen Date: Wed, 30 Aug 2017 17:06:39 -0700 X-Gmail-Original-Message-ID: Message-ID: To: ntp@ietf.org Archived-At: Subject: Re: [Ntp] Test message, with apologies X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0229630246876983656==" Errors-To: ntp-bounces@ietf.org Sender: "ntp" --===============0229630246876983656== Content-Type: multipart/alternative; boundary="94eb2c04ac2864c18b0558016cd9" --94eb2c04ac2864c18b0558016cd9 Content-Type: text/plain; charset="UTF-8" On Wed, Aug 30, 2017 at 4:59 PM, Glen wrote: > I am sorry for the noise. At Karen's request, I am debugging a list issue. > Report to hopefully follow shortly. > Glen All - A problem with this list, wherein users posting messages to the list were receiving support ticket acknowledgments from "donotreply@secureserver.net", has, hopefully, been resolved. For reasons I cannot fathom, "support@godaddy.com" had been subscribed to this list. So every message sent to the list was sent to support@godaddy, whose ticketing system dutifully acknowledged the "request" back to the originator. While many in that group of companies likely have an interest in your work, I doubt their tier-1 support desk does. I have removed them from this list, and that should, hopefully, put a stop to this. It is not necessary for any of you to resend your messages or take any other action. If we get further reports of this, we'll trace more deeply, but this *should* take care of the issue. I apologize for the intrusion and the noise. Glen -- Glen Barney IT Director AMS (IETF Secretariat) --94eb2c04ac2864c18b0558016cd9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, = Aug 30, 2017 at 4:59 PM, Glen <glen@ams= l.com> wrote:
> I am sorry for the noise.=C2=A0 At Karen's= request, I am debugging a list issue.
> Report to hopefully follow s= hortly.
> Glen

All -

A problem with this li= st, wherein users posting messages to the list were receiving support ticke= t acknowledgments from "donotreply@secureserver.net", has, hopefully, been resolved.
<= br>
For reasons I cannot fathom, "support@godaddy.com" had been subscribed to this list.=C2= =A0 So every message sent to the list was sent to support@godaddy, whose ti= cketing system dutifully acknowledged the "request" back to the o= riginator.=C2=A0

While many in that group of companies likely= have an interest in your work, I doubt their tier-1 support desk does.=C2= =A0 I have removed them from this list, and that should, hopefully, put a s= top to this.

It is not necessary for any of you to resend your= messages or take any other action.=C2=A0 If we get further reports of this= , we'll trace more deeply, but this *should* take care of the issue.
I apologize for the intrusion and the noise.

Glen--
Glen Barney
IT Director
AMS (IETF Secretari= at)
--94eb2c04ac2864c18b0558016cd9-- --===============0229630246876983656== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp --===============0229630246876983656==-- From nobody Wed Aug 30 17:07:03 2017 Return-Path: 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 42ECF132332 for ; Wed, 30 Aug 2017 17:07:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.699 X-Spam-Level: X-Spam-Status: No, score=-3.699 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 V3EiXkKUvVWo for ; Wed, 30 Aug 2017 17:07:01 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 041C3126DD9 for ; Wed, 30 Aug 2017 17:07:01 -0700 (PDT) Received: from mail.amsl.com (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTPS id 3C4AB1C4A2E for ; Wed, 30 Aug 2017 17:06:12 -0700 (PDT) Received: from mail-io0-f169.google.com (mail-io0-f169.google.com [209.85.223.169]) by c8a.amsl.com (Postfix) with ESMTPSA id 19F821C4A2D for ; Wed, 30 Aug 2017 17:06:12 -0700 (PDT) Received: by mail-io0-f169.google.com with SMTP id 81so13195202ioj.5 for ; Wed, 30 Aug 2017 17:07:00 -0700 (PDT) X-Gm-Message-State: AHYfb5i8NMKuZUHMbeW/A5LKgwMYtj0jrnthS/+SClZbqawMIDCX00UD GybDgYuCzo8F31tr63GWXdEgjs4GSA== X-Received: by 10.36.139.132 with SMTP id g126mr3564133ite.135.1504138020305; Wed, 30 Aug 2017 17:07:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.2.21.211 with HTTP; Wed, 30 Aug 2017 17:06:39 -0700 (PDT) In-Reply-To: References: From: Glen Date: Wed, 30 Aug 2017 17:06:39 -0700 X-Gmail-Original-Message-ID: Message-ID: To: ntp@ietf.org Content-Type: multipart/alternative; boundary="94eb2c04ac2864c18b0558016cd9" Archived-At: Subject: Re: [Ntp] Test message, with apologies X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 00:07:02 -0000 --94eb2c04ac2864c18b0558016cd9 Content-Type: text/plain; charset="UTF-8" On Wed, Aug 30, 2017 at 4:59 PM, Glen wrote: > I am sorry for the noise. At Karen's request, I am debugging a list issue. > Report to hopefully follow shortly. > Glen All - A problem with this list, wherein users posting messages to the list were receiving support ticket acknowledgments from "donotreply@secureserver.net", has, hopefully, been resolved. For reasons I cannot fathom, "support@godaddy.com" had been subscribed to this list. So every message sent to the list was sent to support@godaddy, whose ticketing system dutifully acknowledged the "request" back to the originator. While many in that group of companies likely have an interest in your work, I doubt their tier-1 support desk does. I have removed them from this list, and that should, hopefully, put a stop to this. It is not necessary for any of you to resend your messages or take any other action. If we get further reports of this, we'll trace more deeply, but this *should* take care of the issue. I apologize for the intrusion and the noise. Glen -- Glen Barney IT Director AMS (IETF Secretariat) --94eb2c04ac2864c18b0558016cd9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, = Aug 30, 2017 at 4:59 PM, Glen <glen@ams= l.com> wrote:
> I am sorry for the noise.=C2=A0 At Karen's= request, I am debugging a list issue.
> Report to hopefully follow s= hortly.
> Glen

All -

A problem with this li= st, wherein users posting messages to the list were receiving support ticke= t acknowledgments from "donotreply@secureserver.net", has, hopefully, been resolved.
<= br>
For reasons I cannot fathom, "support@godaddy.com" had been subscribed to this list.=C2= =A0 So every message sent to the list was sent to support@godaddy, whose ti= cketing system dutifully acknowledged the "request" back to the o= riginator.=C2=A0

While many in that group of companies likely= have an interest in your work, I doubt their tier-1 support desk does.=C2= =A0 I have removed them from this list, and that should, hopefully, put a s= top to this.

It is not necessary for any of you to resend your= messages or take any other action.=C2=A0 If we get further reports of this= , we'll trace more deeply, but this *should* take care of the issue.
I apologize for the intrusion and the noise.

Glen--
Glen Barney
IT Director
AMS (IETF Secretari= at)
--94eb2c04ac2864c18b0558016cd9-- From nobody Wed Aug 30 17:15:51 2017 Return-Path: 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 18F2A1321A8 for ; Wed, 30 Aug 2017 17:15:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 tCbrbhOk0lOY for ; Wed, 30 Aug 2017 17:15:48 -0700 (PDT) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (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 40274126DD9 for ; Wed, 30 Aug 2017 17:15:48 -0700 (PDT) Received: by mail-wm0-x22e.google.com with SMTP id u126so18867955wmg.1 for ; Wed, 30 Aug 2017 17:15:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Ve/sDNu9cNHis7SBM3UuTGn4W3s6nadNPcAt1jU1GaQ=; b=f3TJ8H0iqFRv+hDNcwRCWXtHK3rcEFyYC3Z0eOWzvh8ChljtxFFNAasRfbnLtrYuQ1 pdODipqVosOTjDQvntcNrhatt4V9lbx/2wrq89k6biIx2WSTqwRRk/9OfWztUYHWunx4 8JvWygGL9mTl1EOkSicZt95Db6MLbjWt4Wiq9Cvyr7quqa/7oQcGqHXKe0Zo7qjJKjE/ 94zIvYu7PGsU2d+YYQNO7gGuv6N+ei7n712BuRzDJi+gYTP0a3/gd2dv7esWKvRWx3mB P6yyAcGhqiC0K/vgrW+W0MmMgna3OlAFxuef6AEzBYF+2wTV1TQ5KCwYVD7/VgLiAJ5B pr8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Ve/sDNu9cNHis7SBM3UuTGn4W3s6nadNPcAt1jU1GaQ=; b=lMgMptaTStp7qC3S9eEd/kQEByWIqjArORtnVwzC2FSeapTlAgwNEEpv1NQC/30YOb Yri/qYxSzK3byLZhoMhmGkfKewppt3h+mFtzTXVmEcv7IiCbu5nuUTGIKJZEFF7wyMqV tN9+cUUZVmycuGajkvbS6xHXafMngarzA5hzxoSgw3R3USqqbJeFDFUJI2TbfYZB5b/g iksGifGd7aIRt7qTrOHzC3pIRjaJ01VlDv7EB8GUtlkfOd0nLPzLRwYphi40tgs06FN9 0mvzlSkQxlhDOpzZgDWaGFy2fUkWtYocr0eCNAn+jnGpJ90n/vYobKDss5sXfyv1AX5J fpXg== X-Gm-Message-State: AHYfb5i3k5LbKe0/t+IKwuIfEhD58n6lHv3CP+2jW6rwiHI25FVm/kfo MtwkFn90XHaRkiRWkoWrcbPvb6ZoSlSuCu4= X-Received: by 10.80.159.138 with SMTP id c10mr155870edf.257.1504138546662; Wed, 30 Aug 2017 17:15:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.157.140 with HTTP; Wed, 30 Aug 2017 17:15:46 -0700 (PDT) In-Reply-To: References: From: Daniel Franke Date: Wed, 30 Aug 2017 20:15:46 -0400 Message-ID: To: Glen Cc: ntp@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Ntp] Test message, with apologies X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 00:15:50 -0000 On 8/30/17, Glen wrote: > A problem with this list, wherein users posting messages to the list were > receiving support ticket acknowledgments from > "donotreply@secureserver.net", > has, hopefully, been resolved. > > For reasons I cannot fathom, "support@godaddy.com" had been subscribed to > this list. So every message sent to the list was sent to support@godaddy, > whose ticketing system dutifully acknowledged the "request" back to the > originator. So THAT'S what those things were. *Digs through spam folder, unflags a crapton of messages* From ntp-bounces@ietf.org Wed Aug 30 17:15:51 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BD8711323B8; Wed, 30 Aug 2017 17:15:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1504138551; bh=xKBJ5dOK+yUV1UX81kjem0JEokem1FBpaBOR5SamsdM=; h=In-Reply-To:References:From:Date:To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc; b=P78x5sUWQfgqnLUYsk9mLLS8452kxVsy43KdwIIkN9vQKrNr7On3qwLdmBacu2Y/0 ClZIdMCXeFRJiunK5FoSVybkDrhehMs2HGsWb95YqgqxLC4gHlMCgRZCSEUMQh0ad4 /HwauWZ2s7YhIeRZYtpxu02plbP2XcCG0M7fUHgE= 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 18F2A1321A8 for ; Wed, 30 Aug 2017 17:15:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 tCbrbhOk0lOY for ; Wed, 30 Aug 2017 17:15:48 -0700 (PDT) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (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 40274126DD9 for ; Wed, 30 Aug 2017 17:15:48 -0700 (PDT) Received: by mail-wm0-x22e.google.com with SMTP id u126so18867955wmg.1 for ; Wed, 30 Aug 2017 17:15:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Ve/sDNu9cNHis7SBM3UuTGn4W3s6nadNPcAt1jU1GaQ=; b=f3TJ8H0iqFRv+hDNcwRCWXtHK3rcEFyYC3Z0eOWzvh8ChljtxFFNAasRfbnLtrYuQ1 pdODipqVosOTjDQvntcNrhatt4V9lbx/2wrq89k6biIx2WSTqwRRk/9OfWztUYHWunx4 8JvWygGL9mTl1EOkSicZt95Db6MLbjWt4Wiq9Cvyr7quqa/7oQcGqHXKe0Zo7qjJKjE/ 94zIvYu7PGsU2d+YYQNO7gGuv6N+ei7n712BuRzDJi+gYTP0a3/gd2dv7esWKvRWx3mB P6yyAcGhqiC0K/vgrW+W0MmMgna3OlAFxuef6AEzBYF+2wTV1TQ5KCwYVD7/VgLiAJ5B pr8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Ve/sDNu9cNHis7SBM3UuTGn4W3s6nadNPcAt1jU1GaQ=; b=lMgMptaTStp7qC3S9eEd/kQEByWIqjArORtnVwzC2FSeapTlAgwNEEpv1NQC/30YOb Yri/qYxSzK3byLZhoMhmGkfKewppt3h+mFtzTXVmEcv7IiCbu5nuUTGIKJZEFF7wyMqV tN9+cUUZVmycuGajkvbS6xHXafMngarzA5hzxoSgw3R3USqqbJeFDFUJI2TbfYZB5b/g iksGifGd7aIRt7qTrOHzC3pIRjaJ01VlDv7EB8GUtlkfOd0nLPzLRwYphi40tgs06FN9 0mvzlSkQxlhDOpzZgDWaGFy2fUkWtYocr0eCNAn+jnGpJ90n/vYobKDss5sXfyv1AX5J fpXg== X-Gm-Message-State: AHYfb5i3k5LbKe0/t+IKwuIfEhD58n6lHv3CP+2jW6rwiHI25FVm/kfo MtwkFn90XHaRkiRWkoWrcbPvb6ZoSlSuCu4= X-Received: by 10.80.159.138 with SMTP id c10mr155870edf.257.1504138546662; Wed, 30 Aug 2017 17:15:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.157.140 with HTTP; Wed, 30 Aug 2017 17:15:46 -0700 (PDT) In-Reply-To: References: From: Daniel Franke Date: Wed, 30 Aug 2017 20:15:46 -0400 Message-ID: To: Glen Archived-At: Subject: Re: [Ntp] Test message, with apologies X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: ntp@ietf.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ntp-bounces@ietf.org Sender: "ntp" On 8/30/17, Glen wrote: > A problem with this list, wherein users posting messages to the list were > receiving support ticket acknowledgments from > "donotreply@secureserver.net", > has, hopefully, been resolved. > > For reasons I cannot fathom, "support@godaddy.com" had been subscribed to > this list. So every message sent to the list was sent to support@godaddy, > whose ticketing system dutifully acknowledged the "request" back to the > originator. So THAT'S what those things were. *Digs through spam folder, unflags a crapton of messages* _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp From nobody Wed Aug 30 18:26:55 2017 Return-Path: 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 03BEE126BFD for ; Wed, 30 Aug 2017 18:26:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 qkYCDe9Ei8cA for ; Wed, 30 Aug 2017 18:26:53 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::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 6E2A81204DA for ; Wed, 30 Aug 2017 18:26:53 -0700 (PDT) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v7V1Lvo4030486; Thu, 31 Aug 2017 02:26:51 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=XJoHpnNrj+GwFHH9jkK14+Hd+cux91rodHX8KuNyv3c=; b=KUr4jNnCoMPX11Uwbp/k/glizErSYNjdCo9YHLqFSLZfQA6hEV43FbxnSr4eIJw+GHLx cqCNLjwhKZPpBPMzxnt1GiuUltqLbD/c8ruuC2hPb2Ewd8xpQXs4iHfyI1WiLWoEqn3p LM69/s7nwVonr+jA5OK6JtEdloL+ghbyP18OjsCZ18DaD/fR/4AecS5aFm36VOE3sjHP IzpByYiyPM914hLkt/+sEpAkyipSACNYsgtlqOtXN4XrHbM6COzcD4QKVEh6ztLyM5mW gEYbNlYldSTDU09UCeqC1bwNdMAHoIkAT4fLiHR0KrUOKs1NgPyWKQpuYKyyeTxVbVI3 Zw== Received: from prod-mail-ppoint4 ([96.6.114.87]) by m0050096.ppops.net-00190b01. with ESMTP id 2ck1d7974n-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 31 Aug 2017 02:26:51 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v7V1PtqG003035; Wed, 30 Aug 2017 21:26:50 -0400 Received: from email.msg.corp.akamai.com ([172.27.25.34]) by prod-mail-ppoint4.akamai.com with ESMTP id 2ck4avrwjd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 30 Aug 2017 21:26:50 -0400 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb1.msg.corp.akamai.com (172.27.27.101) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 30 Aug 2017 20:26:50 -0500 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.6.131]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.6.131]) with mapi id 15.00.1263.000; Wed, 30 Aug 2017 20:26:49 -0500 From: "Salz, Rich" To: Paul Gear , "ntp@ietf.org" Thread-Topic: [Ntp] NTS changelog since draft 9 Thread-Index: AQHTIbHUYQo62yJ4HkOsJT6meZUHWqKdZUcA///QsQCAAGe7AIAAOP8A///TQYCAABPcAA== Date: Thu, 31 Aug 2017 01:26:49 +0000 Message-ID: <2DCA400C-DBE0-479E-A2F5-27D2650FF0D1@akamai.com> References: <5BE6683D-396F-4FAA-B8E8-9E2C277B8A35@akamai.com> <48e72bef-c8fb-2335-f469-aad1bb2f59bd@libertysys.com.au> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1b.0.161010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.47.35] Content-Type: text/plain; charset="utf-8" Content-ID: <9E37B5D23E354A43B846AA3AC10AF2A7@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-30_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1708310021 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-30_10:, , 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 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1708310020 Archived-At: Subject: Re: [Ntp] NTS changelog since draft 9 X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 01:26:55 -0000 DQoNCk9uIDgvMzAvMTcsIDg6MTUgUE0sICJTYWx6LCBSaWNoIiA8cnNhbHpAYWthbWFpLmNvbT4g d3JvdGU6DQoNCiAgICANCiAgICAgICAgVGhpcyBsZWFkcyBtZSB0byBzb21lIHF1ZXN0aW9ucyBm b3IgUmljaDogV2h5IGRvIHlvdSB0aGluayBpdCdzDQogICAgICAgIGltcG9ydGFudCB0aGF0IHRo ZSBjdXJyZW50IGNvb2tpZSBmb3JtYXQgYmUgbm9uLW5vcm1hdGl2ZT8gIERvIHlvdSBoYXZlDQog ICAgICAgIGluIG1pbmQgYW4gYWx0ZXJuYXRlIGNvb2tpZSBmb3JtYXRpb24gcHJvY2Vzcz8gIE9y IGFyZSB5b3UgYXdhcmUgb2Ygc29tZQ0KICAgIA0KICAgIFRoZSBkcmFmdCBzYXlzIOKAnGNsaWVu dHMgQ0FOTk9U4oCdIGRlcGVuZCBvbiB0aGUgZm9ybWF0LiAgVGhhdCBpbXBsaWVzIHRvIG1lLCBw cmV0dHkgY2xlYXJseSwgdGhhdCB0aGUgZGVzY3JpcHRpb24gaXMgbm90IG5vcm1hdGl2ZS4NCiAg ICANCiAgICBGb3IgYSBzaW5nbGUgc2hhcmVkLW1lbW9yeSBzeXN0ZW0sIHdoeSBjYW7igJl0IHRo ZSBjb29raWUgYmUgYSB2aXJ0dWFsIG1lbW9yeSBhZGRyZXNzPyAgV2h5IGNhbuKAmXQgaXQgYmUg YSBkYXRhYmFzZSBrZXk/DQogICAgDQogICAgICAgIEhvd2V2ZXIsIEkgZG9uJ3QgcmVjYWxsIHNl ZWluZyBhbnkgbGFuZ3VhZ2Ugc3BlY2lmeWluZyB3aGV0aGVyIGFsbA0KICAgICAgICBjb29raWVz IHNlbnQgYnkgYSBzZXJ2ZXIgbXVzdCBiZSB0aGUgc2FtZSBpbiBsZW5ndGguIA0KICAgIA0KICAg IEdvb2QgY2F0Y2ghDQogICAgDQogICAgICAgIHNsaWdodGx5IHNob3J0ZXIgb3IgbG9uZ2VyLiAg U28gcGVyaGFwcyB0aGUgd29yZGluZyBzaG91bGQgYmU6ICIuLi4gdGhlDQogICAgICAgIGJvZHkg bGVuZ3RoIG9mIHRoZSBOVFMgQ29va2llIFBsYWNlaG9sZGVyIGV4dGVuc2lvbiBNVVNUIGJlIHRo ZSBzYW1lIGFzDQogICAgICAgIHRoZSBib2R5IGxlbmd0aCBvZiBbdGhlXSBOVFMgQ29va2llIFtl XXh0ZW5zaW9uIFttb3N0IHJlY2VudGx5XSByZWNlaXZlZA0KICAgICAgICBmcm9tIHRoZSBzZXJ2 ZXIuIg0KICAgIA0KICAgICsxIA0KICAgICAgICANCiAgICAgDQogICAgDQogICAgDQoNCg== From ntp-bounces@ietf.org Wed Aug 30 18:26:56 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ABA0126BFD; Wed, 30 Aug 2017 18:26:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1504142816; bh=fiQj4uJaC3oGn/2tk6K8tQ2T1h8wjtIWSut/c6u8jGE=; h=From:To:Date:References:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe; b=BfTpTT2ZaLeUf8AVEkEdDl20xWInkZpEhxDgtxXEuhhEOYTDeHgTt1U0n/GjmLxx1 D8y/qSpD2yFhPhjd0LuUqpvUZeOMCC89WjZZt3msj3kBoYwwl5aC1k3ekObezyykyh 8w3CTZHec6npSzdOq6x9QfAtkfGQwrnBVLtpVoaw= 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 03BEE126BFD for ; Wed, 30 Aug 2017 18:26:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 qkYCDe9Ei8cA for ; Wed, 30 Aug 2017 18:26:53 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::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 6E2A81204DA for ; Wed, 30 Aug 2017 18:26:53 -0700 (PDT) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v7V1Lvo4030486; Thu, 31 Aug 2017 02:26:51 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=XJoHpnNrj+GwFHH9jkK14+Hd+cux91rodHX8KuNyv3c=; b=KUr4jNnCoMPX11Uwbp/k/glizErSYNjdCo9YHLqFSLZfQA6hEV43FbxnSr4eIJw+GHLx cqCNLjwhKZPpBPMzxnt1GiuUltqLbD/c8ruuC2hPb2Ewd8xpQXs4iHfyI1WiLWoEqn3p LM69/s7nwVonr+jA5OK6JtEdloL+ghbyP18OjsCZ18DaD/fR/4AecS5aFm36VOE3sjHP IzpByYiyPM914hLkt/+sEpAkyipSACNYsgtlqOtXN4XrHbM6COzcD4QKVEh6ztLyM5mW gEYbNlYldSTDU09UCeqC1bwNdMAHoIkAT4fLiHR0KrUOKs1NgPyWKQpuYKyyeTxVbVI3 Zw== Received: from prod-mail-ppoint4 ([96.6.114.87]) by m0050096.ppops.net-00190b01. with ESMTP id 2ck1d7974n-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 31 Aug 2017 02:26:51 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v7V1PtqG003035; Wed, 30 Aug 2017 21:26:50 -0400 Received: from email.msg.corp.akamai.com ([172.27.25.34]) by prod-mail-ppoint4.akamai.com with ESMTP id 2ck4avrwjd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 30 Aug 2017 21:26:50 -0400 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb1.msg.corp.akamai.com (172.27.27.101) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 30 Aug 2017 20:26:50 -0500 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.6.131]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.6.131]) with mapi id 15.00.1263.000; Wed, 30 Aug 2017 20:26:49 -0500 From: "Salz, Rich" To: Paul Gear , "ntp@ietf.org" Thread-Topic: [Ntp] NTS changelog since draft 9 Thread-Index: AQHTIbHUYQo62yJ4HkOsJT6meZUHWqKdZUcA///QsQCAAGe7AIAAOP8A///TQYCAABPcAA== Date: Thu, 31 Aug 2017 01:26:49 +0000 Message-ID: <2DCA400C-DBE0-479E-A2F5-27D2650FF0D1@akamai.com> References: <5BE6683D-396F-4FAA-B8E8-9E2C277B8A35@akamai.com> <48e72bef-c8fb-2335-f469-aad1bb2f59bd@libertysys.com.au> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1b.0.161010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.47.35] Content-ID: <9E37B5D23E354A43B846AA3AC10AF2A7@akamai.com> MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-30_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1708310021 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-30_10:, , 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 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1708310020 Archived-At: Subject: Re: [Ntp] NTS changelog since draft 9 X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Errors-To: ntp-bounces@ietf.org Sender: "ntp" DQoNCk9uIDgvMzAvMTcsIDg6MTUgUE0sICJTYWx6LCBSaWNoIiA8cnNhbHpAYWthbWFpLmNvbT4g d3JvdGU6DQoNCiAgICANCiAgICAgICAgVGhpcyBsZWFkcyBtZSB0byBzb21lIHF1ZXN0aW9ucyBm b3IgUmljaDogV2h5IGRvIHlvdSB0aGluayBpdCdzDQogICAgICAgIGltcG9ydGFudCB0aGF0IHRo ZSBjdXJyZW50IGNvb2tpZSBmb3JtYXQgYmUgbm9uLW5vcm1hdGl2ZT8gIERvIHlvdSBoYXZlDQog ICAgICAgIGluIG1pbmQgYW4gYWx0ZXJuYXRlIGNvb2tpZSBmb3JtYXRpb24gcHJvY2Vzcz8gIE9y IGFyZSB5b3UgYXdhcmUgb2Ygc29tZQ0KICAgIA0KICAgIFRoZSBkcmFmdCBzYXlzIOKAnGNsaWVu dHMgQ0FOTk9U4oCdIGRlcGVuZCBvbiB0aGUgZm9ybWF0LiAgVGhhdCBpbXBsaWVzIHRvIG1lLCBw cmV0dHkgY2xlYXJseSwgdGhhdCB0aGUgZGVzY3JpcHRpb24gaXMgbm90IG5vcm1hdGl2ZS4NCiAg ICANCiAgICBGb3IgYSBzaW5nbGUgc2hhcmVkLW1lbW9yeSBzeXN0ZW0sIHdoeSBjYW7igJl0IHRo ZSBjb29raWUgYmUgYSB2aXJ0dWFsIG1lbW9yeSBhZGRyZXNzPyAgV2h5IGNhbuKAmXQgaXQgYmUg YSBkYXRhYmFzZSBrZXk/DQogICAgDQogICAgICAgIEhvd2V2ZXIsIEkgZG9uJ3QgcmVjYWxsIHNl ZWluZyBhbnkgbGFuZ3VhZ2Ugc3BlY2lmeWluZyB3aGV0aGVyIGFsbA0KICAgICAgICBjb29raWVz IHNlbnQgYnkgYSBzZXJ2ZXIgbXVzdCBiZSB0aGUgc2FtZSBpbiBsZW5ndGguIA0KICAgIA0KICAg IEdvb2QgY2F0Y2ghDQogICAgDQogICAgICAgIHNsaWdodGx5IHNob3J0ZXIgb3IgbG9uZ2VyLiAg U28gcGVyaGFwcyB0aGUgd29yZGluZyBzaG91bGQgYmU6ICIuLi4gdGhlDQogICAgICAgIGJvZHkg bGVuZ3RoIG9mIHRoZSBOVFMgQ29va2llIFBsYWNlaG9sZGVyIGV4dGVuc2lvbiBNVVNUIGJlIHRo ZSBzYW1lIGFzDQogICAgICAgIHRoZSBib2R5IGxlbmd0aCBvZiBbdGhlXSBOVFMgQ29va2llIFtl XXh0ZW5zaW9uIFttb3N0IHJlY2VudGx5XSByZWNlaXZlZA0KICAgICAgICBmcm9tIHRoZSBzZXJ2 ZXIuIg0KICAgIA0KICAgICsxIA0KICAgICAgICANCiAgICAgDQogICAgDQogICAgDQoNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCm50cCBtYWlsaW5nIGxp c3QKbnRwQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbnRw Cg== From nobody Wed Aug 30 18:32:33 2017 Return-Path: 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 159B21204DA for ; Wed, 30 Aug 2017 18:32:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=libertysys.com.au 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 BXDaB_n5itNT for ; Wed, 30 Aug 2017 18:32:30 -0700 (PDT) Received: from mail.libertysys.com.au (ppp178-79.static.internode.on.net [150.101.178.79]) (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 1E1F1126BF0 for ; Wed, 30 Aug 2017 18:32:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.libertysys.com.au (Postfix) with ESMTP id E316F9224B for ; Thu, 31 Aug 2017 11:32:26 +1000 (AEST) X-Virus-Scanned: Debian amavisd-new at mail2.gear.dyndns.org Received: from mail.libertysys.com.au ([127.0.0.1]) by localhost (mail.gear.dyndns.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yjo5riFLcH46 for ; Thu, 31 Aug 2017 11:32:20 +1000 (AEST) Received: from [172.22.64.102] (eber-home.gear.dyndns.org [172.22.64.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.libertysys.com.au (Postfix) with ESMTPSA id 6B8A492103 for ; Thu, 31 Aug 2017 11:32:20 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=libertysys.com.au; s=2016; t=1504143140; bh=stpZk3OD/zwyAACg1Gvjki7729RXt0eJ4VN6lZHKiko=; h=Subject:To:References:From:Date:In-Reply-To; b=g9HWxICTGQ8rHFpMaVhPzAhOura+0usTaR/FRVObnZC4Mp76vm/MFZq46RDrklIg2 10mf7DgRPBmnE9jTiO54cDP37xf+Pj6FPrVelpEVZaNE4Xc6HYF8cjhJ7oiQdRNedW ozO3qET8VsAA/GDAlf6pr1KCWDp611DAaK7N//3g= To: ntp@ietf.org References: <5BE6683D-396F-4FAA-B8E8-9E2C277B8A35@akamai.com> <48e72bef-c8fb-2335-f469-aad1bb2f59bd@libertysys.com.au> <2DCA400C-DBE0-479E-A2F5-27D2650FF0D1@akamai.com> From: Paul Gear Message-ID: <26533cec-64c5-859c-b181-4b2d21758099@libertysys.com.au> Date: Thu, 31 Aug 2017 11:32:20 +1000 MIME-Version: 1.0 In-Reply-To: <2DCA400C-DBE0-479E-A2F5-27D2650FF0D1@akamai.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-AU Archived-At: Subject: Re: [Ntp] NTS changelog since draft 9 X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 01:32:32 -0000 On 31/08/17 11:26, Salz, Rich wrote: > > On 8/30/17, 8:15 PM, "Salz, Rich" wrote: > > > This leads me to some questions for Rich: Why do you think it's > important that the current cookie format be non-normative? Do you have > in mind an alternate cookie formation process? Or are you aware of some > > The draft says “clients CANNOT†depend on the format. That implies to me, pretty clearly, that the description is not normative. The cookie format described in the draft clearly says that clients aren't to depend on it, but it's absolutely vital that the server understand it, because it contains the keys necessary to decrypt and validate the client request. > > For a single shared-memory system, why can’t the cookie be a virtual memory address? Why can’t it be a database key? Because that's storing state on the server - the point of the cookie is to offload the session state storage (including all necessary keys) to the client. Regards, Paul From ntp-bounces@ietf.org Wed Aug 30 18:32:33 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C6DA31321B0; Wed, 30 Aug 2017 18:32:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1504143153; bh=1e/8F4QN6wyO5j6JpWSx6+nwiMQxI3hVCAtyKGZB7TU=; h=To:References:From:Date:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe; b=Q72wiXMhOBXEzYDU3SC38VLTZ+x6UkwBX3woTreSCUcq/M0NiEj3d+4kK6C/5Cd5U 6TmnrTU1IpoW2pQr1J3TIKEA+HFNYESws5ju0yeQNf4JG4AaLAJ742MNs8wrqyIskJ KZz2XbbQtY4kI9wbIJgsUs24NJEJHKFcAxmUVDTM= 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 159B21204DA for ; Wed, 30 Aug 2017 18:32:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=libertysys.com.au 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 BXDaB_n5itNT for ; Wed, 30 Aug 2017 18:32:30 -0700 (PDT) Received: from mail.libertysys.com.au (ppp178-79.static.internode.on.net [150.101.178.79]) (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 1E1F1126BF0 for ; Wed, 30 Aug 2017 18:32:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.libertysys.com.au (Postfix) with ESMTP id E316F9224B for ; Thu, 31 Aug 2017 11:32:26 +1000 (AEST) X-Virus-Scanned: Debian amavisd-new at mail2.gear.dyndns.org Received: from mail.libertysys.com.au ([127.0.0.1]) by localhost (mail.gear.dyndns.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yjo5riFLcH46 for ; Thu, 31 Aug 2017 11:32:20 +1000 (AEST) Received: from [172.22.64.102] (eber-home.gear.dyndns.org [172.22.64.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.libertysys.com.au (Postfix) with ESMTPSA id 6B8A492103 for ; Thu, 31 Aug 2017 11:32:20 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=libertysys.com.au; s=2016; t=1504143140; bh=stpZk3OD/zwyAACg1Gvjki7729RXt0eJ4VN6lZHKiko=; h=Subject:To:References:From:Date:In-Reply-To; b=g9HWxICTGQ8rHFpMaVhPzAhOura+0usTaR/FRVObnZC4Mp76vm/MFZq46RDrklIg2 10mf7DgRPBmnE9jTiO54cDP37xf+Pj6FPrVelpEVZaNE4Xc6HYF8cjhJ7oiQdRNedW ozO3qET8VsAA/GDAlf6pr1KCWDp611DAaK7N//3g= To: ntp@ietf.org References: <5BE6683D-396F-4FAA-B8E8-9E2C277B8A35@akamai.com> <48e72bef-c8fb-2335-f469-aad1bb2f59bd@libertysys.com.au> <2DCA400C-DBE0-479E-A2F5-27D2650FF0D1@akamai.com> From: Paul Gear Message-ID: <26533cec-64c5-859c-b181-4b2d21758099@libertysys.com.au> Date: Thu, 31 Aug 2017 11:32:20 +1000 MIME-Version: 1.0 In-Reply-To: <2DCA400C-DBE0-479E-A2F5-27D2650FF0D1@akamai.com> Content-Language: en-AU Archived-At: Subject: Re: [Ntp] NTS changelog since draft 9 X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Errors-To: ntp-bounces@ietf.org Sender: "ntp" T24gMzEvMDgvMTcgMTE6MjYsIFNhbHosIFJpY2ggd3JvdGU6Cj4KPiBPbiA4LzMwLzE3LCA4OjE1 IFBNLCAiU2FseiwgUmljaCIgPHJzYWx6QGFrYW1haS5jb20+IHdyb3RlOgo+Cj4gICAgIAo+ICAg ICAgICAgVGhpcyBsZWFkcyBtZSB0byBzb21lIHF1ZXN0aW9ucyBmb3IgUmljaDogV2h5IGRvIHlv dSB0aGluayBpdCdzCj4gICAgICAgICBpbXBvcnRhbnQgdGhhdCB0aGUgY3VycmVudCBjb29raWUg Zm9ybWF0IGJlIG5vbi1ub3JtYXRpdmU/ICBEbyB5b3UgaGF2ZQo+ICAgICAgICAgaW4gbWluZCBh biBhbHRlcm5hdGUgY29va2llIGZvcm1hdGlvbiBwcm9jZXNzPyAgT3IgYXJlIHlvdSBhd2FyZSBv ZiBzb21lCj4gICAgIAo+ICAgICBUaGUgZHJhZnQgc2F5cyDigJxjbGllbnRzIENBTk5PVOKAnSBk ZXBlbmQgb24gdGhlIGZvcm1hdC4gIFRoYXQgaW1wbGllcyB0byBtZSwgcHJldHR5IGNsZWFybHks IHRoYXQgdGhlIGRlc2NyaXB0aW9uIGlzIG5vdCBub3JtYXRpdmUuCgpUaGUgY29va2llIGZvcm1h dCBkZXNjcmliZWQgaW4gdGhlIGRyYWZ0IGNsZWFybHkgc2F5cyB0aGF0IGNsaWVudHMKYXJlbid0 IHRvIGRlcGVuZCBvbiBpdCwgYnV0IGl0J3MgYWJzb2x1dGVseSB2aXRhbCB0aGF0IHRoZSBzZXJ2 ZXIKdW5kZXJzdGFuZCBpdCwgYmVjYXVzZSBpdCBjb250YWlucyB0aGUga2V5cyBuZWNlc3Nhcnkg dG8gZGVjcnlwdCBhbmQKdmFsaWRhdGUgdGhlIGNsaWVudCByZXF1ZXN0LgoKPiAgICAgCj4gICAg IEZvciBhIHNpbmdsZSBzaGFyZWQtbWVtb3J5IHN5c3RlbSwgd2h5IGNhbuKAmXQgdGhlIGNvb2tp ZSBiZSBhIHZpcnR1YWwgbWVtb3J5IGFkZHJlc3M/ICBXaHkgY2Fu4oCZdCBpdCBiZSBhIGRhdGFi YXNlIGtleT8KCkJlY2F1c2UgdGhhdCdzIHN0b3Jpbmcgc3RhdGUgb24gdGhlIHNlcnZlciAtIHRo ZSBwb2ludCBvZiB0aGUgY29va2llIGlzCnRvIG9mZmxvYWQgdGhlIHNlc3Npb24gc3RhdGUgc3Rv cmFnZSAoaW5jbHVkaW5nIGFsbCBuZWNlc3Nhcnkga2V5cykgdG8KdGhlIGNsaWVudC4KClJlZ2Fy ZHMsClBhdWwKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Cm50cCBtYWlsaW5nIGxpc3QKbnRwQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbnRwCg== From ntp-bounces@ietf.org Wed Aug 30 18:39:22 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EF0E613219A; Wed, 30 Aug 2017 18:39:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1504143562; bh=lA6qfd0cXv8vCCFu1VS4ytEtGLClMOFMEZgjnazsiNA=; h=From:To:Date:References:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe; b=kIvrCB2X1G+eEJiKkTLVVCWqwXCk9JyrjZfNCanPfm8XbEIDxB7NA3fDczb1POB3T jMPve43LHhqWk92IHqyST/u7DCp38eEKAc1J1CQ3ovu905+UwAyEx8KH/9uPliB9Nh DqwTHOjEeRw2NpGCRcQm1KBU+Od/WXFBoIgH6hK4= 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 873CE13219A for ; Wed, 30 Aug 2017 18:39:20 -0700 (PDT) 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, SPF_PASS=-0.001] 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 JHggANeoDmGC for ; Wed, 30 Aug 2017 18:39:19 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::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 005D1132195 for ; Wed, 30 Aug 2017 18:39:18 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v7V1btAR021212; Thu, 31 Aug 2017 02:39:17 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=l8rZVTO2vP2flT8JS/0Fi4lZikSqKuR3c5crBpSbdgw=; b=fdg5oj5o9nugU1bJpQv1nQXj0I5N/qfeBcTFyaZpzSPHXFO0hYDZy1KgjG+7bYBMZc0B LXfs1c8G116U192IDyXI0MixTg2iA40aAAVwgw3+lP9mME1F50+ysYneKowuB8T+0oeb 3vAjN7S65UXINc4E6875zKsD6k2CxW6GmM6MfgSVd8rCF0NKShcF8NvjXzoMHtVUuWGL 9KVKkB24qMx8sfODzVzM3P4cuoCn7tmonXvLfz+ReeReWhVCXrtCXIzcd/ahlsN/OFNi u9pGFrE2LM0ErhUFroyBsrUKS1VVsm2868VWTct88kOw1R7shcZ5hNydqk0vDbMewL9E 1Q== Received: from prod-mail-ppoint3 ([96.6.114.86]) by m0050102.ppops.net-00190b01. with ESMTP id 2cjx2bt07s-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 31 Aug 2017 02:39:16 +0100 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v7V1aHZc010902; Wed, 30 Aug 2017 21:39:16 -0400 Received: from email.msg.corp.akamai.com ([172.27.25.32]) by prod-mail-ppoint3.akamai.com with ESMTP id 2cp60rgyt4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 30 Aug 2017 21:39:15 -0400 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb2.msg.corp.akamai.com (172.27.27.102) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 30 Aug 2017 20:39:07 -0500 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.6.131]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.6.131]) with mapi id 15.00.1263.000; Wed, 30 Aug 2017 20:39:07 -0500 From: "Salz, Rich" To: Paul Gear , "ntp@ietf.org" Thread-Topic: [Ntp] NTS changelog since draft 9 Thread-Index: AQHTIbHUYQo62yJ4HkOsJT6meZUHWqKdZUcA///QsQCAAGe7AIAAOP8A///TQYCAABPcAIAARJgA//++1YA= Date: Thu, 31 Aug 2017 01:39:06 +0000 Message-ID: References: <5BE6683D-396F-4FAA-B8E8-9E2C277B8A35@akamai.com> <48e72bef-c8fb-2335-f469-aad1bb2f59bd@libertysys.com.au> <2DCA400C-DBE0-479E-A2F5-27D2650FF0D1@akamai.com> <26533cec-64c5-859c-b181-4b2d21758099@libertysys.com.au> In-Reply-To: <26533cec-64c5-859c-b181-4b2d21758099@libertysys.com.au> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1b.0.161010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.47.35] Content-ID: <5969B110733C8540B93B30D59C42030A@akamai.com> MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-30_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1708310023 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-30_10:, , 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 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1708310024 Archived-At: Subject: Re: [Ntp] NTS changelog since draft 9 X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Errors-To: ntp-bounces@ietf.org Sender: "ntp" 4p6iIFRoZSBjb29raWUgZm9ybWF0IGRlc2NyaWJlZCBpbiB0aGUgZHJhZnQgY2xlYXJseSBzYXlz IHRoYXQgY2xpZW50cw0KICAgIGFyZW4ndCB0byBkZXBlbmQgb24gaXQsIGJ1dCBpdCdzIGFic29s dXRlbHkgdml0YWwgdGhhdCB0aGUgc2VydmVyDQogICAgdW5kZXJzdGFuZCBpdCwgYmVjYXVzZSBp dCBjb250YWlucyB0aGUga2V5cyBuZWNlc3NhcnkgdG8gZGVjcnlwdCBhbmQNCiAgICB2YWxpZGF0 ZSB0aGUgY2xpZW50IHJlcXVlc3QuDQogICAgDQpXZWxsIHllYWgsIG9mIGNvdXJzZSDimLoNCg0K 4p6iICAgICBCZWNhdXNlIHRoYXQncyBzdG9yaW5nIHN0YXRlIG9uIHRoZSBzZXJ2ZXIgLSB0aGUg cG9pbnQgb2YgdGhlIGNvb2tpZSBpcw0KICAgIHRvIG9mZmxvYWQgdGhlIHNlc3Npb24gc3RhdGUg c3RvcmFnZSAoaW5jbHVkaW5nIGFsbCBuZWNlc3Nhcnkga2V5cykgdG8NCiAgICB0aGUgY2xpZW50 Lg0KICAgIA0KSWYgbXkgc2VydmVyIGNob3NlIHRvIGRvIHRoYXQsIGhvdyB3b3VsZCBhbnlvbmUg a25vdz8gIEhvdyBjb3VsZCBhbnlvbmUgY2FyZT8NCg0KRGVzY3JpYmluZyBvbmUgcG9zc2libGUg Y29va2llIGZvcm1hdCwgaW4gYSBjcnlwdG9ncmFwaGljYWxseS1zdHJvbmcgd2F5LCBpcyBhIGdv b2QgdGhpbmcuICBCdXQgdGhlIFJGQyByZWFsbHkgc2hvdWxkbuKAmXQgZG8gYW55dGhpbmcgb3Ro ZXIgdGhhbiBzYXkg4oCcaGVyZeKAmXMgc29tZXRoaW5nIHlvdSBjYW4gdXNl4oCdICBBcyBhbiBB cHBlbmRpeC4NCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXwpudHAgbWFpbGluZyBsaXN0Cm50cEBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL250cAo= From nobody Wed Aug 30 18:39:22 2017 Return-Path: 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 873CE13219A for ; Wed, 30 Aug 2017 18:39:20 -0700 (PDT) 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, SPF_PASS=-0.001] 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 JHggANeoDmGC for ; Wed, 30 Aug 2017 18:39:19 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::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 005D1132195 for ; Wed, 30 Aug 2017 18:39:18 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v7V1btAR021212; Thu, 31 Aug 2017 02:39:17 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=l8rZVTO2vP2flT8JS/0Fi4lZikSqKuR3c5crBpSbdgw=; b=fdg5oj5o9nugU1bJpQv1nQXj0I5N/qfeBcTFyaZpzSPHXFO0hYDZy1KgjG+7bYBMZc0B LXfs1c8G116U192IDyXI0MixTg2iA40aAAVwgw3+lP9mME1F50+ysYneKowuB8T+0oeb 3vAjN7S65UXINc4E6875zKsD6k2CxW6GmM6MfgSVd8rCF0NKShcF8NvjXzoMHtVUuWGL 9KVKkB24qMx8sfODzVzM3P4cuoCn7tmonXvLfz+ReeReWhVCXrtCXIzcd/ahlsN/OFNi u9pGFrE2LM0ErhUFroyBsrUKS1VVsm2868VWTct88kOw1R7shcZ5hNydqk0vDbMewL9E 1Q== Received: from prod-mail-ppoint3 ([96.6.114.86]) by m0050102.ppops.net-00190b01. with ESMTP id 2cjx2bt07s-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 31 Aug 2017 02:39:16 +0100 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v7V1aHZc010902; Wed, 30 Aug 2017 21:39:16 -0400 Received: from email.msg.corp.akamai.com ([172.27.25.32]) by prod-mail-ppoint3.akamai.com with ESMTP id 2cp60rgyt4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 30 Aug 2017 21:39:15 -0400 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb2.msg.corp.akamai.com (172.27.27.102) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 30 Aug 2017 20:39:07 -0500 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.6.131]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.6.131]) with mapi id 15.00.1263.000; Wed, 30 Aug 2017 20:39:07 -0500 From: "Salz, Rich" To: Paul Gear , "ntp@ietf.org" Thread-Topic: [Ntp] NTS changelog since draft 9 Thread-Index: AQHTIbHUYQo62yJ4HkOsJT6meZUHWqKdZUcA///QsQCAAGe7AIAAOP8A///TQYCAABPcAIAARJgA//++1YA= Date: Thu, 31 Aug 2017 01:39:06 +0000 Message-ID: References: <5BE6683D-396F-4FAA-B8E8-9E2C277B8A35@akamai.com> <48e72bef-c8fb-2335-f469-aad1bb2f59bd@libertysys.com.au> <2DCA400C-DBE0-479E-A2F5-27D2650FF0D1@akamai.com> <26533cec-64c5-859c-b181-4b2d21758099@libertysys.com.au> In-Reply-To: <26533cec-64c5-859c-b181-4b2d21758099@libertysys.com.au> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1b.0.161010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.47.35] Content-Type: text/plain; charset="utf-8" Content-ID: <5969B110733C8540B93B30D59C42030A@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-30_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1708310023 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-30_10:, , 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 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1708310024 Archived-At: Subject: Re: [Ntp] NTS changelog since draft 9 X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 01:39:20 -0000 4p6iIFRoZSBjb29raWUgZm9ybWF0IGRlc2NyaWJlZCBpbiB0aGUgZHJhZnQgY2xlYXJseSBzYXlz IHRoYXQgY2xpZW50cw0KICAgIGFyZW4ndCB0byBkZXBlbmQgb24gaXQsIGJ1dCBpdCdzIGFic29s dXRlbHkgdml0YWwgdGhhdCB0aGUgc2VydmVyDQogICAgdW5kZXJzdGFuZCBpdCwgYmVjYXVzZSBp dCBjb250YWlucyB0aGUga2V5cyBuZWNlc3NhcnkgdG8gZGVjcnlwdCBhbmQNCiAgICB2YWxpZGF0 ZSB0aGUgY2xpZW50IHJlcXVlc3QuDQogICAgDQpXZWxsIHllYWgsIG9mIGNvdXJzZSDimLoNCg0K 4p6iICAgICBCZWNhdXNlIHRoYXQncyBzdG9yaW5nIHN0YXRlIG9uIHRoZSBzZXJ2ZXIgLSB0aGUg cG9pbnQgb2YgdGhlIGNvb2tpZSBpcw0KICAgIHRvIG9mZmxvYWQgdGhlIHNlc3Npb24gc3RhdGUg c3RvcmFnZSAoaW5jbHVkaW5nIGFsbCBuZWNlc3Nhcnkga2V5cykgdG8NCiAgICB0aGUgY2xpZW50 Lg0KICAgIA0KSWYgbXkgc2VydmVyIGNob3NlIHRvIGRvIHRoYXQsIGhvdyB3b3VsZCBhbnlvbmUg a25vdz8gIEhvdyBjb3VsZCBhbnlvbmUgY2FyZT8NCg0KRGVzY3JpYmluZyBvbmUgcG9zc2libGUg Y29va2llIGZvcm1hdCwgaW4gYSBjcnlwdG9ncmFwaGljYWxseS1zdHJvbmcgd2F5LCBpcyBhIGdv b2QgdGhpbmcuICBCdXQgdGhlIFJGQyByZWFsbHkgc2hvdWxkbuKAmXQgZG8gYW55dGhpbmcgb3Ro ZXIgdGhhbiBzYXkg4oCcaGVyZeKAmXMgc29tZXRoaW5nIHlvdSBjYW4gdXNl4oCdICBBcyBhbiBB cHBlbmRpeC4NCg0KDQo= From nobody Wed Aug 30 18:54:28 2017 Return-Path: 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 089AA13219A for ; Wed, 30 Aug 2017 18:54:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=libertysys.com.au 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 WkF9BN_qP0C8 for ; Wed, 30 Aug 2017 18:54:25 -0700 (PDT) Received: from mail.libertysys.com.au (ppp178-79.static.internode.on.net [150.101.178.79]) (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 A2019124207 for ; Wed, 30 Aug 2017 18:54:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.libertysys.com.au (Postfix) with ESMTP id 6F2E892123 for ; Thu, 31 Aug 2017 11:54:21 +1000 (AEST) X-Virus-Scanned: Debian amavisd-new at mail2.gear.dyndns.org Received: from mail.libertysys.com.au ([127.0.0.1]) by localhost (mail.gear.dyndns.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SE9f1U8aBEDG for ; Thu, 31 Aug 2017 11:54:15 +1000 (AEST) Received: from [172.22.64.102] (eber-home.gear.dyndns.org [172.22.64.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.libertysys.com.au (Postfix) with ESMTPSA id 6142392103 for ; Thu, 31 Aug 2017 11:54:15 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=libertysys.com.au; s=2016; t=1504144455; bh=cXoW74KlvlnZdBPH1zRb7E6x29Xc944whvUWfrUq4t8=; h=From:Subject:To:References:Date:In-Reply-To; b=bifRm4efwL0MLh83S+a3qU9uMN0qVdVwmwHha+PjX7nplw7H4ofzLixLN5UCMt2MW iropy8ZCRN+ekEmQ0DXNNJr+hrDNz2twrXL/mjBd7V+JyUkPrAu0gVXeoYogxW/nUc 3pVbkGoOJh0ieuvu+9ejwcfsYSqbYj6SCf3Z+234= From: Paul Gear To: ntp@ietf.org References: <5BE6683D-396F-4FAA-B8E8-9E2C277B8A35@akamai.com> <48e72bef-c8fb-2335-f469-aad1bb2f59bd@libertysys.com.au> <2DCA400C-DBE0-479E-A2F5-27D2650FF0D1@akamai.com> <26533cec-64c5-859c-b181-4b2d21758099@libertysys.com.au> Message-ID: <7d48ed90-b293-3ad2-0132-d778475aeefb@libertysys.com.au> Date: Thu, 31 Aug 2017 11:54:15 +1000 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------8408778EFBC477BE6EEFE385" Content-Language: en-AU Archived-At: Subject: Re: [Ntp] NTS changelog since draft 9 X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 01:54:27 -0000 This is a multi-part message in MIME format. --------------8408778EFBC477BE6EEFE385 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit On 31/08/17 11:39, Salz, Rich wrote: > ➢ The cookie format described in the draft clearly says that clients > aren't to depend on it, but it's absolutely vital that the server > understand it, because it contains the keys necessary to decrypt and > validate the client request. > > Well yeah, of course ☺ Your original comment on this was: > Line 614, it doesn’t seem right to say that you must not attempt to > interpret cookies and then intend to provide a recommended construction. > Delete the recommendation. The draft doesn't say that "you" must not attempt to interpret cookies. It says clients must not. And then section 7 provides a recommended way for servers to interpret them. This seems completely valid and expected. So I'm not seeing your point about why it should be deleted. Apologies if I'm being thick. > ➢ Because that's storing state on the server - the point of the cookie is > to offload the session state storage (including all necessary keys) to > the client. > > If my server chose to do that, how would anyone know? How could anyone care? That's why it should be RECOMMENDED rather than REQUIRED. > Describing one possible cookie format, in a cryptographically-strong way, is a good thing. But the RFC really shouldn’t do anything other than say “here’s something you can use†As an Appendix. I think the same principle applies here which was discussed recently in the thread about client data minimisation: each protocol standard should do its part (however small) to ensure cryptographically strong behaviour by default. If there are good reasons for overriding this behaviour, then implementations should be able to do so, but that's well within the guidelines for RECOMMENDED and in my opinion doesn't warrant deleting the recommendation or moving such a vital piece of the scalability story for NTS to an appendix. Paul --------------8408778EFBC477BE6EEFE385 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 31/08/17 11:39, Salz, Rich wrote:
➢ The cookie format described in the draft clearly says that clients
    aren't to depend on it, but it's absolutely vital that the server
    understand it, because it contains the keys necessary to decrypt and
    validate the client request.
    
Well yeah, of course ☺

Your original comment on this was:
Line 614, it doesn’t seem right to say that you must not attempt to
interpret cookies and then intend to provide a recommended construction.
Delete the recommendation.

The draft doesn't say that "you" must not attempt to interpret cookies.  It says clients must not.  And then section 7 provides a recommended way for servers to interpret them.  This seems completely valid and expected.  So I'm not seeing your point about why it should be deleted.  Apologies if I'm being thick.

➢     Because that's storing state on the server - the point of the cookie is
    to offload the session state storage (including all necessary keys) to
    the client.
    
If my server chose to do that, how would anyone know?  How could anyone care?

That's why it should be RECOMMENDED rather than REQUIRED.

Describing one possible cookie format, in a cryptographically-strong way, is a good thing.  But the RFC really shouldn’t do anything other than say “here’s something you can use† As an Appendix.

I think the same principle applies here which was discussed recently in the thread about client data minimisation: each protocol standard should do its part (however small) to ensure cryptographically strong behaviour by default.  If there are good reasons for overriding this behaviour, then implementations should be able to do so, but that's well within the guidelines for RECOMMENDED and in my opinion doesn't warrant deleting the recommendation or moving such a vital piece of the scalability story for NTS to an appendix.

Paul

--------------8408778EFBC477BE6EEFE385-- From ntp-bounces@ietf.org Wed Aug 30 18:54:29 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EA25A13219A; Wed, 30 Aug 2017 18:54:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1504144469; bh=eKRBmjUUiwC3QT27VO2Uw1zVkcp1ohCDgT+SPGQBO1o=; h=From:To:References:Date:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe; b=lym7E0kG2BOvgLBBx/hJelC7/l8WWOvC8krGhDqU7j1HXhni4Ur4BC1Un6+ugbn+Y tF8NpHGNEZ4RLyIOUYcL+66A1ke/Coa5n99K1yl+wvoZouA5GiNI38sMgXNpxWeJm5 eaMDj51eLkD7tYSz3qFPRZrJBl3asZi8jR4c92AY= 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 089AA13219A for ; Wed, 30 Aug 2017 18:54:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=libertysys.com.au 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 WkF9BN_qP0C8 for ; Wed, 30 Aug 2017 18:54:25 -0700 (PDT) Received: from mail.libertysys.com.au (ppp178-79.static.internode.on.net [150.101.178.79]) (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 A2019124207 for ; Wed, 30 Aug 2017 18:54:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.libertysys.com.au (Postfix) with ESMTP id 6F2E892123 for ; Thu, 31 Aug 2017 11:54:21 +1000 (AEST) X-Virus-Scanned: Debian amavisd-new at mail2.gear.dyndns.org Received: from mail.libertysys.com.au ([127.0.0.1]) by localhost (mail.gear.dyndns.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SE9f1U8aBEDG for ; Thu, 31 Aug 2017 11:54:15 +1000 (AEST) Received: from [172.22.64.102] (eber-home.gear.dyndns.org [172.22.64.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.libertysys.com.au (Postfix) with ESMTPSA id 6142392103 for ; Thu, 31 Aug 2017 11:54:15 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=libertysys.com.au; s=2016; t=1504144455; bh=cXoW74KlvlnZdBPH1zRb7E6x29Xc944whvUWfrUq4t8=; h=From:Subject:To:References:Date:In-Reply-To; b=bifRm4efwL0MLh83S+a3qU9uMN0qVdVwmwHha+PjX7nplw7H4ofzLixLN5UCMt2MW iropy8ZCRN+ekEmQ0DXNNJr+hrDNz2twrXL/mjBd7V+JyUkPrAu0gVXeoYogxW/nUc 3pVbkGoOJh0ieuvu+9ejwcfsYSqbYj6SCf3Z+234= From: Paul Gear To: ntp@ietf.org References: <5BE6683D-396F-4FAA-B8E8-9E2C277B8A35@akamai.com> <48e72bef-c8fb-2335-f469-aad1bb2f59bd@libertysys.com.au> <2DCA400C-DBE0-479E-A2F5-27D2650FF0D1@akamai.com> <26533cec-64c5-859c-b181-4b2d21758099@libertysys.com.au> Message-ID: <7d48ed90-b293-3ad2-0132-d778475aeefb@libertysys.com.au> Date: Thu, 31 Aug 2017 11:54:15 +1000 MIME-Version: 1.0 In-Reply-To: Content-Language: en-AU Archived-At: Subject: Re: [Ntp] NTS changelog since draft 9 X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============4752622085354581042==" Errors-To: ntp-bounces@ietf.org Sender: "ntp" This is a multi-part message in MIME format. --===============4752622085354581042== Content-Type: multipart/alternative; boundary="------------8408778EFBC477BE6EEFE385" Content-Language: en-AU This is a multi-part message in MIME format. --------------8408778EFBC477BE6EEFE385 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit On 31/08/17 11:39, Salz, Rich wrote: > ➢ The cookie format described in the draft clearly says that clients > aren't to depend on it, but it's absolutely vital that the server > understand it, because it contains the keys necessary to decrypt and > validate the client request. > > Well yeah, of course ☺ Your original comment on this was: > Line 614, it doesn’t seem right to say that you must not attempt to > interpret cookies and then intend to provide a recommended construction. > Delete the recommendation. The draft doesn't say that "you" must not attempt to interpret cookies. It says clients must not. And then section 7 provides a recommended way for servers to interpret them. This seems completely valid and expected. So I'm not seeing your point about why it should be deleted. Apologies if I'm being thick. > ➢ Because that's storing state on the server - the point of the cookie is > to offload the session state storage (including all necessary keys) to > the client. > > If my server chose to do that, how would anyone know? How could anyone care? That's why it should be RECOMMENDED rather than REQUIRED. > Describing one possible cookie format, in a cryptographically-strong way, is a good thing. But the RFC really shouldn’t do anything other than say “here’s something you can use†As an Appendix. I think the same principle applies here which was discussed recently in the thread about client data minimisation: each protocol standard should do its part (however small) to ensure cryptographically strong behaviour by default. If there are good reasons for overriding this behaviour, then implementations should be able to do so, but that's well within the guidelines for RECOMMENDED and in my opinion doesn't warrant deleting the recommendation or moving such a vital piece of the scalability story for NTS to an appendix. Paul --------------8408778EFBC477BE6EEFE385 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 31/08/17 11:39, Salz, Rich wrote:
➢ The cookie format described in the draft clearly says that clients
    aren't to depend on it, but it's absolutely vital that the server
    understand it, because it contains the keys necessary to decrypt and
    validate the client request.
    
Well yeah, of course ☺

Your original comment on this was:
Line 614, it doesn’t seem right to say that you must not attempt to
interpret cookies and then intend to provide a recommended construction.
Delete the recommendation.

The draft doesn't say that "you" must not attempt to interpret cookies.  It says clients must not.  And then section 7 provides a recommended way for servers to interpret them.  This seems completely valid and expected.  So I'm not seeing your point about why it should be deleted.  Apologies if I'm being thick.

➢     Because that's storing state on the server - the point of the cookie is
    to offload the session state storage (including all necessary keys) to
    the client.
    
If my server chose to do that, how would anyone know?  How could anyone care?

That's why it should be RECOMMENDED rather than REQUIRED.

Describing one possible cookie format, in a cryptographically-strong way, is a good thing.  But the RFC really shouldn’t do anything other than say “here’s something you can use† As an Appendix.

I think the same principle applies here which was discussed recently in the thread about client data minimisation: each protocol standard should do its part (however small) to ensure cryptographically strong behaviour by default.  If there are good reasons for overriding this behaviour, then implementations should be able to do so, but that's well within the guidelines for RECOMMENDED and in my opinion doesn't warrant deleting the recommendation or moving such a vital piece of the scalability story for NTS to an appendix.

Paul

--------------8408778EFBC477BE6EEFE385-- --===============4752622085354581042== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp --===============4752622085354581042==-- From nobody Wed Aug 30 18:57:59 2017 Return-Path: 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 AFB81124207 for ; Wed, 30 Aug 2017 18:57:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_PASS=-0.001] 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 S0zQDNrAubHw for ; Wed, 30 Aug 2017 18:57:57 -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 1457E12008A for ; Wed, 30 Aug 2017 18:57:57 -0700 (PDT) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v7V1vHAA028165; Thu, 31 Aug 2017 02:57:55 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=5dLMSaA8Zs/27gn06q4zGOBmNoBtInW0rG8dNi5IByE=; b=OGFv+UvrG2sX0z4I0XFpSlVloLhFVgDQD3Ip6++0O/2nL7V5QbeYnxZh/55SEW3ZV2e8 7gAknvLQcp5FL+JrFifLAw0X03acB8q2VdBf9so9613zPqilXXyEH+Qp4oc84m+uwkT6 1b9W84rl04VA5gGLco6dCdZbZJXh/Pfiht4koe80yKepBKsVzRnpPvxiWaXk4uD4OE3W sL8hZPxm9yHTfndd3FgUj6Ra/E/aUEXfefbNRMLRaYNd9GWcvgUPXS5WvAl0Fao4Pio1 4MzYZlbW3VURQtL1HqH6OzaeOrpytUhVJ1+PHpTDCyUdHz88/N7JC601jIG05HgJ7jPr QA== Received: from prod-mail-ppoint4 ([96.6.114.87]) by m0050093.ppops.net-00190b01. with ESMTP id 2ck08ktjy6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 31 Aug 2017 02:57:55 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v7V1tvbA027884; Wed, 30 Aug 2017 21:57:54 -0400 Received: from email.msg.corp.akamai.com ([172.27.25.31]) by prod-mail-ppoint4.akamai.com with ESMTP id 2ck4avs2ep-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 30 Aug 2017 21:57:54 -0400 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb5.msg.corp.akamai.com (172.27.27.105) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 30 Aug 2017 20:57:52 -0500 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.6.131]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.6.131]) with mapi id 15.00.1263.000; Wed, 30 Aug 2017 20:57:52 -0500 From: "Salz, Rich" To: Paul Gear , "ntp@ietf.org" Thread-Topic: [Ntp] NTS changelog since draft 9 Thread-Index: AQHTIbHUYQo62yJ4HkOsJT6meZUHWqKdZUcA///QsQCAAGe7AIAAOP8A///TQYCAABPcAIAARJgA//++1YAACOlkgP//vfQA Date: Thu, 31 Aug 2017 01:57:52 +0000 Message-ID: <2F9F5044-BDB3-4CC2-A535-5DADCA82F414@akamai.com> References: <5BE6683D-396F-4FAA-B8E8-9E2C277B8A35@akamai.com> <48e72bef-c8fb-2335-f469-aad1bb2f59bd@libertysys.com.au> <2DCA400C-DBE0-479E-A2F5-27D2650FF0D1@akamai.com> <26533cec-64c5-859c-b181-4b2d21758099@libertysys.com.au> <7d48ed90-b293-3ad2-0132-d778475aeefb@libertysys.com.au> In-Reply-To: <7d48ed90-b293-3ad2-0132-d778475aeefb@libertysys.com.au> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1b.0.161010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.47.35] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-30_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1708310028 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-30_10:, , 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 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1708310029 Archived-At: Subject: Re: [Ntp] NTS changelog since draft 9 X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 01:57:59 -0000 Pj4gRGVsZXRlIHRoZSByZWNvbW1lbmRhdGlvbi4NCg0K4p6iIFRoZSBkcmFmdCBkb2Vzbid0IHNh eSB0aGF0ICJ5b3UiIG11c3Qgbm90IGF0dGVtcHQgdG8gaW50ZXJwcmV0IGNvb2tpZXMuwqAgSXQg c2F5cyBjbGllbnRzIG11c3Qgbm90LsKgIEFuZCB0aGVuIHNlY3Rpb24gNyBwcm92aWRlcyBhIHJl Y29tbWVuZGVkIHdheSBmb3Igc2VydmVycyB0byBpbnRlcnByZXQgdGhlbS7CoCBUaGlzIHNlZW1z IGNvbXBsZXRlbHkgdmFsaWQgYW5kIGV4cGVjdGVkLsKgIFNvIEknbSBub3Qgc2VlaW5nIHlvdXIg cG9pbnQgYWJvdXQgd2h5IGl0IHNob3VsZCBiZSBkZWxldGVkLsKgIEFwb2xvZ2llcyBpZiBJJ20g YmVpbmcgdGhpY2suDQoNCkFoLCBJIG1lYW50IGRlbGV0ZSB0aGUgd29yZCDigJxyZWNvbW1lbmRl ZOKAnSAgRG93bmdyYWRlIGl0IHRvIOKAnG9uZSBwb3NzaWJsZeKAnSAgSXQgc2hvdWxkIGJlIG5v dCBub3JtYXRpdmUsIGFuZCBpdCBzaG91bGQgb2ZmZXIgYSBzdWdnZXN0aW9uIGZvciBhIGdvb2Qg d2F5IHRvIGRvIHRoaW5ncy4gIEkgYW0gc29ycnkgZm9yIHRoZSBtaXNsZWFkaW5nIGNvbW1lbnQu IFRoZSB0ZXh0IG9uIG9uZSB3YXkgdG8gZG8gY29va2llcyBpcyBnb29kLCBhbmQgdXNlZnVsIGZv ciB0aG9zZSB3ZSBtaWdodCBub3QgaGF2ZSBhIGdvb2Qga25vd2xlZGdlIG9mIGNyeXB0by4gIEl0 IHNob3VsZCBzdGF5LCBqdXN0IGRvd25ncmFkZWQgdG8gYW4gYXBwZW5kaXguDQoNCg== From ntp-bounces@ietf.org Wed Aug 30 18:58:00 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D5A8124207; Wed, 30 Aug 2017 18:58:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1504144680; bh=No5FxtYW9e3cNJXYym6HyFwc7dNnKqvJWvB2qwgdEM8=; h=From:To:Date:References:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe; b=qSYVr/5Svk0SKk3asB9HGdd8dHt3WX+0oQ4Y7vgrxWUT2QATuYQ+xJlh3nqc1mrZB eep6Iw4LML3B74C9j3GK0O4hniHFqz2DlkWYCjld1bYqJa2FUIOrFGFRvxHmFKY8Na YgmNAo7mGKDriCTw8U7GGbG/6BhMmspP5UNSpoWs= 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 AFB81124207 for ; Wed, 30 Aug 2017 18:57:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_PASS=-0.001] 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 S0zQDNrAubHw for ; Wed, 30 Aug 2017 18:57:57 -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 1457E12008A for ; Wed, 30 Aug 2017 18:57:57 -0700 (PDT) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v7V1vHAA028165; Thu, 31 Aug 2017 02:57:55 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=5dLMSaA8Zs/27gn06q4zGOBmNoBtInW0rG8dNi5IByE=; b=OGFv+UvrG2sX0z4I0XFpSlVloLhFVgDQD3Ip6++0O/2nL7V5QbeYnxZh/55SEW3ZV2e8 7gAknvLQcp5FL+JrFifLAw0X03acB8q2VdBf9so9613zPqilXXyEH+Qp4oc84m+uwkT6 1b9W84rl04VA5gGLco6dCdZbZJXh/Pfiht4koe80yKepBKsVzRnpPvxiWaXk4uD4OE3W sL8hZPxm9yHTfndd3FgUj6Ra/E/aUEXfefbNRMLRaYNd9GWcvgUPXS5WvAl0Fao4Pio1 4MzYZlbW3VURQtL1HqH6OzaeOrpytUhVJ1+PHpTDCyUdHz88/N7JC601jIG05HgJ7jPr QA== Received: from prod-mail-ppoint4 ([96.6.114.87]) by m0050093.ppops.net-00190b01. with ESMTP id 2ck08ktjy6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 31 Aug 2017 02:57:55 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v7V1tvbA027884; Wed, 30 Aug 2017 21:57:54 -0400 Received: from email.msg.corp.akamai.com ([172.27.25.31]) by prod-mail-ppoint4.akamai.com with ESMTP id 2ck4avs2ep-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 30 Aug 2017 21:57:54 -0400 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb5.msg.corp.akamai.com (172.27.27.105) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 30 Aug 2017 20:57:52 -0500 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.6.131]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.6.131]) with mapi id 15.00.1263.000; Wed, 30 Aug 2017 20:57:52 -0500 From: "Salz, Rich" To: Paul Gear , "ntp@ietf.org" Thread-Topic: [Ntp] NTS changelog since draft 9 Thread-Index: AQHTIbHUYQo62yJ4HkOsJT6meZUHWqKdZUcA///QsQCAAGe7AIAAOP8A///TQYCAABPcAIAARJgA//++1YAACOlkgP//vfQA Date: Thu, 31 Aug 2017 01:57:52 +0000 Message-ID: <2F9F5044-BDB3-4CC2-A535-5DADCA82F414@akamai.com> References: <5BE6683D-396F-4FAA-B8E8-9E2C277B8A35@akamai.com> <48e72bef-c8fb-2335-f469-aad1bb2f59bd@libertysys.com.au> <2DCA400C-DBE0-479E-A2F5-27D2650FF0D1@akamai.com> <26533cec-64c5-859c-b181-4b2d21758099@libertysys.com.au> <7d48ed90-b293-3ad2-0132-d778475aeefb@libertysys.com.au> In-Reply-To: <7d48ed90-b293-3ad2-0132-d778475aeefb@libertysys.com.au> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1b.0.161010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.47.35] Content-ID: MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-30_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1708310028 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-30_10:, , 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 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1708310029 Archived-At: Subject: Re: [Ntp] NTS changelog since draft 9 X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Errors-To: ntp-bounces@ietf.org Sender: "ntp" Pj4gRGVsZXRlIHRoZSByZWNvbW1lbmRhdGlvbi4NCg0K4p6iIFRoZSBkcmFmdCBkb2Vzbid0IHNh eSB0aGF0ICJ5b3UiIG11c3Qgbm90IGF0dGVtcHQgdG8gaW50ZXJwcmV0IGNvb2tpZXMuwqAgSXQg c2F5cyBjbGllbnRzIG11c3Qgbm90LsKgIEFuZCB0aGVuIHNlY3Rpb24gNyBwcm92aWRlcyBhIHJl Y29tbWVuZGVkIHdheSBmb3Igc2VydmVycyB0byBpbnRlcnByZXQgdGhlbS7CoCBUaGlzIHNlZW1z IGNvbXBsZXRlbHkgdmFsaWQgYW5kIGV4cGVjdGVkLsKgIFNvIEknbSBub3Qgc2VlaW5nIHlvdXIg cG9pbnQgYWJvdXQgd2h5IGl0IHNob3VsZCBiZSBkZWxldGVkLsKgIEFwb2xvZ2llcyBpZiBJJ20g YmVpbmcgdGhpY2suDQoNCkFoLCBJIG1lYW50IGRlbGV0ZSB0aGUgd29yZCDigJxyZWNvbW1lbmRl ZOKAnSAgRG93bmdyYWRlIGl0IHRvIOKAnG9uZSBwb3NzaWJsZeKAnSAgSXQgc2hvdWxkIGJlIG5v dCBub3JtYXRpdmUsIGFuZCBpdCBzaG91bGQgb2ZmZXIgYSBzdWdnZXN0aW9uIGZvciBhIGdvb2Qg d2F5IHRvIGRvIHRoaW5ncy4gIEkgYW0gc29ycnkgZm9yIHRoZSBtaXNsZWFkaW5nIGNvbW1lbnQu IFRoZSB0ZXh0IG9uIG9uZSB3YXkgdG8gZG8gY29va2llcyBpcyBnb29kLCBhbmQgdXNlZnVsIGZv ciB0aG9zZSB3ZSBtaWdodCBub3QgaGF2ZSBhIGdvb2Qga25vd2xlZGdlIG9mIGNyeXB0by4gIEl0 IHNob3VsZCBzdGF5LCBqdXN0IGRvd25ncmFkZWQgdG8gYW4gYXBwZW5kaXguDQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCm50cCBtYWlsaW5nIGxpc3QK bnRwQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbnRwCg== From ntp-bounces@ietf.org Wed Aug 30 19:10:42 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C60E1320BD; Wed, 30 Aug 2017 19:10:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1504145442; bh=P77calVNaninh6MQnKHDUR9pq9Cws1al8mlJXUfT+GI=; h=In-Reply-To:References:From:Date:To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc; b=IPtfK6YAnafOd3PPkH76MJXwtqQl5NyHioFRX6VFGzIywLU8Z3GqnRmqXXUZckrjc Jxr8H55GXRB8fUsatB49R+RTz7ku0FX8Gwn2QiALsRlfQPm8B+JKpC4CAu/JlAGj6s R6b7zUVV8QauwGp9O6z7vqk++wUPYWRjeimkPB+Y= 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 8FF221320BD for ; Wed, 30 Aug 2017 19:10:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 wD0Bf5HmlYir for ; Wed, 30 Aug 2017 19:10:39 -0700 (PDT) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (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 AD8AC1204DA for ; Wed, 30 Aug 2017 19:10:38 -0700 (PDT) Received: by mail-wm0-x22e.google.com with SMTP id 137so5316072wmj.1 for ; Wed, 30 Aug 2017 19:10:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MlyJilcA+cIgSlf2Q+RMntXI3p6vKK49QEDaR6+2gOI=; b=QyZMj1Dr/XJ+uF3DAUwUsDV/t9Sn+PdnBJg1PC6Y3qKA1lQBf4BzFb239gbeo/nMlX LMix1QwVznSFUOsxff3smQfgDDmW7A+xO+fpW+mFL2D99ssdYbRjYiuvhemQPXv6pQan WcYG+M2fcs7Mm9frN0AIgBYRZskPGsGd65d27oGvJ7aYysx0r5W0v7o0SyDxKWFdYtNe Vk6G89NKrrikFZSAm52G40BRI609DH3zT7yzkRxi/0NECqEupLDfGtD8iwoijz8AIyZZ L3vizixCmXokhh2SyfSJ1F4Yt4eZMAZPDihRj/FXr0CZaVoByAsk6CDrcC6Vmhz2hJnD CfWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=MlyJilcA+cIgSlf2Q+RMntXI3p6vKK49QEDaR6+2gOI=; b=ONvRB1oAwpkprkG64nJhpB5MfWoELGwU6Lw7sjHlJubdNpF5iswS2UukBQ8m+crm0x 9weGuR9Pgcx7xxwDXef2vVw+J4tpxES+S72cJo1icvze2Q0+il3p1uqelKsfHMlr9VPx mZPaebaLog7XLQBK4zEL5G2XamoUgbRkbLCe0cxjXsePj1nsg2U39O/G4rEOoM4StAei E9vAr/mpVzVqU6Hwmr5JenLUcgdnA1FSwuPrK1fyOFmdVo0H5iqHZZWBNwtz8b9NNScS yIaZ4hH5ckBu/xorbmJiSDeLGSyNN2JO6O1yHiAQ4OaXfyc8wKYAuiUQ8py0R4WWtd/B rGXg== X-Gm-Message-State: AHYfb5gFU7B2nwqE2q0qyF1fmYNd5pZXkoku8bNHq2ovym69Tp9X6OG2 O6uqky4pj/jTD77SPUmdaYIsiXA+kA4/c8E= X-Received: by 10.80.134.251 with SMTP id 56mr262775edu.19.1504145437165; Wed, 30 Aug 2017 19:10:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.157.140 with HTTP; Wed, 30 Aug 2017 19:10:36 -0700 (PDT) Received: by 10.80.157.140 with HTTP; Wed, 30 Aug 2017 19:10:36 -0700 (PDT) In-Reply-To: <2F9F5044-BDB3-4CC2-A535-5DADCA82F414@akamai.com> References: <5BE6683D-396F-4FAA-B8E8-9E2C277B8A35@akamai.com> <48e72bef-c8fb-2335-f469-aad1bb2f59bd@libertysys.com.au> <2DCA400C-DBE0-479E-A2F5-27D2650FF0D1@akamai.com> <26533cec-64c5-859c-b181-4b2d21758099@libertysys.com.au> <7d48ed90-b293-3ad2-0132-d778475aeefb@libertysys.com.au> <2F9F5044-BDB3-4CC2-A535-5DADCA82F414@akamai.com> From: Daniel Franke Date: Wed, 30 Aug 2017 22:10:36 -0400 Message-ID: To: "Salz, Rich" Archived-At: Subject: Re: [Ntp] NTS changelog since draft 9 X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: ntp@ietf.org, Paul Gear Content-Type: multipart/mixed; boundary="===============9044213862299427261==" Errors-To: ntp-bounces@ietf.org Sender: "ntp" --===============9044213862299427261== Content-Type: multipart/alternative; boundary="f403045c13a0790f9305580326ca" --f403045c13a0790f9305580326ca Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Aug 30, 2017 9:58 PM, "Salz, Rich" wrote: Ah, I meant delete the word =E2=80=9Crecommended=E2=80=9D Downgrade it to = =E2=80=9Cone possible=E2=80=9D It should be not normative, and it should offer a suggestion for a good way to do things. I am sorry for the misleading comment. The text on one way to do cookies is good, and useful for those we might not have a good knowledge of crypto. It should stay, just downgraded to an appendix. See what you think of the current git head. I've removed all RFC 2119 language concerning cookie format and made an explicit "non-normative" statement. Still keeping it where it is rather than move it to an appendix, though. --f403045c13a0790f9305580326ca Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Aug 30, 2017 9:58 PM, "Salz, Rich" <rsalz@akamai.com> wrote:

Ah, I meant delete the word =E2=80=9Crecommended=E2=80=9D=C2=A0 Downg= rade it to =E2=80=9Cone possible=E2=80=9D=C2=A0 It should be not normative,= and it should offer a suggestion for a good way to do things.=C2=A0 I am s= orry for the misleading comment. The text on one way to do cookies is good,= and useful for those we might not have a good knowledge of crypto.=C2=A0 I= t should stay, just downgraded to an appendix.

See what you think of the c= urrent git head. I've removed all RFC 2119 language concerning cookie f= ormat and made an explicit "non-normative" statement. Still keepi= ng it where it is rather than move it to an appendix, though.

--f403045c13a0790f9305580326ca-- --===============9044213862299427261== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp --===============9044213862299427261==-- From nobody Wed Aug 30 19:10:42 2017 Return-Path: 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 8FF221320BD for ; Wed, 30 Aug 2017 19:10:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 wD0Bf5HmlYir for ; Wed, 30 Aug 2017 19:10:39 -0700 (PDT) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (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 AD8AC1204DA for ; Wed, 30 Aug 2017 19:10:38 -0700 (PDT) Received: by mail-wm0-x22e.google.com with SMTP id 137so5316072wmj.1 for ; Wed, 30 Aug 2017 19:10:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MlyJilcA+cIgSlf2Q+RMntXI3p6vKK49QEDaR6+2gOI=; b=QyZMj1Dr/XJ+uF3DAUwUsDV/t9Sn+PdnBJg1PC6Y3qKA1lQBf4BzFb239gbeo/nMlX LMix1QwVznSFUOsxff3smQfgDDmW7A+xO+fpW+mFL2D99ssdYbRjYiuvhemQPXv6pQan WcYG+M2fcs7Mm9frN0AIgBYRZskPGsGd65d27oGvJ7aYysx0r5W0v7o0SyDxKWFdYtNe Vk6G89NKrrikFZSAm52G40BRI609DH3zT7yzkRxi/0NECqEupLDfGtD8iwoijz8AIyZZ L3vizixCmXokhh2SyfSJ1F4Yt4eZMAZPDihRj/FXr0CZaVoByAsk6CDrcC6Vmhz2hJnD CfWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=MlyJilcA+cIgSlf2Q+RMntXI3p6vKK49QEDaR6+2gOI=; b=ONvRB1oAwpkprkG64nJhpB5MfWoELGwU6Lw7sjHlJubdNpF5iswS2UukBQ8m+crm0x 9weGuR9Pgcx7xxwDXef2vVw+J4tpxES+S72cJo1icvze2Q0+il3p1uqelKsfHMlr9VPx mZPaebaLog7XLQBK4zEL5G2XamoUgbRkbLCe0cxjXsePj1nsg2U39O/G4rEOoM4StAei E9vAr/mpVzVqU6Hwmr5JenLUcgdnA1FSwuPrK1fyOFmdVo0H5iqHZZWBNwtz8b9NNScS yIaZ4hH5ckBu/xorbmJiSDeLGSyNN2JO6O1yHiAQ4OaXfyc8wKYAuiUQ8py0R4WWtd/B rGXg== X-Gm-Message-State: AHYfb5gFU7B2nwqE2q0qyF1fmYNd5pZXkoku8bNHq2ovym69Tp9X6OG2 O6uqky4pj/jTD77SPUmdaYIsiXA+kA4/c8E= X-Received: by 10.80.134.251 with SMTP id 56mr262775edu.19.1504145437165; Wed, 30 Aug 2017 19:10:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.157.140 with HTTP; Wed, 30 Aug 2017 19:10:36 -0700 (PDT) Received: by 10.80.157.140 with HTTP; Wed, 30 Aug 2017 19:10:36 -0700 (PDT) In-Reply-To: <2F9F5044-BDB3-4CC2-A535-5DADCA82F414@akamai.com> References: <5BE6683D-396F-4FAA-B8E8-9E2C277B8A35@akamai.com> <48e72bef-c8fb-2335-f469-aad1bb2f59bd@libertysys.com.au> <2DCA400C-DBE0-479E-A2F5-27D2650FF0D1@akamai.com> <26533cec-64c5-859c-b181-4b2d21758099@libertysys.com.au> <7d48ed90-b293-3ad2-0132-d778475aeefb@libertysys.com.au> <2F9F5044-BDB3-4CC2-A535-5DADCA82F414@akamai.com> From: Daniel Franke Date: Wed, 30 Aug 2017 22:10:36 -0400 Message-ID: To: "Salz, Rich" Cc: Paul Gear , ntp@ietf.org Content-Type: multipart/alternative; boundary="f403045c13a0790f9305580326ca" Archived-At: Subject: Re: [Ntp] NTS changelog since draft 9 X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 02:10:40 -0000 --f403045c13a0790f9305580326ca Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Aug 30, 2017 9:58 PM, "Salz, Rich" wrote: Ah, I meant delete the word =E2=80=9Crecommended=E2=80=9D Downgrade it to = =E2=80=9Cone possible=E2=80=9D It should be not normative, and it should offer a suggestion for a good way to do things. I am sorry for the misleading comment. The text on one way to do cookies is good, and useful for those we might not have a good knowledge of crypto. It should stay, just downgraded to an appendix. See what you think of the current git head. I've removed all RFC 2119 language concerning cookie format and made an explicit "non-normative" statement. Still keeping it where it is rather than move it to an appendix, though. --f403045c13a0790f9305580326ca Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Aug 30, 2017 9:58 PM, "Salz, Rich" <rsalz@akamai.com> wrote:

Ah, I meant delete the word =E2=80=9Crecommended=E2=80=9D=C2=A0 Downg= rade it to =E2=80=9Cone possible=E2=80=9D=C2=A0 It should be not normative,= and it should offer a suggestion for a good way to do things.=C2=A0 I am s= orry for the misleading comment. The text on one way to do cookies is good,= and useful for those we might not have a good knowledge of crypto.=C2=A0 I= t should stay, just downgraded to an appendix.

See what you think of the c= urrent git head. I've removed all RFC 2119 language concerning cookie f= ormat and made an explicit "non-normative" statement. Still keepi= ng it where it is rather than move it to an appendix, though.

--f403045c13a0790f9305580326ca-- From nobody Wed Aug 30 20:00:29 2017 Return-Path: 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 DCB3B1320BD for ; Wed, 30 Aug 2017 20:00:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 OzLRzsm6mgYK for ; Wed, 30 Aug 2017 20:00:27 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [67.231.157.127]) (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 E0FF5126BFD for ; Wed, 30 Aug 2017 20:00:26 -0700 (PDT) Received: from pps.filterd (m0122331.ppops.net [127.0.0.1]) by m0122331.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v7V2vvjN017754; Thu, 31 Aug 2017 04:00:23 +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 : mime-version; s=jan2016.eng; bh=0o3tDJxziEUaa9ER0fMZMzpuUbVDrF0V91LaZxO/GC4=; b=XE3D+8Do+0VSWq9pj/gFc/HUWyd9I5cMw3q18Mk7ijCK1PnJU3WRgtp91pqs/n/4YDN0 iE6MoAksjYeX1BMKqKLEK0vTurIFU5YJ/gHqZx96WUlfJYt2KMD5qd7enRZFXRnj8Ag+ 5fubechETwM078mwrfkp6VdnnTumtnC5nush5kAGjuZ0dmpXPzjdfJ8nq95b5KySvWZ+ HYhjILJjcAQgjP7O1OKrrYB41EBW41XkKwhdtDBmyPkLFsHcS+kPaAcMHVYkig+7uug1 uHyV+JSpeTo3uOn7oS4OloPYOuBaK6YFRhZZUeD7F6Kx72p64OOa0oYABF1C6ABgTiA5 pQ== Received: from prod-mail-ppoint4 ([96.6.114.87]) by mx0b-00190b01.pphosted.com with ESMTP id 2cjwuqsk30-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 31 Aug 2017 04:00:23 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v7V2u9SD010176; Wed, 30 Aug 2017 23:00:22 -0400 Received: from email.msg.corp.akamai.com ([172.27.25.33]) by prod-mail-ppoint4.akamai.com with ESMTP id 2ck4avsbss-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 30 Aug 2017 23:00:21 -0400 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb1.msg.corp.akamai.com (172.27.27.101) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 30 Aug 2017 22:00:17 -0500 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.6.131]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.6.131]) with mapi id 15.00.1263.000; Wed, 30 Aug 2017 22:00:17 -0500 From: "Salz, Rich" To: Daniel Franke CC: Paul Gear , "ntp@ietf.org" Thread-Topic: [Ntp] NTS changelog since draft 9 Thread-Index: AQHTIbHUYQo62yJ4HkOsJT6meZUHWqKdZUcA///QsQCAAGe7AIAAOP8A///TQYCAABPcAIAARJgA//++1YAACOlkgP//vfQAgABGnQD//8rTgA== Date: Thu, 31 Aug 2017 03:00:17 +0000 Message-ID: <7784CF56-8AB5-4FE0-A36D-701B68D5981B@akamai.com> References: <5BE6683D-396F-4FAA-B8E8-9E2C277B8A35@akamai.com> <48e72bef-c8fb-2335-f469-aad1bb2f59bd@libertysys.com.au> <2DCA400C-DBE0-479E-A2F5-27D2650FF0D1@akamai.com> <26533cec-64c5-859c-b181-4b2d21758099@libertysys.com.au> <7d48ed90-b293-3ad2-0132-d778475aeefb@libertysys.com.au> <2F9F5044-BDB3-4CC2-A535-5DADCA82F414@akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1b.0.161010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.40.59] Content-Type: multipart/alternative; boundary="_000_7784CF568AB54FE0A36D701B68D5981Bakamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-30_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1708310042 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-30_10:, , 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 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1708310042 Archived-At: Subject: Re: [Ntp] NTS changelog since draft 9 X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 03:00:29 -0000 --_000_7784CF568AB54FE0A36D701B68D5981Bakamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TG9va3MgZ29vZCwgdGhhbmtzIQ0KDQpGcm9tOiBEYW5pZWwgRnJhbmtlIDxkZm94ZnJhbmtlQGdt YWlsLmNvbT4NCkRhdGU6IFdlZG5lc2RheSwgQXVndXN0IDMwLCAyMDE3IGF0IDEwOjEwIFBNDQpU bzogUmljaCBTYWx6IDxyc2FsekBha2FtYWkuY29tPg0KQ2M6IFBhdWwgR2VhciA8bnRwQGxpYmVy dHlzeXMuY29tLmF1PiwgIm50cEBpZXRmLm9yZyIgPG50cEBpZXRmLm9yZz4NClN1YmplY3Q6IFJl OiBbTnRwXSBOVFMgY2hhbmdlbG9nIHNpbmNlIGRyYWZ0IDkNCg0KT24gQXVnIDMwLCAyMDE3IDk6 NTggUE0sICJTYWx6LCBSaWNoIiA8cnNhbHpAYWthbWFpLmNvbTxtYWlsdG86cnNhbHpAYWthbWFp LmNvbT4+IHdyb3RlOg0KDQpBaCwgSSBtZWFudCBkZWxldGUgdGhlIHdvcmQg4oCccmVjb21tZW5k ZWTigJ0gIERvd25ncmFkZSBpdCB0byDigJxvbmUgcG9zc2libGXigJ0gIEl0IHNob3VsZCBiZSBu b3Qgbm9ybWF0aXZlLCBhbmQgaXQgc2hvdWxkIG9mZmVyIGEgc3VnZ2VzdGlvbiBmb3IgYSBnb29k IHdheSB0byBkbyB0aGluZ3MuICBJIGFtIHNvcnJ5IGZvciB0aGUgbWlzbGVhZGluZyBjb21tZW50 LiBUaGUgdGV4dCBvbiBvbmUgd2F5IHRvIGRvIGNvb2tpZXMgaXMgZ29vZCwgYW5kIHVzZWZ1bCBm b3IgdGhvc2Ugd2UgbWlnaHQgbm90IGhhdmUgYSBnb29kIGtub3dsZWRnZSBvZiBjcnlwdG8uICBJ dCBzaG91bGQgc3RheSwganVzdCBkb3duZ3JhZGVkIHRvIGFuIGFwcGVuZGl4Lg0KDQpTZWUgd2hh dCB5b3UgdGhpbmsgb2YgdGhlIGN1cnJlbnQgZ2l0IGhlYWQuIEkndmUgcmVtb3ZlZCBhbGwgUkZD IDIxMTkgbGFuZ3VhZ2UgY29uY2VybmluZyBjb29raWUgZm9ybWF0IGFuZCBtYWRlIGFuIGV4cGxp Y2l0ICJub24tbm9ybWF0aXZlIiBzdGF0ZW1lbnQuIFN0aWxsIGtlZXBpbmcgaXQgd2hlcmUgaXQg aXMgcmF0aGVyIHRoYW4gbW92ZSBpdCB0byBhbiBhcHBlbmRpeCwgdGhvdWdoLg0KDQo= --_000_7784CF568AB54FE0A36D701B68D5981Bakamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseTpDYWxpYnJpOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5tc29JbnMNCgl7 bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLXN0eWxlLW5hbWU6IiI7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTsNCgljb2xvcjp0ZWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29y ZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBp biAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwv c3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9 ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OkNhbGlicmkiPkxvb2tzIGdvb2QsIHRoYW5rcyE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4g MGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6Q2FsaWJyaTtjb2xvcjpibGFjayI+RnJvbTogPC9zcGFuPg0KPC9iPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTpDYWxpYnJpO2NvbG9yOmJsYWNrIj5EYW5pZWwgRnJhbmtlICZsdDtkZm94ZnJh bmtlQGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+V2VkbmVzZGF5LCBBdWd1c3QgMzAs IDIwMTcgYXQgMTA6MTAgUE08YnI+DQo8Yj5UbzogPC9iPlJpY2ggU2FseiAmbHQ7cnNhbHpAYWth bWFpLmNvbSZndDs8YnI+DQo8Yj5DYzogPC9iPlBhdWwgR2VhciAmbHQ7bnRwQGxpYmVydHlzeXMu Y29tLmF1Jmd0OywgJnF1b3Q7bnRwQGlldGYub3JnJnF1b3Q7ICZsdDtudHBAaWV0Zi5vcmcmZ3Q7 PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbTnRwXSBOVFMgY2hhbmdlbG9nIHNpbmNlIGRyYWZ0 IDk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEF1ZyAzMCwgMjAxNyA5OjU4IFBNLCAmcXVv dDtTYWx6LCBSaWNoJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86cnNhbHpAYWthbWFpLmNvbSI+ cnNhbHpAYWthbWFpLmNvbTwvYT4mZ3Q7IHdyb3RlOg0KPG86cD48L286cD48L3A+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDow aW4iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BaCwgSSBtZWFudCBkZWxldGUgdGhlIHdvcmQg 4oCccmVjb21tZW5kZWTigJ0mbmJzcDsgRG93bmdyYWRlIGl0IHRvIOKAnG9uZSBwb3NzaWJsZeKA nSZuYnNwOyBJdCBzaG91bGQgYmUgbm90IG5vcm1hdGl2ZSwgYW5kIGl0IHNob3VsZCBvZmZlciBh IHN1Z2dlc3Rpb24gZm9yIGEgZ29vZCB3YXkgdG8gZG8gdGhpbmdzLiZuYnNwOyBJIGFtIHNvcnJ5 IGZvciB0aGUgbWlzbGVhZGluZyBjb21tZW50LiBUaGUgdGV4dCBvbiBvbmUgd2F5IHRvIGRvIGNv b2tpZXMNCiBpcyBnb29kLCBhbmQgdXNlZnVsIGZvciB0aG9zZSB3ZSBtaWdodCBub3QgaGF2ZSBh IGdvb2Qga25vd2xlZGdlIG9mIGNyeXB0by4mbmJzcDsgSXQgc2hvdWxkIHN0YXksIGp1c3QgZG93 bmdyYWRlZCB0byBhbiBhcHBlbmRpeC48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNlZSB3 aGF0IHlvdSB0aGluayBvZiB0aGUgY3VycmVudCBnaXQgaGVhZC4gSSd2ZSByZW1vdmVkIGFsbCBS RkMgMjExOSBsYW5ndWFnZSBjb25jZXJuaW5nIGNvb2tpZSBmb3JtYXQgYW5kIG1hZGUgYW4gZXhw bGljaXQgJnF1b3Q7bm9uLW5vcm1hdGl2ZSZxdW90OyBzdGF0ZW1lbnQuIFN0aWxsIGtlZXBpbmcg aXQgd2hlcmUgaXQgaXMgcmF0aGVyIHRoYW4gbW92ZSBpdCB0byBhbiBhcHBlbmRpeCwgdGhvdWdo LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_7784CF568AB54FE0A36D701B68D5981Bakamaicom_-- From ntp-bounces@ietf.org Wed Aug 30 20:00:30 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 62FA61320BD; Wed, 30 Aug 2017 20:00:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1504148430; bh=NjQFLYONZ1FeqDsDLLXW3xwuMvQ9YvgffAGo2Aew/eI=; h=From:To:Date:References:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc; b=JYyeghz+dSgm9qPWL14kxgseMgTc7QFjDS4L1QmDoCl3p2KiwcMBvgMowBggawRy7 MeA19/a3c5MNxAF3uPQzmucQ1udU2zinpHgpmetAN3wDGw2xRk3C9eC167LQLCwJjJ +SIjpYNEZgYnH+u9tZENvERPduOfNt+lOoosHAck= 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 DCB3B1320BD for ; Wed, 30 Aug 2017 20:00:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 OzLRzsm6mgYK for ; Wed, 30 Aug 2017 20:00:27 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [67.231.157.127]) (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 E0FF5126BFD for ; Wed, 30 Aug 2017 20:00:26 -0700 (PDT) Received: from pps.filterd (m0122331.ppops.net [127.0.0.1]) by m0122331.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v7V2vvjN017754; Thu, 31 Aug 2017 04:00:23 +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 : mime-version; s=jan2016.eng; bh=0o3tDJxziEUaa9ER0fMZMzpuUbVDrF0V91LaZxO/GC4=; b=XE3D+8Do+0VSWq9pj/gFc/HUWyd9I5cMw3q18Mk7ijCK1PnJU3WRgtp91pqs/n/4YDN0 iE6MoAksjYeX1BMKqKLEK0vTurIFU5YJ/gHqZx96WUlfJYt2KMD5qd7enRZFXRnj8Ag+ 5fubechETwM078mwrfkp6VdnnTumtnC5nush5kAGjuZ0dmpXPzjdfJ8nq95b5KySvWZ+ HYhjILJjcAQgjP7O1OKrrYB41EBW41XkKwhdtDBmyPkLFsHcS+kPaAcMHVYkig+7uug1 uHyV+JSpeTo3uOn7oS4OloPYOuBaK6YFRhZZUeD7F6Kx72p64OOa0oYABF1C6ABgTiA5 pQ== Received: from prod-mail-ppoint4 ([96.6.114.87]) by mx0b-00190b01.pphosted.com with ESMTP id 2cjwuqsk30-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 31 Aug 2017 04:00:23 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v7V2u9SD010176; Wed, 30 Aug 2017 23:00:22 -0400 Received: from email.msg.corp.akamai.com ([172.27.25.33]) by prod-mail-ppoint4.akamai.com with ESMTP id 2ck4avsbss-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 30 Aug 2017 23:00:21 -0400 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb1.msg.corp.akamai.com (172.27.27.101) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 30 Aug 2017 22:00:17 -0500 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.6.131]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.6.131]) with mapi id 15.00.1263.000; Wed, 30 Aug 2017 22:00:17 -0500 From: "Salz, Rich" To: Daniel Franke Thread-Topic: [Ntp] NTS changelog since draft 9 Thread-Index: AQHTIbHUYQo62yJ4HkOsJT6meZUHWqKdZUcA///QsQCAAGe7AIAAOP8A///TQYCAABPcAIAARJgA//++1YAACOlkgP//vfQAgABGnQD//8rTgA== Date: Thu, 31 Aug 2017 03:00:17 +0000 Message-ID: <7784CF56-8AB5-4FE0-A36D-701B68D5981B@akamai.com> References: <5BE6683D-396F-4FAA-B8E8-9E2C277B8A35@akamai.com> <48e72bef-c8fb-2335-f469-aad1bb2f59bd@libertysys.com.au> <2DCA400C-DBE0-479E-A2F5-27D2650FF0D1@akamai.com> <26533cec-64c5-859c-b181-4b2d21758099@libertysys.com.au> <7d48ed90-b293-3ad2-0132-d778475aeefb@libertysys.com.au> <2F9F5044-BDB3-4CC2-A535-5DADCA82F414@akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1b.0.161010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.40.59] MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-30_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1708310042 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-30_10:, , 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 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1708310042 Archived-At: Subject: Re: [Ntp] NTS changelog since draft 9 X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "ntp@ietf.org" , Paul Gear Content-Type: multipart/mixed; boundary="===============0892764429381427033==" Errors-To: ntp-bounces@ietf.org Sender: "ntp" --===============0892764429381427033== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_7784CF568AB54FE0A36D701B68D5981Bakamaicom_" --_000_7784CF568AB54FE0A36D701B68D5981Bakamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TG9va3MgZ29vZCwgdGhhbmtzIQ0KDQpGcm9tOiBEYW5pZWwgRnJhbmtlIDxkZm94ZnJhbmtlQGdt YWlsLmNvbT4NCkRhdGU6IFdlZG5lc2RheSwgQXVndXN0IDMwLCAyMDE3IGF0IDEwOjEwIFBNDQpU bzogUmljaCBTYWx6IDxyc2FsekBha2FtYWkuY29tPg0KQ2M6IFBhdWwgR2VhciA8bnRwQGxpYmVy dHlzeXMuY29tLmF1PiwgIm50cEBpZXRmLm9yZyIgPG50cEBpZXRmLm9yZz4NClN1YmplY3Q6IFJl OiBbTnRwXSBOVFMgY2hhbmdlbG9nIHNpbmNlIGRyYWZ0IDkNCg0KT24gQXVnIDMwLCAyMDE3IDk6 NTggUE0sICJTYWx6LCBSaWNoIiA8cnNhbHpAYWthbWFpLmNvbTxtYWlsdG86cnNhbHpAYWthbWFp LmNvbT4+IHdyb3RlOg0KDQpBaCwgSSBtZWFudCBkZWxldGUgdGhlIHdvcmQg4oCccmVjb21tZW5k ZWTigJ0gIERvd25ncmFkZSBpdCB0byDigJxvbmUgcG9zc2libGXigJ0gIEl0IHNob3VsZCBiZSBu b3Qgbm9ybWF0aXZlLCBhbmQgaXQgc2hvdWxkIG9mZmVyIGEgc3VnZ2VzdGlvbiBmb3IgYSBnb29k IHdheSB0byBkbyB0aGluZ3MuICBJIGFtIHNvcnJ5IGZvciB0aGUgbWlzbGVhZGluZyBjb21tZW50 LiBUaGUgdGV4dCBvbiBvbmUgd2F5IHRvIGRvIGNvb2tpZXMgaXMgZ29vZCwgYW5kIHVzZWZ1bCBm b3IgdGhvc2Ugd2UgbWlnaHQgbm90IGhhdmUgYSBnb29kIGtub3dsZWRnZSBvZiBjcnlwdG8uICBJ dCBzaG91bGQgc3RheSwganVzdCBkb3duZ3JhZGVkIHRvIGFuIGFwcGVuZGl4Lg0KDQpTZWUgd2hh dCB5b3UgdGhpbmsgb2YgdGhlIGN1cnJlbnQgZ2l0IGhlYWQuIEkndmUgcmVtb3ZlZCBhbGwgUkZD IDIxMTkgbGFuZ3VhZ2UgY29uY2VybmluZyBjb29raWUgZm9ybWF0IGFuZCBtYWRlIGFuIGV4cGxp Y2l0ICJub24tbm9ybWF0aXZlIiBzdGF0ZW1lbnQuIFN0aWxsIGtlZXBpbmcgaXQgd2hlcmUgaXQg aXMgcmF0aGVyIHRoYW4gbW92ZSBpdCB0byBhbiBhcHBlbmRpeCwgdGhvdWdoLg0KDQo= --_000_7784CF568AB54FE0A36D701B68D5981Bakamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseTpDYWxpYnJpOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5tc29JbnMNCgl7 bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLXN0eWxlLW5hbWU6IiI7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTsNCgljb2xvcjp0ZWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29y ZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBp biAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwv c3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9 ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OkNhbGlicmkiPkxvb2tzIGdvb2QsIHRoYW5rcyE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4g MGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6Q2FsaWJyaTtjb2xvcjpibGFjayI+RnJvbTogPC9zcGFuPg0KPC9iPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTpDYWxpYnJpO2NvbG9yOmJsYWNrIj5EYW5pZWwgRnJhbmtlICZsdDtkZm94ZnJh bmtlQGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+V2VkbmVzZGF5LCBBdWd1c3QgMzAs IDIwMTcgYXQgMTA6MTAgUE08YnI+DQo8Yj5UbzogPC9iPlJpY2ggU2FseiAmbHQ7cnNhbHpAYWth bWFpLmNvbSZndDs8YnI+DQo8Yj5DYzogPC9iPlBhdWwgR2VhciAmbHQ7bnRwQGxpYmVydHlzeXMu Y29tLmF1Jmd0OywgJnF1b3Q7bnRwQGlldGYub3JnJnF1b3Q7ICZsdDtudHBAaWV0Zi5vcmcmZ3Q7 PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbTnRwXSBOVFMgY2hhbmdlbG9nIHNpbmNlIGRyYWZ0 IDk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEF1ZyAzMCwgMjAxNyA5OjU4IFBNLCAmcXVv dDtTYWx6LCBSaWNoJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86cnNhbHpAYWthbWFpLmNvbSI+ cnNhbHpAYWthbWFpLmNvbTwvYT4mZ3Q7IHdyb3RlOg0KPG86cD48L286cD48L3A+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDow aW4iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BaCwgSSBtZWFudCBkZWxldGUgdGhlIHdvcmQg 4oCccmVjb21tZW5kZWTigJ0mbmJzcDsgRG93bmdyYWRlIGl0IHRvIOKAnG9uZSBwb3NzaWJsZeKA nSZuYnNwOyBJdCBzaG91bGQgYmUgbm90IG5vcm1hdGl2ZSwgYW5kIGl0IHNob3VsZCBvZmZlciBh IHN1Z2dlc3Rpb24gZm9yIGEgZ29vZCB3YXkgdG8gZG8gdGhpbmdzLiZuYnNwOyBJIGFtIHNvcnJ5 IGZvciB0aGUgbWlzbGVhZGluZyBjb21tZW50LiBUaGUgdGV4dCBvbiBvbmUgd2F5IHRvIGRvIGNv b2tpZXMNCiBpcyBnb29kLCBhbmQgdXNlZnVsIGZvciB0aG9zZSB3ZSBtaWdodCBub3QgaGF2ZSBh IGdvb2Qga25vd2xlZGdlIG9mIGNyeXB0by4mbmJzcDsgSXQgc2hvdWxkIHN0YXksIGp1c3QgZG93 bmdyYWRlZCB0byBhbiBhcHBlbmRpeC48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNlZSB3 aGF0IHlvdSB0aGluayBvZiB0aGUgY3VycmVudCBnaXQgaGVhZC4gSSd2ZSByZW1vdmVkIGFsbCBS RkMgMjExOSBsYW5ndWFnZSBjb25jZXJuaW5nIGNvb2tpZSBmb3JtYXQgYW5kIG1hZGUgYW4gZXhw bGljaXQgJnF1b3Q7bm9uLW5vcm1hdGl2ZSZxdW90OyBzdGF0ZW1lbnQuIFN0aWxsIGtlZXBpbmcg aXQgd2hlcmUgaXQgaXMgcmF0aGVyIHRoYW4gbW92ZSBpdCB0byBhbiBhcHBlbmRpeCwgdGhvdWdo LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_7784CF568AB54FE0A36D701B68D5981Bakamaicom_-- --===============0892764429381427033== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp --===============0892764429381427033==-- From ntp-bounces@ietf.org Wed Aug 30 22:40:22 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B6FA31329AA; Wed, 30 Aug 2017 22:40:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1504158022; bh=vesOj6vgKSMU1xKBUHU/rw9J03YV56usOGkeebIRPFI=; h=From:To:Date:References:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc; b=JsFFOSrsXRAr79JcsuLM0w/FoldqtDnAbCcuhAAmr1aPywKRo8/zBhH3uCQIGCrQ4 3HIfYNS7dj2lM3aT1s70zAp7c0CQzvOFbEfgNX7o5dLW5qj05pJ0SxVSQmhwImjYpA k8Y8jGpsYLPL/mEnaOJ81lQhgOmZxIh1GRsv+gKY= 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 3956F1323B6; Wed, 30 Aug 2017 22:40:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 E02KUnJ_Xh1w; Wed, 30 Aug 2017 22:40:18 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90A661323B9; Wed, 30 Aug 2017 22:40:17 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml706-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DNQ49000; Thu, 31 Aug 2017 05:40:15 +0000 (GMT) Received: from DGGEML401-HUB.china.huawei.com (10.3.17.32) by lhreml706-cah.china.huawei.com (10.201.108.47) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 31 Aug 2017 06:40:14 +0100 Received: from DGGEML507-MBX.china.huawei.com ([169.254.2.7]) by DGGEML401-HUB.china.huawei.com ([fe80::89ed:853e:30a9:2a79%31]) with mapi id 14.03.0301.000; Thu, 31 Aug 2017 13:40:02 +0800 From: Jiangyuanlong To: "Karen O'Donoghue" , "ntp@ietf.org" Thread-Topic: WGLC for draft-ietf-ntp-using-nts-for-ntp Thread-Index: AQHTEMnCM2s3Nc34m0O8jzUH1rPjTqKd5GhQ Date: Thu, 31 Aug 2017 05:40:01 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68BBB59A424@dggeml507-mbx.china.huawei.com> References: <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> In-Reply-To: <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.74.202.215] MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090201.59A7A140.0008, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.2.7, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 666b641cd5f3b740c4f82b08a209ee43 Archived-At: Subject: Re: [Ntp] WGLC for draft-ietf-ntp-using-nts-for-ntp X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "tictoc@ietf.org" Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Errors-To: ntp-bounces@ietf.org Sender: "ntp" SGksIGFmdGVyIGdvaW5nIHRocm91Z2ggdGhpcyBkcmFmdCwgSSBhbSBub3Qgc3VyZSB3aGV0aGVy IGlldGYtbnRwLWRhdGEtbWluaW1pemF0aW9uLTAwIHNob3VsZCBiZSBsaXN0ZWQgaW4gdGhlIE5v cm1hdGl2ZSBSZWZlcmVuY2UsIG9yIG5vdCBhdCBhbGwuDQpVc3VhbGx5LCBhbiB1bnB1Ymxpc2hl ZCBub3JtYXRpdmUgcmVmZXJlbmNlIHdpbGwgZHJhbWF0aWNhbGx5IHNsb3cgdGhlIHByb2Nlc3Mg b2YgdHVybmluZyBhIGRyYWZ0IGludG8gYSBSRkMgKHRoZXkgbmVlZCB0byBiZSBwdWJsaXNoZWQg YXMgYSBjbHVzdGVyIGF0IHRoZSBzYW1lIHRpbWUpLg0KSXQgc2VlbXMgYWxzbyBpZXRmLW50cC1k YXRhLW1pbmltaXphdGlvbiBzb2x2ZXMgdGhlIHByb2JsZW0gb2YgdW5saW5rYWJpbGl0eSwgbm90 IG5lY2Vzc2FyaWx5IGEgcGFydCBvZiBOVFMsIGJ1dCBhIGNvbXBsZW1lbnQgKGp1c3QgYXMgdGhl IHJlbGF0aW9uc2hpcCBvZiBTZWN0aW9uIDkgIlNlY3VyaXR5IENvbnNpZGVyYXRpb25zIiBhbmQg U2VjdGlvbiAxMCAiUHJpdmFjeSBDb25zaWRlcmF0aW9ucyIgKS4gDQoNCk1pbm9yIGVkaXRvcmlh bCBjb21tZW50czoNCjEuIElFVEYgcmVxdWlyZW1lbnQgbGFuZ3VhZ2VzIGNhbiBiZSB1c2VkIGlu IFNlY3Rpb24gNCBtb3JlIGZyZXF1ZW50bHkuDQoyLiAiYm90aCBwYXJ0aWVzIHNob3VsZCBhdHRl bXB0IHRvIGluaXRpYXRlIGEgRFRMUyBzZXNzaW9uIHdpdGggdGhlaXIgcGVlciIgY2FuIGJlIHJl cGhyYXNlZCBpbnRvICJlYWNoIHBhcnR5IFNIT1VMRCBhdHRlbXB0IHRvIGluaXRpYXRlIGEgRFRM UyBzZXNzaW9uIHdpdGggaXRzIHBlZXIiIGluIFBhZ2UgNy4NCjMuICIgYW4gV2FybmluZyByZWNv cmQgIiB0byAiYSBXYXJuaW5nIHJlY29yZCIgaW4gU2VjdGlvbiA1LjEuNC4NCg0KS2luZCByZWdh cmRzLA0KWXVhbmxvbmcNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFRJQ1RP QyBbbWFpbHRvOnRpY3RvYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgS2FyZW4gTydE b25vZ2h1ZQ0KU2VudDogV2VkbmVzZGF5LCBBdWd1c3QgMDksIDIwMTcgMTI6NDEgUE0NClRvOiBu dHBAaWV0Zi5vcmcNCkNjOiB0aWN0b2NAaWV0Zi5vcmcNClN1YmplY3Q6IFtUSUNUT0NdIFdHTEMg Zm9yIGRyYWZ0LWlldGYtbnRwLXVzaW5nLW50cy1mb3ItbnRwDQoNCkZvbGtzLA0KDQpUaGlzIGJl Z2lucyBhIHRocmVlIHdlZWsgd29ya2luZyBncm91cCBsYXN0IGNhbGwgKFdHTEMpIGZvciAiTmV0 d29yayBUaW1lIFNlY3VyaXR5IGZvciB0aGUgTmV0d29yayBUaW1lIFByb3RvY29s4oCdLg0KDQpo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW50cC11c2luZy1udHMt Zm9yLW50cC8NCg0KUGxlYXNlIHJldmlldyBhbmQgcHJvdmlkZSBjb21tZW50cyB0byB0aGUgbWFp bGluZyBsaXN0IGJ5IG5vIGxhdGVyIHRoYW4gMzEgQXVndXN0IDIwMTcuIEVhcmxpZXIgY29tbWVu dHMgYW5kIGRpc2N1c3Npb24gd291bGQgYmUgYXBwcmVjaWF0ZWQuIFBsZWFzZSBub3RlIHRoYXQg dGhlIGNoYWlycyB3aWxsIGJlIHVzaW5nIHRoaXMgV0dMQyB0byBkZXRlcm1pbmUgY29uc2Vuc3Vz IHRvIG1vdmUgdGhpcyBkb2N1bWVudCBmb3J3YXJkIHRvIHRoZSBJRVNHLiANCg0KQWxzbywgYXMg YSByZW1pbmRlciwgd2UgaGF2ZSBtaWdyYXRlZCB0aGUgd29ya2luZyBncm91cCBtYWlsaW5nIGxp c3QgdG8gSUVURiBpbmZyYXN0cnVjdHVyZS4gUGxlYXNlIHJlc3BvbmQgdG8gbnRwQGlldGYub3Jn LiBdDQoNClJlZ2FyZHMsDQpLYXJlbiBhbmQgRGlldGVyDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KVElDVE9DIG1haWxpbmcgbGlzdA0KVElDVE9DQGll dGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RpY3RvYw0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbnRwIG1haWxpbmcg bGlzdApudHBAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9u dHAK From nobody Wed Aug 30 22:40:29 2017 Return-Path: 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 3956F1323B6; Wed, 30 Aug 2017 22:40:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 E02KUnJ_Xh1w; Wed, 30 Aug 2017 22:40:18 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90A661323B9; Wed, 30 Aug 2017 22:40:17 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml706-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DNQ49000; Thu, 31 Aug 2017 05:40:15 +0000 (GMT) Received: from DGGEML401-HUB.china.huawei.com (10.3.17.32) by lhreml706-cah.china.huawei.com (10.201.108.47) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 31 Aug 2017 06:40:14 +0100 Received: from DGGEML507-MBX.china.huawei.com ([169.254.2.7]) by DGGEML401-HUB.china.huawei.com ([fe80::89ed:853e:30a9:2a79%31]) with mapi id 14.03.0301.000; Thu, 31 Aug 2017 13:40:02 +0800 From: Jiangyuanlong To: "Karen O'Donoghue" , "ntp@ietf.org" CC: "tictoc@ietf.org" Thread-Topic: WGLC for draft-ietf-ntp-using-nts-for-ntp Thread-Index: AQHTEMnCM2s3Nc34m0O8jzUH1rPjTqKd5GhQ Date: Thu, 31 Aug 2017 05:40:01 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68BBB59A424@dggeml507-mbx.china.huawei.com> References: <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> In-Reply-To: <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.74.202.215] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090201.59A7A140.0008, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.2.7, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 666b641cd5f3b740c4f82b08a209ee43 Archived-At: Subject: Re: [Ntp] WGLC for draft-ietf-ntp-using-nts-for-ntp X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 05:40:20 -0000 SGksIGFmdGVyIGdvaW5nIHRocm91Z2ggdGhpcyBkcmFmdCwgSSBhbSBub3Qgc3VyZSB3aGV0aGVy IGlldGYtbnRwLWRhdGEtbWluaW1pemF0aW9uLTAwIHNob3VsZCBiZSBsaXN0ZWQgaW4gdGhlIE5v cm1hdGl2ZSBSZWZlcmVuY2UsIG9yIG5vdCBhdCBhbGwuDQpVc3VhbGx5LCBhbiB1bnB1Ymxpc2hl ZCBub3JtYXRpdmUgcmVmZXJlbmNlIHdpbGwgZHJhbWF0aWNhbGx5IHNsb3cgdGhlIHByb2Nlc3Mg b2YgdHVybmluZyBhIGRyYWZ0IGludG8gYSBSRkMgKHRoZXkgbmVlZCB0byBiZSBwdWJsaXNoZWQg YXMgYSBjbHVzdGVyIGF0IHRoZSBzYW1lIHRpbWUpLg0KSXQgc2VlbXMgYWxzbyBpZXRmLW50cC1k YXRhLW1pbmltaXphdGlvbiBzb2x2ZXMgdGhlIHByb2JsZW0gb2YgdW5saW5rYWJpbGl0eSwgbm90 IG5lY2Vzc2FyaWx5IGEgcGFydCBvZiBOVFMsIGJ1dCBhIGNvbXBsZW1lbnQgKGp1c3QgYXMgdGhl IHJlbGF0aW9uc2hpcCBvZiBTZWN0aW9uIDkgIlNlY3VyaXR5IENvbnNpZGVyYXRpb25zIiBhbmQg U2VjdGlvbiAxMCAiUHJpdmFjeSBDb25zaWRlcmF0aW9ucyIgKS4gDQoNCk1pbm9yIGVkaXRvcmlh bCBjb21tZW50czoNCjEuIElFVEYgcmVxdWlyZW1lbnQgbGFuZ3VhZ2VzIGNhbiBiZSB1c2VkIGlu IFNlY3Rpb24gNCBtb3JlIGZyZXF1ZW50bHkuDQoyLiAiYm90aCBwYXJ0aWVzIHNob3VsZCBhdHRl bXB0IHRvIGluaXRpYXRlIGEgRFRMUyBzZXNzaW9uIHdpdGggdGhlaXIgcGVlciIgY2FuIGJlIHJl cGhyYXNlZCBpbnRvICJlYWNoIHBhcnR5IFNIT1VMRCBhdHRlbXB0IHRvIGluaXRpYXRlIGEgRFRM UyBzZXNzaW9uIHdpdGggaXRzIHBlZXIiIGluIFBhZ2UgNy4NCjMuICIgYW4gV2FybmluZyByZWNv cmQgIiB0byAiYSBXYXJuaW5nIHJlY29yZCIgaW4gU2VjdGlvbiA1LjEuNC4NCg0KS2luZCByZWdh cmRzLA0KWXVhbmxvbmcNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFRJQ1RP QyBbbWFpbHRvOnRpY3RvYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgS2FyZW4gTydE b25vZ2h1ZQ0KU2VudDogV2VkbmVzZGF5LCBBdWd1c3QgMDksIDIwMTcgMTI6NDEgUE0NClRvOiBu dHBAaWV0Zi5vcmcNCkNjOiB0aWN0b2NAaWV0Zi5vcmcNClN1YmplY3Q6IFtUSUNUT0NdIFdHTEMg Zm9yIGRyYWZ0LWlldGYtbnRwLXVzaW5nLW50cy1mb3ItbnRwDQoNCkZvbGtzLA0KDQpUaGlzIGJl Z2lucyBhIHRocmVlIHdlZWsgd29ya2luZyBncm91cCBsYXN0IGNhbGwgKFdHTEMpIGZvciAiTmV0 d29yayBUaW1lIFNlY3VyaXR5IGZvciB0aGUgTmV0d29yayBUaW1lIFByb3RvY29s4oCdLg0KDQpo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW50cC11c2luZy1udHMt Zm9yLW50cC8NCg0KUGxlYXNlIHJldmlldyBhbmQgcHJvdmlkZSBjb21tZW50cyB0byB0aGUgbWFp bGluZyBsaXN0IGJ5IG5vIGxhdGVyIHRoYW4gMzEgQXVndXN0IDIwMTcuIEVhcmxpZXIgY29tbWVu dHMgYW5kIGRpc2N1c3Npb24gd291bGQgYmUgYXBwcmVjaWF0ZWQuIFBsZWFzZSBub3RlIHRoYXQg dGhlIGNoYWlycyB3aWxsIGJlIHVzaW5nIHRoaXMgV0dMQyB0byBkZXRlcm1pbmUgY29uc2Vuc3Vz IHRvIG1vdmUgdGhpcyBkb2N1bWVudCBmb3J3YXJkIHRvIHRoZSBJRVNHLiANCg0KQWxzbywgYXMg YSByZW1pbmRlciwgd2UgaGF2ZSBtaWdyYXRlZCB0aGUgd29ya2luZyBncm91cCBtYWlsaW5nIGxp c3QgdG8gSUVURiBpbmZyYXN0cnVjdHVyZS4gUGxlYXNlIHJlc3BvbmQgdG8gbnRwQGlldGYub3Jn LiBdDQoNClJlZ2FyZHMsDQpLYXJlbiBhbmQgRGlldGVyDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KVElDVE9DIG1haWxpbmcgbGlzdA0KVElDVE9DQGll dGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RpY3RvYw0K From nobody Thu Aug 31 00:14:07 2017 Return-Path: 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 A9EB8132D0C; Thu, 31 Aug 2017 00:14:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 ChJE5228TDVS; Thu, 31 Aug 2017 00:14:02 -0700 (PDT) Received: from rrzmta2.uni-regensburg.de (rrzmta2.uni-regensburg.de [194.94.155.52]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0C04132D0D; Thu, 31 Aug 2017 00:14:02 -0700 (PDT) Received: from rrzmta2.uni-regensburg.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 13853756DB; Thu, 31 Aug 2017 09:14:01 +0200 (CEST) Received: from gwsmtp1.uni-regensburg.de (gwsmtp1.uni-regensburg.de [132.199.5.51]) by rrzmta2.uni-regensburg.de (Postfix) with ESMTP id 017077331F; Thu, 31 Aug 2017 09:14:00 +0200 (CEST) Received: from uni-regensburg-smtp1-MTA by gwsmtp1.uni-regensburg.de with Novell_GroupWise; Thu, 31 Aug 2017 09:14:00 +0200 Message-Id: <59A7B736020000A100027ADF@gwsmtp1.uni-regensburg.de> X-Mailer: Novell GroupWise Internet Agent 14.2.2 Date: Thu, 31 Aug 2017 09:13:58 +0200 From: "Ulrich Windl" To: "Daniel Franke" , "ntp-bounces@ietf.org" , Cc: "ntp@ietf.org" , , References: <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> <47b5b4e3-41c9-6779-4a96-b11650483499@nwtime.org> In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Archived-At: Subject: [Ntp] Antw: Antwort: Re: WGLC for draft-ietf-ntp-using-nts-for-ntp X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 07:14:05 -0000 >>> schrieb am 30.08.2017 um 17:13 in Nachricht : [...] > I agree with Daniel. A standards document is not the appropriate place = for=20 > a performance analysis.=20 [...] I think it depends: Talking about CPU cycles for a specific machine should = not go into the draft, but considerations like O()-notation could. Also a = performance analysis at the protocol level (e.g. number of packet = round-trips) (not at the host level (e.g. time to process a packet)) would = very well fit any proposed protocol IMHO. To summarize: If the analysis is part of the "eternal truth", it should go = into the documents, but if it's just part of the "temporary truth" it = should not. Regards, Ulrich From ntp-bounces@ietf.org Thu Aug 31 00:14:07 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F439132D0D; Thu, 31 Aug 2017 00:14:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1504163647; bh=gAsrevOW/MslTKsPvyZdEkImWZFb8NHgHKX9MIncXFU=; h=Date:From:To:References:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc; b=Ypd3CoRMf+TvC+OOtK9ZR22l9HhhKn+KC3k44cHonaG8vRM9t1qk5gPgHkzHix9Mv gukGPYBH4Gw9uJOH8g9bj5UTAo2wiJjRcnYejNdamvj1dR+FVkCKG2xp8bhnFPzTcT 92KKXeUXob704I7gujZ82zFdamFa3pYzxGHXbgQo= 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 A9EB8132D0C; Thu, 31 Aug 2017 00:14:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 ChJE5228TDVS; Thu, 31 Aug 2017 00:14:02 -0700 (PDT) Received: from rrzmta2.uni-regensburg.de (rrzmta2.uni-regensburg.de [194.94.155.52]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0C04132D0D; Thu, 31 Aug 2017 00:14:02 -0700 (PDT) Received: from rrzmta2.uni-regensburg.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 13853756DB; Thu, 31 Aug 2017 09:14:01 +0200 (CEST) Received: from gwsmtp1.uni-regensburg.de (gwsmtp1.uni-regensburg.de [132.199.5.51]) by rrzmta2.uni-regensburg.de (Postfix) with ESMTP id 017077331F; Thu, 31 Aug 2017 09:14:00 +0200 (CEST) Received: from uni-regensburg-smtp1-MTA by gwsmtp1.uni-regensburg.de with Novell_GroupWise; Thu, 31 Aug 2017 09:14:00 +0200 Message-Id: <59A7B736020000A100027ADF@gwsmtp1.uni-regensburg.de> X-Mailer: Novell GroupWise Internet Agent 14.2.2 Date: Thu, 31 Aug 2017 09:13:58 +0200 From: "Ulrich Windl" To: "Daniel Franke" , "ntp-bounces@ietf.org" , References: <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> <47b5b4e3-41c9-6779-4a96-b11650483499@nwtime.org> In-Reply-To: Mime-Version: 1.0 Content-Disposition: inline Archived-At: Subject: [Ntp] Antw: Antwort: Re: WGLC for draft-ietf-ntp-using-nts-for-ntp X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "ntp@ietf.org" , kristof.teichel@ptb.de, stenn@nwtime.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ntp-bounces@ietf.org Sender: "ntp" >>> schrieb am 30.08.2017 um 17:13 in Nachricht : [...] > I agree with Daniel. A standards document is not the appropriate place for > a performance analysis. [...] I think it depends: Talking about CPU cycles for a specific machine should not go into the draft, but considerations like O()-notation could. Also a performance analysis at the protocol level (e.g. number of packet round-trips) (not at the host level (e.g. time to process a packet)) would very well fit any proposed protocol IMHO. To summarize: If the analysis is part of the "eternal truth", it should go into the documents, but if it's just part of the "temporary truth" it should not. Regards, Ulrich _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp From nobody Thu Aug 31 02:14:27 2017 Return-Path: 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 C4A1B1329AB; Thu, 31 Aug 2017 02:14:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 Nm6HglWyEx5E; Thu, 31 Aug 2017 02:14:24 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB818132709; Thu, 31 Aug 2017 02:14:24 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 5317F13A94; Thu, 31 Aug 2017 09:14:24 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 5317F13A94 Authentication-Results: ext-mx05.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx05.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=mlichvar@redhat.com Received: from localhost (unknown [10.43.2.117]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 778DF91D19; Thu, 31 Aug 2017 09:14:23 +0000 (UTC) Date: Thu, 31 Aug 2017 11:14:27 +0200 From: Miroslav Lichvar To: Karen O'Donoghue Cc: "ntp@ietf.org" , "tictoc@ietf.org" Message-ID: <20170831091427.GT11067@localhost> References: <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> User-Agent: Mutt/1.8.0 (2017-02-23) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Thu, 31 Aug 2017 09:14:24 +0000 (UTC) Archived-At: Subject: Re: [Ntp] WGLC for draft-ietf-ntp-using-nts-for-ntp X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 09:14:27 -0000 On Wed, Aug 09, 2017 at 04:41:25AM +0000, Karen O'Donoghue wrote: > https://datatracker.ietf.org/doc/draft-ietf-ntp-using-nts-for-ntp/ > > Please review and provide comments to the mailing list by no later than 31 August 2017. I don't support advancing the document as it currently stands (commit 5835e58 in the github repo). As I said before [1], the main issue for me is the use of DTLS transport in the symmetric mode. It's an easy solution how to get around some issues, but it demotes the mode to a second-class status. I think all timing messages in NTP should use the same transport. i.e. standard NTP format with optional extension fields on UDP port 123. The draft is still not clear on how should two active peers match their DTLS connections. I think it would need to specify the port of the DTLS client or exchange some additional information in DTLS or NTP that would identify the peer. My recommendation is to remove the specification of NTS in the symmetric mode from the document, at least for now. I believe the NTS-KE used in the client/server mode can be adopted for the symmetric mode, possibly with some small extensions, but it will take time. I think most of us here will agree it shouldn't delay the adoption of NTS in the client/server mode. [1] https://www.ietf.org/mail-archive/web/ntp/current/msg02048.html -- Miroslav Lichvar From ntp-bounces@ietf.org Thu Aug 31 02:14:28 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 546DB1329AB; Thu, 31 Aug 2017 02:14:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1504170868; bh=YHK3qmKp7I2GtJIS+vzy/k98eruDbBnkchnTV8tkBek=; h=Date:From:To:References:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc; b=sCaQ3ZHIZgrqMN4bANp7IxbkZ40UvPsnkk8EHAweEV4cyEX99WpekFsyzNKOy8r+R F8Z7hRpHBhkomOt1cwQfDszUAT3bSzQrmZaGJZE6ph9cs0WaN8Xo3jrjkcWldsjRzi QPMVTL5eOAk5oDtSBAxXhSK6WhVSisebbH1D3R2Q= 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 C4A1B1329AB; Thu, 31 Aug 2017 02:14:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 Nm6HglWyEx5E; Thu, 31 Aug 2017 02:14:24 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB818132709; Thu, 31 Aug 2017 02:14:24 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 5317F13A94; Thu, 31 Aug 2017 09:14:24 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 5317F13A94 Authentication-Results: ext-mx05.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx05.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=mlichvar@redhat.com Received: from localhost (unknown [10.43.2.117]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 778DF91D19; Thu, 31 Aug 2017 09:14:23 +0000 (UTC) Date: Thu, 31 Aug 2017 11:14:27 +0200 From: Miroslav Lichvar To: Karen O'Donoghue Message-ID: <20170831091427.GT11067@localhost> References: <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> User-Agent: Mutt/1.8.0 (2017-02-23) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Thu, 31 Aug 2017 09:14:24 +0000 (UTC) Archived-At: Subject: Re: [Ntp] WGLC for draft-ietf-ntp-using-nts-for-ntp X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "ntp@ietf.org" , "tictoc@ietf.org" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ntp-bounces@ietf.org Sender: "ntp" On Wed, Aug 09, 2017 at 04:41:25AM +0000, Karen O'Donoghue wrote: > https://datatracker.ietf.org/doc/draft-ietf-ntp-using-nts-for-ntp/ > > Please review and provide comments to the mailing list by no later than 31 August 2017. I don't support advancing the document as it currently stands (commit 5835e58 in the github repo). As I said before [1], the main issue for me is the use of DTLS transport in the symmetric mode. It's an easy solution how to get around some issues, but it demotes the mode to a second-class status. I think all timing messages in NTP should use the same transport. i.e. standard NTP format with optional extension fields on UDP port 123. The draft is still not clear on how should two active peers match their DTLS connections. I think it would need to specify the port of the DTLS client or exchange some additional information in DTLS or NTP that would identify the peer. My recommendation is to remove the specification of NTS in the symmetric mode from the document, at least for now. I believe the NTS-KE used in the client/server mode can be adopted for the symmetric mode, possibly with some small extensions, but it will take time. I think most of us here will agree it shouldn't delay the adoption of NTS in the client/server mode. [1] https://www.ietf.org/mail-archive/web/ntp/current/msg02048.html -- Miroslav Lichvar _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp From nobody Thu Aug 31 04:39:18 2017 Return-Path: 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 5EB80132D56 for ; Thu, 31 Aug 2017 04:39:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 FIMT8Ceu5xxS for ; Thu, 31 Aug 2017 04:39:14 -0700 (PDT) Received: from rrzmta1.uni-regensburg.de (rrzmta1.uni-regensburg.de [194.94.155.51]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64AED1321A5 for ; Thu, 31 Aug 2017 04:39:11 -0700 (PDT) Received: from rrzmta1.uni-regensburg.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 0393E577BA for ; Thu, 31 Aug 2017 13:39:10 +0200 (CEST) Received: from gwsmtp1.uni-regensburg.de (gwsmtp1.uni-regensburg.de [132.199.5.51]) by rrzmta1.uni-regensburg.de (Postfix) with ESMTP id D79CD57535 for ; Thu, 31 Aug 2017 13:39:09 +0200 (CEST) Received: from uni-regensburg-smtp1-MTA by gwsmtp1.uni-regensburg.de with Novell_GroupWise; Thu, 31 Aug 2017 13:39:09 +0200 Message-Id: <59A7F55B020000A100027B05@gwsmtp1.uni-regensburg.de> X-Mailer: Novell GroupWise Internet Agent 14.2.2 Date: Thu, 31 Aug 2017 13:39:07 +0200 From: "Ulrich Windl" To: "ntp@ietf.org" References: <59A7F55B020000A100027B05@gwsmtp1.uni-regensburg.de> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Archived-At: Subject: [Ntp] Questions on https://tools.ietf.org/html/draft-ietf-ntp-mode-6-cmds-02 X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 11:39:17 -0000 Hello! I just read https://tools.ietf.org/html/draft-ietf-ntp-mode-6-cmds-02 to = verify my older implementation of NTP control messages. I found some things that are strange! For example: (Page 4): "The original development of the NTP daemon included a remote = facility (ntpdc) for monitoring and configuration. This facility used mode = 7 commands to communicate with the NTP daemon. This document illustrates = the mode 7 packet format only.": I thought the document describes mode _6_ = packets!? Similar "The mode 7 message format is shown in Figure 3.: Why describe the = packet format then? While the draft talks about sequence and version numbers in the mode 7 = packet, it fails to specify it for mode 6 packets: "Version Number (VN): This is a three-bit integer indicating a minimum NTP = version number. NTP servers do not respond to control messages with an = unrecognized version number. Requests may intentionally use a lower = version number to enable interoperability with earlier versions of NTP. = Responses carry the same version as the corresponding request.": What is = the version number the draft specifies? Obviously the first NTP version to = support a mode 6 or 7 packet is version 2. As the definition of the Clock (Radio) Status word is quite different = between NTPv3 and NTPv4 (just as the System Event Code is) I wonder how a = conforming implementation will handle the VN transmitted in the request = packet: Will it respond with the correct packet regarding NV, will it flag = obsolete requests as an error (the current implementation does not), or = will it always return the current format? ("will" obviously should either = "SHOULD" or "MUST" in a specification) On page 6: "Each request uses a different sequence number.": Is this a = recommendation (SHOULD) or a requirement (MUST)? Obviously it should help = against spurious packets being received (or for multiple outstanding = requests when the order of packets received may vary). An unanswered issue is how to find out what version the remote party = supports, i.e. how to find out whether the remote party is NTPv3 or NTPv4 = (for example). Reading variable "version" with a low VN to guess the = version will fail on Solaris for example, where the daemon does not return = a version string... Regards, Ulrich From ntp-bounces@ietf.org Thu Aug 31 04:39:19 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 32565132D5A; Thu, 31 Aug 2017 04:39:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1504179559; bh=NcspfvF3nyay/oyZ+zIfIzIgam9IV7hmnIoDIZd3/Q4=; h=Date:From:To:References:Subject:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe; b=RTpO/s1buf65Zk020nQD9OfcNjoYQBjw+OifBPS/fxCii2lLei0qBAWi8VYHIZOI7 n4eLg4eCmndVSRQIaDDfDbjBPVP88WsFJHGEENAVclpxAdiiyWMaIZgHtSpp7dvhur nt5HNoO8GfFiiNlve2FXqD5V+zUeHIl6gSmfquZI= 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 5EB80132D56 for ; Thu, 31 Aug 2017 04:39:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 FIMT8Ceu5xxS for ; Thu, 31 Aug 2017 04:39:14 -0700 (PDT) Received: from rrzmta1.uni-regensburg.de (rrzmta1.uni-regensburg.de [194.94.155.51]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64AED1321A5 for ; Thu, 31 Aug 2017 04:39:11 -0700 (PDT) Received: from rrzmta1.uni-regensburg.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 0393E577BA for ; Thu, 31 Aug 2017 13:39:10 +0200 (CEST) Received: from gwsmtp1.uni-regensburg.de (gwsmtp1.uni-regensburg.de [132.199.5.51]) by rrzmta1.uni-regensburg.de (Postfix) with ESMTP id D79CD57535 for ; Thu, 31 Aug 2017 13:39:09 +0200 (CEST) Received: from uni-regensburg-smtp1-MTA by gwsmtp1.uni-regensburg.de with Novell_GroupWise; Thu, 31 Aug 2017 13:39:09 +0200 Message-Id: <59A7F55B020000A100027B05@gwsmtp1.uni-regensburg.de> X-Mailer: Novell GroupWise Internet Agent 14.2.2 Date: Thu, 31 Aug 2017 13:39:07 +0200 From: "Ulrich Windl" To: "ntp@ietf.org" References: <59A7F55B020000A100027B05@gwsmtp1.uni-regensburg.de> Mime-Version: 1.0 Content-Disposition: inline Archived-At: Subject: [Ntp] Questions on https://tools.ietf.org/html/draft-ietf-ntp-mode-6-cmds-02 X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ntp-bounces@ietf.org Sender: "ntp" Hello! I just read https://tools.ietf.org/html/draft-ietf-ntp-mode-6-cmds-02 to verify my older implementation of NTP control messages. I found some things that are strange! For example: (Page 4): "The original development of the NTP daemon included a remote facility (ntpdc) for monitoring and configuration. This facility used mode 7 commands to communicate with the NTP daemon. This document illustrates the mode 7 packet format only.": I thought the document describes mode _6_ packets!? Similar "The mode 7 message format is shown in Figure 3.: Why describe the packet format then? While the draft talks about sequence and version numbers in the mode 7 packet, it fails to specify it for mode 6 packets: "Version Number (VN): This is a three-bit integer indicating a minimum NTP version number. NTP servers do not respond to control messages with an unrecognized version number. Requests may intentionally use a lower version number to enable interoperability with earlier versions of NTP. Responses carry the same version as the corresponding request.": What is the version number the draft specifies? Obviously the first NTP version to support a mode 6 or 7 packet is version 2. As the definition of the Clock (Radio) Status word is quite different between NTPv3 and NTPv4 (just as the System Event Code is) I wonder how a conforming implementation will handle the VN transmitted in the request packet: Will it respond with the correct packet regarding NV, will it flag obsolete requests as an error (the current implementation does not), or will it always return the current format? ("will" obviously should either "SHOULD" or "MUST" in a specification) On page 6: "Each request uses a different sequence number.": Is this a recommendation (SHOULD) or a requirement (MUST)? Obviously it should help against spurious packets being received (or for multiple outstanding requests when the order of packets received may vary). An unanswered issue is how to find out what version the remote party supports, i.e. how to find out whether the remote party is NTPv3 or NTPv4 (for example). Reading variable "version" with a low VN to guess the version will fail on Solaris for example, where the daemon does not return a version string... Regards, Ulrich _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp From ntp-bounces@ietf.org Thu Aug 31 05:34:21 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A0ED132D93; Thu, 31 Aug 2017 05:34:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1504182861; bh=dxh/SBw1yugzMZu22BKFPGp1BALeQNqvRoxV/eY9O7c=; h=In-Reply-To:References:From:Date:To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc; b=RkSQEOKjFbhjxlkn0HUnM9aKJAh5BK3zt9ouZqc1/hR5aYlF9CE6/zLGrUlFxc7io xQ1A/ZPHJm5y9SpaEelsO6UgxmNlKZ43RMgPSHz8r6D4AVq96kZQYgqu8DVsN7LhHf iDei+92guBZXWD6JvYHLJ2OCm0y/MbOt4uHgTHKc= 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 AAD28132D6F; Thu, 31 Aug 2017 05:34:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 UjRqffzw6xHX; Thu, 31 Aug 2017 05:34:12 -0700 (PDT) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (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 33F3D132D89; Thu, 31 Aug 2017 05:34:05 -0700 (PDT) Received: by mail-wm0-x231.google.com with SMTP id f127so3855494wmf.1; Thu, 31 Aug 2017 05:34:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=bG4VjwOWuvYq0jOcsqtZYHJkZbCO0J606TwYNNA7RzQ=; b=VCJhFDdhpdjWXVVzONAjH+rlWJC/zs0Grdi8/QlZtEzrnetegyRsGJEqM4XkMuKAWO d09x1/4HM0hj8xC6cY6x1ZqfcGtqRtiMrtRndUh6MTM5Hts26fXcP8COeRMod9s65oPk rnmjzb/u6gxckKGHnx6bvfAtVqvVflPIOnEHG6Wus3UkrJKa/bqi6wNSzUMSq9AeYshz JBi7ODE7nXUuBQnSrzwPNIbGfIwlFdDdRSR05nTGdfxOLVBAPlu0+uNHTLfk6/eTodVW Izy5stLCKXJZ0GnXnxSBGHxgcWmU7+dwGGWSc8sVBn+LrGMo4hZq4FwMiNe1uc4RS/Ph YMIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=bG4VjwOWuvYq0jOcsqtZYHJkZbCO0J606TwYNNA7RzQ=; b=WA5xej/Cj73leWQySE1hdiTa4HEzrCKLLxeTXhX7AP+uIs2uACxSGXdyaeuDaiQa4u /yinks4PtD+bMEzYMr6iNb4nVlCGAleFxf3FmNLp/b1xD4FfaQWGOh9o839AR/qZzpLj kXlAHATSq6gPlci8Bma7xImlRuYMhUg0BzexI5cfj2ajQM0hbeNzEOqTnwMB9bGSX5oh sa7m7GI6XcuAc6DrDdQ4KSWB3gGogsPPVOsQ93mEnnavQkE+6isALn3zPIJRr1L9PD1e cP0kU9NfPb7kOQnl8Ypo/qp9vddbYXsu84cuJ17afjzWglEqv6BrNsZqnJmeO2LFD8eI +j9g== X-Gm-Message-State: AHYfb5j/QVHMDYmQl0SA3PDNxUBRlfiGIE15FIU2t9BLeLGppEsQ8732 h7LicFFgZh0WJdytjtctpeqPaDMDLdIb2/s= X-Google-Smtp-Source: ADKCNb59AXZkgmzu5+rgAOCaTe25ptdM88ofHzHDSeCCZiRkNBZphorq0Cg0k5tTVzQ8PCp4PYGLHizQnP+lVakK8io= X-Received: by 10.80.240.214 with SMTP id a22mr1105992edm.294.1504182843360; Thu, 31 Aug 2017 05:34:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.157.140 with HTTP; Thu, 31 Aug 2017 05:34:02 -0700 (PDT) In-Reply-To: <20170831091427.GT11067@localhost> References: <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> <20170831091427.GT11067@localhost> From: Daniel Franke Date: Thu, 31 Aug 2017 08:34:02 -0400 Message-ID: To: Miroslav Lichvar Archived-At: Subject: Re: [Ntp] WGLC for draft-ietf-ntp-using-nts-for-ntp X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "ntp@ietf.org" , "tictoc@ietf.org" , Karen O'Donoghue Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ntp-bounces@ietf.org Sender: "ntp" Replies inline, paragraphs reordered. On 8/31/17, Miroslav Lichvar wrote: > As I said before [1], the main issue for me is the use of DTLS transport > in the symmetric mode. It's an easy solution how to get around some > issues, but it demotes the mode to a second-class status. I think all > timing messages in NTP should use the same transport. i.e. standard > NTP format with optional extension fields on UDP port 123. I strongly disagree with you that this is giving "second-class status". I don't view NTS-KE as the Right Thing and DTLS encapsulation as a kludge; if anything, it's the other way around. The DTLS record layer is simple, correct, and performant. It's what I'd want to use for everything if it weren't for the pesky state-management issue. Lots of people on this list seem to have the intuition that sending time packets over DTLS can never be as accurate as sending them over the NTP port with an authenticator attached. But as I showed in my analysis the other day, that just ain't so. > My recommendation is to remove the specification of NTS in the symmetric > mode from the document, at least for now. I believe the NTS-KE used in > the client/server mode can be adopted for the symmetric mode, possibly > with some small extensions, but it will take time. I think most of us > here will agree it shouldn't delay the adoption of NTS in the > client/server mode. If specification for symmetric mode were removed, how would section 4 read? Do you want to get rid of DTLS encapsulation altogether? Restrict what traffic can be sent over it? Can you send a PR with what you have in mind? (Won't promise to merge it, but I'll review it) > The draft is still not clear on how should two active peers match > their DTLS connections. I think it would need to specify the port of > the DTLS client or exchange some additional information in DTLS or NTP > that would identify the peer. In my composing this reply you've convinced me on the "not clear" part; I'd better add something about this in the security considerations or everybody is going to screw it up. With plain unauthenticated NTP, we rely on IP and port to identify peers. But IP addresses aren't cryptographic identities; that's why DTLS needs certificates. To do symmetric mode safely, you need a mutually authenticated handshake (i.e., both sides present certificates). The identity in that certificate is the additional information you're looking for. Chairs, I'm temporarily changing my *own* vote on advancement to "no" until I've expanded on this. It goes back to "yes" with my next git push :-). _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp From nobody Thu Aug 31 05:34:25 2017 Return-Path: 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 AAD28132D6F; Thu, 31 Aug 2017 05:34:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 UjRqffzw6xHX; Thu, 31 Aug 2017 05:34:12 -0700 (PDT) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (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 33F3D132D89; Thu, 31 Aug 2017 05:34:05 -0700 (PDT) Received: by mail-wm0-x231.google.com with SMTP id f127so3855494wmf.1; Thu, 31 Aug 2017 05:34:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=bG4VjwOWuvYq0jOcsqtZYHJkZbCO0J606TwYNNA7RzQ=; b=VCJhFDdhpdjWXVVzONAjH+rlWJC/zs0Grdi8/QlZtEzrnetegyRsGJEqM4XkMuKAWO d09x1/4HM0hj8xC6cY6x1ZqfcGtqRtiMrtRndUh6MTM5Hts26fXcP8COeRMod9s65oPk rnmjzb/u6gxckKGHnx6bvfAtVqvVflPIOnEHG6Wus3UkrJKa/bqi6wNSzUMSq9AeYshz JBi7ODE7nXUuBQnSrzwPNIbGfIwlFdDdRSR05nTGdfxOLVBAPlu0+uNHTLfk6/eTodVW Izy5stLCKXJZ0GnXnxSBGHxgcWmU7+dwGGWSc8sVBn+LrGMo4hZq4FwMiNe1uc4RS/Ph YMIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=bG4VjwOWuvYq0jOcsqtZYHJkZbCO0J606TwYNNA7RzQ=; b=WA5xej/Cj73leWQySE1hdiTa4HEzrCKLLxeTXhX7AP+uIs2uACxSGXdyaeuDaiQa4u /yinks4PtD+bMEzYMr6iNb4nVlCGAleFxf3FmNLp/b1xD4FfaQWGOh9o839AR/qZzpLj kXlAHATSq6gPlci8Bma7xImlRuYMhUg0BzexI5cfj2ajQM0hbeNzEOqTnwMB9bGSX5oh sa7m7GI6XcuAc6DrDdQ4KSWB3gGogsPPVOsQ93mEnnavQkE+6isALn3zPIJRr1L9PD1e cP0kU9NfPb7kOQnl8Ypo/qp9vddbYXsu84cuJ17afjzWglEqv6BrNsZqnJmeO2LFD8eI +j9g== X-Gm-Message-State: AHYfb5j/QVHMDYmQl0SA3PDNxUBRlfiGIE15FIU2t9BLeLGppEsQ8732 h7LicFFgZh0WJdytjtctpeqPaDMDLdIb2/s= X-Google-Smtp-Source: ADKCNb59AXZkgmzu5+rgAOCaTe25ptdM88ofHzHDSeCCZiRkNBZphorq0Cg0k5tTVzQ8PCp4PYGLHizQnP+lVakK8io= X-Received: by 10.80.240.214 with SMTP id a22mr1105992edm.294.1504182843360; Thu, 31 Aug 2017 05:34:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.157.140 with HTTP; Thu, 31 Aug 2017 05:34:02 -0700 (PDT) In-Reply-To: <20170831091427.GT11067@localhost> References: <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> <20170831091427.GT11067@localhost> From: Daniel Franke Date: Thu, 31 Aug 2017 08:34:02 -0400 Message-ID: To: Miroslav Lichvar Cc: "Karen O'Donoghue" , "ntp@ietf.org" , "tictoc@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Ntp] WGLC for draft-ietf-ntp-using-nts-for-ntp X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 12:34:18 -0000 Replies inline, paragraphs reordered. On 8/31/17, Miroslav Lichvar wrote: > As I said before [1], the main issue for me is the use of DTLS transport > in the symmetric mode. It's an easy solution how to get around some > issues, but it demotes the mode to a second-class status. I think all > timing messages in NTP should use the same transport. i.e. standard > NTP format with optional extension fields on UDP port 123. I strongly disagree with you that this is giving "second-class status". I don't view NTS-KE as the Right Thing and DTLS encapsulation as a kludge; if anything, it's the other way around. The DTLS record layer is simple, correct, and performant. It's what I'd want to use for everything if it weren't for the pesky state-management issue. Lots of people on this list seem to have the intuition that sending time packets over DTLS can never be as accurate as sending them over the NTP port with an authenticator attached. But as I showed in my analysis the other day, that just ain't so. > My recommendation is to remove the specification of NTS in the symmetric > mode from the document, at least for now. I believe the NTS-KE used in > the client/server mode can be adopted for the symmetric mode, possibly > with some small extensions, but it will take time. I think most of us > here will agree it shouldn't delay the adoption of NTS in the > client/server mode. If specification for symmetric mode were removed, how would section 4 read? Do you want to get rid of DTLS encapsulation altogether? Restrict what traffic can be sent over it? Can you send a PR with what you have in mind? (Won't promise to merge it, but I'll review it) > The draft is still not clear on how should two active peers match > their DTLS connections. I think it would need to specify the port of > the DTLS client or exchange some additional information in DTLS or NTP > that would identify the peer. In my composing this reply you've convinced me on the "not clear" part; I'd better add something about this in the security considerations or everybody is going to screw it up. With plain unauthenticated NTP, we rely on IP and port to identify peers. But IP addresses aren't cryptographic identities; that's why DTLS needs certificates. To do symmetric mode safely, you need a mutually authenticated handshake (i.e., both sides present certificates). The identity in that certificate is the additional information you're looking for. Chairs, I'm temporarily changing my *own* vote on advancement to "no" until I've expanded on this. It goes back to "yes" with my next git push :-). From ntp-bounces@ietf.org Thu Aug 31 05:45:37 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 34451132D91; Thu, 31 Aug 2017 05:45:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1504183537; bh=4oMkrSVDqOLkQEwjaZ3X2i/GmNbyGV+HI7v7j3bmxXE=; h=In-Reply-To:References:From:Date:To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc; b=mc3xzrm1PfWJBuwhSNcBqlo5hJ5C7FYjV07dQCGb/iEVFZOD9Ob+Da9pkvZPDU3aE Dc9BvdyqERlqLkfB+C1SabW9wQ53I7d6MsLPtP5hNfYk9IsjP8MU9TGPbRGaEBZdZY Zs9BdwimYdzecKKYFxpv4GPjjCXDJgfETElVtIDM= 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 62A03132D89; Thu, 31 Aug 2017 05:45:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 GEb2RXSx7OmV; Thu, 31 Aug 2017 05:45:32 -0700 (PDT) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (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 6EADD1321AC; Thu, 31 Aug 2017 05:45:31 -0700 (PDT) Received: by mail-wm0-x232.google.com with SMTP id u26so3770657wma.0; Thu, 31 Aug 2017 05:45:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mzFLa5skYIBb5eehisWhoO05q8p6gCEzcfXvqHsr/7c=; b=aGrtuVhUHa4/y8GXX065XmYV9uUILmD7jFp9l671TkYY4oJJs7/nvZvWXZzQKqFeXl 7WERNSRdoiSwCh3I880C1XdHkld5wmogRdQ4TVtSSb3X328v70ZRCqktJ587X+mhsRps EVHTNC+LWDsnioVkWrlPVnIIj2ZMGGKtifkbZzBjnYh3jgmXqTbnHkKGTY0t+5YE3ZPt zeHVOmWzMKDz1o1uAgWKlRs5tqQJEHcMeRqr2F3DfP+7mVgXX3KBjuGkCPx2VmMLSrGa 7U0lXym1PGcGvnRHyhCpLOMF2HVIZvClIhrnhHo7f9zxvLFUSq1RfVVnpGzLESx+J3pF 2SUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=mzFLa5skYIBb5eehisWhoO05q8p6gCEzcfXvqHsr/7c=; b=M0O/NM2X/IftdeuKqhErGr6DIBBSHjhNClLuC7Jvof3zlSukt/YcCIlJEAEPro/+eO ZkJvbGxJy6YQ3L1I6HfZ+3TCmZgnx39WSHliDKNjB9aDCgssi4xYpQ1xhNAIsdTvUOOr pxF0W3NJqrAskbfejwGnD8TxoAR3JyJhcfSccEU6eVtihyIt0LYjLHlyMZHxtvNo7u33 XI4lTO28cgRSS0KLziC5bms4MZuFB697WeeY9Y/EHLy9fT/JlQnG2Ha4eYvDiImK6cyW PrkxV+REp8jfWmhqx2RBKWnYeMp5IjXsodAorUgJ4x2pr8B00YLD08TpBsypomWiOSHY 4jGw== X-Gm-Message-State: AHYfb5g+M60mLFOALohwhx+qlddlIqLgHSKkjBo69VRhtTjBdKv2hXLr wbBMHaKfcPsQxkTkAiWfzizWP9a5lg== X-Google-Smtp-Source: ADKCNb43hxru4C8Q85qVaSWYC61BuMIheQkVdIVS/AIOc/CqRu/EFwVl5vTMQSK7XJJ2XBJ3fa5KtS1o7Ybka7Hxtg4= X-Received: by 10.80.240.135 with SMTP id v7mr1096310edl.54.1504183529891; Thu, 31 Aug 2017 05:45:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.157.140 with HTTP; Thu, 31 Aug 2017 05:45:29 -0700 (PDT) In-Reply-To: <3B0A1BED22CAD649A1B3E97BE5DDD68BBB59A424@dggeml507-mbx.china.huawei.com> References: <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> <3B0A1BED22CAD649A1B3E97BE5DDD68BBB59A424@dggeml507-mbx.china.huawei.com> From: Daniel Franke Date: Thu, 31 Aug 2017 08:45:29 -0400 Message-ID: To: Jiangyuanlong Archived-At: Subject: Re: [Ntp] WGLC for draft-ietf-ntp-using-nts-for-ntp X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Aanchal Malhotra , "ntp@ietf.org" , "tictoc@ietf.org" , Karen O'Donoghue , Sharon Goldberg Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ntp-bounces@ietf.org Sender: "ntp" On 8/31/17, Jiangyuanlong wrote: > Hi, after going through this draft, I am not sure whether > ietf-ntp-data-minimization-00 should be listed in the Normative Reference, > or not at all. I was *just* about to bring this up myself. I think it's properly an informative reference. Sharon, Aanchal, CCing the two of you because I recall you had a different opinion last year in Boston and thought it should stay a normative reference (but I'm not sure I understood you correctly then). Note that this is a completely separate issue from whether data minimization should be published as Standards Track vs. Informational. It can stay a Standards Track document and still be cited from NTS for Informative purposes. _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp From nobody Thu Aug 31 05:45:42 2017 Return-Path: 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 62A03132D89; Thu, 31 Aug 2017 05:45:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 GEb2RXSx7OmV; Thu, 31 Aug 2017 05:45:32 -0700 (PDT) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (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 6EADD1321AC; Thu, 31 Aug 2017 05:45:31 -0700 (PDT) Received: by mail-wm0-x232.google.com with SMTP id u26so3770657wma.0; Thu, 31 Aug 2017 05:45:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mzFLa5skYIBb5eehisWhoO05q8p6gCEzcfXvqHsr/7c=; b=aGrtuVhUHa4/y8GXX065XmYV9uUILmD7jFp9l671TkYY4oJJs7/nvZvWXZzQKqFeXl 7WERNSRdoiSwCh3I880C1XdHkld5wmogRdQ4TVtSSb3X328v70ZRCqktJ587X+mhsRps EVHTNC+LWDsnioVkWrlPVnIIj2ZMGGKtifkbZzBjnYh3jgmXqTbnHkKGTY0t+5YE3ZPt zeHVOmWzMKDz1o1uAgWKlRs5tqQJEHcMeRqr2F3DfP+7mVgXX3KBjuGkCPx2VmMLSrGa 7U0lXym1PGcGvnRHyhCpLOMF2HVIZvClIhrnhHo7f9zxvLFUSq1RfVVnpGzLESx+J3pF 2SUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=mzFLa5skYIBb5eehisWhoO05q8p6gCEzcfXvqHsr/7c=; b=M0O/NM2X/IftdeuKqhErGr6DIBBSHjhNClLuC7Jvof3zlSukt/YcCIlJEAEPro/+eO ZkJvbGxJy6YQ3L1I6HfZ+3TCmZgnx39WSHliDKNjB9aDCgssi4xYpQ1xhNAIsdTvUOOr pxF0W3NJqrAskbfejwGnD8TxoAR3JyJhcfSccEU6eVtihyIt0LYjLHlyMZHxtvNo7u33 XI4lTO28cgRSS0KLziC5bms4MZuFB697WeeY9Y/EHLy9fT/JlQnG2Ha4eYvDiImK6cyW PrkxV+REp8jfWmhqx2RBKWnYeMp5IjXsodAorUgJ4x2pr8B00YLD08TpBsypomWiOSHY 4jGw== X-Gm-Message-State: AHYfb5g+M60mLFOALohwhx+qlddlIqLgHSKkjBo69VRhtTjBdKv2hXLr wbBMHaKfcPsQxkTkAiWfzizWP9a5lg== X-Google-Smtp-Source: ADKCNb43hxru4C8Q85qVaSWYC61BuMIheQkVdIVS/AIOc/CqRu/EFwVl5vTMQSK7XJJ2XBJ3fa5KtS1o7Ybka7Hxtg4= X-Received: by 10.80.240.135 with SMTP id v7mr1096310edl.54.1504183529891; Thu, 31 Aug 2017 05:45:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.157.140 with HTTP; Thu, 31 Aug 2017 05:45:29 -0700 (PDT) In-Reply-To: <3B0A1BED22CAD649A1B3E97BE5DDD68BBB59A424@dggeml507-mbx.china.huawei.com> References: <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> <3B0A1BED22CAD649A1B3E97BE5DDD68BBB59A424@dggeml507-mbx.china.huawei.com> From: Daniel Franke Date: Thu, 31 Aug 2017 08:45:29 -0400 Message-ID: To: Jiangyuanlong Cc: "Karen O'Donoghue" , "ntp@ietf.org" , "tictoc@ietf.org" , Sharon Goldberg , Aanchal Malhotra Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Ntp] WGLC for draft-ietf-ntp-using-nts-for-ntp X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 12:45:34 -0000 On 8/31/17, Jiangyuanlong wrote: > Hi, after going through this draft, I am not sure whether > ietf-ntp-data-minimization-00 should be listed in the Normative Reference, > or not at all. I was *just* about to bring this up myself. I think it's properly an informative reference. Sharon, Aanchal, CCing the two of you because I recall you had a different opinion last year in Boston and thought it should stay a normative reference (but I'm not sure I understood you correctly then). Note that this is a completely separate issue from whether data minimization should be published as Standards Track vs. Informational. It can stay a Standards Track document and still be cited from NTS for Informative purposes. From nobody Thu Aug 31 06:26:55 2017 Return-Path: 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 82AA0132E03 for ; Thu, 31 Aug 2017 06:26:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sonia.de 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 1xPi7gZoPE_U for ; Thu, 31 Aug 2017 06:26:39 -0700 (PDT) Received: from mailgate1.sonia.de (mailgate1.sonia.de [141.41.1.242]) (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 7203D132E13 for ; Thu, 31 Aug 2017 06:26:18 -0700 (PDT) Received: from mailgate1.sonia.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 74B7213169; Thu, 31 Aug 2017 15:26:16 +0200 (CEST) Received: from mail.sonia.de (mail.sonia.de [141.41.8.70]) by mailgate1.sonia.de (Postfix) with ESMTP id 7AB3C13155; Thu, 31 Aug 2017 15:26:14 +0200 (CEST) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_T+Lb6Oqlh0eEORkb/+60rg)" Received: from ostfalia.de ([141.41.8.70]) by mail.sonia.de (Oracle Communications Messaging Server 7.0.5.37.0 64bit (built Jan 25 2016)) with ESMTPA id <0OVJ00LKJXBQ1G00@mail.sonia.de>; Thu, 31 Aug 2017 15:26:14 +0200 (CEST) Received: from [141.41.8.91] (Forwarded-For: 141.41.8.91) by mail.sonia.de (mshttpd); Thu, 31 Aug 2017 15:26:14 +0200 From: Martin Langer To: Daniel Franke Cc: ntp@ietf.org Message-id: <6f30da5ad29de.59a82a96@ostfalia.de> Date: Thu, 31 Aug 2017 15:26:14 +0200 X-Mailer: Oracle Communications Messenger Express 7.0.5.37.0 64bit (built Jan 25 2016) Content-language: de X-Accept-Language: de Priority: normal In-reply-to: References: <70a0c971b2978.598d965e@ostfalia.de> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sonia.de; h=mime-version:content-type:from:to:cc:message-id:date:subject:in-reply-to:references; s=20140129; bh=8cGn7scUhnjHCByICi0tCaaT/oMrEZlBUsUGcNF6nPo=; b=DXI5zDVREStbSlF/CbE5cPFsHASV8FOWrENOxwDF8dK3zOvZ3yilYacwYnsFu/oncZjqiLihd+RfC8wUKlFgbjWfJohr+/5E+Mchwn8JXf22gyHlnppwPPUrlgCZava2wY/QKf7RdDLDLLCETXSW8xsD7tD7JksQqqhom7b7oB4= Archived-At: Subject: Re: [Ntp] some comments on the NTS4NTP-Draft09 X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 13:26:47 -0000 This is a multi-part message in MIME format. --Boundary_(ID_T+Lb6Oqlh0eEORkb/+60rg) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Content-disposition: inline Hello all, I'm back now. I have not managed to read all the mail, but thanks for the replies. I think I found another minor problem that I wanted to address. The following case: During the NTS-KE the client sends various record types to the server. The 'NTS Next Protocol Negotiation' record type contains 2 IDs (ID 0 for NTP/4 and ID 1 for PTP/2). The server will generate one or more cookies in the response message. To do this, the S2C and C2S key must be extracted first. Now in Section 5.2: [...] However, all protocols which utilize NTS-KE MUST conform to the following two rules: The disambiguating label string MUST be "EXPORTER-network-timesecurity/1". The per-association context value MUST be provided, and MUST begin with the two-octet Protocol ID which was negotiated as a Next Protocol. [..] Indeed, at the moment we use ID 0 for NTP. But which ID is selected when the server supports both protocols (IDs)? Best regards, Martin Am 29.08.17 20:26 schrieb Daniel Franke : > > Sorry for overlooking this earlier. > > On 8/11/17, Martin Langer wrote: > > > 1. confusing term "ntp/4" > > ----------------------------------------- > > "ntp/4" is the same term as in the TLS ALPN extension (see: page 18, chapter > > 8): > > > > [...] IANA is requested to allocate the following two entries in the > > Application-Layer Protocol Negotation (ALPN) Protocol IDs registry: [...] > > Protocol: Network Time Protocol, version 4 Identification Sequence: 0x6E > > 0x74 0x70 0x2F 0x34 ("ntp/4") [...] > > > > But the NTS Next Protocol Negotiation record contains IDs (e.g. 0x00 for > > 'Network Time Protocol version 4'; see table at page 21) and not the term > > 'ntp/4'. This can confusing some readers. > > Yup, this is an outright error. I'll fix it in Git momentarily. > > > 2. Network Byte Order / Host Byte Order > > > 3. general comment > > ----------- > > My first thought was: why? At first it was a magic number for me. The > > solution is here: chapter 5.2: > > [...] and MUST begin with the two-octet Protocol ID which was negotiated as > > a Next Protocol. [...] > > > > I think this should be mentioned again or referenced to the corresponding > > table (chapter 8). > > I'll edit to clarify these. > > > 4. general comment > > ============================================================ > > > > page 13 (chapter 6.5, 2nd section): > > ----------------------------------------- > > [...] This length requirement serves to ensure that the response will not be > > larger than the request, in order to improve timekeeping precision and > > [...] > > > > > > remark: > > ----------- > > Does it really improve the timekeeping? I think the idea is to reduce the > > asymmetry if the request and response message have the same size. > > But client and server may have different performance and therefore the > > processing speed per NTP Package is different too. ...it's just a thought > > I'm led to believe Prof. Mills did some experiments at one point and > found a non-zero impact from using asymmetrically-sized packets. I > guess a citation here would help. Harlan/Dave, do you know of any > academic reference I can point at to support this claim? > > > > 5. alternative proposal > > ============================================================ > > > > page 20 (chapter 8, 1st section): > > ----------------------------------------- > > [...] Type Number (REQUIRED): An integer in the range 0-32767 inclusive > > [...] > > > > > > better?: > > ----------- > > [...] Type Number (REQUIRED): An 15 bit integer in the range 0-32767 > > inclusive [...] > > > > ....not 16 bit, because we use a critical bit in our records (first bit) > > I disagree that this is an improvement. At best it's redundant since > 0-32767 already covers the full range of possible 15-bit values. But > more importantly, we should be maintaining separation of concerns > between the IANA registry and the protocol specs which make reference > to it. IANA is just recording the number. It's up to protocol > specification to define how it should be encoded. > > > 6. some problems with 'The NTS Authenticator and Encrypted Extensions > > extension' (page 14, chapter 6.6) > > ============================================================ > > > > field description: > > ----------------------------------------- > > 'Nonce lenght': We should mention that the value is to be interpreted as > > 'unsigned int'. > > I agree. I've just changed this in git. > > > 'Nonce': At first I had some trouble to understand where the nonce comes > > from and which length we use. Now I know it, but maybe we should add some > > more information to this field. > > perhaps from these: [...] Nonce: a nonce as required by the negotiated AEAD > > Algorithm. [...] to these: [...] Nonce: a new generated nonce whose length > > and format is determined by the negotiated AEAD algorithm (RFC 5116, chapter > > 3.2). [...] > > I don't quite like the wording you propose but I'll see if I can make > some clarification along those lines. > > > 'Chipertext': Some readers (students in my team) had difficulties to > > understand this field. All of them thought, that this field contains an > > encrypted version of the whole NTP package. And this is wrong. I think the > > problem is this line: [...] authentication tag in addition to the actual > > ciphertext. [...]. Well, if readers do not know exactly how AEAD works, then > > this leads to strong understanding problems at this point, since the terms > > 'authentication tag' and 'ciphertext' seem not known. I think we should add > > a reference (RFC 5116 --> AEAD) or some information about this terms > > ('authentication tag' is like a MAC and 'ciphertext' contains optional > > Extension Fields and can be absent if no Extension Fields are encrypted.). > > Maybe confuses the field name 'Chipertext' too. > > The use of 'ciphertext' here comes straight out of RFC 5116, which in > turn comes out of Rogaway's 2002 paper in which he coins "AEAD". I > agree it's a little confusing if you're not steeped in the relevant > literature but I think any departure from the RFC 5116 terminology > would do more harm than good. > > > > > > > 'Padding:' This line: [...] so that implementations can unambiguously > > delimit the end of the ciphertext from the start of the padding [...] can be > > difficult to. In the beginning I did not know how this should work. We > > should say that implementations can read the last octet of this extension > > content, to find out how big the padding is. > > Fair enough. > > > Furthermore we should change this line: > > [...] requirement that (in the absence of a legacy MAC) extensions have a > > total length in octets (including the four octets for the type and length > > fields) [...] > > > > in this: > > [...] requirement that (in the absence of a legacy MAC) NTP extensions have > > a total length in octets (including the four octets for the type and length > > fields) [...] > > This interacts somewhat with Harlan's request to say "extension field" > rather than just "extension". I've done that now, and I'll go through > RFC 7822 again to make sure we're using consistent terminology in this > and other places. > > > > [...] P: The plaintext SHALL consist of all (if any) extensions to be > > encrypted. [...] > > > > Which format? Typical NTPv4 Extension Fields or another format? We should > > define that. We should also mention that only this content is encrypted (not > > the content of parameter 'A'). > > If we don't want encrypt anything (default case), then this parameter is > > empty. > > Typcial NTPv4 EFs. I'll add a sentence or two to clarify this. > > > Please let me know if you have problems to understand my *english*. > > Your English is completely fine. > --Boundary_(ID_T+Lb6Oqlh0eEORkb/+60rg) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable Content-disposition: inline Hello all=2C=3Cbr /=3E=3Cbr /=3EI=27m back now=2E I have not managed to = read all the mail=2C but thanks for the replies=2E I think I found anoth= er =3Cspan class=3D=22=22 id=3D=22result=5Fbox=22 lang=3D=22en=22 tabind= ex=3D=22-1=22=3E=3Cspan class=3D=22=22=3Eminor problem that I wanted to = address=2E=3C/span=3E=3C/span=3E=3Cbr /=3E=3Cspan class=3D=22=22 id=3D=22= result=5Fbox=22 lang=3D=22en=22=3E=3Cspan class=3D=22=22=3E=3Cspan class= =3D=22=22 id=3D=22result=5Fbox=22 lang=3D=22en=22=3E=3Cspan class=3D=22=22= =3E=3C/span=3E=3C/span=3E=3Cspan class=3D=22=22 id=3D=22result=5Fbox=22 = lang=3D=22en=22=3E=3Cspan class=3D=22=22=3E=3Cspan class=3D=22short=5Fte= xt=22 id=3D=22result=5Fbox=22 lang=3D=22en=22=3E=3Cspan class=3D=22=22=3E= The following case=3A=C2=A0 =3C/span=3E=3C/span=3E=3C/span=3E=3C/span=3E= During the NTS-KE the client sends various record types to the server=2E= =3C/span=3E=3C/span=3E=3Cspan class=3D=22=22 id=3D=22result=5Fbox=22 la= ng=3D=22en=22=3E=3Cspan class=3D=22=22=3E=3Cspan class=3D=22short=5Ftext= =22 id=3D=22result=5Fbox=22 lang=3D=22en=22=3E=3Cspan class=3D=22=22=3E=3C= /span=3E=3C/span=3EThe =27NTS Next Protocol Negotiation=27 record type c= ontains 2 IDs (ID 0 for NTP/4 and ID 1 for PTP/2)=2E =3C/span=3E=3C/span= =3E=3Cspan class=3D=22=22 id=3D=22result=5Fbox=22 lang=3D=22en=22=3E=3Cs= pan=3EThe server will generate one or more cookies in the response messa= ge=2E=3C/span=3E =3Cspan class=3D=22=22=3E=3C/span=3E=3C/span=3E=3Cspan = class=3D=22=22 id=3D=22result=5Fbox=22 lang=3D=22en=22=3E=3Cspan class=3D= =22=22=3E=3Cspan class=3D=22short=5Ftext=22 id=3D=22result=5Fbox=22 lang= =3D=22en=22=3E=3Cspan class=3D=22alt-edited=22=3ETo do this=2C the =3C/s= pan=3E=3C/span=3E=3C/span=3E=3C/span=3E=3Cspan class=3D=22=22 id=3D=22re= sult=5Fbox=22 lang=3D=22en=22=3E=3Cspan class=3D=22=22=3E=3Cspan class=3D= =22short=5Ftext=22 id=3D=22result=5Fbox=22 lang=3D=22en=22=3E=3Cspan cla= ss=3D=22alt-edited=22=3E=3Cspan class=3D=22=22 id=3D=22result=5Fbox=22 l= ang=3D=22en=22=3E=3Cspan class=3D=22=22=3ES2C and C2S =3C/span=3E=3C/spa= n=3Ekey =3C/span=3E=3C/span=3E=3C/span=3E=3C/span=3E=3Cspan class=3D=22=22= id=3D=22result=5Fbox=22 lang=3D=22en=22=3E=3Cspan class=3D=22=22=3E=3Cs= pan class=3D=22=22 id=3D=22result=5Fbox=22 lang=3D=22en=22=3E=3Cspan cla= ss=3D=22=22=3E=3Cspan class=3D=22short=5Ftext=22 id=3D=22result=5Fbox=22= lang=3D=22en=22=3E=3Cspan class=3D=22alt-edited=22=3Emust be extracted = first=2E=3C/span=3E=3C/span=3E=3C/span=3E=3C/span=3E=3Cbr /=3E=3Cbr /=3E= =3C/span=3E=3C/span=3ENow in Section 5=2E2=3A=3Cbr /=3E=3Cbr /=3E=5B=2E=2E= =2E=5D=3Cbr /=3EHowever=2C all protocols which utilize NTS-KE MUST confo= rm to the following two rules=3A=3Cbr /=3E=3Cbr /=3EThe disambiguating l= abel string MUST be =26quot=3BEXPORTER-network-timesecurity/1=26quot=3B=2E= =3Cbr /=3E=3Cbr /=3EThe per-association context value MUST be provided=2C= and MUST begin with the two-octet Protocol ID which was negotiated as a= Next Protocol=2E=3Cbr /=3E=5B=2E=2E=5D=3Cbr /=3E=3Cbr /=3EIndeed=2C at = the moment we use ID 0 for NTP=2E But w=3Cspan class=3D=22=22 id=3D=22re= sult=5Fbox=22 lang=3D=22en=22=3E=3Cspan class=3D=22=22=3Ehich ID is sele= cted when the server supports both protocols (IDs)=3F =3Cbr /=3E=3Cbr /=3E= =3Cbr /=3EBest regards=2C =3Cbr /=3EMartin=3Cbr /=3E=3Cbr /=3E=3C/span=3E= =3C/span=3E=3Cbr /=3E=3Cspan=3EAm 29=2E08=2E17 20=3A26 schrieb =3Cb clas= s=3D=22name=22=3EDaniel Franke =3C/b=3E =26lt=3Bdfoxfranke=40gmail=2Ecom= =26gt=3B=3A=3C/span=3E=3Cblockquote cite=3D=22mid=3ACAJm83bBjvnEtgTec0cq= =5FoSH4sSQzDO1FrxXZQ2xj3W=3DhRwE0hg=40mail=2Egmail=2Ecom=22 class=3D=22i= wcQuote=22 style=3D=22border-left=3A 1px solid =2300F=3B padding-left=3A= 13px=3B margin-left=3A 0=3B=22 type=3D=22cite=22=3E=3Cdiv class=3D=22mi= mepart text plain=22=3ESorry for overlooking this earlier=2E=3Cbr /=3E=3C= br /=3EOn 8/11/17=2C Martin Langer =26lt=3Bmart=2Elanger=40ostfalia=2Ede= =26gt=3B wrote=3A=3Cbr /=3E=3Cbr /=3E=26gt=3B 1=2E confusing term =26quo= t=3Bntp/4=26quot=3B=3Cbr /=3E=26gt=3B ----------------------------------= -------=3Cbr /=3E=26gt=3B =26quot=3Bntp/4=26quot=3B is the same term as = in the TLS ALPN extension (see=3A page 18=2C chapter=3Cbr /=3E=26gt=3B 8= )=3A=3Cbr /=3E=26gt=3B=3Cbr /=3E=26gt=3B =5B=2E=2E=2E=5D IANA is request= ed to allocate the following two entries in the=3Cbr /=3E=26gt=3B Applic= ation-Layer Protocol Negotation (ALPN) Protocol IDs registry=3A =5B=2E=2E= =2E=5D=3Cbr /=3E=26gt=3B Protocol=3A Network Time Protocol=2C version 4 = Identification Sequence=3A 0x6E=3Cbr /=3E=26gt=3B 0x74 0x70 0x2F 0x34 (=26= quot=3Bntp/4=26quot=3B) =5B=2E=2E=2E=5D=3Cbr /=3E=26gt=3B=3Cbr /=3E=26gt= =3B But the NTS Next Protocol Negotiation record contains IDs (e=2Eg=2E = 0x00 for=3Cbr /=3E=26gt=3B =27Network Time Protocol version 4=27=3B see = table at page 21) and not the term=3Cbr /=3E=26gt=3B =27ntp/4=27=2E This= can confusing some readers=2E=3Cbr /=3E=3Cbr /=3EYup=2C this is an outr= ight error=2E I=27ll fix it in Git momentarily=2E=3Cbr /=3E=3Cbr /=3E=26= gt=3B 2=2E Network Byte Order / Host Byte Order=3Cbr /=3E=3Cbr /=3E=26gt= =3B 3=2E general comment=3Cbr /=3E=26gt=3B -----------=3Cbr /=3E=26gt=3B= My first thought was=3A why=3F At first it was a magic number for me=2E= The=3Cbr /=3E=26gt=3B solution is here=3A chapter 5=2E2=3A=3Cbr /=3E=26= gt=3B =5B=2E=2E=2E=5D and MUST begin with the two-octet Protocol ID whic= h was negotiated as=3Cbr /=3E=26gt=3B a Next Protocol=2E =5B=2E=2E=2E=5D= =3Cbr /=3E=26gt=3B=3Cbr /=3E=26gt=3B I think this should be mentioned ag= ain or referenced to the corresponding=3Cbr /=3E=26gt=3B table (chapter = 8)=2E=3Cbr /=3E=3Cbr /=3EI=27ll edit to clarify these=2E=3Cbr /=3E=3Cbr = /=3E=26gt=3B 4=2E general comment=3Cbr /=3E=26gt=3B =3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3Cbr /=3E=26gt=3B=3Cbr /=3E=26gt=3B page 13 (chapter 6=2E= 5=2C 2nd section)=3A=3Cbr /=3E=26gt=3B ---------------------------------= --------=3Cbr /=3E=26gt=3B =5B=2E=2E=2E=5D This length requirement serve= s to ensure that the response will not be=3Cbr /=3E=26gt=3B larger than = the request=2C in order to improve timekeeping precision and=3Cbr /=3E=26= gt=3B =5B=2E=2E=2E=5D=3Cbr /=3E=26gt=3B=3Cbr /=3E=26gt=3B=3Cbr /=3E=26gt= =3B remark=3A=3Cbr /=3E=26gt=3B -----------=3Cbr /=3E=26gt=3B Does it re= ally improve the timekeeping=3F I think the idea is to reduce the=3Cbr /= =3E=26gt=3B asymmetry if the request and response message have the same = size=2E=3Cbr /=3E=26gt=3B But client and server may have different perfo= rmance and therefore the=3Cbr /=3E=26gt=3B processing speed per NTP Pack= age is different too=2E =2E=2E=2Eit=27s just a thought=3Cbr /=3E=3Cbr /=3E= I=27m led to believe Prof=2E Mills did some experiments at one point and= =3Cbr /=3Efound a non-zero impact from using asymmetrically-sized packet= s=2E I=3Cbr /=3Eguess a citation here would help=2E Harlan/Dave=2C do yo= u know of any=3Cbr /=3Eacademic reference I can point at to support this= claim=3F=3Cbr /=3E=3Cbr /=3E=3Cbr /=3E=26gt=3B 5=2E alternative proposa= l=3Cbr /=3E=26gt=3B =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3Cbr /=3E=26gt=3B= =3Cbr /=3E=26gt=3B page 20 (chapter 8=2C 1st section)=3A=3Cbr /=3E=26gt=3B= -----------------------------------------=3Cbr /=3E=26gt=3B =5B=2E=2E=2E= =5D Type Number (REQUIRED)=3A An integer in the range 0-32767 inclusive=3C= br /=3E=26gt=3B =5B=2E=2E=2E=5D=3Cbr /=3E=26gt=3B=3Cbr /=3E=26gt=3B=3Cbr= /=3E=26gt=3B better=3F=3A=3Cbr /=3E=26gt=3B -----------=3Cbr /=3E=26gt=3B= =5B=2E=2E=2E=5D Type Number (REQUIRED)=3A An 15 bit integer in the rang= e 0-32767=3Cbr /=3E=26gt=3B inclusive =5B=2E=2E=2E=5D=3Cbr /=3E=26gt=3B=3C= br /=3E=26gt=3B =2E=2E=2E=2Enot 16 bit=2C because we use a critical bit = in our records (first bit)=3Cbr /=3E=3Cbr /=3EI disagree that this is an= improvement=2E At best it=27s redundant since=3Cbr /=3E0-32767 already = covers the full range of possible 15-bit values=2E But=3Cbr /=3Emore imp= ortantly=2C we should be maintaining separation of concerns=3Cbr /=3Ebet= ween the IANA registry and the protocol specs which make reference=3Cbr = /=3Eto it=2E IANA is just recording the number=2E It=27s up to protocol=3C= br /=3Especification to define how it should be encoded=2E=3Cbr /=3E=3Cb= r /=3E=26gt=3B 6=2E some problems with =27The NTS Authenticator and Encr= ypted Extensions=3Cbr /=3E=26gt=3B extension=27 (page 14=2C chapter 6=2E= 6)=3Cbr /=3E=26gt=3B =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3Cbr /=3E=26gt= =3B=3Cbr /=3E=26gt=3B field description=3A=3Cbr /=3E=26gt=3B -----------= ------------------------------=3Cbr /=3E=26gt=3B =27Nonce lenght=27=3A W= e should mention that the value is to be interpreted as=3Cbr /=3E=26gt=3B= =27unsigned int=27=2E=3Cbr /=3E=3Cbr /=3EI agree=2E I=27ve just changed= this in git=2E=3Cbr /=3E=3Cbr /=3E=26gt=3B =27Nonce=27=3A At first I ha= d some trouble to understand where the nonce comes=3Cbr /=3E=26gt=3B fro= m and which length we use=2E Now I know it=2C but maybe we should add so= me=3Cbr /=3E=26gt=3B more information to this field=2E=3Cbr /=3E=26gt=3B= perhaps from these=3A =5B=2E=2E=2E=5D Nonce=3A a nonce as required by t= he negotiated AEAD=3Cbr /=3E=26gt=3B Algorithm=2E =5B=2E=2E=2E=5D to the= se=3A =5B=2E=2E=2E=5D Nonce=3A a new generated nonce whose length=3Cbr /= =3E=26gt=3B and format is determined by the negotiated AEAD algorithm (R= FC 5116=2C chapter=3Cbr /=3E=26gt=3B 3=2E2)=2E =5B=2E=2E=2E=5D=3Cbr /=3E= =3Cbr /=3EI don=27t quite like the wording you propose but I=27ll see if= I can make=3Cbr /=3Esome clarification along those lines=2E=3Cbr /=3E=3C= br /=3E=26gt=3B =27Chipertext=27=3A Some readers (students in my team) h= ad difficulties to=3Cbr /=3E=26gt=3B understand this field=2E All of the= m thought=2C that this field contains an=3Cbr /=3E=26gt=3B encrypted ver= sion of the whole NTP package=2E And this is wrong=2E I think the=3Cbr /= =3E=26gt=3B problem is this line=3A =5B=2E=2E=2E=5D authentication tag i= n addition to the actual=3Cbr /=3E=26gt=3B ciphertext=2E =5B=2E=2E=2E=5D= =2E Well=2C if readers do not know exactly how AEAD works=2C then=3Cbr /= =3E=26gt=3B this leads to strong understanding problems at this point=2C= since the terms=3Cbr /=3E=26gt=3B =27authentication tag=27 and =27ciphe= rtext=27 seem not known=2E I think we should add=3Cbr /=3E=26gt=3B a ref= erence (RFC 5116 --=26gt=3B AEAD) or some information about this terms=3C= br /=3E=26gt=3B (=27authentication tag=27 is like a MAC and =27ciphertex= t=27 contains optional=3Cbr /=3E=26gt=3B Extension Fields and can be abs= ent if no Extension Fields are encrypted=2E)=2E=3Cbr /=3E=26gt=3B Maybe = confuses the field name =27Chipertext=27 too=2E=3Cbr /=3E=3Cbr /=3EThe u= se of =27ciphertext=27 here comes straight out of RFC 5116=2C which in=3C= br /=3Eturn comes out of Rogaway=27s 2002 paper in which he coins =26quo= t=3BAEAD=26quot=3B=2E I=3Cbr /=3Eagree it=27s a little confusing if you=27= re not steeped in the relevant=3Cbr /=3Eliterature but I think any depar= ture from the RFC 5116 terminology=3Cbr /=3Ewould do more harm than good= =2E=3Cbr /=3E=3Cbr /=3E=26gt=3B=3Cbr /=3E=26gt=3B=3Cbr /=3E=26gt=3B =27P= adding=3A=27 This line=3A =5B=2E=2E=2E=5D so that implementations can un= ambiguously=3Cbr /=3E=26gt=3B delimit the end of the ciphertext from the= start of the padding =5B=2E=2E=2E=5D can be=3Cbr /=3E=26gt=3B difficult= to=2E In the beginning I did not know how this should work=2E We=3Cbr /= =3E=26gt=3B should say that implementations can read the last octet of t= his extension=3Cbr /=3E=26gt=3B content=2C to find out how big the paddi= ng is=2E=3Cbr /=3E=3Cbr /=3EFair enough=2E=3Cbr /=3E=3Cbr /=3E=26gt=3B F= urthermore we should change this line=3A=3Cbr /=3E=26gt=3B =5B=2E=2E=2E=5D= requirement that (in the absence of a legacy MAC) extensions have a=3Cb= r /=3E=26gt=3B total length in octets (including the four octets for the= type and length=3Cbr /=3E=26gt=3B fields) =5B=2E=2E=2E=5D=3Cbr /=3E=26g= t=3B=3Cbr /=3E=26gt=3B in this=3A=3Cbr /=3E=26gt=3B =5B=2E=2E=2E=5D requ= irement that (in the absence of a legacy MAC) NTP extensions have=3Cbr /= =3E=26gt=3B a total length in octets (including the four octets for the = type and length=3Cbr /=3E=26gt=3B fields) =5B=2E=2E=2E=5D=3Cbr /=3E=3Cbr= /=3EThis interacts somewhat with Harlan=27s request to say =26quot=3Bex= tension field=26quot=3B=3Cbr /=3Erather than just =26quot=3Bextension=26= quot=3B=2E=C2=A0 I=27ve done that now=2C and I=27ll go through=3Cbr /=3E= RFC 7822 again to make sure we=27re using consistent terminology in this= =3Cbr /=3Eand other places=2E=3Cbr /=3E=3Cbr /=3E=3Cbr /=3E=26gt=3B =5B=2E= =2E=2E=5D P=3A The plaintext SHALL consist of all (if any) extensions to= be=3Cbr /=3E=26gt=3B encrypted=2E =5B=2E=2E=2E=5D=3Cbr /=3E=26gt=3B=3Cb= r /=3E=26gt=3B Which format=3F Typical NTPv4 Extension Fields or another= format=3F We should=3Cbr /=3E=26gt=3B define that=2E We should also men= tion that only this content is encrypted (not=3Cbr /=3E=26gt=3B the cont= ent of parameter =27A=27)=2E=3Cbr /=3E=26gt=3B If we don=27t want encryp= t anything (default case)=2C then this parameter is=3Cbr /=3E=26gt=3B em= pty=2E=3Cbr /=3E=3Cbr /=3ETypcial NTPv4 EFs=2E I=27ll add a sentence or = two to clarify this=2E=3Cbr /=3E=3Cbr /=3E=26gt=3B Please let me know if= you have problems to understand my *english*=2E=3Cbr /=3E=3Cbr /=3EYour= English is completely fine=2E=3Cbr /=3E=3C/div=3E=3C/blockquote=3E --Boundary_(ID_T+Lb6Oqlh0eEORkb/+60rg)-- From ntp-bounces@ietf.org Thu Aug 31 06:26:56 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E7E0132E15; Thu, 31 Aug 2017 06:26:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1504186016; bh=gO6xWd2LkYUs4qqwMqxgdfTbdz28wV7i30rzJVCFoEU=; h=From:To:Date:In-reply-to:References:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc; b=TicdMgXBXjliMaoWsiTOlYIyeUCHqfByRhfCTKTvvBdyWAxvaaGiUFfiSP9OYGhDk xxbi2RtxDh7uprwdApN2cDqHpu241liI0NyZr6gocj/DV2cN7RqfEL4694IyHtvMET t9lQQ0myb4DsU0/uBs/UwmM+UecKnjgO0FYW2TVI= 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 82AA0132E03 for ; Thu, 31 Aug 2017 06:26:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sonia.de 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 1xPi7gZoPE_U for ; Thu, 31 Aug 2017 06:26:39 -0700 (PDT) Received: from mailgate1.sonia.de (mailgate1.sonia.de [141.41.1.242]) (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 7203D132E13 for ; Thu, 31 Aug 2017 06:26:18 -0700 (PDT) Received: from mailgate1.sonia.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 74B7213169; Thu, 31 Aug 2017 15:26:16 +0200 (CEST) Received: from mail.sonia.de (mail.sonia.de [141.41.8.70]) by mailgate1.sonia.de (Postfix) with ESMTP id 7AB3C13155; Thu, 31 Aug 2017 15:26:14 +0200 (CEST) MIME-version: 1.0 Received: from ostfalia.de ([141.41.8.70]) by mail.sonia.de (Oracle Communications Messaging Server 7.0.5.37.0 64bit (built Jan 25 2016)) with ESMTPA id <0OVJ00LKJXBQ1G00@mail.sonia.de>; Thu, 31 Aug 2017 15:26:14 +0200 (CEST) Received: from [141.41.8.91] (Forwarded-For: 141.41.8.91) by mail.sonia.de (mshttpd); Thu, 31 Aug 2017 15:26:14 +0200 From: Martin Langer To: Daniel Franke Message-id: <6f30da5ad29de.59a82a96@ostfalia.de> Date: Thu, 31 Aug 2017 15:26:14 +0200 X-Mailer: Oracle Communications Messenger Express 7.0.5.37.0 64bit (built Jan 25 2016) Content-language: de X-Accept-Language: de Priority: normal In-reply-to: References: <70a0c971b2978.598d965e@ostfalia.de> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sonia.de; h=mime-version:content-type:from:to:cc:message-id:date:subject:in-reply-to:references; s=20140129; bh=8cGn7scUhnjHCByICi0tCaaT/oMrEZlBUsUGcNF6nPo=; b=DXI5zDVREStbSlF/CbE5cPFsHASV8FOWrENOxwDF8dK3zOvZ3yilYacwYnsFu/oncZjqiLihd+RfC8wUKlFgbjWfJohr+/5E+Mchwn8JXf22gyHlnppwPPUrlgCZava2wY/QKf7RdDLDLLCETXSW8xsD7tD7JksQqqhom7b7oB4= Archived-At: Subject: Re: [Ntp] some comments on the NTS4NTP-Draft09 X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: ntp@ietf.org Content-Type: multipart/mixed; boundary="===============6267431790883443952==" Errors-To: ntp-bounces@ietf.org Sender: "ntp" This is a multi-part message in MIME format. --===============6267431790883443952== Content-type: multipart/alternative; boundary="Boundary_(ID_T+Lb6Oqlh0eEORkb/+60rg)" Content-language: de This is a multi-part message in MIME format. --Boundary_(ID_T+Lb6Oqlh0eEORkb/+60rg) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Content-disposition: inline Hello all, I'm back now. I have not managed to read all the mail, but thanks for the replies. I think I found another minor problem that I wanted to address. The following case: During the NTS-KE the client sends various record types to the server. The 'NTS Next Protocol Negotiation' record type contains 2 IDs (ID 0 for NTP/4 and ID 1 for PTP/2). The server will generate one or more cookies in the response message. To do this, the S2C and C2S key must be extracted first. Now in Section 5.2: [...] However, all protocols which utilize NTS-KE MUST conform to the following two rules: The disambiguating label string MUST be "EXPORTER-network-timesecurity/1". The per-association context value MUST be provided, and MUST begin with the two-octet Protocol ID which was negotiated as a Next Protocol. [..] Indeed, at the moment we use ID 0 for NTP. But which ID is selected when the server supports both protocols (IDs)? Best regards, Martin Am 29.08.17 20:26 schrieb Daniel Franke : > > Sorry for overlooking this earlier. > > On 8/11/17, Martin Langer wrote: > > > 1. confusing term "ntp/4" > > ----------------------------------------- > > "ntp/4" is the same term as in the TLS ALPN extension (see: page 18, chapter > > 8): > > > > [...] IANA is requested to allocate the following two entries in the > > Application-Layer Protocol Negotation (ALPN) Protocol IDs registry: [...] > > Protocol: Network Time Protocol, version 4 Identification Sequence: 0x6E > > 0x74 0x70 0x2F 0x34 ("ntp/4") [...] > > > > But the NTS Next Protocol Negotiation record contains IDs (e.g. 0x00 for > > 'Network Time Protocol version 4'; see table at page 21) and not the term > > 'ntp/4'. This can confusing some readers. > > Yup, this is an outright error. I'll fix it in Git momentarily. > > > 2. Network Byte Order / Host Byte Order > > > 3. general comment > > ----------- > > My first thought was: why? At first it was a magic number for me. The > > solution is here: chapter 5.2: > > [...] and MUST begin with the two-octet Protocol ID which was negotiated as > > a Next Protocol. [...] > > > > I think this should be mentioned again or referenced to the corresponding > > table (chapter 8). > > I'll edit to clarify these. > > > 4. general comment > > ============================================================ > > > > page 13 (chapter 6.5, 2nd section): > > ----------------------------------------- > > [...] This length requirement serves to ensure that the response will not be > > larger than the request, in order to improve timekeeping precision and > > [...] > > > > > > remark: > > ----------- > > Does it really improve the timekeeping? I think the idea is to reduce the > > asymmetry if the request and response message have the same size. > > But client and server may have different performance and therefore the > > processing speed per NTP Package is different too. ...it's just a thought > > I'm led to believe Prof. Mills did some experiments at one point and > found a non-zero impact from using asymmetrically-sized packets. I > guess a citation here would help. Harlan/Dave, do you know of any > academic reference I can point at to support this claim? > > > > 5. alternative proposal > > ============================================================ > > > > page 20 (chapter 8, 1st section): > > ----------------------------------------- > > [...] Type Number (REQUIRED): An integer in the range 0-32767 inclusive > > [...] > > > > > > better?: > > ----------- > > [...] Type Number (REQUIRED): An 15 bit integer in the range 0-32767 > > inclusive [...] > > > > ....not 16 bit, because we use a critical bit in our records (first bit) > > I disagree that this is an improvement. At best it's redundant since > 0-32767 already covers the full range of possible 15-bit values. But > more importantly, we should be maintaining separation of concerns > between the IANA registry and the protocol specs which make reference > to it. IANA is just recording the number. It's up to protocol > specification to define how it should be encoded. > > > 6. some problems with 'The NTS Authenticator and Encrypted Extensions > > extension' (page 14, chapter 6.6) > > ============================================================ > > > > field description: > > ----------------------------------------- > > 'Nonce lenght': We should mention that the value is to be interpreted as > > 'unsigned int'. > > I agree. I've just changed this in git. > > > 'Nonce': At first I had some trouble to understand where the nonce comes > > from and which length we use. Now I know it, but maybe we should add some > > more information to this field. > > perhaps from these: [...] Nonce: a nonce as required by the negotiated AEAD > > Algorithm. [...] to these: [...] Nonce: a new generated nonce whose length > > and format is determined by the negotiated AEAD algorithm (RFC 5116, chapter > > 3.2). [...] > > I don't quite like the wording you propose but I'll see if I can make > some clarification along those lines. > > > 'Chipertext': Some readers (students in my team) had difficulties to > > understand this field. All of them thought, that this field contains an > > encrypted version of the whole NTP package. And this is wrong. I think the > > problem is this line: [...] authentication tag in addition to the actual > > ciphertext. [...]. Well, if readers do not know exactly how AEAD works, then > > this leads to strong understanding problems at this point, since the terms > > 'authentication tag' and 'ciphertext' seem not known. I think we should add > > a reference (RFC 5116 --> AEAD) or some information about this terms > > ('authentication tag' is like a MAC and 'ciphertext' contains optional > > Extension Fields and can be absent if no Extension Fields are encrypted.). > > Maybe confuses the field name 'Chipertext' too. > > The use of 'ciphertext' here comes straight out of RFC 5116, which in > turn comes out of Rogaway's 2002 paper in which he coins "AEAD". I > agree it's a little confusing if you're not steeped in the relevant > literature but I think any departure from the RFC 5116 terminology > would do more harm than good. > > > > > > > 'Padding:' This line: [...] so that implementations can unambiguously > > delimit the end of the ciphertext from the start of the padding [...] can be > > difficult to. In the beginning I did not know how this should work. We > > should say that implementations can read the last octet of this extension > > content, to find out how big the padding is. > > Fair enough. > > > Furthermore we should change this line: > > [...] requirement that (in the absence of a legacy MAC) extensions have a > > total length in octets (including the four octets for the type and length > > fields) [...] > > > > in this: > > [...] requirement that (in the absence of a legacy MAC) NTP extensions have > > a total length in octets (including the four octets for the type and length > > fields) [...] > > This interacts somewhat with Harlan's request to say "extension field" > rather than just "extension". I've done that now, and I'll go through > RFC 7822 again to make sure we're using consistent terminology in this > and other places. > > > > [...] P: The plaintext SHALL consist of all (if any) extensions to be > > encrypted. [...] > > > > Which format? Typical NTPv4 Extension Fields or another format? We should > > define that. We should also mention that only this content is encrypted (not > > the content of parameter 'A'). > > If we don't want encrypt anything (default case), then this parameter is > > empty. > > Typcial NTPv4 EFs. I'll add a sentence or two to clarify this. > > > Please let me know if you have problems to understand my *english*. > > Your English is completely fine. > --Boundary_(ID_T+Lb6Oqlh0eEORkb/+60rg) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable Content-disposition: inline Hello all=2C=3Cbr /=3E=3Cbr /=3EI=27m back now=2E I have not managed to = read all the mail=2C but thanks for the replies=2E I think I found anoth= er =3Cspan class=3D=22=22 id=3D=22result=5Fbox=22 lang=3D=22en=22 tabind= ex=3D=22-1=22=3E=3Cspan class=3D=22=22=3Eminor problem that I wanted to = address=2E=3C/span=3E=3C/span=3E=3Cbr /=3E=3Cspan class=3D=22=22 id=3D=22= result=5Fbox=22 lang=3D=22en=22=3E=3Cspan class=3D=22=22=3E=3Cspan class= =3D=22=22 id=3D=22result=5Fbox=22 lang=3D=22en=22=3E=3Cspan class=3D=22=22= =3E=3C/span=3E=3C/span=3E=3Cspan class=3D=22=22 id=3D=22result=5Fbox=22 = lang=3D=22en=22=3E=3Cspan class=3D=22=22=3E=3Cspan class=3D=22short=5Fte= xt=22 id=3D=22result=5Fbox=22 lang=3D=22en=22=3E=3Cspan class=3D=22=22=3E= The following case=3A=C2=A0 =3C/span=3E=3C/span=3E=3C/span=3E=3C/span=3E= During the NTS-KE the client sends various record types to the server=2E= =3C/span=3E=3C/span=3E=3Cspan class=3D=22=22 id=3D=22result=5Fbox=22 la= ng=3D=22en=22=3E=3Cspan class=3D=22=22=3E=3Cspan class=3D=22short=5Ftext= =22 id=3D=22result=5Fbox=22 lang=3D=22en=22=3E=3Cspan class=3D=22=22=3E=3C= /span=3E=3C/span=3EThe =27NTS Next Protocol Negotiation=27 record type c= ontains 2 IDs (ID 0 for NTP/4 and ID 1 for PTP/2)=2E =3C/span=3E=3C/span= =3E=3Cspan class=3D=22=22 id=3D=22result=5Fbox=22 lang=3D=22en=22=3E=3Cs= pan=3EThe server will generate one or more cookies in the response messa= ge=2E=3C/span=3E =3Cspan class=3D=22=22=3E=3C/span=3E=3C/span=3E=3Cspan = class=3D=22=22 id=3D=22result=5Fbox=22 lang=3D=22en=22=3E=3Cspan class=3D= =22=22=3E=3Cspan class=3D=22short=5Ftext=22 id=3D=22result=5Fbox=22 lang= =3D=22en=22=3E=3Cspan class=3D=22alt-edited=22=3ETo do this=2C the =3C/s= pan=3E=3C/span=3E=3C/span=3E=3C/span=3E=3Cspan class=3D=22=22 id=3D=22re= sult=5Fbox=22 lang=3D=22en=22=3E=3Cspan class=3D=22=22=3E=3Cspan class=3D= =22short=5Ftext=22 id=3D=22result=5Fbox=22 lang=3D=22en=22=3E=3Cspan cla= ss=3D=22alt-edited=22=3E=3Cspan class=3D=22=22 id=3D=22result=5Fbox=22 l= ang=3D=22en=22=3E=3Cspan class=3D=22=22=3ES2C and C2S =3C/span=3E=3C/spa= n=3Ekey =3C/span=3E=3C/span=3E=3C/span=3E=3C/span=3E=3Cspan class=3D=22=22= id=3D=22result=5Fbox=22 lang=3D=22en=22=3E=3Cspan class=3D=22=22=3E=3Cs= pan class=3D=22=22 id=3D=22result=5Fbox=22 lang=3D=22en=22=3E=3Cspan cla= ss=3D=22=22=3E=3Cspan class=3D=22short=5Ftext=22 id=3D=22result=5Fbox=22= lang=3D=22en=22=3E=3Cspan class=3D=22alt-edited=22=3Emust be extracted = first=2E=3C/span=3E=3C/span=3E=3C/span=3E=3C/span=3E=3Cbr /=3E=3Cbr /=3E= =3C/span=3E=3C/span=3ENow in Section 5=2E2=3A=3Cbr /=3E=3Cbr /=3E=5B=2E=2E= =2E=5D=3Cbr /=3EHowever=2C all protocols which utilize NTS-KE MUST confo= rm to the following two rules=3A=3Cbr /=3E=3Cbr /=3EThe disambiguating l= abel string MUST be =26quot=3BEXPORTER-network-timesecurity/1=26quot=3B=2E= =3Cbr /=3E=3Cbr /=3EThe per-association context value MUST be provided=2C= and MUST begin with the two-octet Protocol ID which was negotiated as a= Next Protocol=2E=3Cbr /=3E=5B=2E=2E=5D=3Cbr /=3E=3Cbr /=3EIndeed=2C at = the moment we use ID 0 for NTP=2E But w=3Cspan class=3D=22=22 id=3D=22re= sult=5Fbox=22 lang=3D=22en=22=3E=3Cspan class=3D=22=22=3Ehich ID is sele= cted when the server supports both protocols (IDs)=3F =3Cbr /=3E=3Cbr /=3E= =3Cbr /=3EBest regards=2C =3Cbr /=3EMartin=3Cbr /=3E=3Cbr /=3E=3C/span=3E= =3C/span=3E=3Cbr /=3E=3Cspan=3EAm 29=2E08=2E17 20=3A26 schrieb =3Cb clas= s=3D=22name=22=3EDaniel Franke =3C/b=3E =26lt=3Bdfoxfranke=40gmail=2Ecom= =26gt=3B=3A=3C/span=3E=3Cblockquote cite=3D=22mid=3ACAJm83bBjvnEtgTec0cq= =5FoSH4sSQzDO1FrxXZQ2xj3W=3DhRwE0hg=40mail=2Egmail=2Ecom=22 class=3D=22i= wcQuote=22 style=3D=22border-left=3A 1px solid =2300F=3B padding-left=3A= 13px=3B margin-left=3A 0=3B=22 type=3D=22cite=22=3E=3Cdiv class=3D=22mi= mepart text plain=22=3ESorry for overlooking this earlier=2E=3Cbr /=3E=3C= br /=3EOn 8/11/17=2C Martin Langer =26lt=3Bmart=2Elanger=40ostfalia=2Ede= =26gt=3B wrote=3A=3Cbr /=3E=3Cbr /=3E=26gt=3B 1=2E confusing term =26quo= t=3Bntp/4=26quot=3B=3Cbr /=3E=26gt=3B ----------------------------------= -------=3Cbr /=3E=26gt=3B =26quot=3Bntp/4=26quot=3B is the same term as = in the TLS ALPN extension (see=3A page 18=2C chapter=3Cbr /=3E=26gt=3B 8= )=3A=3Cbr /=3E=26gt=3B=3Cbr /=3E=26gt=3B =5B=2E=2E=2E=5D IANA is request= ed to allocate the following two entries in the=3Cbr /=3E=26gt=3B Applic= ation-Layer Protocol Negotation (ALPN) Protocol IDs registry=3A =5B=2E=2E= =2E=5D=3Cbr /=3E=26gt=3B Protocol=3A Network Time Protocol=2C version 4 = Identification Sequence=3A 0x6E=3Cbr /=3E=26gt=3B 0x74 0x70 0x2F 0x34 (=26= quot=3Bntp/4=26quot=3B) =5B=2E=2E=2E=5D=3Cbr /=3E=26gt=3B=3Cbr /=3E=26gt= =3B But the NTS Next Protocol Negotiation record contains IDs (e=2Eg=2E = 0x00 for=3Cbr /=3E=26gt=3B =27Network Time Protocol version 4=27=3B see = table at page 21) and not the term=3Cbr /=3E=26gt=3B =27ntp/4=27=2E This= can confusing some readers=2E=3Cbr /=3E=3Cbr /=3EYup=2C this is an outr= ight error=2E I=27ll fix it in Git momentarily=2E=3Cbr /=3E=3Cbr /=3E=26= gt=3B 2=2E Network Byte Order / Host Byte Order=3Cbr /=3E=3Cbr /=3E=26gt= =3B 3=2E general comment=3Cbr /=3E=26gt=3B -----------=3Cbr /=3E=26gt=3B= My first thought was=3A why=3F At first it was a magic number for me=2E= The=3Cbr /=3E=26gt=3B solution is here=3A chapter 5=2E2=3A=3Cbr /=3E=26= gt=3B =5B=2E=2E=2E=5D and MUST begin with the two-octet Protocol ID whic= h was negotiated as=3Cbr /=3E=26gt=3B a Next Protocol=2E =5B=2E=2E=2E=5D= =3Cbr /=3E=26gt=3B=3Cbr /=3E=26gt=3B I think this should be mentioned ag= ain or referenced to the corresponding=3Cbr /=3E=26gt=3B table (chapter = 8)=2E=3Cbr /=3E=3Cbr /=3EI=27ll edit to clarify these=2E=3Cbr /=3E=3Cbr = /=3E=26gt=3B 4=2E general comment=3Cbr /=3E=26gt=3B =3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3Cbr /=3E=26gt=3B=3Cbr /=3E=26gt=3B page 13 (chapter 6=2E= 5=2C 2nd section)=3A=3Cbr /=3E=26gt=3B ---------------------------------= --------=3Cbr /=3E=26gt=3B =5B=2E=2E=2E=5D This length requirement serve= s to ensure that the response will not be=3Cbr /=3E=26gt=3B larger than = the request=2C in order to improve timekeeping precision and=3Cbr /=3E=26= gt=3B =5B=2E=2E=2E=5D=3Cbr /=3E=26gt=3B=3Cbr /=3E=26gt=3B=3Cbr /=3E=26gt= =3B remark=3A=3Cbr /=3E=26gt=3B -----------=3Cbr /=3E=26gt=3B Does it re= ally improve the timekeeping=3F I think the idea is to reduce the=3Cbr /= =3E=26gt=3B asymmetry if the request and response message have the same = size=2E=3Cbr /=3E=26gt=3B But client and server may have different perfo= rmance and therefore the=3Cbr /=3E=26gt=3B processing speed per NTP Pack= age is different too=2E =2E=2E=2Eit=27s just a thought=3Cbr /=3E=3Cbr /=3E= I=27m led to believe Prof=2E Mills did some experiments at one point and= =3Cbr /=3Efound a non-zero impact from using asymmetrically-sized packet= s=2E I=3Cbr /=3Eguess a citation here would help=2E Harlan/Dave=2C do yo= u know of any=3Cbr /=3Eacademic reference I can point at to support this= claim=3F=3Cbr /=3E=3Cbr /=3E=3Cbr /=3E=26gt=3B 5=2E alternative proposa= l=3Cbr /=3E=26gt=3B =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3Cbr /=3E=26gt=3B= =3Cbr /=3E=26gt=3B page 20 (chapter 8=2C 1st section)=3A=3Cbr /=3E=26gt=3B= -----------------------------------------=3Cbr /=3E=26gt=3B =5B=2E=2E=2E= =5D Type Number (REQUIRED)=3A An integer in the range 0-32767 inclusive=3C= br /=3E=26gt=3B =5B=2E=2E=2E=5D=3Cbr /=3E=26gt=3B=3Cbr /=3E=26gt=3B=3Cbr= /=3E=26gt=3B better=3F=3A=3Cbr /=3E=26gt=3B -----------=3Cbr /=3E=26gt=3B= =5B=2E=2E=2E=5D Type Number (REQUIRED)=3A An 15 bit integer in the rang= e 0-32767=3Cbr /=3E=26gt=3B inclusive =5B=2E=2E=2E=5D=3Cbr /=3E=26gt=3B=3C= br /=3E=26gt=3B =2E=2E=2E=2Enot 16 bit=2C because we use a critical bit = in our records (first bit)=3Cbr /=3E=3Cbr /=3EI disagree that this is an= improvement=2E At best it=27s redundant since=3Cbr /=3E0-32767 already = covers the full range of possible 15-bit values=2E But=3Cbr /=3Emore imp= ortantly=2C we should be maintaining separation of concerns=3Cbr /=3Ebet= ween the IANA registry and the protocol specs which make reference=3Cbr = /=3Eto it=2E IANA is just recording the number=2E It=27s up to protocol=3C= br /=3Especification to define how it should be encoded=2E=3Cbr /=3E=3Cb= r /=3E=26gt=3B 6=2E some problems with =27The NTS Authenticator and Encr= ypted Extensions=3Cbr /=3E=26gt=3B extension=27 (page 14=2C chapter 6=2E= 6)=3Cbr /=3E=26gt=3B =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3Cbr /=3E=26gt= =3B=3Cbr /=3E=26gt=3B field description=3A=3Cbr /=3E=26gt=3B -----------= ------------------------------=3Cbr /=3E=26gt=3B =27Nonce lenght=27=3A W= e should mention that the value is to be interpreted as=3Cbr /=3E=26gt=3B= =27unsigned int=27=2E=3Cbr /=3E=3Cbr /=3EI agree=2E I=27ve just changed= this in git=2E=3Cbr /=3E=3Cbr /=3E=26gt=3B =27Nonce=27=3A At first I ha= d some trouble to understand where the nonce comes=3Cbr /=3E=26gt=3B fro= m and which length we use=2E Now I know it=2C but maybe we should add so= me=3Cbr /=3E=26gt=3B more information to this field=2E=3Cbr /=3E=26gt=3B= perhaps from these=3A =5B=2E=2E=2E=5D Nonce=3A a nonce as required by t= he negotiated AEAD=3Cbr /=3E=26gt=3B Algorithm=2E =5B=2E=2E=2E=5D to the= se=3A =5B=2E=2E=2E=5D Nonce=3A a new generated nonce whose length=3Cbr /= =3E=26gt=3B and format is determined by the negotiated AEAD algorithm (R= FC 5116=2C chapter=3Cbr /=3E=26gt=3B 3=2E2)=2E =5B=2E=2E=2E=5D=3Cbr /=3E= =3Cbr /=3EI don=27t quite like the wording you propose but I=27ll see if= I can make=3Cbr /=3Esome clarification along those lines=2E=3Cbr /=3E=3C= br /=3E=26gt=3B =27Chipertext=27=3A Some readers (students in my team) h= ad difficulties to=3Cbr /=3E=26gt=3B understand this field=2E All of the= m thought=2C that this field contains an=3Cbr /=3E=26gt=3B encrypted ver= sion of the whole NTP package=2E And this is wrong=2E I think the=3Cbr /= =3E=26gt=3B problem is this line=3A =5B=2E=2E=2E=5D authentication tag i= n addition to the actual=3Cbr /=3E=26gt=3B ciphertext=2E =5B=2E=2E=2E=5D= =2E Well=2C if readers do not know exactly how AEAD works=2C then=3Cbr /= =3E=26gt=3B this leads to strong understanding problems at this point=2C= since the terms=3Cbr /=3E=26gt=3B =27authentication tag=27 and =27ciphe= rtext=27 seem not known=2E I think we should add=3Cbr /=3E=26gt=3B a ref= erence (RFC 5116 --=26gt=3B AEAD) or some information about this terms=3C= br /=3E=26gt=3B (=27authentication tag=27 is like a MAC and =27ciphertex= t=27 contains optional=3Cbr /=3E=26gt=3B Extension Fields and can be abs= ent if no Extension Fields are encrypted=2E)=2E=3Cbr /=3E=26gt=3B Maybe = confuses the field name =27Chipertext=27 too=2E=3Cbr /=3E=3Cbr /=3EThe u= se of =27ciphertext=27 here comes straight out of RFC 5116=2C which in=3C= br /=3Eturn comes out of Rogaway=27s 2002 paper in which he coins =26quo= t=3BAEAD=26quot=3B=2E I=3Cbr /=3Eagree it=27s a little confusing if you=27= re not steeped in the relevant=3Cbr /=3Eliterature but I think any depar= ture from the RFC 5116 terminology=3Cbr /=3Ewould do more harm than good= =2E=3Cbr /=3E=3Cbr /=3E=26gt=3B=3Cbr /=3E=26gt=3B=3Cbr /=3E=26gt=3B =27P= adding=3A=27 This line=3A =5B=2E=2E=2E=5D so that implementations can un= ambiguously=3Cbr /=3E=26gt=3B delimit the end of the ciphertext from the= start of the padding =5B=2E=2E=2E=5D can be=3Cbr /=3E=26gt=3B difficult= to=2E In the beginning I did not know how this should work=2E We=3Cbr /= =3E=26gt=3B should say that implementations can read the last octet of t= his extension=3Cbr /=3E=26gt=3B content=2C to find out how big the paddi= ng is=2E=3Cbr /=3E=3Cbr /=3EFair enough=2E=3Cbr /=3E=3Cbr /=3E=26gt=3B F= urthermore we should change this line=3A=3Cbr /=3E=26gt=3B =5B=2E=2E=2E=5D= requirement that (in the absence of a legacy MAC) extensions have a=3Cb= r /=3E=26gt=3B total length in octets (including the four octets for the= type and length=3Cbr /=3E=26gt=3B fields) =5B=2E=2E=2E=5D=3Cbr /=3E=26g= t=3B=3Cbr /=3E=26gt=3B in this=3A=3Cbr /=3E=26gt=3B =5B=2E=2E=2E=5D requ= irement that (in the absence of a legacy MAC) NTP extensions have=3Cbr /= =3E=26gt=3B a total length in octets (including the four octets for the = type and length=3Cbr /=3E=26gt=3B fields) =5B=2E=2E=2E=5D=3Cbr /=3E=3Cbr= /=3EThis interacts somewhat with Harlan=27s request to say =26quot=3Bex= tension field=26quot=3B=3Cbr /=3Erather than just =26quot=3Bextension=26= quot=3B=2E=C2=A0 I=27ve done that now=2C and I=27ll go through=3Cbr /=3E= RFC 7822 again to make sure we=27re using consistent terminology in this= =3Cbr /=3Eand other places=2E=3Cbr /=3E=3Cbr /=3E=3Cbr /=3E=26gt=3B =5B=2E= =2E=2E=5D P=3A The plaintext SHALL consist of all (if any) extensions to= be=3Cbr /=3E=26gt=3B encrypted=2E =5B=2E=2E=2E=5D=3Cbr /=3E=26gt=3B=3Cb= r /=3E=26gt=3B Which format=3F Typical NTPv4 Extension Fields or another= format=3F We should=3Cbr /=3E=26gt=3B define that=2E We should also men= tion that only this content is encrypted (not=3Cbr /=3E=26gt=3B the cont= ent of parameter =27A=27)=2E=3Cbr /=3E=26gt=3B If we don=27t want encryp= t anything (default case)=2C then this parameter is=3Cbr /=3E=26gt=3B em= pty=2E=3Cbr /=3E=3Cbr /=3ETypcial NTPv4 EFs=2E I=27ll add a sentence or = two to clarify this=2E=3Cbr /=3E=3Cbr /=3E=26gt=3B Please let me know if= you have problems to understand my *english*=2E=3Cbr /=3E=3Cbr /=3EYour= English is completely fine=2E=3Cbr /=3E=3C/div=3E=3C/blockquote=3E --Boundary_(ID_T+Lb6Oqlh0eEORkb/+60rg)-- --===============6267431790883443952== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp --===============6267431790883443952==-- From ntp-bounces@ietf.org Thu Aug 31 07:03:03 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B1C65132DFF; Thu, 31 Aug 2017 07:03:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1504188183; bh=8DSTCa+od8ztUQrD1iwF7hpKxlBlu4ktr581qJIfXkU=; h=Date:From:To:References:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc; b=FkeFnH7bkltTwoFrbO4P4IVkty/vIq3wHi7eDy1rGsxzyU6FlBHOmZ85MmpbPGOhT PC5ZrWjas+qi50R85mljoCd2NCzpftUGnQUrZpTtAtAmht06CQ5fhnJ5BXBcLDbrcb XW7EgXyth9eVfqftu5YsRZxFpQrUtgYYXfarF3bU= 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 0B16E132D8F; Thu, 31 Aug 2017 07:03:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 mtJ6RNmzpzmH; Thu, 31 Aug 2017 07:02:55 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AD9D132DF9; Thu, 31 Aug 2017 07:02:55 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 8395F7EA9C; Thu, 31 Aug 2017 14:02:54 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 8395F7EA9C Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=mlichvar@redhat.com Received: from localhost (unknown [10.43.2.117]) by smtp.corp.redhat.com (Postfix) with ESMTPS id AE1EF9ECEB; Thu, 31 Aug 2017 14:02:52 +0000 (UTC) Date: Thu, 31 Aug 2017 16:02:58 +0200 From: Miroslav Lichvar To: Daniel Franke Message-ID: <20170831140258.GV11067@localhost> References: <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> <20170831091427.GT11067@localhost> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.0 (2017-02-23) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Thu, 31 Aug 2017 14:02:54 +0000 (UTC) Archived-At: Subject: Re: [Ntp] WGLC for draft-ietf-ntp-using-nts-for-ntp X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "ntp@ietf.org" , "tictoc@ietf.org" , Karen O'Donoghue Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ntp-bounces@ietf.org Sender: "ntp" On Thu, Aug 31, 2017 at 08:34:02AM -0400, Daniel Franke wrote: > Lots of people on this list seem to have the intuition that sending > time packets over DTLS can never be as accurate as sending them over > the NTP port with an authenticator attached. But as I showed in my > analysis the other day, that just ain't so. The problem is not with transmission. The problem as I see it is with transport and reception. Encryption prevents modifications of the packet in the network, which will be needed for delay corrections. A different port number will not work with existing QoS in switches/routers and hardware timestamping in NICs. I'm sure in some cases reconfiguration to handle both ports will be possible, but there is HW where the port number is hardcoded in the firmware or silicon. If there is a rarely used port for timing messages, will everyone support it? I doubt that. The symmetric mode will not get all benefits of NTP support. If DTLS records were exchanged in NTP packets in extension fields, as was originally considered by the design group, this wouldn't be a problem. > > My recommendation is to remove the specification of NTS in the symmetric > > mode from the document, at least for now. I believe the NTS-KE used in > > the client/server mode can be adopted for the symmetric mode, possibly > > with some small extensions, but it will take time. I think most of us > > here will agree it shouldn't delay the adoption of NTS in the > > client/server mode. > > If specification for symmetric mode were removed, how would section 4 > read? Do you want to get rid of DTLS encapsulation altogether? > Restrict what traffic can be sent over it? Can you send a PR with what > you have in mind? (Won't promise to merge it, but I'll review it) I'm not sure. I think the whole section could be limited to the control (6) mode. The other modes (1, 2, 3, 4, 5, 7) can be allowed, but not recommended. In the broadcast mode I think it doesn't make much sense anyway. > The > identity in that certificate is the additional information you're > looking for. Ok, thanks. -- Miroslav Lichvar _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp From nobody Thu Aug 31 07:03:08 2017 Return-Path: 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 0B16E132D8F; Thu, 31 Aug 2017 07:03:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 mtJ6RNmzpzmH; Thu, 31 Aug 2017 07:02:55 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AD9D132DF9; Thu, 31 Aug 2017 07:02:55 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 8395F7EA9C; Thu, 31 Aug 2017 14:02:54 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 8395F7EA9C Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=mlichvar@redhat.com Received: from localhost (unknown [10.43.2.117]) by smtp.corp.redhat.com (Postfix) with ESMTPS id AE1EF9ECEB; Thu, 31 Aug 2017 14:02:52 +0000 (UTC) Date: Thu, 31 Aug 2017 16:02:58 +0200 From: Miroslav Lichvar To: Daniel Franke Cc: Karen O'Donoghue , "ntp@ietf.org" , "tictoc@ietf.org" Message-ID: <20170831140258.GV11067@localhost> References: <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> <20170831091427.GT11067@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.0 (2017-02-23) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Thu, 31 Aug 2017 14:02:54 +0000 (UTC) Archived-At: Subject: Re: [Ntp] WGLC for draft-ietf-ntp-using-nts-for-ntp X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 14:03:01 -0000 On Thu, Aug 31, 2017 at 08:34:02AM -0400, Daniel Franke wrote: > Lots of people on this list seem to have the intuition that sending > time packets over DTLS can never be as accurate as sending them over > the NTP port with an authenticator attached. But as I showed in my > analysis the other day, that just ain't so. The problem is not with transmission. The problem as I see it is with transport and reception. Encryption prevents modifications of the packet in the network, which will be needed for delay corrections. A different port number will not work with existing QoS in switches/routers and hardware timestamping in NICs. I'm sure in some cases reconfiguration to handle both ports will be possible, but there is HW where the port number is hardcoded in the firmware or silicon. If there is a rarely used port for timing messages, will everyone support it? I doubt that. The symmetric mode will not get all benefits of NTP support. If DTLS records were exchanged in NTP packets in extension fields, as was originally considered by the design group, this wouldn't be a problem. > > My recommendation is to remove the specification of NTS in the symmetric > > mode from the document, at least for now. I believe the NTS-KE used in > > the client/server mode can be adopted for the symmetric mode, possibly > > with some small extensions, but it will take time. I think most of us > > here will agree it shouldn't delay the adoption of NTS in the > > client/server mode. > > If specification for symmetric mode were removed, how would section 4 > read? Do you want to get rid of DTLS encapsulation altogether? > Restrict what traffic can be sent over it? Can you send a PR with what > you have in mind? (Won't promise to merge it, but I'll review it) I'm not sure. I think the whole section could be limited to the control (6) mode. The other modes (1, 2, 3, 4, 5, 7) can be allowed, but not recommended. In the broadcast mode I think it doesn't make much sense anyway. > The > identity in that certificate is the additional information you're > looking for. Ok, thanks. -- Miroslav Lichvar From nobody Thu Aug 31 10:14:40 2017 Return-Path: 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 B16EB132E22 for ; Thu, 31 Aug 2017 10:14:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 7Ml7xy7QTsOW for ; Thu, 31 Aug 2017 10:14:34 -0700 (PDT) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (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 65D4C132DF8 for ; Thu, 31 Aug 2017 10:14:34 -0700 (PDT) Received: by mail-io0-x22b.google.com with SMTP id n71so2495360iod.1 for ; Thu, 31 Aug 2017 10:14:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=0grU66qZYX4pLBnbTvsP0qt+njhlO4wkv96rrz1iJJI=; b=UtSNVR6kO5kKfAfPgUCxp25p9qFyuQJ3gQMeHUcqvNYEizmpFYbL5+v78vlSgUUXsA yJlrfMqOUHFYeHBD+Ygg94FxuZ7e5nlJGF+ChBaPVoyuV8I54iI8zPBYCS68dAIeDuMJ GVCpe6ldxYk/oeLg/WgMnbh5G7qmPYekkJoE65cVRw4nM6unqk4Kk3ZIsP8sdya1JmoW eAHyCIgIDs5ZJfOpcYl/1HS3bsXW12lHgQEzefjDttVxGFt9fv+2MoUQysgpfSY1guxI 7qNULzqq4e6zesHcA/jGEx9J/p+xcsXTmuEUpH74cTScUxhE7SWwNTiv1KYtg6hzJBpr f00A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=0grU66qZYX4pLBnbTvsP0qt+njhlO4wkv96rrz1iJJI=; b=pZ9y8/k5LRszy/4ZXHot/lNo7GiZhpQssfd+Pp9YAFBu5BXN59UHjNQKWZRhoyGk4+ EHUIqCUjQQ7AYiLtRy5pI6SOUpOPGiWrhlaWnKOasLq46MsUbqgYJX6LnIfU1XZ+/IX9 HzwfvhcwBbL1wF1h3mPKX/9KrxKUva+E0UclkrdQhtE/198+/BtWcWpgUlvR67t7rRSq vUnQKWfIchIXMreMGqND/IhK9Y1kJ4vD/84ybM/eTp8X9VYhmru/yBvHY1473MZ/eyI1 NfJE8ZXqdVMakUSSPxw51S2T7WYx/nPsGjykiXoPAuFTzvud2hpskOrAmOb2vP2D8EWK zXhg== X-Gm-Message-State: AHPjjUh8gcAZ4qZskfQA3z+l94fYgpyMV374E7L54lqGF2Zi7Uf3i/fP Si7UvJtTqB32PNUATtvBjVWy9HnF7KEh X-Google-Smtp-Source: ADKCNb4UCYJ1GXwO/INZQcH44e1rtnr8c8EvVyA3MCME0ZjAsyeguo8O2sKTFqnC/G8HebbLvraDntfz6k9VYK40Av4= X-Received: by 10.107.134.210 with SMTP id q79mr5459554ioi.259.1504199672946; Thu, 31 Aug 2017 10:14:32 -0700 (PDT) MIME-Version: 1.0 Sender: sharon.goldbe@gmail.com Received: by 10.107.155.195 with HTTP; Thu, 31 Aug 2017 10:13:52 -0700 (PDT) From: Sharon Goldberg Date: Thu, 31 Aug 2017 13:13:52 -0400 X-Google-Sender-Auth: MBkGOjiEDYUmQSJOM2zfhKMUbOk Message-ID: To: ntp@ietf.org Content-Type: multipart/alternative; boundary="001a113ff92c2d667b05580fc735" Archived-At: Subject: [Ntp] Sharon Goldberg comments on draft-ietf-ntp-using-nts-for-ntp X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 17:14:38 -0000 --001a113ff92c2d667b05580fc735 Content-Type: text/plain; charset="UTF-8" Review of NTS. First of all, I wanted to congratulate Daniel, Dieter, and Kristof on the great progress made with this draft. This is great work, and much improved since the last WGLC for NTS. My comments, in linear order after reading through the draft that was in GitHub 4 hours ago, are below. https://github.com/dfoxfranke/nts/commit/5835e584cff6b224335 0fd6e8cd8cb3808d58c5d This is a fairly detailed review, that raises several issues. That said, I still don't have a complete understanding of how the client-server NTS protocol works or of its security properties, and would like to give it another read after the authors have edited the draft to clarify some of the issues I read below. Thanks, Sharon **** Section 1.1: The unlinkablilty objective, as written, is misleading. NTS only promises to not leak more linkability information that what is already being leaked by NTP. As written that reader could assume that NTS promises to fully guarantee unlinkability, which is false, since NTP could make the session linkable. It's not sufficient to bury this point in the security considerations section, so this should be reworded. **** Section 1.2: Says: However, client-server mode also has more relaxed security needs, because only the client requires replay protection: it is harmless for servers to process replayed packets. This is false. It can be harmful for a server to process replayed packets if that server keeps client state in order to perform rate limiting with a KoD. Specifically, an adversary can replay client packets at high rate to the server, in order to trigger rate-limint restrictions at the server and cause the server to send a "RATE" KoD to the client. Once the client receives this KoD, it will slow down or even stop its communications with the server. In other words, this is a DoS attack. This is CVE-2015-7705 which we called the "priming the pump" attack in our NDSS'15 paper: https://eprint.iacr.org/2015/1020.pdf Thus, I suggest that the draft include some language targeted at servers that do perform rate limiting with the KoD. Those servers MAY take advantage of NTS's replay protection to stop the Priming the Pump attack. In other words, these servers MAY track the client's unique identifiers and making sure that they are not reused, as a way of preventing the priming the pump attack. I am suggesting the use of MAY because this can be resource intensive for the server. (But, a data structure like a bloom filter could be used to minimize the overhead at the server of checking uniqueness of "unique identifiers"). I also suggest adding some text to the security considerations, explaining that when the server uses (1) rate limiting with the KoD but (2) does not use NTS's replay protections, then the server is vulnerable to the Priming the Pump attack of CVE-2015-7705. **** Page 5: "As previously stated, DTLS-encapsulated NTPv4 is trivial. The communicating parties establish a DTLS session and then exchange arbitrary NTP packets as DTLS Application Data." Nit: It's probably best to avoid judgement calls ("trivial") here. **** Section 4: Regarding security of the control mode: For control mode (6), the party sending queries should be the DTLS client and the party responding to the queries should be the DTLS server. I think we are missing an opportunity here to secure the control mode, and I'm not convinced that DTLS is the right approach. I would like to see this draft specify some way for servers to require client authentication before answering control queries. Why are we not considering the use of SSH? It makes much more sense to have the machine that sends the control query authenticate itself to the responding machine. That way, arbitrary attackers cannot just query the server and learn sensitive information about its state (or even modify its state using a write command). If we do think we are gaining something by securing the control mode with DTLS, the draft should spell out exactly what this security property is. **** Section 4. The description of symmetric mode operation is underspecified. I read it several times and I don't understand how it works. The draft says: For symmetric operation between an active (mode 1) and passive (mode 2) peer, the active peer should be the DTLS client and the passive peer should be the DTLS server. For symmetric operation between two active (mode 1) peers, both parties should attempt to initiate a DTLS session with their peer. If one handshake fails and the other succeeds, the successfully- established session should be used for traffic in both directions. If both handshakes succeed, either session may be used and packets should receive identical disposition regardless of which of the two sessions they arrived over. Inactive sessions may be timed out but the redundant session should not be proactively closed. I don't understand how two DLTS associations are used at the same time, given that symmetric mode uses a single request-response ladder for both peers to derive the time. I also don't understand the last sentence quoted above. What does proactively mean? Under what conditions should you actually close the session? Miroslav made this comment already, and I know that Daniel is current updating this text (have not seen this update yet) but I wanted to support Miroslav's concerns. **** Section 5: Nit: Immediately following a successful handshake, the client SHALL send a single request (as Application Data encapsulated in the TLS-protected channel), then the server SHALL send a single response followed by a TLS "Close notify" alert and then discard the channel state. Maybe change this "MUST discard the channel state" (or SHOULD)? In order to minimize the attack surface of someone compromising the server and then using the old channel state that is sitting around in order to launch attacks. That said, if there is a good reason to keep the channel state, maybe the draft should specify what that reasoning is. (I'm struggling to understand why anyone would want to keep the channel state around.) ****** Section 5: As a point of presentation: I had trouble getting a high level view of the protocol from reading Section 5. Some issues confused me that I think should be defined up front. In other words, I think Section 5 should start with some prose (even a new subsection) that gives a detailed overview of the protocol. Pointing out some specific confusions of mine. - There are several "numbers" defined in this document, and it is hard for the reader to disambiguate between them. Specifically, there is the "Next Protocol number" and the "Field Type" and the "Record Number". The start of Section 5 should start by telling the reader what are the different "fields" and "types", and each of their purposes. I also suggest providing references to the relevant IANA Considerations in Section 8. - This section would benefit by showing a ladder presenting the sequence of communications and message types that go back and forth during a typical NTS exchange. - I'm not clear if the C, record type, and body length fields depicted in Figure 1 need to be authenticated by the AEAD authenticator. Maybe this should be spelled out more clearly. **** Nowhere in the document do a see an explicit statement about when the client is allowed to start taking time from an NTS-secured server. I think the draft should spell this out, at the very minimum with a SHOULD requirement, and possibly even a MUST. To do this, it would help to have a ladder that shows the protocol flow, and spells out in what point in the flow the client can start taking time. **** Error codes: I'm worried about the error messages defined in Section 5.1.3 and warning in 5.1.4. Specifically I am worried that they could be used a attack vector for DoSing the client. My worry comes because, unless I misunderstood the draft, it looks like the client can act on an unauthenticated error code. That is, the client will tear down an NTS association upon receipt of the error message (error code 1). I worry that an off-path attacker can use this to maliciously cause the client to tear down an association (by injecting a bogus error packet to the client). One way to prevent this is to force the client to validated the unique identifier extension on the error packet. However, I cannot tell from the draft whether or not the client is required to do this. If the intention of the draft is *not* to prevent this attack, then it should be spelled out in the security considerations section. If the draft is preventing this attack, then this shoudl be explained more clearly. A similar issue is whether an on-path attacker (that can eavesdrop and inject packets but not drop or modify packets, (note: this is the threat model for the great firewall of china)) can inject error messages. This sort of attacker, that does not have the power to drop packets, can still inject error messages in order to tear down NTS connections. And, since this attacker can eavesdrop, the unique identifier field will not thwart this attack. If the intention of the draft is not to prevent this attack, then this should be spelled out in the security considerations section. Alternatively, if I misunderstood the draft, then the draft should be edited to clear up my misunderstanding. That is, there should be an explicit statement in Section 5.1.4 and 5.1.3 about whether or not the client can act on an unauthenticated error message, and whether or not the unique id field of the error message needs to be validated. **** A similar issue on error messages: Why does NTS have both error messages, but also uses the NTS NAK in a kiss of death packet? My preference is for a simpler protocol that has only 1 type of error message. Why doesn't just one type suffice? If there is a reason to have two types of error messages, then the draft should more clearly explain the use case for each type. Note also that as written, per page 17, the NTS NAK can be exploited by the on-path attacker (that can eavesdrop and inject packets but not drop or modify packets) in order to DoS the client, as I described above. Thus, at the very least, the security considerations of this draft should acknowledge this attack. ***** Nit: Section 5.1.4, I raised this point earlier when I talked about the need for an overview of the protocol and a ladder at the start of Section 5. To reiterate. I don't understand what it means to "proceed to the Next Protocol". **** 5.1.5 says: Server implementations of NTS extension fields for NTPv4 (Section 6) MUST support AEAD_AES_SIV_CMAC_256 [RFC5297] (Numeric Identifier 15). That is, if the client includes AEAD_AES_SIV_CMAC_256 in its AEAD Algorithm Negotiation record, and the server accepts Protocol ID 0 (NTPv4); in its NTS Next Protocol Negotiation record, then the server's AEAD Algorithm Negotiation record MUST NOT be empty. Question: Does this mode of operation include any restrictions on how many messages can be encrypted and authenticated? If so, this draft should respect this restriction and require rekeying after that number of message. If not, this draft should point to the place in RFC5297 where it says that there is no such restriction, or point out that the restriction is sufficiently high that we can never expect to exceed it. (NOTE: I did not have time, while preparing this review, to understand this AEAD_AES_SIV_CMAC_256 mode of operation, so I am raising this question for Daniel to answer.) Also, does the fact that RFC5297 is informational, while this draft is standards track, create any issues for us? ***** 5.1.6 Cookies. Earlier on this list there was discussion on whether or not the draft should specify normative requirements on cookies. Personally, I support that view that we should place normative requirements on cookies, because an insecure cookie implementation would break the security of the whole protocol. That said, what is a show stopper in my opinion, is a lack of specification in the draft of what properties are required from the cookie. At the very least, we want to make sure that the cookie does not leak the C2S and S2C keys to an observer (or a man in the middle). If I have misunderstood, and this confidentiality is provided because the cookie is encrypted (as a MUST) by the AEAD scheme, then the draft should make this point more clear in section 5.1.6. Also, is there a requirement that cookies be different across different clients? That each cookie used by a client is unique? At the very least these requirements should be spelled out as a MUST somewhere. If SHOULD is used, then a discussion of the risks of not adhering to these requirements should be provided. If this is somewhere in the draft already, and I missed then, then apologies. But this text should be referenced in Section 5.1.6. ****** Section 6.3 I like this section a lot but suggest the text below be edited from: The Unique Identifier extension field has a Field Type of [[TBD2]]. When the extension field is included in a client packet (mode 3), its body SHALL consist of a string of octets generated uniformly at random. The string SHOULD be 32 octets long. to "The string MUST be at least 32 octets long." *** Section 6, final comment. I read this section a few time, but I still don't have a great picture in my head of how this protocol works and how it acheives its security goals. I would like to give it another read once it is updated to address my comments. ***** I did not review Section 8 in detail. **** Section 9: Section 9.1: I like this section very much. But it would help to also have some discussion about how NTS prevents the control mode from being exploited for DoS, since this is the main vector that NTP DoS amplification attacks exploit. That said, I don't think this draft goes far enough regarding the security of the control mode, as I mentioned in an earlier comment. Section 9.2: Verification of Server Certificates: I also like this section very much. Some clarification questions: The following paragraph should include some citations, so that readers can better understand why the check works. As written it is too implementation dependent. There should be a cite to what NTP_PHASE_MAX means and what ntp_gettime() is expected to return. Check whether the system time is in fact unreliable. If the system clock has previously been synchronized since last boot, then on operating systems which implement a kernel-based phase- locked-loop API, a call to ntp_gettime() should show a maximum error less than NTP_PHASE_MAX. In this case, the clock should be considered reliable and certificates can be strictly validated. In the paragraph below, the term "strictly validated" needs to defined. Is this paragraph suggesting validating time with a human? Or somethign else? Allow the system administrator to specify that certificates should *always* be strictly validated. Such a configuration is appropriate on systems which have a battery-backed clock and which can reasonably prompt the user to manually set an approximately- correct time if it appears to be needed. The following two recommendations are so important. I think the draft should elevate these recommendation to SHOULD and put it the TLS profile section, rather than bury it in the security considerations section: Once the clock has been synchronized, periodically write the current system time to persistent storage. Do not accept any certificate whose notAfter field is earlier than the last recorded time. Do not process time packets from servers if the time computed from them falls outside the validity period of the server's certificate. Section 9.4: (Delay attacks) I think the following sentence is false: However, the maximum error that an adversary can introduce is bounded by half of the round trip delay. Why cannot an adversary delay the query an indefinate amount of time, and then send it to the server, and then pass on the server's response? Eg delay the query 1 hour, then send to the server, then let the response pass by you unmolested. The error here would be huge (1 hour on the forward path, and ms on the reverse path). Similarly I don't understand why the second paragraph of Section 9.4 is true. [RFC5905] specifies a parameter called MAXDIST which denotes the maximum round-trip latency (including not only the immediate round trip between client and server but the whole distance back to the reference clock as reported in the Root Delay field) that a client will tolerate before concluding that the server is unsuitable for synchronization. The standard value for MAXDIST is one second, although some implementations use larger values. Whatever value a client chooses, the maximum error which can be introduced by a delay attack is MAXDIST/2. I suggest cutting both of these from the draft. Even if they were correct, I don't think are important for the draft. It's probably not worth while for us to argue about them. Section 9.5, suggested rewording: Whenever this draft specifies the use of random numbers, then cryptographically secure random number generation MUST be used. See [RFC4086] for guidelines concerning this topic. (I am worried about implementations that eg. will use ntp_random() which is not cryptographically secure.) Section 10.4 I like the MUST requirement here about implementation of ntp-data-minimization. Given the amount of protocol mechanisms and complexity we have introduced in order to provide unlinkability, its important to also require that devices adhere to ntp-data-minimization if they actually want unlinkability. Also for this paragraph: It should also be noted that it could be possible to link devices that operate as time servers from their time synchronization traffic, using information exposed in (mode 4) server response packets (e.g. reference ID, reference time, stratum, poll). Also, devices that respond to NTP control queries could be linked using the information revealed by control queries. Suggested expansion: It should also be noted that it could be possible to link devices that operate as time servers from their time synchronization traffic, using information exposed in (mode 4) server response packets (e.g. reference ID, reference time, stratum, poll). Devices that do not wish to be linked in this way SHOULD NOT respond to (mode 3) client query packets from unknown IP addresses. Also, devices that respond to NTP control queries could be linked using the information revealed by control queries. Devices that do not wish to be linked in this way SHOULD NOT respond to control query packets from unknown IP addresses. Thanks for reading this far :) -- Sharon Goldberg Computer Science, Boston University http://www.cs.bu.edu/~goldbe --001a113ff92c2d667b05580fc735 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Review of NTS.

First of all,= I wanted to congratulate Daniel, Dieter, and Kristof on the great progress= made with this draft. This is great work, and much improved since the last= WGLC for NTS. =C2=A0

My comments, in linear order= after reading through the draft that was in GitHub 4 hours ago, are below.=

=C2=A0
This is a fairly detailed review, t= hat raises several issues.=C2=A0 That said, I still don't have a comple= te understanding of how the client-server NTS protocol works or of its secu= rity properties, and would like to give it another read after the authors h= ave edited the draft to clarify some of the issues I read below.
=
Thanks,
Sharon

****
=

Section 1.1: The unlinkablilty objective, as written, i= s misleading. NTS only promises to not leak more linkability information th= at what is already being leaked by NTP. =C2=A0 As written that reader could= assume that NTS promises to fully guarantee unlinkability, which is false,= since NTP could make the session linkable.=C2=A0 It's not sufficient t= o bury this point in the security considerations section, so this should be= reworded.

****

Section 1= .2: =C2=A0Says:=C2=A0

=C2=A0 =C2=A0 However, clien= t-server mode also has more
=C2=A0 =C2=A0relaxed security needs, = because only the client requires replay
=C2=A0 =C2=A0protection: = it is harmless for servers to process replayed packets.
=C2=A0 = =C2=A0
This is false.=C2=A0

It can be ha= rmful for a server to process replayed packets if that server keeps client = state in order to perform rate limiting with a KoD. Specifically, an advers= ary can replay client packets at high rate to the server, in order to trigg= er rate-limint restrictions at the server and cause the server to send a &q= uot;RATE" KoD to the client. Once the client receives this KoD, it wil= l slow down or even stop its communications with the server.=C2=A0 In other= words, this is a DoS attack. =C2=A0

This is CVE-2= 015-7705 which we called the "priming the pump" =C2=A0attack in o= ur NDSS'15 paper:


Thus, I suggest that the draft include= some language targeted at servers that do perform rate limiting with the K= oD.=C2=A0 Those servers MAY take advantage of NTS's replay protection t= o stop the Priming the Pump attack.=C2=A0 In other words, these servers MAY= track the client's unique identifiers and making sure that they are no= t reused, as a way of preventing the priming the pump attack. I am suggesti= ng the use of MAY because this can be resource intensive for the server. = =C2=A0(But, a data structure like a bloom filter could be used to minimize = the overhead at the server of checking uniqueness of "unique identifie= rs").

I also suggest adding some text to the = security considerations, explaining that when the server uses (1) rate limi= ting with the KoD but (2) does not use NTS's replay protections, then t= he server is vulnerable to the Priming the Pump attack of CVE-2015-7705.

****

Page 5: "As previ= ously stated, DTLS-encapsulated NTPv4 is trivial.=C2=A0 The
=C2= =A0 =C2=A0communicating parties establish a DTLS session and then exchange<= /div>
=C2=A0 =C2=A0arbitrary NTP packets as DTLS Application Data."= ;
=C2=A0 =C2=A0
Nit: It's probably best to avoid ju= dgement calls ("trivial") here.=C2=A0

**= **

Section 4: Regarding security of the control mo= de:

=C2=A0 =C2=A0For control mode (6), the party s= ending queries should be the DTLS
=C2=A0 =C2=A0client and the par= ty responding to the queries should be the DTLS
=C2=A0 =C2=A0serv= er.

I think we are missing an opportunity here to = secure the control mode, and I'm not convinced that DTLS is the right a= pproach. =C2=A0

I would like to see this draft spe= cify some way for servers to require client authentication before answering= control queries.

Why are we not considering the u= se of SSH? It makes much more sense to have the machine that sends the cont= rol query authenticate itself to the responding machine. That way, arbitrar= y attackers cannot just query the server and learn sensitive information ab= out its state (or even modify its state using a write command).
<= br>
If we do think we are gaining something by securing the contr= ol mode with DTLS, the draft should spell out exactly what this security pr= operty is.=C2=A0

****

Sec= tion 4. The description of symmetric mode operation is underspecified. I re= ad it several times and I don't understand how it works.=C2=A0 The draf= t says:

=C2=A0 =C2=A0For symmetric operation betwe= en an active (mode 1) and passive (mode
=C2=A0 =C2=A02) peer, the= active peer should be the DTLS client and the passive
=C2=A0 =C2= =A0peer should be the DTLS server.

=C2=A0 =C2=A0Fo= r symmetric operation between two active (mode 1) peers, both
=C2= =A0 =C2=A0parties should attempt to initiate a DTLS session with their peer= .
=C2=A0 =C2=A0If one handshake fails and the other succeeds, the= successfully-
=C2=A0 =C2=A0established session should be used fo= r traffic in both directions.
=C2=A0 =C2=A0If both handshakes suc= ceed, either session may be used and packets
=C2=A0 =C2=A0should = receive identical disposition regardless of which of the two
=C2= =A0 =C2=A0sessions they arrived over.=C2=A0 Inactive sessions may be timed = out but
=C2=A0 =C2=A0the redundant session should not be proactiv= ely closed.
=C2=A0
I don't understand how two DLTS = associations are used at the same time, given that symmetric mode uses a si= ngle request-response ladder for both peers to derive the time.
<= br>
I also don't understand the last sentence quoted above.= =C2=A0 What does proactively mean? Under what conditions should you actuall= y close the session?

Miroslav made this comment al= ready, and I know that Daniel is current updating this text (have not seen = this update yet) but I wanted to support Miroslav's concerns.

****

Section 5:

Nit: =C2=A0

=C2=A0 =C2=A0 Immediately follo= wing a successful handshake, the
=C2=A0 =C2=A0client SHALL send a= single request (as Application Data encapsulated
=C2=A0 =C2=A0in= the TLS-protected channel), then the server SHALL send a single
= =C2=A0 =C2=A0response followed by a TLS "Close notify" alert and = then discard the
=C2=A0 =C2=A0channel state.

=
Maybe change this "MUST discard the channel state" (or SHOUL= D)? =C2=A0 In order to minimize the attack surface of someone compromising = the server and then using the old channel state that is sitting around in o= rder to launch attacks.

That said, if there is a g= ood reason to keep the channel state, maybe the draft should specify what t= hat reasoning is. (I'm struggling to understand why anyone would want t= o keep the channel state around.)

******

Section 5:

As a point of presentat= ion: I had trouble getting a high level view of the protocol from reading S= ection 5.=C2=A0 Some issues confused me that I think should be defined up f= ront.=C2=A0 In other words, I think Section 5 should start with some prose = (even a new subsection) that gives a detailed overview of the protocol.

Pointing out some specific confusions of mine.
<= div>
- There are several "numbers" defined in this = document, and it is hard for the reader to disambiguate between them. Speci= fically, there is the "Next Protocol number" and the "Field = Type" and the "Record Number". The start of Section 5 should= start by telling the reader what are the different "fields" and = "types", and each of their purposes.=C2=A0 I also suggest providi= ng references to the relevant IANA Considerations in Section 8.
<= br>
- This section would benefit by showing a ladder presenting t= he sequence of communications and message types that go back and forth duri= ng a typical NTS exchange.=C2=A0

- I'm not cle= ar if the C, record type, and body length fields depicted in Figure 1 need = to be authenticated by the AEAD authenticator.=C2=A0 Maybe this should be s= pelled out more clearly.

****

=
Nowhere in the document do a see an explicit statement about when the = client is allowed to start taking time from an NTS-secured server.=C2=A0 I = think the draft should spell this out, at the very minimum with a SHOULD re= quirement, and possibly even a MUST.=C2=A0 To do this, it would help to hav= e a ladder that shows the protocol flow, and spells out in what point in th= e flow the client can start taking time.

****

Error codes:

I'm worried = about the error messages defined in Section 5.1.3 and warning in 5.1.4. Spe= cifically I am worried that they could be used a attack vector for DoSing t= he client.

My worry comes because, unless I misund= erstood the draft, it looks like the client can act on an unauthenticated e= rror code.=C2=A0 That is, the client will tear down an NTS association upon= receipt of the error message (error code 1).=C2=A0

I worry that an off-path attacker can use this to maliciously cause the c= lient to tear down an association (by injecting a bogus error packet to the= client).=C2=A0 One way to prevent this is to force the client to validated= the unique identifier extension on the error packet. However, I cannot tel= l from the draft whether or not the client is required to do this.=C2=A0

If the intention of the draft is *not* to prevent th= is attack, then it should be spelled out in the security considerations sec= tion. If the draft is preventing this attack, then this shoudl be explained= more clearly.

A similar issue is whether an on-pa= th attacker (that can eavesdrop and inject packets but not drop or modify p= ackets, (note: this is the threat model for the great firewall of china)) c= an inject error messages.=C2=A0 This sort of attacker, that does not have t= he power to drop packets, can still inject error messages in order to tear = down NTS connections.=C2=A0 And, since this attacker can eavesdrop, the uni= que identifier field will not thwart this attack.=C2=A0

If the intention of the draft is not to prevent this attack, then thi= s should be spelled out in the security considerations section.
<= br>
Alternatively, if I misunderstood the draft, then the draft s= hould be edited to clear up my misunderstanding. That is, there should be a= n explicit statement in Section 5.1.4 and 5.1.3 about whether or not the cl= ient can act on an unauthenticated error message, and whether or not the un= ique id field of the error message needs to be validated.

****

A similar issue on error messages:=C2= =A0

Why does NTS have both error messages, but als= o uses the NTS NAK in a kiss of death packet?

My p= reference is for a simpler protocol that has only 1 type of error message.= =C2=A0 Why doesn't just one type suffice?=C2=A0 If there is a reason to= have two types of error messages, then the draft should more clearly expla= in the use case for each type.

Note also that as w= ritten, per page 17, the NTS NAK can be exploited by the on-path attacker (= that can eavesdrop and inject packets but not drop or modify packets) in or= der to DoS the client, as I described above.=C2=A0 Thus, at the very least,= the security considerations of this draft should acknowledge this attack.<= /div>

*****

Nit: Section 5.1.4,= I raised this point earlier when I talked about the need for an overview o= f the protocol and a ladder at the start of Section 5. To reiterate.
<= div>
I don't understand what it means to "proceed to= the Next Protocol".=C2=A0

****
5.1.5 =C2=A0says:

=C2=A0 =C2=A0 Server= implementations of NTS extension fields for NTPv4 (Section 6)
= =C2=A0 =C2=A0MUST support AEAD_AES_SIV_CMAC_256 [RFC5297] (Numeric Identifi= er 15).
=C2=A0 =C2=A0That is, if the client includes AEAD_AES_SIV= _CMAC_256 in its AEAD
=C2=A0 =C2=A0Algorithm Negotiation record, = and the server accepts Protocol ID 0
=C2=A0 =C2=A0(NTPv4); in its= NTS Next Protocol Negotiation record, then the
=C2=A0 =C2=A0serv= er's AEAD Algorithm Negotiation record MUST NOT be empty.
Question: Does this mode of operation include any restrictions = on how many messages can be encrypted and authenticated?=C2=A0 If so, this = draft should respect this restriction and require rekeying after that numbe= r of message.=C2=A0 If not, this draft should point to the place in RFC5297= where it says that there is no such restriction, or point out that the res= triction is sufficiently high that we can never expect to exceed it.
<= div>=C2=A0
(NOTE: I did not have time, while preparing this revie= w, to understand this =C2=A0AEAD_AES_SIV_CMAC_256 mode of operation, so I a= m raising this question for Daniel to answer.)

Als= o, does the fact that RFC5297 is informational, while this draft is standar= ds track, create any issues for us?

*****

5.1.6 =C2=A0Cookies.

Earlier on t= his list there was discussion on whether or not the draft should specify no= rmative requirements on cookies.=C2=A0 Personally, I support that view that= we should place normative requirements on cookies, because an insecure coo= kie implementation would break the security of the whole protocol.=C2=A0

That said, what is a show stopper in my opinion, is = a lack of specification in the draft of what properties are required from t= he cookie.=C2=A0 At the very least, we want to make sure that the cookie do= es not leak the C2S and S2C keys to an observer (or a man in the middle).
=C2=A0
If I have misunderstood, and this confidentiality= is provided because the cookie is encrypted (as a MUST) by the AEAD scheme= , then the draft should make this point more clear in section 5.1.6.
<= div>
Also, is there a requirement that cookies be different a= cross different clients? That each cookie used by a client is unique?=C2=A0= At the very least these requirements should be spelled out as a MUST somew= here.=C2=A0 If SHOULD is used, then a discussion of the risks of not adheri= ng to these requirements should be provided.

If th= is is somewhere in the draft already, and I missed then, then apologies. Bu= t this text should be referenced in Section 5.1.6.

******

Section 6.3

I lik= e this section a lot but suggest the text below be edited from:
<= br>
=C2=A0 =C2=A0The Unique Identifier extension field has a Fiel= d Type of [[TBD2]].
=C2=A0 =C2=A0When the extension field is incl= uded in a client packet (mode 3), its
=C2=A0 =C2=A0body SHALL con= sist of a string of octets generated uniformly at
=C2=A0 =C2=A0ra= ndom.=C2=A0 The string SHOULD be 32 octets long.=C2=A0
=C2=A0
to "The string MUST be at least 32 octets long."
=C2=A0
***

Section 6, final comment.=C2= =A0 I read this section a few time, but I still don't have a great pict= ure in my head of how this protocol works and how it acheives its security = goals. I would like to give it another read once it is updated to address m= y comments.
=C2=A0
*****

I did= not review Section 8 in detail.

****
Section 9:

Section 9.1: I like this s= ection very much.=C2=A0
=C2=A0
But it would help to als= o have some discussion about how NTS prevents the control mode from being e= xploited for DoS, since this is the main vector that NTP DoS amplification = attacks exploit.=C2=A0 That said, I don't think this draft goes far eno= ugh regarding the security of the control mode, as I mentioned in an earlie= r comment.=C2=A0

Section 9.2: =C2=A0Verification o= f Server Certificates:
=C2=A0
I also like this section = very much. Some clarification questions:

The follo= wing paragraph should include some citations, so that readers can better un= derstand why the check works. As written it is too implementation dependent= . There should be a cite to what NTP_PHASE_MAX means and what ntp_gettime()= is expected to return.


=C2=A0 =C2= =A0 =C2=A0 Check whether the system time is in fact unreliable.=C2=A0 If th= e
=C2=A0 =C2=A0 =C2=A0 system clock has previously been synchroni= zed since last boot,
=C2=A0 =C2=A0 =C2=A0 then on operating syste= ms which implement a kernel-based phase-
=C2=A0 =C2=A0 =C2=A0 loc= ked-loop API, a call to ntp_gettime() should show a maximum
=C2= =A0 =C2=A0 =C2=A0 error less than NTP_PHASE_MAX.=C2=A0 In this case, the cl= ock should be
=C2=A0 =C2=A0 =C2=A0 considered reliable and certif= icates can be strictly validated.
=C2=A0 =C2=A0 =C2=A0=C2=A0
In the paragraph below, the term "strictly validated" needs= to defined.=C2=A0 Is this paragraph suggesting validating time with a huma= n? Or somethign else?

=C2=A0 =C2=A0 =C2=A0 Allow t= he system administrator to specify that certificates should
=C2= =A0 =C2=A0 =C2=A0 *always* be strictly validated.=C2=A0 Such a configuratio= n is
=C2=A0 =C2=A0 =C2=A0 appropriate on systems which have a bat= tery-backed clock and which
=C2=A0 =C2=A0 =C2=A0 can reasonably p= rompt the user to manually set an approximately-
=C2=A0 =C2=A0 = =C2=A0 correct time if it appears to be needed.
=C2=A0 =C2=A0 =C2= =A0=C2=A0
The following two recommendations are so important. I t= hink the draft should elevate these recommendation to SHOULD and put it the= TLS profile section, rather than bury it in the security considerations se= ction:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Once the clock = has been synchronized, periodically write the
=C2=A0 =C2=A0 =C2= =A0 current system time to persistent storage.=C2=A0 Do not accept any
=C2=A0 =C2=A0 =C2=A0 certificate whose notAfter field is earlier than= the last recorded
=C2=A0 =C2=A0 =C2=A0 time.
=C2=A0 = =C2=A0 =C2=A0=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0Do not process tim= e packets from servers if the time computed from
=C2=A0 =C2=A0 = =C2=A0 them falls outside the validity period of the server's
=C2=A0 =C2=A0 =C2=A0 certificate.

Section 9.4: = =C2=A0(Delay attacks)

I think the following senten= ce is false:

=C2=A0 =C2=A0 However, the maximum er= ror that an adversary
=C2=A0 =C2=A0can introduce is bounded by ha= lf of the round trip delay.

Why cannot an adversar= y delay the query an indefinate amount of time, and then send it to the ser= ver, and then pass on the server's response?=C2=A0 Eg delay the query 1= hour, then send to the server, then let the response pass by you unmoleste= d.=C2=A0 The error here would be huge (1 hour on the forward path, and ms o= n the reverse path).

Similarly I don't underst= and why the second paragraph of Section 9.4 is true.

=C2=A0 =C2=A0[RFC5905] specifies a parameter called MAXDIST which denote= s the
=C2=A0 =C2=A0maximum round-trip latency (including not only= the immediate round
=C2=A0 =C2=A0trip between client and server = but the whole distance back to the
=C2=A0 =C2=A0reference clock a= s reported in the Root Delay field) that a client
=C2=A0 =C2=A0wi= ll tolerate before concluding that the server is unsuitable for
= =C2=A0 =C2=A0synchronization.=C2=A0 The standard value for MAXDIST is one s= econd,
=C2=A0 =C2=A0although some implementations use larger valu= es.=C2=A0 Whatever value a
=C2=A0 =C2=A0client chooses, the maxim= um error which can be introduced by a delay
=C2=A0 =C2=A0attack i= s MAXDIST/2.

I suggest cutting both of these from = the draft. Even if they were correct, I don't think are important for t= he draft. It's probably not worth while for us to argue about them.

Section 9.5, suggested rewording:

=C2=A0 =C2=A0 Whenever this draft specifies the use of random numbers= , then cryptographically
=C2=A0 =C2=A0 secure random number gener= ation MUST be used. See [RFC4086] for guidelines concerning
=C2= =A0 =C2=A0this topic.

(I am worried about implemen= tations that eg. will use ntp_random() which is not cryptographically secur= e.)

Section 10.4

I like t= he MUST requirement here about implementation of ntp-data-minimization.=C2= =A0 Given the amount of protocol mechanisms and complexity we have introduc= ed in order to provide unlinkability, its important to also require that de= vices adhere to ntp-data-minimization if they actually want unlinkability.= =C2=A0

Also for this paragraph:

=C2=A0 =C2=A0It should also be noted that it could be possible to li= nk devices
=C2=A0 =C2=A0that operate as time servers from their t= ime synchronization traffic,
=C2=A0 =C2=A0using information expos= ed in (mode 4) server response packets (e.g.
=C2=A0 =C2=A0referen= ce ID, reference time, stratum, poll).=C2=A0 Also, devices that
= =C2=A0 =C2=A0respond to NTP control queries could be linked using the infor= mation
=C2=A0 =C2=A0revealed by control queries.
=C2=A0= =C2=A0
Suggested expansion:

=C2=A0 =C2= =A0It should also be noted that it could be possible to link devices
<= div>=C2=A0 =C2=A0that operate as time servers from their time synchronizati= on traffic,
=C2=A0 =C2=A0using information exposed in (mode 4) se= rver response packets (e.g.
=C2=A0 =C2=A0reference ID, reference = time, stratum, poll).=C2=A0 Devices that do not=C2=A0
=C2=A0 =C2= =A0wish to be linked in this way SHOULD NOT respond to (mode 3) client
=C2=A0 =C2=A0query packets from unknown IP addresses.
=C2= =A0 =C2=A0
=C2=A0 =C2=A0Also, devices that respond to NTP control= queries could be linked using the information revealed by control queries.= Devices that do not
=C2=A0 =C2=A0wish to be linked in this way S= HOULD NOT respond to control query packets=C2=A0
=C2=A0 =C2=A0fro= m unknown IP addresses.
=C2=A0 =C2=A0
=C2=A0 =C2=A0
Thanks for reading this far :)



--
Sharon Goldberg
Computer Science, Boston University
http://www.cs.bu.ed= u/~goldbe
--001a113ff92c2d667b05580fc735-- From ntp-bounces@ietf.org Thu Aug 31 10:14:41 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CE36E132E23; Thu, 31 Aug 2017 10:14:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1504199680; bh=zYHpkCSXSiXNunkEJE80kvCGkZ2REBqQbOPZIlQ1S7k=; h=From:Date:To:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=qxANeILmwTs5th4yEcgmKUuY0CW6K14V2as/mX//4UWEQvMx02VoL9rd/fDD3SG2Q ioM6mTUuDr+2zDVZB4qJDiaNRnz0CwlN7kEsSCt9xW8e2JT0uhJkZc8B0qb33D1dwZ yWGIYT9VeG/nTzxOlc/Y9dsMjuIHCeN5YlO6q908= 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 B16EB132E22 for ; Thu, 31 Aug 2017 10:14:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 7Ml7xy7QTsOW for ; Thu, 31 Aug 2017 10:14:34 -0700 (PDT) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (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 65D4C132DF8 for ; Thu, 31 Aug 2017 10:14:34 -0700 (PDT) Received: by mail-io0-x22b.google.com with SMTP id n71so2495360iod.1 for ; Thu, 31 Aug 2017 10:14:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=0grU66qZYX4pLBnbTvsP0qt+njhlO4wkv96rrz1iJJI=; b=UtSNVR6kO5kKfAfPgUCxp25p9qFyuQJ3gQMeHUcqvNYEizmpFYbL5+v78vlSgUUXsA yJlrfMqOUHFYeHBD+Ygg94FxuZ7e5nlJGF+ChBaPVoyuV8I54iI8zPBYCS68dAIeDuMJ GVCpe6ldxYk/oeLg/WgMnbh5G7qmPYekkJoE65cVRw4nM6unqk4Kk3ZIsP8sdya1JmoW eAHyCIgIDs5ZJfOpcYl/1HS3bsXW12lHgQEzefjDttVxGFt9fv+2MoUQysgpfSY1guxI 7qNULzqq4e6zesHcA/jGEx9J/p+xcsXTmuEUpH74cTScUxhE7SWwNTiv1KYtg6hzJBpr f00A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=0grU66qZYX4pLBnbTvsP0qt+njhlO4wkv96rrz1iJJI=; b=pZ9y8/k5LRszy/4ZXHot/lNo7GiZhpQssfd+Pp9YAFBu5BXN59UHjNQKWZRhoyGk4+ EHUIqCUjQQ7AYiLtRy5pI6SOUpOPGiWrhlaWnKOasLq46MsUbqgYJX6LnIfU1XZ+/IX9 HzwfvhcwBbL1wF1h3mPKX/9KrxKUva+E0UclkrdQhtE/198+/BtWcWpgUlvR67t7rRSq vUnQKWfIchIXMreMGqND/IhK9Y1kJ4vD/84ybM/eTp8X9VYhmru/yBvHY1473MZ/eyI1 NfJE8ZXqdVMakUSSPxw51S2T7WYx/nPsGjykiXoPAuFTzvud2hpskOrAmOb2vP2D8EWK zXhg== X-Gm-Message-State: AHPjjUh8gcAZ4qZskfQA3z+l94fYgpyMV374E7L54lqGF2Zi7Uf3i/fP Si7UvJtTqB32PNUATtvBjVWy9HnF7KEh X-Google-Smtp-Source: ADKCNb4UCYJ1GXwO/INZQcH44e1rtnr8c8EvVyA3MCME0ZjAsyeguo8O2sKTFqnC/G8HebbLvraDntfz6k9VYK40Av4= X-Received: by 10.107.134.210 with SMTP id q79mr5459554ioi.259.1504199672946; Thu, 31 Aug 2017 10:14:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.155.195 with HTTP; Thu, 31 Aug 2017 10:13:52 -0700 (PDT) From: Sharon Goldberg Date: Thu, 31 Aug 2017 13:13:52 -0400 X-Google-Sender-Auth: MBkGOjiEDYUmQSJOM2zfhKMUbOk Message-ID: To: ntp@ietf.org Archived-At: Subject: [Ntp] Sharon Goldberg comments on draft-ietf-ntp-using-nts-for-ntp X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============3961136531515041927==" Errors-To: ntp-bounces@ietf.org Sender: "ntp" --===============3961136531515041927== Content-Type: multipart/alternative; boundary="001a113ff92c2d667b05580fc735" --001a113ff92c2d667b05580fc735 Content-Type: text/plain; charset="UTF-8" Review of NTS. First of all, I wanted to congratulate Daniel, Dieter, and Kristof on the great progress made with this draft. This is great work, and much improved since the last WGLC for NTS. My comments, in linear order after reading through the draft that was in GitHub 4 hours ago, are below. https://github.com/dfoxfranke/nts/commit/5835e584cff6b224335 0fd6e8cd8cb3808d58c5d This is a fairly detailed review, that raises several issues. That said, I still don't have a complete understanding of how the client-server NTS protocol works or of its security properties, and would like to give it another read after the authors have edited the draft to clarify some of the issues I read below. Thanks, Sharon **** Section 1.1: The unlinkablilty objective, as written, is misleading. NTS only promises to not leak more linkability information that what is already being leaked by NTP. As written that reader could assume that NTS promises to fully guarantee unlinkability, which is false, since NTP could make the session linkable. It's not sufficient to bury this point in the security considerations section, so this should be reworded. **** Section 1.2: Says: However, client-server mode also has more relaxed security needs, because only the client requires replay protection: it is harmless for servers to process replayed packets. This is false. It can be harmful for a server to process replayed packets if that server keeps client state in order to perform rate limiting with a KoD. Specifically, an adversary can replay client packets at high rate to the server, in order to trigger rate-limint restrictions at the server and cause the server to send a "RATE" KoD to the client. Once the client receives this KoD, it will slow down or even stop its communications with the server. In other words, this is a DoS attack. This is CVE-2015-7705 which we called the "priming the pump" attack in our NDSS'15 paper: https://eprint.iacr.org/2015/1020.pdf Thus, I suggest that the draft include some language targeted at servers that do perform rate limiting with the KoD. Those servers MAY take advantage of NTS's replay protection to stop the Priming the Pump attack. In other words, these servers MAY track the client's unique identifiers and making sure that they are not reused, as a way of preventing the priming the pump attack. I am suggesting the use of MAY because this can be resource intensive for the server. (But, a data structure like a bloom filter could be used to minimize the overhead at the server of checking uniqueness of "unique identifiers"). I also suggest adding some text to the security considerations, explaining that when the server uses (1) rate limiting with the KoD but (2) does not use NTS's replay protections, then the server is vulnerable to the Priming the Pump attack of CVE-2015-7705. **** Page 5: "As previously stated, DTLS-encapsulated NTPv4 is trivial. The communicating parties establish a DTLS session and then exchange arbitrary NTP packets as DTLS Application Data." Nit: It's probably best to avoid judgement calls ("trivial") here. **** Section 4: Regarding security of the control mode: For control mode (6), the party sending queries should be the DTLS client and the party responding to the queries should be the DTLS server. I think we are missing an opportunity here to secure the control mode, and I'm not convinced that DTLS is the right approach. I would like to see this draft specify some way for servers to require client authentication before answering control queries. Why are we not considering the use of SSH? It makes much more sense to have the machine that sends the control query authenticate itself to the responding machine. That way, arbitrary attackers cannot just query the server and learn sensitive information about its state (or even modify its state using a write command). If we do think we are gaining something by securing the control mode with DTLS, the draft should spell out exactly what this security property is. **** Section 4. The description of symmetric mode operation is underspecified. I read it several times and I don't understand how it works. The draft says: For symmetric operation between an active (mode 1) and passive (mode 2) peer, the active peer should be the DTLS client and the passive peer should be the DTLS server. For symmetric operation between two active (mode 1) peers, both parties should attempt to initiate a DTLS session with their peer. If one handshake fails and the other succeeds, the successfully- established session should be used for traffic in both directions. If both handshakes succeed, either session may be used and packets should receive identical disposition regardless of which of the two sessions they arrived over. Inactive sessions may be timed out but the redundant session should not be proactively closed. I don't understand how two DLTS associations are used at the same time, given that symmetric mode uses a single request-response ladder for both peers to derive the time. I also don't understand the last sentence quoted above. What does proactively mean? Under what conditions should you actually close the session? Miroslav made this comment already, and I know that Daniel is current updating this text (have not seen this update yet) but I wanted to support Miroslav's concerns. **** Section 5: Nit: Immediately following a successful handshake, the client SHALL send a single request (as Application Data encapsulated in the TLS-protected channel), then the server SHALL send a single response followed by a TLS "Close notify" alert and then discard the channel state. Maybe change this "MUST discard the channel state" (or SHOULD)? In order to minimize the attack surface of someone compromising the server and then using the old channel state that is sitting around in order to launch attacks. That said, if there is a good reason to keep the channel state, maybe the draft should specify what that reasoning is. (I'm struggling to understand why anyone would want to keep the channel state around.) ****** Section 5: As a point of presentation: I had trouble getting a high level view of the protocol from reading Section 5. Some issues confused me that I think should be defined up front. In other words, I think Section 5 should start with some prose (even a new subsection) that gives a detailed overview of the protocol. Pointing out some specific confusions of mine. - There are several "numbers" defined in this document, and it is hard for the reader to disambiguate between them. Specifically, there is the "Next Protocol number" and the "Field Type" and the "Record Number". The start of Section 5 should start by telling the reader what are the different "fields" and "types", and each of their purposes. I also suggest providing references to the relevant IANA Considerations in Section 8. - This section would benefit by showing a ladder presenting the sequence of communications and message types that go back and forth during a typical NTS exchange. - I'm not clear if the C, record type, and body length fields depicted in Figure 1 need to be authenticated by the AEAD authenticator. Maybe this should be spelled out more clearly. **** Nowhere in the document do a see an explicit statement about when the client is allowed to start taking time from an NTS-secured server. I think the draft should spell this out, at the very minimum with a SHOULD requirement, and possibly even a MUST. To do this, it would help to have a ladder that shows the protocol flow, and spells out in what point in the flow the client can start taking time. **** Error codes: I'm worried about the error messages defined in Section 5.1.3 and warning in 5.1.4. Specifically I am worried that they could be used a attack vector for DoSing the client. My worry comes because, unless I misunderstood the draft, it looks like the client can act on an unauthenticated error code. That is, the client will tear down an NTS association upon receipt of the error message (error code 1). I worry that an off-path attacker can use this to maliciously cause the client to tear down an association (by injecting a bogus error packet to the client). One way to prevent this is to force the client to validated the unique identifier extension on the error packet. However, I cannot tell from the draft whether or not the client is required to do this. If the intention of the draft is *not* to prevent this attack, then it should be spelled out in the security considerations section. If the draft is preventing this attack, then this shoudl be explained more clearly. A similar issue is whether an on-path attacker (that can eavesdrop and inject packets but not drop or modify packets, (note: this is the threat model for the great firewall of china)) can inject error messages. This sort of attacker, that does not have the power to drop packets, can still inject error messages in order to tear down NTS connections. And, since this attacker can eavesdrop, the unique identifier field will not thwart this attack. If the intention of the draft is not to prevent this attack, then this should be spelled out in the security considerations section. Alternatively, if I misunderstood the draft, then the draft should be edited to clear up my misunderstanding. That is, there should be an explicit statement in Section 5.1.4 and 5.1.3 about whether or not the client can act on an unauthenticated error message, and whether or not the unique id field of the error message needs to be validated. **** A similar issue on error messages: Why does NTS have both error messages, but also uses the NTS NAK in a kiss of death packet? My preference is for a simpler protocol that has only 1 type of error message. Why doesn't just one type suffice? If there is a reason to have two types of error messages, then the draft should more clearly explain the use case for each type. Note also that as written, per page 17, the NTS NAK can be exploited by the on-path attacker (that can eavesdrop and inject packets but not drop or modify packets) in order to DoS the client, as I described above. Thus, at the very least, the security considerations of this draft should acknowledge this attack. ***** Nit: Section 5.1.4, I raised this point earlier when I talked about the need for an overview of the protocol and a ladder at the start of Section 5. To reiterate. I don't understand what it means to "proceed to the Next Protocol". **** 5.1.5 says: Server implementations of NTS extension fields for NTPv4 (Section 6) MUST support AEAD_AES_SIV_CMAC_256 [RFC5297] (Numeric Identifier 15). That is, if the client includes AEAD_AES_SIV_CMAC_256 in its AEAD Algorithm Negotiation record, and the server accepts Protocol ID 0 (NTPv4); in its NTS Next Protocol Negotiation record, then the server's AEAD Algorithm Negotiation record MUST NOT be empty. Question: Does this mode of operation include any restrictions on how many messages can be encrypted and authenticated? If so, this draft should respect this restriction and require rekeying after that number of message. If not, this draft should point to the place in RFC5297 where it says that there is no such restriction, or point out that the restriction is sufficiently high that we can never expect to exceed it. (NOTE: I did not have time, while preparing this review, to understand this AEAD_AES_SIV_CMAC_256 mode of operation, so I am raising this question for Daniel to answer.) Also, does the fact that RFC5297 is informational, while this draft is standards track, create any issues for us? ***** 5.1.6 Cookies. Earlier on this list there was discussion on whether or not the draft should specify normative requirements on cookies. Personally, I support that view that we should place normative requirements on cookies, because an insecure cookie implementation would break the security of the whole protocol. That said, what is a show stopper in my opinion, is a lack of specification in the draft of what properties are required from the cookie. At the very least, we want to make sure that the cookie does not leak the C2S and S2C keys to an observer (or a man in the middle). If I have misunderstood, and this confidentiality is provided because the cookie is encrypted (as a MUST) by the AEAD scheme, then the draft should make this point more clear in section 5.1.6. Also, is there a requirement that cookies be different across different clients? That each cookie used by a client is unique? At the very least these requirements should be spelled out as a MUST somewhere. If SHOULD is used, then a discussion of the risks of not adhering to these requirements should be provided. If this is somewhere in the draft already, and I missed then, then apologies. But this text should be referenced in Section 5.1.6. ****** Section 6.3 I like this section a lot but suggest the text below be edited from: The Unique Identifier extension field has a Field Type of [[TBD2]]. When the extension field is included in a client packet (mode 3), its body SHALL consist of a string of octets generated uniformly at random. The string SHOULD be 32 octets long. to "The string MUST be at least 32 octets long." *** Section 6, final comment. I read this section a few time, but I still don't have a great picture in my head of how this protocol works and how it acheives its security goals. I would like to give it another read once it is updated to address my comments. ***** I did not review Section 8 in detail. **** Section 9: Section 9.1: I like this section very much. But it would help to also have some discussion about how NTS prevents the control mode from being exploited for DoS, since this is the main vector that NTP DoS amplification attacks exploit. That said, I don't think this draft goes far enough regarding the security of the control mode, as I mentioned in an earlier comment. Section 9.2: Verification of Server Certificates: I also like this section very much. Some clarification questions: The following paragraph should include some citations, so that readers can better understand why the check works. As written it is too implementation dependent. There should be a cite to what NTP_PHASE_MAX means and what ntp_gettime() is expected to return. Check whether the system time is in fact unreliable. If the system clock has previously been synchronized since last boot, then on operating systems which implement a kernel-based phase- locked-loop API, a call to ntp_gettime() should show a maximum error less than NTP_PHASE_MAX. In this case, the clock should be considered reliable and certificates can be strictly validated. In the paragraph below, the term "strictly validated" needs to defined. Is this paragraph suggesting validating time with a human? Or somethign else? Allow the system administrator to specify that certificates should *always* be strictly validated. Such a configuration is appropriate on systems which have a battery-backed clock and which can reasonably prompt the user to manually set an approximately- correct time if it appears to be needed. The following two recommendations are so important. I think the draft should elevate these recommendation to SHOULD and put it the TLS profile section, rather than bury it in the security considerations section: Once the clock has been synchronized, periodically write the current system time to persistent storage. Do not accept any certificate whose notAfter field is earlier than the last recorded time. Do not process time packets from servers if the time computed from them falls outside the validity period of the server's certificate. Section 9.4: (Delay attacks) I think the following sentence is false: However, the maximum error that an adversary can introduce is bounded by half of the round trip delay. Why cannot an adversary delay the query an indefinate amount of time, and then send it to the server, and then pass on the server's response? Eg delay the query 1 hour, then send to the server, then let the response pass by you unmolested. The error here would be huge (1 hour on the forward path, and ms on the reverse path). Similarly I don't understand why the second paragraph of Section 9.4 is true. [RFC5905] specifies a parameter called MAXDIST which denotes the maximum round-trip latency (including not only the immediate round trip between client and server but the whole distance back to the reference clock as reported in the Root Delay field) that a client will tolerate before concluding that the server is unsuitable for synchronization. The standard value for MAXDIST is one second, although some implementations use larger values. Whatever value a client chooses, the maximum error which can be introduced by a delay attack is MAXDIST/2. I suggest cutting both of these from the draft. Even if they were correct, I don't think are important for the draft. It's probably not worth while for us to argue about them. Section 9.5, suggested rewording: Whenever this draft specifies the use of random numbers, then cryptographically secure random number generation MUST be used. See [RFC4086] for guidelines concerning this topic. (I am worried about implementations that eg. will use ntp_random() which is not cryptographically secure.) Section 10.4 I like the MUST requirement here about implementation of ntp-data-minimization. Given the amount of protocol mechanisms and complexity we have introduced in order to provide unlinkability, its important to also require that devices adhere to ntp-data-minimization if they actually want unlinkability. Also for this paragraph: It should also be noted that it could be possible to link devices that operate as time servers from their time synchronization traffic, using information exposed in (mode 4) server response packets (e.g. reference ID, reference time, stratum, poll). Also, devices that respond to NTP control queries could be linked using the information revealed by control queries. Suggested expansion: It should also be noted that it could be possible to link devices that operate as time servers from their time synchronization traffic, using information exposed in (mode 4) server response packets (e.g. reference ID, reference time, stratum, poll). Devices that do not wish to be linked in this way SHOULD NOT respond to (mode 3) client query packets from unknown IP addresses. Also, devices that respond to NTP control queries could be linked using the information revealed by control queries. Devices that do not wish to be linked in this way SHOULD NOT respond to control query packets from unknown IP addresses. Thanks for reading this far :) -- Sharon Goldberg Computer Science, Boston University http://www.cs.bu.edu/~goldbe --001a113ff92c2d667b05580fc735 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Review of NTS.

First of all,= I wanted to congratulate Daniel, Dieter, and Kristof on the great progress= made with this draft. This is great work, and much improved since the last= WGLC for NTS. =C2=A0

My comments, in linear order= after reading through the draft that was in GitHub 4 hours ago, are below.=

=C2=A0
This is a fairly detailed review, t= hat raises several issues.=C2=A0 That said, I still don't have a comple= te understanding of how the client-server NTS protocol works or of its secu= rity properties, and would like to give it another read after the authors h= ave edited the draft to clarify some of the issues I read below.
=
Thanks,
Sharon

****
=

Section 1.1: The unlinkablilty objective, as written, i= s misleading. NTS only promises to not leak more linkability information th= at what is already being leaked by NTP. =C2=A0 As written that reader could= assume that NTS promises to fully guarantee unlinkability, which is false,= since NTP could make the session linkable.=C2=A0 It's not sufficient t= o bury this point in the security considerations section, so this should be= reworded.

****

Section 1= .2: =C2=A0Says:=C2=A0

=C2=A0 =C2=A0 However, clien= t-server mode also has more
=C2=A0 =C2=A0relaxed security needs, = because only the client requires replay
=C2=A0 =C2=A0protection: = it is harmless for servers to process replayed packets.
=C2=A0 = =C2=A0
This is false.=C2=A0

It can be ha= rmful for a server to process replayed packets if that server keeps client = state in order to perform rate limiting with a KoD. Specifically, an advers= ary can replay client packets at high rate to the server, in order to trigg= er rate-limint restrictions at the server and cause the server to send a &q= uot;RATE" KoD to the client. Once the client receives this KoD, it wil= l slow down or even stop its communications with the server.=C2=A0 In other= words, this is a DoS attack. =C2=A0

This is CVE-2= 015-7705 which we called the "priming the pump" =C2=A0attack in o= ur NDSS'15 paper:


Thus, I suggest that the draft include= some language targeted at servers that do perform rate limiting with the K= oD.=C2=A0 Those servers MAY take advantage of NTS's replay protection t= o stop the Priming the Pump attack.=C2=A0 In other words, these servers MAY= track the client's unique identifiers and making sure that they are no= t reused, as a way of preventing the priming the pump attack. I am suggesti= ng the use of MAY because this can be resource intensive for the server. = =C2=A0(But, a data structure like a bloom filter could be used to minimize = the overhead at the server of checking uniqueness of "unique identifie= rs").

I also suggest adding some text to the = security considerations, explaining that when the server uses (1) rate limi= ting with the KoD but (2) does not use NTS's replay protections, then t= he server is vulnerable to the Priming the Pump attack of CVE-2015-7705.

****

Page 5: "As previ= ously stated, DTLS-encapsulated NTPv4 is trivial.=C2=A0 The
=C2= =A0 =C2=A0communicating parties establish a DTLS session and then exchange<= /div>
=C2=A0 =C2=A0arbitrary NTP packets as DTLS Application Data."= ;
=C2=A0 =C2=A0
Nit: It's probably best to avoid ju= dgement calls ("trivial") here.=C2=A0

**= **

Section 4: Regarding security of the control mo= de:

=C2=A0 =C2=A0For control mode (6), the party s= ending queries should be the DTLS
=C2=A0 =C2=A0client and the par= ty responding to the queries should be the DTLS
=C2=A0 =C2=A0serv= er.

I think we are missing an opportunity here to = secure the control mode, and I'm not convinced that DTLS is the right a= pproach. =C2=A0

I would like to see this draft spe= cify some way for servers to require client authentication before answering= control queries.

Why are we not considering the u= se of SSH? It makes much more sense to have the machine that sends the cont= rol query authenticate itself to the responding machine. That way, arbitrar= y attackers cannot just query the server and learn sensitive information ab= out its state (or even modify its state using a write command).
<= br>
If we do think we are gaining something by securing the contr= ol mode with DTLS, the draft should spell out exactly what this security pr= operty is.=C2=A0

****

Sec= tion 4. The description of symmetric mode operation is underspecified. I re= ad it several times and I don't understand how it works.=C2=A0 The draf= t says:

=C2=A0 =C2=A0For symmetric operation betwe= en an active (mode 1) and passive (mode
=C2=A0 =C2=A02) peer, the= active peer should be the DTLS client and the passive
=C2=A0 =C2= =A0peer should be the DTLS server.

=C2=A0 =C2=A0Fo= r symmetric operation between two active (mode 1) peers, both
=C2= =A0 =C2=A0parties should attempt to initiate a DTLS session with their peer= .
=C2=A0 =C2=A0If one handshake fails and the other succeeds, the= successfully-
=C2=A0 =C2=A0established session should be used fo= r traffic in both directions.
=C2=A0 =C2=A0If both handshakes suc= ceed, either session may be used and packets
=C2=A0 =C2=A0should = receive identical disposition regardless of which of the two
=C2= =A0 =C2=A0sessions they arrived over.=C2=A0 Inactive sessions may be timed = out but
=C2=A0 =C2=A0the redundant session should not be proactiv= ely closed.
=C2=A0
I don't understand how two DLTS = associations are used at the same time, given that symmetric mode uses a si= ngle request-response ladder for both peers to derive the time.
<= br>
I also don't understand the last sentence quoted above.= =C2=A0 What does proactively mean? Under what conditions should you actuall= y close the session?

Miroslav made this comment al= ready, and I know that Daniel is current updating this text (have not seen = this update yet) but I wanted to support Miroslav's concerns.

****

Section 5:

Nit: =C2=A0

=C2=A0 =C2=A0 Immediately follo= wing a successful handshake, the
=C2=A0 =C2=A0client SHALL send a= single request (as Application Data encapsulated
=C2=A0 =C2=A0in= the TLS-protected channel), then the server SHALL send a single
= =C2=A0 =C2=A0response followed by a TLS "Close notify" alert and = then discard the
=C2=A0 =C2=A0channel state.

=
Maybe change this "MUST discard the channel state" (or SHOUL= D)? =C2=A0 In order to minimize the attack surface of someone compromising = the server and then using the old channel state that is sitting around in o= rder to launch attacks.

That said, if there is a g= ood reason to keep the channel state, maybe the draft should specify what t= hat reasoning is. (I'm struggling to understand why anyone would want t= o keep the channel state around.)

******

Section 5:

As a point of presentat= ion: I had trouble getting a high level view of the protocol from reading S= ection 5.=C2=A0 Some issues confused me that I think should be defined up f= ront.=C2=A0 In other words, I think Section 5 should start with some prose = (even a new subsection) that gives a detailed overview of the protocol.

Pointing out some specific confusions of mine.
<= div>
- There are several "numbers" defined in this = document, and it is hard for the reader to disambiguate between them. Speci= fically, there is the "Next Protocol number" and the "Field = Type" and the "Record Number". The start of Section 5 should= start by telling the reader what are the different "fields" and = "types", and each of their purposes.=C2=A0 I also suggest providi= ng references to the relevant IANA Considerations in Section 8.
<= br>
- This section would benefit by showing a ladder presenting t= he sequence of communications and message types that go back and forth duri= ng a typical NTS exchange.=C2=A0

- I'm not cle= ar if the C, record type, and body length fields depicted in Figure 1 need = to be authenticated by the AEAD authenticator.=C2=A0 Maybe this should be s= pelled out more clearly.

****

=
Nowhere in the document do a see an explicit statement about when the = client is allowed to start taking time from an NTS-secured server.=C2=A0 I = think the draft should spell this out, at the very minimum with a SHOULD re= quirement, and possibly even a MUST.=C2=A0 To do this, it would help to hav= e a ladder that shows the protocol flow, and spells out in what point in th= e flow the client can start taking time.

****

Error codes:

I'm worried = about the error messages defined in Section 5.1.3 and warning in 5.1.4. Spe= cifically I am worried that they could be used a attack vector for DoSing t= he client.

My worry comes because, unless I misund= erstood the draft, it looks like the client can act on an unauthenticated e= rror code.=C2=A0 That is, the client will tear down an NTS association upon= receipt of the error message (error code 1).=C2=A0

I worry that an off-path attacker can use this to maliciously cause the c= lient to tear down an association (by injecting a bogus error packet to the= client).=C2=A0 One way to prevent this is to force the client to validated= the unique identifier extension on the error packet. However, I cannot tel= l from the draft whether or not the client is required to do this.=C2=A0

If the intention of the draft is *not* to prevent th= is attack, then it should be spelled out in the security considerations sec= tion. If the draft is preventing this attack, then this shoudl be explained= more clearly.

A similar issue is whether an on-pa= th attacker (that can eavesdrop and inject packets but not drop or modify p= ackets, (note: this is the threat model for the great firewall of china)) c= an inject error messages.=C2=A0 This sort of attacker, that does not have t= he power to drop packets, can still inject error messages in order to tear = down NTS connections.=C2=A0 And, since this attacker can eavesdrop, the uni= que identifier field will not thwart this attack.=C2=A0

If the intention of the draft is not to prevent this attack, then thi= s should be spelled out in the security considerations section.
<= br>
Alternatively, if I misunderstood the draft, then the draft s= hould be edited to clear up my misunderstanding. That is, there should be a= n explicit statement in Section 5.1.4 and 5.1.3 about whether or not the cl= ient can act on an unauthenticated error message, and whether or not the un= ique id field of the error message needs to be validated.

****

A similar issue on error messages:=C2= =A0

Why does NTS have both error messages, but als= o uses the NTS NAK in a kiss of death packet?

My p= reference is for a simpler protocol that has only 1 type of error message.= =C2=A0 Why doesn't just one type suffice?=C2=A0 If there is a reason to= have two types of error messages, then the draft should more clearly expla= in the use case for each type.

Note also that as w= ritten, per page 17, the NTS NAK can be exploited by the on-path attacker (= that can eavesdrop and inject packets but not drop or modify packets) in or= der to DoS the client, as I described above.=C2=A0 Thus, at the very least,= the security considerations of this draft should acknowledge this attack.<= /div>

*****

Nit: Section 5.1.4,= I raised this point earlier when I talked about the need for an overview o= f the protocol and a ladder at the start of Section 5. To reiterate.
<= div>
I don't understand what it means to "proceed to= the Next Protocol".=C2=A0

****
5.1.5 =C2=A0says:

=C2=A0 =C2=A0 Server= implementations of NTS extension fields for NTPv4 (Section 6)
= =C2=A0 =C2=A0MUST support AEAD_AES_SIV_CMAC_256 [RFC5297] (Numeric Identifi= er 15).
=C2=A0 =C2=A0That is, if the client includes AEAD_AES_SIV= _CMAC_256 in its AEAD
=C2=A0 =C2=A0Algorithm Negotiation record, = and the server accepts Protocol ID 0
=C2=A0 =C2=A0(NTPv4); in its= NTS Next Protocol Negotiation record, then the
=C2=A0 =C2=A0serv= er's AEAD Algorithm Negotiation record MUST NOT be empty.
Question: Does this mode of operation include any restrictions = on how many messages can be encrypted and authenticated?=C2=A0 If so, this = draft should respect this restriction and require rekeying after that numbe= r of message.=C2=A0 If not, this draft should point to the place in RFC5297= where it says that there is no such restriction, or point out that the res= triction is sufficiently high that we can never expect to exceed it.
<= div>=C2=A0
(NOTE: I did not have time, while preparing this revie= w, to understand this =C2=A0AEAD_AES_SIV_CMAC_256 mode of operation, so I a= m raising this question for Daniel to answer.)

Als= o, does the fact that RFC5297 is informational, while this draft is standar= ds track, create any issues for us?

*****

5.1.6 =C2=A0Cookies.

Earlier on t= his list there was discussion on whether or not the draft should specify no= rmative requirements on cookies.=C2=A0 Personally, I support that view that= we should place normative requirements on cookies, because an insecure coo= kie implementation would break the security of the whole protocol.=C2=A0

That said, what is a show stopper in my opinion, is = a lack of specification in the draft of what properties are required from t= he cookie.=C2=A0 At the very least, we want to make sure that the cookie do= es not leak the C2S and S2C keys to an observer (or a man in the middle).
=C2=A0
If I have misunderstood, and this confidentiality= is provided because the cookie is encrypted (as a MUST) by the AEAD scheme= , then the draft should make this point more clear in section 5.1.6.
<= div>
Also, is there a requirement that cookies be different a= cross different clients? That each cookie used by a client is unique?=C2=A0= At the very least these requirements should be spelled out as a MUST somew= here.=C2=A0 If SHOULD is used, then a discussion of the risks of not adheri= ng to these requirements should be provided.

If th= is is somewhere in the draft already, and I missed then, then apologies. Bu= t this text should be referenced in Section 5.1.6.

******

Section 6.3

I lik= e this section a lot but suggest the text below be edited from:
<= br>
=C2=A0 =C2=A0The Unique Identifier extension field has a Fiel= d Type of [[TBD2]].
=C2=A0 =C2=A0When the extension field is incl= uded in a client packet (mode 3), its
=C2=A0 =C2=A0body SHALL con= sist of a string of octets generated uniformly at
=C2=A0 =C2=A0ra= ndom.=C2=A0 The string SHOULD be 32 octets long.=C2=A0
=C2=A0
to "The string MUST be at least 32 octets long."
=C2=A0
***

Section 6, final comment.=C2= =A0 I read this section a few time, but I still don't have a great pict= ure in my head of how this protocol works and how it acheives its security = goals. I would like to give it another read once it is updated to address m= y comments.
=C2=A0
*****

I did= not review Section 8 in detail.

****
Section 9:

Section 9.1: I like this s= ection very much.=C2=A0
=C2=A0
But it would help to als= o have some discussion about how NTS prevents the control mode from being e= xploited for DoS, since this is the main vector that NTP DoS amplification = attacks exploit.=C2=A0 That said, I don't think this draft goes far eno= ugh regarding the security of the control mode, as I mentioned in an earlie= r comment.=C2=A0

Section 9.2: =C2=A0Verification o= f Server Certificates:
=C2=A0
I also like this section = very much. Some clarification questions:

The follo= wing paragraph should include some citations, so that readers can better un= derstand why the check works. As written it is too implementation dependent= . There should be a cite to what NTP_PHASE_MAX means and what ntp_gettime()= is expected to return.


=C2=A0 =C2= =A0 =C2=A0 Check whether the system time is in fact unreliable.=C2=A0 If th= e
=C2=A0 =C2=A0 =C2=A0 system clock has previously been synchroni= zed since last boot,
=C2=A0 =C2=A0 =C2=A0 then on operating syste= ms which implement a kernel-based phase-
=C2=A0 =C2=A0 =C2=A0 loc= ked-loop API, a call to ntp_gettime() should show a maximum
=C2= =A0 =C2=A0 =C2=A0 error less than NTP_PHASE_MAX.=C2=A0 In this case, the cl= ock should be
=C2=A0 =C2=A0 =C2=A0 considered reliable and certif= icates can be strictly validated.
=C2=A0 =C2=A0 =C2=A0=C2=A0
In the paragraph below, the term "strictly validated" needs= to defined.=C2=A0 Is this paragraph suggesting validating time with a huma= n? Or somethign else?

=C2=A0 =C2=A0 =C2=A0 Allow t= he system administrator to specify that certificates should
=C2= =A0 =C2=A0 =C2=A0 *always* be strictly validated.=C2=A0 Such a configuratio= n is
=C2=A0 =C2=A0 =C2=A0 appropriate on systems which have a bat= tery-backed clock and which
=C2=A0 =C2=A0 =C2=A0 can reasonably p= rompt the user to manually set an approximately-
=C2=A0 =C2=A0 = =C2=A0 correct time if it appears to be needed.
=C2=A0 =C2=A0 =C2= =A0=C2=A0
The following two recommendations are so important. I t= hink the draft should elevate these recommendation to SHOULD and put it the= TLS profile section, rather than bury it in the security considerations se= ction:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Once the clock = has been synchronized, periodically write the
=C2=A0 =C2=A0 =C2= =A0 current system time to persistent storage.=C2=A0 Do not accept any
=C2=A0 =C2=A0 =C2=A0 certificate whose notAfter field is earlier than= the last recorded
=C2=A0 =C2=A0 =C2=A0 time.
=C2=A0 = =C2=A0 =C2=A0=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0Do not process tim= e packets from servers if the time computed from
=C2=A0 =C2=A0 = =C2=A0 them falls outside the validity period of the server's
=C2=A0 =C2=A0 =C2=A0 certificate.

Section 9.4: = =C2=A0(Delay attacks)

I think the following senten= ce is false:

=C2=A0 =C2=A0 However, the maximum er= ror that an adversary
=C2=A0 =C2=A0can introduce is bounded by ha= lf of the round trip delay.

Why cannot an adversar= y delay the query an indefinate amount of time, and then send it to the ser= ver, and then pass on the server's response?=C2=A0 Eg delay the query 1= hour, then send to the server, then let the response pass by you unmoleste= d.=C2=A0 The error here would be huge (1 hour on the forward path, and ms o= n the reverse path).

Similarly I don't underst= and why the second paragraph of Section 9.4 is true.

=C2=A0 =C2=A0[RFC5905] specifies a parameter called MAXDIST which denote= s the
=C2=A0 =C2=A0maximum round-trip latency (including not only= the immediate round
=C2=A0 =C2=A0trip between client and server = but the whole distance back to the
=C2=A0 =C2=A0reference clock a= s reported in the Root Delay field) that a client
=C2=A0 =C2=A0wi= ll tolerate before concluding that the server is unsuitable for
= =C2=A0 =C2=A0synchronization.=C2=A0 The standard value for MAXDIST is one s= econd,
=C2=A0 =C2=A0although some implementations use larger valu= es.=C2=A0 Whatever value a
=C2=A0 =C2=A0client chooses, the maxim= um error which can be introduced by a delay
=C2=A0 =C2=A0attack i= s MAXDIST/2.

I suggest cutting both of these from = the draft. Even if they were correct, I don't think are important for t= he draft. It's probably not worth while for us to argue about them.

Section 9.5, suggested rewording:

=C2=A0 =C2=A0 Whenever this draft specifies the use of random numbers= , then cryptographically
=C2=A0 =C2=A0 secure random number gener= ation MUST be used. See [RFC4086] for guidelines concerning
=C2= =A0 =C2=A0this topic.

(I am worried about implemen= tations that eg. will use ntp_random() which is not cryptographically secur= e.)

Section 10.4

I like t= he MUST requirement here about implementation of ntp-data-minimization.=C2= =A0 Given the amount of protocol mechanisms and complexity we have introduc= ed in order to provide unlinkability, its important to also require that de= vices adhere to ntp-data-minimization if they actually want unlinkability.= =C2=A0

Also for this paragraph:

=C2=A0 =C2=A0It should also be noted that it could be possible to li= nk devices
=C2=A0 =C2=A0that operate as time servers from their t= ime synchronization traffic,
=C2=A0 =C2=A0using information expos= ed in (mode 4) server response packets (e.g.
=C2=A0 =C2=A0referen= ce ID, reference time, stratum, poll).=C2=A0 Also, devices that
= =C2=A0 =C2=A0respond to NTP control queries could be linked using the infor= mation
=C2=A0 =C2=A0revealed by control queries.
=C2=A0= =C2=A0
Suggested expansion:

=C2=A0 =C2= =A0It should also be noted that it could be possible to link devices
<= div>=C2=A0 =C2=A0that operate as time servers from their time synchronizati= on traffic,
=C2=A0 =C2=A0using information exposed in (mode 4) se= rver response packets (e.g.
=C2=A0 =C2=A0reference ID, reference = time, stratum, poll).=C2=A0 Devices that do not=C2=A0
=C2=A0 =C2= =A0wish to be linked in this way SHOULD NOT respond to (mode 3) client
=C2=A0 =C2=A0query packets from unknown IP addresses.
=C2= =A0 =C2=A0
=C2=A0 =C2=A0Also, devices that respond to NTP control= queries could be linked using the information revealed by control queries.= Devices that do not
=C2=A0 =C2=A0wish to be linked in this way S= HOULD NOT respond to control query packets=C2=A0
=C2=A0 =C2=A0fro= m unknown IP addresses.
=C2=A0 =C2=A0
=C2=A0 =C2=A0
Thanks for reading this far :)



--
Sharon Goldberg
Computer Science, Boston University
http://www.cs.bu.ed= u/~goldbe
--001a113ff92c2d667b05580fc735-- --===============3961136531515041927== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp --===============3961136531515041927==-- From nobody Thu Aug 31 12:19:41 2017 Return-Path: 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 92C4F1329AD for ; Thu, 31 Aug 2017 12:19:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 8wc4C59_O3M0 for ; Thu, 31 Aug 2017 12:19:37 -0700 (PDT) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (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 1031E1321AE for ; Thu, 31 Aug 2017 12:19:37 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id f127so3442905wmf.1 for ; Thu, 31 Aug 2017 12:19:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HR0DOpRNdWTuLWd27Eo0wBDkWVoWAVgWZVAJ3Fi6I0E=; b=YIt/cJTCX95xJtV5yJ1qzOyEgX4gYV9ThFNca+2CCFFA+GgEQn7Mhb5rBWJ+y9FWEo 5mZxgzkeSb7ZNH6P+cgqIFfLUqLq7hiRagZSsDnQ6h3CBwUM/tk0cVH++8hAhYt+bsts m8HCityp0+718susZg1d9wMe4Ta0qU1HJ0oa7FgR1E3+NRw0KPaVeQuAJt68R89Kl7du x0x3aOB05MyjjvrgbnLD2ZcQYbKhjeyd8KslQkTvmqPRlEqnFdsj7JDNi/OeQP8Ws5KC mC8S0gR/MYA5H47ldByUd9pjfvyfb19lirQAIpW9tJXMwrxW6ICig8IZkWYRxh5o7wDf NL4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=HR0DOpRNdWTuLWd27Eo0wBDkWVoWAVgWZVAJ3Fi6I0E=; b=kFpbnLy1nWd1f1h6+58/C60Kpr/zggaxKN6/3Es4Pa/H2Q5Hhjc684bpa3HPkuZ/Lr VK95ZyR/S6TR96eqcz8Zs39aryZ1WkPSuk0Y/8K6uMYM1EZtlg9I4cfDxyeoZWaKTaO3 R2JipDSI5YEbT0XEyciKMPBa9jEVyy/qR4VEfALwwRqyyo0SMbIs5anUuK2HWZV8H6m3 ZFesl5u8URvg2r03yzr6sKgeLHyxRam9WvA0NcKK5Y8xu8uZHT64sdmmXNz19k6iTZP/ kqL+ypHTvUtJ25vLM5kf1s0S9wA74o8vDT3Lpq9m8FTF1JFtjTthEFZKnAXAJxplK+yY QCFA== X-Gm-Message-State: AHYfb5hX5vswnL+hCHz5h9Xd3AVGogFa38VA6LRtwyAFkqZABB4EibbM b3Au4xgWgjb7MK62za+4ZssiDWNx8pBHfyk= X-Google-Smtp-Source: ADKCNb4ENJmZxKTmi+3vsj4Us9MMXuqPZ8lgHE3DQG0Nj2JxVcqMRyuv98eAj0vp7CmlsFoAv03cTacOHgIZn5JpK1s= X-Received: by 10.80.186.82 with SMTP id 18mr2395624eds.86.1504207175122; Thu, 31 Aug 2017 12:19:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.157.140 with HTTP; Thu, 31 Aug 2017 12:19:34 -0700 (PDT) In-Reply-To: References: From: Daniel Franke Date: Thu, 31 Aug 2017 15:19:34 -0400 Message-ID: To: Sharon Goldberg Cc: ntp@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Ntp] Sharon Goldberg comments on draft-ietf-ntp-using-nts-for-ntp X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 19:19:41 -0000 On 8/31/17, Sharon Goldberg wrote: > Section 1.1: The unlinkablilty objective, as written, is misleading. NTS > only promises to not leak more linkability information that what is already > being leaked by NTP. As written that reader could assume that NTS > promises to fully guarantee unlinkability, which is false, since NTP could > make the session linkable. It's not sufficient to bury this point in the > security considerations section, so this should be reworded. Will do. > Section 1.2: Says: > > However, client-server mode also has more > relaxed security needs, because only the client requires replay > protection: it is harmless for servers to process replayed packets. > > This is false. > > It can be harmful for a server to process replayed packets if that server > keeps client state in order to perform rate limiting with a KoD. > Specifically, an adversary can replay client packets at high rate to the > server, in order to trigger rate-limint restrictions at the server and > cause the server to send a "RATE" KoD to the client. Once the client > receives this KoD, it will slow down or even stop its communications with > the server. In other words, this is a DoS attack. Good point. I'll restore the truth of this sentence by qualifying it with "stateless servers" and then discuss priming-the-pump in the security considerations. > For control mode (6), the party sending queries should be the DTLS > client and the party responding to the queries should be the DTLS > server. > > I think we are missing an opportunity here to secure the control mode, and > I'm not convinced that DTLS is the right approach. > > I would like to see this draft specify some way for servers to require > client authentication before answering control queries. There already is -- connect with a client certificate. This should be clearer after I finish updating in response to Miroslav's comments. > Section 5: > > Nit: > > Immediately following a successful handshake, the > client SHALL send a single request (as Application Data encapsulated > in the TLS-protected channel), then the server SHALL send a single > response followed by a TLS "Close notify" alert and then discard the > channel state. > > Maybe change this "MUST discard the channel state" (or SHOULD)? In order > to minimize the attack surface of someone compromising the server and then > using the old channel state that is sitting around in order to launch > attacks. 'send a single response followed by a TLS "close notify" alert and then discard the channel state' is already the intended predicate of SHALL (synonymous in RFC 2119 with MUST). Which part confused you -- my grammar, or the meaning of 'SHALL'? If the former I'll see if I can clarify. > - There are several "numbers" defined in this document, and it is hard for > the reader to disambiguate between them. Specifically, there is the "Next > Protocol number" and the "Field Type" and the "Record Number". The start of > Section 5 should start by telling the reader what are the different > "fields" and "types", and each of their purposes. I also suggest providing > references to the relevant IANA Considerations in Section 8. > > - This section would benefit by showing a ladder presenting the sequence of > communications and message types that go back and forth during a typical > NTS exchange. There was such a thing in previous drafts. I pulled it because it had gotten sufficiently out of sync with the spec that it was doing more harm than good. I'll see if I can come up with something new and better. I've cut out and not responded to a portion of your feedback below because it appears to the result of confusion that a better ladder diagram would alleviate. I.e., the type 1 error codes that you were worried about are exchanged during NTS-KE, and therefore protected by DTLS and can't be spoofed. NTS NAKs, on the other hand, are NTP packets. > 5.1.5 says: > > Server implementations of NTS extension fields for NTPv4 (Section 6) > MUST support AEAD_AES_SIV_CMAC_256 [RFC5297] (Numeric Identifier 15). > That is, if the client includes AEAD_AES_SIV_CMAC_256 in its AEAD > Algorithm Negotiation record, and the server accepts Protocol ID 0 > (NTPv4); in its NTS Next Protocol Negotiation record, then the > server's AEAD Algorithm Negotiation record MUST NOT be empty. > > Question: Does this mode of operation include any restrictions on how many > messages can be encrypted and authenticated? If so, this draft should > respect this restriction and require rekeying after that number of > message. If not, this draft should point to the place in RFC5297 where it > says that there is no such restriction, or point out that the restriction > is sufficiently high that we can never expect to exceed it. I'll see about adding some more discussion about this. RFC 5297 recommends a limit of 2**48 messages under a single key; most other algorithms are similar or worse. When you get up to 2**64, there's a 50% of a collision that will compromise secrecy, but not authentication on the two colliding messages (only). A stateless server can't be expected to keep a count of how many times a key has been used, but it can expire cookies with sufficient frequency that the 2**48 cap can never be hit in time due to CPU and/or bandwidth limitations. > Also, does the fact that RFC5297 is informational, while this draft is > standards track, create any issues for us? No. See, e.g., how RFC 5246 (TLS 1.2, Standards Track) has RFC 2104 (HMAC, Informational) as a normative reference. > Earlier on this list there was discussion on whether or not the draft > should specify normative requirements on cookies. Personally, I support > that view that we should place normative requirements on cookies, because > an insecure cookie implementation would break the security of the whole > protocol. > > That said, what is a show stopper in my opinion, is a lack of specification > in the draft of what properties are required from the cookie. At the very > least, we want to make sure that the cookie does not leak the C2S and S2C > keys to an observer (or a man in the middle). > > If I have misunderstood, and this confidentiality is provided because the > cookie is encrypted (as a MUST) by the AEAD scheme, then the draft should > make this point more clear in section 5.1.6. I don't think we can possibly enumerate every possible thing that the server must not do lest it compromise the security of the protocol. There's nothing in the draft that says the server must not leak the S2C and C2S keys, but there's also nothing that says servers can't expose an open SSH port and post their root password to Twitter. How about if I just call out, in the sections where the server sends cookies to the client through an encrypted channel, the fact that the client is going to send them back in the clear? > But it would help to also have some discussion about how NTS prevents the > control mode from being exploited for DoS, since this is the main vector > that NTP DoS amplification attacks exploit. That said, I don't think this > draft goes far enough regarding the security of the control mode, as I > mentioned in an earlier comment. NTS isn't designed to mitigate any existing DoS-amplification vulnerabilities in NTP, it's just meant not to create any new ones. If you're using the NTF implementation then you can avoid being an amplifier by putting their recommended restrict lines in your configuration file, and other implementations just don't support the amplification-prone messages to begin with. If you're sending amplification-prone messages over DTLS then at least, having successfully completed the handshake, you're proving you can read messages sent to your alleged source IP. But I'm not counting on this holding true forever, since any of various proposed IP mobility extensions to DTLS could easily falsify it. So, I really don't want to make any claim that NTS will buy you anything at all here. > Section 9.2: Verification of Server Certificates: > > I also like this section very much. Some clarification questions: > > The following paragraph should include some citations, so that readers can > better understand why the check works. As written it is too implementation > dependent. There should be a cite to what NTP_PHASE_MAX means and what > ntp_gettime() is expected to return. I'll see if I can dredge up something stable enough to cite. > Check whether the system time is in fact unreliable. If the > system clock has previously been synchronized since last boot, > then on operating systems which implement a kernel-based phase- > locked-loop API, a call to ntp_gettime() should show a maximum > error less than NTP_PHASE_MAX. In this case, the clock should be > considered reliable and certificates can be strictly validated. > > In the paragraph below, the term "strictly validated" needs to defined. Is > this paragraph suggesting validating time with a human? Or somethign else? Strictly validated = enforce the notBefore and notAfter fields with reference to the current system time. > The following two recommendations are so important. I think the draft > should elevate these recommendation to SHOULD and put it the TLS profile > section, rather than bury it in the security considerations section: > > Once the clock has been synchronized, periodically write the > current system time to persistent storage. Do not accept any > certificate whose notAfter field is earlier than the last recorded > time. > > Do not process time packets from servers if the time computed from > them falls outside the validity period of the server's > certificate. I hear you about maybe promoting these somehow, but the TLS profile section is the wrong place for them. > Section 9.4: (Delay attacks) > > I think the following sentence is false: > > However, the maximum error that an adversary > can introduce is bounded by half of the round trip delay. > > Why cannot an adversary delay the query an indefinate amount of time, and > then send it to the server, and then pass on the server's response? Eg > delay the query 1 hour, then send to the server, then let the response pass > by you unmolested. The error here would be huge (1 hour on the forward > path, and ms on the reverse path). > > Similarly I don't understand why the second paragraph of Section 9.4 is > true. > > [RFC5905] specifies a parameter called MAXDIST which denotes the > maximum round-trip latency (including not only the immediate round > trip between client and server but the whole distance back to the > reference clock as reported in the Root Delay field) that a client > will tolerate before concluding that the server is unsuitable for > synchronization. The standard value for MAXDIST is one second, > although some implementations use larger values. Whatever value a > client chooses, the maximum error which can be introduced by a delay > attack is MAXDIST/2. > > I suggest cutting both of these from the draft. Even if they were correct, > I don't think are important for the draft. It's probably not worth while > for us to argue about them. The argument here is: 1. Error is bounded by the half the round trip time, *inclusive* of any adversarially-induced delays. 2. Round trip time is in turn bounded by MAXDIST, because if it's longer than that then the packet won't be processed. I disagree with you about the importance of these. If the adversary can get away with delaying packets for arbitrary lengths of time without detection, then NTS isn't worth bothering with. > Section 9.5, suggested rewording: > > Whenever this draft specifies the use of random numbers, then > cryptographically > secure random number generation MUST be used. See [RFC4086] for > guidelines concerning > this topic. > > (I am worried about implementations that eg. will use ntp_random() which is > not cryptographically secure.) +1. > I like the MUST requirement here about implementation of > ntp-data-minimization. Given the amount of protocol mechanisms and > complexity we have introduced in order to provide unlinkability, its > important to also require that devices adhere to ntp-data-minimization if > they actually want unlinkability. I'm actually thinking of lower-casing the "MUST" and making the data minimization reference informative. You might want to argue this out with Jiangyuanlong. > > Also for this paragraph: > > It should also be noted that it could be possible to link devices > that operate as time servers from their time synchronization traffic, > using information exposed in (mode 4) server response packets (e.g. > reference ID, reference time, stratum, poll). Also, devices that > respond to NTP control queries could be linked using the information > revealed by control queries. > > Suggested expansion: > > It should also be noted that it could be possible to link devices > that operate as time servers from their time synchronization traffic, > using information exposed in (mode 4) server response packets (e.g. > reference ID, reference time, stratum, poll). Devices that do not > wish to be linked in this way SHOULD NOT respond to (mode 3) client > query packets from unknown IP addresses. > > Also, devices that respond to NTP control queries could be linked using > the information revealed by control queries. Devices that do not > wish to be linked in this way SHOULD NOT respond to control query > packets > from unknown IP addresses. +1. From ntp-bounces@ietf.org Thu Aug 31 12:19:42 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E7211329AD; Thu, 31 Aug 2017 12:19:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1504207182; bh=1qXD/uLMY9Ki75lcvbBm3JjeWwIJFBR23D7ofMwRlQg=; h=In-Reply-To:References:From:Date:To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc; b=fFbwvmc2UXMRFsKC9x3SSoaltPYkXNTC+d0Ijnr4jYkfOYoX7K+MGn0jNKveqdH0l RpW7xBhFpwUFIbIniSsFOp6HGn6JmAMHBE5rShgjv8O1ao8btH7gN8B86AfutUtABC t7e+aoOG33JlZZPO9ENGkhPZxI/cWPPxwBohj72E= 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 92C4F1329AD for ; Thu, 31 Aug 2017 12:19:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 8wc4C59_O3M0 for ; Thu, 31 Aug 2017 12:19:37 -0700 (PDT) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (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 1031E1321AE for ; Thu, 31 Aug 2017 12:19:37 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id f127so3442905wmf.1 for ; Thu, 31 Aug 2017 12:19:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HR0DOpRNdWTuLWd27Eo0wBDkWVoWAVgWZVAJ3Fi6I0E=; b=YIt/cJTCX95xJtV5yJ1qzOyEgX4gYV9ThFNca+2CCFFA+GgEQn7Mhb5rBWJ+y9FWEo 5mZxgzkeSb7ZNH6P+cgqIFfLUqLq7hiRagZSsDnQ6h3CBwUM/tk0cVH++8hAhYt+bsts m8HCityp0+718susZg1d9wMe4Ta0qU1HJ0oa7FgR1E3+NRw0KPaVeQuAJt68R89Kl7du x0x3aOB05MyjjvrgbnLD2ZcQYbKhjeyd8KslQkTvmqPRlEqnFdsj7JDNi/OeQP8Ws5KC mC8S0gR/MYA5H47ldByUd9pjfvyfb19lirQAIpW9tJXMwrxW6ICig8IZkWYRxh5o7wDf NL4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=HR0DOpRNdWTuLWd27Eo0wBDkWVoWAVgWZVAJ3Fi6I0E=; b=kFpbnLy1nWd1f1h6+58/C60Kpr/zggaxKN6/3Es4Pa/H2Q5Hhjc684bpa3HPkuZ/Lr VK95ZyR/S6TR96eqcz8Zs39aryZ1WkPSuk0Y/8K6uMYM1EZtlg9I4cfDxyeoZWaKTaO3 R2JipDSI5YEbT0XEyciKMPBa9jEVyy/qR4VEfALwwRqyyo0SMbIs5anUuK2HWZV8H6m3 ZFesl5u8URvg2r03yzr6sKgeLHyxRam9WvA0NcKK5Y8xu8uZHT64sdmmXNz19k6iTZP/ kqL+ypHTvUtJ25vLM5kf1s0S9wA74o8vDT3Lpq9m8FTF1JFtjTthEFZKnAXAJxplK+yY QCFA== X-Gm-Message-State: AHYfb5hX5vswnL+hCHz5h9Xd3AVGogFa38VA6LRtwyAFkqZABB4EibbM b3Au4xgWgjb7MK62za+4ZssiDWNx8pBHfyk= X-Google-Smtp-Source: ADKCNb4ENJmZxKTmi+3vsj4Us9MMXuqPZ8lgHE3DQG0Nj2JxVcqMRyuv98eAj0vp7CmlsFoAv03cTacOHgIZn5JpK1s= X-Received: by 10.80.186.82 with SMTP id 18mr2395624eds.86.1504207175122; Thu, 31 Aug 2017 12:19:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.157.140 with HTTP; Thu, 31 Aug 2017 12:19:34 -0700 (PDT) In-Reply-To: References: From: Daniel Franke Date: Thu, 31 Aug 2017 15:19:34 -0400 Message-ID: To: Sharon Goldberg Archived-At: Subject: Re: [Ntp] Sharon Goldberg comments on draft-ietf-ntp-using-nts-for-ntp X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: ntp@ietf.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ntp-bounces@ietf.org Sender: "ntp" On 8/31/17, Sharon Goldberg wrote: > Section 1.1: The unlinkablilty objective, as written, is misleading. NTS > only promises to not leak more linkability information that what is already > being leaked by NTP. As written that reader could assume that NTS > promises to fully guarantee unlinkability, which is false, since NTP could > make the session linkable. It's not sufficient to bury this point in the > security considerations section, so this should be reworded. Will do. > Section 1.2: Says: > > However, client-server mode also has more > relaxed security needs, because only the client requires replay > protection: it is harmless for servers to process replayed packets. > > This is false. > > It can be harmful for a server to process replayed packets if that server > keeps client state in order to perform rate limiting with a KoD. > Specifically, an adversary can replay client packets at high rate to the > server, in order to trigger rate-limint restrictions at the server and > cause the server to send a "RATE" KoD to the client. Once the client > receives this KoD, it will slow down or even stop its communications with > the server. In other words, this is a DoS attack. Good point. I'll restore the truth of this sentence by qualifying it with "stateless servers" and then discuss priming-the-pump in the security considerations. > For control mode (6), the party sending queries should be the DTLS > client and the party responding to the queries should be the DTLS > server. > > I think we are missing an opportunity here to secure the control mode, and > I'm not convinced that DTLS is the right approach. > > I would like to see this draft specify some way for servers to require > client authentication before answering control queries. There already is -- connect with a client certificate. This should be clearer after I finish updating in response to Miroslav's comments. > Section 5: > > Nit: > > Immediately following a successful handshake, the > client SHALL send a single request (as Application Data encapsulated > in the TLS-protected channel), then the server SHALL send a single > response followed by a TLS "Close notify" alert and then discard the > channel state. > > Maybe change this "MUST discard the channel state" (or SHOULD)? In order > to minimize the attack surface of someone compromising the server and then > using the old channel state that is sitting around in order to launch > attacks. 'send a single response followed by a TLS "close notify" alert and then discard the channel state' is already the intended predicate of SHALL (synonymous in RFC 2119 with MUST). Which part confused you -- my grammar, or the meaning of 'SHALL'? If the former I'll see if I can clarify. > - There are several "numbers" defined in this document, and it is hard for > the reader to disambiguate between them. Specifically, there is the "Next > Protocol number" and the "Field Type" and the "Record Number". The start of > Section 5 should start by telling the reader what are the different > "fields" and "types", and each of their purposes. I also suggest providing > references to the relevant IANA Considerations in Section 8. > > - This section would benefit by showing a ladder presenting the sequence of > communications and message types that go back and forth during a typical > NTS exchange. There was such a thing in previous drafts. I pulled it because it had gotten sufficiently out of sync with the spec that it was doing more harm than good. I'll see if I can come up with something new and better. I've cut out and not responded to a portion of your feedback below because it appears to the result of confusion that a better ladder diagram would alleviate. I.e., the type 1 error codes that you were worried about are exchanged during NTS-KE, and therefore protected by DTLS and can't be spoofed. NTS NAKs, on the other hand, are NTP packets. > 5.1.5 says: > > Server implementations of NTS extension fields for NTPv4 (Section 6) > MUST support AEAD_AES_SIV_CMAC_256 [RFC5297] (Numeric Identifier 15). > That is, if the client includes AEAD_AES_SIV_CMAC_256 in its AEAD > Algorithm Negotiation record, and the server accepts Protocol ID 0 > (NTPv4); in its NTS Next Protocol Negotiation record, then the > server's AEAD Algorithm Negotiation record MUST NOT be empty. > > Question: Does this mode of operation include any restrictions on how many > messages can be encrypted and authenticated? If so, this draft should > respect this restriction and require rekeying after that number of > message. If not, this draft should point to the place in RFC5297 where it > says that there is no such restriction, or point out that the restriction > is sufficiently high that we can never expect to exceed it. I'll see about adding some more discussion about this. RFC 5297 recommends a limit of 2**48 messages under a single key; most other algorithms are similar or worse. When you get up to 2**64, there's a 50% of a collision that will compromise secrecy, but not authentication on the two colliding messages (only). A stateless server can't be expected to keep a count of how many times a key has been used, but it can expire cookies with sufficient frequency that the 2**48 cap can never be hit in time due to CPU and/or bandwidth limitations. > Also, does the fact that RFC5297 is informational, while this draft is > standards track, create any issues for us? No. See, e.g., how RFC 5246 (TLS 1.2, Standards Track) has RFC 2104 (HMAC, Informational) as a normative reference. > Earlier on this list there was discussion on whether or not the draft > should specify normative requirements on cookies. Personally, I support > that view that we should place normative requirements on cookies, because > an insecure cookie implementation would break the security of the whole > protocol. > > That said, what is a show stopper in my opinion, is a lack of specification > in the draft of what properties are required from the cookie. At the very > least, we want to make sure that the cookie does not leak the C2S and S2C > keys to an observer (or a man in the middle). > > If I have misunderstood, and this confidentiality is provided because the > cookie is encrypted (as a MUST) by the AEAD scheme, then the draft should > make this point more clear in section 5.1.6. I don't think we can possibly enumerate every possible thing that the server must not do lest it compromise the security of the protocol. There's nothing in the draft that says the server must not leak the S2C and C2S keys, but there's also nothing that says servers can't expose an open SSH port and post their root password to Twitter. How about if I just call out, in the sections where the server sends cookies to the client through an encrypted channel, the fact that the client is going to send them back in the clear? > But it would help to also have some discussion about how NTS prevents the > control mode from being exploited for DoS, since this is the main vector > that NTP DoS amplification attacks exploit. That said, I don't think this > draft goes far enough regarding the security of the control mode, as I > mentioned in an earlier comment. NTS isn't designed to mitigate any existing DoS-amplification vulnerabilities in NTP, it's just meant not to create any new ones. If you're using the NTF implementation then you can avoid being an amplifier by putting their recommended restrict lines in your configuration file, and other implementations just don't support the amplification-prone messages to begin with. If you're sending amplification-prone messages over DTLS then at least, having successfully completed the handshake, you're proving you can read messages sent to your alleged source IP. But I'm not counting on this holding true forever, since any of various proposed IP mobility extensions to DTLS could easily falsify it. So, I really don't want to make any claim that NTS will buy you anything at all here. > Section 9.2: Verification of Server Certificates: > > I also like this section very much. Some clarification questions: > > The following paragraph should include some citations, so that readers can > better understand why the check works. As written it is too implementation > dependent. There should be a cite to what NTP_PHASE_MAX means and what > ntp_gettime() is expected to return. I'll see if I can dredge up something stable enough to cite. > Check whether the system time is in fact unreliable. If the > system clock has previously been synchronized since last boot, > then on operating systems which implement a kernel-based phase- > locked-loop API, a call to ntp_gettime() should show a maximum > error less than NTP_PHASE_MAX. In this case, the clock should be > considered reliable and certificates can be strictly validated. > > In the paragraph below, the term "strictly validated" needs to defined. Is > this paragraph suggesting validating time with a human? Or somethign else? Strictly validated = enforce the notBefore and notAfter fields with reference to the current system time. > The following two recommendations are so important. I think the draft > should elevate these recommendation to SHOULD and put it the TLS profile > section, rather than bury it in the security considerations section: > > Once the clock has been synchronized, periodically write the > current system time to persistent storage. Do not accept any > certificate whose notAfter field is earlier than the last recorded > time. > > Do not process time packets from servers if the time computed from > them falls outside the validity period of the server's > certificate. I hear you about maybe promoting these somehow, but the TLS profile section is the wrong place for them. > Section 9.4: (Delay attacks) > > I think the following sentence is false: > > However, the maximum error that an adversary > can introduce is bounded by half of the round trip delay. > > Why cannot an adversary delay the query an indefinate amount of time, and > then send it to the server, and then pass on the server's response? Eg > delay the query 1 hour, then send to the server, then let the response pass > by you unmolested. The error here would be huge (1 hour on the forward > path, and ms on the reverse path). > > Similarly I don't understand why the second paragraph of Section 9.4 is > true. > > [RFC5905] specifies a parameter called MAXDIST which denotes the > maximum round-trip latency (including not only the immediate round > trip between client and server but the whole distance back to the > reference clock as reported in the Root Delay field) that a client > will tolerate before concluding that the server is unsuitable for > synchronization. The standard value for MAXDIST is one second, > although some implementations use larger values. Whatever value a > client chooses, the maximum error which can be introduced by a delay > attack is MAXDIST/2. > > I suggest cutting both of these from the draft. Even if they were correct, > I don't think are important for the draft. It's probably not worth while > for us to argue about them. The argument here is: 1. Error is bounded by the half the round trip time, *inclusive* of any adversarially-induced delays. 2. Round trip time is in turn bounded by MAXDIST, because if it's longer than that then the packet won't be processed. I disagree with you about the importance of these. If the adversary can get away with delaying packets for arbitrary lengths of time without detection, then NTS isn't worth bothering with. > Section 9.5, suggested rewording: > > Whenever this draft specifies the use of random numbers, then > cryptographically > secure random number generation MUST be used. See [RFC4086] for > guidelines concerning > this topic. > > (I am worried about implementations that eg. will use ntp_random() which is > not cryptographically secure.) +1. > I like the MUST requirement here about implementation of > ntp-data-minimization. Given the amount of protocol mechanisms and > complexity we have introduced in order to provide unlinkability, its > important to also require that devices adhere to ntp-data-minimization if > they actually want unlinkability. I'm actually thinking of lower-casing the "MUST" and making the data minimization reference informative. You might want to argue this out with Jiangyuanlong. > > Also for this paragraph: > > It should also be noted that it could be possible to link devices > that operate as time servers from their time synchronization traffic, > using information exposed in (mode 4) server response packets (e.g. > reference ID, reference time, stratum, poll). Also, devices that > respond to NTP control queries could be linked using the information > revealed by control queries. > > Suggested expansion: > > It should also be noted that it could be possible to link devices > that operate as time servers from their time synchronization traffic, > using information exposed in (mode 4) server response packets (e.g. > reference ID, reference time, stratum, poll). Devices that do not > wish to be linked in this way SHOULD NOT respond to (mode 3) client > query packets from unknown IP addresses. > > Also, devices that respond to NTP control queries could be linked using > the information revealed by control queries. Devices that do not > wish to be linked in this way SHOULD NOT respond to control query > packets > from unknown IP addresses. +1. _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp From nobody Thu Aug 31 12:26:22 2017 Return-Path: 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 2C1D9132355 for ; Thu, 31 Aug 2017 12:26:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 GpNzp1owD6R5 for ; Thu, 31 Aug 2017 12:26:19 -0700 (PDT) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (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 3AAD1132939 for ; Thu, 31 Aug 2017 12:26:19 -0700 (PDT) Received: by mail-wm0-x22f.google.com with SMTP id 187so3470906wmn.1 for ; Thu, 31 Aug 2017 12:26:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wJvyc0TDz36vQjRIDRIP5F+7W3TJTt1STu6GIKS26GI=; b=NSXdl04KqqGK8NRUnHSvV5g86eMY/ehvtatIW2r2i6vLYILdVSDaLXJjvH5I+XQ4G6 R7gK0k9gHX3w/QWNVQyqxGjy8n5piwFg7wqHZOhNaEEKkNYznY3p2LoehZnHNWFPa3sx JJYT/MGIaJZBzulhvivq62j9cYzpsz8MdqH1hMwKVrdzPrGxEqBZA767EscTTjKkzp7Y 11osSnh07YKgYZm0Zcqlj9ScA8GQbgi04Lwpm+j3XbzGWeLUobhoD6+M6jgjJBXnRujc pnbcPjvTGKGwUfyIkwdN90NPrTCzz9fspt+pTBIbP1Iyv75+tYd+NdDpI8VdifNIQQ43 pDdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wJvyc0TDz36vQjRIDRIP5F+7W3TJTt1STu6GIKS26GI=; b=IAOGtROzSyzOENfWb2baP67v7IBIUadCDyBdjFqQ4Sbua+aIPYSHCPhipQIyCdZMIy qID5bdWOr2PdiLBwQ06YW9GcHRPu+/3G1wsbQ6SIyULQXpv0GYzSWGbzRzR0YaKa+1Gq cGmTYtGoNcPJ1M8WPv5gVmQEWoctUgvRBBi5HoEH0KcbQlzQxkKbziyLKUiH/5m391Y1 6wYCJAGd77OEH907xK32jq3kae9ZmYecnm2dL1Ohw2QziuFr5BHnHQ7mtvXtSNz5Xrcn CoQ5GDQp6sASNi1KVYLuhPYx3lU9ao46EVZrdjC8k7HuXslkTxn+dGbRbuo/8CWuo6lr /SHA== X-Gm-Message-State: AHYfb5iFjP4f5UZrdCJkNGW0k57Lc64yCmqgXYn0mQ0ay6U0IFkPMOXf K+dazjxKMLY4lHhiZHVmd0Lmwm8imHM6ch0= X-Google-Smtp-Source: ADKCNb7x+5sdDwyB2ilUvs7skJOHRW38NNgqSZtPH7KCy4JAXGm0sxSbMDhYIrnBtnwF1+E66RrDVJnSvRTvdGRGzwE= X-Received: by 10.80.186.82 with SMTP id 18mr2409211eds.86.1504207577693; Thu, 31 Aug 2017 12:26:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.157.140 with HTTP; Thu, 31 Aug 2017 12:26:16 -0700 (PDT) In-Reply-To: References: From: Daniel Franke Date: Thu, 31 Aug 2017 15:26:16 -0400 Message-ID: To: Sharon Goldberg Cc: ntp@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Ntp] Sharon Goldberg comments on draft-ietf-ntp-using-nts-for-ntp X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 19:26:21 -0000 On 8/31/17, Daniel Franke wrote: > I've cut out and not responded to a portion of your feedback below > because it appears to the result of confusion that a better ladder > diagram would alleviate. I.e., the type 1 error codes that you were > worried about are exchanged during NTS-KE, and therefore protected by > DTLS and can't be spoofed. NTS NAKs, on the other hand, are NTP > packets. Sorry for almost confusing you further -- that should have said TLS, not DTLS. From ntp-bounces@ietf.org Thu Aug 31 12:26:22 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AD7D132939; Thu, 31 Aug 2017 12:26:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1504207582; bh=U7K2wQJD1iGvqIzJBcG3EaM3nCI/eK6bcBndNp/QGH4=; h=In-Reply-To:References:From:Date:To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc; b=TPKjMQgJYzVU+NIykmwwQjVcsc5nCJFh7bSOrL1IQUr8vS42Bne/+TpCmsJq7mYUe vUhLeeytuS5scJdLkRxo6zvrYTbjnHoXNPvNfyf1cyaidQhuvzFHpyJ7/jah9uleI3 t9CzlymqQylOV00JrCRtdkr7Tv6DvBzvmQavErKQ= 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 2C1D9132355 for ; Thu, 31 Aug 2017 12:26:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 GpNzp1owD6R5 for ; Thu, 31 Aug 2017 12:26:19 -0700 (PDT) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (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 3AAD1132939 for ; Thu, 31 Aug 2017 12:26:19 -0700 (PDT) Received: by mail-wm0-x22f.google.com with SMTP id 187so3470906wmn.1 for ; Thu, 31 Aug 2017 12:26:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wJvyc0TDz36vQjRIDRIP5F+7W3TJTt1STu6GIKS26GI=; b=NSXdl04KqqGK8NRUnHSvV5g86eMY/ehvtatIW2r2i6vLYILdVSDaLXJjvH5I+XQ4G6 R7gK0k9gHX3w/QWNVQyqxGjy8n5piwFg7wqHZOhNaEEKkNYznY3p2LoehZnHNWFPa3sx JJYT/MGIaJZBzulhvivq62j9cYzpsz8MdqH1hMwKVrdzPrGxEqBZA767EscTTjKkzp7Y 11osSnh07YKgYZm0Zcqlj9ScA8GQbgi04Lwpm+j3XbzGWeLUobhoD6+M6jgjJBXnRujc pnbcPjvTGKGwUfyIkwdN90NPrTCzz9fspt+pTBIbP1Iyv75+tYd+NdDpI8VdifNIQQ43 pDdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wJvyc0TDz36vQjRIDRIP5F+7W3TJTt1STu6GIKS26GI=; b=IAOGtROzSyzOENfWb2baP67v7IBIUadCDyBdjFqQ4Sbua+aIPYSHCPhipQIyCdZMIy qID5bdWOr2PdiLBwQ06YW9GcHRPu+/3G1wsbQ6SIyULQXpv0GYzSWGbzRzR0YaKa+1Gq cGmTYtGoNcPJ1M8WPv5gVmQEWoctUgvRBBi5HoEH0KcbQlzQxkKbziyLKUiH/5m391Y1 6wYCJAGd77OEH907xK32jq3kae9ZmYecnm2dL1Ohw2QziuFr5BHnHQ7mtvXtSNz5Xrcn CoQ5GDQp6sASNi1KVYLuhPYx3lU9ao46EVZrdjC8k7HuXslkTxn+dGbRbuo/8CWuo6lr /SHA== X-Gm-Message-State: AHYfb5iFjP4f5UZrdCJkNGW0k57Lc64yCmqgXYn0mQ0ay6U0IFkPMOXf K+dazjxKMLY4lHhiZHVmd0Lmwm8imHM6ch0= X-Google-Smtp-Source: ADKCNb7x+5sdDwyB2ilUvs7skJOHRW38NNgqSZtPH7KCy4JAXGm0sxSbMDhYIrnBtnwF1+E66RrDVJnSvRTvdGRGzwE= X-Received: by 10.80.186.82 with SMTP id 18mr2409211eds.86.1504207577693; Thu, 31 Aug 2017 12:26:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.157.140 with HTTP; Thu, 31 Aug 2017 12:26:16 -0700 (PDT) In-Reply-To: References: From: Daniel Franke Date: Thu, 31 Aug 2017 15:26:16 -0400 Message-ID: To: Sharon Goldberg Archived-At: Subject: Re: [Ntp] Sharon Goldberg comments on draft-ietf-ntp-using-nts-for-ntp X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: ntp@ietf.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ntp-bounces@ietf.org Sender: "ntp" On 8/31/17, Daniel Franke wrote: > I've cut out and not responded to a portion of your feedback below > because it appears to the result of confusion that a better ladder > diagram would alleviate. I.e., the type 1 error codes that you were > worried about are exchanged during NTS-KE, and therefore protected by > DTLS and can't be spoofed. NTS NAKs, on the other hand, are NTP > packets. Sorry for almost confusing you further -- that should have said TLS, not DTLS. _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp From nobody Thu Aug 31 13:36:43 2017 Return-Path: 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 394E4132941; Thu, 31 Aug 2017 13:36:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 3pPHGzmXfrBn; Thu, 31 Aug 2017 13:36:39 -0700 (PDT) Received: from mx1.bs.ptb.de (mx1.bs.ptb.de [IPv6:2001:638:610:bd01::120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2311D13292C; Thu, 31 Aug 2017 13:36:38 -0700 (PDT) Received: from smtp-hub.bs.ptb.de (smtpint01.bs.ptb.de [141.25.87.32]) by mx1.bs.ptb.de with ESMTP id v7VKaaRM018459-v7VKaaRO018459 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 31 Aug 2017 22:36:36 +0200 Received: from lotus.bs.ptb.de (lotus.bs.ptb.de [141.25.85.200]) by smtp-hub.bs.ptb.de (Postfix) with ESMTPS id D903053545B; Thu, 31 Aug 2017 22:36:35 +0200 (CEST) MIME-Version: 1.0 Sensitivity: Importance: Normal X-Priority: 3 (Normal) In-Reply-To: <20170831140258.GV11067@localhost> References: <20170831140258.GV11067@localhost>, <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> <20170831091427.GT11067@localhost> From: dieter.sibold@ptb.de To: Miroslav Lichvar Cc: Daniel Franke , "ntp@ietf.org" , "tictoc@ietf.org" , Karen O'Donoghue Message-ID: Date: Thu, 31 Aug 2017 22:36:34 +0200 Content-Type: multipart/alternative; boundary="=_alternative 00713668C125818D_=" Archived-At: Subject: Re: [Ntp] WGLC for draft-ietf-ntp-using-nts-for-ntp X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 20:36:42 -0000 --=_alternative 00713668C125818D_= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Miroslav, please see my comment below -----"ntp" wrote: ----- >To: Daniel Franke >From: Miroslav Lichvar=20 >Sent by: "ntp"=20 >Date: 08/31/2017 16:03 >Cc: "ntp@ietf.org" , "tictoc@ietf.org" >, Karen O'Donoghue >Subject: Re: [Ntp] WGLC for draft-ietf-ntp-using-nts-for-ntp > >On Thu, Aug 31, 2017 at 08:34:02AM -0400, Daniel Franke wrote: >> Lots of people on this list seem to have the intuition that sending >> time packets over DTLS can never be as accurate as sending them >over >> the NTP port with an authenticator attached. But as I showed in my >> analysis the other day, that just ain't so. > >The problem is not with transmission. The problem as I see it is with >transport and reception. Encryption prevents modifications of the >packet in the network, which will be needed for delay corrections. >A different port number will not work with existing QoS in >switches/routers and hardware timestamping in NICs. I'm sure in some >cases reconfiguration to handle both ports will be possible, but >there >is HW where the port number is hardcoded in the firmware or silicon. >If there is a rarely used port for timing messages, will everyone >support it? I doubt that. The symmetric mode will not get all >benefits >of NTP support. > >If DTLS records were exchanged in NTP packets in extension fields, as >was originally considered by the design group, this wouldn't be a >problem. During the NTP interim meeting in Boston, Oct 2016 we had a thorough discus= sion of how to transport NTP's symmetric mode. At this time we had consensu= s to postpone the encapsulation of DTLS records within EF. Therefore, the d= raft represents the decisions take at that time. As Daniel pointed out. The= current scheme to protect the symmetric mode has no disadvantage regarding= time synchronization performance. I would guess that for the majority of m= ode 1/2 configuration it will work just well. It will certainly not work fo= r the special configuration you mentioned. But an alternative approach can = be specified, if future reveals that for any reason this is mandatory for t= he symmetric mode. But until that we should promote the current approach. > >> > My recommendation is to remove the specification of NTS in the >symmetric >> > mode from the document, at least for now. I believe the NTS-KE >used in >> > the client/server mode can be adopted for the symmetric mode, >possibly >> > with some small extensions, but it will take time. I think most >of us >> > here will agree it shouldn't delay the adoption of NTS in the >> > client/server mode. >>=20 >> If specification for symmetric mode were removed, how would section >4 >> read? Do you want to get rid of DTLS encapsulation altogether? >> Restrict what traffic can be sent over it? Can you send a PR with >what >> you have in mind? (Won't promise to merge it, but I'll review it) > >I'm not sure. I think the whole section could be limited to the >control (6) mode. The other modes (1, 2, 3, 4, 5, 7) can be >allowed, but not recommended. In the broadcast mode I think it >doesn't >make much sense anyway. > >> The >> identity in that certificate is the additional information you're >> looking for. > >Ok, thanks. > >--=20 >Miroslav Lichvar > >=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F >ntp mailing list >ntp@ietf.org >https://www.ietf.org/mailman/listinfo/ntp > --=_alternative 00713668C125818D_= Content-Type: text/html; charset=UTF-8 Content-ID: <> Content-Transfer-Encoding: quoted-printable
Miroslav, please see my comment below



-----"ntp" <ntp-bounces@ietf.org> wrote: -----=

>To: Danie= l Franke <df= oxfranke@gmail.com>
>From: Miroslav= Lichvar
>Sent by: "ntp"
>Date: 08/31/2017 16:03
><tictoc@ietf.org>, Karen O'Donoghue <odonoghue@isoc.org= >
>Subject: Re: [Ntp] WGLC for draft-ie= tf-ntp-using-nts-for-ntp
>
>On Thu, Aug 31, 2017 at 08:34:02AM -0400, Daniel Franke = wrote:
>> Lots of people on this list s= eem to have the intuition that sending
>&g= t; time packets over DTLS can never be as accurate as sending them
>over
>> the N= TP port with an authenticator attached. But as I showed in my
>> analysis the other day, that just ain't so.
>
>The problem= is not with transmission. The problem as I see it is with
>transport and reception. Encryption prevents modification= s of the
>packet in the network, which wil= l be needed for delay corrections.
>A diff= erent port number will not work with existing QoS in
>switches/routers and hardware timestamping in NICs. I'm sure in= some
>cases reconfiguration to handle bot= h ports will be possible, but
>there
>is HW where the port number is hardcoded in th= e firmware or silicon.
>If there is a rare= ly used port for timing messages, will everyone
>support it? I doubt that. The symmetric mode will not get all
>benefits
>of N= TP support.
>
>was originally considered by the design = group, this wouldn't be a
>problem.

During the NTP inter= im meeting in Boston, Oct 2016 we had a thorough discussion of how to trans= port NTP's symmetric mode. At this time we had consensus to postpone the en= capsulation of DTLS records within EF. Therefore, the draft represents the = decisions take at that time. As Daniel pointed out. The current scheme to p= rotect the symmetric mode has no disadvantage regarding time synchronizatio= n performance. I would guess that for the majority of mode 1/2 configuratio= n it will work just well. It will certainly not work for the special config= uration you mentioned. But an alternative approach can be specified, if fut= ure reveals that for any reason this is mandatory for the symmetric mode. B= ut until that we should promote the current approach.

>
>= > > My recommendation is to remove the specification of NTS in the
>symmetric
>= ;> > mode from the document, at least for now. I believe the NTS-KE
>used in
>= > > the client/server mode can be adopted for the symmetric mode,
=
>possibly
>&= gt; > with some small extensions, but it will take time. I think most
>of us
>>= ; > here will agree it shouldn't delay the adoption of NTS in the
>> > client/server mode.
>>
>> If specificat= ion for symmetric mode were removed, how would section
>4
>> read? Do you want t= o get rid of DTLS encapsulation altogether?
&= gt;> Restrict what traffic can be sent over it? Can you send a PR with
>what
>>= ; you have in mind? (Won't promise to merge it, but I'll review it)
>
>I'm not sure.= I think the whole section could be limited to the
>control (6) mode. The other modes (1, 2, 3, 4, 5, 7) can be
>allowed, but not recommended. In the broadcast= mode I think it
>doesn't
>make much sense anyway.
>= ;
>> The
= >> identity in that certificate is the additional information you're<= br>
>> looking for.
>
>Ok, thanks.
>
>--
>Miroslav Lichvar
>
>=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F
>ntp mailing list
>
--=_alternative 00713668C125818D_=-- From ntp-bounces@ietf.org Thu Aug 31 13:36:44 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FB10132A0D; Thu, 31 Aug 2017 13:36:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1504211804; bh=C5dTPH5vcqLbvgTUZu8n9RGb3vis1oMUDJdWAmjwZmk=; h=In-Reply-To:References:From:To:Date:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc; b=WnMnbvYOD6aVYCSbviSB4rSZAJb2zNwoAfoTSSfalTtRKUC5wEvmREktDrxOJD0PK bT0KLy3qBoJSNlnkIbVb1Cp+dHj5gB1z5YfahGIrpJVLBqyq9U9QdIr3WXtEUMxSYw JlNHBuLhCeRLzMEbIVpJd9Ny+bzcAvxTkZy1tuNY= 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 394E4132941; Thu, 31 Aug 2017 13:36:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 3pPHGzmXfrBn; Thu, 31 Aug 2017 13:36:39 -0700 (PDT) Received: from mx1.bs.ptb.de (mx1.bs.ptb.de [IPv6:2001:638:610:bd01::120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2311D13292C; Thu, 31 Aug 2017 13:36:38 -0700 (PDT) Received: from smtp-hub.bs.ptb.de (smtpint01.bs.ptb.de [141.25.87.32]) by mx1.bs.ptb.de with ESMTP id v7VKaaRM018459-v7VKaaRO018459 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 31 Aug 2017 22:36:36 +0200 Received: from lotus.bs.ptb.de (lotus.bs.ptb.de [141.25.85.200]) by smtp-hub.bs.ptb.de (Postfix) with ESMTPS id D903053545B; Thu, 31 Aug 2017 22:36:35 +0200 (CEST) MIME-Version: 1.0 Sensitivity: Importance: Normal X-Priority: 3 (Normal) In-Reply-To: <20170831140258.GV11067@localhost> References: <20170831140258.GV11067@localhost>, <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> <20170831091427.GT11067@localhost> From: dieter.sibold@ptb.de To: Miroslav Lichvar Message-ID: Date: Thu, 31 Aug 2017 22:36:34 +0200 Archived-At: Subject: Re: [Ntp] WGLC for draft-ietf-ntp-using-nts-for-ntp X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "ntp@ietf.org" , Daniel Franke , Karen O'Donoghue , "tictoc@ietf.org" Content-Type: multipart/mixed; boundary="===============2040414169163900721==" Errors-To: ntp-bounces@ietf.org Sender: "ntp" --===============2040414169163900721== Content-Type: multipart/alternative; boundary="=_alternative 00713668C125818D_=" --=_alternative 00713668C125818D_= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Miroslav, please see my comment below -----"ntp" wrote: ----- >To: Daniel Franke >From: Miroslav Lichvar=20 >Sent by: "ntp"=20 >Date: 08/31/2017 16:03 >Cc: "ntp@ietf.org" , "tictoc@ietf.org" >, Karen O'Donoghue >Subject: Re: [Ntp] WGLC for draft-ietf-ntp-using-nts-for-ntp > >On Thu, Aug 31, 2017 at 08:34:02AM -0400, Daniel Franke wrote: >> Lots of people on this list seem to have the intuition that sending >> time packets over DTLS can never be as accurate as sending them >over >> the NTP port with an authenticator attached. But as I showed in my >> analysis the other day, that just ain't so. > >The problem is not with transmission. The problem as I see it is with >transport and reception. Encryption prevents modifications of the >packet in the network, which will be needed for delay corrections. >A different port number will not work with existing QoS in >switches/routers and hardware timestamping in NICs. I'm sure in some >cases reconfiguration to handle both ports will be possible, but >there >is HW where the port number is hardcoded in the firmware or silicon. >If there is a rarely used port for timing messages, will everyone >support it? I doubt that. The symmetric mode will not get all >benefits >of NTP support. > >If DTLS records were exchanged in NTP packets in extension fields, as >was originally considered by the design group, this wouldn't be a >problem. During the NTP interim meeting in Boston, Oct 2016 we had a thorough discus= sion of how to transport NTP's symmetric mode. At this time we had consensu= s to postpone the encapsulation of DTLS records within EF. Therefore, the d= raft represents the decisions take at that time. As Daniel pointed out. The= current scheme to protect the symmetric mode has no disadvantage regarding= time synchronization performance. I would guess that for the majority of m= ode 1/2 configuration it will work just well. It will certainly not work fo= r the special configuration you mentioned. But an alternative approach can = be specified, if future reveals that for any reason this is mandatory for t= he symmetric mode. But until that we should promote the current approach. > >> > My recommendation is to remove the specification of NTS in the >symmetric >> > mode from the document, at least for now. I believe the NTS-KE >used in >> > the client/server mode can be adopted for the symmetric mode, >possibly >> > with some small extensions, but it will take time. I think most >of us >> > here will agree it shouldn't delay the adoption of NTS in the >> > client/server mode. >>=20 >> If specification for symmetric mode were removed, how would section >4 >> read? Do you want to get rid of DTLS encapsulation altogether? >> Restrict what traffic can be sent over it? Can you send a PR with >what >> you have in mind? (Won't promise to merge it, but I'll review it) > >I'm not sure. I think the whole section could be limited to the >control (6) mode. The other modes (1, 2, 3, 4, 5, 7) can be >allowed, but not recommended. In the broadcast mode I think it >doesn't >make much sense anyway. > >> The >> identity in that certificate is the additional information you're >> looking for. > >Ok, thanks. > >--=20 >Miroslav Lichvar > >=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F >ntp mailing list >ntp@ietf.org >https://www.ietf.org/mailman/listinfo/ntp > --=_alternative 00713668C125818D_= Content-Type: text/html; charset=UTF-8 Content-ID: <> Content-Transfer-Encoding: quoted-printable
Miroslav, please see my comment below



-----"ntp" <ntp-bounces@ietf.org> wrote: -----=

>To: Danie= l Franke <df= oxfranke@gmail.com>
>From: Miroslav= Lichvar
>Sent by: "ntp"
>Date: 08/31/2017 16:03
><tictoc@ietf.org>, Karen O'Donoghue <odonoghue@isoc.org= >
>Subject: Re: [Ntp] WGLC for draft-ie= tf-ntp-using-nts-for-ntp
>
>On Thu, Aug 31, 2017 at 08:34:02AM -0400, Daniel Franke = wrote:
>> Lots of people on this list s= eem to have the intuition that sending
>&g= t; time packets over DTLS can never be as accurate as sending them
>over
>> the N= TP port with an authenticator attached. But as I showed in my
>> analysis the other day, that just ain't so.
>
>The problem= is not with transmission. The problem as I see it is with
>transport and reception. Encryption prevents modification= s of the
>packet in the network, which wil= l be needed for delay corrections.
>A diff= erent port number will not work with existing QoS in
>switches/routers and hardware timestamping in NICs. I'm sure in= some
>cases reconfiguration to handle bot= h ports will be possible, but
>there
>is HW where the port number is hardcoded in th= e firmware or silicon.
>If there is a rare= ly used port for timing messages, will everyone
>support it? I doubt that. The symmetric mode will not get all
>benefits
>of N= TP support.
>
>was originally considered by the design = group, this wouldn't be a
>problem.

During the NTP inter= im meeting in Boston, Oct 2016 we had a thorough discussion of how to trans= port NTP's symmetric mode. At this time we had consensus to postpone the en= capsulation of DTLS records within EF. Therefore, the draft represents the = decisions take at that time. As Daniel pointed out. The current scheme to p= rotect the symmetric mode has no disadvantage regarding time synchronizatio= n performance. I would guess that for the majority of mode 1/2 configuratio= n it will work just well. It will certainly not work for the special config= uration you mentioned. But an alternative approach can be specified, if fut= ure reveals that for any reason this is mandatory for the symmetric mode. B= ut until that we should promote the current approach.

>
>= > > My recommendation is to remove the specification of NTS in the
>symmetric
>= ;> > mode from the document, at least for now. I believe the NTS-KE
>used in
>= > > the client/server mode can be adopted for the symmetric mode,
=
>possibly
>&= gt; > with some small extensions, but it will take time. I think most
>of us
>>= ; > here will agree it shouldn't delay the adoption of NTS in the
>> > client/server mode.
>>
>> If specificat= ion for symmetric mode were removed, how would section
>4
>> read? Do you want t= o get rid of DTLS encapsulation altogether?
&= gt;> Restrict what traffic can be sent over it? Can you send a PR with
>what
>>= ; you have in mind? (Won't promise to merge it, but I'll review it)
>
>I'm not sure.= I think the whole section could be limited to the
>control (6) mode. The other modes (1, 2, 3, 4, 5, 7) can be
>allowed, but not recommended. In the broadcast= mode I think it
>doesn't
>make much sense anyway.
>= ;
>> The
= >> identity in that certificate is the additional information you're<= br>
>> looking for.
>
>Ok, thanks.
>
>--
>Miroslav Lichvar
>
>=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F
>ntp mailing list
>
--=_alternative 00713668C125818D_=-- --===============2040414169163900721== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp --===============2040414169163900721==-- From nobody Thu Aug 31 13:49:36 2017 Return-Path: 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 3F9CB13248B for ; Thu, 31 Aug 2017 13:49:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.207 X-Spam-Level: X-Spam-Status: No, score=-1.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RDNS_NONE=0.793, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rellim.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 RNtUWsHKdg60 for ; Thu, 31 Aug 2017 13:49:32 -0700 (PDT) Received: from spidey.rellim.com (unknown [IPv6:2001:470:e815::19]) (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 C50BC1326EA for ; Thu, 31 Aug 2017 13:49:31 -0700 (PDT) Received: from spidey.rellim.com (dave.rellim.com [IPv6:2001:470:e815:0:0:0:0:19] (may be forged)) (authenticated bits=0) by spidey.rellim.com (8.15.2/8.15.2) with ESMTPSA id v7VKnOZe020624 (version=TLSv1.2 cipher=DHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Thu, 31 Aug 2017 13:49:29 -0700 DKIM-Filter: OpenDKIM Filter v2.10.3 spidey.rellim.com v7VKnOZe020624 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=rellim.com; s=kong; t=1504212569; bh=kK3tJT6jyF3u1QQxKcFZkZXxTTsUlN3B3mAgZiPU88o=; h=Date:From:To:Subject:In-Reply-To:References; b=fubJ2jDWdee5RVBtn9gkqN0V20CLZzD20+zh9nUc74q0CoVO+6XMOWzgwEnivEJoj Fzff9RkWiXar6H7gPvhF6zjV9nsXSrK8fu92NnWBENQwTNXMRVwWMrv8T1f3bWQChu PtYr4kHT1HGX9Wn1nEzz1EdVX5InU5YqEKuvJqpQ= Date: Thu, 31 Aug 2017 13:49:24 -0700 From: "Gary E. Miller" To: ntp@ietf.org Message-ID: <20170831134924.793e9b15@spidey.rellim.com> In-Reply-To: References: Organization: Rellim X-Mailer: Claws Mail 3.15.0-dirty (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/mfgThu_TUc5VG0aJTi5kUfb"; protocol="application/pgp-signature" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (spidey.rellim.com [IPv6:2001:470:e815:0:0:0:0:19]); Thu, 31 Aug 2017 13:49:29 -0700 (PDT) Archived-At: Subject: Re: [Ntp] Sharon Goldberg comments on draft-ietf-ntp-using-nts-for-ntp X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 20:49:36 -0000 --Sig_/mfgThu_TUc5VG0aJTi5kUfb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yo Sharon! On Thu, 31 Aug 2017 13:13:52 -0400 Sharon Goldberg wrote: > This is a fairly detailed review, that raises several issues. That > said, I still don't have a complete understanding of how the > client-server NTS protocol works or of its security properties,=20 [...] I'm a bit uncomfortable standardizing any protocol without an existing reference implementation. One of the "founding beliefs" is embodied in an early quote about the IETF from David Clark: "We reject kings, presidents and voting. We believe in rough consensus and running code". https://www.ietf.org/tao.html I'd like to see some running code. RGDS GARY --------------------------------------------------------------------------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 gem@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can=E2=80=99t measure it, you can=E2=80=99t improve it." - Lord= Kelvin --Sig_/mfgThu_TUc5VG0aJTi5kUfb Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEENqCjEoytAEAuFCk8DQ7ZSUHRedgFAlmodlQACgkQDQ7ZSUHR edi3mwgAkODZFSAdjaGyB2yvexr9Sgjmf5V+tveOdb9hEZcJA59H+IqmxelBEZBL ifbeesDCJvwBe0yUyq744A3AG/fmXARwRE2Dq5cjSNDQrsW7rNsIBVOcTD68+haX jafqwou4Q35Wi1c3XZIJcJ8A1RhQp/MiaDhewc8ZcEBFYaam4krHgvoxwB+Wph/+ Tmu+19qTKXmhfDPqZ+vHHKc+FdbovhIIT7TMF1zKSP4KkzZ4x4mvyvYCKBXp+wNk arSqkYyvXi7DBgyM0kXLYJgAz/hbyXyU/LQfHUMn1sOlyhDvJWTItfxlV1JjUUum NhUorjUE7ESZ24kanAP15mlqDHzqVQ== =1qsu -----END PGP SIGNATURE----- --Sig_/mfgThu_TUc5VG0aJTi5kUfb-- From ntp-bounces@ietf.org Thu Aug 31 13:49:37 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AB3B2132223; Thu, 31 Aug 2017 13:49:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1504212577; bh=pRXUTAT4CtIiHkUoISqD6yYpLabHgVThMl2YCtHrz6s=; h=Date:From:To:In-Reply-To:References:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe; b=vpR/HaNPyd8RXTlbcQczMQHFpjNuKB1ipTQZcRqnr3TaeQptlE7hIpEZ3KMJo7Y+u H1M+fXniMcIK5tin+XHzqYRdfmse9cwYhOnYPX/5l5LyiPgvm1fWhJHLffTOWmCUl7 p1tuT8rivXAc92p9b8fCl8TL9fYVGjIj8i3H9w30= 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 3F9CB13248B for ; Thu, 31 Aug 2017 13:49:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.207 X-Spam-Level: X-Spam-Status: No, score=-1.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RDNS_NONE=0.793, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rellim.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 RNtUWsHKdg60 for ; Thu, 31 Aug 2017 13:49:32 -0700 (PDT) Received: from spidey.rellim.com (unknown [IPv6:2001:470:e815::19]) (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 C50BC1326EA for ; Thu, 31 Aug 2017 13:49:31 -0700 (PDT) Received: from spidey.rellim.com (dave.rellim.com [IPv6:2001:470:e815:0:0:0:0:19] (may be forged)) (authenticated bits=0) by spidey.rellim.com (8.15.2/8.15.2) with ESMTPSA id v7VKnOZe020624 (version=TLSv1.2 cipher=DHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Thu, 31 Aug 2017 13:49:29 -0700 DKIM-Filter: OpenDKIM Filter v2.10.3 spidey.rellim.com v7VKnOZe020624 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=rellim.com; s=kong; t=1504212569; bh=kK3tJT6jyF3u1QQxKcFZkZXxTTsUlN3B3mAgZiPU88o=; h=Date:From:To:Subject:In-Reply-To:References; b=fubJ2jDWdee5RVBtn9gkqN0V20CLZzD20+zh9nUc74q0CoVO+6XMOWzgwEnivEJoj Fzff9RkWiXar6H7gPvhF6zjV9nsXSrK8fu92NnWBENQwTNXMRVwWMrv8T1f3bWQChu PtYr4kHT1HGX9Wn1nEzz1EdVX5InU5YqEKuvJqpQ= Date: Thu, 31 Aug 2017 13:49:24 -0700 From: "Gary E. Miller" To: ntp@ietf.org Message-ID: <20170831134924.793e9b15@spidey.rellim.com> In-Reply-To: References: Organization: Rellim X-Mailer: Claws Mail 3.15.0-dirty (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (spidey.rellim.com [IPv6:2001:470:e815:0:0:0:0:19]); Thu, 31 Aug 2017 13:49:29 -0700 (PDT) Archived-At: Subject: Re: [Ntp] Sharon Goldberg comments on draft-ietf-ntp-using-nts-for-ntp X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1056582847461603596==" Errors-To: ntp-bounces@ietf.org Sender: "ntp" --===============1056582847461603596== Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/mfgThu_TUc5VG0aJTi5kUfb"; protocol="application/pgp-signature" --Sig_/mfgThu_TUc5VG0aJTi5kUfb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yo Sharon! On Thu, 31 Aug 2017 13:13:52 -0400 Sharon Goldberg wrote: > This is a fairly detailed review, that raises several issues. That > said, I still don't have a complete understanding of how the > client-server NTS protocol works or of its security properties,=20 [...] I'm a bit uncomfortable standardizing any protocol without an existing reference implementation. One of the "founding beliefs" is embodied in an early quote about the IETF from David Clark: "We reject kings, presidents and voting. We believe in rough consensus and running code". https://www.ietf.org/tao.html I'd like to see some running code. RGDS GARY --------------------------------------------------------------------------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 gem@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can=E2=80=99t measure it, you can=E2=80=99t improve it." - Lord= Kelvin --Sig_/mfgThu_TUc5VG0aJTi5kUfb Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEENqCjEoytAEAuFCk8DQ7ZSUHRedgFAlmodlQACgkQDQ7ZSUHR edi3mwgAkODZFSAdjaGyB2yvexr9Sgjmf5V+tveOdb9hEZcJA59H+IqmxelBEZBL ifbeesDCJvwBe0yUyq744A3AG/fmXARwRE2Dq5cjSNDQrsW7rNsIBVOcTD68+haX jafqwou4Q35Wi1c3XZIJcJ8A1RhQp/MiaDhewc8ZcEBFYaam4krHgvoxwB+Wph/+ Tmu+19qTKXmhfDPqZ+vHHKc+FdbovhIIT7TMF1zKSP4KkzZ4x4mvyvYCKBXp+wNk arSqkYyvXi7DBgyM0kXLYJgAz/hbyXyU/LQfHUMn1sOlyhDvJWTItfxlV1JjUUum NhUorjUE7ESZ24kanAP15mlqDHzqVQ== =1qsu -----END PGP SIGNATURE----- --Sig_/mfgThu_TUc5VG0aJTi5kUfb-- --===============1056582847461603596== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp --===============1056582847461603596==-- From ntp-bounces@ietf.org Thu Aug 31 15:18:47 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3167B132FB0; Thu, 31 Aug 2017 15:18:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1504217927; bh=2TuuPjxN8h2JYZulVhQUkOfI6iGjq3NSv362FCUNCT0=; h=Date:From:In-Reply-To:References:Subject:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:Cc; b=kLblf9r3iIjJNVqcyTDbJTPA8GHj0g6MzkPv8jUInXA1gIEzbj448vb8jempGH4k8 jWUmLnmrxOufL2D4vtxJkf4x52fb6hpVRWApaCaxNeICW36eSmni9mpu/rYGq6JvwV 67iTJ27GorIPvq13GQz43TvyjHAyGEXE6kzkTryg= 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 910BE132F6D; Thu, 31 Aug 2017 15:18:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.979 X-Spam-Level: X-Spam-Status: No, score=-0.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MISSING_HEADERS=1.021, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rellim.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 Xgo8qGBXlXEt; Thu, 31 Aug 2017 15:18:44 -0700 (PDT) Received: from spidey.rellim.com (rellim.com [IPv6:2001:470:e815::19]) (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 46F54132FAB; Thu, 31 Aug 2017 15:18:44 -0700 (PDT) Received: from spidey.rellim.com (rellim.com [IPv6:2001:470:e815:0:0:0:0:19]) (authenticated bits=0) by spidey.rellim.com (8.15.2/8.15.2) with ESMTPSA id v7VMIcaX027038 (version=TLSv1.2 cipher=DHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 31 Aug 2017 15:18:43 -0700 DKIM-Filter: OpenDKIM Filter v2.10.3 spidey.rellim.com v7VMIcaX027038 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=rellim.com; s=kong; t=1504217923; bh=OZX1Q0o67cS66EdrvU21TfXvkalJV2pyCugKXI/H3w8=; h=Date:From:Cc:Subject:In-Reply-To:References; b=PUCmp7bG9tXYh7Lvmxu7UDWvNJxkCJ3l7/uL9cvBN0D/9Saa02+6NLdXIGjcbkGUb vDunV8+PidXz021ajgklxzFBcQ2HRUO+izUq6Kx5drUlz3zcwcBzvNSL3nVWGKEgtn c1PtgzqvjIUX56opL3OzowF5YO+dBu6PxRHQOE5s= Date: Thu, 31 Aug 2017 15:18:37 -0700 From: "Gary E. Miller" Message-ID: <20170831151837.535c0ee2@spidey.rellim.com> In-Reply-To: References: <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> <20170831091427.GT11067@localhost> Organization: Rellim X-Mailer: Claws Mail 3.15.0-dirty (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (spidey.rellim.com [IPv6:2001:470:e815:0:0:0:0:19]); Thu, 31 Aug 2017 15:18:43 -0700 (PDT) Archived-At: Subject: Re: [Ntp] WGLC for draft-ietf-ntp-using-nts-for-ntp X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "ntp@ietf.org" , "tictoc@ietf.org" Content-Type: multipart/mixed; boundary="===============2500296186675437921==" Errors-To: ntp-bounces@ietf.org Sender: "ntp" --===============2500296186675437921== Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/DdEgsE0MI/6jDr5Q6nmkuUG"; protocol="application/pgp-signature" --Sig_/DdEgsE0MI/6jDr5Q6nmkuUG Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yo Daniel! On Thu, 31 Aug 2017 08:34:02 -0400 Daniel Franke wrote: > Lots of people on this list seem to have the intuition that sending > time packets over DTLS can never be as accurate as sending them over > the NTP port with an authenticator attached. But as I showed in my > analysis the other day, that just ain't so. Analysis is great, but I'd like to see running code. RGDS GARY --------------------------------------------------------------------------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 gem@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can=E2=80=99t measure it, you can=E2=80=99t improve it." - Lord= Kelvin --Sig_/DdEgsE0MI/6jDr5Q6nmkuUG Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEENqCjEoytAEAuFCk8DQ7ZSUHRedgFAlmoiz4ACgkQDQ7ZSUHR edhFxAf/QPNrBdGbFQHq/xVBbHCpg1I+TpuXlBJW/EiLJ8XeTtBzQqtHxJQtctl+ 0daELlzvmJh3/m00z8TiijY8VRJUcrKLxFZ9RZtp7M1OojHKsz1ouwA99hkHe8E7 ER/3PapgCvF2yjhGPPRFwqojAHgo5W8AwIhSkNrw3lIrw3k8wz8g99pOGvHXudzz TxKLvEnSRgFM6LBRMLedkT8i41ILOx+7Po/BpDDfM4Vp0EVH3NX25aiZ5XICFSao 5ZAOGWLXlVz9wOOq1pB0UgWhcUHkwvH661Me9gL3SdJLaV9xOLfWxxPvdOkS81RT LCmSBEe/zge1UUgh1AIf55SvjOEPzg== =OAp5 -----END PGP SIGNATURE----- --Sig_/DdEgsE0MI/6jDr5Q6nmkuUG-- --===============2500296186675437921== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp --===============2500296186675437921==-- From nobody Thu Aug 31 15:18:48 2017 Return-Path: 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 910BE132F6D; Thu, 31 Aug 2017 15:18:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.979 X-Spam-Level: X-Spam-Status: No, score=-0.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MISSING_HEADERS=1.021, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rellim.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 Xgo8qGBXlXEt; Thu, 31 Aug 2017 15:18:44 -0700 (PDT) Received: from spidey.rellim.com (rellim.com [IPv6:2001:470:e815::19]) (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 46F54132FAB; Thu, 31 Aug 2017 15:18:44 -0700 (PDT) Received: from spidey.rellim.com (rellim.com [IPv6:2001:470:e815:0:0:0:0:19]) (authenticated bits=0) by spidey.rellim.com (8.15.2/8.15.2) with ESMTPSA id v7VMIcaX027038 (version=TLSv1.2 cipher=DHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 31 Aug 2017 15:18:43 -0700 DKIM-Filter: OpenDKIM Filter v2.10.3 spidey.rellim.com v7VMIcaX027038 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=rellim.com; s=kong; t=1504217923; bh=OZX1Q0o67cS66EdrvU21TfXvkalJV2pyCugKXI/H3w8=; h=Date:From:Cc:Subject:In-Reply-To:References; b=PUCmp7bG9tXYh7Lvmxu7UDWvNJxkCJ3l7/uL9cvBN0D/9Saa02+6NLdXIGjcbkGUb vDunV8+PidXz021ajgklxzFBcQ2HRUO+izUq6Kx5drUlz3zcwcBzvNSL3nVWGKEgtn c1PtgzqvjIUX56opL3OzowF5YO+dBu6PxRHQOE5s= Date: Thu, 31 Aug 2017 15:18:37 -0700 From: "Gary E. Miller" Cc: "ntp@ietf.org" , "tictoc@ietf.org" Message-ID: <20170831151837.535c0ee2@spidey.rellim.com> In-Reply-To: References: <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> <20170831091427.GT11067@localhost> Organization: Rellim X-Mailer: Claws Mail 3.15.0-dirty (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/DdEgsE0MI/6jDr5Q6nmkuUG"; protocol="application/pgp-signature" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (spidey.rellim.com [IPv6:2001:470:e815:0:0:0:0:19]); Thu, 31 Aug 2017 15:18:43 -0700 (PDT) Archived-At: Subject: Re: [Ntp] WGLC for draft-ietf-ntp-using-nts-for-ntp X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 22:18:45 -0000 --Sig_/DdEgsE0MI/6jDr5Q6nmkuUG Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yo Daniel! On Thu, 31 Aug 2017 08:34:02 -0400 Daniel Franke wrote: > Lots of people on this list seem to have the intuition that sending > time packets over DTLS can never be as accurate as sending them over > the NTP port with an authenticator attached. But as I showed in my > analysis the other day, that just ain't so. Analysis is great, but I'd like to see running code. RGDS GARY --------------------------------------------------------------------------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 gem@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can=E2=80=99t measure it, you can=E2=80=99t improve it." - Lord= Kelvin --Sig_/DdEgsE0MI/6jDr5Q6nmkuUG Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEENqCjEoytAEAuFCk8DQ7ZSUHRedgFAlmoiz4ACgkQDQ7ZSUHR edhFxAf/QPNrBdGbFQHq/xVBbHCpg1I+TpuXlBJW/EiLJ8XeTtBzQqtHxJQtctl+ 0daELlzvmJh3/m00z8TiijY8VRJUcrKLxFZ9RZtp7M1OojHKsz1ouwA99hkHe8E7 ER/3PapgCvF2yjhGPPRFwqojAHgo5W8AwIhSkNrw3lIrw3k8wz8g99pOGvHXudzz TxKLvEnSRgFM6LBRMLedkT8i41ILOx+7Po/BpDDfM4Vp0EVH3NX25aiZ5XICFSao 5ZAOGWLXlVz9wOOq1pB0UgWhcUHkwvH661Me9gL3SdJLaV9xOLfWxxPvdOkS81RT LCmSBEe/zge1UUgh1AIf55SvjOEPzg== =OAp5 -----END PGP SIGNATURE----- --Sig_/DdEgsE0MI/6jDr5Q6nmkuUG-- From ntp-bounces@ietf.org Thu Aug 31 17:19:54 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ADF16133128; Thu, 31 Aug 2017 17:19:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1504225194; bh=eg1ox/pof0OjHxXUqQPkFM406NJC2dwBdE8fIavGN5I=; h=From:To:Date:References:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc; b=XC7NMlKiGWYB82yofG9gFOridvKTj5aIASoKLprhls3rBDUYXkgtgPBV6uzB9CZSa mgpOKs/wqTnPF1ZlLn4mnOlYebLF9jea2kBZb861ENUXbBw8e1Brf1J1oNHMWoVQKa Q35U9a4q4nHRH+i6dQupTjR1i0f6LoEIj9JlNnJg= 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 2F60213310E; Thu, 31 Aug 2017 17:19:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 HRWRYOdMkcA1; Thu, 31 Aug 2017 17:19:50 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59B5E132F2E; Thu, 31 Aug 2017 17:19:49 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DUO06930; Fri, 01 Sep 2017 00:19:47 +0000 (GMT) Received: from DGGEML406-HUB.china.huawei.com (10.3.17.50) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 1 Sep 2017 01:19:46 +0100 Received: from DGGEML507-MBX.china.huawei.com ([169.254.2.7]) by dggeml406-hub.china.huawei.com ([10.3.17.50]) with mapi id 14.03.0301.000; Fri, 1 Sep 2017 08:19:37 +0800 From: Jiangyuanlong To: Daniel Franke Thread-Topic: [Ntp] WGLC for draft-ietf-ntp-using-nts-for-ntp Thread-Index: AQHTEMnCM2s3Nc34m0O8jzUH1rPjTqKd5GhQgAAh9YCAAUarEA== Date: Fri, 1 Sep 2017 00:19:37 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68BBB59A767@dggeml507-mbx.china.huawei.com> References: <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> <3B0A1BED22CAD649A1B3E97BE5DDD68BBB59A424@dggeml507-mbx.china.huawei.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.46.31.248] MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.59A8A7A3.0154, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.2.7, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 5001f724e99e429273661cae8bee9248 Archived-At: Subject: Re: [Ntp] WGLC for draft-ietf-ntp-using-nts-for-ntp X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Aanchal Malhotra , "ntp@ietf.org" , "tictoc@ietf.org" , Karen O'Donoghue , Sharon Goldberg Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ntp-bounces@ietf.org Sender: "ntp" Daniel, that also works. BTW, you need not give the exact version of the WG draft, but tag it as "in progress". Cheers, Yuanlong > -----Original Message----- > From: Daniel Franke [mailto:dfoxfranke@gmail.com] > Sent: Thursday, August 31, 2017 8:45 PM > To: Jiangyuanlong > Cc: Karen O'Donoghue; ntp@ietf.org; tictoc@ietf.org; Sharon Goldberg; > Aanchal Malhotra > Subject: Re: [Ntp] WGLC for draft-ietf-ntp-using-nts-for-ntp > > On 8/31/17, Jiangyuanlong wrote: > > Hi, after going through this draft, I am not sure whether > > ietf-ntp-data-minimization-00 should be listed in the Normative > > Reference, or not at all. > > I was *just* about to bring this up myself. I think it's properly an informative > reference. > > Sharon, Aanchal, CCing the two of you because I recall you had a different > opinion last year in Boston and thought it should stay a normative reference > (but I'm not sure I understood you correctly then). Note that this is a > completely separate issue from whether data minimization should be > published as Standards Track vs. Informational. > It can stay a Standards Track document and still be cited from NTS for > Informative purposes. _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp From nobody Thu Aug 31 17:19:58 2017 Return-Path: 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 2F60213310E; Thu, 31 Aug 2017 17:19:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 HRWRYOdMkcA1; Thu, 31 Aug 2017 17:19:50 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59B5E132F2E; Thu, 31 Aug 2017 17:19:49 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DUO06930; Fri, 01 Sep 2017 00:19:47 +0000 (GMT) Received: from DGGEML406-HUB.china.huawei.com (10.3.17.50) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 1 Sep 2017 01:19:46 +0100 Received: from DGGEML507-MBX.china.huawei.com ([169.254.2.7]) by dggeml406-hub.china.huawei.com ([10.3.17.50]) with mapi id 14.03.0301.000; Fri, 1 Sep 2017 08:19:37 +0800 From: Jiangyuanlong To: Daniel Franke CC: "Karen O'Donoghue" , "ntp@ietf.org" , "tictoc@ietf.org" , Sharon Goldberg , Aanchal Malhotra Thread-Topic: [Ntp] WGLC for draft-ietf-ntp-using-nts-for-ntp Thread-Index: AQHTEMnCM2s3Nc34m0O8jzUH1rPjTqKd5GhQgAAh9YCAAUarEA== Date: Fri, 1 Sep 2017 00:19:37 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68BBB59A767@dggeml507-mbx.china.huawei.com> References: <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> <3B0A1BED22CAD649A1B3E97BE5DDD68BBB59A424@dggeml507-mbx.china.huawei.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.46.31.248] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.59A8A7A3.0154, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.2.7, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 5001f724e99e429273661cae8bee9248 Archived-At: Subject: Re: [Ntp] WGLC for draft-ietf-ntp-using-nts-for-ntp X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Sep 2017 00:19:52 -0000 RGFuaWVsLCB0aGF0IGFsc28gd29ya3MuIEJUVywgeW91IG5lZWQgbm90IGdpdmUgdGhlIGV4YWN0 IHZlcnNpb24gb2YgdGhlIFdHIGRyYWZ0LCBidXQgdGFnIGl0IGFzICJpbiBwcm9ncmVzcyIuDQoN CkNoZWVycywNCll1YW5sb25nDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJv bTogRGFuaWVsIEZyYW5rZSBbbWFpbHRvOmRmb3hmcmFua2VAZ21haWwuY29tXQ0KPiBTZW50OiBU aHVyc2RheSwgQXVndXN0IDMxLCAyMDE3IDg6NDUgUE0NCj4gVG86IEppYW5neXVhbmxvbmcNCj4g Q2M6IEthcmVuIE8nRG9ub2dodWU7IG50cEBpZXRmLm9yZzsgdGljdG9jQGlldGYub3JnOyBTaGFy b24gR29sZGJlcmc7DQo+IEFhbmNoYWwgTWFsaG90cmENCj4gU3ViamVjdDogUmU6IFtOdHBdIFdH TEMgZm9yIGRyYWZ0LWlldGYtbnRwLXVzaW5nLW50cy1mb3ItbnRwDQo+IA0KPiBPbiA4LzMxLzE3 LCBKaWFuZ3l1YW5sb25nIDxqaWFuZ3l1YW5sb25nQGh1YXdlaS5jb20+IHdyb3RlOg0KPiA+IEhp LCBhZnRlciBnb2luZyB0aHJvdWdoIHRoaXMgZHJhZnQsIEkgYW0gbm90IHN1cmUgd2hldGhlcg0K PiA+IGlldGYtbnRwLWRhdGEtbWluaW1pemF0aW9uLTAwIHNob3VsZCBiZSBsaXN0ZWQgaW4gdGhl IE5vcm1hdGl2ZQ0KPiA+IFJlZmVyZW5jZSwgb3Igbm90IGF0IGFsbC4NCj4gDQo+IEkgd2FzICpq dXN0KiBhYm91dCB0byBicmluZyB0aGlzIHVwIG15c2VsZi4gSSB0aGluayBpdCdzIHByb3Blcmx5 IGFuIGluZm9ybWF0aXZlDQo+IHJlZmVyZW5jZS4NCj4gDQo+IFNoYXJvbiwgQWFuY2hhbCwgQ0Np bmcgdGhlIHR3byBvZiB5b3UgYmVjYXVzZSBJIHJlY2FsbCB5b3UgaGFkIGEgZGlmZmVyZW50DQo+ IG9waW5pb24gbGFzdCB5ZWFyIGluIEJvc3RvbiBhbmQgdGhvdWdodCBpdCBzaG91bGQgc3RheSBh IG5vcm1hdGl2ZSByZWZlcmVuY2UNCj4gKGJ1dCBJJ20gbm90IHN1cmUgSSB1bmRlcnN0b29kIHlv dSBjb3JyZWN0bHkgdGhlbikuIE5vdGUgdGhhdCB0aGlzIGlzIGENCj4gY29tcGxldGVseSBzZXBh cmF0ZSBpc3N1ZSBmcm9tIHdoZXRoZXIgZGF0YSBtaW5pbWl6YXRpb24gc2hvdWxkIGJlDQo+IHB1 Ymxpc2hlZCBhcyBTdGFuZGFyZHMgVHJhY2sgdnMuIEluZm9ybWF0aW9uYWwuDQo+IEl0IGNhbiBz dGF5IGEgU3RhbmRhcmRzIFRyYWNrIGRvY3VtZW50IGFuZCBzdGlsbCBiZSBjaXRlZCBmcm9tIE5U UyBmb3INCj4gSW5mb3JtYXRpdmUgcHVycG9zZXMuDQo= From ntp-bounces@ietf.org Thu Aug 31 17:27:53 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 00859133012; Thu, 31 Aug 2017 17:27:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1504225673; bh=ry9KvuQEymN9W5bzgvCamV8JYigou3l3ByKBVjQnTXs=; h=In-Reply-To:References:From:Date:To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc; b=Ly6JcMSrWYVDMaB0gkp43atRR2JbBAIq5jsaifZZ+y6rec4TsvcW72Se/qNTYlw1c J3yNuBsiPbVkMJHXISbWUWgr8uvaVf0GqZzZOam3OcRzSsw1bIXyRTttgNijvR9jIE pIuaEceDISkT7OVgSf7nC+RX9FWij3+o5pSWkDZ8= 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 3B0E0132F79 for ; Thu, 31 Aug 2017 17:27:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 CbHWybKagy-x for ; Thu, 31 Aug 2017 17:27:49 -0700 (PDT) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (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 23622132946 for ; Thu, 31 Aug 2017 17:27:49 -0700 (PDT) Received: by mail-wm0-x232.google.com with SMTP id u26so6669649wma.0 for ; Thu, 31 Aug 2017 17:27:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=688aR4lgrtKaaUUlUkC5G7+u9fzgyzp2YCxq87rRBRY=; b=eXbvCENDjIXQAGi05JfPTTr+mdGvjvaNFWncZLkmumA6h90XeQoitmAz4QzZDazaJ8 hVDQfzHdBBtlC37EB++xCHUbZ8EZc05aXKJ+mpslwN9DkoDem+Tadk2OAC3s1azf5eFi CSX5aCZVPi+E05bsOnlTzKDpK96fUVuypf16XT/e/6APQw0YXh2rk+WZAcnkR7MAOcmq gQ9AOgUtnuZczmBZUjVeovSpVSBsqAdWejn7UW/UV2Vp5NnCykygcg22iMDuLe39dGF3 7WJHdrV0CW7KW89ycLIHqW02V1yHmcOXq/wfhTOlLWxFyblXXgcbb+xH+P2OaYJfMby7 ShEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=688aR4lgrtKaaUUlUkC5G7+u9fzgyzp2YCxq87rRBRY=; b=WDDW9hgk3/DLA9EXMg7H/TvMUVX0faBxSgwodnQAyQ1cJdYqVtgHBGJlqO3S43stdX YT6bE+YjzZtAS0e4/e/e7VPzUUjzMpOgDX44zcnn9CaOWusBjknbHLjH5yguWCEptFJ3 mLGAk7Sl3yETJTyPLZTW2ToMnHsK3m4s39GOMuwoUgCOiFe13uE5HVdOwDBpfgnNxKlo 9o5rUbKL5jvoQV4hIgkniYCT0pmSKDebf6yp1GDJkRTod/P6gnlSw678shZ1oPOo/2bU tgXO65VV/+R13h+voyuNWX9iviU8El5dTTCbJvRK7gtnnnhw5hGK3CHEzJpYTNLG08hV Iy+w== X-Gm-Message-State: AHPjjUjYlmuCsefL1IG+CKYNE4FvXglyq9Sn/lMbh3otWcrZXuCVVlrO 4OWRFbUF6qGMHW8Xvo6RaX31GlREKw== X-Google-Smtp-Source: ADKCNb7ZDkXX8f/aAC8nyGkIxrvNllnQF4fngE26lhE8zccyF7rNLaDAXIP07kUntyjp+LWgCecAaaAAyBe2tdPU91I= X-Received: by 10.80.215.29 with SMTP id t29mr155451edi.141.1504225667593; Thu, 31 Aug 2017 17:27:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.157.140 with HTTP; Thu, 31 Aug 2017 17:27:46 -0700 (PDT) In-Reply-To: References: <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> <20170831091427.GT11067@localhost> From: Daniel Franke Date: Thu, 31 Aug 2017 20:27:46 -0400 Message-ID: To: Miroslav Lichvar , Sharon Goldberg Archived-At: Subject: Re: [Ntp] WGLC for draft-ietf-ntp-using-nts-for-ntp X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "ntp@ietf.org" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ntp-bounces@ietf.org Sender: "ntp" Miroslav, I just pushed a bunch of new detail in section 4 to git. Let me know what you think of it and whether it affects your vote. Sharon, I still need to incorporate your feedback. I'm in the middle of doing new diagrams. _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp From nobody Thu Aug 31 17:27:53 2017 Return-Path: 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 3B0E0132F79 for ; Thu, 31 Aug 2017 17:27:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 CbHWybKagy-x for ; Thu, 31 Aug 2017 17:27:49 -0700 (PDT) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (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 23622132946 for ; Thu, 31 Aug 2017 17:27:49 -0700 (PDT) Received: by mail-wm0-x232.google.com with SMTP id u26so6669649wma.0 for ; Thu, 31 Aug 2017 17:27:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=688aR4lgrtKaaUUlUkC5G7+u9fzgyzp2YCxq87rRBRY=; b=eXbvCENDjIXQAGi05JfPTTr+mdGvjvaNFWncZLkmumA6h90XeQoitmAz4QzZDazaJ8 hVDQfzHdBBtlC37EB++xCHUbZ8EZc05aXKJ+mpslwN9DkoDem+Tadk2OAC3s1azf5eFi CSX5aCZVPi+E05bsOnlTzKDpK96fUVuypf16XT/e/6APQw0YXh2rk+WZAcnkR7MAOcmq gQ9AOgUtnuZczmBZUjVeovSpVSBsqAdWejn7UW/UV2Vp5NnCykygcg22iMDuLe39dGF3 7WJHdrV0CW7KW89ycLIHqW02V1yHmcOXq/wfhTOlLWxFyblXXgcbb+xH+P2OaYJfMby7 ShEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=688aR4lgrtKaaUUlUkC5G7+u9fzgyzp2YCxq87rRBRY=; b=WDDW9hgk3/DLA9EXMg7H/TvMUVX0faBxSgwodnQAyQ1cJdYqVtgHBGJlqO3S43stdX YT6bE+YjzZtAS0e4/e/e7VPzUUjzMpOgDX44zcnn9CaOWusBjknbHLjH5yguWCEptFJ3 mLGAk7Sl3yETJTyPLZTW2ToMnHsK3m4s39GOMuwoUgCOiFe13uE5HVdOwDBpfgnNxKlo 9o5rUbKL5jvoQV4hIgkniYCT0pmSKDebf6yp1GDJkRTod/P6gnlSw678shZ1oPOo/2bU tgXO65VV/+R13h+voyuNWX9iviU8El5dTTCbJvRK7gtnnnhw5hGK3CHEzJpYTNLG08hV Iy+w== X-Gm-Message-State: AHPjjUjYlmuCsefL1IG+CKYNE4FvXglyq9Sn/lMbh3otWcrZXuCVVlrO 4OWRFbUF6qGMHW8Xvo6RaX31GlREKw== X-Google-Smtp-Source: ADKCNb7ZDkXX8f/aAC8nyGkIxrvNllnQF4fngE26lhE8zccyF7rNLaDAXIP07kUntyjp+LWgCecAaaAAyBe2tdPU91I= X-Received: by 10.80.215.29 with SMTP id t29mr155451edi.141.1504225667593; Thu, 31 Aug 2017 17:27:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.157.140 with HTTP; Thu, 31 Aug 2017 17:27:46 -0700 (PDT) In-Reply-To: References: <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> <20170831091427.GT11067@localhost> From: Daniel Franke Date: Thu, 31 Aug 2017 20:27:46 -0400 Message-ID: To: Miroslav Lichvar , Sharon Goldberg Cc: "ntp@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Ntp] WGLC for draft-ietf-ntp-using-nts-for-ntp X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Sep 2017 00:27:52 -0000 Miroslav, I just pushed a bunch of new detail in section 4 to git. Let me know what you think of it and whether it affects your vote. Sharon, I still need to incorporate your feedback. I'm in the middle of doing new diagrams. From nobody Thu Aug 31 23:43:48 2017 Return-Path: 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 1DF851332C1 for ; Thu, 31 Aug 2017 23:43:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no 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 ISbQugj0gsrD for ; Thu, 31 Aug 2017 23:43:44 -0700 (PDT) Received: from rrzmta2.uni-regensburg.de (rrzmta2.uni-regensburg.de [194.94.155.52]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D4C91332C0 for ; Thu, 31 Aug 2017 23:43:43 -0700 (PDT) Received: from rrzmta2.uni-regensburg.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 975D472FFC for ; Fri, 1 Sep 2017 08:43:42 +0200 (CEST) Received: from gwsmtp1.uni-regensburg.de (gwsmtp1.uni-regensburg.de [132.199.5.51]) by rrzmta2.uni-regensburg.de (Postfix) with ESMTP id 726C772E88 for ; Fri, 1 Sep 2017 08:43:42 +0200 (CEST) Received: from uni-regensburg-smtp1-MTA by gwsmtp1.uni-regensburg.de with Novell_GroupWise; Fri, 01 Sep 2017 08:43:42 +0200 Message-Id: <59A9019C020000A100027B2F@gwsmtp1.uni-regensburg.de> X-Mailer: Novell GroupWise Internet Agent 14.2.2 Date: Fri, 01 Sep 2017 08:43:40 +0200 From: "Ulrich Windl" To: ,"ntp@ietf.org" References: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Archived-At: Subject: [Ntp] Antw: Sharon Goldberg comments on draft-ietf-ntp-using-nts-for-ntp X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Sep 2017 06:43:46 -0000 >>> Sharon Goldberg schrieb am 31.08.2017 um 19:13 in = Nachricht : [...] > The following paragraph should include some citations, so that readers = can > better understand why the check works. As written it is too implementatio= n > dependent. There should be a cite to what NTP_PHASE_MAX means and what > ntp_gettime() is expected to return. >=20 >=20 > Check whether the system time is in fact unreliable. If the > system clock has previously been synchronized since last boot, > then on operating systems which implement a kernel-based phase- > locked-loop API, a call to ntp_gettime() should show a maximum > error less than NTP_PHASE_MAX. In this case, the clock should be > considered reliable and certificates can be strictly validated. >=20 [...] I'm also unhappy with that, because it uses a mechanism that is widely = outside of the NTP specification: ntp_gettime() is not part of the NTP RFC = ("RFC 1589: A Kernel Model for Precision Timekeeping" is informational), = nor is the kernel clock model (AFAIK). Even if it were, there is no = guarantee that NTP is the only party that may set the kernel variables, = meaning the "maximum error" could be unreliable. Regards, Ulrich From ntp-bounces@ietf.org Thu Aug 31 23:43:48 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 901441332C2; Thu, 31 Aug 2017 23:43:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1504248228; bh=YquTG2GO/y7j7J76iSwnx+i32jtmKXIUWRwpv60uhSM=; h=Date:From:To:References:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe; b=JtvC0tsR8uoKG8B+Q4sPEE58Frou6Vp2NTfvvSdo8wOjaNEWsGt9dwGPmbM9tEEPf 5NUr85VJBWMMoKPPWR7tb1X+3i3CP4/EQukwFqb/jHqaOxmo8z5w+s28g+zGhZIiXq LqNi4e05YMPSrJUC1rri+/E82DmB/SNLd+bdfZmY= 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 1DF851332C1 for ; Thu, 31 Aug 2017 23:43:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no 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 ISbQugj0gsrD for ; Thu, 31 Aug 2017 23:43:44 -0700 (PDT) Received: from rrzmta2.uni-regensburg.de (rrzmta2.uni-regensburg.de [194.94.155.52]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D4C91332C0 for ; Thu, 31 Aug 2017 23:43:43 -0700 (PDT) Received: from rrzmta2.uni-regensburg.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 975D472FFC for ; Fri, 1 Sep 2017 08:43:42 +0200 (CEST) Received: from gwsmtp1.uni-regensburg.de (gwsmtp1.uni-regensburg.de [132.199.5.51]) by rrzmta2.uni-regensburg.de (Postfix) with ESMTP id 726C772E88 for ; Fri, 1 Sep 2017 08:43:42 +0200 (CEST) Received: from uni-regensburg-smtp1-MTA by gwsmtp1.uni-regensburg.de with Novell_GroupWise; Fri, 01 Sep 2017 08:43:42 +0200 Message-Id: <59A9019C020000A100027B2F@gwsmtp1.uni-regensburg.de> X-Mailer: Novell GroupWise Internet Agent 14.2.2 Date: Fri, 01 Sep 2017 08:43:40 +0200 From: "Ulrich Windl" To: ,"ntp@ietf.org" References: In-Reply-To: Mime-Version: 1.0 Content-Disposition: inline Archived-At: Subject: [Ntp] Antw: Sharon Goldberg comments on draft-ietf-ntp-using-nts-for-ntp X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ntp-bounces@ietf.org Sender: "ntp" >>> Sharon Goldberg schrieb am 31.08.2017 um 19:13 in Nachricht : [...] > The following paragraph should include some citations, so that readers can > better understand why the check works. As written it is too implementation > dependent. There should be a cite to what NTP_PHASE_MAX means and what > ntp_gettime() is expected to return. > > > Check whether the system time is in fact unreliable. If the > system clock has previously been synchronized since last boot, > then on operating systems which implement a kernel-based phase- > locked-loop API, a call to ntp_gettime() should show a maximum > error less than NTP_PHASE_MAX. In this case, the clock should be > considered reliable and certificates can be strictly validated. > [...] I'm also unhappy with that, because it uses a mechanism that is widely outside of the NTP specification: ntp_gettime() is not part of the NTP RFC ("RFC 1589: A Kernel Model for Precision Timekeeping" is informational), nor is the kernel clock model (AFAIK). Even if it were, there is no guarantee that NTP is the only party that may set the kernel variables, meaning the "maximum error" could be unreliable. Regards, Ulrich _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp