On 28/9/2018 8:04 μμ, Ryan Sleevi via dev-security-policy wrote:
On Fri, Sep 28, 2018 at 1:22 AM Dimitris Zacharopoulos via
dev-security-policy<dev-security-policy@lists.mozilla.org> wrote:
Forgive my ignorance, but could you please explain what was your
ultimate goal, as "an attacker", what were you hoping to gain and how
could you use this against Relying Parties?
I read your email several times but I could not easily find a case where
your fake address creates any serious concern for Relying Parties. Even
if you used the same street address as CloudFlare, the CA would check
against the database and would find two company records that share the
same address. That would obviously block the process and additional
checks would take place. Now, as a way to delay certificate issuance for
CloudFlare, I find it interesting but it certainly doesn't seem to
affect Relying Parties.
I'm not Ian, but I would have thought his email would have been obvious and
clear. The confusion here is that two jurisdictions can allow different
entities the same name. The EVGs seek to resolve this by making use of a
variety of ancilliary fields - such as serialNumber and the incorporation
information - to presumably attempt to establish to the relying party the
identity they're speaking to.
In the "Stripe, Inc" case, the user was able to distinguish 'real' from
'fake' by virtue of the incorporation information - Kentucky vs California.
However, in this case, the attack went further, in as much as through the
CA using an unreliable datasource to verify the jurisdictional information.
If the CA used an unreliable datasource, then the end user would see
something that, for intents and purposes, appears the same.
I'm not sure your point about the same address - Ian made it clear it was a
different but *similar* address - and I'm not sure why you suggest it would
block for the legitimate subscriber. Does that explain it simply enough?
Perhaps I am confusing different past discussions. If I recall
correctly, in previous discussions we described the case where an
attacker tries to get a certificate for a company "Example Inc." with
domain "example.com". This domain has a domain Registrant Address as
"123 Example Street".
The attacker registers a company with the same name "Example Inc." in a
different jurisdiction, with address "123 Example Street" and a
different (attacker's) phone number. How is the attacker able to get a
certificate for example.com? That would be a real "attack" scenario.
Unless this topic comes as a follow-up to the previous discussion of
displaying the "Stripe Inc." information to Relying Parties, with the
additional similarity in Street Address and not just the name of the
Organization. If I recall correctly, that second "Stripe Inc." was not a
"fake" entity but a "real" entity that was properly registered in some
Jurisdiction. This doesn't seem to be the same attack scenario as
getting a certificate for a Domain for which you are not the owner nor
control, but a way to confuse Relying Parties. Certainly, in case of
fraud, this leaves a lot more evidence for the authorities to trail back
to a source, than for a case without Organization information.
And to take this one step further, I believe there are several GISs that
also accept whatever address you tell them because:
1. They have no reason to believe that you will lie to them (they know
who you are and in some Jurisdictions you might be prosecuted for
lying to the government)
2. No foreseeable harm to others could be done if you misrepresent your
own address.
Then they are not Reliable nor QIISes. Full stop.
But they do have some Reliable and Qualified Information according to
our standards (for example registry number, legal representative,
company name). If a CA uses only this information from that source, why
shouldn't it be considered reliable? We all need to consider the fact
that CAs use tools to do their validation job effectively and
efficiently. These tools are evaluated continuously. Complete dismissal
of tools must be justified in a very concrete way.
I would accept your conclusion for an Information Source that claimed,
in their practices, that they verify some information against a
secondary government database and the CA gets evidence that they don't
actually do that. This means that the rest of the "claimed as verified"
information is now questionable. This is very much similar to the
Browsers checking for misbehavior on CAs where they claim certain
practices in their CP/CPS and don't actually implement them. That would
be a case where the CA might decide to completely distrust that
Information Source.
I hope you can see the difference.
In my understanding, this is the process each CA must perform to
evaluate every Data Source before granting them the "Reliable" or
"Qualified" status. Self-reported information without any supporting
evidence is clearly not acceptable. I have not evaluated this database
that you mention but if they accept self-reporting for "Street Address"
and don't perform any additional verification (like asking you for a
utility bill or cross-referencing it with a government database), then
the "Street Address" information is unreliable and the CA's evaluation
process should catch that.
That doesn't mean that the rest of the information is also unreliable.
For example, an Information Source might describe in their documentation
practices how they verify each piece of information, for example:
I disagree with this assessment, and I think it's precisely why greater
restriction is needed on the flexibility of CAs to make such
interpretations. I understand the point you're trying to make - why throw
the baby out with the bathwater - but to its use within the EVGs and the
BRs, such structural issues throw into fundamental question the status as a
RDS or QIIS.
As you highlight, this is an assessment that each CA makes, according to
its own processes and skills, and based on their own understanding.
Auditors, which while required to have professional understanding of the
relevant standards but are by no means omniscient nor experts, then also
review these processes. Thus, we can easily end up in a situation where CA
A determines that Foo is an RDS and QIIS for (Address, Serial Number),
while CA B determines that Foo is an RDS and QIIS only for (Serial Number).
For an adversarial model, however, the strength of CA B's understanding and
recognition that Foo is not suitable as a QIIS for Address is irrelevant,
as an adversary needs only obtain a certificate from CA A instead. While
I'm sure CA B would love to market and crow about their excellence in the
market for recognizing that Foo was not a QIIS for Address, to the end
user, browser, and relying party, the fact that CA B deserves a cookie and
a pat on the back is irrelevant.
I remember this argument being supported in the past and although I used
to agree to it, with the recent developments and CA disqualifications, I
support the opposite. That is, Subscribers start to choose their CA more
carefully and pay attention to the trust, reputation and practices,
because of the risk of getting their Certificates challenged, revoked or
the CA distrusted.
This is because the goal of a given root program is to ensure a
consistently operated PKI with a consistent degree of assurance. That CA A
accepts Foo as a QIIS and CA B does not, because they both participate in
the same PKI (namely, the browser's root program), the levels of assurance
are not equal to the expectations of the policy. One model of approaching
this is to try to outsource that lack of assurance to the relying party -
for example, telling them that "CA A shouldn't be relied upon" or "CA B is
more trustworthy" - but for the Web, that's a fundamentally failed model
full of user-hostility. The other approach is to establish more consistent
criteria to assess CA A and CA B against, to reduce the divergence in
assurance - which is where a whitelist comes from.
CAs are required to comply with very complicated standards and these
standards describe best practices on how to evaluate and re-evaluate
information sources.
If CA A trusted the "street address" from a DS, used this information to
be included in Certificates and later during re-evaluation discovered
that this particular piece of information is unreliable, I would expect
this to be treated as an incident according to the current standards.
The CA would have to create a plan to mitigate this problem. Again, this
depends on the CA's decisions how to mitigate the problem. Others would
revoke all the affected certificates immediately, others would
re-evaluate the "street address" information using a different reliable
source and revoke the Certificates they were unable to re-verify, others
would do nothing. It is impossible to cover all possible cases and
require equal treatment for incidents.
I fully support a white-list of RDS/QIS with global acceptance and
collective scrutiny but even these lists need to be re-evaluated
periodically as required by our standards. Perhaps a "global black-list"
might be setup for certain cases of misbehavior like the one described
above. However, this white-list should not be the only one allowed to
be used and national jurisdiction databases (company registries) should
also be allowed provided they are adequately evaluated by the CA
according to our standards.
I also support the idea of describing which information is evaluated as
"reliable" from a particular source and not completely dismiss a source
if they describe in their practices that they accept "some other"
irrelevant-to-the-ca information as self-reported.
It is a very challenging goal, especially because there are so many
different jurisdictions from which to collect reliable information. As a
more realistic goal, perhaps we could describe the ideal data source
evaluation and periodic re-evaluation process more explicitly in the
Guidelines, with clear and auditable criteria.
Dimitris.
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
