Re: [FORGED] Re: [FORGED] Re: Website owner survey data on identity, browser UIs, and the EV UI

[Peter Gutmann via dev-security-policy]

Ronald Crane via dev-security-policy  
writes:

>Please cite the best study you know about on this topic (BTW, I am *not* 
>snidely 
>implying that there isn't one).

Sure, gimme a day or two since I'm away at the moment.

Alternatively, there's been such a vast amount of work done on this that a few
seconds of googling should find plenty of publications.  As the first search 
text that came to mind, "browser ui phishing" returns just under half a million 
hits.  Making it "browser ui phishing inurl:.pdf" to get just papers (rather 
than
web articles, blog posts, etc) reduces that to 30,000 results.

Peter.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Next Root Store Policy Update

[Jeremy Rowley via dev-security-policy]

One suggestion on incident reports is to define "regularly update" as some 
period of time as non-responses can result in additional incident reports.  
Maybe something along the lines of "the greater of every 7 days, the time 
period specified in the next update field by Mozilla, or the time period for 
the next update as agreed upon with Mozilla". I'd also change "the 
corresponding bug is resolved by a Mozilla representative" to "the 
corresponding bug is marked as resolved in bugzilla by a Mozilla 
representative" since the CA is resolving the actual bug, and Mozilla is 
managing its perception on the bug's status.

Jeremy

-Original Message-
From: dev-security-policy  On 
Behalf Of Wayne Thayer via dev-security-policy
Sent: Wednesday, October 2, 2019 4:17 PM
To: mozilla-dev-security-policy 
Subject: Re: Next Root Store Policy Update

Over the past 3 months, a number of other projects distracted me from this 
work. Now I'd like to focus on finishing these updates to our Root Store 
policy. There are roughly 6 issues remaining to be discussed, and I will, as 
always, greatly appreciate everyone's input on them. I'll be sending out 
individual emails on each issue.

Meanwhile, you can view a redline of the changes we previously agreed on:
https://github.com/mozilla/pkipolicy/compare/master...2.7

- Wayne

On Wed, Mar 27, 2019 at 4:12 PM Wayne Thayer  wrote:

> I've added a few more issues that were recently created to the list 
> for
> 2.7: https://github.com/mozilla/pkipolicy/labels/2.7
>
> 176 - Clarify revocation requirements for S/MIME certs
> 175 - Forbidden Practices wiki page says email validation cannot be 
> delegated to 3rd parties
>
> I plan to begin posting issues for discussion shortly.
>
>
> On Fri, Mar 8, 2019 at 2:12 PM Wayne Thayer  wrote:
>
>> Later this month, I would like to begin discussing a number of 
>> proposed changes to the Mozilla Root Store policy [1]. I have 
>> reviewed the list of issues on GitHub and labeled the ones that I recommend 
>> discussing:
>> https://github.com/mozilla/pkipolicy/labels/2.7 They are:
>>
>> 173 - Strengthen requirement for newly included roots to meet all 
>> current requirements
>> 172 - Update section 5.3 to include Policy Certification Authorities 
>> as an exception to the mandatory EKU inclusion requirement
>> 171 - Require binding of CA certificates to CP/CPS
>> 170 - Clarify Section 5.1 about allowed ECDSA curve-hash pair 169, 
>> 140 - Extend Section 8 to also encompass subordinate CAs 168, 161, 
>> 158  - Require Incident Reports, move practices into policy
>> 163 - Require EKUs in end-entity certificates (S/MIME)
>> 162 - Require disclosure of CA software vendor/version in incident 
>> report
>> 159 - Clarify section 5.3.1 Technically Constrained
>> 152 - Add EV audit exception for policy constrained intermediates
>> 151 - Change PITRA to Point-in-Time assessment in section 8
>>
>> I will appreciate any feedback on the proposed list of issues to discuss.
>>
>> I do recognize that the current DarkMatter discussions could result 
>> in the need to add some additional items to this list.
>>
>> I have created a new branch for drafting these changes [1] and made 
>> one commit that adds a bullet to the BR Conformance section informing 
>> the reader that Mozilla policy has a more restrictive list of 
>> approved algorithms [3]
>>
>> As we've done in the past, I plan to post individual issues for 
>> discussion in small batches over the next few months, with the goal 
>> of finalizing version 2.7 by June.
>>
>> - Wayne
>>
>> [1]
>> https://www.mozilla.org/en-US/about/governance/policies/security-grou
>> p/certs/policy/ [2] 
>> https://github.com/mozilla/pkipolicy/blob/2.7/rootstore/policy.md
>> [3] https://github.com/mozilla/pkipolicy/issues/167
>>
>
___
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

RE: Policy 2.7 Proposal: Require EKUs in End-Entity Certificates

[Jeremy Rowley via dev-security-policy]

I'm surprised any CA has heartburn over the EKU changes. Microsoft has required 
them in end entity certificates for quite some time. From the MS policy: 
"Effective February 1, 2017, all end-entity certificates must contain the EKU 
for the purpose that the CA issued the certificate to the customer, and the 
end-entity certificate may not use “any EKU.”" There's a chance that the CA is 
not in Microsoft, but I thought Mozilla usually had fewer CAs than Microsoft 
included. 

-Original Message-
From: dev-security-policy  On 
Behalf Of Wayne Thayer via dev-security-policy
Sent: Wednesday, October 2, 2019 6:05 PM
To: horn...@gmail.com
Cc: mozilla-dev-security-policy 
Subject: Re: Policy 2.7 Proposal: Require EKUs in End-Entity Certificates

On Tue, Jul 9, 2019 at 2:12 AM horn917--- via dev-security-policy < 
dev-security-policy@lists.mozilla.org> wrote:

> Wayne Thayer於 2019年3月30日星期六 UTC+8上午4時48分27秒寫道：
> > The BRs require EKUs in leaf TLS certs, but there is no equivalent 
> > requirement for S/MIME certificates. This leads to confusion such as 
> > [1]
> in
> > which certificates that are not intended for TLS or S/MIME fall 
> > within
> the
> > scope of our policies.
> >
> > Simply requiring EKUs in S/MIME certificates won't solve the problem
> unless
> > we are willing to exempt certificates without an EKU from our 
> > policies,
> and
> > doing that would create a rather obvious loophole for issuing S/MIME 
> > certificates that don't adhere to our policies.
> >
> > The proposed solution is to require EKUs in all certificates that 
> > chain
> up
> > to roots in our program, starting on some future effective date (e.g.
> April
> > 1, 2020). This has the potential to cause some compatibility 
> > problems
> that
> > would be difficult to measure and assess. Before drafting language 
> > for
> this
> > proposal, I would like to gauge everyone's support for this proposal.
> >
> > Alternately, we could easily argue that section 1.1 of our existing
> policy
> > already makes it clear that CAs must include EKUs other than 
> > id-kp-serverAuth and id-kp-emailProtection in certificates that they 
> > wish to remain out of scope for our policies.
> >
> > This is https://github.com/mozilla/pkipolicy/issues/163
> >
> > I will greatly appreciate everyone's input on this topic.
> >
> > - Wayne
> >
> > [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1523221
>
>
> GPKI(Taiwan) will follow Mozilla policy to add EKU to EE certificates 
> However, the influence range of implementation is very large.
> We need to define our own Document Signing EKU and data encryption 
> EKU, and coordinate all subordinate Cas(Five CAs) and application 
> system’s owners(more than 2,000 application systems).
> It needs a whole year to implement this. Therefore, after multiple 
> evaluations, it is decided to officially add the EKU to the user 
> certificate on January 1, 2021.
> It is difficult for us to complete ahead of April 2020.
> Can we get more buffer?
>
>
I had expected to have this policy update completed sooner when I proposed 
April 2020 as the date for requiring EKUs in end-entity certificates. Given 
that, I think it's reasonable to push the date back to July 2020, but not to 
January 2021. 2021 seems particularly unreasonable in light of the Microsoft 
requirement [1] that went into effect in January 2017 and appears to apply to 
GPKI.

Will any other CAs find it impossible to meet this requirement for certificates 
issued after June 2020? Also, are there any concerns with this applying to 
certificates issued from technically constrained intermediate CA certificates? 
As-proposed, this applies to those certificates (and it appears to me that 
Microsoft's policy does as well).

- Wayne

[1]
https://docs.microsoft.com/en-us/security/trusted-root/program-requirements#4-program-technical-requirements
___
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

Re: Policy 2.7 Proposal: Clarify Section 5.1 ECDSA Curve-Hash Requirements

[Wayne Thayer via dev-security-policy]

Thank you Ryan. Brian reviewed these changes back in May, so I've gone
ahead and accepted them for the 2.7 policy update:
https://github.com/mozilla/pkipolicy/commit/5657ecf650d70fd3c6ca5062bee360fd83da9d27

I'll consider this issue resolved unless there are further comments.

- Wayne

On Fri, May 24, 2019 at 1:38 AM Ryan Sleevi  wrote:

>
>
> On Wed, May 22, 2019 at 7:43 PM Brian Smith  wrote:
>
>> Ryan Sleevi  wrote:
>>
>>>
>>>
 It would be easier to understand if this is true if the proposed text
 cited the RFCs, like RFC 4055, that actually impose the requirements that
 result in the given encodings.

>>>
>>> Could you clarify, do you just mean adding references to each of the
>>> example encodings (such as the above example, for the SPKI encoding)?
>>>
>>
>> Exactly. That way, it is clear that the given encodings are not imposing
>> a new requirement, and it would be clear which standard is being used to
>> determine to correct encoding.
>>
>
> Thanks, did that in
> https://github.com/sleevi/pkipolicy/commit/80da8acded63618a058d26c73db1e2438a6df9ed
>
>
>>
>> I realize that determining the encoding from each of these cited specs
>> would require understanding more specifications, including in particular
>> how ASN.1 DER requires DEFAULT values to be encoded. I would advise against
>> calling out all of these details individually less people get confused by
>> inevitable omissions.
>>
>
> Hopefully struck the right balance. These changes are now reflected in the
> PR at https://github.com/mozilla/pkipolicy/pull/183
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Updated website owner survey data on identity, browser UIs, and the EV UI

[Kirk Hall via dev-security-policy]

On September 21, I sent a message to the Mozilla community with the results of 
a survey of all of Entrust Datacard’s customers (both those who use EV 
certificates, and those who don’t) concerning what they think about website 
identity in browsers, browser UIs in general, and EV browser UIs in particular. 
[1]  The data we published was based on 504 results collected over two days (a 
pretty good response).

The survey was distributed in a way that each customer could only respond once. 
 We left the survey open, and can now publish updated results from a combined 
total of 804 separate certificate customers (300 more than last time).  The 
results mirror the results we first reported two weeks ago – and based on Paul 
Walsh’s data on when survey results should be considered statistically 
significant [2], this means that the updated survey results are very solid.

Here is a summary of the updated respondent results for the six questions 
listed below.

(1) 97% of respondents agreed or strongly agreed with the statement: "Customers 
/ users have the right to know which organization is running a website if the 
website asks the user to provide sensitive data."  (This is the same result as 
for the prior sample.)

(2) 94% of respondents agreed or strongly agreed with the statement “Identity 
on the Internet is becoming increasingly important over time.”  (This is 1% 
higher than in the prior sample.)

(3) When respondents were asked “How important is it that your website has an 
SSL certificate that tells customers they are at your company's official 
website via a unique and consistent UI in the URL bar?” 76% said it was either 
extremely important or very important to them. Another 13% said it was somewhat 
important (total: 89%).  (This is 2% higher than in the prior sample.)

(4) When respondents were asked “Do you believe that positive visual signals in 
the browser UI (such as the EV UI for EV sites) are important to encourage 
website owners to choose EV certificates and undergo the EV validation process 
for their organization?” 72% said it was either extremely important or very 
important to them.  (This is down 1% from the prior sample.) Another 18% said 
it was somewhat important.  (This is up 1% from the prior sample.)  The total 
is the same at 90%.

(5) 92% agreed or strongly agreed with the statement: “Web browser security 
indicators should be standardized across different browsers to make the UI 
easier for users to understand.”  (No change from prior sample.)

(6) Finally, when asked “Do you think browsers should standardize among 
themselves on a common Extended Validation UI so that it appears roughly the 
same in all browsers?” 89% said yes.  (This is down 2% from the prior sample.)

Here is the distribution of respondents by number of employees:

804 enterprise responses total (versus 504 in prior sample).  There was an 
increase in survey participation by smaller companies in these updated results.

Organization Size by Employee Count

12.34% 1 to 99 employees
15.53% 100 to 499 employees
9.71% 500 to 999 employees
24.13% 1,000 to 4,999 employees
17.20% 5,000 to 19,999 employees
18.72% 20,000 or more employees
2.36% Don't know

Clearly organizations of all sizes think website identity is important, that 
the EV UI should be retained, and that the browser UI design should be 
standardized across different browsers. While any survey can certainly be 
improved, this is the only data anyone has provided to the Mozilla community 
concerning what website owners think about browser UIs, and what they would 
like to see.

We again recommend that Mozilla consider adopting the binary Apple UI, which 
works in both desktop and mobile environments and distinguishes between 
EV/identity sites (with a green lock symbol and URL) and DV/anonymous sites 
(with a black lock symbol and URL) – check it out in an iPhone.  (Apple did not 
eliminate the EV UI, as some has erroneously said.)  This is easy for users to 
understand at a glance. To see how it looks, compare apple.com (EV) to 
google.com (DV) on an iPhone using Safari.  Paul has suggested that color 
difference alone is not sufficient, and there should be something more to 
distinguish the EV UI from the DV UI – that sounds good to me, but if Mozilla 
and Apple align, we will have made progress on getting a common UI across 
multiple browsers.

As others have said on this string, there are no recent browser or academic 
studies that that say an improved EV UI can’t work with users.  The only study 
that has been cited to support removal of the EV UI is a Google study that 
essentially asked what users *do* know about UIs today (answer: users don’t 
understand the current EV UI and don’t rely on it to make security decisions).  
I believe the reason for this result is that the EV UI is constantly changing 
(the Chrome EV UI has gone through three major changes in the last 12 months, 
with no user education – so why sho

Re: Policy 2.7 Proposal: Require EKUs in End-Entity Certificates

[Wayne Thayer via dev-security-policy]

On Tue, Jul 9, 2019 at 2:12 AM horn917--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Wayne Thayer於 2019年3月30日星期六 UTC+8上午4時48分27秒寫道：
> > The BRs require EKUs in leaf TLS certs, but there is no equivalent
> > requirement for S/MIME certificates. This leads to confusion such as [1]
> in
> > which certificates that are not intended for TLS or S/MIME fall within
> the
> > scope of our policies.
> >
> > Simply requiring EKUs in S/MIME certificates won't solve the problem
> unless
> > we are willing to exempt certificates without an EKU from our policies,
> and
> > doing that would create a rather obvious loophole for issuing S/MIME
> > certificates that don't adhere to our policies.
> >
> > The proposed solution is to require EKUs in all certificates that chain
> up
> > to roots in our program, starting on some future effective date (e.g.
> April
> > 1, 2020). This has the potential to cause some compatibility problems
> that
> > would be difficult to measure and assess. Before drafting language for
> this
> > proposal, I would like to gauge everyone's support for this proposal.
> >
> > Alternately, we could easily argue that section 1.1 of our existing
> policy
> > already makes it clear that CAs must include EKUs other than
> > id-kp-serverAuth and id-kp-emailProtection in certificates that they wish
> > to remain out of scope for our policies.
> >
> > This is https://github.com/mozilla/pkipolicy/issues/163
> >
> > I will greatly appreciate everyone's input on this topic.
> >
> > - Wayne
> >
> > [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1523221
>
>
> GPKI(Taiwan) will follow Mozilla policy to add EKU to EE certificates
> However, the influence range of implementation is very large.
> We need to define our own Document Signing EKU and data encryption EKU,
> and coordinate all subordinate Cas(Five CAs) and application system’s
> owners(more than 2,000 application systems).
> It needs a whole year to implement this. Therefore, after multiple
> evaluations, it is decided to officially add the EKU to the user
> certificate on January 1, 2021.
> It is difficult for us to complete ahead of April 2020.
> Can we get more buffer?
>
>
I had expected to have this policy update completed sooner when I proposed
April 2020 as the date for requiring EKUs in end-entity certificates. Given
that, I think it's reasonable to push the date back to July 2020, but not
to January 2021. 2021 seems particularly unreasonable in light of the
Microsoft requirement [1] that went into effect in January 2017 and appears
to apply to GPKI.

Will any other CAs find it impossible to meet this requirement for
certificates issued after June 2020? Also, are there any concerns with this
applying to certificates issued from technically constrained intermediate
CA certificates? As-proposed, this applies to those certificates (and it
appears to me that Microsoft's policy does as well).

- Wayne

[1]
https://docs.microsoft.com/en-us/security/trusted-root/program-requirements#4-program-technical-requirements
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: [FORGED] Re: Website owner survey data on identity, browser UIs, and the EV UI

[Ronald Crane via dev-security-policy]

On 10/2/2019 3:27 PM, Peter Gutmann wrote:

Ronald Crane via dev-security-policy  
writes:


"Virtually impossible"? "Anyone"? Really? Those are big claims that need real
data.

How many references to research papers would you like?  Would a dozen do, or
do you want two dozen?

One well-done paper would do.

I'm pretty sure I haven't been phished yet.
How would you know?


Since most phishing appears to be financial, I would expect unauthorized 
withdrawals from financial accounts, unauthorized credit card charges, 
unordered packages showing up, dunning notices from the IRS because I 
filed my tax returns with a phisher, etc. I haven't observed these 
indicia of getting phished.



And how does this help the other 7.53 billion people who
will be targets for phishers?
Alas it doesn't. We do need better phishing prevention. Do you have a 
suggestion?

In any case, have we ever really tried to teach users to use the correct
domain?

Yes, we've tried that.  And that.  And that too.  And the other thing.  Yes,
that too.

None of them work.


Please cite the best study you know about on this topic (BTW, I am *not* 
snidely implying that there isn't one).


-R

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.7 Proposal: Clarify Revocation Requirements for S/MIME Certificates

[Wayne Thayer via dev-security-policy]

Thank you for the comments Dimitris. I think you make a valid point in
general that S/MIME certificates are quite different from TLS certificates,
and applying the BR rules to them might not be appropriate. I expect this
to ultimately be sorted out by the CAB Forum's future S/MIME Working Group,
but in the interim we still need some reasonable Mozilla policy. This leads
me to conclude that the best solution might be to do as Kathleen suggested
and reinstate the old Mozilla revocation requirements (prior to referencing
the BRs) to apply to S/MIME certificates:
https://github.com/mozilla/pkipolicy/blob/2.4.1/rootstore/policy.md#6-revocation
The biggest change here from my earlier proposal would be that no
revocation timeline would be specified.

I also suggest that we add a requirement for both TLS and S/MIME
certificates that states the CA must revoke a certificate that "does not
comply with the version of this policy that was in effect at the time it
was issued.". Currently, there is no hard requirement for CAs to revoke
certificates that comply with the BRs but not with our own policy (e.g. use
of the P-521 algorithm [1]).

How do these changes sound to everyone?

- Wayne

[1]
https://groups.google.com/d/msg/mozilla.dev.security.policy/4gs5pKqTeK8/_eJvekr1BgAJ

On Fri, Jun 14, 2019 at 10:43 PM Dimitris Zacharopoulos via
dev-security-policy  wrote:

>
> Dear Wayne,
>
> Please consider the fact that S/MIME is focused on "signature"
> Certificates which has different considerations than "authentication"
> Certificates. The baseline requirements (and their revocation
> requirements) are focused on "authentication" Certificates. I believe
> the revocation policies, at least for the CA Certificates, do not align
> well with S/MIME.
>
> When a piece of data is "signed" (such as an e-mail), Relying Parties
> need to be able to verify the status of the signing Certificate _when
> the signature was created_. If the Issuing CA is revoked, it is no
> longer able to provide status information for that Certificate. If we
> think about the serial number issue, if a CA had to be revoked, status
> information for its issued Certificates would discontinue leading
> Relying Parties to have difficulties validating the existing signed
> e-mails that were valid when signed.
>
> This might be something to consider more carefully.
>
>
> Thank you,
> Dimitris.
>
>
> On 15/5/2019 3:25 π.μ., Wayne Thayer via dev-security-policy wrote:
> > On Tue, May 14, 2019 at 11:21 AM Kathleen Wilson via dev-security-policy
> <
> > dev-security-policy@lists.mozilla.org> wrote:
> >
> >> On 5/10/19 5:46 PM, Wayne Thayer wrote:
> >>> I've attempted to update section 6 to incorporate revocation
> requirements
> >>> for S/MIME certificates:
> >>>
> >>>
> >>
> https://github.com/mozilla/pkipolicy/commit/15ad5b9180903b92b8f638c219740c0fb6ba0637
> >>> Note: since much of this language is copied directly from the BRs, if
> we
> >>> decide to adopt it, the policy will also need to comply with the
> Creative
> >>> Commons Attribution 4.0 International license used by the BRs.
> >>>
> >>> I will greatly appreciate everyone's review and comments on this
> proposed
> >>> change.
> >>
> >> The proposed changes look OK to me.
> >>
> >> But I would also be fine with the new section 6.2 regarding revocation
> >> of S/MIME certs just re-using the revocation text that we used to have
> >> in our policy (which had been removed in an effort to remove redundancy
> >> with the BRs).
> >>
> >>
> >>
> https://github.com/mozilla/pkipolicy/blob/2.4.1/rootstore/policy.md#6-revocation
> >>
> >>
> > The 'reasons for revocation' from the old policy are very close to the BR
> > language I proposed. The main difference in my proposal is the inclusion
> of
> > deadlines by which certificates must be revoked (same as in the BRs).
> While
> > the BR deadlines have sometimes been challenging, I do feel that we're
> > better off to have them as our standard and handle exceptions as
> incidents,
> > so my preference is to stick with my proposal.
> > ___
> > 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
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: [FORGED] Re: Website owner survey data on identity, browser UIs, and the EV UI

[Peter Gutmann via dev-security-policy]

Paul Walsh ​ writes:

>I would like to see one research paper published by one browser vendor to
>show that website identity visual indicators can not work.

Uhhh... are you serious with that request?  You're asking for a study from a
browser vendor, a group who in any case don't publish research papers but
write browsers, indicating that their own UI doesn't work?

>I’d love you to show me the type of research I’ve asked for. I’m open to
>learning more. I’m not new to this game. I worked on integrated browsers and
>search engines in the 90’s at AOL.

If it's OK to cite peer-reviewed papers from universities published at
conferences and in journals, I can dig up a few of those.

Peter.


___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Website owner survey data on identity, browser UIs, and the EV UI

[Paul Walsh via dev-security-policy]

> On Oct 2, 2019, at 3:41 PM, Ronald Crane via dev-security-policy 
>  wrote:
> 
> On 10/2/2019 3:00 PM, Paul Walsh via dev-security-policy wrote:
>> On Oct 2, 2019, at 2:52 PM, Ronald Crane via dev-security-policy 
>>  wrote:
> [snip]
>>> Some other changes that might help reduce phishing are:
>>> 1. Site owners should avoid using multiple domains, because using them 
>>> habituates users to the idea that there are several valid domains for a 
>>> given entity. Once users have that idea, phishers are most of the way to 
>>> success. Some of the biggest names in, e.g., brokerage services are 
>>> offenders on this front.
>> [PW] Companies like Google own so many domains and sub-domains that it’s 
>> difficult to stay ahead of them. I think this is an unrealistic expectation. 
>> So if other browser vendors have the same opinion, they should look inward.
> It is not unrealistic to expect, e.g., Blahblah Investments, SIPC, to use 
> only "www.blahblahinvestments.com" for everything related to its retail 
> investment services. It *is* unreasonable to habituate users to bad practices.

I agree. 

>>> 2. Site owners should not use URL-shortening services, for the same reason 
>>> as (1).
>> Site owners using shortened URLs isn’t the problem in my opinion. Even if 
>> shortened URLs went away, phishing wouldn’t stop. Unless you have research 
>> to provides more insight?
> Where did I say that phishing would "stop" if URL shortening services 
> disappeared? I said avoiding them would be helpful, since it would reinforce 
> the idea that there is one correct domain per entity, or at least per entity 
> service. Probably all the entity services should be subdomains of the one 
> correct domain, but alas it will take a sustained security campaign and a 
> decade to make a dent in that problem.

I agree. I said, if they disappeared it wouldn’t stop phishing. So it’s still a 
problem. I wanted to use an extreme example to demonstrate a point. 


>>> 3. Site owners should not use QR codes, since fake ones are perfect for 
>>> phishing.
>> Same as above. You don’t need to mask URLs to have a successful phishing 
>> campaign.
> No, you don't "need" to do it. It is, however, a very useful weapon in 
> phishers' quivers.

I agree.

>> sɑlesforce[.com] is available for purchase right now.
> 
> I was going to suggest banning non-Latin-glyph domains, since they are yet 
> another useful phishing weapon. FF converts all such domains into Punycode 
> when typed or pasted into the address bar, though the conversion is displayed 
> below the address bar, not in it. So your example becomes 
> "http://xn--slesforce-51d.com/";.

Just providing an example of a URL that uses .com. I can provide more without 
using special characters to demonstrate the same point. 



___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: [FORGED] Re: Website owner survey data on identity, browser UIs, and the EV UI

[Paul Walsh via dev-security-policy]

> On Oct 2, 2019, at 3:27 PM, Peter Gutmann via dev-security-policy 
>  wrote:
> 
> Ronald Crane via dev-security-policy  
> writes:
> 
>> "Virtually impossible"? "Anyone"? Really? Those are big claims that need real
>> data.
> 
> How many references to research papers would you like?  Would a dozen do, or
> do you want two dozen?

I would like to see one research paper published by one browser vendor to show 
that website identity visual indicators can not work. 

I’m not asking for an individual who tricked the system to get an EV cert - 
that doesn’t prove anything in relation to visual indicators and the 
effectiveness of well designed UI. It just proves that a specific process of 
getting verified can be improved. 

> 
> (This has been researched to death, it's not rocket science, given a bit of
> time you can dig up vast numbers of references.  The only reason I haven't do
> it for this post is that I get the feeling I'd be wasting said time doing so).

I’ve been working on URL classification since I co-instigated the W3C Standard 
in 2004. Here’s a link to where you can see one of the first browser add-ons we 
built with visual indicators for more context around URLs 
https://www.w3.org/2001/sw/sweo/public/UseCases/Segala/ 
 Segala was the first 
company I founded. 

I’d love you to show me the type of research I’ve asked for. I’m open to 
learning more. I’m not new to this game. I worked on integrated browsers and 
search engines in the 90’s at AOL. 

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Website owner survey data on identity, browser UIs, and the EV UI

[Paul Walsh via dev-security-policy]

> On Oct 2, 2019, at 3:20 PM, Kurt Roeckx  wrote:
> 
> On Wed, Oct 02, 2019 at 03:17:31PM -0700, Paul Walsh wrote:
 In separate research, CAs have shown data to demonstrate that website 
 owners want to have their identity verified. 
>>> 
>>> They have not. In fact, I would say that most website owners are perfectly
>>> happy with DV certificates.
>> 
>> What’s your source of data to substantiate what you “would say”? We need to 
>> start talking about facts and data.
> 
> How many DV, OV and EV certificates are there? I think it's rather
> clear what most website owners use.

Let’s try this another way. 

If there was a well implemented visual indicator that users relied on for 
trust, and ID verification was low cost, fast and accessible, more website 
owners would be more likely to want that visual indicator - especially if their 
customers asked them why they didn’t have it.

We saw this from our research - crypto exchanges and wallets were being 
requested by their customers to seek verification. It can work. 

> 
> 
> Kurt
> 

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Website owner survey data on identity, browser UIs, and the EV UI

[Ronald Crane via dev-security-policy]

On 10/2/2019 3:00 PM, Paul Walsh via dev-security-policy wrote:

On Oct 2, 2019, at 2:52 PM, Ronald Crane via dev-security-policy 
 wrote:

[snip]

Some other changes that might help reduce phishing are:
1. Site owners should avoid using multiple domains, because using them 
habituates users to the idea that there are several valid domains for a given 
entity. Once users have that idea, phishers are most of the way to success. 
Some of the biggest names in, e.g., brokerage services are offenders on this 
front.

[PW] Companies like Google own so many domains and sub-domains that it’s 
difficult to stay ahead of them. I think this is an unrealistic expectation. So 
if other browser vendors have the same opinion, they should look inward.
It is not unrealistic to expect, e.g., Blahblah Investments, SIPC, to 
use only "www.blahblahinvestments.com" for everything related to its 
retail investment services. It *is* unreasonable to habituate users to 
bad practices.

2. Site owners should not use URL-shortening services, for the same reason as 
(1).

Site owners using shortened URLs isn’t the problem in my opinion. Even if 
shortened URLs went away, phishing wouldn’t stop. Unless you have research to 
provides more insight?
Where did I say that phishing would "stop" if URL shortening services 
disappeared? I said avoiding them would be helpful, since it would 
reinforce the idea that there is one correct domain per entity, or at 
least per entity service. Probably all the entity services should be 
subdomains of the one correct domain, but alas it will take a sustained 
security campaign and a decade to make a dent in that problem.

3. Site owners should not use QR codes, since fake ones are perfect for 
phishing.

Same as above. You don’t need to mask URLs to have a successful phishing 
campaign.
No, you don't "need" to do it. It is, however, a very useful weapon in 
phishers' quivers.

sɑlesforce[.com] is available for purchase right now.


I was going to suggest banning non-Latin-glyph domains, since they are 
yet another useful phishing weapon. FF converts all such domains into 
Punycode when typed or pasted into the address bar, though the 
conversion is displayed below the address bar, not in it. So your 
example becomes "http://xn--slesforce-51d.com/";.





4. Browser publishers should petition ICANN to revoke most of the gTLDs it has 
approved, since they provide fertile ground for phishing.

Petitioning them won’t work. gTLDs are here to stay, even if we dislike them. 
Also, most phishing sites use .com and other well known TLDs. I’m not saying 
gTLDs aren’t used, they are. But they’re not needed.
Of course they're not "needed" for phishing. They are, however, useful 
for phishing.

So, bringing it back to Mozilla. I’d still love to see recent research/data to 
back up Mozilla’s decision to remove identity UI in Firefox. By promoting the 
padlock without education about phishing, browser vendors are actually making 
the web more dangerous.


I also would like to see more research.

-R


___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Website owner survey data on identity, browser UIs, and the EV UI

[Paul Walsh via dev-security-policy]

> On Oct 2, 2019, at 3:18 PM, Ronald Crane via dev-security-policy 
>  wrote:
> 
> 
> On 10/2/2019 2:47 PM, Paul Walsh via dev-security-policy wrote:
>> On Oct 2, 2019, at 1:16 PM, Ronald Crane via dev-security-policy 
>>  wrote:
>>> On 10/1/2019 6:56 PM, Paul Walsh via dev-security-policy wrote:
 New tools such as Modlishka now automate phishing attacks, making it 
 virtually impossible for any browser or security solution to detect -  
 bypassing 2FA. Google has admitted that it’s unable to detect these 
 phishing scams as they use a phishing domain but instead of a fake 
 website, they use the legitimate website to steal credentials, including 
 2FA. This is why Google banned its users from signing into its own 
 websites via mobile apps with a WebView. If Google can prevent these 
 attacks, Mozilla can’t.
>>> I understand that Modlishka emplaces the phishing site as a MITM. This is 
>>> yet another reason for browser publishers to help train their users to use 
>>> only authentic domain names, and also to up their game on detecting and 
>>> banning phishing domains. I don't think it says much about the value, or 
>>> lack thereof, of EV certs. As has been cited repeatedly in this thread, 
>>> most phishing sites don't even bother to use SSL, indicating that most 
>>> users who can be phished aren't verifying the correct domain.
>> Ronald - it’s virtually impossible for anyone to spot well designed phishing 
>> attacks. Teaching people to check the URL doesn’t work - I can catch out 99% 
>> with a single test, every time.
> 
> "Virtually impossible"? "Anyone"? Really? Those are big claims that need real 
> data. I'm pretty sure I haven't been phished yet.

Yes :)

I have results from 1,845 people so far. I published the test on Twitter, 
inside our Telegram group and presented it many times at many blockchain 
conferences around the world. Only 4 people got it right - and I also put it in 
front of great security professionals. My point is that it’s virtually 
impossible to spot some phishing scams for almost everyone. I’ve seen some top 
social engineers own up to falling for a phishing test at work on Twitter - and 
this is what they do for a living. It’s not a measurement of experience or 
expertise. 

Here’s one test https://twitter.com/Paul__Walsh/status/1174359874932621316?s=20

> 
> In any case, have we ever really tried to teach users to use the correct 
> domain? As I noted in a recent response, many site owners do things -- such 
> as using multiple domains for a single entity, using URL-shortening services, 
> using QR codes, etc. -- that habituate users to the idea that there's more 
> than one correct domain, and/or that they can get it from untrustworthy 
> sources. Once they have that idea, phishing is easy.

This won’t resolve the problem unfortunately. Companies that use few domains 
are high profile targets. 

> 
>> It’s the solution if users had a reliable way to check website identity as 
>> I’ve explained
> And EV certs do this how? Please address https://stripe.ian.sh .

I already addressed this by asking for a single instance of where an attacker 
used an EV certificate. I provide quite a lot of text around this point - 
pointing out that just because you can prove something can be done, doesn’t 
mean it will be. No security solution on the market is 100%. No company is 
hack-proof. Threat actors will only spend time, energy and cost if it’s worth 
it. 

From a security POV, the bar to attaining an EV cert is too high for it to be a 
real threat. They have to setup a real company and it can only be used once. So 
when the cert is revoked that’s the end of it. But, the process could be 
improved.

Back to my question, can you provide examples of attacks that used an EV cert?

I’m not here to defend EV certs or CAs. I’m here to ask that you stop and 
rethink your decision to remove UI for website identity. This isn’t to say that 
we can’t rethink the CA model and tech. From what I can see, browser vendors 
are railroading everyone, including CAs. There’s no collaboration here. Just a 
few people who *think* they know what’s best. I see no evidence to substantive 
any decisions. 


>> Perhaps you can comment on my data about users who do rely on a new visual 
>> indicator and the success that has seen?
> Please post a link to a paper describing it, including the methodology you 
> used.

I’ve already published the methodology used on a thread in this forum with all 
the data collected in relation to this point. I just haven’t taken the time to 
PDF it and stick it on a website. It will however, be published on a website in 
the form of a guest post - later this week. 


>> Any opinion I’ve read is just that, opinion, with zero data/evidence to 
>> substantiate anything cited. The closest I’ve seen is exceptionally old 
>> research that’s more than 10 years old.
> Um, 
> https://casecurity.org/wp-content/uploads/2017/09/Incidence-of-Phishing-Among-D

Re: [FORGED] Re: Website owner survey data on identity, browser UIs, and the EV UI

[Peter Gutmann via dev-security-policy]

Ronald Crane via dev-security-policy  
writes:

>"Virtually impossible"? "Anyone"? Really? Those are big claims that need real
>data.

How many references to research papers would you like?  Would a dozen do, or
do you want two dozen?

(This has been researched to death, it's not rocket science, given a bit of
time you can dig up vast numbers of references.  The only reason I haven't do
it for this post is that I get the feeling I'd be wasting said time doing so).

>I'm pretty sure I haven't been phished yet.

How would you know?  And how does this help the other 7.53 billion people who
will be targets for phishers?

>In any case, have we ever really tried to teach users to use the correct
>domain?

Yes, we've tried that.  And that.  And that too.  And the other thing.  Yes,
that too.  

None of them work.

Peter.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Website owner survey data on identity, browser UIs, and the EV UI

[Kurt Roeckx via dev-security-policy]

On Wed, Oct 02, 2019 at 03:17:31PM -0700, Paul Walsh wrote:
> >> In separate research, CAs have shown data to demonstrate that website 
> >> owners want to have their identity verified. 
> > 
> > They have not. In fact, I would say that most website owners are perfectly
> > happy with DV certificates.
> 
> What’s your source of data to substantiate what you “would say”? We need to 
> start talking about facts and data.

How many DV, OV and EV certificates are there? I think it's rather
clear what most website owners use.


Kurt

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Website owner survey data on identity, browser UIs, and the EV UI

[Paul Walsh via dev-security-policy]

> On Oct 2, 2019, at 3:11 PM, Kurt Roeckx  wrote:
> 
> On Wed, Oct 02, 2019 at 02:48:56PM -0700, Paul Walsh wrote:
>> On Oct 2, 2019, at 12:52 AM, Kurt Roeckx via dev-security-policy 
>>  wrote:
>>> 
>>> On 2019-10-02 09:20, Kurt Roeckx wrote:
 On 2019-10-02 02:39, Paul Walsh wrote:
> 
> According to Ellis, the goal for a customer survey is to get feedback 
> from people who had recently experienced "real usage" of the product. The 
> key question in the survey for these people according to Ellis, is:
> 
> "How would you feel if you could no longer rely on MetaCert's green 
> shield?
 No, the question he would be asking is:
 "How would you feel if you could no longer use MetaCert's EV certificates?"
>>> 
>>> And it's probably better to even turn that into:
>>> How would you feel if you could no longer buy MetaCert's EV certificates?
>> 
>> [PW] MetaCert is not a CA. We don’t have any relationships with any CAs 
>> either. 
> 
> Well, for what Ellis is talking about, it's asking about a
> product, and how the user would feel if that product can't be used
> anymore.
> 
> That just shows that there are users that want your product, not
> that everybody wants it.

I’m not sure I understand the point you would like me to take from this. Not 
every person in the world wants to use Firefox. That doesn’t stop Mozilla from 
building browser software. No company in the world tries to sell to everyone. 
If most people want browser UI for website identity, are you saying we 
shouldn’t give it to them because everyone didn’t proactively say they wanted 
it? 


> 
>> Our research was aimed at end-users, as I said previously. We have proof 
>> that users want to use a visual indicator for trust. And we also 
>> demonstrated that it’s possible to protect users with well designed browser 
>> UI/UX.
> 
> Sure, there will be users that want that, nobody is denying that.

Great. Perhaps we can talk about the things that we agree on. 

> 
>> In separate research, CAs have shown data to demonstrate that website owners 
>> want to have their identity verified. 
> 
> They have not. In fact, I would say that most website owners are perfectly
> happy with DV certificates.

What’s your source of data to substantiate what you “would say”? We need to 
start talking about facts and data.

> 
> 
> Kurt
> 

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Next Root Store Policy Update

[Wayne Thayer via dev-security-policy]

Over the past 3 months, a number of other projects distracted me from this
work. Now I'd like to focus on finishing these updates to our Root Store
policy. There are roughly 6 issues remaining to be discussed, and I will,
as always, greatly appreciate everyone's input on them. I'll be sending out
individual emails on each issue.

Meanwhile, you can view a redline of the changes we previously agreed on:
https://github.com/mozilla/pkipolicy/compare/master...2.7

- Wayne

On Wed, Mar 27, 2019 at 4:12 PM Wayne Thayer  wrote:

> I've added a few more issues that were recently created to the list for
> 2.7: https://github.com/mozilla/pkipolicy/labels/2.7
>
> 176 - Clarify revocation requirements for S/MIME certs
> 175 - Forbidden Practices wiki page says email validation cannot be
> delegated to 3rd parties
>
> I plan to begin posting issues for discussion shortly.
>
>
> On Fri, Mar 8, 2019 at 2:12 PM Wayne Thayer  wrote:
>
>> Later this month, I would like to begin discussing a number of proposed
>> changes to the Mozilla Root Store policy [1]. I have reviewed the list of
>> issues on GitHub and labeled the ones that I recommend discussing:
>> https://github.com/mozilla/pkipolicy/labels/2.7 They are:
>>
>> 173 - Strengthen requirement for newly included roots to meet all current
>> requirements
>> 172 - Update section 5.3 to include Policy Certification Authorities as
>> an exception to the mandatory EKU inclusion requirement
>> 171 - Require binding of CA certificates to CP/CPS
>> 170 - Clarify Section 5.1 about allowed ECDSA curve-hash pair
>> 169, 140 - Extend Section 8 to also encompass subordinate CAs
>> 168, 161, 158  - Require Incident Reports, move practices into policy
>> 163 - Require EKUs in end-entity certificates (S/MIME)
>> 162 - Require disclosure of CA software vendor/version in incident report
>> 159 - Clarify section 5.3.1 Technically Constrained
>> 152 - Add EV audit exception for policy constrained intermediates
>> 151 - Change PITRA to Point-in-Time assessment in section 8
>>
>> I will appreciate any feedback on the proposed list of issues to discuss.
>>
>> I do recognize that the current DarkMatter discussions could result in
>> the need to add some additional items to this list.
>>
>> I have created a new branch for drafting these changes [1] and made one
>> commit that adds a bullet to the BR Conformance section informing the
>> reader that Mozilla policy has a more restrictive list of approved
>> algorithms [3]
>>
>> As we've done in the past, I plan to post individual issues for
>> discussion in small batches over the next few months, with the goal of
>> finalizing version 2.7 by June.
>>
>> - Wayne
>>
>> [1]
>> https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/
>> [2] https://github.com/mozilla/pkipolicy/blob/2.7/rootstore/policy.md
>> [3] https://github.com/mozilla/pkipolicy/issues/167
>>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Website owner survey data on identity, browser UIs, and the EV UI

[Ronald Crane via dev-security-policy]

On 10/2/2019 2:47 PM, Paul Walsh via dev-security-policy wrote:

On Oct 2, 2019, at 1:16 PM, Ronald Crane via dev-security-policy 
 wrote:

On 10/1/2019 6:56 PM, Paul Walsh via dev-security-policy wrote:

New tools such as Modlishka now automate phishing attacks, making it virtually 
impossible for any browser or security solution to detect -  bypassing 2FA. 
Google has admitted that it’s unable to detect these phishing scams as they use 
a phishing domain but instead of a fake website, they use the legitimate 
website to steal credentials, including 2FA. This is why Google banned its 
users from signing into its own websites via mobile apps with a WebView. If 
Google can prevent these attacks, Mozilla can’t.

I understand that Modlishka emplaces the phishing site as a MITM. This is yet 
another reason for browser publishers to help train their users to use only 
authentic domain names, and also to up their game on detecting and banning 
phishing domains. I don't think it says much about the value, or lack thereof, 
of EV certs. As has been cited repeatedly in this thread, most phishing sites 
don't even bother to use SSL, indicating that most users who can be phished 
aren't verifying the correct domain.

Ronald - it’s virtually impossible for anyone to spot well designed phishing 
attacks. Teaching people to check the URL doesn’t work - I can catch out 99% 
with a single test, every time.


"Virtually impossible"? "Anyone"? Really? Those are big claims that need 
real data. I'm pretty sure I haven't been phished yet.


In any case, have we ever really tried to teach users to use the correct 
domain? As I noted in a recent response, many site owners do things -- 
such as using multiple domains for a single entity, using URL-shortening 
services, using QR codes, etc. -- that habituate users to the idea that 
there's more than one correct domain, and/or that they can get it from 
untrustworthy sources. Once they have that idea, phishing is easy.



It’s the solution if users had a reliable way to check website identity as I’ve 
explained

And EV certs do this how? Please address https://stripe.ian.sh .

Perhaps you can comment on my data about users who do rely on a new visual 
indicator and the success that has seen?
Please post a link to a paper describing it, including the methodology 
you used.

Any opinion I’ve read is just that, opinion, with zero data/evidence to 
substantiate anything cited. The closest I’ve seen is exceptionally old 
research that’s more than 10 years old.
Um, 
https://casecurity.org/wp-content/uploads/2017/09/Incidence-of-Phishing-Among-DV-OV-and-EV-Websites-9-13-2017-short-vepdf 
(see table on p.2) is from 2017. That is not "more than 10 years old" 
nor just "opinion, with zero data/evidence to substantiate anything 
cited". Let's debate the merits with more light and less heat.

According to Webroot 93% of all new phishing sites have an SSL certificate. 
According to MetaCert it’s more than 96%. This is increasing as Let’s Encrypt 
issues more free certs.


Please link the surveys you cite. In any case, the Lets Encrypt issue 
*does* appear to be a problem, as you noted elsewhere. Does Google Safe 
Browsing automatically add these (fake Paypal and similar) domains to 
its probable-phish list? They should.



If you want to talk about certificate issuance that’s broken, look at how Let’s 
Encrypt has issued more than 14,000 DV certs to domains with PayPal in it.


I'm agnostic on the EV UI, but have seen little evidence that it's 
useful. Maybe your paper will help convince me otherwise.


-R


___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Website owner survey data on identity, browser UIs, and the EV UI

[Kurt Roeckx via dev-security-policy]

On Wed, Oct 02, 2019 at 02:48:56PM -0700, Paul Walsh wrote:
> On Oct 2, 2019, at 12:52 AM, Kurt Roeckx via dev-security-policy 
>  wrote:
> > 
> > On 2019-10-02 09:20, Kurt Roeckx wrote:
> >> On 2019-10-02 02:39, Paul Walsh wrote:
> >>> 
> >>> According to Ellis, the goal for a customer survey is to get feedback 
> >>> from people who had recently experienced "real usage" of the product. The 
> >>> key question in the survey for these people according to Ellis, is:
> >>> 
> >>> "How would you feel if you could no longer rely on MetaCert's green 
> >>> shield?
> >> No, the question he would be asking is:
> >> "How would you feel if you could no longer use MetaCert's EV certificates?"
> > 
> > And it's probably better to even turn that into:
> > How would you feel if you could no longer buy MetaCert's EV certificates?
> 
> [PW] MetaCert is not a CA. We don’t have any relationships with any CAs 
> either. 

Well, for what Ellis is talking about, it's asking about a
product, and how the user would feel if that product can't be used
anymore.

That just shows that there are users that want your product, not
that everybody wants it.

> Our research was aimed at end-users, as I said previously. We have proof that 
> users want to use a visual indicator for trust. And we also demonstrated that 
> it’s possible to protect users with well designed browser UI/UX.

Sure, there will be users that want that, nobody is denying that.

> In separate research, CAs have shown data to demonstrate that website owners 
> want to have their identity verified. 

They have not. In fact, I would say that most website owners are perfectly
happy with DV certificates.


Kurt

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Website owner survey data on identity, browser UIs, and the EV UI

[Paul Walsh via dev-security-policy]

On Oct 2, 2019, at 2:52 PM, Ronald Crane via dev-security-policy 
 wrote:
> 
> On 10/2/2019 1:16 PM, Ronald Crane via dev-security-policy wrote:
>> On 10/1/2019 6:56 PM, Paul Walsh via dev-security-policy wrote:
>>> New tools such as Modlishka now automate phishing attacks, making it 
>>> virtually impossible for any browser or security solution to detect -  
>>> bypassing 2FA. Google has admitted that it’s unable to detect these 
>>> phishing scams as they use a phishing domain but instead of a fake website, 
>>> they use the legitimate website to steal credentials, including 2FA. This 
>>> is why Google banned its users from signing into its own websites via 
>>> mobile apps with a WebView. If Google can prevent these attacks, Mozilla 
>>> can’t.
>> 
>> I understand that Modlishka emplaces the phishing site as a MITM. This is 
>> yet another reason for browser publishers to help train their users to use 
>> only authentic domain names, and also to up their game on detecting and 
>> banning phishing domains. I don't think it says much about the value, or 
>> lack thereof, of EV certs. As has been cited repeatedly in this thread, most 
>> phishing sites don't even bother to use SSL, indicating that most users who 
>> can be phished aren't verifying the correct domain.
>> 
>> -R
>> 
> Some other changes that might help reduce phishing are:
> 
> 1. Site owners should avoid using multiple domains, because using them 
> habituates users to the idea that there are several valid domains for a given 
> entity. Once users have that idea, phishers are most of the way to success. 
> Some of the biggest names in, e.g., brokerage services are offenders on this 
> front.

[PW] Companies like Google own so many domains and sub-domains that it’s 
difficult to stay ahead of them. I think this is an unrealistic expectation. So 
if other browser vendors have the same opinion, they should look inward.

> 
> 2. Site owners should not use URL-shortening services, for the same reason as 
> (1).

Site owners using shortened URLs isn’t the problem in my opinion. Even if 
shortened URLs went away, phishing wouldn’t stop. Unless you have research to 
provides more insight?

> 
> 3. Site owners should not use QR codes, since fake ones are perfect for 
> phishing.

Same as above. You don’t need to mask URLs to have a successful phishing 
campaign. sɑlesforce[.com] is available for purchase right now. 

> 
> 4. Browser publishers should petition ICANN to revoke most of the gTLDs it 
> has approved, since they provide fertile ground for phishing.

Petitioning them won’t work. gTLDs are here to stay, even if we dislike them. 
Also, most phishing sites use .com and other well known TLDs. I’m not saying 
gTLDs aren’t used, they are. But they’re not needed. 

So, bringing it back to Mozilla. I’d still love to see recent research/data to 
back up Mozilla’s decision to remove identity UI in Firefox. By promoting the 
padlock without education about phishing, browser vendors are actually making 
the web more dangerous. 

- Paul


> There appear to be ~1900 such gTLDs [1]. I doubt that even the largest 
> corporations have registered their base domains under every such gTLD. Where 
> does "www.microsoft.somenamethatICANNmightaddasagTLD" go? I sure don't know 
> where "www.zippenhop.[pick a non-.com gTLD] goes.
> 
> [1]  Search for "delegated" status at 
> https://newgtlds.icann.org/en/program-status/delegated-strings .
> ___
> 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

Re: Website owner survey data on identity, browser UIs, and the EV UI

[Ronald Crane via dev-security-policy]

On 10/2/2019 1:16 PM, Ronald Crane via dev-security-policy wrote:

On 10/1/2019 6:56 PM, Paul Walsh via dev-security-policy wrote:
New tools such as Modlishka now automate phishing attacks, making it 
virtually impossible for any browser or security solution to detect - 
 bypassing 2FA. Google has admitted that it’s unable to detect these 
phishing scams as they use a phishing domain but instead of a fake 
website, they use the legitimate website to steal credentials, 
including 2FA. This is why Google banned its users from signing into 
its own websites via mobile apps with a WebView. If Google can 
prevent these attacks, Mozilla can’t.


I understand that Modlishka emplaces the phishing site as a MITM. This 
is yet another reason for browser publishers to help train their users 
to use only authentic domain names, and also to up their game on 
detecting and banning phishing domains. I don't think it says much 
about the value, or lack thereof, of EV certs. As has been cited 
repeatedly in this thread, most phishing sites don't even bother to 
use SSL, indicating that most users who can be phished aren't 
verifying the correct domain.


-R


Some other changes that might help reduce phishing are:

1. Site owners should avoid using multiple domains, because using them 
habituates users to the idea that there are several valid domains for a 
given entity. Once users have that idea, phishers are most of the way to 
success. Some of the biggest names in, e.g., brokerage services are 
offenders on this front.


2. Site owners should not use URL-shortening services, for the same 
reason as (1).


3. Site owners should not use QR codes, since fake ones are perfect for 
phishing.


4. Browser publishers should petition ICANN to revoke most of the gTLDs 
it has approved, since they provide fertile ground for phishing. There 
appear to be ~1900 such gTLDs [1]. I doubt that even the largest 
corporations have registered their base domains under every such gTLD. 
Where does "www.microsoft.somenamethatICANNmightaddasagTLD" go? I sure 
don't know where "www.zippenhop.[pick a non-.com gTLD] goes.


[1]  Search for "delegated" status at 
https://newgtlds.icann.org/en/program-status/delegated-strings .

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Website owner survey data on identity, browser UIs, and the EV UI

[Paul Walsh via dev-security-policy]

On Oct 2, 2019, at 12:52 AM, Kurt Roeckx via dev-security-policy 
 wrote:
> 
> On 2019-10-02 09:20, Kurt Roeckx wrote:
>> On 2019-10-02 02:39, Paul Walsh wrote:
>>> 
>>> According to Ellis, the goal for a customer survey is to get feedback from 
>>> people who had recently experienced "real usage" of the product. The key 
>>> question in the survey for these people according to Ellis, is:
>>> 
>>> "How would you feel if you could no longer rely on MetaCert's green shield?
>> No, the question he would be asking is:
>> "How would you feel if you could no longer use MetaCert's EV certificates?"
> 
> And it's probably better to even turn that into:
> How would you feel if you could no longer buy MetaCert's EV certificates?

[PW] MetaCert is not a CA. We don’t have any relationships with any CAs either. 

We do not sell verification services to website owners. We’re doing 
verification at scale, for free. We generate revenue on the other end - selling 
security services as well as API access to the data. Trying to protect users 
from threats is clearly not working. So they need to know what’s verified as 
not-unsafe. I’m afraid to use the word safe too often because it’s vague.

Our research was aimed at end-users, as I said previously. We have proof that 
users want to use a visual indicator for trust. And we also demonstrated that 
it’s possible to protect users with well designed browser UI/UX.

In separate research, CAs have shown data to demonstrate that website owners 
want to have their identity verified. 

I haven’t seen any research / data to show why Mozilla should remove UI instead 
of improving it. 

FWIW my COO and engineers built the official Firefox add-ons for digg, 
Delicious, Yahoo!, eBay, PayPal, Google and Microsoft. And they built and 
maintained spreadfirefox .com - so we have a lot of experience working "with” 
Mozilla. We're blown away by the team’s decision to remove UI without any 
research to back up their decisions.

Was there anything you disagreed with in my lengthy responses Kurt? 

Thanks,
Paul




___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Website owner survey data on identity, browser UIs, and the EV UI

[Paul Walsh via dev-security-policy]

On Oct 2, 2019, at 1:16 PM, Ronald Crane via dev-security-policy 
 wrote:
> 
> On 10/1/2019 6:56 PM, Paul Walsh via dev-security-policy wrote:
>> New tools such as Modlishka now automate phishing attacks, making it 
>> virtually impossible for any browser or security solution to detect -  
>> bypassing 2FA. Google has admitted that it’s unable to detect these phishing 
>> scams as they use a phishing domain but instead of a fake website, they use 
>> the legitimate website to steal credentials, including 2FA. This is why 
>> Google banned its users from signing into its own websites via mobile apps 
>> with a WebView. If Google can prevent these attacks, Mozilla can’t.
> 
> I understand that Modlishka emplaces the phishing site as a MITM. This is yet 
> another reason for browser publishers to help train their users to use only 
> authentic domain names, and also to up their game on detecting and banning 
> phishing domains. I don't think it says much about the value, or lack 
> thereof, of EV certs. As has been cited repeatedly in this thread, most 
> phishing sites don't even bother to use SSL, indicating that most users who 
> can be phished aren't verifying the correct domain.

Ronald - it’s virtually impossible for anyone to spot well designed phishing 
attacks. Teaching people to check the URL doesn’t work - I can catch out 99% 
with a single test, every time. It’s the solution if users had a reliable way 
to check website identity as I’ve explained. Almost all breaches start with 
phishing and it’s getting worse. 

Perhaps you can comment on my data about users who do rely on a new visual 
indicator and the success that has seen? 

Any opinion I’ve read is just that, opinion, with zero data/evidence to 
substantiate anything cited. The closest I’ve seen is exceptionally old 
research that’s more than 10 years old.

According to Webroot 93% of all new phishing sites have an SSL certificate. 
According to MetaCert it’s more than 96%. This is increasing as Let’s Encrypt 
issues more free certs. I think people are mixing up spam with phishing. Or 
they’re just guessing based on what they see personally. It’s time to reference 
facts from the security world.

With billions of dollars being invested in cybersecurity and many billions 
spent paying for those services, it’s still technically impossible for any 
company with any solution to detect every new malicious URL - and it will never 
be possible to detect every new dangerous URL. 

So, most attacks start with phishing. Most phishing sites have a padlock. Most 
people trust sites with a padlock. Security companies can’t stop all new 
threats.

What’s the answer? It certainly isn’t removing website identity and promoting 
the padlock.

- Paul

> 
> -R
> 
> 
> ___
> 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

Re: Website owner survey data on identity, browser UIs, and the EV UI

[Ronald Crane via dev-security-policy]

On 10/1/2019 6:56 PM, Paul Walsh via dev-security-policy wrote:

New tools such as Modlishka now automate phishing attacks, making it virtually 
impossible for any browser or security solution to detect -  bypassing 2FA. 
Google has admitted that it’s unable to detect these phishing scams as they use 
a phishing domain but instead of a fake website, they use the legitimate 
website to steal credentials, including 2FA. This is why Google banned its 
users from signing into its own websites via mobile apps with a WebView. If 
Google can prevent these attacks, Mozilla can’t.


I understand that Modlishka emplaces the phishing site as a MITM. This 
is yet another reason for browser publishers to help train their users 
to use only authentic domain names, and also to up their game on 
detecting and banning phishing domains. I don't think it says much about 
the value, or lack thereof, of EV certs. As has been cited repeatedly in 
this thread, most phishing sites don't even bother to use SSL, 
indicating that most users who can be phished aren't verifying the 
correct domain.


-R


___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DigiCert OCSP services returns 1 byte

[Rob Stradling via dev-security-policy]

On 02/10/2019 00:51, Wayne Thayer wrote:
> On Tue, Oct 1, 2019 at 3:34 AM Rob Stradling wrote:
> 
> I propose that you update [4] to say that Mozilla won't treat
> non-compliance with [4] as an "incident" whilst it remains the case
> that the BRs are inconsistent with [4].
> 
> I could simply move [4] to a "recommended practice" (SHOULD) until the 
> ballot comes into force, then move it back to "required". That implies 
> that the bugs which have been opened for this specific issue (responding 
> "unknown" - not to be confused with "returns 1 byte") will be closed as 
> INVALID.
> 
> Are there strong objections to this course of action?

It seems a bit strange to recommend a practice that CAs cannot currently 
adhere to without violating the BRs and some other root programs' 
policies, but at the same time it is helpful to signpost upcoming policy 
changes.

I don't object strongly.

> - Wayne
> 
> [4] 
> https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Precertificates

-- 
Rob Stradling
Senior Research & Development Scientist
Sectigo Limited

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Website owner survey data on identity, browser UIs, and the EV UI

[Kurt Roeckx via dev-security-policy]

On 2019-10-02 09:20, Kurt Roeckx wrote:

On 2019-10-02 02:39, Paul Walsh wrote:


According to Ellis, the goal for a customer survey is to get feedback 
from people who had recently experienced "real usage" of the product. 
The key question in the survey for these people according to Ellis, is:


"How would you feel if you could no longer rely on MetaCert's green 
shield?


No, the question he would be asking is:
"How would you feel if you could no longer use MetaCert's EV certificates?"


And it's probably better to even turn that into:
How would you feel if you could no longer buy MetaCert's EV certificates?


Kurt
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Website owner survey data on identity, browser UIs, and the EV UI

[Kurt Roeckx via dev-security-policy]

On 2019-10-02 02:39, Paul Walsh wrote:


According to Ellis, the goal for a customer survey is to get feedback from people who had 
recently experienced "real usage" of the product. The key question in the 
survey for these people according to Ellis, is:

"How would you feel if you could no longer rely on MetaCert's green shield?


No, the question he would be asking is:
"How would you feel if you could no longer use MetaCert's EV certificates?"

Which is something totally different. It's very important to get the 
question right.



Kurt
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy