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

[Sharon Goldberg <[e-mail]>]

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

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