Re: Mississuance of EV Certificates

Am Dienstag, 12. Dezember 2017 18:04:55 UTC+1 schrieb Ryan Sleevi: > On Tue, Dec 12, 2017 at 10:18 AM, Nick Lamb via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > > > The implemented controls detected the misconfiguration within 24 > > > hours. The incorrect

Re: On the value of EV

On 12/12/2017 22:51, Ryan Sleevi wrote: On Tue, Dec 12, 2017 at 3:44 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: What you are writing below, with far too many words is that you think that URLs are the only identities that matter in this world, and

Re: On the value of EV

On Thu, Dec 14, 2017 at 12:21:12AM +, Tim Hollebeek via dev-security-policy wrote: > If you look at the phishing data feeds and correlate them with EV > certificates, > you'll find out that Tim's "speculation" is right. Ladies and gentlemen, this evening, for your viewing pleasure, the

Re: On the value of EV

On Wednesday, December 13, 2017 at 5:08:05 PM UTC-6, Matt Palmer wrote: > > There is a "curatorship", if you will, engaged by the site author. If > > there are sub-resources loaded in, whether they are EV or not, it is the > > root page author's place to "take responsibility" for the contents of

Re: On the value of EV

On Wednesday, December 13, 2017 at 11:09:44 PM UTC-6, Matt Palmer wrote: > > Before that, though, a quick word from our sponsor, Elephant-Be-Gone Amulets > of America, Inc. No elephants in America, you say? See, they're 100% > effective! Get yours today! Of relevance on this point, I'm quite

Re: [FORGED] Re: CA generated keys

Matthew Hardeman via dev-security-policy writes: >In principle, I support Mr. Sleevi's position, practically I lean toward Mr. >Thayer's and Mr. Hollebeek's position. I probably support at least one of those, if I can figure out who's been quoted as

RE: On the value of EV

If you look at the phishing data feeds and correlate them with EV certificates, you'll find out that Tim's "speculation" is right. In my experience, it's generally a bad idea to disagree with Tim Shirley. -Tim > -Original Message- > From: dev-security-policy [mailto:dev-security-policy-

RE: On the value of EV

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 that don't. -Tim > -Original Message- > From:

Re: On the value of EV

Of course not - facetious or not, it’s similarly logically and empirically flawed. On Wed, Dec 13, 2017 at 7:29 PM Tim Hollebeek via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > I don't want to spend too much time digressing into a discussion of the > same > origin

Re: On the value of EV

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

On Wed, Dec 13, 2017 at 6:23 PM, Matthew Hardeman via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > I realize I'm doing a poor job at articulating the profound risks, > perhaps > > because they're best not for e-mail discussions, but these problems are > not > > unique

Re: [FORGED] Re: CA generated keys

On Wednesday, December 13, 2017 at 5:52:16 PM UTC-6, Peter Gutmann wrote: > >Sitting on my desk are not less than 3 reference designs. At least two of > >them have decent hardware RNG capabilities. > > My code runs on a lot (and I mean a *lot*) of embedded, virtually none of > which has

RE: On the value of EV

I don't want to spend too much time digressing into a discussion of the same origin policy as a basis for a reasonable security model for the web, but I hope we could all agree on one thing that was abundantly obvious twenty years ago, and has only become more obvious: Anything originally

RE: CA generated keys

Wayne, For TLS/SSL certificates, I think PKCS #12 delivery of the key and certificate at the same time should be allowed, and I have no problem with a requirement to delete the key after delivery. I also think server side generation along the lines of RFC 7030 (EST) section 4.4 should be

Re: On the value of EV

I have been trying very hard to engage at the substance, but you keep misunderstanding my statements and then answering that strawman. So lets reiterate: - I do not suggest assigning *liability* to the user. - I do suggest *helping the user* make informed decisions of the kind that humans

Re: CA generated keys

On Wed, Dec 13, 2017 at 11:06 AM, Tim Hollebeek via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > Wayne, > > For TLS/SSL certificates, I think PKCS #12 delivery of the key and > certificate > at the same time should be allowed, and I have no problem with a > requirement

RE: CA generated keys

As I’m sure you’re aware, RSA key generation is far, far more reliant on the quality of the random number generation and the prime selection algorithm than TLS is dependent on randomness. In fact it’s the combination of poor randomness with attempts to reduce the cost of RSA key generation

Re: On the value of EV

On Wed, 13 Dec 2017 12:29:40 +0100 Jakob Bohm via dev-security-policy wrote: > What is *programmatically* enforced is too little for human safety. > believing that computers can replace human judgement is a big mistake. > Most of the world knows this.

Re: On the value of EV

So many of the arguments made here, such as this one, as well as the recent demonstrations that helped start this thread, focus on edge cases. And while those are certainly valuable to consider, they obscure the fact that “Green Bar” adds value in the mainstream use cases. If we were talking

Re: CA generated keys

In principle, I support Mr. Sleevi's position, practically I lean toward Mr. Thayer's and Mr. Hollebeek's position. Sitting on my desk are not less than 3 reference designs. At least two of them have decent hardware RNG capabilities. What's noteworthy is the garbage software stack, kernel

Re: CA generated keys

Tim, I appreciate your reply, but that seems to be backwards looking rather than forwards looking. That is, it looks and assumes static-RSA ciphersuites are acceptable, and thus the entropy risk to TLS is mitigated by client-random to this terrible TLS-server devices, and the issue to mitigate is

Re: On the value of EV

On 13/12/2017 18:38, Nick Lamb wrote: On Wed, 13 Dec 2017 12:29:40 +0100 Jakob Bohm via dev-security-policy wrote: What is *programmatically* enforced is too little for human safety. believing that computers can replace human judgement is a big mistake.

Re: On the value of EV

On Wed, Dec 13, 2017 at 1:19 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > I would be sorely disappointed Prepare to be sorely disappointed > and consider it a security bug It is not a bug. It is not part of the security boundary of the Web, thus

Re: On the value of EV

On Wed, Dec 13, 2017 at 12:58 PM, Tim Shirley via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > As an employee of a CA, I’m sure many here will dismiss my point of view > as self-serving. But when I am making trust decisions on the internet, I > absolutely rely on both

Re: CA generated keys

On Wed, Dec 13, 2017 at 1:24 PM, Matthew Hardeman wrote: > As I pointed out, it can be demonstrated that quality ECDHE exchanges can > happen assuming a stateful DPRNG with a decent starting entropy corpus. > Agreed - but that's also true for the devices Tim is mentioning.

Re: On the value of EV

I don’t dispute your claims if the attacker is ‘on the wire’; what I dispute is that that is actually the case most of the time. I’d think a far more common case is one in which I receive an email, purportedly from my bank, but containing a URL that isn’t the one I recognize as my bank’s.

Re: On the value of EV

Right, but both Ian and James' research show that it's an unreliable guarantee for those attacks - you may be relying on it, but it's not safe for it. Further, the costs to support your use case - well-intentioned but perhaps not aligning with the pragmatic reality - affect users who don't do so

Re: CA generated keys

> I appreciate your reply, but that seems to be backwards looking rather than > forwards looking. That is, it looks and assumes static-RSA ciphersuites are > acceptable, and thus the entropy risk to TLS is mitigated by client-random > to this terrible TLS-server devices, and the issue to mitigate

Re: CA generated keys

> As an unrelated but funny aside, I once heard about a expensive, high > assurance device with a embedded bi-stable circuit for producing high quality > hardware random numbers. As part of a rigorous validation and review process > in order to guarantee product quality, the instability was

Re: CA generated keys

On Wednesday, December 13, 2017 at 12:50:38 PM UTC-6, Ryan Sleevi wrote: > On Wed, Dec 13, 2017 at 1:24 PM, Matthew Hardeman > wrote: > > > As I pointed out, it can be demonstrated that quality ECDHE exchanges can > > happen assuming a stateful DPRNG with a decent starting

Re: On the value of EV

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 > credentials, there's no reason to believe I've

RE: CA generated keys

So ECHDE is an interesting point that I had not considered, but as Matt noted, the quality of randomness in the devices does generally improve with time. It tends to be the initial bootstrapping where things go horribly wrong. A couple years ago I was actually on the opposite side of this

Re: On the value of EV

I’m not looking for a guarantee. Nothing is ever going to meet that standard. What I’m looking for is something that’s going to improve my odds. What I see in Ian’s and James’s research is some ways that it’s possible to create confusion, accidentally or deliberately. But I haven’t heard of

Re: On the value of EV

On Monday, December 11, 2017 at 6:01:25 PM UTC-6, Ryan Sleevi wrote: > > Not really - what matters is that the user insists they got had via a > > phishing link or other process - that can certainly be verified after the > > fact > > > No. Why's that? This is how investigations begin. > > -

Re: On the value of EV

On Wed, Dec 13, 2017 at 3:50 PM, Tim Shirley wrote: > I’m not looking for a guarantee. Nothing is ever going to meet that > standard. What I’m looking for is something that’s going to improve my > odds. What I see in Ian’s and James’s research is some ways that it’s >

Re: On the value of EV

On 13/12/17 11:58, Tim Shirley wrote: > So many of the arguments made here, such as this one, as well as the recent > demonstrations that helped start this thread, focus on edge cases. And while > those are certainly valuable to consider, they obscure the fact that “Green > Bar” adds value in

Re: On the value of EV

On Wed, Dec 13, 2017 at 6:29 AM Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> 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

Re: On the value of EV

On Wed, Dec 13, 2017 at 4:14 PM, Matthew Hardeman via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Monday, December 11, 2017 at 6:01:25 PM UTC-6, Ryan Sleevi wrote: > > > > Not really - what matters is that the user insists they got had via a > > > phishing link or

Re: On the value of EV

On Wed, Dec 13, 2017 at 4:28 PM, Matthew Hardeman via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > 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

Re: On the value of EV

On 13/12/2017 14:50, Tim Shirley wrote: I guess I’m also having a hard time appreciating how the presence of this information is a “cost” to users who don’t care about it. For one thing, it’s been there for years in all major browsers, so everyone has at least been conditioned to its

Re: On the value of EV

On Wed, Dec 13, 2017 at 4:40 PM, Matthew Hardeman via dev-security-policy < dev-security-policy@lists.mozilla.org> 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. > > > >

RE: On the value of EV

There are also the really cool hash-based revocation ideas that actually do help even against active attackers on the same network. I really wish those ideas got more serious attention. -Tim > -Original Message- > From: dev-security-policy [mailto:dev-security-policy- >

Re: On the value of EV

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

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 new > technology to technically enforce

Re: On the value of EV

As I understand it, Adam’s argument there was that to get value out of a revoked certificate, you need to be between the user and the web server so you can direct the traffic to your web server, so you’re already in position to also block revocation checks. I don’t think that maps here because

Re: On the value of EV

On Wed, Dec 13, 2017 at 4:46 PM, Tim Shirley via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > As I understand it, Adam’s argument there was that to get value out of a > revoked certificate, you need to be between the user and the web server so > you can direct the traffic

Re: On the value of EV

On Wed, Dec 13, 2017 at 5:19 PM, Tim Hollebeek via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > There are also the really cool hash-based revocation ideas that actually > do help > even against active attackers on the same network. I really wish those > ideas got > more

Re: On the value of EV

No, I’m not presuming that; that’s why I put the ? after never. I’ve never heard of any, so it’s possible it really is never. But I’m pretty confident in at least the “rare” part because I’m sure if you knew of any you’d be sharing examples. ;) From: Ryan Sleevi Reply-To:

Re: On the value of EV

On Wed, Dec 13, 2017 at 05:58:38PM +, Tim Shirley via dev-security-policy wrote: > So many of the arguments made here, such as this one, as well as the > recent demonstrations that helped start this thread, focus on edge cases. > And while those are certainly valuable to consider, they

Re: On the value of EV

I'm saying that even 'rarely' is presumptive - that is, that the lack of public evidence is equivalent to a lack of occurrence. As to sharing examples, it presumes that the point of discussion is whether EV is an effective mitigator of phishing, which is a logically flawed viewpoint assuming

Re: On the value of EV

On Wed, Dec 13, 2017 at 01:40:35PM -0800, Matthew Hardeman via dev-security-policy wrote: > I'm not sure we need namespace separation for EV versus non-EV subresouces. > > The cause for this is simple: > > It is the main page resource at the root of the document which causes each > sub-resource