Subject: [Ntp] WGLC for draft-ietf-ntp-using-nts-for-ntp

From: Karen O'Donoghue <[email-masked]>
Date: Wed, 9 Aug 2017 04:41:25 +0000

Folks,

This begins a three week working group last call (WGLC) for "Network Time Security for the Network Time Protocol”.

https://datatracker.ietf.org/doc/draft-ietf-ntp-using-nts-for-ntp/

Please review and provide comments to the mailing list by no later than 31 August 2017. Earlier comments and discussion would be appreciated. Please note that the chairs will be using this WGLC to determine consensus to move this document forward to the IESG. 

Also, as a reminder, we have migrated the working group mailing list to IETF infrastructure. Please respond to [email-masked]. ]

Regards,
Karen and Dieter

---

From: Harlan Stenn <[email-masked]>
Date: Sun, 27 Aug 2017 22:05:02 -0700

I spent 2 hours on the phone on Friday with Dave Mills, discussing this
proposal.  Here is the "result" of that conversation.

 Dave: Do not ratify this proposal.  It needs more discussion and
clarification.  The proposal as written should NOT be approved.

 Harlan: I agree with Dave.

TL;DR version:

There are some parts of the proposal that are wrong, and some other
parts are misleading.  There are sections of the proposal that are
confusing, and there are sections of the proposal that are inadequately
described.

Long version:

1.1. Objectives

- Confidentiality: Under what conditions is this actually useful?  If
confidentiality is a need for some, in those situations why not just
send the NTP traffic over an encrypted VPN?

- Replay prevention: The core NTP specification already has replay
prevention.  The proposed language is misleading, implying that without
NTS there is no replay protection.  If the existing core protection
against replay is inadequate, please describe the problem(s).  You could
also say "NTS offers another, additional layer of replay prevention
beyond what NTP already provides."

- Request-response consistency: The core NTP protocol already has
request-response consistency checks, where useful.  The proposed
language is misleading, implying that without NTS there is no
request-response consistency checking.  If the existing checks for
request-response consistency is inadequate, please describe the
problem(s).  You could also say "NTS offers another, additional layer of
request-response consistency checks beyond what NTP already provides."

- Unlinkability: The stated threat seems extraordinarily unlikely to be
possible if more than several networks are involved.  Even if such a
threat was possible and used, if the client/server model for NTS is to
use NTP packets with NTS extension fields, an outside observer can still
see that there is a client sending requests to a set of servers that
some other client has used before.  How is that traffic not "linkable"?
This "feature" seems to be a red-herring.

- Non-amplification: The core problem is DDoS.  Amplification is a
secondary problem.  Sure, the avoidance of amplification is a useful
interim step.  But the target protocol isn't the place to solve the
DDoS problem.  DDoS is basically an "overcommit" problem.  BCP38, anyone?

- Scalability: The way this is phrased is confusing.  If this goal is
specific to NTS, then it should say so.  Given the subsequent
discussions about C2S, S2C, etc., it also seems disingenuous.  Aside
from these things, it seems to be another red-herring.  More detail below.

1.2. Protocol Overview

"These various modes have different and contradictory requirement for
security and performance."  This is a naive observation, and is not
true.  We *always* care about performance and security.  Different modes
simply use different equations for deciding how to achieve the
performance and security goals they require.

"... it is harmless for servers to process replayed packets."  This may
be true as far as the server is concerned, but carried to its extreme
this is no different from how a DDoS attack is conducted.  But servers
are expected to be stateless, and, again, the target protocol isn't the
place to solve the DDoS problem.

"In order to simultaneously serve these *conflicting* requirements..."
Again, the requirements are not conflicting, they're just different,
based on the use-case.

"... NTS is structured as a suite of three protocols:"  It should be
noted that other methods to accomplish these goals are possible, and
that what is subsequently described is *one* way that is expected to
satisfy the requirements.

- DTLS-encapsulated NTPv4: No mention is made of the fact that this
method will increase timing jitter, and degrade the quality of
timekeeping.  This is especially troublesome given that peer mode is
mostly used for groups of lower-stratum servers offering time to many
clients.

- NTS Extensions for NTPv4: Should this be "NTS Extension Fields for
NTPv4"?  Is the comment about the server not needing state correct?  No
subsequent discussion is provided to support this.  Several paragraphs
into "6.7. Protocol Details" we see "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, ..." but says nothing more about
this.  Please offer even one description of how this can be done,
efficiently if possible, without the server retaining state.

This paragraph then goes on to talk about how the proposed NTF Extension
Fields are (only) "suitable for securing client/server ...".  Is
"suitable" the right word in this sentence?  How about "needed",
"appropriate", or "used", or "useful"?

The paragraph again mentions "the server can implement them without
retaining per-client state" and then says the NTF EFs are "suitable
*only* for client/server mode because only the client, and not the
server, is protected from replay."  This section has a number of serious
problems.  One is that NTS is all about securing NTP traffic, but it's
confusing when this section passively describes client/server traffic.
This seems to be true, since symmetric mode is expected to be protected
via DTLS and not NTS-EFs.  We think it would be more clear to actively
describe how NTS protects the different modes of NTP.  I.e., a section
describing all the steps by which NTS protects symmetric mode
(active/active is really no different from active/passive for this
situation), then all the steps for client/server, then how NTS does not
(yet) have a solution for broadcast mode, and, finally, NTS for mode
6/7.  The paragraph continues the unsubstantiated and dubious claim that
the server does not need per-client state.  We could again note that NTP
broadcast mode is only expected to be used in trusted networks, and that
symmetric keys offer authentication in these presumably trusted networks.

The core NTP specification already provides authentication functionality
for all modes using symmetric keys.  Symmetric key protection suffers
from not having a built-in means to perform key exchange.  There is also
an issue with multiple "trust groups", but that problem might be solved
with MAC-EFs, where multiple MACs are provided for the different trust
groups.  If the key exchange problem was solved, the only thing
remaining to do is to limit symmetric keys to known IPs, and that is a
problem we have already solved.

- NTS Key Establishment: Where is NTS-KE actually described?  This is
hinted at by the reference to RFC7505, but it should be explicitly
stated and at least contain a summary description.

- "It is intended that NTP implementations will use DTLS-encapsulated
NTPv4 to secure symmetric ..."  This sentence should appear much earlier
in the document.

- "As previously stated, DTLS-encapsulated NTPv4 is trivial."  Again,
please note exactly what mode(s) are using this method, and expressly
note that DTLS-encapsulated NTP traffic will show more timing jitter and
be less accurate than normal NTPv4 UDP traffic.  While interleave mode
was inadvertently left out of RFC5905, it is likely the best way to
attempt to mitigate the jitter problems created by DTLS-encapsulated
NTPv4.  However, it is not yet clear that there is any way to easily
capture the packet receive or transmit timestamps in a DTLS-encapsulated
transport.

- "The typical protocol flow for client/server mode is as follows. ..."
Where is the process to generate the shared key described?  Please see
Dave's recent Autokey paper, Section 8, for the level of detail we're
looking for here.  What are the details on the "supply of cookies"?

- "Time synchronization proceeds ... Included among these fields are
..."  How?  Please provide details.  Describe how to recover from a
dropped packet (or few).  "The server uses the cookie to recover this
key material (previously discarded) ...".  How?  Details, please.
Assuming this can be done without saving state, how expensive is it?

- 4. The NTS-encapsulated NTPv4 protocol.  This is new language.  Was
"DTLS-encapsulated NTPv4 protocol" meant instead?  What port will be used?

- "The NTS-encapsulated NTPv4 protocol is the RECOMMENDED ...": Again,
should this be "DTLS-encapsulated"?  Also there is no mention of the
degradation of the NTP protocol because of the increased jitter caused
by the DTLS encapsulation.

- "Since DTLS-encapsulated ...": Again, no mention of the performance
degradation.

- "For symmetric operation ...": There are two paragraphs which discuss
this.  Dave expressly disagrees with the first paragraph.  The
differences between active/active and active/passive in this situation
would seem to be spurious.  Why are they called out?  What difference
does it make which side it the DTLS server and which side is the DTLS
client?  A protocol restart in this case could easily cause the roles to
reverse.  As for the situation where both sides create DTLS sessions,
how can this possibly happen?  There should be a single association
between the two parties, and the implementation can be expected to
prevent this from happening.  See Section 8 of Dave's recent Autokey
paper for how Dave would implement this.

- "If, likely as a result of user error, ...": how about "configuration
error" oe "user configuration error" instead of "user error"?  It's
"symmetric active", not "symmetry active".  In any event, this situation
is no different from one side sending a mode 1 (active) packet, and
getting back a mode 4 (server) response.  Except that NTS recommends
DTLS encapsulation for symmetric servers, and recommends against DTLS
encapsulation for client/server mode.

- 6. NTS Extensions for NTPv4:  If you're talking about NTP extension
fields, please call them extension fields.

- 6.1. Key Extraction: When does NTS-KE mean "key establishment" and
when does KE mean "key extraction"?  Please more clearly identify when
talking about TLS exchanges over the TCP port, and when talking about
extension fields in a UDP NTP packet.

- 6.2. Packet structure overview
- "Possibly, some additional extensions which are neither encrypted nor
authenticated.  >These are discarded by the receiver.<"  The part about
discarding EFs after the NTS packet seems wrong - it's over-reach.

- "The purpose of the unique-identifier extension is to protect the
client from replay attacks.":  Again, this is *additional* replay
prevention, beyond the existing prevention offered in the base protocol.

- 6.3. The Unique Identifier extension:  This is an NTP/NTS extension
field, right?  If so, please use the normal language.  This should not
use a new EF, it should use the proposed NTS EF Field Type of
(recommended value) 4, with a sub-code of [TBD], perhaps suggesting 1.

- 6.4. The NTS Cookie extension:  Ditto - EF type 4, sub-code of [TBD],
perhaps suggesting 2.

- 6.5.  The NTS Cookie Placeholder extension:  Ditto - EF type 4,
sub-code of [TBD], perhaps suggesting 3.

- 6.6. The NTS Authenticator and Encrypted Extensions extension:  Ditto,
it's an "Extension Field", not an "extension", and it should be EF type
4, sub-code of [TBD], perhaps suggesting 4.

Should 6.2. be:

6.2. Packet structure overview

and then use:

6.3. NTS Extension Field and Sub-Codes
The NTS Extension Field uses a Field Type of [TBD] (recommendation to
IANA: 4), with the following sub-codes:

6.3.1. The Unique Identifier Sub-Code
6.3.2. The Cookie Extension Sub-Code
6.3.3. The Cookie Placeholder Extension Sub-Code
6.3.4. The Authenticator and Encrypted Extensions Sub-Code

Please note that I might have mis-named sub-code - the RFC I've proposed
to address this isn't handy.

When specifying EF types and sub-codes, please note which top-level bits
(R/E/O/I) are expected.

- 6.7. Protocol details
- "Upon receiving an NTS-protected request, the server SHALL (thru some
implementation-defined mechanism) use the cookie to recover ...":
First, "NTS-protected request" is not quite right - this only applies to
the NTS EFs, correct, as they're the only ones that use an NTS-generated
MAC, right?  No MAC protection is suggested for DTLS-encapsulated NTPv4,
correct?  Next, as previously mentioned, please provide details on how
an implementation would accomplish this without saving state on a
per-client basis.  Also describe any computational or storage costs.

- "... C2S key, and S2C key ...": What do separate keys offer us that 1
key doesn't?

- "... the server SHALL include the following extensions in its
response:": First, "extensions" should be "Extension Fields", right?
The list of EFs that are included does not explicitly say where the MAC
lives.  One would *assume* the MAC lives in or after the last NTS Cookie
Extension Field, but it doesn't say this.  Also NTS Cookie EFs must be
authenticated *and* encrypted.  If the MAC lives in the last NTS Cookie
EF, is the MAC encrypted?   The answer to that last question MUST be
"no", in which case there seems to be a need for the MAC to live as
either a legacy MAC, or in a MAC-EF, after the last NTS Cookie EF.

- "The server MAY include additional (non-NTS-related) ...": Please
explain and justify.  This seems like massive over-reach, and should not
be "controlled" by the NTS specification.

- "In general, however, the client MUST discard any unauthenticated
extensions and process the packet as though they were not present.":
Please explain and justify.  This seems like massive over-reach, and
should not be "controlled" by the NTS specification.

- "If the server is unable to validate, ... KoD ...": This is
overloading/mis-using KoD.  What is wrong with the crypto-NAK for this
purpose?

- "Upon receiving an NTS-protected response, ...":  Again, NTS does both
client/server and peer mode exchanges.  This section seems to only need
to concern itself with client/server.  Furthermore, the sentence would
be more accurate if it was:  "After passing the NTP base-packet checks,
a packet protected by NTS Extension Fields MUST verify that the ..."

- 8. IANA  Considerations
- Port Number: [[TBD1]]: why not use TCP/123?  If this is done, please
clearly demonstrate that the protocol will allow additional uses on this
port, as we'd like to eventually use TCP/123 for monitoring and control
purposes, too.

- [[TBD2]]-[[TBD5]]: see earlier discussion.  We want a single NTS
Extension Field (type 4 is suggested), with sub-codes for the specific
subfield types.

Please better identify in the IANA considerations when you're asking
about EF codes v. TLS codes.

- 9.1. Avoiding DDoS amplification: We discussed this above, and I won't
repeat that here.  I will again repeat that the core issue is DDoS, and
the secondary issue is amplification.

- 9.2. NTP is designed to come up from a position of zero access to any
network resources, and as network resources become available, NTP will
evaluate these resources.  In particular, DNS cannot be trusted before
time is trusted, and most 3rd-party certificates cannot be trusted until
after time is trusted.  Dave's recent Autokey paper discusses these
issues as well, and a thorough comparison of the requirements and
assertions of the Autokey and NTS documents should be performed.

- 9.3. Usage of NTP pools
- "... Pools in existence as of 2017 are volunteer-run, with minimal
requirements for admission and no organized effort to monitor pool
servers for misbehavior. ..."  Really?  Where did you get this
"information"?

- 10.1. Unlinkability.  This would seem to be a red-herring.  Beyond
that, see the comments under 1.1.

- 10.2. Confidentiality.  Please.  What client-confidential information
exists in a normal NTP header that is not able to be adequately
protected right now?  Using SNTP wueries with minimal data fields one
already gets all of the protections described in ntp-data-minimization.
The point about "Future extension fields could hypothetically contain
sensitive information" seems implausible.  Have any such possibilities
>that are appropriate for an NTP Extension Field< packet even been
considered?  But assuming there is a way to tell NTS to send this
information encrypted, that would mean that the peer-mode DTLS
connection would have to provide encryption, and the client/server NTS
EF would have to provide an API, which has not been described here, to
contain this encrypted information.

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

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

---

From: Harlan Stenn <[email-masked]>
Date: Sun, 27 Aug 2017 22:05:02 -0700

TL;DR version:

Long version:

1.1. Objectives

1.2. Protocol Overview

Should 6.2. be:

and then use:

- 6.7. Protocol details

- 8. IANA  Considerations

---

From: Daniel Franke <[email-masked]>
Date: Mon, 28 Aug 2017 17:01:04 -0400

Responses inline, some paragraphs reordered so I can address them
together.

On 8/28/17, Harlan Stenn <[email-masked]> wrote:
> ...

Within NTS, the confidentiality scheme is a necessary building block
to achieve unlinkability. Where *else* will it be useful? I don't
know. We've built a tool; I can't predict every way people will use
it. If you want to put confidential information into an extension
field, now you can. If this ability never gets used for anything
except NTS cookies, then so be it: we've done no work that wasn't
already necessary for that case.

> What client-confidential information exists in a normal NTP header
> that is not able to be adequately protected right now?  Using SNTP
> wueries with minimal data fields one already gets all of the
> protections described in ntp-data-minimization.

Is there something here you suppose I disagree with? What's stated in
section 10.2 is that NTS doesn't protect the confidentiality of the
header, but if you implement data minimization then that's okay
because there'll be nothing left there that needs protecting.

> ...

The existing text here is very terse, I don't think it implies
anything one way or the other about existing protections, and I think
we should leave it that way since such a discussion is of no use to
implementers. But anyway, if it were necessary to opine, my answer
would be twofold:

1. As a general matter of good design, a security protocol should be
generically secure and not rely on assumptions about the structure of
the plaintext it's protecting. That alone should be good enough, but,

2. The 64-bit origin timestamp is not big enough to protect against
accidental collision. I could expand, but since, in the data
minimization draft, it was over your objection that we recommended
even taking full advantage of the bits we've got, I'm certain the
explanation would not be to your liking and you'd be happier with the
document's present silence on the matter.

> request-response consistency checks beyond what NTP already provides."

Request-response consistency comes out of the same set of mechanisms
that provide replay protection, so in reply to this I reiterate what I
wrote above.

> ...

We discussed this last year in Boston. What's written is "For mobile
clients, *NTS* will not leak any information which would permit a
passive adversary to determine that two packets sent over different
networks came from the same client" (emphasis added). Yes, there are
aspects of NTP, as well as other things running on most people's
systems having nothing at all to do with NTP, which can sabotage this
goal. We wrote the data minimization draft to clean up the other
NTP-specific bits to the best of our ability. The whole rest of
ecosystem is outside this WG's sphere of responsibility, and cleaning
it up is going to be long haul for the IETF over decades. Nonetheless,
the IETF does seem committed to this goal, and we're doing our small
part.

> ...

I don't follow your point. No, of course NTS is not designed to solve
DDoS in general, internet-wide. The goal that's written is
"implementations [of NTS] may avoid acting as DDoS amplifiers by never
responding to a request with a packet larger than the request packet"
and that's what the design achieves.

> from these things, it seems to be another red-herring.  More detail below.

The text says, "Servers implementations may serve large numbers of
clients without having to retain any client-specific state". Given
that this is the document specifying NTS, is it not already clear that
this means "server implementations of NTS"? See below about
statelessness.

> Again, the requirements are not conflicting, they're just different,

Am I correct in reading this as an objection to word choice and not to
substance? The language seems clear to me as it stands, but if you think
it can be improved then please propose text.

> place to solve the DDoS problem.

Replayed packets aren't any more of a contributor to DDoS than fresh ones,
so this seems like a strange thing to bring up here.

> satisfy the requirements.

Of course other designs are possible. This is the one, and the only
one, that we're proposing as a standard.

> [...]

> Also there is no mention of the degradation of the NTP protocol
> because of the increased jitter caused by the DTLS encapsulation.

No mention is made of this because there is no reason or evidence that
it would be true. All the necessary cryptographic algorithms can, should,
and generally do have constant-time implementations, and their execution
time is negligible compared to network latency even over a LAN.

> ...
> Next, as previously mentioned, please provide details on how

As explained toward the end of the protocol overview section (1.2),
server statelessness is enabled through cookies. Section 7, which
appears missing from your feedback, explains how.

> "appropriate", or "used", or "useful"?

I mean "suitable" in the sense of "satisfying all stated
objectives". I think it carries that sense better than any of those
proposed synonyms.

> stated and at least contain a summary description.

NTS-KE is specified in section 5, which appears missing from your
feedback.

> NTPv4 to secure symmetric ..."  This sentence should appear much earlier

It's already just a few paragraphs into the overview section. How much
earlier do you want it?

> capture the packet receive or transmit timestamps in a DTLS-encapsulated

DTLS doesn't do any flow control or group or split any
packets. Getting timestamps for a DTLS packet is literally no
different than for any other.

> Where is the process to generate the shared key described?

In section 5 and 6.1.

> Please see Dave's recent Autokey paper, Section 8, for the level of
> detail we're looking for here.  What are the details on the "supply
> of cookies"?

The initial supply is sent as specified in section 5.1.6. Clients manage
and refresh their supply as specified in section 6.7. The structure of
cookies is described in section 7.

> Assuming this can be done without saving state, how expensive is it?

See section 7.

> ...
> should this be "DTLS-encapsulated"?

Aaargh, crud. I swore I fixed these but obviously I didn't. It should
say "DTLS-encapsulated" everywhere. "NTS-encapsulated" is a holdover
from earlier drafts; we changed it because "DTLS-encapsulated" is
clearer and more accurate. I'll fix this properly in the post-WGLC draft.

> paper for how Dave would implement this.

I'm not following you here. In the suggested arrangement, any peer
configured as active is going to be initiating a DTLS session as a
DTLS client, therefore active-active and active-passive configurations
will result in different outcomes, and in the active-active case you
might end up with two of them. If you have a better recommendation
which avoids this, please post text.

> "symmetric active", not "symmetry active".

You're right, "configuration error" is better. The latter is a typo
and I'll fix it in the post-WGLC draft.

> In any event, this situation is no different from one side sending a
> mode 1 (active) packet, and getting back a mode 4 (server) response.
> Except that NTS recommends DTLS encapsulation for symmetric servers,
> and recommends against DTLS encapsulation for client/server mode.

My reading of RFC 5905 suggests that a mode 4 packet is not a legal
response to a mode 1 packet, and your code seems to agree with me.
See https://github.com/ntp-project/ntp/blob/stable/ntpd/ntp_peer.c#L25

> ...

No objection to changing section 6 to "NTS Extension Fields for NTPv4"
if there's consensus for this.

> extension fields in a UDP NTP packet.

The "KE" in NTS-KE always stands for "key establishment" and runs over
TLS/TCP as specified in section 5. Extraction is the RFC5705
computation that both parties perform after the establishment protocol
has been completed. It doesn't run "over" anything because it's just a
function evaluation, not a message.

> ...

How is this over-reach? Doing otherwise entirely defeats the
authentication objectives of the protocol.

> field, right?  If so, please use the normal language.

Yes, it's an NTP extension field, and I'm happy to add the word
"field" in there. I left "NTS" out of its name on purpose, because
it's nothing but a bag of random bytes that the server is expected to
echo back. NTS requires the EF, but using the EF does not require NTS.

> This should not use a new EF, it should use the proposed NTS EF Field Type of
> ...

These top-level bits are not reserved and have no meaning outside of
Autokey.  There is no mention of them in either RFC 5905 or RFC 7822,
and when we discussed this in Chicago, there was an overwhelming
consensus against any attempt to change this. In light of this, I see
no benefit to cramming all NTS extensions into a single code and
requiring a sub-code to disambiguate them.

> No MAC protection is suggested for DTLS-encapsulated NTPv4, correct?

When NTP traffic is already encapsulated in DTLS, adding a legacy MAC
serves no further purpose. But, as stated, DTLS-encapsulated NTPv4
permits arbitrary NTP traffic, which means there's no prohibition on
including one.

> MAC, right?
> ...

NTS doesn't use the legacy MAC field, or a MAC at all; it uses AEAD,
as specified in section 6.6. The output of the AEAD function will
generally include something that's functionally similar to a MAC, but
the structure of that is specified in RFC 5116 and (in the specific
case of AES-SIV) 5297, not here. The AEAD output lives in the NTS
Authenticator and Encrypted Extensions EF.

> - "... C2S key, and S2C key ...": What do separate keys offer us that 1

We discussed this a bit in the thread with Scott Fluhrer from last May
(note to self: I need to add Scott to the acknowledgements). In
general, there are two reasons that cryptographic protocols should use
separate keys for different message directions:

1. To keep messages intended for one recipient from being accepted if
they're maliciously redirected to another (including back to the
sender). In the particular case of NTP client/server mode, this one's
not a big issue because the mode field is already there for
disambiguation, but see above about how crypto protocols ought to be
generically secure.

2. So that it isn't necessary for one sender to avoid using a nonce
already used by the other.

As Scott pointed out, there is a slight downside to using separate
keys: it enlarges cookies by a bit. I don't make much of this since
everything still fits comfortably inside a single packet.

One possibility that hasn't yet been discussed: add an extra step to
the key extraction function of section 6.1, so that one intermediate
secret is extracted from the master secret, and then the S2C and C2S
keys are extracted from the intermediate secret. Then, to save space,
just store the intermediate secret in the cookie. This approach has a
small computational downside since now you have to recompute the
TLS-PRF for every packet you handle, but server implementors who
consider this a bad trade-off can just go on storing the S2C and C2S
keys in the cookie. I'm open to making this change if the WG agrees
it's a good idea.

You can already achieve the same thing by storing the master secret
in the cookie, but this weakens forward secrecy of the NTS-KE
session in a way that seems undesirable.

> overloading/mis-using KoD.  What is wrong with the crypto-NAK for this

On the contrary, this seems like an overloading/misuse of crypto-NAK,
which indicates a problem with the legacy MAC field. KoD is suited
just fine for this sort of purpose; it's only a rate-limiting
mechanism when the kiss code is "RATE". Looking at figure 13 in RFC
5905, NTS NAK seems to fit in just fine among all the other kiss codes
defined there.

> to concern itself with client/server.

Right. This is in section 6 which indeed only concerns itself with
client/server mode. It prohibits including these extensions in any
other mode; you need to use DTLS-encapsulated NTPv4 for that.

> Furthermore, the sentence would be more accurate if it was: "After
> passing the NTP base-packet checks, a packet protected by NTS
> Extension Fields MUST verify that the ..."

No! This is an implementation detail and not something the spec needs
to opine on, but NTS fields should be the first thing checked, not the
last. Why expose all that other attack surface to packets that might
be forgeries if you don't have to?

> port, as we'd like to eventually use TCP/123 for monitoring and control

You just answered your own question, more or less. You mentioned in
Boston that you intended to make use of NTP's existing TCP/123
allocation because ordered-and-reliable delivery can be desirable for
large mode 6 responses.  We went to a separate port to avoid stepping
on this, as there would be no elegant and reliable way to disambiguate
what protocol we're speaking.  Same goes for the UDP port.

> about EF codes v. TLS codes.

What's a "TLS code", and what's unclear? Each request to IANA states the
name of the registry the request pertains to.

> assertions of the Autokey and NTS documents should be performed.

DNS can't, and needn't, be trusted regardless since we're not assuming
DNSsec, and addressing the issues around X.509 trust is the whole
purpose of this section. Discussion of how these problems apply to
entirely different protocol (Autokey) seems like a strange thing to
include here.

> servers for misbehavior. ..."  Really?  Where did you get this

For all the but the last part, from
http://www.pool.ntp.org/en/join.html.  If I'm wrong about the "no
organized effort to monitor pool servers for misbehavior" part, please
cite one and I'll remove or revise that phrase.

---

From: Daniel Franke <[email-masked]>
Date: Mon, 28 Aug 2017 17:01:04 -0400

In section 5 and 6.1.

See section 7.

---

From: Harlan Stenn <[email-masked]>
Date: Mon, 28 Aug 2017 14:16:12 -0700

I don't have time to respond now, and since I'm at ISPCS this week I
probably won't have time to respond before the 31st.

Daniel, based on my initial read of your response, nothing you have said
changes what Dave and I think.  If it turns out that something *does*
change what we think, it means that the language in the draft is still
unclear and should be revised.

Dave and I still vote "NO" on advancing this document at this time.

H

---

From: Harlan Stenn <[email-masked]>
Date: Mon, 28 Aug 2017 14:16:12 -0700

H

---

From: Daniel Franke <[email-masked]>
Date: Mon, 28 Aug 2017 17:28:20 -0400

> Dave and I still vote "NO" on advancing this document at this time.

Harlan, your opposition is noted, but your attempt to seize the mantle
of Prof. Mills' authority here is inappropriate I want you to stop.
Prof. Mills could not possibly have read and responded to my comments
in the time it took you to send this reply. Your original critique, in
which you claim to be speaking for the two of you, is also written
entirely in your style with no indication of what is Prof. Mills'
commentary and what is yours.

I understand that Prof. Mills' health makes it challenging for him to
participate fully in this discussion. We should all do everything we
possibly can to accommodate him. But you are not acting as a faithful
messenger and I will not accept your words as his.

---

From: Daniel Franke <[email-masked]>
Date: Mon, 28 Aug 2017 17:28:20 -0400

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 29 Aug 2017 00:17:35 +0000

>   changes what Dave and I think.

Has Dave seen (or heard I suppose) Daniel’s response?  If not, please keep your view on his separate.

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 29 Aug 2017 00:17:35 +0000

---

From: Harlan Stenn <[email-masked]>
Date: Mon, 28 Aug 2017 17:28:35 -0700

> of Prof. Mills' authority here is inappropriate I want you to stop.
Please focus on responding to our comments.

> in the time it took you to send this reply.

Daniel, you're right, Dave hasn't seen your response yet.  But you did
not address the points we wanted to make, so I'm comfortable with my
response and position.

> Your original critique, in
If it actually makes a different I can try and identify the comments
that were Dave's and the comments that were mine.

But the bottom line is that Dave and I were/are on the same page on
these things.  If we did not communicate our reasoning in the way you
found optimal, I can try and address this.  In the meantime I fall back
on the top portion of the message Dave expressly told me to convey to
this group:

>> confusing, and there are sections of the proposal that are
>> inadequately described.

> messenger and I will not accept your words as his.

I wouldn't say it's his "health", I'd say it's his physical limitations.

And I will get your responses to him for his comments, but that almost
certainly won't happen before the 31st.

---

From: Harlan Stenn <[email-masked]>
Date: Mon, 28 Aug 2017 17:28:35 -0700

---

From: Harlan Stenn <[email-masked]>
Date: Mon, 28 Aug 2017 17:32:25 -0700

> Has Dave seen (or heard I suppose) Daniel’s response?  If not, please keep your view on his separate.

As I just replied, no.  But, as I also wrote, based on my read of
Daniel's response, Daniel did not address the points we raised.  If he
really did, however, then this reaffirms our point about the document
being unclear.

---

From: Harlan Stenn <[email-masked]>
Date: Mon, 28 Aug 2017 17:32:25 -0700

---

From: Karen O'Donoghue <[email-masked]>
Date: Tue, 29 Aug 2017 02:21:37 +0000

Gentlemen,

The tone of this conversation is not helpful or productive. Please limit all discussion to the merits of the technical points being raised. 

Harlan, while I understand that Dave Mills is unable to participate fully in the mailing list for health reasons, I ask you to limit your comments and discussion to your personal opinions only. Anything else is hearsay. 

To facilitate Dave’s participation, Dieter and I will reach out to Dave Mills as WG chairs to provide him an opportunity to comment. Additionally, we will schedule a virtual interim to address comments received on this WGLC, and that will provide an additional opportunity for Dave to personally express his opinions and interact with the working group. 

All working group members:  Please note that the WGLC on this document has been out for almost three weeks, and the only set of comments received to date are Harlan’s. Please review and comment immediately or Dieter and I will not have sufficient information to determine consensus. 

Karen

> On Aug 28, 2017, at 8:32 PM, Harlan Stenn <[email-masked]> wrote:
>

---

From: Karen O'Donoghue <[email-masked]>
Date: Tue, 29 Aug 2017 02:21:37 +0000

Gentlemen,

Karen

---

From: Karen O'Donoghue <[email-masked]>
Date: Tue, 29 Aug 2017 02:25:02 +0000

Folks,

The working group last call for this document has been out for almost three weeks now. Please respond immediately with technical comments and an indication of whether or not you approve the advancement of this document. 

Regards,
Karen

> On Aug 9, 2017, at 12:41 AM, Karen O'Donoghue <[email-masked]> wrote:
> 
> Folks,
>

---

From: Karen O'Donoghue <[email-masked]>
Date: Tue, 29 Aug 2017 02:25:02 +0000

Folks,

Regards,
Karen

---

From: [email-masked]
Date: Tue, 29 Aug 2017 08:55:12 +0200

"ntp" <[email-masked]> schrieb am 29.08.2017 02:28:35:

> Von: Harlan Stenn <[email-masked]>
> An: Daniel Franke <[email-masked]>
> Kopie: [email-masked]
> Datum: 29.08.2017 02:28
> Betreff: Re: [Ntp] WGLC for draft-ietf-ntp-using-nts-for-ntp
> Gesendet von: "ntp" <[email-masked]>
> 

> >> Dave and I still vote "NO" on advancing this document at this time.

(Citing as found in Daniel's mail, since for some reason, I seem to never 
have received the original message)

Harlan, on what grounds exactly?

Let me clarify: I believe it would be helpful if you could mark up for the 
WG what you (and potentially Dave, if he can contribute) see as 
"dealbreakers".
The list of feedback/issues you sent to the list suffers from a 
non-differentiation with regard to perceived severity of the items -- 
especially since some of them pretty clearly seem to be of the sort "fix 
the typo/adjust the wording and the problem is solved", purely editorial 
and solvable in very little time.

With more clarity on how severe you think the individual issues are and 
(roughly) what you think could be done to solve them, I believe the input 
would become much more constructive.

Best regards,
Kristof

---

From: [email-masked]
Date: Tue, 29 Aug 2017 08:55:12 +0200

Best regards,
Kristof

---

From: "Ulrich Windl" <[email-masked]>
Date: Tue, 29 Aug 2017 09:02:36 +0200

Hi guys!

Maybe Dave Mills will agree to voice recording. Then you could attach a voice transcript of your discussion. For example OPUS (Request for Comments: 6716) is a nice audio codec for speech ;-)

Regards,
Ulrich

>>> Daniel Franke <[email-masked]> schrieb am 28.08.2017 um 23:28 in
Nachricht

---

From: "Ulrich Windl" <[email-masked]>
Date: Tue, 29 Aug 2017 09:02:36 +0200

Hi guys!

Regards,
Ulrich

Nachricht

---

From: [email-masked]
Date: Tue, 29 Aug 2017 10:05:22 +0200

Hello all,

I am going to attempt a rundown of Harlan's input, trying to avoid too 
much overlap with responses that Daniel already gave.
I want to treat the "Objectives" subsection separately, ASAP, because 
consensus here is really essential for consensus anywhere else.

> send the NTP traffic over an encrypted VPN?

The need for confidentiality (for fresh keys) is derived from the need for 
unlinkability (see Daniel's response).
Editorial: I believe that for better logical structure, confidentiality 
should therefore be listed after unlinkability, and be given a short 
comment acknowledging this derivation.
Content: I think necessity is proven and I see no significant downside.

> beyond what NTP already provides."

I don't see how it is helpful to read the NTS proposal as a critique of 
NTPv4.
Content: Relying on timestamps for replay protection simply offers much 
less entropy than relying on random values. Also, see Daniel's response. 
Personally, I see necessity for this objective. Also, I cannot see any 
significant downside.

> request-response consistency checks beyond what NTP already provides."

See replay prevention.

> This "feature" seems to be a red-herring.

I don't think there is much merit to re-evaluating general IETF policy for 
our special case.
Editorial: can we have a citation for where this policy is stated?
Content: 
- Necessity is derived from general policy. So we will do the best we can. 
An argument along the lines of "but it might not good enough" should not 
influence that policy.
- This is item 1/2 where we are facing a kind of categorical imperative. 
The overall system only works if all protocols follow a certain ruleset. 
Therefore, we must follow that ruleset. In this case, the rule is: do not 
introduce new ways for an observer to recognize you by your traffic.

> DDoS problem.  DDoS is basically an "overcommit" problem.  BCP38, 
anyone?

See unlinkability.
- This is item 2/2 where categorical imperative comes into play. The rule 
here is: do not introduce new ways for an attacker to direct to a target a 
message larger than the one sent by the attacker.

> specific to NTS, then it should say so.

It's a little more complex: NTS must not *introduce a need for* per-client 
state. 
But I don't think that level of detail would be helpful here.

> Given the subsequent
> discussions about C2S, S2C, etc., it also seems disingenuous. 

Do I understand correctly that you don't believe the objective is being 
fulfilled? 
If so, I disagree. But in any event, this question should not influence 
our policy of having scalability as an objective.

> Aside

No, scalability is not a "red herring". On the contrary, it is a major 
reason why we need a new standard (because scalability is a huge drawback 
of using symmetric key protection).

My take-away for the "Objectives" subsection is this:

I believe it could be clearer. Specifically, I would suggest we add some 
language linking to RFC 7384 (Tal's "Security Requirements...") for the 
objectives that are derived from there, and some other language for 
objectives that are derived from generic IETF goals for security 
protocols.
I would like to stress that all of this is solvable by small amounts of 
editorial work.

I also believe that nothing in this subsection is wrong or misleading.
(Confirmation from other reviewers welcome - again, consensus here is 
needed as a basis for all other discussion)

---

From: [email-masked]
Date: Tue, 29 Aug 2017 10:05:22 +0200

Hello all,

See replay prevention.

See unlinkability.

---

From: [email-masked]
Date: Tue, 29 Aug 2017 15:16:34 +0200

"Ulrich Windl" <[email-masked]> schrieb am 29.08.2017 
10:32:03:
> Von: "Ulrich Windl" <[email-masked]>
> An: <[email-masked]>
> Datum: 29.08.2017 10:40
> Betreff: Antw: [Ntp] [NTP] WGLC for draft-ietf-ntp-using-nts-for-ntp
> (Objectives Subsection)
> 
> Hi!
> 
> I'm not deep in it, but the basic discussion seems to be that Dave 
> Mills thinks some things are "good enough", while others think they 
> are not. Maybe point out more clearly where any why things are not 
> good enough.
> I must agree that I, too, see little practical difference between  a
> sub-nanosecond timestamp and a random number (just to name one 
> example), considering that the network delay is above microseconds. 
> So the chances for a successful replay should be less than 1/1000th, 
right?

I guess this specific example is a matter of perspective: consciously 
settling for ~1/(2^10) does not sound optimal to me when the alternative 
is to go for ~1/(2^128), at the cost of a few additional octets.
Also, I appreciate Daniel's point that it is simply good practice to make 
the securtiy properties of a protection mechanism independent from the 
content of the protected protocol.

Additionally: do we have any argument that introducing a nonce (as per 
good general practice) would actively be a significant detriment? 
Because I don't see it, and I sense a slight tendency (in the whole WG, 
where the NTS documents have been concerned) to mix up "we do not 
absolutely have to" and "we absolutely should not".

> >>> <[email-masked]> schrieb am 29.08.2017 um 10:05 in Nachricht
> <[email-masked]>:
> > Hello all,
> > 

> >> confusing, and there are sections of the proposal that are 
inadequately

---

From: [email-masked]
Date: Tue, 29 Aug 2017 15:16:34 +0200

right?

inadequately

---

From: Robert Annessi <[email-masked]>
Date: Tue, 29 Aug 2017 15:52:21 +0200

Hi all,

> Please review and provide comments to the mailing list by no later than 31
> August 2017. Earlier comments and discussion would be appreciated. Please
> note that the chairs will be using this WGLC to determine consensus to move
> this document forward to the IESG. 

I have a minor remark/question:
The introduction states that certain sections of the draft may be applicable 
to other time synchronization protocols, PTP specifically. In Section 1.2 this 
idea is presented slightly more detailed saying that the NTS Key Establishment 
might be extended to PTP. Considering that NTS does not support broadcast 
communication (as stated in Section 1.2) and PTP by default relies on 
multicast communication, I am wondering why this vague future extension is 
included in the draft, although it may not even be feasible. 

Best,
Robert

---

From: Robert Annessi <[email-masked]>
Date: Tue, 29 Aug 2017 15:52:21 +0200

Hi all,

Best,
Robert

---

From: [email-masked]
Date: Tue, 29 Aug 2017 21:39:50 +0200

-----"ntp" <[email-masked]> schrieb: -----

>An: [email-masked]
>Von: Robert Annessi
>Gesendet von: "ntp"
>Datum: 29.08.2017 15:52
>> This begins a three week working group last call (WGLC) for
>"Network Time
>> Security for the Network Time Protocol”.
>

I knew there was something that I had wanted to contribute to the discussion for a long time but just kind of forgotten.

This was it.

I agree that this is a problem in the text, and I vote for taking out all passages that specifically mention PTP in this context.

---

From: [email-masked]
Date: Tue, 29 Aug 2017 21:39:50 +0200

This was it.

---

From: Daniel Franke <[email-masked]>
Date: Tue, 29 Aug 2017 15:55:51 -0400

On 8/29/17, [email-masked] <[email-masked]> wrote:
> I knew there was something that I had wanted to contribute to the discussion
> for a long time but just kind of forgotten.
> This was it.
>
> I agree that this is a problem in the text, and I vote for taking out all
> passages that specifically mention PTP in this context.

Well, you're the reason I had it there to begin with. I thought you
and Dieter still had ambitions to get something working wrt PTP. If
that's no longer the case then, without objection, I'll remove that
reference from the intro.

Besides the Terms and Abbreviations appendix, the only other reference
to PTP is an IANA request to reserve NTS Next Protocol code 1 for use
with PTP. Since we changed these codes from textual to numeric I guess
there's no reason to keep that either; we can always request a new
allocation once there's something concrete to attach to it.

---

From: Daniel Franke <[email-masked]>
Date: Tue, 29 Aug 2017 15:55:51 -0400

---

From: [email-masked]
Date: Tue, 29 Aug 2017 22:07:52 +0200

Hello all,

please forgive my patchwork approach to this discussion.

I am having some trouble making time for an extensive wall of text.

(Harlan)

>> capture the packet receive or transmit timestamps in a DTLS-encapsulated

(Daniel)
>different than for any other.

Historically, encapsulation is an overall concept that has been argued against a lot in the course of NTS (as far as I've witnessed it).

Therefore, I think that a paragraph of discussion on the presumed negligibiliy of the precision loss with DTLS-encapsulation is warranted.

Especially in the case of transmit timestamps (where every cryptographic operation takes place between the reading of the timestamp and the actual time of transmission that the timestamp was supposed to measure), perhaps it should at least be mentioned why this encapsulation is not significantly more expensive than e.g. adding a MAC/AEAD value.

One thing I really don't know, however, is where such a piece of text should be placed in order to not distort the core specification text (I don't think anyone wants to or should have to read a passage about the design decision process in the middle of the instructions on how to do the DTLS-encapsulation).

---

From: [email-masked]
Date: Tue, 29 Aug 2017 22:07:52 +0200

Hello all,

(Harlan)

(Daniel)

---

From: [email-masked]
Date: Tue, 29 Aug 2017 22:12:18 +0200

An: [email-masked]
Von: Daniel Franke
Gesendet von: "ntp"
Datum: 29.08.2017 21:55
Kopie: [email-masked], Robert Annessi <[email-masked]>
Betreff: Re: [Ntp] Antwort: Re: WGLC for draft-ietf-ntp-using-nts-for-ntp

While we do still have those ambitions you speak of, the measures that have made it into the current NTS draft simply do not cover the essentials of what is needed for PTP.
Therefore any mention of it could be seen as misleading and I believe we should avoid it.

Sounds good to me. Thanks.

---

From: [email-masked]
Date: Tue, 29 Aug 2017 22:12:18 +0200

---

From: Daniel Franke <[email-masked]>
Date: Tue, 29 Aug 2017 18:44:53 -0400

On 8/29/17, [email-masked] <[email-masked]> wrote:
> Historically, encapsulation is an overall concept that has been argued
> against a lot in the course of NTS (as far as I've witnessed it).
> Therefore, I think that a paragraph of discussion on the presumed
> negligibiliy of the precision loss with DTLS-encapsulation is warranted.
>
> Especially in the case of transmit timestamps (where every cryptographic
> operation takes place between the reading of the timestamp and the actual
> time of transmission that the timestamp was supposed to measure), perhaps it
> should at least be mentioned why this encapsulation is not significantly
> more expensive than e.g. adding a MAC/AEAD value.
>
> One thing I really don't know, however, is where such a piece of text should
> be placed in order to not distort the core specification text (I don't think
> anyone wants to or should have to read a passage about the design decision
> process in the middle of the instructions on how to do the
> DTLS-encapsulation).

I don't think performance analysis needs to go in the RFC at all. I
can't call to mind any other RFC that has included such a thing, and
I'm certain I've never seen it out of the TLS WG.

But for any skeptics, here's the math.

Let's start by looking at legacy MD5(K||M). Computing MD5 over 64
bytes ( 16-byte key, 48-byte NTP header) takes about 900 cycles on my
Broadwell system.

Now let's look at the AES-CMAC draft and at DTLS encapsulation with AES-GCM.

For these, a couple optimizations are possible to minimize the time
that elapses between when you call clock_gettime() (or whatever your
OS's equivalent) for the transmit timestamp, and when the
authenticated (and possibly encrypted) packet is ready to send.

The first optimization is straightforward. AES-CMAC supports
incremental, one-pass computation, as do all (D)TLS ciphers. That
means it's possible to precompute the crypto for every block preceding
the one that holds the transmit timestamp, before the transmit
timestamp is obtained. (This is possible with MD5 too, but it doesn't
buy you anything because MD5's internal block size is larger than the
data being hashed.)

The second optimization only works in DTLS, and it's *conceptually*
straightforward but probably a pain to implement just on account of
API limitations in TLS libraries. With AES-GCM, as well as with any
stream cipher, you can precompute encryption of the transmit timestamp
even before you have it, because all the expensive parts of encryption
don't depend on the plaintext -- you use your cipher algorithm to
compute a pseudorandom stream of bits and then the combination with
the plaintext is a simple xor (a single CPU cycle, which I'll
neglect).

An NTP header is 48 octets, which conveniently works out to exactly
three AES blocks. In this situation, AES-CMAC basically acts like
AES-CBC with one extra XOR thrown in and outputting just the final
block. On my Broadwell system, AES-CBC takes about 75 cycles per
block. On Skylake it's somewhat faster. So, to get from capturing the
transmit timestamp to a ready message, you need about 75 CPU cycles if
you optimize or about 225 if you don't. Both of these figures assume
you're at least doing AES key setup before you get the transmit
timestamp. I'm not sure exactly how much key setup adds, probably
another few hundred cycles, but I'm not going to bother measuring it
because not doing that in advance is just dumb.

Now let's look at DTLS with AES-GCM. A DTLS record consists of a
12-octet header, treated as associated data, followed by ciphertext
which is internally structured as the
actual encrypted payload followed by a 16-octet authenticator.

AES-GCM is rather complex, but at high level you can think of it as a
combination of AES-CTR with a non-cryptographic hash called GHASH. Its
cost comes down to the cost of computing AES-CTR over the plaintext,
plus the cost of computing GHASH over the associated data and the
output of AES-CTR, plus the cost of one additional AES operation at
the end.

AES-CTR allows you use CPU pipelining to encrypt a few blocks in
parallel on a single core. Encrypting one block costs about the same
as one block with AES-CBC (about 75 cycles), but you can do three
blocks for about the same cost as one. GHASH adds about 5 cycles per
block. Regardless, computing the authenticator adds another 75 cycles
or so at the end.

So with no optimization, we're looking at 75 cycles for AES-CTR, 20
cycles for GHASH, 75 cycles for the authenticator.

Basic optimization saves 15 cycles on GHASH, but because of
parallelism doesn't buy anything else.

Clever optimization cuts out everything except the final authenticator
computation.

So here's how it roughly works out:

MD5: 900 cycles
AES-CMAC, no optimization: 225 cycles
AES-CMAC, basic optimization: 75 cycles
DTLS, no optimization: 170 cycles
DTLS, basic optimization: 155 cycles
DTLS, clever optimization: 75 cycles

900 cycles for MD5 at 3.5GHz is 257 nanoseconds. In the worst case,
the resulting timing asymmetry throws off your accuracy by half that,
or 128 nanoseconds. That is several orders magnitude smaller than
anything NTP can possibly promise you. If you want to measure the
impact of adding the MD5 step in real world conditions, you will have
an extremely difficult time distinguishing it from zero.

AES-CMAC and DTLS each cut this performance impact by an additional
order of magnitude. If you try measuring the impact of either one and
tell me that you were able to do so, I will tell you that there is
either something wrong with your experiment or something wrong with
your crypto implementation.

DTLS encapsulation is *just fine*.

---

From: Daniel Franke <[email-masked]>
Date: Tue, 29 Aug 2017 18:44:53 -0400

MD5: 900 cycles

---

From: Paul Gear <[email-masked]>
Date: Wed, 30 Aug 2017 09:49:42 +1000

Hi everyone,

I sent a few minor comments to the list on 2017-08-11 but it looks like
I sent from the wrong address.  Here they are again.  Point 2 has
already been covered.

 1. There are a number of non-capitalised occurrences of "may",
    "should", and "should not" on page 6 - is this intentional, or
    should they be capitalised as RFC 2119 references?
 2. The phrase "symmetry active peer" towards the end of page 6
    presumably should read "symmetric active peer".
 3. Is "Cookie placeholder" (sect 6.5) the best name for this
    extension?  It's intended to function as a cookie request, so
    wouldn't "Cookie request" be a better name for it?
 4. Section 7 also contains some non-capitalised "should" references,
    which may need to be replaced with RFC 2119 references.  Similarly,
    it uses the language "it need not be the same as the one that was
    negotiated with the client" - should "need not" be reworded in terms
    of MAY or OPTIONAL?
 5. Section 9.3 states that "Pools in existence as of 2017 are
    volunteer-run, with ... no organized effort to monitor pool servers
    for misbehavior."  I'm not sure how this can be considered accurate
    for pool.ntp.org - a centrally-maintained host checks the
    reachability and offset in for every participating host in the pool,
    removes them from DNS if they misbehave, and publishes public
    results of this process.  That is clearly an "organized effort to
    monitor".

I've been working on a talk for AusNOG 2017 in Melbourne which covers
the outstanding drafts, and have really learned a lot from going through
them repeatedly over the past couple of weeks.  I have a few technical
comments which are more appropriate as replies to other threads so I'll
make those comments separately.

Regards,
Paul

---

From: Paul Gear <[email-masked]>
Date: Wed, 30 Aug 2017 09:49:42 +1000

Hi everyone,

Regards,
Paul

---

From: Dieter Sibold <[email-masked]>
Date: Wed, 30 Aug 2017 15:07:06 +0000

As Robert pointed out with the lack of broadcast support we cannot protect PTP's timing messages. The only input of this draft to PTP could be the key exchange. Therefore, I also agree to drop PTP from this draft.

Dieter

-----Original Message-----
From: ntp [mailto:[email-masked]] On Behalf Of Daniel Franke
Sent: Tuesday, August 29, 2017 9:56 PM
To: [email-masked]
Cc: [email-masked]; Robert Annessi <[email-masked]>
Subject: Re: [Ntp] Antwort: Re: WGLC for draft-ietf-ntp-using-nts-for-ntp

On 8/29/17, [email-masked] <[email-masked]> wrote:
> I knew there was something that I had wanted to contribute to the 
> discussion for a long time but just kind of forgotten.
> This was it.
>
> I agree that this is a problem in the text, and I vote for taking out 
> all passages that specifically mention PTP in this context.

Well, you're the reason I had it there to begin with. I thought you and Dieter still had ambitions to get something working wrt PTP. If that's no longer the case then, without objection, I'll remove that reference from the intro.

Besides the Terms and Abbreviations appendix, the only other reference to PTP is an IANA request to reserve NTS Next Protocol code 1 for use with PTP. Since we changed these codes from textual to numeric I guess there's no reason to keep that either; we can always request a new allocation once there's something concrete to attach to it.

---

From: Dieter Sibold <[email-masked]>
Date: Wed, 30 Aug 2017 15:07:06 +0000

Dieter

---

From: [email-masked]
Date: Wed, 30 Aug 2017 17:13:59 +0200

"ntp" <[email-masked]> schrieb am 30.08.2017 00:44:53:

> Von: Daniel Franke <[email-masked]>
> Kopie: [email-masked], Harlan Stenn <[email-masked]>
> Datum: 30.08.2017 00:45

I agree with Daniel. A standards document is not the appropriate place for 
a performance analysis.

---

From: [email-masked]
Date: Wed, 30 Aug 2017 17:13:59 +0200

---

From: Greg Dowd <[email-masked]>
Date: Wed, 30 Aug 2017 15:38:19 +0000

While I don't profess to know anything about the mapping of NTS to PTP, I would note that the telecom industry does use unicast flows for synchronization (PTP Profiles G.8265.1 for frequency and G.8275.2 for phase/tod).  

-----Original Message-----
From: ntp [mailto:[email-masked]] On Behalf Of Dieter Sibold
Sent: Wednesday, August 30, 2017 8:07 AM
To: Daniel Franke <[email-masked]>; [email-masked]
Cc: [email-masked]; Robert Annessi <[email-masked]>
Subject: Re: [Ntp] Antwort: Re: WGLC for draft-ietf-ntp-using-nts-for-ntp

EXTERNAL EMAIL

Dieter

---

From: Greg Dowd <[email-masked]>
Date: Wed, 30 Aug 2017 15:38:19 +0000

-----Original Message-----
From: ntp [mailto:[email-masked]] On Behalf Of Dieter Sibold
Sent: Wednesday, August 30, 2017 8:07 AM
To: Daniel Franke <[email-masked]>; [email-masked]
Cc: [email-masked]; Robert Annessi <[email-masked]>
Subject: Re: [Ntp] Antwort: Re: WGLC for draft-ietf-ntp-using-nts-for-ntp

EXTERNAL EMAIL

Dieter

---

From: Karen O'Donoghue <[email-masked]>
Date: Wed, 30 Aug 2017 17:21:04 +0000

Folks,

The PTP language is an artifact of when we thought we could achieve commonality between what the IETF NTP and the IEEE 1588 PTP communities were doing to address security. In the intervening time, the two approaches have diverged somewhat, and I think we need to focus here on getting an initial version of NTS out the door. I suggest we remove references to PTP in this document and revisit possible reuse or interoperation at a future time. I personally still believe it is worthwhile to work on easy interoperation between the two. 

Regards,
Karen

> On Aug 30, 2017, at 11:38 AM, Greg Dowd <[email-masked]> wrote:
>

---

From: Karen O'Donoghue <[email-masked]>
Date: Wed, 30 Aug 2017 17:21:04 +0000

Folks,

Regards,
Karen

---

From: Jiangyuanlong <[email-masked]>
Date: Thu, 31 Aug 2017 05:40:01 +0000

Hi, after going through this draft, I am not sure whether ietf-ntp-data-minimization-00 should be listed in the Normative Reference, or not at all.
Usually, an unpublished normative reference will dramatically slow the process of turning a draft into a RFC (they need to be published as a cluster at the same time).
It seems also ietf-ntp-data-minimization solves the problem of unlinkability, not necessarily a part of NTS, but a complement (just as the relationship of Section 9 "Security Considerations" and Section 10 "Privacy Considerations" ). 

Minor editorial comments:
1. IETF requirement languages can be used in Section 4 more frequently.
2. "both parties should attempt to initiate a DTLS session with their peer" can be rephrased into "each party SHOULD attempt to initiate a DTLS session with its peer" in Page 7.
3. " an Warning record " to "a Warning record" in Section 5.1.4.

Kind regards,
Yuanlong

-----Original Message-----
From: TICTOC [mailto:[email-masked]] On Behalf Of Karen O'Donoghue
Sent: Wednesday, August 09, 2017 12:41 PM
To: [email-masked]
Cc: [email-masked]
Subject: [TICTOC] WGLC for draft-ietf-ntp-using-nts-for-ntp

Folks,

Regards,
Karen and Dieter
_______________________________________________
TICTOC mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tictoc
_______________________________________________
ntp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ntp

---

From: Jiangyuanlong <[email-masked]>
Date: Thu, 31 Aug 2017 05:40:01 +0000

Kind regards,
Yuanlong

-----Original Message-----
From: TICTOC [mailto:[email-masked]] On Behalf Of Karen O'Donoghue
Sent: Wednesday, August 09, 2017 12:41 PM
To: [email-masked]
Cc: [email-masked]
Subject: [TICTOC] WGLC for draft-ietf-ntp-using-nts-for-ntp

Folks,

Regards,
Karen and Dieter

---

From: "Ulrich Windl" <[email-masked]>
Date: Thu, 31 Aug 2017 09:13:58 +0200

>>> <[email-masked]> schrieb am 30.08.2017 um 17:13 in Nachricht
<[email-masked]>:

[...]
[...]

I think it depends: Talking about CPU cycles for a specific machine should not go into the draft, but considerations like O()-notation could. Also a performance analysis at the protocol level (e.g. number of packet round-trips) (not at the host level (e.g. time to process a packet)) would very well fit any proposed protocol IMHO.

To summarize: If the analysis is part of the "eternal truth", it should go into the documents, but if it's just part of the "temporary truth" it should not.

Regards,
Ulrich

---

From: "Ulrich Windl" <[email-masked]>
Date: Thu, 31 Aug 2017 09:13:58 +0200

[...]
[...]

Regards,
Ulrich

---

From: Miroslav Lichvar <[email-masked]>
Date: Thu, 31 Aug 2017 11:14:27 +0200

On Wed, Aug 09, 2017 at 04:41:25AM +0000, Karen O'Donoghue wrote:
> Please review and provide comments to the mailing list by no later than 31 August 2017.

I don't support advancing the document as it currently stands (commit
5835e58 in the github repo).

As I said before [1], the main issue for me is the use of DTLS transport
in the symmetric mode. It's an easy solution how to get around some
issues, but it demotes the mode to a second-class status. I think all
timing messages in NTP should use the same transport. i.e. standard
NTP format with optional extension fields on UDP port 123.

The draft is still not clear on how should two active peers match
their DTLS connections. I think it would need to specify the port of
the DTLS client or exchange some additional information in DTLS or NTP
that would identify the peer.

My recommendation is to remove the specification of NTS in the symmetric
mode from the document, at least for now. I believe the NTS-KE used in
the client/server mode can be adopted for the symmetric mode, possibly
with some small extensions, but it will take time. I think most of us
here will agree it shouldn't delay the adoption of NTS in the
client/server mode.

[1] https://www.ietf.org/mail-archive/web/ntp/current/msg02048.html

-- 
Miroslav Lichvar

---

From: Miroslav Lichvar <[email-masked]>
Date: Thu, 31 Aug 2017 11:14:27 +0200

-- 
Miroslav Lichvar

---

From: Daniel Franke <[email-masked]>
Date: Thu, 31 Aug 2017 08:34:02 -0400

Replies inline, paragraphs reordered.

> NTP format with optional extension fields on UDP port 123.

I strongly disagree with you that this is giving "second-class
status". I don't view NTS-KE as the Right Thing and DTLS encapsulation
as a kludge; if anything, it's the other way around. The DTLS record
layer is simple, correct, and performant. It's what I'd want to use
for everything if it weren't for the pesky state-management issue.

Lots of people on this list seem to have the intuition that sending
time packets over DTLS can never be as accurate as sending them over
the NTP port with an authenticator attached. But as I showed in my
analysis the other day, that just ain't so.

> here will agree it shouldn't delay the adoption of NTS in the

If specification for symmetric mode were removed, how would section 4
read? Do you want to get rid of DTLS encapsulation altogether?
Restrict what traffic can be sent over it? Can you send a PR with what
you have in mind? (Won't promise to merge it, but I'll review it)

> that would identify the peer.

In my composing this reply you've convinced me on the "not clear"
part; I'd better add something about this in the security
considerations or everybody is going to screw it up. With plain
unauthenticated NTP, we rely on IP and port to identify peers. But IP
addresses aren't cryptographic identities; that's why DTLS needs
certificates. To do symmetric mode safely, you need a mutually
authenticated handshake (i.e., both sides present certificates). The
identity in that certificate is the additional information you're
looking for.

Chairs, I'm temporarily changing my *own* vote on advancement to "no"
until I've expanded on this. It goes back to "yes" with my next git
push :-).

---

From: Daniel Franke <[email-masked]>
Date: Thu, 31 Aug 2017 08:34:02 -0400

---

From: Daniel Franke <[email-masked]>
Date: Thu, 31 Aug 2017 08:45:29 -0400

On 8/31/17, Jiangyuanlong <[email-masked]> wrote:
> Hi, after going through this draft, I am not sure whether
> ietf-ntp-data-minimization-00 should be listed in the Normative Reference,
> or not at all.

I was *just* about to bring this up myself. I think it's properly an
informative reference.

Sharon, Aanchal, CCing the two of you because I recall you had a
different opinion last year in Boston and thought it should stay a
normative reference (but I'm not sure I understood you correctly
then). Note that this is a completely separate issue from whether data
minimization should be published as Standards Track vs. Informational.
It can stay a Standards Track document and still be cited from NTS for
Informative purposes.

---

From: Daniel Franke <[email-masked]>
Date: Thu, 31 Aug 2017 08:45:29 -0400

---

From: Miroslav Lichvar <[email-masked]>
Date: Thu, 31 Aug 2017 16:02:58 +0200

> analysis the other day, that just ain't so.

The problem is not with transmission. The problem as I see it is with
transport and reception. Encryption prevents modifications of the
packet in the network, which will be needed for delay corrections.
A different port number will not work with existing QoS in
switches/routers and hardware timestamping in NICs. I'm sure in some
cases reconfiguration to handle both ports will be possible, but there
is HW where the port number is hardcoded in the firmware or silicon.
If there is a rarely used port for timing messages, will everyone
support it? I doubt that. The symmetric mode will not get all benefits
of NTP support.

If DTLS records were exchanged in NTP packets in extension fields, as
was originally considered by the design group, this wouldn't be a
problem.

> you have in mind? (Won't promise to merge it, but I'll review it)

I'm not sure. I think the whole section could be limited to the
control (6) mode. The other modes (1, 2, 3, 4, 5, 7) can be
allowed, but not recommended. In the broadcast mode I think it doesn't
make much sense anyway.

> The

Ok, thanks.

-- 
Miroslav Lichvar

---

From: Miroslav Lichvar <[email-masked]>
Date: Thu, 31 Aug 2017 16:02:58 +0200

Ok, thanks.

-- 
Miroslav Lichvar

---

From: [email-masked]
Date: Thu, 31 Aug 2017 22:36:34 +0200

Miroslav, please see my comment below

-----"ntp" <[email-masked]> wrote: -----

>To: Daniel Franke <[email-masked]>
>From: Miroslav Lichvar 
>Sent by: "ntp" 
>Date: 08/31/2017 16:03
>Cc: "[email-masked]" <[email-masked]>, "[email-masked]"
><[email-masked]>, Karen O'Donoghue <[email-masked]>
>Subject: Re: [Ntp] WGLC for draft-ietf-ntp-using-nts-for-ntp
>

During the NTP interim meeting in Boston, Oct 2016 we had a thorough discussion of how to transport NTP's symmetric mode. At this time we had consensus to postpone the encapsulation of DTLS records within EF. Therefore, the draft represents the decisions take at that time. As Daniel pointed out. The current scheme to protect the symmetric mode has no disadvantage regarding time synchronization performance. I would guess that for the majority of mode 1/2 configuration it will work just well. It will certainly not work for the special configuration you mentioned. But an alternative approach can be specified, if future reveals that for any reason this is mandatory for the symmetric mode. But until that we should promote the current approach.

---

From: [email-masked]
Date: Thu, 31 Aug 2017 22:36:34 +0200

---

From: "Gary E. Miller" <[email-masked]>
Date: Thu, 31 Aug 2017 15:18:37 -0700

Yo Daniel!

On Thu, 31 Aug 2017 08:34:02 -0400

> analysis the other day, that just ain't so.

Analysis is great, but I'd like to see running code.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	[email-masked]  Tel:+1 541 382 8588

	    Veritas liberabit vos. -- Quid est veritas?
    "If you can’t measure it, you can’t improve it." - Lord Kelvin
_______________________________________________
ntp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ntp

---

From: "Gary E. Miller" <[email-masked]>
Date: Thu, 31 Aug 2017 15:18:37 -0700

Yo Daniel!

RGDS
GARY

---

From: Jiangyuanlong <[email-masked]>
Date: Fri, 1 Sep 2017 00:19:37 +0000

Daniel, that also works. BTW, you need not give the exact version of the WG draft, but tag it as "in progress".

Cheers,
Yuanlong

> From: Daniel Franke [mailto:[email-masked]]
> Sent: Thursday, August 31, 2017 8:45 PM
> To: Jiangyuanlong
> Cc: Karen O'Donoghue; [email-masked]; [email-masked]; Sharon Goldberg;
> Aanchal Malhotra
> > ietf-ntp-data-minimization-00 should be listed in the Normative
> > Reference, or not at all.
> 
> I was *just* about to bring this up myself. I think it's properly an informative
> reference.
> 
> Sharon, Aanchal, CCing the two of you because I recall you had a different
> opinion last year in Boston and thought it should stay a normative reference
> (but I'm not sure I understood you correctly then). Note that this is a
> completely separate issue from whether data minimization should be
> published as Standards Track vs. Informational.

---

From: Jiangyuanlong <[email-masked]>
Date: Fri, 1 Sep 2017 00:19:37 +0000

Cheers,
Yuanlong

---

From: Daniel Franke <[email-masked]>
Date: Thu, 31 Aug 2017 20:27:46 -0400

Miroslav, I just pushed a bunch of new detail in section 4 to git. Let
me know what you think of it and whether it affects your vote.

Sharon, I still need to incorporate your feedback. I'm in the middle
of doing new diagrams.

---

From: Daniel Franke <[email-masked]>
Date: Thu, 31 Aug 2017 20:27:46 -0400