Re: [lamps] New drafts available - non-composite hybrid authentication, and binding certs

[Ryan Sleevi <[e-mail]>]

On Tue, Mar 29, 2022 at 3:12 PM [e-mail] <[e-mail]>
wrote:

>
> The extension does not include another certificate by reference, it is a
> hint that the RA took care to determine that the private key for Cert B is
> under the control of the same entity as the private key for Cert A. One
> cert's validity is not dependent on any attributes or assertions from any
> other certificate.
>

I think we may be talking past each other, but I would love to try to
resolve this. I very well could be misunderstanding some fundamentals, so
apologies ahead of time for the length, as I try to explain my thought
process and concerns with the approaches.

I don’t think this answer makes sense, at least not when we’re discussing
the “separate PKI (policies)” case, and I’m not sure it’s necessary when
we’re talking about the same PKI (policies).

If we’re talking “same PKI”, then a relying party should be able to be
confident that if the practices for naming and validating an entity are the
same, then two certificates bearing the same name are the same entity.
Something terrible has to go wrong at the CA policy authoring for this to
not hold, such that the same identity asserted in two certificates can
refer to different logical entities. Where this happens (e.g. the "old"
entity operating foo.example and the "new" entity), we have revocation and
expiration to resolve that conflict. In a PQ world in which we assume A and
B use differently capable certificates - say, one classic encryption, one
PQ, or of different PQ algorithms - then as long as the signature scheme is
not defeated, it should hold that if both certificates assert the same
identity, from the same policy authority, they should be the same entity.

If the signature scheme is defeated, then binding doesn’t help any, as the
attacker presumably can impersonate the bound certificate. For example, if
we used SHA-256 and MD5, if the SHA-256 cert bound to MD5, and MD5 was
compromised (as it was), then the attacker can issue a cert that claims to
be that same IssuerAndSN (or hash), but will belong to a different entity.

I realize you’re discussing the use in an online protocol, but this
introduces a host of security considerations. Let’s assume a client fully
validates both certificates - at some point, it will need to extract the
identity information from the certificate, whether DNS or some other
identity. If the attacker can (temporarily) access the SHA-256 cert’s
private key, whether through a relay attack or because the attacker is the
keyholder themselves, then the flow is that they would generate a malicious
MD5 certificate asserting a different identity. The relying party would
check both certificates and proofs of key possession, and further, see the
binding (presumably, in the SHA-256 cert) asserting that any holder of the
matching MD5 cert is the same identity. If the client/relying party
extracts the identity from the MD5 certificate, rather than the SHA-256
cert, then the attacker can pivot and assert any identity they want, and
the SHA-256 cert is pointless.

To mitigate this, you end up needing to have the RP fully check identity on
both certificates. But once you’ve done that, in a “same PKI (policies)”
case, hasn’t that implicitly signaled that both certificates are operated
by the same entity? It’s only if one cert has a different level of
assurance than another that it becomes less clear, but isn’t the level of
assurance inherently either part of the identity expression _or_ something
you can already signal (e.g. by CP OIDs)? The only place where this
extension would make sense, in the same PKI case, would be if the same
identity can refer to multiple entities, and that seems flawed for reasons
orthogonal to this.

I’m not sure how clear that argument is, but hopefully it captures a bit
why “different certs, same policies” means this signal is unnecessary. I
realize this isn't strictly your use case, but it's relevant to some of the
other industry conversations occurring in other SDOs, and it seems
important to highlight how this approach doesn't solve that problem.

That leaves us with two other scenarios worth considering, and I think more
closer to your particular use case:

1) Different PKIs, same naming of entities
2) Different PKIs, different naming of entities

With 1, even if the two certificates bear the same identity, the presumed
semantics and policies will be different, so the relying party expects the
same identity is not necessarily the same entity. But how, in practice, is
CA B (SHA-256) going to verify the identity expressed by CA A (MD5), in
order to make such a binding? The assumption I'm making here is that when
RA B is enrolling under CA B (SHA-256), they're going to have the entity
demonstrate some proof of control over Identity A (MD5); how else can you
be sure they refer to the same entity, except through such verification?
When RA B/CA B issues Identity B, they end up relying on Identity A
(binding a name and a key), in order to make the assertion that B is the
same entity as A. If the cryptographic strength of A comes into question,
then the level of assurance of that binding comes into question, and that's
what I meant by B needing to be reissued: the binding's assurance is now
weakened as well.

Why? Similar to the same PKI case - if I issue a dopplengager MD5 cert,
asserting Identity C, then the security of the relying party would depend
on whether or not they extracted Identity B (SHA-256) or Identity C (forged
MD5). To address this, you either need to reissue B to remove that link
(preventing the confusion by removing the binding), or require that the
relying party require that the identity, and all other related identity
attributes, are the same between B and A/C. This would prevent C from
asserting a different identity than B/A and causing a confused deputy style
attack.

With 2), however, this mitigation is no longer possible - because the very
design constraint is different name types/identity scopes. So in that
scenario, a relying party needs to know which of the two identities is the
"better" identity to extract/"safe" one to use. If it runs identity
validation for both certs, things get a little weird, because both B/A and
B/C may be able to satisfy the constraints if (A, C) use a different naming
scheme than B. The assertion intended by B is to the A naming, but the
actual binding allows the substitution of C's identity, such that even if
both systems pass validation, any use of the A/C identity would be a
security issue (because C would be attacker-controlled).

Similarly, with respect to binding, let's say A is known weak, and so it is
replaced with a new certificate, D, that uses SHA-512. If I attempt to use
B/D to authenticate to the system, B won't have a binding to D, and thus
would fail if the RP asserted there is a binding. Alternatively, I could
bind D to B, and B to A, but then I'd need to have a way to resolve whether
the mismatched binding (B > A) was a failure, or whether the matching
binding (D > B) was sufficient. If I do the former, and say mismatches are
errors, then it means that in order to issue D (SHA-512), I also need to
replace B (SHA-256) with E (SHA-256), so that I have D/E, and I'd need the
issuers to coordinate to make sure the sequencing was right (so I don't end
up with D>B and E>D, and thus still have a mismatch). However, if I do the
latter, and say "strongest binding wins", then I need a way of expressing
that binding strength in the relying party, and that becomes a security and
policy decision that bears being explicit in the draft, and likely
introduces other protocol complexities wherever it is deployed.

I realize you say it depends on the implementation and verifier, but I
think the scenario like the above is exactly why there are security
considerations, in practice, to deploying this, and it's not a no-cost
extension. This is doubly-so when there's ongoing activity in other SDOs
that the IETF liaises with, that attempt to couple multiple independent
identity systems (e.g. legal identity and machine identity), and are
exploring such approaches like binding between two different certificate
systems. The security considerations of such solutions have impact on the
identity systems, and protocols, and those have to be carefully spelled
out, and the security of one system affects the security of the other.

In the context of RFC 5280, and the protocols that the IETF has using
these, the primary identity system is one of machine identity (e.g. routed
in DNS and IPs, whether for TLS, S/MIME, RPKI, etc). So, in this context, I
*think* it primarily is concerned with "Same PKIs, same naming" or
"Different PKIs, same naming", since both certificates would be asserting
the same hostname, email address, IP assignment, etc. I don't believe (or
at least, this draft doesn't seem to suggest) that it's concerned with the
"Different PKIs, different naming" scenario, such as trying to assert that
both foo.example and bar.example are under control of the same entity, but
relying on different RAs/CAs to perform those partial assessments, but if
I've misunderstood some of the goal, this would be great to clarify.

I realize much of this may feel very abstract, but if I were to make a
metapoint, it's that the security of the overall extension is going to rest
upon the protocol/protocols where it's deployed. I don't think we should
adopt the extension independent of being able to conduct that holistic
evaluation, because we can't really evaluate if the extension is fit for
purpose without having a better contextualization of that purpose. The
assumptions here, for example, assumed online protocols, like TLS, and
offline protocols like S/MIME would have their own messy set of
complexities. I understand and appreciate the goal of trying to have
flexibility independent of the protocol expression, but I'm a little
worried that this sort of compositional/hybrid analysis is not something
you can really just pull out, not as a generic reusuable component.

>