Subject: [Uta] 6125bis: multiple identifiers

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

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.

## 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.

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 16 Nov 2021 16:38:51 -0500

FWIW, I found nothing in that text to object to...

> On 16 Nov 2021, at 3:14 pm, Salz, Rich <rsalz=[email-masked]> wrote:
> 

-- 
	Viktor.

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 17 Nov 2021 11:17:51 +1100

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.
>

---

From: Ryan Sleevi <[email-masked]>
Date: Wed, 17 Nov 2021 00:10:18 -0500

On Tue, Nov 16, 2021 at 7:18 PM Martin Thomson <[email-masked]> wrote:

> 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.

Not necessarily; see below.

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.

Or SRV-IDs, which Mozilla was previously very positive about supporting
(e.g. the addition restrictions in Mozilla policy regarding SRVNames)

In the context of the document text, this seems to be accurate, right? That
is, you’re rightfully highlighting that DNS-IDs alone aren’t sufficient to
mitigate against ALPACA, but either SRV-IDs or ALPN provide a greater
degree of protection.

Of course, you still have issues with wildcards, which are equally a notion
of multiple identities.

>
> 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.

I think I would disagree with this claim. Application-layer signals are one
way to solve this problem, but they are not a necessary condition.

>
> 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.

I don’t think this conclusion is entirely obvious; namely, the claim that
you need _only_ that identity.

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.

Yes, it is though. Just as we saw issues with TLS1.3 and QUIC, or POODLE,
TLS versions (and configurations) are best thought of as different
protocols that facilitate cross-protocol attacks.

What you describe below is separate, and useful, but seems to dismiss one
problem while mentioning a somewhat separate problem.

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.

This is a separate discussion, I think? That’s not to say it’s not useful,
but talking about operational security seems to be trying to drive more
specific guidance from what was intentionally meant as fairly generic. It
appears that you may be thinking it reads the opposite though - that the
current text is somehow too specific to a generic problem.

Do you have specific text to propose? That might help address the
disconnect here.

>
> 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.

See the past list discussion that raised concerns about that proposed
change, which this language was trying to address.

> _______________________________________________
> Uta mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uta
>

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 17 Nov 2021 17:59:11 +1100

On Wed, Nov 17, 2021, at 16:10, Ryan Sleevi wrote:
> I think I would disagree with this claim. Application-layer signals are 
> one way to solve this problem, but they are not a necessary condition.

Sure.  I was maybe imprecise in writing this up; this is a statement I agree with.  I'm more concerned about the absence of any signal (or rather agreement) and how that might arise.

>> 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. 
>
> Yes, it is though. Just as we saw issues with TLS1.3 and QUIC, or 
> POODLE, TLS versions (and configurations) are best thought of as 
> different protocols that facilitate cross-protocol attacks.

I was assuming that the advice here as given.  If TLS 1.2 breaks or a cipher breaks, then I guess that maybe a consistent configuration might help, but if the consistent configuration means that every node in the group is vulnerable, then nothing is gained.

> change, which this language was trying to address.

Yeah, I don't think that a "SHOULD" is a good resolution to that discussion.