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

Dieter Sibold
dsibold.ietf@gmail.com

On 26 Mar 2019, at 10:47, Harlan Stenn wrote:

> On 3/26/2019 2:41 AM, Watson Ladd wrote:
>>
>>
>> On Tue, Mar 26, 2019, 9:02 AM Harlan Stenn <stenn@nwtime.org
>> <mailto:stenn@nwtime.org>> 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.

 From my point of view these are arguments against leap-smearing and not 
against the data minimization draft which from my point of view is 
mandatory since it meet modern regulation requirements such as the eu 
gdpr.

- Dieter

>
> -- 
> Harlan Stenn, Network Time Foundation
> http://nwtime.org - be a Member!
>
> _______________________________________________
> ntp mailing list
> ntp@ietf.org
> https://www.ietf.org/mailman/listinfo/ntp