Am Dienstag, 12. Dezember 2017 16:19:22 UTC+1 schrieb Nick Lamb:
> Hi,
>
> I have a couple of follow-up questions if I may:
>
> On Tue, 12 Dec 2017 02:09:47 -0800 (PST)
> "cornelia.enke--- via dev-security-policy"
> wrote:
>
> > The subject information in the affected certificates were not
> >
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 configurat
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
ther
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 e
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 allo
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
>
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.
That's a massive and probably insurmountable
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 that
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 tra
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 a
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 suppor
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
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 the
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.
Most of the world knows this.
That's a
> 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 i
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 is
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
W
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.
Which I guess is the
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. Usua
> 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 no
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 o
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 entropy corpus.
> >
>
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 mai
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 t
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 a
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.
>
> -
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
> possible to create confus
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 seat-belt
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 othe
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
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 Langle
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
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 presence
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.
> >
> > https://en.wikipedia.org/wiki/Same-
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
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-
> bounces+tim.holl
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 s
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: "r...@sleevi.com"
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 obscur
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 corre
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
On Wednesday, December 13, 2017 at 3:42:38 PM UTC-6, Ryan Sleevi wrote:
> > Would Ian have requested a certificate for Stripe, Inc. if his full name
> > were also in that certificate? Maybe, maybe not. But anyone investigating
> > that certificate would need do no extra work to know what individ
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:
https://info.phishlabs.com/blog/quarter-phishing-attacks-hosted-https-domains
In particular, "the rate at which p
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
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 saying what.
>Sitting on my desk are not les
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 to
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 hardwa
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-
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: dev-security-
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 introduc
On Wed, Dec 13, 2017 at 4:06 PM, 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
>
Perhaps, but Mozilla has stated their position on that, so it’s not germane
to this thread and discussion.
You’re still making a logically flawed argument to say “Because (some)
feeds of known phishing sources (with undefined definitions or resolution
mechanisms) don’t contain an EV, EV is a defen
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 policy
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 music
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
55 matches
Mail list logo