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

[Russ Housley <housley@xxxxxxxxxxxx>]

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@xxxxxxxx (not chair@xxxxxxxx).

Russ

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

-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call