Re: Intent to Ship: Move Extended Validation Information out of the URL bar

On Fri, 23 Aug 2019 at 22:53, Daniel Marschall via dev-security-policy wrote: > > Am Freitag, 23. August 2019 00:50:35 UTC+2 schrieb Ronald Crane: > > On 8/22/2019 1:43 PM, kirkhalloregon--- via dev-security-policy wrote: > > > > Whatever the merits of EV (and perhaps there are some -- I'm not >

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

On Fri, 23 Aug 2019 at 05:00, Leo Grove via dev-security-policy wrote: > > On Thursday, August 22, 2019 at 5:50:35 PM UTC-5, Ronald Crane wrote: > > On 8/22/2019 1:43 PM, kirkhalloregon--- via dev-security-policy wrote: > > > I can tell you that anti-phishing services and browser phishing filters

Re: Fwd: Intent to Ship: Move Extended Validation Information out of the URL bar

On Thu, Aug 15, 2019, 7:46 AM Doug Beattie via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Peter, > > Do you have any empirical data to backup the claims that there is no > benefit > from EV certificates? From the reports I've seen, the percentage of > phishing and

Re: Use of Certificate/Public Key Pinning

PKP is a footgun. Deploying it without being prepared for the situations you've described is ill-advised. There's a few options available for organizations who want to pin, in increasing order of sophistication: Enforce Certificate Transparency. You're not locked into any CA or key, only that

Re: Mitigating DNS fragmentation attacks

On Mon, 15 Oct 2018 at 04:51, Paul Wouters via dev-security-policy wrote: > > On Oct 14, 2018, at 21:09, jsha--- via dev-security-policy > wrote: > > > > There’s a paper from 2013 outlining a fragmentation attack on DNS that > > allows an off-path attacker to poison certain DNS results using

Re: Possible violation of CAA by nazwa.pl

Thanks Jakob, I think you summed things up well. -tom On 27 July 2018 at 01:46, Jakob Bohm via dev-security-policy wrote: > On 26/07/2018 23:04, Matthew Hardeman wrote: >> >> On Thu, Jul 26, 2018 at 2:23 PM, Tom Delmas via dev-security-policy < >> dev-security-policy@lists.mozilla.org> wrote:

Re: How do you handle mass revocation requests?

On 28 February 2018 at 11:37, Jeremy Rowley via dev-security-policy wrote: > What kind of transparency would the Mozilla community like around this > issue? There aren't many more facts than I shared above, but there is a lot > of speculation. Let me know

Re: Allowing WebExtensions to Override Certificate Trust Decisions

On 27 February 2018 at 10:23, Alex Gaynor via dev-security-policy wrote: > A reasonable compromise that jumps out to me is allowing extensions to make > an otherwise-secure connection fail, but not allow them to rehabilitate an > insecure connection. This

Re: Investigating validations & issuances - The high value IP space BGP Hijacks on 2017-12-12

This is an extremely good point. I wonder: 1. If Mozilla should ask/require CAs to perform this check. 2. If Mozilla should ask/require CAs to invest in the capability to make this check for future requests in the future (where we would require responses within a certain time period.) -tom On

Re: Private key corresponding to public key in trusted Cisco certificate embedded in executable

On 19 June 2017 at 08:28, Samuel Pinder via dev-security-policy wrote: > Therefore the newly re-issued > certificate *will* end up with it's private key compromised *again*, > no matter how well it may be obfuscated in the application, it is > still against

Re: Mozilla CT Policy

On 4 November 2016 at 07:19, Gervase Markham wrote: > * Are there any CT-related services Mozilla should consider running or > supporting, for the good of the ecosystem? Part answer, part question, but I don't want to forget it: Besides an Auditor, perhaps Mozilla should run a

Re: Mozilla CT Policy

On 4 November 2016 at 07:19, Gervase Markham wrote: > * How do we decide when to un-trust a log? What reasons are valid > reasons for doing so? Do we want different types of distrust for a log? That is, a "We don't trust you at all anymore" distrust vs a "We don't trust

Re: Cerificate Concern about Cloudflare's DNS

On 2 November 2016 at 11:24, Jeremy Rowley wrote: > Revocation support for non-subscribers is sort of implied...sort of: > > Section 4.9.3: > The CA SHALL provide Subscribers, Relying Parties, Application Software > Suppliers, and other third parties with > clear

Re: Cerificate Concern about Cloudflare's DNS

On 2 November 2016 at 09:44, Jakob Bohm wrote: > The only thing that might be a CA / BR issue would be this: There's been (some) mention that even if a user moves off Cloudflare, the CA is not obligated to revoke. I don't agree with that. If a user purchased a domain from

Re: Remediation Plan for WoSign and StartCom

On 19 October 2016 at 02:58, Kurt Roeckx wrote: > On 2016-10-19 01:37, Rob Stradling wrote: >> >> On 18/10/16 23:49, Gervase Markham wrote: >>> >>> On 18/10/16 15:42, Ryan Hurst wrote: I do not understand the desire to require StartCom / WoSign to not utilize their

Mozilla Root Store Elsewhere (Was Re: StartCom & Qihoo Incidents)

On 18 October 2016 at 08:00, Jakob Bohm wrote: > On 18/10/2016 14:35, Gervase Markham wrote: >> >> On 17/10/16 16:35, Jakob Bohm wrote: >>> >>> In the not so distant past, the Mozilla root program was much more >>> useful due to different behavior: >>> >>> 1. Mozilla

Re: Deficiencies in the Web PKI and Mozilla's shepherding thereof, exposed by the WoSign affair

On 4 October 2016 at 06:12, Eric Rescorla wrote: > with the exception of the end-entity > certificate which MUST be first. After testing, this part seems to be the component that stops my idea. I could build paths to arbitrary roots with extra chains contained in the list... but

Re: Deficiencies in the Web PKI and Mozilla's shepherding thereof, exposed by the WoSign affair

On 3 October 2016 at 19:24, Jakob Bohm wrote: > On 03/10/2016 20:41, Kyle Hamilton wrote: >> 2. There is only One Certificate Path that can be proven in TLS, which >> prevents risk management by end-entities. >> > > Are you sure, I thought the standard TLS protocol

Re: StartEncrypt considered harmful today

On 30 June 2016 at 11:10, Peter Kurrasch wrote: > Very interesting. This is exactly the sort of thing I'm concerned about with > respect to Let's Encrypt and ACME. > > I would think that all CA's should issue some sort of statement regarding the > security testing of any

Re: Name-constraining government CAs, or not

Are https://technet.microsoft.com/en-us/library/cc751157.aspx and http://aka.ms/auditreqs the MSFT components (previously?) under NDA? Government CAs must restrict server authentication to .gov domains and may only issues other certificates to the ISO3166 country codes that the country has

Re: Consequences of mis-issuance under CNNIC

On 2 April 2015 at 03:49, c.le...@gmail.com wrote: It would be a golden opportunity for Chinese gov to push for a home-grown browser that is not under the control of western imperialism governments for sure. You mean 360 Browser? Hard to get good statistics it seems, but there are reports