I think that the text on presented identifiers needs work.
There are a few different things at play here:
The identities we use are not always as specific as the identity used in
application protocols. On the web, we use origins, which is scheme+host+port,
but the reference identity that we use for authentication only covers the host
portion of that tuple. Most notably here, different origins on different
ports, cannot be distinguished in authentication. For that you need
application-layer constructs, like HTTP's Host header field.
Authenticating the host portion doesn't tell you anything about the protocol
that was chosen (c.f., ALPACA). For that you need to use ALPN.
The one credential (i.e., a certificate) can present multiple identities. This
is, I think what you are trying to address here.
>From this, I think that you want to up-level this text and talk about what is
>authenticated and what that means for application protocols that use this
>authentication. There are cross-protocol attacks. Attacks that exploit
>ambiguity of identity. Attacks that exploit ambiguity about the type of
>identity. And they all derive from the same non-specificity in the
>authentication layer.
That non-specific authentication means that - in general - you need to have
application-layer signals about what identity is in play. You don't address
that at all. ALPN is a special case in that we've hoisted that into the TLS
layer.
SNI is another thing that is available at the TLS layer, but we've seen in the
case of HTTP that this is not something that has the same characteristics as
ALPN in negotiating/selecting a single value. It will depend on the protocol,
but in HTTP we don't rely on SNI to identify which identity is intended, that's
the purpose of a Host header field. The text here is a little vague about the
SNI thing, but I would think that you need a stronger statement regarding
clients that don't support SNI - if the protocol relies on SNI to bind the
connection to a single identity. If a protocol relies on SNI to select an
identity AND some clients don't provide SNI THEN in order to support those
clients you then need to have only that identity in the certificate. That is,
the certificate needs to select the identity instead. We've seen people deploy
servers on unique IP addresses in order to support clients that don't provide
SNI, but that is not a good idea if the protocol relies on SNI to select an
identity.
Your recommendations about TLS versions and ciphersuites might be misleading.
Yes, a consistent configuration across servers is a good thing, but it's not
TLS configuration that matters here. It's general operational security. The
only way in which it relates to this general problem is that - in the event of
compromise - the weakest server in the set is the one that matters. That it's
an LDAP server doesn't matter, because compromising it also affects the mail
server due to their credentials being fungible. In this setting, TLS
configuration only matters to the extent that full server impersonation is
enabled via that configuration. That's possible, as we've seen, but there are
far more ways to achieve that. RCE for instance.
The ALPN recommendation could be strengthened. A lot. I would prefer a
construct that used "MUST" conditioned on an "unless the protocol does not
support it" and maybe "in which case the identities for which the server is
used are not used for any other protocol without ALPN support" or similar
conditions.
On Wed, Nov 17, 2021, at 07:14, Salz, Rich wrote:
> Ryan Sleevi has proposed adding the text below to the security
> considerations section. I’ve posted about this before and had
> miniscule feedback. Barring strong objections, I intend to merge this
> near the end of the week and publish a new draft containing this and
> the name-change.
>
> ## Multiple Presented 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. TLS Extensions such as TLS Server Name Identification
> (SNI), discussed in {{TLS, Section 4.4.2.2}}, and Application Layer Protocol
> Negotiation (ALPN), discussed in {{ALPN}}, provide a way for the application
> to indicate the desired identifier and protocol to the server, which it
> can then used to select the most appropriate certificate.
>
> This specification allows multiple DNS-IDs, SRV-IDs, or URI-IDs in a
> certificate. As a result, an application service can use the same
> certificate for multiple hostnames, such as when a client does not
> support
> the TLS SNI extension, or for multiple protocols, such as SMTP and
> HTTP, on a
> single hostname. The use of a single certificate and its keypair in such
> environments can make it easier to launch cross-protocol attacks,
> particularly when used in
> differing TLS configurations; see, for example, {{ALPACA}} and
> {{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 use the
> TLS
> ALPN extension to ensure the correct protocol is used.
_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
