Re: [Uta] 6125bis -- security considerations

[Alexey Melnikov <[e-mail]>]

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 
> <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}}.
>
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
>
> protocols share the same port, the client MUST use the Application-Layer
>
> Protocol Negotiation as described in {{ALPN}}.
>
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.

> 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.
>
>
Best Regards,

Alexey