Re: [Uta] 6125bis -- multiple identifiers (was security considerations)

["Salz, Rich" <[e-mail]>]

  *   It started off with this discussion, but clearly, it's a much broader change. It does try and reintroduce the ALPN conversation, although with a looser 2119 fit, and trying to explain the "why" of the SHOULD, in a way directly relevant to this specification, in a way that is hopefully acceptable to mitigating the concerns previously raised.


  *   I'm specifically proposing splitting up "Multiple Identifiers" into two discussions - "Multiple Presented Identifiers" (multiple names in certs, and concerns for server operators) and "Multiple Reference Identifiers" (multiple acceptable names to match, and concerns for client implementations)

I really like your proposal. I split it off into its own pull request, https://github.com/richsalz/draft-ietf-uta-rfc6125bis/pull/33.  Again for this not comfortable with GitHub, here’s the new text, followed by Ryan’s comments on it.

This specification allows multiple DNS-IDs, SRV-IDs, or URI-IDs in a
certificate, which allows for a single application service to use the
same certificate for multiple identifiers. This enables a single certificate
to be used across multiple hostnames, such as when a client does not
support the TLS SNI extension, or across multiple protocols, such as
SMTP and HTTP, on a single hostname. The use of a single certificate
and public/private keypair in such environments MAY facilitate
cross-protocol attacks, particularly when used in differing TLS
configurations. See, for example, {{ALPACA}}, {{DROWN}}. Server
operators SHOULD take steps to mitigate the risk of cross-protocol
attacks, such as ensuring all TLS endpoints using a given certificate
support exactly the same TLS version(s) and ciphersuite(s), and
SHOULD make use of the TLS ALPN extension to ensure the correct
protocol is used.

## Multiple Reference Identifiers

This specification describes how a client may construct multiple
acceptable reference identifiers, and may match any of those reference
identifiers with the set of presented identifiers. {{PKIX, Section 4.2.1.10}}
describes a mechanism to allow CA certificates to be constrained in the
set of presented identifiers that they may include within server certificates.
However, these constraints only apply to the explicitly enumerated name
forms. For example, a CA that is only name constrained for DNS-IDs is not
constrained for SRV-IDs and URI-IDs, unless those name forms are also
explicitly included within the name constraints extension.

A client that constructs multiple reference identifiers of different types,
such as both DNS-ID and SRV-IDs, as described in
{#verify-reference-rules}, SHOULD take care to ensure that CAs issuing
such certificates are appropriately constrained. This MAY take the form of
local policy through agreement with the issuing CA, or MAY be enforced by
the client requiring that if one form of presented identifier is constrained,
such as a dNSName name constraint for DNS-IDs, then all other forms of
acceptable reference identities are also constrained, such as requiring a
uniformResourceIndicator name constraint for URI-IDs.


  *   I understand this latter text may have some degree of controversy attached; one of the intended aspects of flexibility with nameConstraints was precisely that it allows new name forms to be introduced in the future, without requiring the reissuance of certificates. I've tried to balance that with the client behaviour, namely, that a client shouldn't construct a given reference identifier / allow a match for a given reference identifier unless it's constrained, _if_ it accepts other forms of constrained reference identifiers.


  *   The canonical example here of the challenge is something like introducing support for SRV-IDs within browser clients, which would be a huge boon to reducing the risk of cross-protocol issues like ALPACA. However, clients cannot (safely) do this as long as there exist servers that are only constrained for dNSNames, without corresponding SRVName constraints. This tries to balance that, by suggesting the client should, when presented with such a constrained chain, only allow DNS-ID reference identifiers to match (because the indication that "some" constraint was intended). Reissuance of that intermediate, to also constrain SRVName, would provide the explicit signal to the client that it's acceptable (or not) to use SRV-ID reference identifiers.


  *   This does not holistically integrate it (e.g. by adding a cross-reference to #verify-reference-rules to the security considerations), but is meant to see if there is objection/concern with this approach.