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

2019-08-23 Thread Tom Ritter via dev-security-policy
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

2019-08-23 Thread Tom Ritter via dev-security-policy
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

2019-08-15 Thread Tom Ritter via dev-security-policy
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

2019-08-13 Thread Tom Ritter via dev-security-policy
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

2018-10-15 Thread Tom Ritter via dev-security-policy
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

2018-07-27 Thread Tom Ritter via dev-security-policy
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?

2018-02-28 Thread Tom Ritter via dev-security-policy
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

2018-02-28 Thread Tom Ritter via dev-security-policy
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

2017-12-15 Thread Tom Ritter via dev-security-policy
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

2017-06-19 Thread Tom Ritter via dev-security-policy
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