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

From: Russ Housley <[email-masked]>
Date: Mon, 17 Feb 2020 08:22:50 -0500

Section 3 says: "... NTS-KE server's private certificate."  Certificates are public.  I assume that you are talking about a private key here.

Section 4.1.5 says: "...  denoting Numeric Identifiers from the IANA AEAD registry [RFC5116]".  I think it would be more useful to provide a pointer to the registry instead of the RFC that created the registry.

Section 4.1.7 says: "...an IPv4 address in dotted decimal notation, an IPv6 address, or ...". This is followed by a sentence on the format of the IPv6 address and s sentence on IDNs.  I think a parallel structure would be more clear.  Please list the choices, and then discuss the format used for each of the choices.

Section 7.1: I believe the contact should be [email-masked] <mailto:[email-masked]> (not [email-masked] <mailto:[email-masked]>).

Russ

> On Feb 14, 2020, at 9:46 AM, The IESG <[email-masked]> wrote:
> 
> 
> The IESG has received a request from the Network Time Protocol WG (ntp) to
> consider the following document: - 'Network Time Security for the Network
> Time Protocol'
>  <draft-ietf-ntp-using-nts-for-ntp-22.txt> as Proposed Standard
> 
> The IESG plans to make a decision in the next few weeks, and solicits final
> comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2020-02-28. Exceptionally, comments may
> be sent to [email-masked] instead. In either case, please retain the beginning
> of the Subject line to allow automated sorting.
> 
> Abstract
> 
> 
>   This memo specifies Network Time Security (NTS), a mechanism for
>   using Transport Layer Security (TLS) and Authenticated Encryption
>   with Associated Data (AEAD) to provide cryptographic security for the
>   client-server mode of the Network Time Protocol (NTP).
> 
>   NTS is structured as a suite of two loosely coupled sub-protocols.
>   The first (NTS-KE) handles initial authentication and key
>   establishment over TLS.  The second handles encryption and
>   authentication during NTP time synchronization via extension fields
>   in the NTP packets, and holds all required state only on the client
>   via opaque cookies.
> 
> 
> 
> 
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-ietf-ntp-using-nts-for-ntp/
> 
> IESG discussion can be tracked via
> https://datatracker.ietf.org/doc/draft-ietf-ntp-using-nts-for-ntp/ballot/
> 
> 
> No IPR declarations have been submitted directly on this I-D.
> 
> 
> The document contains these normative downward references.
> See RFC 3967 for additional information: 
>    rfc5297: Synthetic Initialization Vector (SIV) Authenticated Encryption Using the Advanced Encryption Standard (AES) (Informational - IETF stream)
> 
> 
> 
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce

---

From: Marcus Dansarie <[email-masked]>
Date: Tue, 18 Feb 2020 21:39:13 +0100

Russ,

Thank you for reviewing the draft and providing comments! I've discussed
the issues with the other authors. Please see our answers below.

Kind regards,
Marcus

On 2020-02-17 14:22, Russ Housley wrote:
> Section 3 says: "... NTS-KE server's private certificate."  Certificates
> are public.  I assume that you are talking about a private key here.

Indeed. This will be fixed.

> Section 4.1.5 says: "...  denoting Numeric Identifiers from the IANA
> AEAD registry [RFC5116]".  I think it would be more useful to provide a
> pointer to the registry instead of the RFC that created the registry.

This makes sense, although we are unsure about what the best practice
is. Do you (or anyone else) know if there's IETF guidance on how to
reference IANA registries?

> Section 4.1.7 says: "...an IPv4 address in dotted decimal notation, an
> IPv6 address, or ...". This is followed by a sentence on the format of
> the IPv6 address and s sentence on IDNs.  I think a parallel structure
> would be more clear.  Please list the choices, and then discuss the
> format used for each of the choices.

To fix this, we suggest changing the paragraph to:

"The contents of the string SHALL be either an IPv4 address, an IPv6
address, or a fully qualified domain name (FQDN). IPv4 address MUST be
in dotted decimal notation. IPv6 addresses MUST conform to the "Text
Representation of Addresses" as specified in [RFC4291] and MUST NOT
include zone identifiers [RFC6874]. If internationalized labels are
needed in the domain name, the A-LABEL syntax specified in [RFC5891]
MUST be used."

> Section 7.1: I believe the contact should be [email-masked]
> <mailto:[email-masked]> (not [email-masked] <mailto:[email-masked]>).

Section 8.1.1. of RFC 6335 says to use [email-masked].

---

From: "Patrik Fältström" <[email-masked]>
Date: Tue, 18 Feb 2020 21:58:29 +0100

On 18 Feb 2020, at 21:39, Marcus Dansarie wrote:

> If internationalized labels are needed in the domain name, the A-LABEL syntax specified in [RFC5891] MUST be used.

A different suggestion which I claim is more correct is:

If a label contains at least one non-ascii character, an A-LABEL MUST be used as defined in section 2.3.2.1 of RFC5890.

   Patrik

---

From: Daniel Lublin <[email-masked]>
Date: Wed, 19 Feb 2020 08:23:47 +0100

Good day,

I'm not entirely convinced of keeping a list of implementations in an RFC.
But since the information is there, let's at least have it corrected and
updated upon publishing.

Updated XML for the whole section 8.6. Implementation 6 follows.

  <section title="Implementation 6">
    <t>Organization: Hacklunch, independent</t>

    <t>Implementor: Michael Cardell Widerkrantz, Daniel Lublin, Martin Samuelsson et. al.</t>

    <t>Maturity: interoperable client, immature server</t>

    <section title="Coverage">
      <t>NTS-KE client and server.</t>
    </section>

    <section title="Licensing">
      <t>Licensing is ISC (details in LICENSE file).</t>

      <t>Source code is available at:
      https://gitlab.com/hacklunch/ntsclient</t>
    </section>

    <section title="Contact Information">
      <t>Contact Michael Cardell Widerkrantz: [email-masked]</t>
    </section>

    <section title="Last Update">
      <t>The implementation was updated 6. February 2020.</t>
    </section>
  </section>

---

From: Russ Housley <[email-masked]>
Date: Wed, 19 Feb 2020 03:21:25 -0500

Marcus:

See below ...

> reference IANA registries?

RFC 8708 says this for a specific registry:

   [IANA-LMS] IANA, "Leighton-Micali Signatures (LMS)",
              <https://www.iana.org/assignments/leighton-micali-
              signatures/>.

> needed in the domain name, the A-LABEL syntax specified in [RFC5891]

I liked the text proposed for the last sentence by Patrik.  Otherwise, this looks fine to me.

> Section 8.1.1. of RFC 6335 says to use [email-masked].

I stand corrected.

Russ

---

From: Harlan Stenn <[email-masked]>
Date: Wed, 19 Feb 2020 00:26:41 -0800

I think a list of implementations is a bad idea.

Does the WG really want to deal with the ongoing updates, and the
liability that will likely exist if the list is incorrect, or it is
decided that updates will no longer be made?

H

On 2/18/2020 11:23 PM, Daniel Lublin wrote:
> ntp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ntp
> 

-- 
Harlan Stenn <[email-masked]>
http://networktimefoundation.org - be a member!

---

From: Hal Murray <[email-masked]>
Date: Wed, 19 Feb 2020 00:48:13 -0800

> But since the information is there, let's at least have it corrected and

I thought it was a temporary section and would be deleted by the final editing 
pass when the TBDs were filled in.

Traditionally, RFCs required running code, normally at least 2 independent 
implementations that can talk to each other.  That section is useful while 
debugging and collects the data for the reviewers.

-------

Speaking of TBDs...  How do we contact the czar who assigns numbers for NTP 
extensions?  We've all been testing with 4 values.  It will be a pain if they 
change and I don't know of any reason not to make the values we are using 
official.

-- 
These are my opinions.  I hate spam.

---

From: Harlan Stenn <[email-masked]>
Date: Wed, 19 Feb 2020 00:52:35 -0800

> change and I don't know of any reason not to make the values we are using 

As long as we're talking about the original 0x0n04 values I agree with you.

---

From: "Ulrich Windl" <[email-masked]>
Date: Wed, 19 Feb 2020 14:25:14 +0100

>>> Harlan Stenn <[email-masked]> schrieb am 19.02.2020 um 09:26 in
Nachricht
<10141_1582100906_5E4CF1AA_10141_2470_1_0edc8be5-3887-06a4-8821-041ad65bb027@nwt
> I think a list of implementations is a bad idea.

What about some informational statement like "At the time of writing there
exist <number> implementations having demonstrated use of the protocol in
practice." Any maybe "Those implementations are/were: ..."

>>       <t>NTS‑KE client and server.</t>
>>     </section>
>> 
> ‑‑ 
> http://networktimefoundation.org ‑ be a member!
>

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 19 Feb 2020 14:14:56 +0000

Hi Daniel and Harlan,
  The list of implementations will be removed before the document is published as RFC as per RFC7942. Hope this addresses your concerns.

Thanks
Suresh

On Feb 19, 2020, at 3:26 AM, Harlan Stenn <[email-masked]<mailto:[email-masked]>> wrote:

H

   <section title="Contact Information">
     <t>Contact Michael Cardell Widerkrantz: [email-masked]<mailto:[email-masked]></t>
   </section>

_______________________________________________
ntp mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ntp

--
Harlan Stenn <[email-masked]<mailto:[email-masked]>>
http://networktimefoundation.org<http://networktimefoundation.org/> - be a member!

--
last-call mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/last-call

---

From: Paul Wouters <[email-masked]>
Date: Wed, 19 Feb 2020 09:43:45 -0500

> On Feb 19, 2020, at 02:23, Daniel Lublin <[email-masked]> wrote:
> 
> Good day,
> 

There shouldn’t be. See https://tools.ietf.org/html/rfc7942

which clearly states:

Since this information is necessarily time dependent, it is inappropriate for inclusion in a published RFC. The authors should include a note to the RFC Editor requesting that the [implementation] section be removed before publication.

Paul

---

From: Watson Ladd <[email-masked]>
Date: Wed, 19 Feb 2020 07:03:04 -0800

On Wed, Feb 19, 2020 at 6:45 AM Paul Wouters <[email-masked]> wrote:
>
>
>
> On Feb 19, 2020, at 02:23, Daniel Lublin <daniel@lublin..se> wrote:
>
> Good day,
>
>    Since this information is necessarily time dependent, it is
>    inappropriate for inclusion in a published RFC.  The authors should
>    include a note to the RFC Editor requesting that the [implementation] section be
>    removed before publication.

I could have sworn that note appears in the draft in Section 8, and
looking at the file it indeed does.

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 19 Feb 2020 15:31:25 +0000

>    I think a list of implementations is a bad idea.
    
I could not agree more!

---

From: Karen O'Donoghue <[email-masked]>
Date: Wed, 19 Feb 2020 15:38:00 +0000

Folks,

Suresh said this but let me reiterate... It was never the plan for the list of implementations to be in the final RFC. It will be removed in the publication phase. We should have indicated as such in the draft and that was my mistake for not catching it. 

Karen

        
    I could not agree more!

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 19 Feb 2020 16:48:56 +0000

Hi Hal,
  (Changed subject to match your question below)

On Feb 19, 2020, at 3:48 AM, Hal Murray <[email-masked]<mailto:[email-masked]>> wrote:

[email-masked]<mailto:[email-masked]> said:
I'm not entirely convinced of keeping a list of implementations in an RFC.
But since the information is there, let's at least have it corrected and
updated upon publishing.

-------

If you are talking about NTP extension field types [0], they do require IETF review for allocation (i.e. no czar). Writing up a draft with your usage and sending it over to the ntp wg for consideration would be the best way forward.

[0] https://www.iana.org/assignments/ntp-parameters/ntp-parameters.xhtml#ntp-parameters-3

Regards
Suresh

---

From: "Franke, Daniel" <[email-masked]>
Date: Wed, 19 Feb 2020 18:19:40 +0000

Suresh,

Hal may not have been clear. The four extension fields we're discussing are the four defined by the NTS draft. Due to the registry's unfortunate lack of any P&E range, Hal and other implementers have picked four codes that they've been squatting on for their draft implementations. Desiring to avoid a flag day when the draft becomes final, they'd like IANA to turn these four codes into official allocations rather than having IANA arbitrarily assign something else. Speaking as an author of the draft I have no objection to this.

________________________________
From: Suresh Krishnan <[email-masked]>
Sent: Wednesday, February 19, 2020 11:48
To: Hal Murray
Cc: Daniel Lublin; [email-masked]; [email-masked]; Karen O'Donoghue; [email-masked]; [email-masked]; IETF-Announce
Subject: NTP Extensions (was Re: [Ntp] Last Call: <draft-ietf-ntp-using-nts-for-ntp-22.txt> (Network Time Security for the Network Time Protocol) to Proposed Standard)

Hi Hal,

-------

[0] https://www.iana.org/assignments/ntp-parameters/ntp-parameters.xhtml#ntp-parameters-3<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.iana.org_assignments_ntp-2Dparameters_ntp-2Dparameters.xhtml-23ntp-2Dparameters-2D3&d=DwMFAg&c=96ZbZZcaMF4w0F4jpN6LZg&r=NlX0r6ynsvJy6t1-UbBqZbYxmdFYzvmLMmHofVndJ5k&m=4kCauNy5drgPVUEUsh2dWTBaaNAbwXU3tn1IZ2PbYI8&s=Ilafc9XVtUXj0DZFzrrma2AVM9yP4qsJLTGybPb_FaE&e=>

Regards
Suresh

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 19 Feb 2020 10:29:47 -0800

> Hal may not have been clear. The four extension fields we're discussing are the four defined by the NTS draft. Due to the registry's unfortunate lack of any P&E range, Hal and other implementers ha…

It's pretty normal/supported to include requested values in the IANA
Considerations section.  Just be clear that they're suggestions and not
official allocations, lest you get a DISCUSS for codepoint squatting :)

-Ben

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 19 Feb 2020 22:25:29 +0000

Hi Daniel,

On Feb 19, 2020, at 1:19 PM, Franke, Daniel <[email-masked]<mailto:[email-masked]>> wrote:

Suresh,

Ah. Thanks for clarifying. That makes sense. I don’t have any issues with this either. As Ben Kaduk said downthread, you can stuff in the currently used values as “requested values” into the draft after the last call completes. I will work with IANA to get these values assigned (I don’t foresee an issue)

Regards
Suresh

---

From: Karen O'Donoghue <[email-masked]>
Date: Thu, 20 Feb 2020 09:12:42 +0000

And... just to close the loop... what is it they say ... one should trust but verify... 

I thought we had had the discussion, but I didn't double check the document, assuming that we must not have said anything because of the discussion on the mailing list... and as has been gently pointed out to me...
The header itself for the section actually says... 

"8. Implementation Status - RFC EDITOR: REMOVE BEFORE PUBLICATION"

So, like everyone else, I jumped on a conversation before verifying the underlying assumptions... A lesson for all... 

Karen

On 2/19/20, 10:37 AM, "Karen O'Donoghue" <[email-masked]> wrote:

    Folks,

    Karen

            
        I could not agree more!

---

From: Steven Sommars <[email-masked]>
Date: Sun, 23 Feb 2020 19:28:08 -0600

There is substantial size-based blocking of UDP port 123 IPv4 packets by
ISPs/IXPs.  From one NTP monitoring point I saw about one third of the NTP
destinations unreachable for  212-460 byte port 123 UDP sizes.  Another
monitoring point had blocking for all NTP destinations when the size was
greater than 428 bytes.  Size-based NTP filtering was discussed on the
NANOG mailing list in 2014 (see for example
https://mailman.nanog.org/pipermail/nanog/2014-February/064634.html ).
NTP requests can be dropped, so  section 9.3 of draft 22 does not address
the problem.

How will NTS work in today's UDP-unfriendly Internet?

On Fri, Feb 14, 2020 at 8:47 AM The IESG <[email-masked]> wrote:

>     rfc5297: Synthetic Initialization Vector (SIV) Authenticated
> Encryption Using the Advanced Encryption Standard (AES) (Informational -
> IETF stream)
>
>
>

---

From: Steven Sommars <[email-masked]>
Date: Mon, 24 Feb 2020 08:51:46 -0600

There is substantial size-based blocking of UDP port 123 IPv4 packets by
ISPs/IXPs.  From one NTP monitoring point I saw about one third of the NTP
destinations unreachable (dropped en route) for  212-460 byte port 123
UDP.  Another monitoring point experienced blocking for all NTP
destinations when the size was greater than 428 bytes.  Size-based NTP
blocking is not a secret; it was discussed on the NANOG mailing list in
2014 (see for example
https://mailman.nanog.org/pipermail/nanog/2014-February/064634.html ).
NTP requests can be dropped, so  section 9.3 of draft 22 does not address
the problem.   While NTS will not be a DDoS amplification source, it will
be affected by existing DDoS countermeasures.

---

From: Watson Ladd <[email-masked]>
Date: Mon, 24 Feb 2020 08:14:58 -0800

> How will NTS work in today's UDP-unfriendly Internet?

NTS-KE can advertise an alternate port for NTP.

---

From: "Ulrich Windl" <[email-masked]>
Date: Wed, 26 Feb 2020 09:39:15 +0100

>>> Steven Sommars <[email-masked]> schrieb am 24.02.2020 um 15:51 in
Nachricht
<13690_1582555938_5E53E31F_13690_19_1_CAD4huA6nNtJB5=E+dxBvmsLrozkgZ3f-3P=NydCsm
> How will NTS work in today's UDP-unfriendly Internet?

Maybe a candidate for the best practices: "How to block unwanted NTP packets correctly?", "Should NTP packets be blocked?". Here I can't use any external NTP server, BTW. I feel safe ;-)