Re: [Ntp] Wildcards in NTS certificate checking

Paul Gear <ntp@libertysys.com.au> Sun, 17 April 2022 01:42 UTC

Return-Path: <ntp@libertysys.com.au>
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 63B403A15AB for <ntp@ietfa.amsl.com>; Sat, 16 Apr 2022 18:42:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.109
X-Spam-Level:
X-Spam-Status: No, score=-2.109 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=libertysys.com.au
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1-8K2U-6iGtG for <ntp@ietfa.amsl.com>; Sat, 16 Apr 2022 18:42:21 -0700 (PDT)
Received: from mail.libertysys.com.au (2001-44b8-2100-3f00-0000-0000-0000-0019.static.ipv6.internode.on.net [IPv6:2001:44b8:2100:3f00::19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8764B3A15AA for <ntp@ietf.org>; Sat, 16 Apr 2022 18:42:21 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.libertysys.com.au (Postfix) with ESMTP id 264961805A9 for <ntp@ietf.org>; Sun, 17 Apr 2022 11:42:15 +1000 (AEST)
X-Virus-Scanned: Debian amavisd-new at mail2.gear.dyndns.org
Received: from mail.libertysys.com.au ([150.101.186.52]) by localhost (mail.gear.dyndns.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JJjLuGwa1uNc for <ntp@ietf.org>; Sun, 17 Apr 2022 11:42:08 +1000 (AEST)
Received: from [IPV6:2001:44b8:2100:3f40:98a3:b4a2:f254:6dd7] (unknown [IPv6:2001:44b8:2100:3f40:98a3:b4a2:f254:6dd7]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail.libertysys.com.au (Postfix) with ESMTPSA id 4066F18049A for <ntp@ietf.org>; Sun, 17 Apr 2022 11:42:08 +1000 (AEST)
Authentication-Results: mail.libertysys.com.au; dmarc=fail (p=quarantine dis=none) header.from=libertysys.com.au
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=libertysys.com.au; s=2016; t=1650159728; bh=zxZDWf+kqdsKezhPw0ylvamEvCFBAHsx2VbnMnrR1N8=; h=Date:Subject:To:References:From:In-Reply-To:From; b=MXQj2xMKxsKkemPyn0WtxtgcjMeOPDtF7R8DpNnkYkGb9xhWqtijukbx0WKKmHPNB O0ZviP6kyFy84ou/VZC5oRugnVX45htJPscLQAWzrjejig3TRebYfxVIalWQsR1x9E FZz1F5qswDZ3zCel5y3xBG+DB9mZwbHRkETiH6gQ=
Message-ID: <1df0abfa-9afc-c10f-bdb9-b7bcfe8454cb@libertysys.com.au>
Date: Sun, 17 Apr 2022 11:42:07 +1000
MIME-Version: 1.0
Content-Language: en-AU
To: ntp@ietf.org
References: <20220414182255.CEF3828C1CB@107-137-68-211.lightspeed.sntcca.sbcglobal.net> <f7a50921-7c79-f2bb-6d4e-1416b4b86320@sidn.nl>
From: Paul Gear <ntp@libertysys.com.au>
In-Reply-To: <f7a50921-7c79-f2bb-6d4e-1416b4b86320@sidn.nl>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/La_5r0gnmx0LbWKCsSoQgQ61tVc>
Subject: Re: [Ntp] Wildcards in NTS certificate checking
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.29
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: Sun, 17 Apr 2022 01:42:27 -0000

On 15/4/22 17:43, Marco Davids (IETF) wrote:
> ...
>
>> The change you want is a one line edit.
>>
>> What I'm missing is a discussion of the risks/benefits associated with
>> left-wildcards and consensus from the NTS community that we should 
>> support
>> them.
>
> Yes, I agree. Well, I already gave my input, so there's little to add 
> there. But to sum them up:
>
> - wildcards are still common practice, and widely deployed and issued,
> - it's not only about security, but also about interoperability,
> - the default should be to accept them, because the RFC8915 doesn't 
> say otherwise,
> - perhaps make a configuration option in the software that disallows them
>
>> Or something similar from a security group saying the increased risk 
>> from
>> left-wildcards is insignificant so they should be widely accecpted.
>
> But they probably already are ;-) Any Chrony-user will confirm that. 
> Probably other NTS-clients support them too (but I haven't verified 
> that).
>
>> I can't tell if I'm being a nut-case for dragging my feet or a hero for
>> starting a long overdue trend to get rid of wildcards.
>
> Your cause is noble without a doubt. But as a guy with an operational 
> background I learned that noble causes don't always lead to desired 
> results. The last thing we need is that we are frustrating the process 
> of broader NTS deployment.

Hi everyone,

As a member of the NTP pool operator community, I plead with you: DO NOT 
ban the use of wildcards in NTS.  By all means, if you think that they 
are less secure (I think that is very debatable, but here is not the 
place for doing so), then provide your clients with the ability to 
discard associations with servers which use them.  But please do not 
make decisions in the standard which should be local policy decisions.  
Wildcards are a widely-expected feature of TLS implementations, and 
there are common scenarios in which they are the only means to achieve a 
desired configuration.

Regards,
Paul