[Ntp] Antw: Re: Antw: [EXT] Re: Wildcards in NTS certificate checking

Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de> Wed, 20 April 2022 06:55 UTC

Return-Path: <Ulrich.Windl@rz.uni-regensburg.de>
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 34B213A12B5 for <ntp@ietfa.amsl.com>; Tue, 19 Apr 2022 23:55:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level:
X-Spam-Status: No, score=-1.906 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, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
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 syx8pe4zBwVa for <ntp@ietfa.amsl.com>; Tue, 19 Apr 2022 23:55:40 -0700 (PDT)
Received: from mx2.uni-regensburg.de (mx2.uni-regensburg.de [194.94.157.147]) (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 7FD7F3A1162 for <ntp@ietf.org>; Tue, 19 Apr 2022 23:55:40 -0700 (PDT)
Received: from mx2.uni-regensburg.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id C7D06600004E for <ntp@ietf.org>; Wed, 20 Apr 2022 08:55:36 +0200 (CEST)
Received: from gwsmtp.uni-regensburg.de (gwsmtp1.uni-regensburg.de [132.199.5.51]) by mx2.uni-regensburg.de (Postfix) with ESMTP id A7251600004D for <ntp@ietf.org>; Wed, 20 Apr 2022 08:55:33 +0200 (CEST)
Received: from uni-regensburg-smtp1-MTA by gwsmtp.uni-regensburg.de with Novell_GroupWise; Wed, 20 Apr 2022 08:55:33 +0200
Message-Id: <625FAE63020000A100049786@gwsmtp.uni-regensburg.de>
X-Mailer: Novell GroupWise Internet Agent 18.4.0
Date: Wed, 20 Apr 2022 08:55:31 +0200
From: Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de>
To: Daniel Franke <dfoxfranke@gmail.com>, halmurray+ietf@sonic.net
Cc: "ntp@ietf.org" <ntp@ietf.org>
References: <DEBE05CE020000C5FDA5B133@gwsmtp.uni-regensburg.de> <C72B1BFF020000657BE0EBB5@gwsmtp.uni-regensburg.de> <C47F79BB02000008FDA5B133@gwsmtp.uni-regensburg.de> <5865E3950200000D7BE0EBB5@gwsmtp.uni-regensburg.de> <DFB7955F020000B8DC344014@gwsmtp.uni-regensburg.de> <8E9786F3020000E1FDA5B133@gwsmtp.uni-regensburg.de> <625E5A02020000A1000496FA@gwsmtp.uni-regensburg.de> <7F61F6D6020000D6AB59E961@gwsmtp.uni-regensburg.de> <CAF2E1DF02000014FDA5B133@gwsmtp.uni-regensburg.de>
In-Reply-To: <CAF2E1DF02000014FDA5B133@gwsmtp.uni-regensburg.de>
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/BczaKPrSPqHl0doNXK0I4ySE5sI>
Subject: [Ntp] Antw: Re: Antw: [EXT] Re: 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: Wed, 20 Apr 2022 06:55:49 -0000

Hi!

Well actually the whole discussion is more about "clarity" (of specification)
rather than about "security".
Some time ago I was bitten myself by a change in Firefox when it stopped to
use the CN of a host certificate to match the host name (as years before), but
insisted that the hostname is present in subject's alternate name(s).

So maybe make clear what works, and what won't. Maybe add an explanation why
(what the policy decisions had in mind).

As mentioned the mechanism matching the certificates with host names or
addresses is most important (it decides whether wildcards will work or not).

Regards,
Ulrich

>>> Hal Murray <halmurray+ietf@sonic.net> schrieb am 19.04.2022 um 22:32 in
Nachricht
<20220419203203.1FAFC28C1CA@107-137-68-211.lightspeed.sntcca.sbcglobal.net>:

> dfoxfranke@gmail.com said:
>> Absent any specific arrangement with its clients to the contrary, the
server
>> is free to use wildcard certificates and to change certificates at any
time.
>> The client is free to pin certificates or to prohibit wildcards, but,
absent
>> any specific arrangement with the server operator to the contrary, should
>> anticipate that this will lead to sudden breakage that it will be
incumbent
>> on the user to debug. Having this as a default does not make for a good
user
>> experience. 
> 
> Good point.  But what about people who are willing to work a bit for better

> security?  Would they even use NTS, or would they all install a GPS box 
> inside 
> their firewall?
> 
> What is the target audience?  Do we have more than one?
> 
> Should we be collecting ideas for a BCP?
> 
> What are the units of (in)security?  How do we even discuss how much feature

> X 
> adds to security?
> 
> Here is one to think about...  You don't want all of your servers using the

> same CA.
> 
> 
> ‑‑ 
> These are my opinions.  I hate spam.
> 
> 
> 
> _______________________________________________
> ntp mailing list
> ntp@ietf.org 
> https://www.ietf.org/mailman/listinfo/ntp