On Tue, Aug 13, 2019 at 11:12 AM Nuno Ponte via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Dear m.d.s.p.,
> I would like to bring into discussion the use of certificate/public key
> pinning and the impacts on the 5-days period for certificate revocation
> according to BR §
> Recently, we (Multicert) had to rollout a general certificate replacement
> due to the serial number entropy issue. Some of the most troubled cases to
> replace the certificates were customers doing certificate pinning on mobile
> apps. Changing the certificate in these cases required configuration
> changes in the code base, rebuild app, QA testing, submission to App
> stores, call for expedited review of each App store, wait for review to be
> completed and only then the new app version is made available for
> installation by end users (which is turn are required to update the app the
> soonest).
> Meeting the 5-days deadline with this sort of process is “challenging”, at
> best.
> A first approach is to move from certificate pinning to public key pinning
> (PKP). This prevents the need to update the app in many of the certificate
> replacement operations, where the public key is reused and the certificate
> can be replaced transparently to the app (generically, an “User Agent”
> doing PKP).
> However, in the event of a serious security incident that requires re-key
> (such as key compromise), the certificate must be revoked in less than 24
> hours (for the benefit of everyone – subscriber, relying parties, issuing
> CA, etc). It’s virtually impossible to release a new app version within
> this timeframe. And this, I think, make a very strong point against the use
> of PKI.
> On the other side, PKP is a simple yet powerful and effective technique to
> protect against MITM and other attacks. It seems to be widely used in apps
> with advanced threat models (mobile banking, sensitive personal
> information, etc) and there are many frameworks available (including native
> support in Android via Network Security Configuration [1]).
> There are several possible mitigation actions, such as pinning more than
> one public key to have more than one certificate to quickly rollover in
> case of a revocation. Even then, it is very likely that all the redundant
> key pairs were generated and maintained by the same systems and procedures,
> and thus all of them will become effectively compromised.
> Ultimately, it may become common practice that 1) PKP frameworks are set
> to bypass revocation checks or 2) PKP is done with private certificates
> (homemade, self-signed, managed ad-hoc with no CRL/OCSP services). Does any
> of this leads to a safer Internet?
> I don’t expect this thread to end up into an absolute conclusion
> advocating for or against, but opening it to discussion and contributions
> may help to document possible strategies, mitigations, alternatives, pros &
> cons, and hopefully provide guidance for an educated decision.
> Best regards,
> Nuno Ponte
> Multicert SA


Thanks for raising this. I appreciate that a CA is attempting to provide
guidance to their Subscribers, since, as you note, the CA is still beholden
to the Baseline Requirements, and the Subscriber still beholden to their
Subscriber Agreement.

As one of the co-authors of the HTTP Public Key Pinning RFC, RFC 7469, I
would readily encourage your Subscribers not to pin at all. However, if
they are going to pin to anything, then it:
1) Should be to the public key, not certificate
2) Should only be to the root
3) Should require an agreement with the root that the Root (i.e. Multicert)
will disclose all possible certificate paths and root certificates that are
unexpired and may exist.
  - This includes cross-signed certificates

Note that mobile devices, the scenario you discuss for pinning, already
largely do not implement revocation checks and do not offer a way for
applications to control it, so I don't think that should be a concern.

Of course, many of these techniques predate improvements to the ecosystem,
such as CAA and Certificate Transparency. Many of the concerns that
motivated HPKP, which subsequently evolved into the aforementioned OS APIs,
were predicated on an assumption of a CA that has lax validation methods.
Yet techniques such as CAA exist to give site operators meaningful control
- and to ensure that any CA that violates such checks, and ignores CAA, is
unambiguously at risk of being distrusted by the entire platform.

If there's concern about the DNS registrar being hacked, the Subscriber has
the option of choosing a better registrar before hand, without resorting to
PKP, and/or transitioning to registries with better security practices
overall. In general, this means avoiding ccTLDs, which are known lax due to
their lack of any formal IANA or ICANN agreements with respect to
operations. Certificate Transparency offers a compliment to this, ensuring
that even if the Registrar or Registry is compromised, misissued
certificates can be promptly detected for subsequent investigation and

However, as to your question about private PKIs potentially being more
secure - it is indeed possible this may be the right answer! Organizations
which desire complete lifecycle control over their certificates may benefit
from the use of such private PKIs - while also being wholly responsible for
the operational security of such, which naturally will be something their
regulatory oversight bodies will take great interest in.

Beyond that, what Matt and Tom said is absolutely correct. Making use of
multiple (distinct) TLS endpoints, even on the same IP, is absolutely
crucial for reducing these risks.

As a CA, the best thing you can do is to make sure your Subscribers know
that they are taking on operational risk when they pin, and the CA is not
empowered to assist in resolving that.
dev-security-policy mailing list

Reply via email to