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) <[email protected]> Date: Wednesday, 30 April 2025 at 09:14 To: Viktor Dukhovni <[email protected]>, opsawg <[email protected]>, [email protected] <[email protected]> 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 <[email protected]> Date: Wednesday, 30 April 2025 at 02:14 To: opsawg <[email protected]>, [email protected] <[email protected]> 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 -- [email protected] To unsubscribe send an email to [email protected]
_______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
