Return-Path: X-Original-To: ntp@mail2.ietf.org Delivered-To: ntp@mail2.ietf.org Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 11C8255509D2 for ; Mon, 18 Aug 2025 01:49:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -4.397 X-Spam-Level: X-Spam-Status: No, score=-4.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=ptb.de Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mPBbw25719Gx for ; Mon, 18 Aug 2025 01:49:15 -0700 (PDT) Received: from mx1.bs.ptb.de (mx1.bs.ptb.de [192.53.103.120]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 50E1955509CA for ; Mon, 18 Aug 2025 01:49:15 -0700 (PDT) Received: from s23397.bs.ptb.de ([172.21.101.132]) by mx1.bs.ptb.de with ESMTPS id 57I8ml0n006784-57I8ml0p006784 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=OK); Mon, 18 Aug 2025 10:48:47 +0200 In-Reply-To: <205d39f7-44d1-4cbd-ba8e-dfac04a90f01@nwtime.org> References: <2a81e8be-3214-406e-91f6-320f62a6c3e4@nwtime.org> <92576df4-71b3-4634-9a6f-49d5393095bd@ntp.org> To: "Harlan Stenn" MIME-Version: 1.0 From: kristof.teichel@ptb.de Message-ID: Date: Mon, 18 Aug 2025 10:48:46 +0200 Content-Type: multipart/alternative; boundary="=_alternative 00306901C1258CEA_=" X-FEAS-Client-IP: 172.21.101.132 X-FE-Policy-ID: 5:5:5:SYSTEM DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=ptb.de; s=s1-ptbde; c=relaxed/relaxed; h=references:to:cc:mime-version:subject:from:message-id:date:content-type; bh=vCfJwgBMcMt/BB3UqEDV86DD1m96XZBq8WKvn9GWnEU=; b=WXf1ZfOLsbwVuESxGxXmEPqt7/POaynS+iTPKSP2lieA0aVONxL5kGyupM4a4DcVzfDr3kmlKqIL oAXSBFQOemkh7HGYeAyqJUX7cYS2fxt3xDg0xvFZs3jaIOuEVKAPbVXNVmAocnhWTaqT1QMy1QnT mzF88HIykXNfLYYsvbveb5/CoG/UO/UMD8DlnZuu91xiEMSLh7y+UuKLGEPb8RTRE+NpWYm7rK3w 6bT1o8+X/iCLUqYr0sEy6hXOOTYx18YdkGZZfz3Gj/F7UEcBX1I7XtHZDX3FFjRQY3zi81io3gWI 7GwuUFUmRRwKfodV+8BvTbkyE8mx2mIDP6EnwQ== Message-ID-Hash: MKJF7MGB22J2AEHA3HJAO4OSTXBYRUJU X-Message-ID-Hash: MKJF7MGB22J2AEHA3HJAO4OSTXBYRUJU X-MailFrom: kristof.teichel@ptb.de X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-ntp.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: "iana-prot-param-comment@iana.org" , NTP WG , "Salz, Rich" X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5BNtp=5D_Re=3A_=5BIANA_=231413181=5D_NTP_Extension_Field_addition?= =?utf-8?q?s=2C_and_IANA_NTP_table_management_process_=28ntp-parameters=29?= List-Id: Network Time Protocol Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: Dies ist eine mehrteilige Nachricht im MIME-Format. --=_alternative 00306901C1258CEA_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable 1) Compatibility problem: I don't believe this one was unclear in the slightest, especially since it = is follwowing Miroslav's argument, who quoted with reference: > Quoting from section 2 of > https://datatracker.ietf.org/doc/html/draft-stenn-ntp-mac-last-ef-04: > > In the example below the Field Length in the LAST-EF is 4, because > there is clearly no need in this case for the 28 octets required by > RFC 7822 [RFC7822]. But the LAST-EF could have any supported length, > as any payload is ignored. Do you wish to debate that this poses an incompatibility with=20 RFC7822-compliant implementations? Because that discussion hardly seems productive, or in-good-faith. (You could BTW just choose to make it RFC7822-compliant with a one-liner,=20 or arguably by just not going out of your way to make clear that you don't = think 7822 should be followed here) 2) Problem with potential harm to the NTP (or even NTP-external)=20 ecosystem: This one is harder to pin down, because it concerns I-DO ( https://datatracker.ietf.org/doc/html/draft-stenn-ntp-i-do-06),=20 specifically the interaction between an "offer" and a "response" (or=20 "I-DO-RESPONSE", or "I-Do Response") message, which is not documented all=20 that well in that document version. (Response is mentioned from page 3, an offer -or the fact that there is a=20 dichotomy offer/response- seems is mentioned from page 5...) But there is this (Section 2.3 "Behavior", bottom of page 5): > Any system that receives an I-Do "offer", 0x0007, SHOULD reply with > an I-Do "response", 0x8007. > > Any system that sends an I-Do "offer" or "response" may send as few > or as many of its supported Field Types as it chooses. ...and this seems to me completely at odds with our policy of preventing=20 amplification attacks by ensuring that one cannot provoke a longer reply=20 by sending a shorter request. It might be argued that with two-octet identifiers and a manageable number = of potential EF types, this shouldn't be a big deal; but I think it has=20 potential for problems (in theory, a response EF could be 2^16*2 bytes,=20 which meets and exceeds any reasonable max packet length, in response to a = minimal-length offer EF which would be like 4-8 bytes). I think this is easily fixable (e.g. make it so a response MUST NOT=20 include anything not already offered in the offer), but you would have to=20 do that. Besten Gru=DF / Kind regards, Kristof Teichel =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F Dr.-Ing. Kurt Kristof Teichel Physikalisch-Technische Bundesanstalt (PTB)=20 Arbeitsgruppe 4.42 "Zeit=FCbertragung" Bundesallee 100 38116 Braunschweig (Germany) Tel.: +49 (531) 592-4471 E-Mail: kristof.teichel@ptb.de =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F Von: "Harlan Stenn" An: kristof.teichel@ptb.de, "Salz, Rich" Kopie: "iana-prot-param-comment@iana.org"=20 , "NTP WG" Datum: 15.08.2025 09:47 Betreff: Re: [Ntp] Re: [IANA #1413181] NTP Extension Field=20 additions, and IANA NTP table management process (ntp-parameters) On 8/15/2025 2:41 AM, kristof.teichel=3D40ptb.de@dmarc.ietf.org wrote: > I will interject to remind that while I am arguing procedure (need for=20 > clearer specification because IETF says so), I am also arguing some=20 > substance: > The documentation we do have suggests that parts of the intended=20 > mechanism are incompatible with existing specification documents, and=20 > also allows suspicion that parts of the intended mechanism might be=20 > damaging to the whole ecosystem where it would be deployed (see my mail=20 > from July 10th). For each of the requested EF types for which I have requested=20 allocation, please identify which EF type requests you think are OK, and=20 which EF types have a specification that you believe has a problem. Please specifically identify each place you think has a problem. Thanks... H > From what I understand, these are expressly the types of problems that=20 > DEs should watch out for in this process. >=20 >=20 > Besten Gru=DF / Kind regards, > Kristof Teichel >=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 >=20 > Dr.-Ing. Kurt Kristof Teichel > Physikalisch-Technische Bundesanstalt (PTB) > Arbeitsgruppe 4.42 "Zeit=FCbertragung" > Bundesallee 100 > 38116 Braunschweig (Germany) > Tel.: +49 (531) 592-4471 > E-Mail: kristof.teichel@ptb.de > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F >=20 >=20 >=20 > Von: "Salz, Rich" > An: "Harlan Stenn" , "iana-prot-=20 > param-comment@iana.org" > Kopie: "NTP WG" > Datum: 14.08.2025 15:40 > Betreff: [Ntp] Re: [IANA #1413181] NTP Extension Field additions, and=20 > IANA NTP table management process (ntp-parameters) > ------------------------------------------------------------------------ >=20 >=20 > * The metaphor for what is happening now is that I am registering the > * owner of a plot of land. The DEs are apparently asking for detailed > * building plans. >=20 >=20 > It is not fair to ?blame? the DEs for this. RFC 9748, which updated the=20 > NTP Registries requires a specification [1]. That document is an IETF=20 > consensus document and they are just doing as directed. >=20 > [1] =5Fhttps://www.rfc-editor.org/rfc/rfc9748.html#name-designated-=20 > experts=5F experts>=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=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 > To unsubscribe send an email to ntp-leave@ietf.org --=20 Harlan Stenn http://networktimefoundation.org - be a member! --=_alternative 00306901C1258CEA_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable 1) Compatibility problem:
I don't believe this one was unclear in the slightest, especially since it is follwowing Miroslav's argument, who quoted with reference:

> Quoting from section 2 of
> https://datatracker.ietf.org/doc/html/draft-stenn-ntp-mac-last-ef-04:
>
>   In the example below the Field Length in the LAST-EF is 4, because
>   there is clearly no need in this case for the 28 octets required by
>   RFC 7822 [RFC7822].  But the LAST-EF could have any suppor= ted length,
>   as any payload is ignored.

Do you wish to debate that this poses an incompatibility with RFC7822-compliant implementa= tions?
Because that dis= cussion hardly seems productive, or in-good-faith.
(You could BTW just choose to make it RFC7822-compliant with a one-liner, or arguably by just not going out of your way to make clear that you don't think 7822 should be followed here)

2) Problem with potential harm to the NTP (or even NTP-external) ecosystem:
This one is hard= er to pin down, because it concerns I-DO (https://datatracker.ietf.org/doc/html/d= raft-stenn-ntp-i-do-06), specifically the interaction between an "offer" and a "respo= nse" (or "I-DO-RESPONSE", or "I-Do Response") message, which is not documented all that well in that document version.
(Response is men= tioned from page 3, an offer -or the fact that there is a dichotomy offer/response- seems is mentioned from page 5...)
But there is this (Section 2.3 "Behavior", bottom of page 5):

> Any system that receives an I-Do "offer", 0x0007, SHOULD reply with
> an I-Do "response", 0x8007.
>
> Any system that sends an I-Do "offer" or "response" may send as few
> or as many of its supported Field Types as it chooses.

...and this seems to me completely at odds with our policy of preventing amplification attacks by ensuring that one cannot provoke a longer reply by sending a shorter request.
It might be argu= ed that with two-octet identifiers and a manageable number of potential EF types, this shouldn't be a big deal; but I think it has potential for probl= ems (in theory, a response EF could be 2^16*2 bytes, which meets and exceeds any reasonable max packet length, in response to a minimal-length offer EF which would be like 4-8 bytes).
I think this is easily fixable (e.g. make it so a response MUST NOT include anything not already offered in the offer), but you would have to do that.



Besten Gru=DF / Kind regards,
Kristof Teichel<= /span>

=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F

Dr.-Ing. Kurt Kristof Teichel
Physikalisch-Tec= hnische Bundesanstalt (PTB)
Arbeitsgruppe 4.42 "Zeit=FCbertragung"
Bundesallee 100<= /span>
38116 Braunschwe= ig (Germany)
Tel.:   &nb= sp;    +49 (531) 592-4471
E-Mail:   kristof.teichel@ptb.de
=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F



Von:        "Harlan Stenn" <stenn=3D40nwtime.org@dmarc.ietf.org>
An:        kristof.teichel@ptb.de, "Salz, Rich" <rsalz@akamai.com>
Kop= ie:        "iana-prot-param-comment@iana.org" <iana-prot-param-comment@iana.org>, "NTP WG" <ntp@ietf.o= rg>
Dat= um:        15.08.2025 09:47
Bet= reff:        Re: [Ntp] Re: [IANA #1413181] NTP Extension Field additions, and IANA NTP table management process (ntp-parameters)



On 8/15/2025 2:41 AM, kristof.teich= el=3D40ptb.de@dmarc.ietf.org wrote:
> I will interject to remind that while I am arguing procedure (need for
> clearer specification because IETF says so), I am also arguing some
> substance:
> The documentation we do have suggests that parts of the intended
> mechanism are incompatible with existing specification documents, and
> also allows suspicion that parts of the intended mechanism might be
> damaging to the whole ecosystem where it would be deployed (see my mail
> from July 10th).

For each of the requested EF types for which I have requested
allocation, please identify which EF type requests you think are OK, and
which EF types have a specification that you believe has a problem.

Please specifically identify each place you think has a problem.

Thanks...

H

>  From what I understand, these are expressly the types of problems that
> DEs should watch out for in this process.
>
>
> Besten Gru=DF / Kind regards,
> Kristof Teichel
>
> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
>
> Dr.-Ing. Kurt Kristof Teichel
> Physikalisch-Technische Bundesanstalt (PTB)
> Arbeitsgruppe 4.42 "Zeit=FCbertragung"
> Bundesallee 100
> 38116 Braunschweig (Germany)
> Tel.:    +49 (531) 592-4471
> E-Mail: kristof.teichel@ptb.de
> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
>
>
>
> Von: "Salz, Rich" <rsalz=3D40akamai.com@dmarc.ietf.org>= ;
> An: "Harlan Stenn" <stenn=3D40nwtime.org@dmarc.ietf.org&g= t;, "iana-prot-
> param-comment@iana.org" <iana-prot-param-comment@iana.org><= br> > Kopie: "NTP WG" <ntp@ietf.org>
> Datum: 14.08.2025 15:40
> Betreff: [Ntp] Re: [IANA #1413181] NTP Extension Field additions, and
> IANA NTP table management process (ntp-parameters)
> ----------------------------------------------------------------------= --
>
>
>   * The metaphor for what is happening now is that I am registeri= ng the
>   * owner of a plot of land.  The DEs are apparently asking for detailed
>   * building plans.
>
>
> It is not fair to ‘blame’ the DEs for this. RFC 9748, whic= h updated the
> NTP Registries requires a specification [1]. That document is an IETF
> consensus document and they are just doing as directed.
>
> [1] =5Fhttps://www.rfc-e= ditor.org/rfc/rfc9748.html#name-designated-
> experts=5F <https://w= ww.rfc-editor.org/rfc/rfc9748.html#name-designated-
> experts>=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=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
> To unsubscribe send an email to ntp-leave@ietf.org
--
Harlan Stenn <stenn@nwtime.org>
http://networktimefoundation.org - be a member!

--=_alternative 00306901C1258CEA_=--