Subject: [Uta] 6125bis -- security considerations

From: "Salz, Rich" <[email-masked]>
Date: Tue, 28 Sep 2021 14:20:19 +0000

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.

---

From: Ryan Sleevi <[email-masked]>
Date: Tue, 28 Sep 2021 11:41:09 -0400

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=
[email-masked]> 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
>
>
>
>
>
> _______________________________________________
> Uta mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uta
>

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 28 Sep 2021 16:51:45 +0000

Your suggestions make sense to me.  Let’s see if anyone disagrees.  Thanks for reading!  I agree about the PSL and spreading it around. Maybe just drop the reference?  But then, I understood what you wrote about crossing the beams, er administrative domains.

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 28 Sep 2021 18:05:53 +0100

Hi Rich,

On 28/09/2021 15:20, Salz, Rich 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>
>
> (SNI) extension as discussed in {{TLS, Section 4.4.2.2}}.
>
I don't think this MUST is appropriate, as this is not universally 
required by different protocols. I would rather rephrase this as a good 
way of addressing this issue.
> If multiple
The last sentence: the client might have no idea, this is not 
necessarily something common or known to the client. At least not common 
outside of Web.

To rephrase this, I think this MUST requirement is outside of scope of 
this document.

> SRV-IDs, or URI-IDs in a certificate.
Best Regards,

Alexey