On Tue, Nov 16, 2021 at 7:18 PM Martin Thomson <m...@lowentropy.net> wrote:
> 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.
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.
>
> 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
>
_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
