IETF Logo Mail Archive

[Ntp] Wildcards in NTS certificate checking

Hal Murray <halmurray+ietf@sonic.net> Wed, 13 April 2022 06:10 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 1E05D3A193B for <ntp@ietfa.amsl.com>; Tue, 12 Apr 2022 23:10:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.907
X-Spam-Level:
X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=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 tadBT1D7JHmD for <ntp@ietfa.amsl.com>; Tue, 12 Apr 2022 23:10:25 -0700 (PDT)
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 7F1413A1939 for <ntp@ietf.org>; Tue, 12 Apr 2022 23:10:25 -0700 (PDT)
Received: from 107-137-68-211.lightspeed.sntcca.sbcglobal.net (107-137-68-211.lightspeed.sntcca.sbcglobal.net [107.137.68.211]) (authenticated bits=0) by c.mail.sonic.net (8.16.1/8.16.1) with ESMTPSA id 23D6ANfs015455 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Tue, 12 Apr 2022 23:10:23 -0700
Received: from hgm (localhost [IPv6:::1]) by 107-137-68-211.lightspeed.sntcca.sbcglobal.net (Postfix) with ESMTP id 6F4A628C1B9; Tue, 12 Apr 2022 23:10:23 -0700 (PDT)
X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.7.1
To: ntp@ietf.org
cc: Hal Murray <halmurray+ietf@sonic.net>
From: Hal Murray <halmurray+ietf@sonic.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 12 Apr 2022 23:10:23 -0700
Message-Id: <20220413061023.6F4A628C1B9@107-137-68-211.lightspeed.sntcca.sbcglobal.net>
X-Sonic-CAuth: UmFuZG9tSVbPOutu51vBudUTYb3LNdme8i6oVHz140c2RpqyQuZysOi4hLaNV+JDO2+cKPYpyiwO8KYAvjMHhWm5m26FGDlH2rDzAyDtkPw=
X-Sonic-ID: C;3vO4Z/C67BG6lasBQWJIoQ== M;/NLoZ/C67BG6lasBQWJIoQ==
X-Sonic-Spam-Details: -1.5/5.0 by cerberusd
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/YaadZwIAF_R3yoo0oFGIPKnyavs>
Subject: [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: Wed, 13 Apr 2022 06:10:30 -0000

Wildcards are deprecated by RFC 6125

https://datatracker.ietf.org/doc/draft-ietf-uta-rfc6125bis/
says:

   *  The only legal place for a certificate wildcard name is as the
      left-most component in a domain name.

   A technology MAY disallow the use of the wildcard character in DNS
   names.  If it does so, then the specification MUST state that
   wildcard certificates as defined in this document are not supported.

----------

RFC 8915 doesn't say anything about wildcards.  I don't remember any 
discussion and I didn't find any with a quick search.

If we were still working on the NTS specs, what, if anything, would we say 
about wildcards?

Is the security risk of a leftmost wildcard low enough that we should jump on 
the bandwagon?  (Is there a bandwagon?)

Are SANs (Server Alternate Names) a better alternative?


-- 
These are my opinions.  I hate spam.

v2.23.0 | Report a Bug | By Email