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

[Sharon Goldberg <[e-mail]>]

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 <[e-mail]> wrote:

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



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

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