On Mon, Oct 4, 2021 at 9:29 AM Salz, Rich <rs...@akamai.com> wrote: > > - 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! >
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.
_______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
