Subject: [Ntp] Benjamin Kaduk's Discuss on draft-ietf-ntp-using-nts-for-ntp-23: (with DISCUSS and COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Tue, 10 Mar 2020 17:22:13 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-ntp-using-nts-for-ntp-23: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ntp-using-nts-for-ntp/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thank you for this document; it has been a long time coming and is much
awaited.  That said, I have a few points I'd like to discuss before I
can comfortably ballot Yes:

I'm happy to see prominent references to RFCs 7525 and 6125.
Unfortunately, merely citing RFC 6125 does not provide a usable
specification for an application to implement; we need to additionally
state what type of name (e.g., SRV-ID or DNS-ID) is used as input to the
validation process and how the application obtains that name.  Given
that we are defining a service name (and port number) for ntske, SRV-ID
might be appropriate (DNS-ID is the most common form I see consumers
of RFC 6125 using).

In a related vein, if ALPN is necessary for confirming ntske operation,
it's not entirely clear to me that a dedicated port (in addition to
service name) is required, and RFC 6335 discourages fixed port numbera
llocations.  Perhaps it's not intended that DNS-SD is used to discover
NTS-KE servers, though -- there's no reference to RFC 6763 in this
document, or other discussion of server discovery that I can see.

We seem to be internally inconsistent about whether the Cookie extension
can be encrypted -- Section 5.7 says "MUST NOT be encrypted", but
Section 5.2 implies that it could be encrypted:

   Always included among the authenticated or authenticated-and-
   encrypted extension fields are a cookie extension field and a unique
   identifier extension field.  [...]

Section 7.6 says that applications for new record types need to specify
the contents of the "Set Critical Bit" field, but this field is not
included in the table of initial entries.  Additionally, there doesn't
seem to be a clear description of what the semantics of the "Set
Critical Bit" field should be.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Section 1.1

   o  Identity: Through the use of the X.509 public key infrastructure,

It's not exactly accurate to say that there's one privileged "X.509 PKI"
(even if that would have been true about the original X.500 vision); we
have a large set of stuff on the "Web PKI" but there are other
X.509-based PKIs in use in, e.g., the cable industry.  I'd suggest
either dropping "the" or (if appropriate, which is not entirely clear)
adding "Web".

   o  Replay prevention: Client implementations may detect when a
      received time synchronization packet is a replay of a previous
      packet.

Given that a replay of time synchronization information kind of defeats
the point of a time synchronization protocol, do we want to use
something stronger than "may" here?

   o  Unlinkability: For mobile clients, NTS will not leak any
      information additional to NTP which would permit a passive
      adversary to determine that two packets sent over different
      networks came from the same client.

I guess it's kind of implicit that server mobility isn't really a thing
and thus we don't need to be concerned about linkability of servers.

   o  Non-amplification: Implementations (especially server
      implementations) may avoid acting as distributed denial-of-service
      (DDoS) amplifiers by never responding to a request with a packet
      larger than the request packet.

[similar comment about "may"]

Section 1.2

   The typical protocol flow is as follows: The client connects to an
   NTS-KE server on the NTS TCP port and the two parties perform a TLS

(Section 7.1 requests a port for "ntske"; I don't know how tightly we
need to constrain descriptive usage like this.)

   handshake.  Via the TLS channel, the parties negotiate some
   additional protocol parameters and the server sends the client a
   supply of cookies along with an IP address to the NTP server for
   which the cookies are valid.  The parties use TLS key export

nit: "IP address of the NTP server"

   phase of the protocol.  This negotiation takes only a single round
   trip, after which the server closes the connection and discards all
   associated state.  At this point the NTS-KE phase of the protocol is

nit(?): I'm not sure if there's a preference between "only takes a single
round trip" and "consists of a single request/response exchange".

   Figure 1 provides an overview of the high-level interaction between
   the client, the NTS-KE server, and the NTP server.  Note that the
   cookies' data format and the exchange of secrets between NTS-KE and
   NTP servers are not part of this specification and are implementation
   dependent.  However, a suggested format for NTS cookies is provided
   in Section 6.

This is analogous to the RFC 5077 treatment of TLS session tickets that
gives a "recommended" construction; however, while RFC 8446 to some
extent supersedes RFC 5077's specification, 8446 specifically does not
give a "recommended" construction, since there's not a whole lot that
specifically needs to be recommended.  I wonder if it would be better to
discuss this as an "example" construction rather than a "recommended"
one.

Section 3

   Since the NTS protocol is new as of this publication, no backward-
   compatibility concerns exist to justify using obsolete, insecure, or
   otherwise broken TLS features or versions.  Implementations MUST

So we can mandate TLS 1.3?
(Among other things, this would also obviate any need to worry about
requiring extended master secret before using the TLS Exporter
interface.)

   conform with [RFC7525] or with a later revision of BCP 195.  In
   particular, failure to use cipher suites that provide forward secrecy
   will make all negotiated NTS keys recoverable by anyone that gains
   access to the NTS-KE server's private key.  Furthermore:

So forward secret ciphersuites are REQUIRED?

Section 4

Is there any significance to the ordering of records within a message
(other than End of Message)?

   The NTS key establishment protocol is conducted via TCP port
   [[TBD1]].  The two endpoints carry out a TLS handshake in conformance

[See discuss point about server discovery]

   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.

[side note: since we define NTS-KE to be the single request/response
pair and the response is self-framing, the close_notify is kind of
redundant.  Which is not to say that it's bad to talk about, though it
does make one wonder why we only say the server sends it and don't have
the client also send one in response.  (Note that RFC 8446 has "Each
party MUST send a "close_notify" alert before closing its write side of
the connection, unless it has already sent some error alert.")]

While the prospect of a reflection attack seens unlikely (would a
machine be acting as both NTS-KE client and server?), it may be worth
introducing some marker of whether a record is being sent by a client
vs. a server.

   For clarity regarding bit-endianness: the Critical Bit is the most-
   significant bit of the first octet.  In C, given a network buffer
   `unsigned char b[]` containing an NTS-KE record, the critical bit is
   `b[0] >> 7` while the record type is `((b[0] & 0x7f) << 8) + b[1]`.

When people use C syntax for examples we tend to ask for a reference or
at least indication of a language version, though I can't imaging this
particular aspect changing in a future version of C...

Please mention somewhere that the angle brackets in Figure 3 are used to
denote optional records.

Section 4.1.2

Just to check: because of the "close_notify" requirement, any future
"Next Protocol" is going to only be using the key material established
through this NTS-KE session, but cannot be using this TLS connection
(akin to STARTTILS ... or should I say STARTNTS?).

Section 4.1.3

What do I do if I get an Error record without the critical bit set?
Treat it as ... an error?

Section 4.1.5

The AEAD Algorithms registry just gives a listing of "raw" ciphers; do
we expect there to be a need for additional specifications that cover
how to integrate the AEAD cipher into a given NTS Next Protocol?
(Obviously this document does so for NTPv4.)

   If the NTS Next Protocol Negotiation record offers Protocol ID 0 (for
   NTPv4), then this record MUST be included exactly once.  Other
   protocols MAY require it as well.

(This seems to in practice force any future NPN protocols to not try to
define semantics for including AEAD Algorithm Negotiation more than once
... which is probably fine.)

Section 4.1.7

   The NTPv4 Server Negotiation record has a Record Type number of 6.
   Its body consists of an ASCII-encoded [ANSI.X3-4.1986] string.  The

Is the ANSI ref preferred over RFC 20?

   contents of the string SHALL be either an IPv4 address, an IPv6
   address, or a fully qualified domain name (FQDN).  IPv4 addresses

I note that up in Section 1.2 we just said that the NTS-KE server sends
"an IP address to [sic] the NTP server for which the cookies are valid",
which is internally inconsistent.

   [RFC4291] and MUST NOT include zone identifiers [RFC6874].  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 RFC 5890 [RFC5890].

It's probably implicit, but this of course only applies in the "FQDN"
case, and the previous sentences were talking about the IP-address
cases...

      The disambiguating label string MUST be "EXPORTER-network-time-
      security/1".

I guess it's a matter of taste (though maybe we had some IAB guidance?),
but the version suffix "/1" may not be needed.

Section 5.1

My instincts are telling me to try to include, e.g., the TLS SNI value
and the NTPv4 Server/Port negotiation results in the exporter input, but
I think that is not actually needed (the TLS handshake transcript
protects the SNI value and the TLS connection itself protects the
others).

Section 5.2

   field is to enable the server to offload storage of session state
   onto the client.  The purpose of the unique identifier extension
   field is to protect the client from replay attacks.

Just to check: this is a "unique identifier" of the NTP packet (i.e., a
nonce), not a "unique identifier" of the client or some other persistent
entity?

Section 5.5

It's probably worth mentioning here that the Cookie Placeholder is
allowed to appear multiple times (Section 5.7 gives the recommended
procedure for doing so).
(Interestingly, the TLS WG is currently discussing a TLS extension to
allow a client to request a specific number of cookies on a given
handshake, which RFC 8446 left entirely to the server's discretion.)
[As another side note, this "single-use cookie with a new one returned
on each exchange" mechanism reminds me a lot of the ACME nonce usage,
though ACME places the burden of single-use on the server whereas for
NTS the client can enforce or choose to not enforce single-use.]

   prevent DDoS amplification.  The contents of the NTS Cookie
   Placeholder extension field's body are undefined and, aside from
   checking its length, MUST be ignored by the server.

It seems like whenever we leave something's contents undefined, some
clever person in the future is going to want to repurpose it for
something...if we require it to be all-zeros (or some other value) for
now, such future extensions can be more reliable.

Section 5.6

   not exceed the length of the request.  For mode 4 (server) packets,
   no Additional Padding field is ever required.  For mode 3 (client)

nit: s/ever/never/

   Senders are always free to include more Additional Padding than
   mandated by the above paragraph.  Theoretically, it could be

Is there a practical upper bound on how much padding could be included?
Would we expect servers to discard packets with "too much" additional
padding?

Section 5.7

      Exactly one Unique Identifier extension field which MUST be
      authenticated, MUST NOT be encrypted, and whose contents MUST NOT
      duplicate those of any previous request.

What's the scope of the "MUST NOT duplicate"?  Per C2S key?  Per client?

      and MUST NOT be encrypted.  The cookie MUST be one which has been
      previously provided to the client; either from the key exchange
      server during the NTS-KE handshake or from the NTP server in
      response to a previous NTS-protected NTP request.

nit: comma instead of semicolon (the second half is not a complete
sentence).

   preference.  Section 10.1 describes the privacy considerations of
   this in further detail.

nit(?): maybe "this tradeoff"?

   fields which MUST be authenticated and MAY be encrypted.  The number
   of NTS Cookie Placeholder extension fields that the client includes
   SHOULD be such that if the client includes N placeholders and the
   server sends back N+1 cookies, the number of unused cookies stored by
   the client will come to eight.  The client SHOULD NOT include more
   than seven NTS Cookie Placeholder extension fields in a request.
   When both the client and server adhere to all cookie-management
   guidance provided in this memo, the number of placeholder extension
   fields will equal the number of dropped packets since the last
   successful volley.

Choosing the number of Cooke Placeholders to include in this way can
introduce a side channel of information for (essentially) the amount of
packet loss the client is observing.  In the interest of reducing the
number of side channels available, perhaps we should give some positive
guidance to prefer encrypting the placeholders rather than leaving them
authenticated but unencrypted?

   1280 octets if no non-NTS-related extensions are used; 1280 octets is
   the minimum prescribed MTU for IPv6 and is in practice also safe for
   avoiding IPv4 fragmentation.  Nonetheless, senders SHOULD include

(If I held the pen this would be "generally safe", but I do not have
specific grounds to object to this phrasing.)

I know that RFC 5116 discusses AEAD decryption as producing either
plaintext or FAIL, but when Figure 5 has the server merely "verify time
request message", should we be saying anything about "decrypt encrypted
extension fields EF" as well?  [Similarly for the client's "verify time
response message".]

   present.  Servers MAY implement exceptions to this requirement for
   particular extension fields if their specification explicitly
   provides for such.

[the specification of the server or the specification of the extension
field?]

   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, and
   then use the C2S key to authenticate the packet and decrypt the
   ciphertext.  If the cookie is valid and authentication and decryption
   succeed, the server SHALL include the following extension fields in
   its response:

[This is not consistent with the RFC 5116 AEAD terminology, though it's
hard to make a strong case that it needs to be.]

   The server MAY include additional (non-NTS-related) extension fields
   which MAY appear prior to the NTS Authenticator and Encrypted
   Extension Fields extension field (therefore authenticated but not
   encrypted), within it (therefore encrypted and authenticated), or
   after it (therefore neither encrypted nor authenticated).  In
   general, however, the client MUST discard any unauthenticated
   extension fields and process the packet as though they were not
   present.  Clients MAY implement exceptions to this requirement for
   particular extension fields if their specification explicitly
   provides for such.

[same as for the other direction]

   If the NTP server has previously responded with authentic NTS-
   protected NTP packets (i.e., packets containing the NTS Authenticator
   and Encrypted Extension Fields extension field), the client MUST

I do see "authentic" outside the parenthetical, but still wonder if
"authentic" or "properly validated" or something should also appear
within the parenthetical.

   protocol upon forced disassociation from an NTP server.  In that
   case, it MUST be able to detect and stop looping between the NTS-KE
   and NTP servers by rate limiting the retries using e.g. exponential
   retry intervals.

[I frequently express a desire to see the base of the exponent indicated
when "exponential retry intervals" are specified, though it does not
seem mandatory for correcness of operation here.]

Section 6

   nonce reuse.  It need not be the same as the one that was negotiated
   with the client.  Servers should randomly generate and store a master
   AEAD key `K`. Servers should additionally choose a non-secret, unique

And in general should be the same for all cookies generated by a given
server?
Also, we should say that 'K' should (MUST?) not be used for any other
purpose.

   periods prior.  Servers should continue to accept any cookie
   generated using keys that they have not yet erased, even if those

nit: "been erased"

   function of its predecessor.  A recommended concrete implementation
   of this approach is to use HKDF [RFC5869] to derive new keys, using
   the key's predecessor as Input Keying Material and its key identifier
   as a salt.

Do we need to say to generate the appropriate amount of output material
from HKDF as needed for the next-generation key?  (I kind of hope not,
but...)

   The cookie should consist of the tuple `(I,N,C)`.

Are 'I' and 'N' fixed-length or length-prefixed?

   and nonce `N` with no associated data.  If decryption or verification
   fails, reply with an NTS NAK.  Otherwise, parse out the contents of

[same comment about RFC 5116 terminology]

Section 7.2

In a similar vein as my comment on the
"EXPORTER-network-time-security/1" string, perhaps the "/1" is not
necessary here?

Section 7.3

I will send a note to the TLS WG giving them a heads-up about the
"Recommended" value of "Y", though my sense is that this should be in
keeping with the spirit of recommended values.

Section 9

We should probably have some discussion of the consequences of
compromise of the server's cookie-encryption key.  Possibly also for
when the key associated with a cookie is compromised from a client,
though if cookies are single-use the scope may be quite limited.  (That
is, since we are using the shared symmetric key for authentication by
virtue of "I didn't send it so it must be from the other party that has
the key".)

Section 9.2

   NTS users should also consider that they are not fully protected
   against DDoS attacks by on-path adversaries.  In addition to dropping
   packets and attacks such as those described in Section 9.5, an on-
   path attacker can send spoofed kiss-o'-death replies, which are not
   authenticated, in response to NTP requests.  This could result in

Wouldn't these on-path attacks just be DoS attacks, not DDoS ones?

   significantly increased load on the NTS-KE server.  Implementers have
   to weigh the user's need for unlinkability against the added
   resilience that comes with cookie reuse in cases of NTS-KE server
   unavailability.

It's perhaps worth mentioning the requirement for kiss-o'-death replies
to echo the message identifier once a server is known to have sent valid
NTS-protected messages, which limits the scope of this attack to on-path
attackers.

Section 9.3

It might be worth some discussion of the potential tradeoffs involved in
encoding a client IP address into a cookie, with respect to allowing for
some form of source-address validation (and thus protection against
serving as a DDoS reflector).  QUIC, for example, has facility for
encoding source-address validation state into cookie-like artifacts.
Such IP address recording comes with concordant privacy and tracking
considerations, though (hence "tradeoffs").

Additionally, it seems that if the "NTP Server Negotiation" record is
optional for the client to send but can be set by the server, that would
result in some modest packet expansion, which would be topical to
mention here.

Section 9.5

   mitigate this attack.  However, the maximum error that an adversary
   can introduce is bounded by half of the round trip delay.

Half of the round-trip after the delay attack or in its absence?

Section 9.6

   At various points in NTS, the generation of cryptographically secure
   random numbers is required.  Whenever this draft specifies the use of

The string "random" appears only in the construction of the unique
identifier and the non-normative recommended cookie construction, and
the RFC 5116 recommended nonce construction also takes a random input;
do we want to mention specific examples instead of or in addition to
saying "various points"?  (I might consider mentioning that the SIV mode
helps reduce the dependence on strong random numbers as wel.)

Section 9.7

Is there anything to say about a target end-state where some peers can
successfully require NTS for all connections (i.e., no fallback of any
sort)?

   For the reasons described here, implementations SHOULD NOT revert
   from NTS-protected to unprotected NTP with any server without
   explicit user action.

Which would then force a choice between tolerating bad time and reusing
cookies, until user action can be obtained?

Section 10.1

   The unlinkability objective only holds for time synchronization
   traffic, as opposed to key exchange traffic.  This implies that it
   cannot be guaranteed for devices that function not only as time
   clients, but also as time servers (because the latter can be
   externally triggered to send authentication data).

Are we just talking about the TLS server certificate?

Section 12.1

I'm not sure that a normative reference is needed for "MUST NOT do this"
(to RFC 6874).

RFC 7507 seems used only in the definition of SCSV, which is itself
unused in the document.

Section 12.2

Why is RFC 5280 only informative but RFC 6125 is normative?

The "SHALL" regarding HKDF usage in TLS 1.3 exporters would seem to make
RFC 5869 a normative reference per
https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/,
though in my opinion the RFC 8446 reference would suffice for that
usage.

Also, Daniel should update (or remove) the address in his Author entry.

---

From: "Franke, Daniel" <[email-masked]>
Date: Wed, 11 Mar 2020 22:58:07 +0000

Ben,

Thanks for the review. I agree with your DISCUSS points and they all should be straightforward to address. Your inference that we don't intend for DNS-SD to be used with NTS-KE is correct. We'll aim to have a revised draft out in a few days.
________________________________________
From: Benjamin Kaduk via Datatracker <[email-masked]>
Sent: Tuesday, March 10, 2020 20:22
To: The IESG
Cc: [email-masked]; [email-masked]; [email-masked]; Karen O'Donoghue; [email-masked]
Subject: Benjamin Kaduk's Discuss on draft-ietf-ntp-using-nts-for-ntp-23: (with DISCUSS and COMMENT)

Section 1.1

Section 1.2

Section 3

Section 4

Section 4.1.2

Section 4.1.3

Section 4.1.5

Section 4.1.7

Section 5.1

Section 5.2

Section 5.5

Section 5.6

nit: s/ever/never/

Section 5.7

Section 6

nit: "been erased"

Section 7.2

Section 7.3

Section 9

Section 9.2

Section 9.3

Section 9.5

Section 9.6

Section 9.7

Section 10.1

Section 12.1

Section 12.2

---

From: Ragnar Sundblad <[email-masked]>
Date: Thu, 19 Mar 2020 17:01:49 +0100

Hello Benjamin,

Thank you very much for your thorough review and all your comments!
This has helped us improve on the text in many places.

Please find our answers below.

> On 11 Mar 2020, at 01:22, Benjamin Kaduk via Datatracker <[email-masked]> wrote:
> 

The service discovery is not in scope for this draft, and we anticipate
several different methods in the future. There are already discussions
going on on the ntp working group. We therefore do not specify these things
here, but want to refer to the relevant specifications for the different
methods. The rules for constructing a list of reference identifiers for
certificate validation is laid out in Section 6.2.1. of RFC 6125. This is what
we expect NTS-KE clients to do.

> document, or other discussion of server discovery that I can see.

Again, we anticipate several different methods and there is ongoing work in the
ntp working group.

>  identifier extension field.  [...]

The cookie is not encrypted from client to server (since the server
does not yet know what C2S key to use, it is in the cookie), but
encrypted when sent from the server to the client, for unlinkability.
We added a reference to Section 5.7. to emphasize how this should be done.

> Critical Bit" field should be.

Thanks - there used to be a Critical bit in the registry, but as you
saw is not any more. It is now removed from the text too. The entire paragraph
in question will be removed in draft 25.

Indeed, fixed!

> something stronger than "may" here?

The reasoning behind this was that the protocol allows for this,
but can not guarantee that an implementation does what it is
supposed to do.

> and thus we don't need to be concerned about linkability of servers.

We think so too.

> [similar comment about "may"]

(See answer above.)

> need to constrain descriptive usage like this.)

It says "typical", so our feeling is that this is ok.

> nit: "IP address of the NTP server"

Fixed!

> round trip" and "consists of a single request/response exchange".

We neither, so we decided to let it be (there are a lot of last
minute changes anyway).

> discuss this as an "example" construction rather than a "recommended"

We could not see a big advantage of changing it, it would have to be
changed in several places, so we let it be.

> requiring extended master secret before using the TLS Exporter

This has been debated back and forth several times in the WG, and the last time
it was still an argument that there were a lot of installations that would have
had trouble supporting TLS 1.3, so demanding 1.3 would have slowed down the
adoption rate. Considering the current state of TLS 1.3 adoption in operating
systems, we are not entirely sure those arguments still hold.

> So forward secret ciphersuites are REQUIRED?

Since TLS 1.3 requires PFS ciphers, this is only an issue with TLS 1.2
implementations. Our wording in Section 3 should be interpreted that we
advocate PFS ciphers for TLS 1.2 implementations in the spirit of Section 6.3 in
RFC 7525: "This document therefore advocates strict use of forward-secrecy-only
ciphers."

> (other than End of Message)?

No.

> the connection, unless it has already sent some error alert.")]

Thank you! This has been addressed in draft 25.

> introducing some marker of whether a record is being sent by a client

We don't really see how that attack would work.

Yes, a machine could be both a NTS-KE client and server, for example an
NTS enabled stratum 2 server box. With bad configuration, it could
potentially use itself as a server, including negotiating cookies
and keys for itself, just as can be done with an NTP server today
(but if nothing else the NTP stratum mechanism should make that
time link useless).

> particular aspect changing in a future version of C...

Neither can we. Draft 24 was updated to emphasize that we are refering to the C
programming language. (There is a bit called C on the same page of the draft.)

> Please mention somewhere that the angle brackets in Figure 3 are used to

We could not figure out a reasonable way to fix this to make it
entirely right, and it is meant just an illustration to the text
which has the details.

> (akin to STARTTILS ... or should I say STARTNTS?).

Correct, the protocol that uses the key material will not use this
TLS connection.

> Treat it as ... an error?

The critical bit should only be checked if the receiver does not
recognise the record id, see Section 4, page 9 of the draft.

> ... which is probably fine.)

Yes, that is pretty much the expectation, though details from the
NTPv4 next protocol may be reused.

> Is the ANSI ref preferred over RFC 20?

No, it is now changed to RFC 20.

> which is internally inconsistent.

Right, fixed with a small change of the text.

> case, and the previous sentences were talking about the IP-address

You are right. We have updated this to get it more explicit.

> but the version suffix "/1" may not be needed.

We intend this to be a version number, should it ever be needed.

> protects the SNI value and the TLS connection itself protects the

Indeed, this should be handled by the TLS layer.

> nonce), not a "unique identifier" of the client or some other persistent

Yes. It is all described in the following section (5.3).

> NTS the client can enforce or choose to not enforce single-use.]

We have elected to specify all details regarding that in Section 5.7. only.

> now, such future extensions can be more reliable.

Good point, we have now changed it to "SHOULD be all zeros".
(It also avoids sending data from uninitialised buffers.)

>  no Additional Padding field is ever required.  For mode 3 (client)

Here it actually should be "ever".

> Would we expect servers to discard packets with "too much" additional

It will be limited by the maximum UDP packet size. We can't see any
reason to put any upper boundary on the padding, since having more
than necessary will mainly harm the sender, and the harm to the
receiver (e.g. filling packet reassembly buffers) could likely be
accomplished anyway with or without padding.

> What's the scope of the "MUST NOT duplicate"?  Per C2S key?  Per client?

Text updated to clarify this.

> nit: comma instead of semicolon (the second half is not a complete

Fixed.

> nit(?): maybe "this tradeoff"?

It may not be a "tradeoff" in all situations, so we let it be.

> authenticated but unencrypted?

The number of cookie placeholders can be seen from the packet size
anyway, so there is no real gain in hiding them.

> specific grounds to object to this phrasing.)

That is better, changed.

> extension fields EF" as well?  [Similarly for the client's "verify time

We saw little gain in adding more text to the figure, so we didn't.

> [the specification of the server or the specification of the extension

The specification of the extension field.

> hard to make a strong case that it needs to be.]

We believe it is clear enough as it is.

> [same as for the other direction]

(Same answer here.)

> within the parenthetical.

Right, the parenthesis is now removed.

> seem mandatory for correcness of operation here.]

Here, exponential is just an example, it may be dependant on the
application, e.g. something with very low available bandwidth
and/or low time dependency may not want to waste cycles on this,
and the exact rate limiting methods and constants may need to change 
when we get more knowledge or other external circumstances change.

> And in general should be the same for all cookies generated by a given

Yes, until it is switched to the next 'K'.

> Also, we should say that 'K' should (MUST?) not be used for any other

Do we really have to explicitly specify that for a secret key?
Also, Section 6 is non-normative and contains general suggestions.
Specific details are implementation dependent.

>  generated using keys that they have not yet erased, even if those

We think the text is correct as it is.

> from HKDF as needed for the next-generation key?  (I kind of hope not,

Section 6 is non-normative and contains general suggestions. Specific
details are implementation dependent.

> Are 'I' and 'N' fixed-length or length-prefixed?

(Same answer as above.)

> [same comment about RFC 5116 terminology]

(Same answer as above.)

> "EXPORTER-network-time-security/1" string, perhaps the "/1" is not

Here too it is meant to be a version number.

> keeping with the spirit of recommended values.

We have changed this to an "N" in draft 24 since we thought it was more correct
for this type of label. We immediately learned it was not. Thus, it will be
changed back to 'Y' in draft 25.

> virtue of "I didn't send it so it must be from the other party that has

NTP and NTS-KE server operators are expected to remove compromised keys as soon
as the compromise is discovered. This would cause the NTP servers to respond
with NTS NAK, thus forcing key renegotiation. We are aware that this does
not protect against MITM attacks where the attacker has access to a
compromised cookie encryption key.

> Wouldn't these on-path attacks just be DoS attacks, not DDoS ones?

Right, changed.

> NTS-protected messages, which limits the scope of this attack to on-path

Since we already state that the attack is limited to on-path attackers in the
same paragraph, we have elected not to make further changes.

> considerations, though (hence "tradeoffs").

This would prevent mobile clients from using stored cookies. In the
end, it's an implementation issue.

> result in some modest packet expansion, which would be topical to

The NTP Server Negotiation record is used by NTS-KE and is not an
NTP extension field. There is no need to protect against packet
expansion when using the TCP/TLS based NTS-KE part of NTS.

> Half of the round-trip after the delay attack or in its absence?

Half of the round-trip time after the delay attack. The round-trip
time is typically limited to 1 second in many implementations.
We have added a link to the referenced paper where this is explained.

> helps reduce the dependence on strong random numbers as wel.)

This section was removed and Section 5.7 updated to clarify this.

> cookies, until user action can be obtained?

This is about not accepting a downgrade from NTS-protected to
unprotected (traditional) NTP. Whether cookies are reused or not is
another issue, and is only about unlinkability of the client vs
resilience of the time link.

> Are we just talking about the TLS server certificate?

Likely that was what was meant, but not necessarily, there are
other ways, to identify a server, the time scale, for example.

The text has been updated to better reflect this.

> I'm not sure that a normative reference is needed for "MUST NOT do this"

Implementers are required to know about zone identifiers and how they
are formatted in order to be able to detect them correctly if they
are received. 

> RFC 7507 seems used only in the definition of SCSV, which is itself

Right, removed now.

> Why is RFC 5280 only informative but RFC 6125 is normative?

Changed to be normative.

> though in my opinion the RFC 8446 reference would suffice for that

Changed to be normative.

> Also, Daniel should update (or remove) the address in his Author entry.

He has. :-)

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 19 Mar 2020 14:21:55 -0700

I'll also reply inline.

> we expect NTS-KE clients to do.

I don't think it's appropriate to leave the selection of type of identifier
fully up to the application; even if we don't discuss server discovery, we
can still discuss the framework used for naming servers, as naming is a key
part of authentication and authorization.  RFC 6125 itself acknowledges
this, noting in Section 2.1 that:

   [...] Ideally, protocol specifications that
   reference this document will specify which identifiers are mandatory-
   to-implement by servers and clients, which identifiers ought to be
   supported by certificate issuers, and which identifiers ought to be
   requested by application service providers.  Because these
   requirements differ across applications, it is impossible to
   categorically stipulate universal rules (e.g., that all software
   implementations, service providers, and certification authorities for
   all application protocols need to use or support DNS-IDs as a
   baseline for the purpose of interoperability).

   However, it is preferable that each application protocol will at
   least define a baseline that applies to the community of software
   developers, application service providers, and CAs actively using or
   supporting that technology (one such community, the CA/Browser Forum,
   has codified such a baseline for "Extended Validation Certificates"
   in [EV-CERTS]).

The checklist in Section 3 also gives guidance to application protocol
designers as to how to select the type of identifier to be used for their
protocol.

> in question will be removed in draft 25.

Ah, excellent.

> but can not guarantee that an implementation does what it is

I think that using "can" would avoid any risk of misunderstanding as
"sometimes possible" vs. "at their option"

> systems, we are not entirely sure those arguments still hold.

I guess the key question is whether any OSes would be willing to take an
updated NTP implementation that supports NTS but get stymied by the lack of
support for TLS 1.3 in the system TLS implementation.  I know that FreeBSD,
for example, will not upgrade the openssl major version within a stable release
branch, but I believe similar arguments apply to the ntpd major version.

If we do retain support for TLS 1.2, I do think we need to say that the
extended-master-secret extension must be used for those connections,
though.

> (but if nothing else the NTP stratum mechanism should make that

IMO explicitly noting the message direction is more robust and future-proof
(should any groundbreaking extensions appear), but I cannot insist on a
change here.

> programming language. (There is a bit called C on the same page of the draft.)

(I didn't even notice that there was a 'C' bit nearby!)

> We intend this to be a version number, should it ever be needed.

I think that was clear.  The argument (IIRC) I refer to is basically that
the protocol-level difference between going from "foo/1" to "foo/2" and
going from "foo" to "foov2" is negligible, and in the latter case you get
prettier identifiers for the initial batch of time.

> Here it actually should be "ever".

Indeed, my apologies -- I must have missed the "no".

> Do we really have to explicitly specify that for a secret key?

Unfortunately, it seems that we do, in general.  Too many instances of
software authors reusing a key because it was convenient :(

> Specific details are implementation dependent.

Fair enough.

> We think the text is correct as it is.

And I agree, sigh.  (I assume I read past "they".)

> changed back to 'Y' in draft 25.

Sorry to have caused any confusion!

> compromised cookie encryption key.

I did not doubt that you are aware of this; the question is whether all
future readers of this document will similarly be aware.

> same paragraph, we have elected not to make further changes.

Okay.

> end, it's an implementation issue.

True.

> We have added a link to the referenced paper where this is explained.

Ah, thanks.

> > successfully require NTS for all connections (i.e., no fallback of any

(I'll take that as a "no".)

> resilience of the time link.

If there's an attacker stripping NTS so I get unprotected responses, I'll
quickly use up my cookie pool since there's no NTS return traffic to
replenish it.  I could try NTS-KE again, though maybe the attacker can
block that as well.  With no cookie pool, I either have no time service at
all, an insecure time service, or a secure time service with cookie reuse.
I expect most people to choose the last one, but perhaps in some cases the
first one would be preferred.

> > Also, Daniel should update (or remove) the address in his Author entry.

Thanks for all the updates!

-Ben

---

From: Ragnar Sundblad <[email-masked]>
Date: Sun, 22 Mar 2020 17:47:16 +0100

Hello Benjamin,

Thank you very much for your additional comments!

Please see our answers inline below.

> designers as to how to select the type of identifier to be used for their

We have added a paragraph about that implementations must obey the
rules in RFC 5280 and RFC 6125 and that we recommend the use of
DNS-ID, and hope this will suffice for now.

> "sometimes possible" vs. "at their option"

This time we got your point, and have now changed them to "can".
Thanks!

> extended-master-secret extension must be used for those connections,

This and other issues showed that keeping 1.2 support would have
required handling several special cases and considerations for the use
of 1.2 vs >=1.3. It would also risk getting any of them wrong, or
missing some, in the specification or the implementations.

We have now removed support for 1.2 and require >=1.3.
A big step, but it is now or never (at least not in a long time).

For running on older OS:es without native 1.3 support, the
implementations will have to be linked to a separate library
supporting 1.3. This is inconvenient, but doable.

> (should any groundbreaking extensions appear), but I cannot insist on a

Since the protocol currently only supports a single request which gets
a single reply, this should not be a problem until someone makes
changes to do more interactions per session. We opted to not change
this now, since this would be a larger change that should be well
thought through, and since this can be handled by that future change.

> prettier identifiers for the initial batch of time.

Right, and this also seems to be the contemporary way of doing it.
We changed this. Again, now or never. Thanks for the suggestion!

> > Specific details are implementation dependent.

Since this is just one of probably an infinite set of ways that
someone could make bad decisions in their designs, and since this is
not part of the NTS protocol, we decided to not changes this.

We added an extra "secret" before "key K" in the text though, to
emphasise that it is.

> future readers of this document will similarly be aware.

Right, we added a new section ("Key Compromise") to describe the
problem and how it should be handled.

> (I'll take that as a "no".)

(The missing reply was an oversight, by me.)

We believe that this will be handled by the ongoing work on NTS
service discovery etc. in the WG. In addition, it is a question
about implementation and application.

> first one would be preferred.

The client MUST only accept responses that are authentic under the S2C
key associated with the corresponding request.

So stripping of NTS extensions from the NTP response (or sending a
fake response) should (=MUST) just lead to the client discarding the
response without further processing.
We added some more explicit text in "Protocol Details" to emphasise
this. We also changed a word in "NTS Stripping" to make it more clear
that this should not be possible to do.

If the attacker can block the KE server traffic, it could likely block
any traffic, and then the client could find itself without time
service or any other service, with or without NTS.
(We would love to be able to solve this though, it would fix so many
things, from attacks to broken cables, we regret to say that NTS is
not the answer to this. :-) )

---

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 22 Mar 2020 16:01:37 -0700

Hi Ragnar,

Also inline.

> DNS-ID, and hope this will suffice for now.

It does suffice to clear the Discuss, though if I may suggest

OLD:
   Implementations MUST follow the rules in RFC 5280 [RFC5280] and RFC
   6125 [RFC6125] for the representation and verification of application
   service identity.  Use of the DNS-ID identifier type [RFC6125] is
   RECOMMENDED.  Section 9.5 of this memo discusses particular
   considerations for certificate verification in the context of NTS.

NEW:
   Implementations MUST follow the rules in RFC 5280 [RFC5280] and RFC 6125
   [RFC6125] for the representation and verification of the application's
   service identity.  When NTS-KE service discovery (out of scope for this
   document) produces one or more host names, use of the DNS-ID identifier
   type [RFC6125] is RECOMMENDED; specifications for service discovery
   mechanisms can provide additional guidance for certificate validation
   based on the results of discovery.  Section 9.5 of this memo discusses
   particular considerations for certificate verification in the context of
   NTS.

In particular, I don't want us to diverge from the RFC 6125 recommendation
to encourage SRV-ID when DNS SRV records are used in discovery.

> supporting 1.3. This is inconvenient, but doable.

Agreed, and thank you for taking this step.

Okay.

Thanks!

Okay.

Thanks!

> not the answer to this. :-) )

:)

Thanks for the extra updates, and I'll go update my ballot position now.

-Ben

---

From: Kurt Roeckx <[email-masked]>
Date: Mon, 23 Mar 2020 00:39:30 +0100

> problem and how it should be handled.

I think this is at least a step in the right direction. I think
there are 2 keys:
- The key for the X.509 certificate
- The key that is negiotatiated during NTS-KE

Both of them can be compromised, and I think the new section only
talks about the 2nd key, and talks about how to deal with that
event, but I think it's also important to deal with the first key.

Kurt

---

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 22 Mar 2020 17:26:36 -0700

Hi Kurt!

> event, but I think it's also important to deal with the first key.

I think it's talking about a third key, the one internal to the NTS
server(s) that is used to self-encrypt the cookies that are handed out to
clients.  Compromising this key affects all clients, so is particularly
noteworthy.  Compromising the X.509 key does the same, though is in theory
covered by the security considerations of other documents (e.g., RFC 5280).
Compromising the result of the NTS-KE negotiation affects only the one
client in question, and thus has something of a narrower scope.  I wouldn't
turn down text that discussed the consequences of its compromise, though!

-Ben

---

From: Sandra Murphy <[email-masked]>
Date: Thu, 26 Mar 2020 08:03:09 -0400

> On Mar 19, 2020, at 5:21 PM, Benjamin Kaduk <[email-masked]> wrote:
> 
>>> 
>>> Section 4
>>> 

Actually, there is a bit of ordering significance.  The NTS Authenticator and Encrypted Extension Fields extension field provides authentication of the NTP protocol header and extension fields that precede it.  Extension headers that follow that extension field are neither authenticated nor encrypted.

—Sandy

---

From: Ragnar Sundblad <[email-masked]>
Date: Thu, 26 Mar 2020 14:21:38 +0100

> On 26 Mar 2020, at 13:03, Sandra Murphy <[email-masked]> wrote:
> 
> 
> 

You are right that there is in the NTP part, Section 5, but Section 4 is about the KE protocol, and there there isn’t any.

Ragnar

---

From: Sandra Murphy <[email-masked]>
Date: Thu, 26 Mar 2020 11:34:28 -0400

Correct.

> On Mar 26, 2020, at 9:21 AM, Ragnar Sundblad <[email-masked]> wrote:
> 
> 
> 
> _______________________________________________
> ntp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ntp