Re: Disallowed company name

On Thu, May 31, 2018 at 4:18 PM, Peter Saint-Andre via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > > We can also think of many business types (e.g., scammers) that would > love to have names like ⒶⓅⓅⓁⒺ but that doesn't mean it's smart to issue > certificates with such

Re: Disallowed company name

On Thu, May 31, 2018 at 3:38 PM, James Burton via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > I recently incorporated the company named ";", see: > https://beta.companieshouse.gov.uk/company/11363219. This company > compiles with > the both the "Companies Act 2006" and

Re: 2018.05.18 Let's Encrypt CAA tag value case sensitivity incident

I believe that Paul Wouters has made a compelling case regarding the current state of keying practices in DNSSEC deployment today. There is sufficient cryptographic rigor to merit logging this data for review of correct assessment as of the point in time at which certificate issuance decisioning

Fwd: 2018.05.18 Let's Encrypt CAA tag value case sensitivity incident

Copying message accidentally sent directly to a list participant. -- Forwarded message -- From: Matthew Hardeman Date: Tue, May 22, 2018 at 3:47 PM Subject: Re: 2018.05.18 Let's Encrypt CAA tag value case sensitivity incident To: Ryan Sleevi

Re: 2018.05.18 Let's Encrypt CAA tag value case sensitivity incident

I concur with Mr. Lamb's position. I agree not only with respect to DNSSEC signatures but to the entire query and RR set upon which the CAs decisions relied. I do acknowledge the challenge that Mr. Hoffman-Andrews surfaced: that it may involve significant effort to correlate the various queries

Re: question about DNS CAA and S/MIME certificates

I concur with Wayne's position that the discussion up to this point isn't leading to a solution. I represent nothing further than that I'm a systems and DNS administrator and domain holder (and thus, I submit, an interested and not entirely uninformed ecosystem participant) who has had an

Re: question about DNS CAA and S/MIME certificates

table definition that we > all know and love. You can't just pretend that's not part of the scoping or > authority here. > > > On Tue, May 15, 2018 at 12:06 PM, Matthew Hardeman via dev-security-policy > <dev-security-policy@lists.mozilla.org> wrote: > >> It is di

Re: question about DNS CAA and S/MIME certificates

...@mydomain.com while allowing the following CAs to issue for any email address over the same domain. On Tue, May 15, 2018 at 11:15 AM, Ryan Sleevi <r...@sleevi.com> wrote: > Both types share a common namespace. The domain name space. > > On Tue, May 15, 2018 at 12:10 PM, Matthew H

Re: question about DNS CAA and S/MIME certificates

Agreed. My point was to query the position of the administration of a large generic email service as to their understanding of the implications of CAA on their domains. Certificates have different types of SANs for good cause: the nuances of the name space differ. For example, SAN rfc822Names

Re: question about DNS CAA and S/MIME certificates

It is disingenuous to apply CAA to S/MIME and other certificate purposes after the fact. As a domain holder myself, having implemented CAA in certain domains, I did intent to restrict issuance of server certificates. I have never intended this to be a restriction of S/MIME certificate issuance.

Re: question about DNS CAA and S/MIME certificates

For that matter, can whoever is in charge of gmail.com speak to their intent as to CAA for S/MIME? I've certainly held certificates which include my personal gmail address before. At no point did I need or seek Google's blessing to do so. I can not imagine that was an uncommon case. (At least,

Re: Regional BGP hijack of Amazon DNS infrastructure

On Wed, Apr 25, 2018 at 1:44 PM, Santhan Raj via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > I did see the (ridiculously silly) self-signed certificate that was used, > but the skeptic in me keeps questioning the timeline of this attack and > recent multiple cert

Re: Regional BGP hijack of Amazon DNS infrastructure

Also, during the period of the attack, they were using a self-signed certificate. As yet there's no public evidence that they achieved issuance of any certificate. There is some question as to whether they could have. On Wed, Apr 25, 2018 at 12:32 PM, Matthew Hardeman

Re: "multiple perspective validations" - AW: Regional BGP hijack of Amazon DNS infrastructure

On Wed, Apr 25, 2018 at 11:01 AM, Quirin Scheitle via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > > This is not about whether or not domains should deploy DNSSEC. > Domains are are their own right to decide whether or not they see DNSSEC > fit for their environment. >

Re: "multiple perspective validations" - AW: Regional BGP hijack of Amazon DNS infrastructure

> > Multiple perspectives is useful when relying on any insecure third-party > resource; for example DNS or Whois. > > This is different than requiring multiple validations of different types; > an attacker that is able to manipulate the DNS validation at the IP layer > is also likely going to be

Re: "multiple perspective validations" - AW: Regional BGP hijack of Amazon DNS infrastructure

On Wed, Apr 25, 2018 at 8:47 AM, Paul Wouters via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > BGP hijack at once. In the end, that's a numbers game with a bunch of > race conditions. But hey, it might lead to actual BGP security getting > deployed :) > I'm an

Re: Regional BGP hijack of Amazon DNS infrastructure

On Tue, Apr 24, 2018 at 7:11 PM, Wayne Thayer wrote: > Thanks Matthew, I appreciate you bringing this to everyone's attention. > > Unless I'm misunderstanding the scope of the attack, it would have been > trivial for them to get a trusted cert from most any CA. However,

Regional BGP hijack of Amazon DNS infrastructure

This story is still breaking, but early indications are that: 1. An attacker at AS10297 (or a customer thereof) announced several more specific subsets of some Amazon DNS infrastructure prefixes: 205.251.192-.195.0/24 205.251.197.0/24 205.251.199.0/24 2. It appears that AS10297 via peering

Re: Sigh. stripe.ian.sh back with EV certificate for Stripe, Inc of Kentucky....

My purpose in bringing up the High Risk Certificate Request and the BR that requires that a CA maintain a list of matching criteria to scrub certificate requests with was merely to illustrate yet another criteria upon which GoDaddy and other CAs may legitimately decline to issue a certificate such

Re: Sigh. stripe.ian.sh back with EV certificate for Stripe, Inc of Kentucky....

Reposting as I accidentally sent to Mr. Mill only. On Thu, Apr 12, 2018 at 1:57 PM, Eric Mill wrote: > > > But he did not deceive users. Demonstrating that this is possible is not > itself an act of deception. > > Except that if he can't maintain a working EV certificate in a

Re: Sigh. stripe.ian.sh back with EV certificate for Stripe, Inc of Kentucky....

Independent of EV, the BRs require that a CA maintain a High Risk Certificate Request policy such that certificate requests are scrubbed against an internal database or other resources of the CAs discretion. The examples particularly call out names that may be more likely to be used in phishing,

Re: Sigh. stripe.ian.sh back with EV certificate for Stripe, Inc of Kentucky....

Perhaps it should be the broader question of both issuance policy and revocation? For example, guidelines denote what issuance is permissible but nowhere in the BR policies (or in any of the root programs as far as I'm aware) is an affirmative obligation to issue to those meeting the

Re: Sigh. stripe.ian.sh back with EV certificate for Stripe, Inc of Kentucky....

On Thu, Apr 12, 2018 at 2:28 PM, Alex Gaynor wrote: > All that proves is the entire EV model cannot possibly accomplish what CAs > claims (with respect to phishing and other similar concerns). To whit: > > - Two companies can validly possess trademarks for the same name in

Re: Sigh. stripe.ian.sh back with EV certificate for Stripe, Inc of Kentucky....

On Thu, Apr 12, 2018 at 2:20 PM, James Burton wrote: > Both mine and Ian's demonstrations never harmed or deceived anyone as > they were proof of concept. The EV certs were properly validated to the > EV guidelines. Both companies are legitimate. So what's the issue? None. > > >

Re: Sigh. stripe.ian.sh back with EV certificate for Stripe, Inc of Kentucky....

On Thu, Apr 12, 2018 at 1:24 PM, Eric Mill wrote: > Ian's intent may have been to demonstrate EV's weaknesses, but that > doesn't mean Ian was intending to deceive users. If Ian had used this to > try to get people to enter their Stripe credentials or something, then > that'd

Re: Sigh. stripe.ian.sh back with EV certificate for Stripe, Inc of Kentucky....

On Thu, Apr 12, 2018 at 12:52 PM, Ryan Sleevi wrote: > > > For that matter, why isn't "O=Stripe, Inc., ST=California, > jurisdictionStateOrProvinceName=Delaware" confusing - does the "average > Internet user" understand the distinction between those two states being > presented?

Re: Sigh. stripe.ian.sh back with EV certificate for Stripe, Inc of Kentucky....

On Thu, Apr 12, 2018 at 12:24 PM, Ryan Sleevi wrote: > > So Apple Computer is misleading to customers of Apple Records, and Apple > Records is misleading to customers of Apple Computer, is that the argument? > In which case, no one named "Apple" should a certificate, right? > >

Re: Sigh. stripe.ian.sh back with EV certificate for Stripe, Inc of Kentucky....

On Thu, Apr 12, 2018 at 12:03 PM, Wayne Thayer wrote: > > > I agree with this, but the current approach taken by CAs is defined in the > BRs, so pointing fingers at individual CAs is not the solution. Based on > this argument, the requirement to revoke when a certificate

Re: Sigh. stripe.ian.sh back with EV certificate for Stripe, Inc of Kentucky....

On Thu, Apr 12, 2018 at 11:45 AM, Ryan Sleevi wrote: > > In what way is it misleading though? It fully identified the organization > that exists, which is a legitimate organization. Thus, the information that > appears within the certificate itself is not misleading - and I

Re: Sigh. stripe.ian.sh back with EV certificate for Stripe, Inc of Kentucky....

On Thu, Apr 12, 2018 at 11:40 AM, Eric Mill wrote: > > That's not accurate -- the EV information presented to users was not > misleading. It correctly described Ian's registered company. The > certificate was incorrectly revoked. We should probably be discussing > whether

Re: Sigh. stripe.ian.sh back with EV certificate for Stripe, Inc of Kentucky....

makes the payment processing company somehow more deserving of one than >>>> Ian's company? Why was GoDaddy allowed to effectively take Ian's site >>>> down >>>> without his consent? >>>> >>>> If this is how EV is goi

Re: Sigh. stripe.ian.sh back with EV certificate for Stripe, Inc of Kentucky....

splay of EV information from Mozilla products. >> >> -- Eric >> >> On Wed, Apr 11, 2018 at 3:31 PM, Jonathan Rudenberg via >> dev-security-policy >> <dev-security-policy@lists.mozilla.org> wrote: >> >> > On Wed, Apr 11, 2018, at 15:27, Matthew Hardem

Re: Sigh. stripe.ian.sh back with EV certificate for Stripe, Inc of Kentucky....

> > On Wed, Apr 11, 2018 at 3:31 PM, Jonathan Rudenberg via > dev-security-policy <dev-security-policy@lists.mozilla.org> wrote: > >> On Wed, Apr 11, 2018, at 15:27, Matthew Hardeman via dev-security-policy >> wrote: >> > It was injudicious of a CA to issue anot

Re: Sigh. stripe.ian.sh back with EV certificate for Stripe, Inc of Kentucky....

Isn't that question a little disingenuous? There was massive controversy in the mainstream tech press and throughout the InfoSec press and elsewhere when a certificate with this EV indication for this entity name for this website and purpose previously issued. It invites trouble in the sense

Re: Sigh. stripe.ian.sh back with EV certificate for Stripe, Inc of Kentucky....

EV (by CA, WRT phishing) do not > match the technical reality. As Ryan noted, as far as I'm aware this > certificate violates neither the BRs, nor the EVG. > > Alex > > On Wed, Apr 11, 2018 at 2:48 PM, Matthew Hardeman via dev-security-policy > <dev-security-policy@lists.m

Re: Sigh. stripe.ian.sh back with EV certificate for Stripe, Inc of Kentucky....

This absolutely appears to be valid issuance. And if it's valid issuance, that raises questions about the value of EV, if we accept that the definition of EV is static and unchangeable. What I propose is that the community of CAs either recognize that it's worthless and give up on it - or -

Re: Sigh. stripe.ian.sh back with EV certificate for Stripe, Inc of Kentucky....

Additionally, I think it's fair to say that I'm aghast that another CA (who by their inclusion in the Mozilla root program has agreed to stay abreast of developments on this list) has issued for the exact same entity and name that already led to significant controversy covered on this list less

Sigh. stripe.ian.sh back with EV certificate for Stripe, Inc of Kentucky....

Hi, I'm merely an interested community member. I'm writing because I'm aghast that yet another CA has issued a certificate for Stripe, Inc of Kentucky. One would think that the various commercial CAs would consider their communal self-interests in today's marketplace. The commercial CA

Re: FW: Complying with Mozilla policy on email validation

On Tue, Apr 3, 2018 at 12:19 PM, Ryan Hurst via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > > For example, if we consider a CA supporting a large mail provider in > providing S/MIME certificates to all of its customers. In this model, the > mail provider is the

Re: 2018.03.12 Let's Encrypt Wildcard Certificate Encoding Issue

On Tue, Mar 13, 2018 at 4:02 PM, Ryan Sleevi <r...@sleevi.com> wrote: > > > On Tue, Mar 13, 2018 at 4:13 PM, Matthew Hardeman via dev-security-policy > <dev-security-policy@lists.mozilla.org> wrote: > >> I am not at all suggesting consequences for Let's Encrypt,

Re: 2018.03.12 Let's Encrypt Wildcard Certificate Encoding Issue

The fact that this mis-issuance occurred does raise a question for the community. For quite some time, it has been repeatedly emphasized that maintaining a non-trusted but otherwise identical staging environment and practicing all permutations of tests and issuances -- especially involving new

Re: Following up on Trustico: reseller practices and accountability

In terms of an "opportunity" to insert regulation into the reseller ecosystem, as Mr. Sleevi points out, there is the question of whether the reseller is just a third party agent acting under contract by the end-user client vs a party with a special relationship with one or more CAs and their own

Re: Following up on Trustico: reseller practices and accountability

On Mon, Mar 5, 2018 at 7:26 AM, James Burton via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Currently, resellers are allowed to submit CSRs on behalf of their > customers and as we've seen this is open to abuse. Maybe it's time to stop > this practice and restrict

Re: Trustico code injection

By this point, one would imagine that reputational risks would prevent any CA from working with Trustico. On Thu, Mar 1, 2018 at 11:56 AM, Hector Martin 'marcan' via dev-security-policy wrote: > On 2018-03-02 00:28, Hanno Böck via dev-security-policy

Re: How do you handle mass revocation requests?

On Wednesday, February 28, 2018 at 4:44:50 PM UTC-6, Jeremy Rowley wrote: > 1) Not all of the certificates being revoked use the Symantec hierarchy. > There are some certs that use the DigiCert replacement hierarchy. Not many > though. > 2) Sorry my wording was strange. It almost always is. What

Re: How do you handle mass revocation requests?

On Wednesday, February 28, 2018 at 3:55:37 PM UTC-6, Ryan Duff wrote: > >From what I've read, it appears the situation here is that Trustico wanted > >to revoke all their customer certs from Digicert so they could do a mass > >migration to another CA (which is not a proper reason to revoke).

Re: How do you handle mass revocation requests?

Did this whole thing start because someone at Trustico wanted to accelerate the process of getting their resold Symantec certificates reissued under a DigiCert trust path? And somehow some misinformed soul imagined creating a revocation crisis would somehow help achieve that goal without

Re: How do you handle mass revocation requests?

I would echo Mr. Gaynor's point. While it's perhaps a pedantic distinction, the private keys are definitely compromised now and were the moment that Trustico provided the keys to Digicert, even if Trustico is defined to be the original authorized recipient. The CA is explicitly not to be in

Re: Allowing WebExtensions to Override Certificate Trust Decisions

Altering the security UI based on a third party extension seems risky in either direction. If a broad pinning scheme was unlikely to cause problems, HPKP would still be a thing. Other criteria for stricter than standard validation seem hard to guarantee over the long haul also. Even if a whole

Re: TLS-SNI-01 and compliance with BRs

On Fri, Jan 19, 2018 at 11:06 AM, Peter Bowen via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > > For a certificate capable of being used for SSL-enabled servers, the CA > must ensure that the applicant has registered the domain(s) referenced in > the certificate or has

Re: TLS-SNI-01 and compliance with BRs

On Fri, Jan 19, 2018 at 2:58 PM, Doug Beattie wrote: > Matthew, > > > > That’s a good summary. It seems we have 2 methods that can be used only > if the CAs using the methods have the design and risk mitigation factors > reviewed and approved. It’s basically the

Re: TLS-SNI-01 and compliance with BRs

One opinion I'd like to add to the discussion... In as far as that at this point, it looks like it's time for guidance from the root programs officially on whether or not and under what circumstances TLS-SNI-01 and/or any other mechanism based on method #10 are allowable moving forward I'd

Re: TLS-SNI-01 and compliance with BRs

On Fri, Jan 19, 2018 at 9:22 AM, Doug Beattie via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > I think we’ve gotten off track. While the general discussion is good and > we need to update the validation methods to provide more precise details, I > want to get back to

Re: TLS-SNI-01 and compliance with BRs

The trouble is that the BRs for those methods are really really vague. I don't know that one can make a stronger case for misissuance versus properly issued in these cases. I'm certainly no fan of the mechanism in TLS-SNI-01 and regard it deficient in the face of real world deployment

Re: 2018.01.09 Issue with TLS-SNI-01 and Shared Hosting Infrastructure

On Wed, Jan 10, 2018 at 10:42 PM, Ryan Sleevi wrote: > > > I do not know why you say that, considering the Forum explicitly decided > to make .10 flexible as it is to accommodate both solutions. > > The goal was explicitly NOT to make an ideal-secure solution, it was to >

Re: 2018.01.09 Issue with TLS-SNI-01 and Shared Hosting Infrastructure

On Wednesday, January 10, 2018 at 6:17:34 PM UTC-6, Ryan Sleevi wrote: > On Wed, Jan 10, 2018 at 5:53 PM, Matthew Hardeman > wrote: > > > > That, indeed, is a chilling picture. I'd like to think the community's > > response to any such stretch of the rules would be along the

Re: 2018.01.09 Issue with TLS-SNI-01 and Shared Hosting Infrastructure

You've just triggered me with an early 2000s flashback. Now I can't get that "So fresh and so clean, clean..." rap line out of my head from OutKast's "So Fresh, So Clean". On Wed, Jan 10, 2018 at 4:11 PM, Tim Hollebeek wrote: > > > My "Freshness Value" ballot should

Re: 2018.01.09 Issue with TLS-SNI-01 and Shared Hosting Infrastructure

On Wed, Jan 10, 2018 at 3:57 PM, Ryan Sleevi wrote: > > > Note that the presumptive discussion re: .well-known has ignored that the > Host header requirements are underspecified, thus the fundamental issue > still exists for that too. That said, there absolutely has been both >

Re: 2018.01.09 Issue with TLS-SNI-01 and Shared Hosting Infrastructure

As another tangent question on the advisability of resuming the TLS-SNI-01 validation method, can/will Let's Encrypt share any data on prevalence of the various validation mechanisms over time and how they stack up against each other in terms of prevalence. Also, it might be helpful to know

Re: 2018.01.09 Issue with TLS-SNI-01 and Shared Hosting Infrastructure

I agree with Nick's questions, and I can certainly see the relevance in matching what actually happens out there to the effectiveness and appropriateness of the various domain validation mechanisms. Having said that, I think it should effectively be a "read only" affair, shaping community and CA

Re: 2018.01.09 Issue with TLS-SNI-01 and Shared Hosting Infrastructure

On Wed, Jan 10, 2018 at 2:38 PM, Ryan Sleevi wrote: > > I think it's important to point out that these levels of technical > discussions are best directed to the IETF ACME WG, under the auspices of > the IETF NoteWell - https://datatracker.ietf.org/wg/acme/about/ > Noted. If

Re: 2018.01.09 Issue with TLS-SNI-01 and Shared Hosting Infrastructure

On Wed, Jan 10, 2018 at 12:00 PM, Wayne Thayer wrote: > ficant difference here. At a minimum the original request >> arrives on port 80 and with a proper Host: header identifying the target >> website to be validated. Yes, it's possible that your host redirects >> that, >>

Re: 2018.01.09 Issue with TLS-SNI-01 and Shared Hosting Infrastructure

On Wed, Jan 10, 2018 at 11:24 AM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > I don't think that's true. If your hosting provider allows other sites > to respond to HTTP requests for your domain, there's a similar > vulnerability in the HTTP-01

Re: 2018.01.09 Issue with TLS-SNI-01 and Shared Hosting Infrastructure

I applaud LetsEncrypt for disclosing rapidly and thoroughly. During the period after the initial announcement and before the full report, I quickly read the ACME spec portion pertaining to TLS-SNI-01. I had not previously read the details of that validation method as that method was not once I

Re: 2018.01.09 Issue with TLS-SNI-01 and Shared Hosting Infrastructure

On Wed, Jan 10, 2018 at 10:35 AM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > Hosting providers can simply refuse to accept uploads of any certificate > which contains names ending in "acme.invalid". > > AIUI, this is Let's Encrypt's recommended

Re: Certificates with shared private keys by gaming software (EA origin, Blizzard battle.net)

Part of the trouble in relying upon the name alone is that on many OS's (maybe all -- at least all the ones that matter for client side work) can have localhost overridden to mean other things. Taking it back to the IP layer has the advantage of certainty for the constrained question of whether

Re: Certificates with shared private keys by gaming software (EA origin, Blizzard battle.net)

On Monday, December 25, 2017 at 11:27:00 AM UTC-6, Adrian R. wrote: > +1 > imho that would be the best idea, and the local/non-local check should happen > inside the same PKI-validation logic flow that is used for certificate > validation. > > If the url resource resolves to local IP addresses

Re: Certificates with shared private keys by gaming software (EA origin, Blizzard battle.net)

On Monday, December 25, 2017 at 10:24:30 AM UTC-6, Hanno Böck wrote: > On Mon, 25 Dec 2017 14:43:21 + > Jeremy Rowley via dev-security-policy > wrote: > > > Without the private key, im not sure how we're supposed to confirm > > key compromise. > >

Re: Certificates with shared private keys by gaming software (EA origin, Blizzard battle.net)

This is nasty. Apparently, it's not actually a true Root CA cert (No CA: True) and it has an EKU that would not include signing certificates. That said, Blizzard's response is further to my point... As long as the browser can access resources of the localhost under the direction of a web page

Re: Certificates with shared private keys by gaming software (EA origin, Blizzard battle.net)

Far too many do it. I think the technique is repugnant garbage that the browsers themselves should solve. Spotify historically did this, too. The idea is that rich-client software on the PC has a daemon running in the background on one of a number of chosen TCP ports. Usually it implements

Re: On the value of EV

On Monday, December 18, 2017 at 3:54:24 PM UTC-6, Andrew wrote: > On Monday, December 18, 2017 at 3:09:31 PM UTC-6, Wayne Thayer wrote: > > Thank you Ryan for raising this question, and to everyone who has been > > contributing in a constructive manner to the discussion. A number of > > excellent

Re: On the value of EV

IDN abuses are far more hostile, to my mind, than EV positive indicators. At least within certain locales. Why is IDN even displayed in styled form if the client locale belongs to a jurisdiction or language for which non-roman characters would be abnormal? Additionally, many vehicles provide

Re: On the value of EV

That is, indeed, a good question. I've also questioned simultaneously questioning users' reliance on the UI while suggesting that no user looks to the UI. If the user does not see or make decisions on the basis of the UI, it seems leaving it present is no harder a conclusion to arrive at than

Re: On the value of EV

On Friday, December 15, 2017 at 5:39:37 PM UTC-6, Ryan Sleevi wrote: > That is not what is required. There is no special enrollment dance - that > is simply straight up misrepresenting it. Your vision is not aligned with > the reality of it. I've never been to a banking website where there

Re: On the value of EV

On Friday, December 15, 2017 at 3:51:48 PM UTC-6, Ryan Sleevi wrote: > Yes, we can say correlated variables are correlated. > No, we cannot imply or infer from correlated variables that there is a > causal relationship. > There exists a not insignificant school of actuarial thought that there

Re: On the value of EV

On Friday, December 15, 2017 at 4:06:02 PM UTC-6, Ryan Sleevi wrote: > It also perpetuates the myopic and flawed view as a phishing mitigation, > whose reliance is upon users checking it (again, user hostile), and > misleading both users and site operators into EV as a phishing mitigation, > when

Re: CA generated keys

On Friday, December 15, 2017 at 3:21:54 PM UTC-6, Ryan Hurst wrote: > Unfortunately, the PKCS#12 format, as supported by UAs and Operating Systems > is not a great candidate for the role of carrying keys anymore. You can see > my blog post on this topic here: http://unmitigatedrisk.com/?p=543

Re: On the value of EV

On Friday, December 15, 2017 at 3:08:32 PM UTC-6, Ryan Sleevi wrote: > Respectfully, this is the tiger-repelling rock. We can't show that any > tigers attacked, therefore, we should keep telling users they need > tiger-repelling rocks. And oh, by the way, they take away attention from > solutions

Re: On the value of EV

On Friday, December 15, 2017 at 1:50:38 PM UTC-6, Ryan Sleevi wrote: > I'm not sure I made those statements, but would be happy to clarify the > confusion. Indeed, as I tried to call out, there are a subset of users who > are looking at it and relying on it - although it cannot be relied upon - >

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

require responses within a certain time period.) > > -tom > > On 14 December 2017 at 22:16, Matthew Hardeman via dev-security-policy > <dev-security-policy@lists.mozilla.org> wrote: > > Has anyone started looking into CA issuances -- or even more importantly > -- CA d

Re: On the value of EV

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

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

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

Beyond EV: Thoughts on trust and actionable trust signals

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

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

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

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 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

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 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: 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: 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

> 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

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: On the value of EV

On Monday, December 11, 2017 at 5:37:34 PM UTC-6, Ryan Sleevi wrote: > Yes. > > If something is not valuable for billions of users, if it is not > trustworthy for billions of users, it should not occupy the cognitive or > visual model billions of users rely on. > Perish the thought that a UI

Re: On the value of EV

On Monday, December 11, 2017 at 5:00:14 PM UTC-6, Ryan Sleevi wrote: > > That Kentucky registration for Stripe, Inc. -- Is it completely fraudulent > > as to registered agent, business address, etc? If it's not, then the > > certificate and underlying entity serve as an archived investigative

Re: On the value of EV

What I dislike about this particular rationale is that I presupposes we should architect web security such as to avoid enhancements which have value to anyone the least common denominator. Is the average user (actually, the bottom rung of the concentration of values around the average, I suppose)

Re: On the value of EV

While I understand that it may formally be beyond the scope formally to consider this in discussion with EV UI handling, I think some consideration to ecosystem harm is appropriate here. If we eliminate EV UI, we have reduced the scope of WebPKI to domain validated certificates (in any pragmatic

Re: On the value of EV

On Mon, Dec 11, 2017 at 2:53 PM, Ryan Sleevi wrote: > > > It feels like, to some extent, this is a question about whether we should > point out the Emperor has no clothes if we don't have clothes to offer him. > It'd be great if they was wearing some, I agree - the Emperor does

Re: On the value of EV

- If the fundamental certificate does deserve the UI treatment, then > demonstrate why it does. You seem to be in agreement that the present form > of legal identity is insufficient for the presumed use case, so I'm hoping > you can close the gap in my understanding on why something is >

<    1   2   3   >