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

[Marcus Dansarie <[e-mail]>]

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:

>     * 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."
>
> 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,
>     * 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.
>
> 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.

>     * 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.
>
> 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.

>     * 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.
>
> 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.

>     * 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.
>
> 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.

>     * 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.
>
> 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.

>     * 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.
>
> 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, [e-mail] wrote:> Hello 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.

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

>> 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 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.

>>     * 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.
>>
>> 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?

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 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."
>
> 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?

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.

>> Agree.
>>
>>     * 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.
>>
>> That is a good point.
>
> 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?

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