Re: [Ntp] [EXT] Re: NTPv5 KISS code support

Hal Murray <halmurray+ietf@sonic.net> Wed, 22 November 2023 03:39 UTC

Return-Path: <halmurray+ietf@sonic.net>
X-Original-To: ntp@ietfa.amsl.com
Delivered-To: ntp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D7D9C14CF13 for <ntp@ietfa.amsl.com>; Tue, 21 Nov 2023 19:39:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9V0AM74GFeR2 for <ntp@ietfa.amsl.com>; Tue, 21 Nov 2023 19:39:28 -0800 (PST)
Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E143AC14CEFF for <ntp@ietf.org>; Tue, 21 Nov 2023 19:39:23 -0800 (PST)
Received: from 107-137-68-211.lightspeed.sntcca.sbcglobal.net (104-182-38-69.lightspeed.sntcca.sbcglobal.net [104.182.38.69]) (authenticated bits=0) by c.mail.sonic.net (8.16.1/8.16.1) with ESMTPSA id 3AM3dLl9023824 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Tue, 21 Nov 2023 19:39:22 -0800
Received: from hgm (localhost [IPv6:::1]) by 107-137-68-211.lightspeed.sntcca.sbcglobal.net (Postfix) with ESMTP id D637B28C20C; Tue, 21 Nov 2023 19:39:21 -0800 (PST)
X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.8
To: NTP WG <ntp@ietf.org>
cc: Hal Murray <halmurray+ietf@sonic.net>
From: Hal Murray <halmurray+ietf@sonic.net>
In-Reply-To: Message from Danny Mayer <mayer@pdmconsulting.net> of "Tue, 21 Nov 2023 12:02:50 -0500." <4578e013-121c-42cb-b044-3d2e0746efea@pdmconsulting.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 21 Nov 2023 19:39:21 -0800
Message-Id: <20231122033921.D637B28C20C@107-137-68-211.lightspeed.sntcca.sbcglobal.net>
X-Sonic-CAuth: UmFuZG9tSVaUe7x2n9NJzPr7jgzi333xsrCk58/98VTjUczoCA9Lctxoku/Q4E3NY3S7BXOw/mqvLJ8lPveieF407zAS+Sys5COj6eH+ySc=
X-Sonic-ID: C;VkxvueiI7hGKLS5nR+6Zsg== M;lHGEueiI7hGKLS5nR+6Zsg==
X-Sonic-Spam-Details: -1.5/5.0 by cerberusd
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/aDGKnkA3ds_wgEFPwL0euitvmYQ>
Subject: Re: [Ntp] [EXT] Re: NTPv5 KISS code support
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Network Time Protocol <ntp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ntp>, <mailto:ntp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ntp/>
List-Post: <mailto:ntp@ietf.org>
List-Help: <mailto:ntp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ntp>, <mailto:ntp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Nov 2023 03:39:33 -0000

Me:
> In the Cryptographic failure case, it might be reasonable to send back a
> non-authenticated message saying why the crypto didn't work.  The catch is
> that the receiver would have to not take any action since it might be forged,
> but it could be logged for debugging.

Danny Mayer said:
> Absolutely not. Providing any information at all gives an attacker insights
> as to what they did wrong. 

Salz, Rich said:
> In general, you want to avoid giving any details about what went wrong if the
> cryptography fails, because that is information that an attacker can use. 

Miroslav Lichvar said:
> Hm, I forgot about this one. I agree it's nice to be able to restart NTS-KE
> quickly instead of waiting for 8 or how many missing responses when the
> client's key is no longer valid. 

RFC 8915 says:
> If the server is unable to validate the cookie or authenticate the request,
> it SHOULD respond with a Kiss-o'-Death (KoD) packet (see Section 7.4 of RFC
> 5905 [RFC5905]) with kiss code "NTSN", meaning "NTS NAK" (NTS
> negative-acknowledgment). It MUST NOT include any NTS Cookie or NTS
> Authenticator and Encrypted Extension Fields extension fields.

This seems like an interesting topic.  I don't care what the answer is.

Should we set a good example for security by not returning ANYTHING when the 
NTS crypto doesn't work?  This would require patching RFC 8915.  There is no 
mention of KoD in the security consideration section of 8915.  There is text 
in the body about checking the UID in unauthenticated packets.

Is there a tradeoff between helping the good guys and helping the bad guys?

I'd be happy if we dropped KoD totally.  It will simplify documenation (and 
code) and avoid discussions like this one.  KoDs can be forged, so any 
discussion has to consider DoS-ing and that gets complicated.

Does anybody have any data on KoDs?  Do they do any good?  I'd expect that 
most of the software that receives them won't know how to process them.


-- 
These are my opinions.  I hate spam.