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

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 iesg@ietf.org <mailto:iesg@ietf.org> (not chair@ietf.org <mailto:chair@ietf.org>).

Russ

> On Feb 14, 2020, at 9:46 AM, The IESG <iesg-secretary@ietf.org> 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
> last-call@ietf.org mailing lists by 2020-02-28. Exceptionally, comments may
> be sent to iesg@ietf.org 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
> IETF-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-announce