Re: [Ntp] New Version Notification for draft-gruessing-ntp-ntpv5-requirements-03.txt

[Danny Mayer <[e-mail]>]

On 10/15/21 2:05 PM, James wrote:
> Danny,
> It turns out DNS does need confidentiality in addition to 
> authentication, because:
>
> * DNSSEC is not universal, and due to broken implementations and 
> operators who don’t bother implementing it fully not everything is 
> covered by it
> * It turns out there is a significant market for DNS query data as it 
> allows for passive tracking of individual users and systems. Some of 
> this is good (e.g. intrusion detection in corporate networks), but a 
> lot of it is bad (such as ISPs violating customer’s expectations of 
> privacy by reselling their data)
Yes, but that has to do with (mainly) browser requests for IP addresses 
and to keep that information from ISP's and others. It's not really a 
DNS issue per se.
> * AXFR/IXFR related traffic, which if observed in flight could expose 
> inner details of multi-horizon or “hidden master” deployment patterns, 
> or in insecure deployments cause hijacking of zones or records. RFC 
> 9103 addresses some of these risks by using DNS over TLS.
AXFR/IXFR doesn't use DOH and can definitely be encrypted or use TLS 
encapsulation.
>
> DNS information may be public, but one can’t know the data unless they 
> know what they are looking for. The TLDR Project[1] was a good example 
> of this, and it uncovered details on the DPRK’s public DNS[2] which 
> was previously not fully known. DNSSEC allowing for enumeration of 
> zones was never seen as a neutral or good feature, it is seen as a 
> security issue, which is where NSEC3 came about.
There's also a NSEC5 proposal though that went nowhere.
>
> Back to the topic of NTP, I could elaborate further on the threat 
> model in my draft to cover scenarios where confidentiality may be a 
> useful mitigation. However, as has been mentioned by Rich and others 
> in the past the overall trend for internet-facing protocols (which I 
> assume NTPv5 would be) is to provide confidentiality even if optional, 
> in part because of all the details RFC 7624 describes, amongst other 
> guidance we’ve received from the IESG and other reviews for protocols 
> of recent times.
>
> Perhaps you can elaborate why you think confidentiality in NTP is a 
> bad idea?
I want to know why confidentiality is a good idea. The complication of 
encrypting an NTP packet adds to the uncertainty of the departure of the 
packet, prevents hardware timestamping and a myriad of other measurement 
issues. The timestamps are not confidential and are only of momentary 
value. What are you trying to hide? When concentrating on the packet 
please identify what parts of the packet should not be exposed since the 
timestamps surely cannot be. If I'm wrong please tell me why I'm wrong 
and provide example use cases to support your theory. I see nothing in 
RFC7624 to indicate an area of concern where NTP is involved.

Danny