Re: [Uta] 6125bis -- security considerations

Hey Rich,

I left a comment on GitHub with respect to the question about
"confusables". I'm not sold that the suggestion I made is the best, but I'm
mostly trying to see about aligning terminology to the modern reference and
save a few indirection clicks (from IDNA-DEFS to UTS36 to UTS39).

I'm a little sad any time there is a new dependency on the public suffix
list, even informative :) I realize the point is to say it's out of scope,
and alternative language, such as "wildcard that spans multiple domain
administration boundaries" is as clear as mud and reads like a mouthful of
marbles. My main concern/consideration is that the whole "wildcards and
PSL" is messy (all the more reason to keep it out of scope!), although I
worry folks will read this and think "Oh, this is a hint to use the PSL,
nudge and wink"

With respect to the ALPN dependency, I believe that's meant to be a
normative dependency now, due to the MUST level requirement being
introduced, correct? RFC 7301 is presently listed as an informative
dependency. That said, the MUST here is now an imposition on the client,
rather than the protocol spec, and that seems to create new challenges for
existing protocols. I left a further suggestion on GitHub for a possible
edit, to clarify that the client MUST use ALPN _if_ a protocol ID is
registered. That handles the legacy colocation problem, and reflects the
growing consensus that new protocols should register such an identifier
over TLS. It's just a thought, though, and may not be the best fit.

On Tue, Sep 28, 2021 at 10:20 AM Salz, Rich <rsalz=
40akamai.com@dmarc.ietf.org> wrote:

> I am proposing the following for the security section.  Any comments?  In
> particular, what about the “multiple identifiers” at the last few lines?
> Should that go away now?  If so, that will have ripple effects.  This text
> is currently at
> https://github.com/richsalz/draft-ietf-uta-rfc6125bis/pull/29
>
>
>
>
>
> # Security Considerations {#security}
>
>
>
> ## Wildcard Certificates {#security-wildcards}
>
>
>
> Wildcard certificates, those that have an identifier with "\*" as the
>
> left-most DNS label, automatically vouch for any single-label host names
>
> within their domain, but not multiple levels of domains.  This can be
>
> convenient for administrators but also poses the risk of vouching for rogue
>
> or buggy hosts. See for example {{Defeating-SSL}} (beginning at slide 91)
> and
>
> {{HTTPSbytes}} (slides 38-40).
>
>
>
> Protection against a wildcard that identifies a public suffix
>
> {{Public-Suffix}}, such as `*.co.uk` or `*.com`, is beyond the scope of
> this
>
> document.
>
>
>
> ## Internationalized Domain Names {#security-idn}
>
>
>
> Allowing internationalized domain names can lead to the inclusion of
> visually
>
> similar, or confusable, characters in certificates.  For discussion, see
> for
>
> example {{IDNA-DEFS}}.
>
>
>
> ## Multiple Identifiers {#security-multi}
>
>
>
> A given application service might be addressed by multiple DNS domain names
>
> for a variety of reasons, and a given deployment might service multiple
>
> domains or protocols.  The client MUST use the TLS Server Name
> Identification
>
> (SNI) extension as discussed in {{TLS, Section 4.4.2.2}}.  If multiple
>
> protocols share the same port, the client MUST use the Application-Layer
>
> Protocol Negotiation as described in {{ALPN}}.
>
>
>
> To accommodate the workaround that was needed before the development
>
> of the SNI extension, this specification allows multiple DNS-IDs,
>
> SRV-IDs, or URI-IDs in a certificate.
>
>
> _______________________________________________
> Uta mailing list
> Uta@ietf.org
> https://www.ietf.org/mailman/listinfo/uta
>