Subject: Re: [Ntp] Sharon Goldberg comments on draft-ietf-ntp-using-nts-for-ntp

From: [email-masked]
Date: Mon, 27 Nov 2017 14:22:04 +0100

Hello all,

I wanted to go into a few key issues that Sharon raised in her review of 
NTS that still have us unsure of how to proceed (either because we cannot 
reach agreement between the authors/editors, or because we feel we need to 
justify our decision towards the working group or both).

For the rest of the discussion, I would like to establish a few 
fundamentals that we have never explicitly talked about.
Let me know if there is significant reason for discourse over these:

A) Interests of the participants

Inherently, participants in NTS-secured NTP communication have very 
different interests depending on their role.
  - Any *client* has an interest to get the most reliable, most accurate 
measurements possible reagrding its offset from a chosen time server. This 
interest benifits the client itself. The client does not inherently want 
to or have to do anyhting to benefit the server.
  - Any *server* has a very simple interest: to serve clients. It does not 
have any interests that benefit itself (except, implicitly, to not cause 
harm, to itself or third parties by using NTS).

Interestingly, this means that often, the server's behavior must be more 
closely regulated than the client's.
After all, if a client wants to go against its own interest, this is 
hardly preventable.
But for any instance where the bahavior of the server affects the client's 
interest, I think that normative language is in order.

B) Strategic motivation

The NTS draft's overall strategic motivation is twofold:
    - We want make sure that participants (=clients, since everything 
other than client-server mode is out) can rely on the timing information 
that they use to synchronize their clock.
    - We want to make sure that implementations following this draft are 
additionally satisfying good practice with regards to being internet 
protocols.
Basically anything else is out of scope, and anything that falls under the 
second bullet point is often highly debatable.

All the items that are currently under "1.1 Objectives" are fundamentally 
just means to achieve either of the two ends listed above.
I am currently thinking about whether I would like to make this more clear 
in the document -- opinions are welcome.

C) The way the document communicates

My understanding of an RFC candidate is that, most of all, it should be 
instructive. It should tell an implementor what to do, as unambiguously as 
possible, but also only as detailed as necessary.
A secondary responsibility that we have is to explain what is going on, so 
that the reader has enough context to see how it is supposed to work and 
compare the actual contents of the document to their expectation. But, 
again, this should IMO only be as detailed as necessary.
A tertiary goal that will sometimes be nice to have is to justify why and 
how what we specify actually works as intended, or why and how it fulfills 
the requirements we state initially. But this cannot be a requirement, 
otherwise the document will simply become too lengthy, AND significant 
parts of it would simply be unnecessary for most implementors/informed 
readers.

D) Attacker model and DoS

I have always worked from the assumption that NTS needed to be secure 
under a Dolev-Yao model (meaning that the modeled attacker can control all 
aspects of the communication).
As kind of a corollary from this, I have always regarded any attack vector 
that gives at worst such capabilities to an attacker as low-priority 
material.
Such attack vectors include, but are not limited to:
  - DoS of a *single* client participant (meaning that it won't be able to 
successfully synchronize its clock via NTS-secured NTP anymore) by 
bombarding it (or its server) with packets
  - DoS of a server (and therefore multiple clients) for limited amounts 
of time (even though I have to admit that this is more severe)
  - Clever use of fragmentation in order to achieve observer capabilities, 
or basically anything that bossts an attacker's capability towards up to 
Dolev-Yao capabilities

Well, now for the issues that remain from the feedback.
I am omitting large parts of Sharon's text. This is only supposed to mean 
that we the editors have a good sense on how to proceed about the points 
raised there, one way or another.
For the remaining issues, I am going to format my discussion starters as 
replies in line.

Best regards, 
Kristof

"ntp" <[email-masked]> schrieb am 31.08.2017 19:13:52:

> Von: Sharon Goldberg <[email-masked]>
> An: [email-masked]
> Datum: 31.08.2017 19:14
> Betreff: [Ntp] Sharon Goldberg comments on 
draft-ietf-ntp-using-nts-for-ntp
> Gesendet von: "ntp" <[email-masked]>
> 
> Review of NTS.
> 
[...]
> 
> Section 1.2:  Says: 
> 
>     However, client-server mode also has more
>    relaxed security needs, because only the client requires replay
>    protection: it is harmless for servers to process replayed packets.
>    
> This is false. 

With a broad statement like such as "it is 100% harmless, period", I agree 
that it is false.
However, I stand by the statement that it is harmless in the context that 
is harmless in our scope.

A replay attack on the client (if not protected against) could lead the 
client to falsely accept a timing packet as authentic even though it could 
be in a completely wrong timing context. Just replay an otherwise 
authentic packet a minute/an hour/a day... later, and you can wreak havoc 
if the client has no concept of "a reply to this request was already 
received" and therefore no reason to drop the packet. 

In this context, a replay attack on the server is not in the same league 
as a replay attack on the client. Actually, it isn't even really playing 
the same game.
(See issues B) and D) int this mail's header)

So how do we proceed?
I am not opposed to going into this issue in a few (!) words, weakening 
the statement that it is harmless to something that is effectively "it is 
not a potential immediate catastrophe". I do not, however, believe that it 
is worth going into the damage that the server can suffer from replay 
attacks performed on it.

> It can be harmful for a server to process replayed packets if that 
> server keeps client state in order to perform rate limiting with a 
> KoD. Specifically, an adversary can replay client packets at high 
> rate to the server, in order to trigger rate-limint restrictions at 
> the server and cause the server to send a "RATE" KoD to the client. 
> Once the client receives this KoD, it will slow down or even stop 
> its communications with the server.  In other words, this is a DoS 
attack.

Scaling-wise, I do not think that it makes sense to treat this.
Yes, any form of rate-limiting is prone to causing issues like this.
Also, replay protection doesn't seem to do anything here, other than to 
save the attacker the hassle of simply inventing new packets for the 
client (remember that rate limiting should be done before any kind of 
authentication checks, so valid MACs aren't actually useful to have).

> This is CVE-2015-7705 which we called the "priming the pump"  attack
> in our NDSS'15 paper:
> 
> https://eprint.iacr.org/2015/1020.pdf
> 
> Thus, I suggest that the draft include some language targeted at 
> servers that do perform rate limiting with the KoD.  Those servers 
> MAY take advantage of NTS's replay protection to stop the Priming 
> the Pump attack.  In other words, these servers MAY track the 
> client's unique identifiers and making sure that they are not 
> reused, as a way of preventing the priming the pump attack. I am 
> suggesting the use of MAY because this can be resource intensive for
> the server.  (But, a data structure like a bloom filter could be 
> used to minimize the overhead at the server of checking uniqueness 
> of "unique identifiers").
> 
> I also suggest adding some text to the security considerations, 
> explaining that when the server uses (1) rate limiting with the KoD 
> but (2) does not use NTS's replay protections, then the server is 
> vulnerable to the Priming the Pump attack of CVE-2015-7705.

This is something that I might be convinced of.
I kind of see it as an argument for why per-client rate limiting is 
systemically a problematic idea though.

[...]
> Section 5:
> 
> As a point of presentation: I had trouble getting a high level view 
> of the protocol from reading Section 5.  Some issues confused me 
> that I think should be defined up front.  In other words, I think 
> Section 5 should start with some prose (even a new subsection) that 
> gives a detailed overview of the protocol.
> 
> Pointing out some specific confusions of mine.
> 
> - There are several "numbers" defined in this document, and it is 
> hard for the reader to disambiguate between them. Specifically, 
> there is the "Next Protocol number" and the "Field Type" and the 
> "Record Number". The start of Section 5 should start by telling the 
> reader what are the different "fields" and "types", and each of 
> their purposes.  I also suggest providing references to the relevant
> IANA Considerations in Section 8.
> 
> - This section would benefit by showing a ladder presenting the 
> sequence of communications and message types that go back and forth 
> during a typical NTS exchange.

Yes, I think we could agree on this.

> 
> - I'm not clear if the C, record type, and body length fields 
> depicted in Figure 1 need to be authenticated by the AEAD 
> authenticator.  Maybe this should be spelled out more clearly.
> 
> ****
> 
> Nowhere in the document do a see an explicit statement about when 
> the client is allowed to start taking time from an NTS-secured 
> server.  I think the draft should spell this out, at the very 
> minimum with a SHOULD requirement, and possibly even a MUST.  To do 
> this, it would help to have a ladder that shows the protocol flow, 
> and spells out in what point in the flow the client can start taking 
time.

I think we have to declare this as outside of our scope, especially since 
NTP is not the only way of manipulating your computer's clock.
The best I think we could do is to point out that time data cannot be 
asserted as authentic/secure before the initial key exchange is completed.
Here, I honestly think this follows trivially from any form of diagram and 
should be easy to see even without one. So with Issue C) from the mail 
header in mind, I doubt that it is a good idea to spend words on this.

[...]
> 
> 5.1.6  Cookies.
> 
> Earlier on this list there was discussion on whether or not the 
> draft should specify normative requirements on cookies.  Personally,
> I support that view that we should place normative requirements on 
> cookies, because an insecure cookie implementation would break the 
> security of the whole protocol. 
> 
> That said, what is a show stopper in my opinion, is a lack of 
> specification in the draft of what properties are required from the 
> cookie.  At the very least, we want to make sure that the cookie 
> does not leak the C2S and S2C keys to an observer (or a man in the 
middle).

I do agree that this is an instance where normative language is called for 
(see Issue A) in the mail header).
However, it is really difficult to mandate anything that ensures an 
abstract requirement (like "do not leak a given key") and stays 
instructive.
For example, does it count as not leaking if I encrypt with a provenly 
unsecure algorithm? How am I supposed to know which algorithms are okay?

Personally, I believe that this means we should actually mandate one or 
more specific secure formats for the cookie (e.g. the one 
described/recommended in the doc).

But I think that consensus on this issue is far from reached.

So how do we proceed?
I would like the WG to give their opinioins on this issue in some explicit 
form, so that consensus can be reached and we at least know that there was 
a form of conscious decision.
  
> If I have misunderstood, and this confidentiality is provided 
> because the cookie is encrypted (as a MUST) by the AEAD scheme, then
> the draft should make this point more clear in section 5.1.6.

No, you have not misunderstood.
The encryption layer you mention is not the one that protects against key 
leakage (the cookie is, at another point, sent in cleartext).
 
> Also, is there a requirement that cookies be different across 
> different clients? That each cookie used by a client is unique?  At 
> the very least these requirements should be spelled out as a MUST 
> somewhere.  If SHOULD is used, then a discussion of the risks of not
> adhering to these requirements should be provided.

I am honestly unsure about the effort of discussing this in the document, 
for the simple reason that it is absolutely not specific to NTS.
Citing this would be a 100% preferable action IMO. If no citable document 
can be found, then I do not know how to proceed.
 
> If this is somewhere in the draft already, and I missed then, then 
> apologies. But this text should be referenced in Section 5.1.6.
> 
> ******
>