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

[[e-mail]]

Hello all,

some responses in-line below.


"ntp" <[e-mail]> schrieb am 21.11.2018 22:18:38:

> Von: "Dieter Sibold" <[e-mail]>
> An: "Marcus Dansarie" <[e-mail]>, "[e-mail]" 
<[e-mail]>
> Datum: 21.11.2018 22:19
> Betreff: Re: [Ntp] WGLC comments on draft-ietf-ntp-using-nts-for-ntp-14
> Gesendet von: "ntp" <[e-mail]>
> 
> Hi Marcus,
> 
> sorry for the late response. See my comments inline.
> 
> Am 15.11.18, 23:00 schrieb "ntp im Auftrag von Marcus Dansarie" 
> <[e-mail] im Auftrag von [e-mail]>:
> 
>     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."
> 
> 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.
 
>     * 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?
 
>     * 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."

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?
 
> 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?
 
>     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.
> 
> I agree with this statement!
> 
>     Kind regards,
>     Marcus Dansarie and Ragnar Sundblad
> 
>     _______________________________________________
>     ntp mailing list
>     [e-mail]
>     https://www.ietf.org/mailman/listinfo/ntp
> 
> _______________________________________________
> ntp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ntp