Re: [Ntp] NTS IANA request

[" [e-mail] " <[e-mail]>]

Err this not thus 

Sent from my HTC, so please excuse any typos.

----- Reply message -----
From: "[e-mail]" <[e-mail]>
To: "[e-mail]" <[e-mail]>, "Harlan Stenn" <[e-mail]>
Cc: <[e-mail]>
Subject: [Ntp]NTS IANA request
Date: Sun, Jun 9, 2019 11:50

Thank you Karen. 

I want to spin thus with there are today three areas of concern. They are 

1) ultra accurate time transfer and the receipt and acknowledgement of that transfer. 

2) use policy controls for time servers and clients 

3) audit mechanisms for proving the integrity after the fact of #1's functionality. 

Not all use models will be totally compatible with #2 and #3 so we need to understand and build templates for each.  

The goal is to build a unified tool suite for as many use constructs and methods as we can, and ones that simplify proving time transfer and tracking accuracy in All (or as many as possible) methods or templates we build.

This is key for other standards to rely on NTP as part if their standards. Take PCIDSS as10.4 for example as just one critical external standard relying on NTP. 

The ideas espoused in limiting specific use models by a few here are actually dangerous to the bigger picture of building secured and reliable time transfer practicess, so in that sense I wanted to thank you for these comments.

//tsg

Sent from my HTC, so please excuse any typos.

----- Reply message -----
From: "[e-mail]" <[e-mail]>
To: "Harlan Stenn" <[e-mail]>
Cc: <[e-mail]>
Subject: [Ntp] NTS IANA request
Date: Fri, Jun 7, 2019 06:23

Harlan,

As we have discussed privately, this type of email response is not helpful.
Please limit your comments on the mailing list to specific technical concerns.

Thank you!
Karen

On 6 Jun 2019, at 17:42, Harlan Stenn wrote:

> As best as I can tell, the following is total rubbish.
>
> H
>
> On 6/6/2019 11:28 AM, Daniel Franke wrote:
>> As a slight tangent, we never concluded the discussion as to what
>> we're going to do about the fact that so many ISPs are dropping
>> 123/udp traffic with payloads larger than 48 bytes. I think we got as
>> far as concluding:
>>
>> 1. We're never going to persuade enough ISPs to change their policy,
>> making 123/udp basically doomed.
>> 2. NTS-KE's port negotiation record gives us all the mechanism we >> need
>> in order to run NTP-with-NTS over an alternate port.
>>
>> But that left an unresolved question: do we allocate a fixed >> alternate
>> UDP port, or should servers ask the OS for a dynamic port and then >> use
>> NTS-KE to advertise whatever the OS assigns to them? Both choices >> have
>> firewall-related drawbacks. If we use a fixed port, we risk landing
>> ourselves right back in the same situation we're in today with 123. >> At
>> minimum, to protect ourselves from this, the NTF would have to commit
>> to adding some code to ntpd such that it will refuse to ever send >> mode
>> 6 or 7 responses over the new port no matter what configuration the
>> user gives it. (Yes, mode 6 too, because mode 6 still amplifies, just
>> not as severely as mode 7 does). If we use a dynamic port, then it
>> becomes much harder for ISPs to block us, but it also becomes harder
>> for corporate firewalls with a default-deny-all policy to let us
>> through.
>>
>> On Thu, Jun 6, 2019 at 1:06 PM Salz, Rich <[e-mail]> wrote:
>>>
>>>>    I'm strongly opposed to modifying NTS-KE to involve sending a >>>> STARTTLS
>>>     as a first step of the handshake. I don't want to make a >>> brea