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

From: Marcus Dansarie <[email-masked]>
Date: Thu, 15 Nov 2018 23:00:32 +0100

All,

Ragnar and I spent a couple of hours yesterday going over NTS4NTP draft
14. Overall, we are very happy with the current state of the draft. Our
remaining concerns and a few general comments are as follows:

* In Section 1.1, we would still like resilience to be an express
objective of NTS. A possible wording could be "Attacks on or faults in
parts of the NTS infrastructure should not completely prohibit clients
from performing time synchronization. In particular, security
enhancements to the NTP protocol should not increase the protocol's
ability to withstand attacks."

* Re Section 3, we still feel that TLS 1.3 should be the lowest
acceptable TLS version. It is certainly true that requiring TLS 1.3
would probably limit short term adaption of NTS. Our opinion, however,
is that concerns for for the short term should not take priority over
the long term where this could lead to servers having to support TLS 1.2
for a long time if TLS 1.2-only client implementations were to emerge
after the draft's adaption as an RFC.

* Our suggested NTP Server Negotiation record from draft-dansarie-nts-00
has been reworked by Daniel Franke into Sections 4.1.7 and 4.1.8
following comments in previous WG meetings. After thorough discussion,
Ragnar and I now agree that the design in current draft is sound and
that there is no need for the NTS-KE protocol to support lists of
preferred/assigned servers in server/port negotiation records. Such
lists would add to protocol complexity while only satisfying a fringe
requirement that can be achieved on the implementation side without this
addition. We only have one minor comment to the wording: In Section
4.1.7, paragraph 2: "If no record of this type is sent, the client SHALL
interpret this [...]", we believe that SHALL is to strong of a
requirement and that a SHOULD would suffice.

* In Section 5.6, we support the addition of an additional padding field
and the reasoning behind it.

* In Section 7.1, the service name has been changed to "ntske". We
support this. The section reserves a TCP port only for NTS-KE. It has
been suggested to us that it is customary to register both TCP and UDP
ports with the same number, but we're unsure what the current practice
is. Considering that NTP's registered port is in the system port range,
we think that we should try to get an NTS-KE port in the same range,
unless there are strong reasons not to.

* In Section 9.3, it is suggested that clients should "not process time
packets from servers if the time computed from them falls outside the
validity period of the server's certificate." We believe that there is a
risk that this could be interpreted as meaning that clients should
reperform an NTS-KE handshake upon expiry of the certificate that was
used by the NTS-KE server to provide the client with its initial supply
of cookies. In the worst case, this could lead to an accidental DoS
attack as many clients try to perform a new NTS-KE handshake at the
expiry time of a server's old certificate. We suggest adding a sentence
like "Clients SHOULD NOT perform a new NTS-KE handshake solely based on
the fact that the certificate used by the NTS-KE server in a previous
handshake has expired, if the client has previously received valid NTS
protected NTP replies that lie within the certificate's validity time."

* Since there is a current draft that attempts to solve the problem
described in Section 9.4, adding a reference there to
draft-schiff-ntp-chronos-01 could be a good idea.

In conclusion: We have no major objections to the draft at this point.
With the exception of our comment on Section 9.3, none of our comments
are of great importance to us and we will yield if there is no
agreement. Our concerns regarding Section 9.3 need to be addressed in
one way or another.

We would like to thank everyone who have contributed to the draft and
made the effort to read and comment on it. We look forward to your
comments on our suggestions.

Kind regards,
Marcus Dansarie and Ragnar Sundblad

---

From: Dieter Sibold <[email-masked]>
Date: Fri, 16 Nov 2018 14:24:20 +0000

Hi Marcus,
thanks for your comments. I have a short query with regards to the last sentence in the first bullet point. I suppose that you meant to write ... should not decrease the protocol's ... instead of ... should not increase the protocol's ... Otherwise, I would not understand the objective.

I'm going to review the other bullet points later.

- Dieter

Am 15.11.18, 23:00 schrieb "ntp im Auftrag von Marcus Dansarie" <[email-masked] im Auftrag von [email-masked]>:

    All,

    

    

    

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

---

From: Marcus Dansarie <[email-masked]>
Date: Fri, 16 Nov 2018 17:36:59 +0100

Of course! Thank you for noticing.

/Marcus

---

From: Marcus Dansarie <[email-masked]>
Date: Mon, 19 Nov 2018 22:07:11 +0100

All,

I spent some time this weekend thinking some more about
draft-ietf-ntp-using-nts-for-ntp-14, so here's a reply to myself with
some more points. The large number of points may seem like harsh
criticism of the draft, but that is not my intent. The draft is good,
well written and a result of the hard work of everyone involved.

* The security of many other network protocols depends on having a
correct perception of time. For that reason, NTP is very attractive as
an attack vector. Table I in [1] contains a summary of protocols that
depend on correct time for security. I would also like to recommend
reading [1] in its entirety as it contains a good summary of attacks on
current NTP, many of which NTS seeks to prevent.

* The security of NTS is entirely dependent on the client correctly
verifying the KE-server's certificate and trust chain. This is made
clear in Section 9.3, but I believe it is important enough that Section
3 needs to contain a reference there. It could read something like: "All
implementations are REQUIRED to implement the measures described in
Section 9.3, as this is critical to the security of the protocol."
Furthermore, I think Section 9.3 should have mandatory requirements for
certificate verification. At the very least, this would have a MUST for
following the requirements in RFC 5280 and RFC 6125. There are some
other measures that could be added as well, such as requiring clients to
perform OCSP checking (though there could be privacy implications to
this) or strictly verifying the OCSP Must Staple flag if it is present.
"Initial" should also be removed removed from the heading of Section 9.3.

* If we settle on TLS 1.2 as the minimum requirement, we should only
allow perfect forward secrecy (PFS) suites to be negotiated in the TLS
handshake. Otherwise, the loss of a certificate private key could
theoretically compromise all keys that have been negotiated using that
certificate. In the worst case, this could be active NTS keys belonging
to thousands (or more!) of clients.

* NTS implementations could be vulnerable to "NTS stripping" attacks,
where an attacker fools clients into reverting to plain NTP. Section 9
should contain guidance on this. A naive NTS implementation might try to
connect to the NTS-KE port at the NTP server's address and simply revert
to plain NTP upon handshake or connection failure. This would be easy
for a MITM attacker to exploit. Having the user explicitly mark a server
as NTS compatible is an obvious mitigation. Another would be to forbid
clients from performing unprotected NTP time synchronization with a
server it has successfully performed NTS-protected synchronization with,
at least for a certain amount of time (cf. HSTS).

A more sophisticated attack would be a MITM attacker sending
kiss-o'-death packets to the client, forcing it to reperform the NTS-KE
handshake in a way that fails. It is important that clients do not
revert to plain NTP here, but instead follow the draft: "As long as the
NTS-KE handshake has not succeeded, the client SHOULD continue polling
the NTP server using the cookies and parameters it has." This could also
be used by an attacker with a forged or stolen certificate to force a
NTS key renegotiation using that certificate.

* In reference to the previous point, we should consider public key
pinning as a way for servers to protect against MITM attacks with forged
certificates. The equivalent for HTTPS (HPKP) is specified by RFC 7469.
This would require adding new record types to the NTS-KE protocol.

The argument against key pinning in NTS is that very few NTP server
administrators are likely to want or need this feature and that this
does not warrant further protocol complexity. Public key pinning is also
a double edged sword in that administrator mistakes can cause long-term
service unavailability for large numbers of users. This has happened on
so many occasions that HPKP has been deprecated in the Google Chrome
browser. (Google still pins their own certificates in Chrome though.)

* The canonical way of configuring NTS is for the user to explicitly set
the address of an NTS-KE server in his or her client. I believe this is
a good idea in general. However, there is currently no way for someone
who is using a NTP server to find out if it supports NTS or the address
of its NTS-KE server. It is obviously possible to try to perform a
NTS-KE handshake with the same address as the NTP server, but this will
only work in cases where the NTP and NTS-KE servers share an IP address.
My suggestion for this is that we use DNS SRV records to enable clients
to find the NTS-KE server associated with a certain NTP server. The
record for ntp.example.com would look something like this:
_ntske._tcp.ntp.example.com. 86400 IN SRV 10 10 [[TBD1]] nts.example.com.
where [[TBD1]] should be replaced with the port number assigned for
NTS-KE. SRV records will also enable transition to NTS without any user
interaction when support for NTS is implemented in NTP clients.

* In Section 5.7, the paragraphs

"To protect the client's privacy, the same cookie SHOULD NOT be included
in multiple requests.  If the client does not have any cookies that it
has not already sent, it SHOULD initiate a re-run the NTS-KE protocol."

and

"The client MAY reuse cookies in order to prioritize resilience over
unlinkability.  Which of the two that should be prioritized in any
particular case is dependent on the application and the user's
preference.  Section 10.1 describes the privacy considerations of this
in further detail."

should be moved together for obvious reasons. Currently, one is in the
beginning of the section and the other at the end.

* Missing word in the abstract: The sentence that begins with "The
second handles encryption and authentication during NTP time via
extension [...]" should be "The second handles encryption and
authentication during NTP time synchronization via extension [...]".

Kind regards,
Marcus Dansarie

[1] Malhotra, Aanchal, et al. "Attacking the Network Time Protocol."
NDSS. 2016. <https://ia.cr/2015/1020>

---

From: Dieter Sibold <[email-masked]>
Date: Wed, 21 Nov 2018 21:18:38 +0000

Hi Marcus,

sorry for the late response. See my comments inline.

    All,

The first sentence of your suggestions implies that the clients should fall back to standard unsecured NTP if there the NTS layer is faulty or attacked. Is that your intention? 
I support the second sentence (the word increased replaced by decrease).

I wasn't in favor for this requirement. However, in the meantime RFC 8446 was released and implementations of TLS 1.3 are available now. I therefore agree with you and Ragnar. I would like to learn about Daniel's and Kristof's opinion.

    

Agree.

That is a good point.

I agree with this statement!
    
    Kind regards,

---

From: Dieter Sibold <[email-masked]>
Date: Thu, 22 Nov 2018 16:51:50 +0000

Hi Marcus,

thanks very much for your thoughts and comments. See my comments inline.

Am 19.11.18, 22:07 schrieb "ntp im Auftrag von Marcus Dansarie" <[email-masked] im Auftrag von [email-masked]>:

    All,

Whereas I agree with this statement I'm not sure if I understand your intention. Do you want to add language to the draft that recommends the reading of [1]? 

I agree that implementations shall implement the measures described in 9.3. Therefore the REQUIRED is from my point of view ok. I'm not sure if we should mandate that a client is doing OCSP. I would think this should be an operational choice. We could formulate this as an recommendation. Why removing "Initial" from the heading?

I'm not able to oversee the implications of this requirement. 

This seems to be sound to me. Do you have an proposal to add this to Sec. 9? 

At this stage I wouldn't recommend to add a new record type to the protocol. 

    

    and

I would leave the first paragraph as it is because this is important for the time_request message. The second paragraph provides a choice for the client (which may be moved to the Security Considerations) which I wouldn't move at the beginning of 5.7. But to have both of these statements grouped together we could change the beginning of the second paragraph to something like "Although the client should not reuse a cookie it MAY reuse it in  order ...". 

Thanks for that. I updated the abstract at the github repro.
    
    Kind regards,
    Marcus Dansarie

---

From: [email-masked]
Date: Fri, 23 Nov 2018 09:57:54 +0100

Hello all,

some responses in-line below.

"ntp" <[email-masked]> schrieb am 21.11.2018 22:18:38:

> Von: "Dieter Sibold" <[email-masked]>
> An: "Marcus Dansarie" <[email-masked]>, "[email-masked]" 
<[email-masked]>
> Datum: 21.11.2018 22:19
> Betreff: Re: [Ntp] WGLC comments on draft-ietf-ntp-using-nts-for-ntp-14
> Gesendet von: "ntp" <[email-masked]>
> 
> Hi Marcus,
> 
> Am 15.11.18, 23:00 schrieb "ntp im Auftrag von Marcus Dansarie" 
> <[email-masked] im Auftrag von [email-masked]>:
> 
>     All,
> 
> The first sentence of your suggestions implies that the clients 
> should fall back to standard unsecured NTP if there the NTS layer is
> faulty or attacked. Is that your intention?

If this would be the intention, then I would be against such a paragraph.
The scenario where a user-level requirement of "ONLY use NTS-secured time" 
prevents the client from making any synchronization makes sense and IMO 
should be possible.
 
> I support the second sentence (the word increased replaced by decrease).

Even here, I would like to know the intention behind this statement.
I am wary about the case of "attacks" being simply the flipping of a bit 
to achieve a false negative (i.e. changing something in the packet so that 
the MAC portion of the security addendum doesn't check out and thereby 
basically doing denial-of-service)... in this case, I beleive it is 
correct behaviour for the client to not synchronize to faulty messages and 
also not to unsecured messages.
Basicaly, I'm saying that I think it is okay for our security features to 
introduce new denial-of-service vectors if the alternative would be to 
decrease security requirements.
 
> I wasn't in favor for this requirement. However, in the meantime RFC
> 8446 was released and implementations of TLS 1.3 are available now. 
> I therefore agree with you and Ragnar. I would like to learn about 
> Daniel's and Kristof's opinion.

This is a tough one, not least because my knowledge about differences 
between TLS 1.2 and 1.3 is basically zero.

In general terms, I am very wary of going for more long-term benefits at 
the cost of longer time until actual widespread adoption.
We have basically been using that general strategy for five-and-a-half 
years now, and I have increasing doubts that all of that time was well 
spent:
There are definitely diminishing returns regarding the increase in quality 
with further effort spent on NTS development, and I think we have passed 
the threshold that I personally find acceptable.
Keep in mind that from my point of view, the alternative to NTS adoption 
is people running a choice or combination of unsecured associations, 
old-style MACs with symmetric keys and no clear procedure, or (internet 
gods forbid) Autokey.

Further, I don't see how (with the right wording) there could ever be a 
situation in which servers would be forced to support TLS 1.2.
At worst, there would come a time where a bunch of clients cannot have 
security with the implementations that they have because nobody supports 
it anymore.
That still does not seem worse than the current situation.

My lack of knowledge regarding the TLS version change prevents me from 
having a qualified opinion.
For example, I have no concept of how long a restriction to TLS 1.3 only 
would hold back widespread NTS adoption.
Thus, I don't want my doubts here to get in the way of a decision.
Daniel, what is your opinion on the matter now undder the new 
circumstances?
 
>     protected NTP replies that lie within the certificate's validity 
time."

Oof, semantically this is weird territory, especially with the automatic 
key refreshment that we get with the current cookie management.
What guarantees is the client really basing on the server's certificate?
In general, authenticity properties are untouched by keys expiring or even 
being lost, as long as the record shows that the authenticity statement 
was made at a time when the key could still be trusted.
This is not true for secrecy properties though, and I have no initial 
grasp of how later authenticity properties are inherited from earlier 
secrecy properties to comment on how quickly a client needs to build a new 
trust model after a certificate expires (even if we assume that all keys 
associated with a certificate are compromised the instant it expires).
Would be an interesting question to do research on, and maybe someone 
already has?
 
>     draft-schiff-ntp-chronos-01 could be a good idea.

Is a reference (even an informative one) to an early draft a good idea?
What is the IETF policy on keeping such a reference updated in something 
that is hopefully soon an RFC?

---

From: [email-masked]
Date: Fri, 23 Nov 2018 10:04:39 +0100

Comments in-line.

<[email-masked]>
> Datum: 22.11.2018 17:52
> Am 19.11.18, 22:07 schrieb "ntp im Auftrag von Marcus Dansarie" 
> Whereas I agree with this statement I'm not sure if I understand 
> your intention. Do you want to add language to the draft that 
> recommends the reading of [1]?

I too would like to know how that translates to recommendations for our 
document text?
 
> I agree that implementations shall implement the measures described 
> in 9.3. Therefore the REQUIRED is from my point of view ok. I'm not 
> sure if we should mandate that a client is doing OCSP. I would think
> this should be an operational choice. We could formulate this as an 
> recommendation. Why removing "Initial" from the heading?
> 

Yes, the case where a client insists on running unsecured associations in 
combinations with secured ones at all is complicated and should IMO be 
advised against.
 
> At this stage I wouldn't recommend to add a new record type to the 
protocol.

I concur.
 
> I would leave the first paragraph as it is because this is important
> for the time_request message. The second paragraph provides a choice
> for the client (which may be moved to the Security Considerations) 
> which I wouldn't move at the beginning of 5.7. But to have both of 
> these statements grouped together we could change the beginning of 
> the second paragraph to something like "Although the client should 
> not reuse a cookie it MAY reuse it in  order ...". 
> 
>

---

From: Marcus Dansarie <[email-masked]>
Date: Fri, 23 Nov 2018 22:40:15 +0100

Hi!

Thank you for your insightful comments. To avoid an exponential increase
in the number of replies, I'm trying to reply inline to all four mails
at once below. Please let me know if I missed something.

I will create pull requests on Github for the suggested changes,
hopefully before Monday.

I am also eager to hear your opinions on my suggested use of DNS SRV
records for clients to find NTS-KE servers. I believe this would greatly
improve the time and breath of adoption of NTS.

Kind regards
Marcus Dansarie

On 2018-11-21 22:18, Dieter Sibold wrote:

> The first sentence of your suggestions implies that the clients should
fall back to standard unsecured NTP if there the NTS layer is faulty or
attacked. Is that your intention?
> I support the second sentence (the word increased replaced by decrease).

No, the intention with the suggested text is to make clear that attacks
on the NTS-KE infrastructure shouldn't affect clients that already have
cookies and are performing NTS protected time synchronization with an
NTP server. Obviously, I failed in making that clear. I can revise the
suggested text or we can skip adding this entirely.

On 2018-11-22 17:51, Dieter Sibold wrote:> Hi Marcus,
> Whereas I agree with this statement I'm not sure if I understand your
intention. Do you want to add language to the draft that recommends the
reading of [1]?

I only meant that point as a general background to my other comments. I
do not propose a reference to [1] in the draft. Sorry if that was unclear.

> I agree that implementations shall implement the measures described in
9.3. Therefore the REQUIRED is from my point of view ok. I'm not sure if
we should mandate that a client is doing OCSP. I would think this should
be an operational choice. We could formulate this as an recommendation.
Why removing "Initial" from the heading?

I agree that we should be careful with what checks we require clients to
do and that a list of recommendations is probably better. We should try
and find an expert on TLS security who is willing to look over Section 3
and 9.3 and make suggestions. Posting a question on the TLS WG mailing
list could be an idea.

I want to remove "Initial" from the heading to emphasize that
certificate verification should be done every time on every handshake
with the KE server, not just the first one.

> I'm not able to oversee the implications of this requirement.

I don't see any implications other than that some old or badly
configured TLS 1.2 implementations may not be able to perform a
handshake. If decide to require TLS 1.3, this won't be a problem since
TLS 1.3 mandates PFS cipher suites. For the security advantages, see my
reply to Kristof below.

> This seems to be sound to me. Do you have an proposal to add this to
Sec. 9?

I will write a suggested text and submit a pull request.

> At this stage I wouldn't recommend to add a new record type to the
protocol.

I think you are right. My suggestion then is that we add language to
Section 9.3 mentioning this attack vector and that client
implementations can mitigate it by allowing clients to manually pin
keys. Verification of key fingerprints would have to be performed out of
band. This makes it an implementation issue. Another mitigation would be
to use NTPs support for symmetric message authentication instead of NTS,
preferably the one described in draft-ietf-ntp-mac-05.

> I would leave the first paragraph as it is because this is important
for the time_request message. The second paragraph provides a choice for
the client (which may be moved to the Security Considerations) which I
wouldn't move at the beginning of 5.7. But to have both of these
statements grouped together we could change the beginning of the second
paragraph to something like "Although the client should not reuse a
cookie it MAY reuse it in  order ...".

Ok. I'll look over the draft and create a pull request with the
suggested changes.

On 2018-11-23 09:57, [email-masked] wrote:> Hello all,
> The scenario where a user-level requirement of "ONLY use NTS-secured
> time" prevents the client from making any synchronization makes sense
> and IMO should be possible.

This is not my intention, see my reply to Dieter above.

> to achieve a false negative (i.e. changing something in the packet so
> that the MAC portion of the security addendum doesn't check out and
> thereby basically doing denial-of-service)... in this case, I beleive it
> is correct behaviour for the client to not synchronize to faulty
> messages and also not to unsecured messages.
> Basicaly, I'm saying that I think it is okay for our security features
> to introduce new denial-of-service vectors if the alternative would be
> to decrease security requirements.

I too worry about "NTS stripping" attacks. It is clear from both your
and Dieter's comments that my and Ragnar's suggested text did not convey
the idea very well.

> There are definitely diminishing returns regarding the increase in
> quality with further effort spent on NTS development, and I think we
> have passed the threshold that I personally find acceptable.

TLS 1.3 is a major step forward in that it deprecates many older and
less secure parts of the TLS protocol. It also reduces the number of
round trips for a TLS handshake from three to two (plus TCP
handshaking). In short: better security and higher speed.

I also agree with you that any suggestions or changes at this point
should be small and not inhibit the process of making this draft an RFC.
I do, however, disagree with you when it comes to prioritizing long- or
short-term benefits. I believe that long-term benefits are preferable
over faster NTS adoption in the short term.

Adoption of TLS 1.3 is ongoing with a number of available
implementations, see
<https://github.com/tlswg/tls13-spec/wiki/Implementations>. Facebook
reports that over 50% of their Internet traffic is now secured with TLS
1.3. Also, OpenSSL 1.1.1 with TLS 1.3 support was released in September
and is starting to make its way into Linux distributions.

Regardless of what we choose, we should not let this delay the draft
progress. My preferences are (in order):
* TLS 1.3
* Current wording of Section 3 with the additional requirement that
NTS-KE must offer only cipher suites that have PFS.
* Current wording of Section 3.

> In general, authenticity properties are untouched by keys expiring or
> even being lost, as long as the record shows that the authenticity
> statement was made at a time when the key could still be trusted.
> secrecy properties to comment on how quickly a client needs to build a
> new trust model after a certificate expires (even if we assume that all
> keys associated with a certificate are compromised the instant it
expires).
> Would be an interesting question to do research on, and maybe someone

Yes, this is weird. My simple view is that if a client performs a NTS-KE
handshake with a server and correctly verifies the certificate, there is
an implicit guarantee that any subsequent NTS-protected communication is
with the entity that controlled the NTS-KE server during the initial
handshake. I will search around to see if anyone has written something
on situations like this.

I can see two ways that the security guaranteed by the NTS-KE server and
verification of that server's certificate can be compromised:

1. An attacker gains knowledge of the S2C and C2S keys used by a
specific NTP client. If the attacker has recorded the TLS handshake and
then gains access to the server's private certificate key, these can be
recreated. Requiring PFS cipher suites prevents this entirely as this
makes the generated symmetric keys independent of the server certificate
key.

2. An attacker gains knowledge of the cookie encryption key shared
between the NTS-KE and NTP servers. The attacker can then decrypt or
alter any cookies encrypted with that key. My proposed solution to this
is for NTP servers to use a different key for cookies it issues than the
one shared with the NTS-KE server. For example: A NTS server encrypts
the cookies it issues with key A. This key is shared with a NTP server.
When the NTP server receives a cookie encrypted with key A, it returns
new cookies encrypted with key B. Key B is not shared with the NTS
server. If all cookies received from the NTS-KE server have been used
when its certificate expires and a PFS suite was used, all the remaining
trust should be between the NTP server and the client. This solution is
an implementation issue rather than a protocol issue, but it should be
noted in Section 9.

Additionally, an attacker with current access to a NTS-KE server can
obviously access all keys required for an attack.

> that is hopefully soon an RFC?

The text in RFCs is never updated. Maybe a just a more vague reference
to ongoing IETF work on the issue?