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

Hello all,

I support Dieter's viewpoint that most of Harlan's original points can be 
read as arguments against leap smearing rather than arguments against data 
minimization (or the way it is handled in the current Data Minimization 
draft).
Honestly, I would go one step further and add that the whole discussion 
point is an argument for the case that the decision to use UTC over TAI in 
the first place was a mistake and should be reconsidered as soon as 
possible (which might not be soon at all).

That digression aside, the decision that was put forward was that of the 
document using either "SHOULD" or "MAY" for certain normative clauses.
First off, I'm a bit unclear about the significance of this decision (as 
in, who would be affected): wouldn't the same implementation be the same 
degree of conformant to a given document if all occurances of SHOULD were 
replaced by MAY and/or vice versa?
That said, it is my belief that given the rather hard-to-measure 
difference as outlined in RFC 2119, SHOULD is better suited than MAY a 
collection of suggestions
- whose advantages include making things conformant to current data 
protection regulations and preventing security goals of a crypto add-on 
from being unobtainable in the first place due to quirks of the underlying 
protectee protocol
- whose main (argued) disadvantage is that it reduces the convenience with 
which a potentially system-disrupting hack can be executed

Best regards,
Kristof

Von:    "Dieter Sibold" <dsibold.ietf@gmail.com>
An:     "Harlan Stenn" <stenn@nwtime.org>
Kopie:  "Watson Ladd" <watsonbladd@gmail.com>, ntp@ietf.org
Datum:  26.03.2019 11:05
Betreff:        Re: [Ntp] Objections to the current language in 
draft-ietf-data-minimization
Gesendet von:   "ntp" <ntp-bounces@ietf.org>

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

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