Subject: Re: [Uta] 6125bis -- security considerations

From: "Salz, Rich" <[email-masked]>
Date: Fri, 1 Oct 2021 14:07:24 +0000

Thanks for your feedback, Ryan and Alexey.  I basically did what you suggested.

I share your concerns about the public suffix list.  Does the WG have any thoughts?  FYI, Ryan wrote this:

  *   I'm a little sad any time there is a new dependency on the public suffix list, even informative :) I realize the point is to say it's out of scope, and alternative language, such as "wildcard that spans multiple domain administration boundaries" is as clear as mud and reads like a mouthful of marbles. My main concern/consideration is that the whole "wildcards and PSL" is messy (all the more reason to keep it out of scope!), although I worry folks will read this and think "Oh, this is a hint to use the PSL, nudge and wink"

Alexey convinced me ALPN is out of scope, it’s more about “how to use TLS in applications” :) not this specific document.

I still would like comments on the last paragraph of the section:

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

Should that go away now?  If so, that will have ripple effects.  Perhaps just add that this MAY be the equivalent of multiple names, could enable cross-protocol attacks, and should be avoided unless necessary?

The revised section is at https://github.com/richsalz/draft-ietf-uta-rfc6125bis/pull/29<https://urldefense.com/v3/__https:/github.com/richsalz/draft-ietf-uta-rfc6125bis/pull/29__;!!GjvTz_vk!HHlppXFTHBLKDYGimeX_L_WlwrRZzdDoVGRUTvmJdFazL5odZ53M_SBLIYdj$>

---

From: Ryan Sleevi <[email-masked]>
Date: Fri, 1 Oct 2021 19:00:42 -0400

On Fri, Oct 1, 2021 at 10:07 AM Salz, Rich <[email-masked]> wrote:

>    - 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.
>
>
>
> Should that go away now?  If so, that will have ripple effects.  Perhaps
> just add that this MAY be the equivalent of multiple names, could enable
> cross-protocol attacks, and should be avoided unless necessary?
>

What sort of ripple effects are you thinking? I agree that, in practice,
the use of multiple names has been normalized beyond the "SNI workaround"
(e.g. the discussions on cross-SNI resumption or the ORIGIN frame), so
removing that text seems acceptable, but I suspect that we'd both be on the
same page of wanting to say _something_ about the risks, such as
cross-protocol attacks. And if we're going to discuss those, would it also
be appropriate to discuss the concerns about accepting multiple different
_types_ of identifiers within a message, and the intersection that can play
with, for example, nameConstraints.

That is, I've seen far too many implementations that will accept (DNS-ID ||
URI-ID) within a TLS endpoint, but will happily ignore that while a DNS-ID
will be constrained by DNS nameConstraints, those same nameConstraints
won't constrain the URI-ID unless URI nameConstraints are included, and
notably... they aren't required to be included in popular PKIs like the Web
PKI.

Happy to suggest text if folks think it's worth tackling during this
revision, although it seems a separate-but-related attack to the
cross-protocol attack.

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 4 Oct 2021 13:29:09 +0000

*   What sort of ripple effects are you thinking?

Purely editorial within the document which talks about one or more DNS-ID/URI-ID in a couple of places.

  *   I agree that, in practice, the use of multiple names has been normalized beyond the "SNI workaround" (e.g. the discussions on cross-SNI resumption or the ORIGIN frame), so removing that text seems acceptable, but I suspect that we'd both be on the same page of wanting to say _something_ about the risks, such as cross-protocol attacks. And if we're going to discuss those, would it also be appropriate to discuss the concerns about accepting multiple different _types_ of identifiers within a message, and the intersection that can play with, for example, nameConstraints.

Yes I think we are.

  *   That is, I've seen far too many implementations that will accept (DNS-ID || URI-ID) within a TLS endpoint, but will happily ignore that while a DNS-ID will be constrained by DNS nameConstraints, those same nameConstraints won't constrain the URI-ID unless URI nameConstraints are included, and notably... they aren't required to be included in popular PKIs like the Web PKI.

I didn’t even realize URI nameConstraints were possible.

  *   Happy to suggest text if folks think it's worth tackling during this revision, although it seems a separate-but-related attack to the cross-protocol attack.

Please do!

---

From: Ryan Sleevi <[email-masked]>
Date: Tue, 5 Oct 2021 11:57:39 -0400

On Mon, Oct 4, 2021 at 9:29 AM Salz, Rich <[email-masked]> wrote:

>
>    - What sort of ripple effects are you thinking?
>
>
>
>    - I agree that, in practice, the use of multiple names has been
>    normalized beyond the "SNI workaround" (e.g. the discussions on cross-SNI
>    resumption or the ORIGIN frame), so removing that text seems acceptable,
>    but I suspect that we'd both be on the same page of wanting to say
>    _something_ about the risks, such as cross-protocol attacks. And if we're
>    going to discuss those, would it also be appropriate to discuss the
>    concerns about accepting multiple different _types_ of identifiers within a
>    message, and the intersection that can play with, for example,
>    nameConstraints.
>
>
>
> Yes I think we are.
>
>
>
>    - That is, I've seen far too many implementations that will accept
>    (DNS-ID || URI-ID) within a TLS endpoint, but will happily ignore that
>    while a DNS-ID will be constrained by DNS nameConstraints, those same
>    nameConstraints won't constrain the URI-ID unless URI nameConstraints are
>    included, and notably... they aren't required to be included in popular
>    PKIs like the Web PKI.
>
>
>
>    - Happy to suggest text if folks think it's worth tackling during this

Done, in
https://github.com/richsalz/draft-ietf-uta-rfc6125bis/pull/29#discussion_r722367686
- although I'm happy to move this to a separate discussion/PR/issue, if
you'd prefer. 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)

The proposed new text is reproduced below (improperly wrapped), again, for
the GitHub averse :)

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.

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 5 Oct 2021 16:14:39 +0000

Thanks for the contribution, Ryan.

I already merged your two smaller changes around SNI and ALPN.  I hope the WG will comment on the larger text you provided, below.
Ryan’s mail.

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)

The proposed new text is reproduced below (improperly wrapped), again, for the GitHub averse :)

same certificate for multiple identifiers. This enables a single certificate

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.

the client requiring that if one form of presented identifier is constrained,

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.