Re: [Ntp] [EXT] An NTPv5 design sketch

On 13 Apr 2020, at 23:16, Daniel Franke wrote:

> On Mon, Apr 13, 2020 at 5:07 PM Ulrich Windl
> <Ulrich.Windl@rz.uni-regensburg.de> wrote:
>>> * Time packets carry an unencrypted and unauthenticated correction
>>>    field intended for manipulation by middleboxes. The function of 
>>> this
>>
>> Doesn't this feature make requiring NTS obsolete? Any MiTM could
>> manipulate these fields then.
>
> I address this some in the final paragraph; implementations need to
> set a limit on the magnitude of the correction they're willing to
> accept, and that limit must be no greater than half the round-trip
> time. Without NTS, the magnitude by which a MitM can manipulate your
> clock is unlimited. With NTS and half-RTT limit on correction fields,
> the magnitude is at most double what it would be with NTS and no
> correction fields (up to a whole RTT rather than a half an RTT).

That is the problem with correction field. In 1588 working group we had 
the same problem with PTP’s correction field. But this does not make 
NTS obsolete. Although a MITM might mingle with the corruption field NTS 
ensures integrity and authenticity of the rest of the NTP packet. So the 
client can trust that the origin of the packet and also the timestamps 
from the packet. If the client as reason to believe that the correction 
fields have been tampered it can even chose to ignore them.

>
>> (also I'm still wondering what's the
>> benefit of encrypting the current time when sending it out more or 
>> less
>> real-time)
>
> Almost certainly none, but given that NTS requires encryption
> regardless (for cookie unlinkability), why in the world would we want
> to *not* encrypt it? What do we gain by trying to pick and choose
> which fields we think really need encryption?

There is no reason not to encrypt the timestamps in a new version of 
NTP.

>
> _______________________________________________
> ntp mailing list
> ntp@ietf.org
> https://www.ietf.org/mailman/listinfo/ntp