Re: [Ntp] Objections to the current language in draft-ietf-data-minimization

[Harlan Stenn <[e-mail]>]

On 3/26/2019 2:41 AM, Watson Ladd wrote:
> 
> 
> On Tue, Mar 26, 2019, 9:02 AM Harlan Stenn <[e-mail]
> <mailto:[e-mail]>> wrote:
> 
>     In my opinion, draft-ietf-ntp-data-minimization-04, like its -03
>     predecessor, exclusively focuses on ways to expose as little information
>     as possible and completely ignores and discounts the costs or problems
>     that can and in some cases will occur if its recommendations are
>     followed.
> 
>     If my claims are accepted, section 1. Introduction of
>     draft-ietf-ntp-data-minimization should be appropriately rewritten to
>     remove its incorrect, or at least misleading, claims, and many of the
>     “SHOULD” recommendations in the document should be changed to “MAY”.
> 
>     In particular, draft-ietf-ntp-data-minimization blindly and explicitly
>     recommends setting LI, the poll interval, and the REFID to 0, with no
>     offered analysis for the costs or benefits of the effects of these
>     recommendations.
> 
>     In this email I’ll use a leap second event to illustrate these points.
> 
>     Regardless of whether or not you believe leap smearing is “good”, there
>     are time servers out there that only offer correct time, some that only
>     offer leap-smeared time, and some that offer one or the other -
>     depending on how they’re asked.
> 
>     For better or worse, a noticeable group of time server operators now
>     offer leap-smeared time in response to NTP mode 3 (client) requests.
>     Sometimes this is what the clients want, sometimes it is not.
>     Regardless, there is clear value and benefit in being able to see if:
> 
>     a server is offering correct, or leap-smeared time
>     a client is following a correct, or a leap-smearing server
> 
>     Let’s look a the poll interval first.  If a server knows a leap second
>     event is coming, it is in a position to look at the poll interval from
>     the client and send back a recommended poll interval that will make sure
>     the client properly handles leap second handling.  Yes, even if the
>     client “lies” and doesn’t tell the server its actual poll interval, the
>     server can respond conservatively, and be responsible to the client.
>     This behavior may well cause an unnecessary increase in the server load.
>      It is also possible that the server may choose to remember the IP and
>     port of the incoming request to independently try and verify the actual
>     poll interval used.  But this is also a case of cost-shifting, and I am
>     opposed to it.
> 
> 
> Alternatively clients can ensure that they pull at least once every 24
> hours so they will know when a second happens.

Are these clients leap-second aware?  If so, that's probably true.

If they are not leap second aware then you're talking about clients that
don't place a high value on accurate time synchronization, so they don't
care.

This is not the client population that will have problems with data
minimization.

-- 
Harlan Stenn, Network Time Foundation
http://nwtime.org - be a Member!