On 2020-11-18 16:36, Ryan Sleevi wrote:
On Wed, Nov 18, 2020 at 8:19 AM Nils Amiet via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
We have carefully read your email, and believe we’ve identified the
following
important points:
1. Potential feasibility issue due to lack of path building support
2. Non-robust CRL implementations may lead to security issues
3. Avoiding financial strain is incompatible with user security.
I wasn't trying to suggest that they are fundamentally incompatible (i.e.
user security benefits by imposing financial strain), but rather, the goal
is user security, and avoiding financial strain is a "nice to have", but
not an essential, along that path.
#1 Potential feasibility issue due to lack of path building support
If a relying party does not implement proper path building, the EE
certificate
may not be validated up to the root certificate. It is true that the new
solution adds some complexity to the certificate hierarchy. More
specifically
it would turn a linear hierarchy into a non-linear one. However, we
consider
that complexity as still being manageable, especially since there are
usually
few levels in the hierarchy in practice. If a CA hierarchy has utilized the
Authority Information Access extension the chance that any PKI library can
build the path seems to be very high.
I'm not sure which PKI libraries you're using, but as with the presumption
of "robust CRL" implementations, "robust AIA" implementations are
unquestionably the minority. While it's true that Chrome, macOS, and
Windows implement AIA checking, a wide variety of popular browsers
(Firefox), operating systems (Android), and libraries (OpenSSL, cURL,
wolf/yassl, etc etc) do not.
Even if the path could not be built, this would lead to a fail-secure
situation
where the EE certificate is considered invalid and it would not raise a
security issue. That would be different if the EE certificate would
erroneously
be considered valid.
This perspective too narrowly focuses on the outcome, without considering
the practical deployment expectations. Failing secure is a desirable
property, surely, but there's no question that a desirable property for CAs
is "Does not widely cause outages" and "Does not widely cause our support
costs to grow".
The focus seems to be on limiting the ecosystem risks associated with
non-comliant 3rd party SubCAs. Specifically, in the (already important)
situation where SICA was operated by a 3rd party (not the root CA
operator), their proposal would enforce the change (by replacing and
revoking the root CA controlled ICA), whereas the original procedure
would rely on auditing a previously unaudited 3rd party, such as a name
constrained corporate CA.
Consider, for example, that despite RFC 5280 having a "fail close" approach
for nameConstraints (by MUST'ing the extension be critical), the CA/B Forum
chose to deviate and make it a MAY. The reason for this MAY was that the
lack of support for nameConstraints on legacy macOS (and OpenSSL) versions
meant that if a CA used nameConstraints, it would fail closed on those
systems, and such a failure made it impractical for the CA to deploy. The
choice to make such an extension non-critical was precisely because
"Everyone who implements the extension is secure, and everyone who doesn't
implement the extension works, but is not secure".
It is unfortunate-but-seemingly-necessary to take this mindset into
consideration: the choice between hard-failure for a number of clients (but
guaranteed security) or the choice between less-than-ideal security, but
practical usability, is often made for the latter, due to the socioeconomic
considerations of CAs.
Now, as it relates to the above point, the path building complexity would
inevitably cause a serious spike in support overhead, because it requires
that in order to avoid issues, every server operator would need to take
action to reconfigure their certificate chains to ensure the "correct"
paths were built to support such non-robust clients (for example, of the
OpenSSL forks, only LibreSSL supports path discovery, and only within the
past several weeks). As a practical matter, that is the same "cost" of
replacing a certificate, but with less determinism of behaviour: instead of
being able to test "am I using the wrong cert or the right one", a server
operator would need to consider the entire certification path, and we know
they'll get that wrong.
Their proposal would fall directly into the "am I using the wrong cert
or the right one" category. EE subscribers would just have to do a
SubCA certifiate replacement, just like they would if a CA-internal
cross-certificate expires and is reissued (as happened in 2019 for
GlobalSign's R1-R3 cross cert, which was totally workable for us
affected subscribers, though insufficient notices were sent out).
This is part of why I'm dismissive of the solution; not because it isn't
technically workable, but because it's practically non-viable when
considering the overall set of ecosystem concerns. These sorts of
considerations all factor in to the decision making and recommendation for
potential remediation for CAs: trying to consider all of the interests, but
also all of the limitations.
#2 Non-robust CRL implementations may lead to security issues
Relying parties using applications that don’t do a proper revocation check
do
have a security risk. This security risk is not introduced by our proposal
but
inherent to not implementing core functionality of public key
infrastructures.
The new solution rewards relying parties that properly follow the
standards.
Indeed, a relying party that has a robust CRL (or OCSP check)
implementation
already would not have to bear any additional security risk. They also
would
benefit from the point that our solution can be implemented very quickly
and so
they would quickly mitigate the security issue. On the other hand, relying
parties with a non-functional revocation mechanism will have to take
corrective
measures. And we can consider it a fair balancing of work and risk when the
workload and risk is on the actors with poor current implementations.
It can be noted that the new solution gives some responsibility to the
relying
parties. Whereas the original solution gives responsibility to the
subscribers
who did nothing wrong about this in the first place. The new solution can
be
considered fairer with this regard.
I think this greatly misunderstands the priority of constituencies here, in
terms of what represents a "fair" solution. The shuffling of responsibility
to relying parties is, ostensibly, an anti-goal we try to minimize. As I
explained above, the practical impact for server operators is not actually
decreased, but increased, and so the overall "risk" here is now greater
than the "current" solution.
With respect to revocation and threat models, I'm not sure this thread is
the best medium to get into it, but "core functionality of public key
infrastructure" would arguably be a misstatement. Revocation functionality
reflected in X.509/RFC 5280 is tied to a number of inherent assumptions
about particular PKI designs and capabilities (e.g. the connectivity of
clients to an X.500/LDAP directory, the failure tolerances of clients
respective to the security goals, the number and type of certificates
issued), and it's not, in fact, a generalized solution. PKI is, at best, a
series of tools to be adjusted for different situations, and those tools
are not inherently right, or their absence not inherently wrong.
As it relates to the set of clients you're considering, again, this is the
difference between the "real world" of implementations and the idealized
world of the 90s that presumed a directory would co-exist with the PKI (and
serve an inherent function). The Directory doesn't exist, nor do PKI
clients broadly implement HTTP in the first place, let alone LDAP, and so
presumptions about the availability of external datas ources to handle this
doesn't actually hold up. This is where the current approach tries to be
both practical and pragmatic, by working in a manner that complements the
existing design constraints, rather than conflicts with them.
However this solution seems to not rely on PKI clients having fail-hard
CRL/OCSP handling, but on them having a way to enforce SubCA
revocations. This includes Mozilla OneCRL, the static CRL support
in OpenSSL and the "Untrusted Certificates" feature in MS CryptoAPI.
...
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
