[cabfpub] SHA1 options for payment processors

[Ryan Sleevi]

On Mar 14, 2016 9:17 AM, "kirk_hall at trendmicro.com" <
kirk_hall at trendmicro.com> wrote:
>
> I disagree that the methods Dean has proposed for making the interim
SHA-1 certs untrusted will not work.

And how will this solution protect users on systems that have never checked
revocation - such as the vast majority of critical infrastructure online in
server to server communication?

The libraries available in nearly every major programming language have no
such capabilities. Servers behind firewalls prevented from egress traffic.
Mobile devices for whom battery drain - and bandwidth costs - are real
concerns. Previously, proponents of SHA-1 extensions argued the impact to
the developing world - but all of these solutions proposed foist the cost
from the CA and organizations responsible for this problem onto browsers
and users - users whose access to critical needs would be impaired by the
costs you suggest they should bear.

This is why the need for public debate is high - let there be no question,
the cause of this is either the CA or the organization being lax in their
duty. They are now coming to ask the world at large to subsidize their
mistake - after so many other organizations, many in competition with those
now asking, spent considerable time and effort to prepare.

>  For example, issuing and immediately revoking will make the certs
untrusted.  If some browsers no longer check certs for revocation, it is
the decision to abandon revocation checking that creates any security
vulnerability for users, not the cert itself – and that vulnerability
exists today even for SHA-256 certs that have been revoked for misissuance,
misuse, etc.  If the browsers are treating revoked certs as “good” when
serving content to users, that’s a totally different security issue.

In bringing this up, you have both missed and made the point as to why this
solution does not work. The number of clients who check revocation is
miniscule - browser and non-browser alike. What you describe as a solution
has no basis in the real world, merely the idealized world you might wish
existed. That's the sort of trade-off discussion to be had - because as a
solution, it does not work.

Further, let's be clear - the solution is to immediately recognize the
certificates as untrustworthy. That is, the CA would actively be engaging
in untrustworthy behaviour. Surely, for an industry based on trust, you can
understand why this is damaging.

But perhaps the most important matter is that this obviously does not work.
I realize you may be more familiar with the business aspects of trust than
the technical, but I encourage you to re-read the work on the MD5 collision
on RapidSSL/Symantec. In that, the attackers were able to change the serial
number in the malicious cert. As I am sure you are aware, the serial number
is how a certificate is revoked - and attacker who can change the serial
number creates an irrevocable certificate.

That's why this suggestion has no merit on technical grounds. It simply
doesn't provide the protection necessary. Now, we could discuss ways that
the CA could make it harder for an attacker, but that again presumes no
colluding insider and perfect operational execution. While we have no
public evidence of the former, in this day and age we cannot discount it,
but in the case of the latter we have ample evidence of CAs' inability to
achieve this - as shown by CRT.sh.

> Likewise, browsers can add these interim SHA-1 certs to their CRLsets
list, and users will be protected.  If I understand correctly, the WorldPay
case only involved 8 or 9 certs total, so this is not a great burden on the
browsers.

And yet again, this is not at all a viable solution - on technical grounds.
Nor does it scale to protect the ecosystem - doing real harm to
non-browser-but-public trust use cases (e.g. in consuming API services from
sites also intended to be accessed from browsers - as in, what enables vast
amounts of online commerce and functionality)

> I still don’t see how Forum members can evaluate any special pleading
from an applicant who needs these interim certs – I assume in all cases
applicants can’t update their devices, so the devices will go dark if they
can’t get an untrusted SHA-1 cert for the next 90 days, etc.  What other
information would you want?

Again, you can find a list of questions that serves as the basis for a
meaningful discussion. Absent that, there isn't really the option to
discuss further.

> Finally, this situation really illustrates that we should NEVER again
create split dates for changes in requirements, where there is an early end
date on issuance of some type of cert, and a later “last validity” date.
In this case, we should have made December 31, 2016 the “last validity”
date only, and CAs should have been allowed to issue up to that date (even
be able to issue a one-day cert on December 30, 2016).  That will get the
attention of customers – when they apply on May 1 and are told they can
only get an 8 month cert, customers will understand the deadline is real
and approaching, and we won’t face the argument “I could have gotten a
one-year cert on Dec. 31, but can’t get any cert on Jan. 1 – that makes no
sense.”
>

I'm sure if you consider this proposal further, you will realize why it
does not work. A split date is always inevitable - because you have the day
before the effective date of the ballot and the day after. To truly avoid
the situation you suggest, we would have to set the effective date to be
the max of the validity date at time of issuance, times two (or 78 months)
- 39 months for the "issued under the old rules" certs to expire, and then
another 39 months to transition the new rules into place. Perhaps if the
validity of certs was limited to, say, 9 months, this would be potentially
workable, but even then, the Forum must be prepared to transition rapidly
in times of security crisis.

The responsible thing for CAs to do would have been to implement the plan
you suggest, and not allow them certificates expiring past 1/1/16 (not 17 -
the risk is real today, as research has shown). Certainly, browsers like
Chrome and Firefox made efforts to assist in bringing awareness, doing as
best they could something similar to what you propose - but it seems the
problem cases that remain are the ones where they were the CAs' customers,
rather than the browsers' - which makes me wonder if perhaps that helps
identify how this problem came to be and where the problem lies.

And that's why the need for the case-by-case basis, and the questions I
posed - we can only do better in the future if we have a better
understanding of why some CAs and sites did so badly in the present.
Proposals such as yours will be needed, so that in the future we can do
better at preventing these sorts of things. I think it is fantastic that
you are looking forward to the next steps - but I don't believe we can
reasonably do that unless we understand the present. And to do that
requires data, which requires meaningful, direct, honest, and unencumbered
interaction with those affected - so that we can truly understand the
situation.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160314/e2d8749a/attachment-0003.html>