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

[Harlan Stenn <[e-mail]>]

HI Kristof,

On 3/26/2019 4:58 AM, [e-mail] wrote:
> 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's fine, but it's a separate discussion.

Some Very Big Players are insisting on using leap-smeared time, so it's
a fact of life that we must live with.

As written, the data-minimization would make it pretty much impossible
to handle mixed client populations where some clients were leap-second
aware and some were not.

Forcing a decision on this point - in either direction - is effectively
"creative destruction", and will only serve to fracture the current
infrastructure.

I think that's a terrible idea.

The goal in what I'm proposing is, in effect, either "live and let
live", or perhaps "be excellent to each other".

> 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 occurences 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

Different groups have different needs/goals.  One size simply does not
fit all situations.

> 
> Best regards,
> Kristof

H
--
> 
> 
> 
> Von:        "Dieter Sibold" <[e-mail]>
> An:        "Harlan Stenn" <[e-mail]>
> Kopie:        "Watson Ladd" <[e-mail]>, [e-mail]
> Datum:        26.03.2019 11:05
> Betreff:        Re: [Ntp] Objections to the current language in
> draft-ietf-data-minimization
> Gesendet von:        "ntp" <[e-mail]>
> ------------------------------------------------------------------------
> 
> 
> 
> 
> 
> Dieter Sibold
> [e-mail]
> 
> 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 <[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.
> 
> 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 <http://nwtime.org/>- be a Member!
>>
>> _______________________________________________
>> ntp mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ntp
> 
> _______________________________________________
> ntp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ntp
> 
> 
> 
> _______________________________________________
> ntp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ntp
> 

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