Re: On the value of EV

2017-12-14 Thread Jakob Bohm via dev-security-policy
On 15/12/2017 02:30, Ryan Sleevi wrote: On Thu, Dec 14, 2017 at 5:01 PM Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: On 14/12/2017 00:23, Peter Gutmann wrote: Tim Shirley via dev-security-policy < dev-security-policy@lists.mozilla.org> writes: But

Re: On the value of EV

2017-12-14 Thread Ryan Sleevi via dev-security-policy
On Thu, Dec 14, 2017 at 5:01 PM Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 14/12/2017 00:23, Peter Gutmann wrote: > > Tim Shirley via dev-security-policy < > dev-security-policy@lists.mozilla.org> writes: > > > >> But regardless of which (or neither)

Re: On the value of EV

2017-12-14 Thread Matthew Hardeman via dev-security-policy
That attack was by hacking the target's domain registrar account. Others have done that as well, including against a Brazilian bank. The right attacker would not even need that - they could just hijack traffic headed to the IP address of the real DNS server in question.

Re: On the value of EV

2017-12-14 Thread Matthew Hardeman via dev-security-policy
On Thursday, December 14, 2017 at 5:50:40 PM UTC-6, Matthew Hardeman wrote: > Route hijacking your way to what would appear as a proper domain validation > is practical for even a modestly resourceful adversary. I suspect that the > only reason more spectacular demonstration of certs issuing

Re: On the value of EV

2017-12-14 Thread Matthew Hardeman via dev-security-policy
On Wednesday, December 13, 2017 at 2:46:10 PM UTC-6, Gervase Markham wrote: > My concern with this argument is that it's susceptible to the criticism > that Adam Langley made of revocation checking: > https://www.imperialviolet.org/2012/02/05/crlsets.html > > "So [EV identity is] like a

Re: On the value of EV

2017-12-14 Thread Jakob Bohm via dev-security-policy
On 14/12/2017 00:23, Peter Gutmann wrote: Tim Shirley via dev-security-policy writes: But regardless of which (or neither) is true, the very fact that EV certs are rarely (never?) used on phishing sites There's no need:

Re: On the value of EV

2017-12-14 Thread Jakob Bohm via dev-security-policy
On 13/12/2017 22:40, Matthew Hardeman wrote: On Tuesday, December 12, 2017 at 3:52:40 PM UTC-6, Ryan Sleevi wrote: Yes. This is the foundation and limit of Web Security. https://en.wikipedia.org/wiki/Same-origin_policy This is what is programatically enforced. Anything else either requires

Re: On the value of EV

2017-12-14 Thread Jakob Bohm via dev-security-policy
On 13/12/2017 20:55, Gervase Markham wrote: On 11/12/17 17:00, Ryan Sleevi wrote: Fundamentally, I think this is misleading. It presumes that, upon something bad happening, someone can link it back to that certificate to link it back to that identity. If I was phished, and entered my

Re: On the value of EV

2017-12-14 Thread Jakob Bohm via dev-security-policy
On 14/12/2017 17:51, Peter Bachman wrote: @Jakob I was referring to the classical namespaces which have evolved since the 1980s. The NSF pilot project was based on a now obsolete version of X.500, Quipu, that world rooted with participating county directories. While I managed that part of

Beyond EV: Thoughts on trust and actionable trust signals

2017-12-14 Thread Matthew Hardeman via dev-security-policy
All, Recent events and a body of historical research have of late been causing questions among a great many respected security researchers and browser UI guys about the benefits of browser UI signal for EV certificates. I'd like to start a discussion tangent to that ongoing dialogue. Regardless

Re: On the value of EV

2017-12-14 Thread Peter Bachman via dev-security-policy
@Ryan “Since improving it as a technical means is an effective non-starter (e.g. introducing a new origin for only EV certs), the only fallback is to the cognitive means” EV is a convenient signal. I like it. The problem is the infrastructure that pits the Internet and it’s protocols with

Re: On the value of EV

2017-12-14 Thread Peter Bachman via dev-security-policy
@Jakob I was referring to the classical namespaces which have evolved since the 1980s. The NSF pilot project was based on a now obsolete version of X.500, Quipu, that world rooted with participating county directories. While I managed that part of the capital D Directory it was in the context

Re: Third party use of OneCRL

2017-12-14 Thread J.C. Jones via dev-security-policy
Niklas, That's fine. Thanks for the heads up. Note that the format has a possibility of changing some in 2018, but only in the way of adding fields, not changing existing data. Cheers, J.C. Crypto Engineering On Thu, Dec 14, 2017 at 9:03 AM, niklas.bachmaier--- via dev-security-policy

RE: On the value of EV

2017-12-14 Thread Tim Hollebeek via dev-security-policy
Of course, the main reason Comodo gets sucked into this swamp is the price point. That isn't necessarily their fault. As I've pointed out elsewhere, Comodo has some great ideas about fixing revocation that would go a long way towards solving the "misbehave only after issuance" problem that you

RE: CA generated keys

2017-12-14 Thread Tim Hollebeek via dev-security-policy
Within 24 hours? Once the download completes? It doesn’t seem significantly harder than the other questions we grapple with. I’m sure there are plenty of reasonable solutions. If you want to deliver the private key first, before issuance, that’d be fine too. It just means two downloads

Re: On the value of EV

2017-12-14 Thread Rob Stradling via dev-security-policy
On 14/12/17 00:25, Tim Hollebeek via dev-security-policy wrote: If you look at where the HTTPS phishing certificates come from, they come almost entirely from Let's Encrypt and Comodo. This is perhaps the best argument in favor of distinguishing between CAs that care about phishing and those