Subject: [ntpwg] Unlinkability formulations in merged draft "NTS-4-NTP"

From: [email-masked]
Date: Wed, 8 Mar 2017 14:48:30 +0100

Hello all,

we have made a few changes to the merged draft (have been pushed to the 
repository at https://github.com/dfoxfranke/nts) after some discussion 
with Aanchal.
These changes are about the formulation of the text regarding 
unlikability.
We would welcome any comments or suggestions.

The relevant text in Section "Objectives":

- Privacy: NTS preserves unlinkability, i. e. it does not leak data that 
would allow an attacker to track mobile NTP clients when they move between 
networks. Note that unlinkability is not guaranteed for devices that 
function as servers as well as clients, see [link to Section "Privacy 
Considerations"].

The relevant text in Section "Privacy Considerations":

Unlinkability shall prevent that a device can be tracked when it changes 
networ adresses (e.g. because said device moved between different 
networks). This is to say that an attacker shall be unable to link a new 
address with one that was formerly used by the device, because of 
recognizable data that the device persistently sends as part of an 
NTS-secured NTP association. This is the justification for continually 
supplying the client with fresh cookies, so that a cookie never represents 
recognizable data in the sense outlined above.

Note that the objective of NTS regarding unlinkability is merely to not 
leak any additional data that would cause linkability. NTS does not 
rectify legacy linkability issues that are already present in NTP. To 
minimize the risk of being tracked by a passive adversary the NTP client 
has to minimize the information it transmits within a client request (mode 
3 packet) as described in the draft "draft-dfranke-ntp-data-minimization"

Also, the objective only holds for actual time synchronization traffic, as 
opposed to key exchange traffic. This implies that it cannot be guaranteed 
for devices that function not only as time clients, but also as time 
servers (because the latter can be externally triggered to send 
authentication data).

What do people here think?

Best regards,
Kristof

_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

From: Sharon Goldberg <[email-masked]>
Date: Wed, 8 Mar 2017 10:12:39 -0500

Kristof, thanks for this.  There are 3 documents in there, I assume you are
talking about

https://github.com/dfoxfranke/nts/blob/master/draft-ietf-
ntp-using-nts-for-ntp.xml

right? Also, there are some missing refs so the draft doesn't compile on
xml2rfc ...

On Wed, Mar 8, 2017 at 8:48 AM, <[email-masked]> wrote:

> These changes are about the formulation of the text regarding unlikability.
> leak any additional data that would cause linkability. NTS does not rectify
> legacy linkability issues that are already present in NTP. To minimize the
> risk of being tracked by a passive adversary the NTP client has to minimize
> the information it transmits within a client request (mode 3 packet) as
> described in the draft "draft-dfranke-ntp-data-minimization"
>

-- 
Sharon Goldberg
Computer Science, Boston University
http://www.cs.bu.edu/~goldbe
_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

From: Sharon Goldberg <[email-masked]>
Date: Wed, 8 Mar 2017 11:41:53 -0500

This is looking good.  I've taken a pass over what was sent and propose the
below candidate text.

Note my use of the IETF "MUST".

- Privacy: Once an NTS session has been established, NTS supports
unlinkability for devices that (1) use NTS as clients and (2) minimize the
information they expose in client query (mode 3) packets per
"draft-dfranke-ntp-data-minimization" . Unlinkability ensures that NTS does
not leak data that allows an attacker to track mobile NTP clients when they
move between networks. See [link to Section "Privacy Considerations"] for
details.

Unlinkability prevents a device from being tracked when it changes network
addresses (e.g. because said device moved between different networks). In
other word, unlinkability thwarts an attacker that seeks to link a new
network address used by a device with a network address that it was
formerly using, because of recognizable data that device is persistently
sent as part of an NTS-secured NTP association. This is the justification
for continually supplying the client with fresh cookies, so that a cookie
never represents recognizable data in the sense outlined above.

NTS's unlinkability object is merely to not leak any additional data that
could be used to link a device's network address. NTS does not rectify
legacy linkability issues that are already present in NTP. Thus, a client
that requires unlinkability MUST also minimize information transmitted in a
client query (mode 3) packet as described in the draft
"draft-dfranke-ntp-data-minimization"

The unlinkability objective only holds for time synchronization traffic, as
opposed to key exchange traffic. This implies that it cannot be guaranteed
for devices that function not only as time clients, but also as time
servers (because the latter can be externally triggered to send
authentication data).

It should also be noted that it could be possible to link devices that
operate as time servers from their time synchronization traffic, using
information exposed in (mode 4) server response packets (e.g. reference ID,
reference time, stratum, poll).  Also, devices that respond to NTP control
queries could be linked using the information revealed by control queries.

On Wed, Mar 8, 2017 at 10:12 AM, Sharon Goldberg <[email-masked]> wrote:

> Kristof, thanks for this.  There are 3 documents in there, I assume you
> are talking about
>
> https://github.com/dfoxfranke/nts/blob/master/draft-ietf-ntp
> -using-nts-for-ntp.xml
>
>> Also, the objective only holds for actual time synchronization traffic,
>> as opposed to key exchange traffic. This implies that it cannot be
>> guaranteed for devices that function not only as time clients, but also as
>> time servers (because the latter can be externally triggered to send
>> authentication data).
>>
>>

---

From: Sharon Goldberg <[email-masked]>
Date: Wed, 8 Mar 2017 11:42:57 -0500

Btw, let us know when is a good time to review the whole draft.
I'd like to take a look before IETF.

On Wed, Mar 8, 2017 at 11:41 AM, Sharon Goldberg <[email-masked]> wrote:

> This is looking good.  I've taken a pass over what was sent and propose
> the below candidate text.
>
> "draft-dfranke-ntp-data-minimization" . Unlinkability ensures that NTS
> does not leak data that allows an attacker to track mobile NTP clients when
> they move between networks. See [link to Section "Privacy Considerations"]
> for details.
>
> The unlinkability objective only holds for time synchronization traffic,