Re: [Ntp] [EXT] Consensus call: NTPv5 and supported modes

Just a quick comment on this mail: I don't really understand what you're 
getting at with the comment - but if you think that Jason Anderson's work 
has anything much to do with NTP broadcast, I think you misunderstood.
It is about other broadcast procedures (mainly GNSS) using the TESLA 
protocol (which requires rough sync as a prerequisite for authenticity), 
and potentially being extra vulnerable by NTP implementations "tattling" 
on an entity's bad sync state via the included timestamps.

Jason, please feel free to correct me if I'm misrepresenting anything.

Besten Gruß / Kind regards,
Kristof Teichel

__________________________________________

Dr.-Ing. Kurt Kristof Teichel
Physikalisch-Technische Bundesanstalt (PTB) 
Arbeitsgruppe 4.42 "Zeitübertragung"
Bundesallee 100
38116 Braunschweig (Germany)
Tel.:        +49 (531) 592-4471
E-Mail:   kristof.teichel@ptb.de
__________________________________________

Von:    "Danny Mayer" <mayer@pdmconsulting.net>
An:     ntp@ietf.org
Datum:  02.07.2023 17:43
Betreff:        Re: [Ntp] [EXT] Consensus call: NTPv5 and supported modes
Gesendet von:   "ntp" <ntp-bounces@ietf.org>

On 6/30/23 5:05 AM, David Venhoek wrote:
> I am of the opinion that we should not include the modes 1, 2 and 5,
> based on the following arguments (in order of importance):
There are a lot of assumptions made here which are probably not valid.
>   - They are known to be vulnerable (about 50% of all ntp reference
> implementation vulnerabilities over the past years came from these
> modes alone, and I for one am not convinced that they are in any way
> securely usable today).

What evidence to you have of this and which modes do you think that they 
apply to? Certainly modes 1 and 2 are able to use the same security as 
modes 3 and 4.

There are ways of dealing with mode 5 (broadcast and multicast) and I 
seem to remember that autokey works for that. Yes, I know that autokey 
is vunerable but it means that there are ways to deal with it.

>   - There seems to be limited interest in working towards fixes for
> their vulnerability, and I have not seen concrete ideas as to how.
I don't know what that means. See above.
>   - The use cases for these modes have reasonable alternatives
> available today: dhcp can distribute the address of an ntp server as
> replacement for mode 5, and mutual client-server connections can be
> used in the same situations as modes 1/2 (if needed with configuration
> settings in the implementation for special algorithmic treatment).
That not a substitute for multicast and cannot handle changes in servers 
sending multicast packets. Furthermore many servers have fixed IP 
addresses and do not use dhcp.
>   - Removing them would significantly simplify both the NTPv5 standard
> and the process of creating it.
Simplication of a standard is not a goal merely because it's easier.
>   - They are already not supported in 2 of the 4 major implementations
> (ntpsec, ntpd-rs), and only partially in a 3rd (chrony).
That's irrelevant since it ignores the many systems that use it today.
>
> I would prefer we mark them as obsolete/deprecated or something like
> that, as I don't see a realistic path to getting them to the point
> where the security concerns are going to be allayed, but am willing to
> leave them open as potential future extensions to NTPv5.
No. The NTP reference implementation will continue to support them and 
it is straightforward to implement NTS for modes 1 and 2. Mode 5 will 
probably need additional work. I need to remind everyone of Jason 
Anderson's work on needing Broadcast mode (though I would change this to 
Multicast since Broadcast is not available in IPv6).
> On the idea that this might inhibit adoption, I am not convinced of
> that. Based on contacts I have had through the ntpd-rs project with
> users, these modes are not among the missing features people seem
> interested in. I know there have been claims that this is absolutely
> critical for some users, but we have not seen anything concrete as to
> for whom and why, and I am therefore not inclined to take those claims
> seriously.
>
> Kind regards,
> David Venhoek
>
> On Thu, Jun 29, 2023 at 3:13?PM Windl, Ulrich <u.windl@ukr.de> wrote:
>> Hi!
>>
>> On " Should NTPv5 additionally support also the modes 1, 2 and 5 known 
from NTPv4?": If not, what should the document say about those? Obsolete? 
An extension?
>> IMHO being too restrictive may delay adoption or acceptance of NTPv5 
after it is available.
>>
>> Kind regards,
>> Ulrich Windl
>>
>>
>> -----Original Message-----
>> From: ntp <ntp-bounces@ietf.org> On Behalf Of Dieter Sibold
>> Sent: Wednesday, June 28, 2023 9:53 PM
>> To: NTP WG <ntp@ietf.org>
>> Subject: [EXT] [Ntp] Consensus call: NTPv5 and supported modes
>>
>> Dear all,
>>
>> at IETF 116 we decided to have two consensus calls regarding the 
content of the NTPv5 requirement draft. These are consensus calls that we 
would like to conduct to help progress the NTPv5 requirements document (
https://datatracker.ietf.org/doc/draft-ietf-ntp-ntpv5-requirements/). Both 
consensus calls will run until July 21st 2023 and will be discussed at the 
next NTP wg meeting at IETF 117 in San Francisco.
>>
>> The first consensus call (the second comes in a follow up mail):
>>
>> Regarding supported modes:
>>
>> Currently, the NTPv5 requirement draft considers a client-server 
communication mode only. Should NTPv5 additionally support also the modes 
1, 2 and 5 known from NTPv4?
>>
>>
>> Greetings
>> Karen and Dieter
>>
>>
>> _______________________________________________
>> 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

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