This is the text intended for the security section
5.1.6. Server Identity Wildcards
The use of wildcards in TLS server identities creates a single point
of failure: a compromised private key of a wildcard certificate
impacts all servers using it. Their use MUST follow recommendations
of Section 7.1 of [RFC9525]. Operators MUST ensure that the wildcard
is limited to a subdomain dedicated solely to TLS TACACS+ servers.
Further, operators MUST ensure that the TLS TACACS+ servers covered
by a wildcard certificate MUST be impervious to redirection of
traffic to a different server (for example, due to man-in-the-middle attacks or
DNS cache poisoning.)
From: Douglas Gash (dcmgash) <dcmgash@xxxxxxxxx>
Date: Wednesday, 30 April 2025 at 09:14
To: Viktor Dukhovni <ietf-dane@xxxxxxxxxxxx>, opsawg <opsawg@xxxxxxxx>, last-call@xxxxxxxx <last-call@xxxxxxxx>
Subject: Re: [Last-Call] Re: Change to draft-ietf-opsawg-tacacs-tls13
Thanks all for the feedback.
Viktor, we will ensure that the implications you raise regarding the use of wildcards are highlighted in the security section. We’ll share that snippet before uploading the next
version.
From: Viktor Dukhovni <ietf-dane@xxxxxxxxxxxx>
Date: Wednesday, 30 April 2025 at 02:14
To: opsawg <opsawg@xxxxxxxx>, last-call@xxxxxxxx <last-call@xxxxxxxx>
Subject: [Last-Call] Re: Change to draft-ietf-opsawg-tacacs-tls13
On Tue, Apr 29, 2025 at 06:15:35PM +0000, Salz, Rich wrote:
> And yet, they're still best avoided, unless there a good reason to
> support them. The security story with wildcards is all bad news,
>
> Shrug. It’s trade-offs, like most things in the security area. I
> assume that the WG decided they’re worth doing, according to an IETF
> consensus standards-track RFC. You disagree; that’s fine.
My comment was actually about the security considerations being
incomplete, and secondly that *if* wildcard support (originally
excluded) is to be added at this late point in the process, then
along with some more detail in the security considerations, there
could be a phrase discouraging their use, i.e. some approximation
of "best avoided".
--
Viktor.
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
