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

[Sharon Goldberg <[e-mail]>]

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

The relevant text in Section "Objectives":

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

The relevant text in Section "Privacy Considerations":

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 <[e-mail]> 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
>
> right? Also, there are some missing refs so the draft doesn't compile on
> xml2rfc ...
>
> On Wed, Mar 8, 2017 at 8:48 AM, <[e-mail]> wrote:
>
>> 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
>> [e-mail]
>> http://lists.ntp.org/listinfo/ntpwg
>>
>
>
>
> --
> Sharon Goldberg
> Computer Science, Boston University
> http://www.cs.bu.edu/~goldbe
>



-- 
Sharon Goldberg
Computer Science, Boston University
http://www.cs.bu.edu/~goldbe

_______________________________________________
ntpwg mailing list
[e-mail]
http://lists.ntp.org/listinfo/ntpwg