Re: Sanctions short of distrust

On 26/09/16 12:25, Rob Stradling wrote: > Who determines whether or not the PSL is accurate? Does common sense > ever override the explicitly stated will of the TLD operator? Normally no, not for the explicitly-stated will (e.g. an email to us). It might perhaps override a random policy

Re: Sanctions short of distrust

Who determines whether or not the PSL is accurate? Does common sense ever override the explicitly stated will of the TLD operator? (BTW, just to be clear: I wasn't alleging, or even speculating, that the certs containing dNSNames for these public suffices were necessarily misissued. I only

Re: Sanctions short of distrust

On 26/09/16 11:14, Rob Stradling wrote: > ICANN: kuzbass.ru There are several .ru in your list; we should check whether the PSL is actually accurate. I think they opened up a lot of previously-reserved domains a while back, but it's hard to find the right records. These are the non-RU entries:

Re: Sanctions short of distrust

On 26/09/16 10:07, Gervase Markham wrote: > Hi Rob, > > On 23/09/16 16:18, Rob Stradling wrote: >> BTW, I also found certs containing the following ICANN suffixes (i.e., >> PSL+0), some of which may be of interest: > > Are these in the PUBLIC or PRIVATE section of the PSL? (s/PUBLIC/ICANN) A

Re: Sanctions short of distrust

On Friday, September 23, 2016 at 9:31:14 AM UTC-7, Jakob Bohm wrote: > 2.2: Mozilla also makes an e-mail client (Thunderbird) which uses the > same CA root list and the same NSS security library to check e-mail > certificates. E-mail trust bits are still part of the Mozilla CA root > database.

Re: Sanctions short of distrust

On 23/09/2016 17:18, Rob Stradling wrote: On 22/09/16 18:48, Jakob Bohm wrote: While you are at it: 1. How many WoSign/StartCom certificates did you find with domains not on that IANA list? Hi Jakob. I wasn't looking for this sort of thing, because Gerv was only interested in "unique

Re: Sanctions short of distrust

On 22/09/16 18:48, Jakob Bohm wrote: > While you are at it: > > 1. How many WoSign/StartCom certificates did you find with domains not > on that IANA list? Hi Jakob. I wasn't looking for this sort of thing, because Gerv was only interested in "unique base domains (PSL+1)". I think there

Re: Sanctions short of distrust

On 23/09/2016 12:51, Peter Gutmann wrote: Jakob Bohm writes: While you are at it: 1. How many WoSign/StartCom certificates did you find with domains not on that IANA list? 2. How many WoSign/StartCom certificates did you find for other uses than

Re: Sanctions short of distrust

Jakob Bohm writes: >While you are at it: > >1. How many WoSign/StartCom certificates did you find with domains not > on that IANA list? > >2. How many WoSign/StartCom certificates did you find for other uses > than https://www.example.tld: > >2.1 Certificates for "odd"

Re: Sanctions short of distrust

t; WoSign CA limited > > > > > > From: dev-security-policy [mailto:dev-security-policy-bounces+richard= > > wosign@lists.mozilla.org] On Behalf Of Peter Kurrasch > > Sent: Thursday, September 22, 2016 3:06 AM > > To: mozilla-dev-security-pol...@lists.mozilla.org >

Re: Sanctions short of distrust

gt; To: mozilla-dev-security-pol...@lists.mozilla.org > Subject: Time to distrust (was: Sanctions short of distrust) > > Do we trust that WoSign will honor requsts for certs to be revoked? Do we > trust that revocation will take place in a timely matter? Do we trust that > WoSign wi

Re: Sanctions short of distrust

On 21/09/2016 21:40, Rob Stradling wrote: On 21/09/16 15:06, Rob Stradling wrote: I ran some queries earlier today on the crt.sh DB, to find all CNs, dNSNames and iPAddresses in all unexpired certs whose issuer names include either "WoSign" or "StartCom". Then I cross-referenced that with the

Re: Time to distrust (was: Sanctions short of distrust)

Well, well. Here we are again, Ryan, with you launching into a bullying, personal attack on me instead of seeking to understand where I'm coming from and why I say the things I say. You may have noticed that I do

Sanctions short of distrust

ds, Richard Wang CEO WoSign CA limited From: dev-security-policy [mailto:dev-security-policy-bounces+richard=wosign@lists.mozilla.org] On Behalf Of Peter Kurrasch Sent: Thursday, September 22, 2016 3:06 AM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Time to distrust (was: San

Re: Sanctions short of distrust

On 21/09/16 15:06, Rob Stradling wrote: > I ran some queries earlier today on the crt.sh DB, to find all CNs, > dNSNames and iPAddresses in all unexpired certs whose issuer names > include either "WoSign" or "StartCom". Then I cross-referenced that > with the latest PSL data to discover the

Re: Time to distrust (was: Sanctions short of distrust)

On Wednesday, September 21, 2016 at 12:05:49 PM UTC-7, Peter Kurrasch wrote: > I have a hard time seeing how any sort of white list solution will actually > mitigate any of the bad behavior exhibited by WoSign. This doesn't help understand where your disconnect is, or how we might educate and

Time to distrust (was: Sanctions short of distrust)

I have a hard time seeing how any sort of white list solution will actually mitigate any of the bad behavior exhibited by WoSign. From my perspective, I think we can make a pretty clear case that WoSign is a

Re: Sanctions short of distrust

On Tuesday, September 13, 2016 at 8:19:03 AM UTC-7, Ryan Sleevi wrote: > On Tuesday, September 13, 2016 at 7:56:20 AM UTC-7, Peter Bowen wrote: > > I would be careful reading too much into server names. > > mail.[example.com] might host web based email access. For example, > > I'm typing this

Re: Sanctions short of distrust

On Monday, September 12, 2016 at 2:46:40 PM UTC-7, Ryan Sleevi wrote: > On Wednesday, August 31, 2016 at 12:43:50 PM UTC-7, Nick Lamb wrote: > > I have spent some time thinking about this, but I am only one person, and > > one with relatively little in-depth knowledge of the Mozilla project, so I

Re: Sanctions short of distrust

On 13/09/2016 16:56, Peter Bowen wrote: On Tue, Sep 13, 2016 at 7:53 AM, Ryan Sleevi wrote: We also see a variety of domains using certs from either for purposes that are ostensibly not relevant to browsers - a frequent dead give-away is a cert for autodiscover.[example.com]

Re: Sanctions short of distrust

On 13/09/2016 16:47, Ryan Sleevi wrote: On Monday, September 12, 2016 at 8:30:07 PM UTC-7, Jakob Bohm wrote: A variation of this, would be to create (compacted) whitelists for specific old intermediary certs, It sounds like you haven't been following this conversation, but the entire point

Re: Sanctions short of distrust

(Apologies for shortness and lack of context. My home is being redecorated so no non-work PCs powered on) Ryan's example doesn't work, autodiscover is a sign of MS Exchange but that means OWA Outlook Web Access may be enabled. Which means web browsers see that certificate.

Re: Sanctions short of distrust

On Tuesday, September 13, 2016 at 7:56:20 AM UTC-7, Peter Bowen wrote: > I would be careful reading too much into server names. > mail.[example.com] might host web based email access. For example, > I'm typing this into a site called mail.google.com :) Apologies that the conjunctive and was not

Re: Sanctions short of distrust

On Tue, Sep 13, 2016 at 7:53 AM, Ryan Sleevi wrote: > We also see a variety of domains using certs from either for purposes that > are ostensibly not relevant to browsers - a frequent dead give-away is a cert > for autodiscover.[example.com] - which is an Exchange

Re: Sanctions short of distrust

On Monday, September 12, 2016 at 8:30:07 PM UTC-7, Jakob Bohm wrote: > A variation of this, would be to create (compacted) whitelists for > specific old intermediary certs, It sounds like you haven't been following this conversation, but the entire point of restarting this thread, and in the

Re: Sanctions short of distrust

On Monday, September 12, 2016 at 8:01:36 PM UTC-7, Peter Bowen wrote: > I'm trying to think of this as potentially reusable code. Just > because IssuerA is quasi-trusted for example.com doesn't mean IssuerB > should be. From a logic perspective, setting the whitelist per issuer > means you are

Re: Sanctions short of distrust

On Mon, Sep 12, 2016 at 2:46 PM, Ryan Sleevi wrote: > > Consider if we start with the list of certificates issued by StartCom and > WoSign [...] Extract the subjectAltName from every one of these certificates, > and then compare against the Alexa Top 1M. This yields more than

Re: Sanctions short of distrust

On 13/09/2016 05:01, Peter Bowen wrote: On Mon, Sep 12, 2016 at 7:02 PM, Ryan Sleevi wrote: On Monday, September 12, 2016 at 6:09:05 PM UTC-7, Peter Bowen wrote: This would have two advantages: 1) Helps limit blast radius of whitelisting a name/domain I'm unclear what you

Re: Sanctions short of distrust

On Mon, Sep 12, 2016 at 7:02 PM, Ryan Sleevi wrote: > On Monday, September 12, 2016 at 6:09:05 PM UTC-7, Peter Bowen wrote: >> This would have two advantages: >> 1) Helps limit blast radius of whitelisting a name/domain > > I'm unclear what you mean by this. I suggest there's an

Re: Sanctions short of distrust

On Monday, September 12, 2016 at 6:14:34 PM UTC-7, Richard Wang wrote: > Please don't mix StartCom with WoSign case, StartCom is 100% independent at > 2015. > > Even now, it still independent in the system, in the validation team and > management team, we share the CRL/OCSP distribution

Re: Sanctions short of distrust

On Monday, September 12, 2016 at 6:09:05 PM UTC-7, Peter Bowen wrote: > I'm not clear from this description, are you proposing to whitelist > eTLD+1 or full hostnames? How large would the lists be if you > whitelisted eTLD+1? This is whitelisting at eTLD+1 (although with a slightly older version

RE: Sanctions short of distrust

-policy [mailto:dev-security-policy-bounces+richard=wosign@lists.mozilla.org] On Behalf Of Adam Caudill Sent: Tuesday, September 13, 2016 7:30 AM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Sanctions short of distrust Of all the possible options - G seems to be the most

Re: Sanctions short of distrust

On Mon, Sep 12, 2016 at 2:46 PM, Ryan Sleevi wrote: > To that end, I'm going to offer one more suggestion for consideration: > G) Distrust with a Whitelist of Hosts > > The issue with C is that it becomes easily inflated by issuing certificates, > even if they're not used; that

Re: Sanctions short of distrust

On Mon, Sep 12, 2016 at 5:46 PM Ryan Sleevi wrote: > On Wednesday, August 31, 2016 at 12:43:50 PM UTC-7, Nick Lamb wrote: > > I have spent some time thinking about this, but I am only one person, > and one with relatively little in-depth knowledge of the Mozilla project, > so I

Re: Sanctions short of distrust

On Wednesday, August 31, 2016 at 12:43:50 PM UTC-7, Nick Lamb wrote: > I have spent some time thinking about this, but I am only one person, and one > with relatively little in-depth knowledge of the Mozilla project, so I think > I will lay out the options I've thought about and invite feedback

Re: Sanctions short of distrust

On 09/09/16 18:25, Ryan Sleevi wrote: > On Friday, September 9, 2016 at 4:42:12 AM UTC-7, Rob Stradling wrote: >> That's a good point. So, to fix my proposal... >> >> For CAs that are on (borrowing Matt's wording) "quintuple secret >> probation" due to a "history of shenanigans with notBefore

Re: Sanctions short of distrust

On Fri, Sep 09, 2016 at 10:25:43AM -0700, Ryan Sleevi wrote: > On Friday, September 9, 2016 at 4:42:12 AM UTC-7, Rob Stradling wrote: > > That's a good point. So, to fix my proposal... > > > > For CAs that are on (borrowing Matt's wording) "quintuple secret > > probation" due to a "history of

Re: Sanctions short of distrust

On Fri, Sep 09, 2016 at 12:41:31PM +0100, Rob Stradling wrote: > For CAs that are on (borrowing Matt's wording) "quintuple secret > probation" due to a "history of shenanigans with notBefore dates", > browsers could require that: > 1. The certificate MUST be "CT qualified" via SCTs embedded in

Re: Sanctions short of distrust

On Friday, September 9, 2016 at 4:42:12 AM UTC-7, Rob Stradling wrote: > That's a good point. So, to fix my proposal... > > For CAs that are on (borrowing Matt's wording) "quintuple secret > probation" due to a "history of shenanigans with notBefore dates", > browsers could require that: Right,

Re: Sanctions short of distrust

On 08/09/16 17:44, Ryan Sleevi wrote: > On Thursday, September 8, 2016 at 4:09:25 AM UTC-7, Rob Stradling wrote: >>> 1. Enforce CT only after a certain date, after which WoSign will need >>> to embed qualified SCTs. This check can be bypassed if the CA >>> backdates certificates (which is

Re: Sanctions short of distrust

On 09/09/16 00:32, Matt Palmer wrote: > On Thu, Sep 08, 2016 at 09:44:04AM -0700, Ryan Sleevi wrote: >> On Thursday, September 8, 2016 at 4:09:25 AM UTC-7, Rob Stradling wrote: 1. Enforce CT only after a certain date, after which WoSign will need to embed qualified SCTs. This check

Re: sanctions short of distrust

It would be useful to try out some of these ideas in a Firefox add-on. But it seems that although Mozilla supports three add-on APIs (XPI, Jetpack, and a subset of Google Web Extensions), none of them allow reading the certificate of the current page. That's a lack. It prevents writing

Re: Sanctions short of distrust

On Thu, Sep 08, 2016 at 09:44:04AM -0700, Ryan Sleevi wrote: > On Thursday, September 8, 2016 at 4:09:25 AM UTC-7, Rob Stradling wrote: > > > 1. Enforce CT only after a certain date, after which WoSign will need > > > to embed qualified SCTs. This check can be bypassed if the CA > > >

Re: Sanctions short of distrust

On Thursday, September 8, 2016 at 4:09:25 AM UTC-7, Rob Stradling wrote: > > 1. Enforce CT only after a certain date, after which WoSign will need > > to embed qualified SCTs. This check can be bypassed if the CA > > backdates certificates (which is problematic, given the history of > >

Re: Sanctions short of distrust

On 02/09/16 21:04, Patrick Figel wrote: > I believe there are two possible solutions if CT enforcement is what the > community decides on: > > 1. Enforce CT only after a certain date, after which WoSign will need > to embed qualified SCTs. This check can be bypassed if the CA >

Re: Sanctions short of distrust

On 06/09/2016 18:15, Ryan Hurst wrote: On Tuesday, September 6, 2016 at 7:54:14 AM UTC-7, Jakob Bohm wrote: On 06/09/2016 16:43, Martin Rublik wrote: On Tue, Sep 6, 2016 at 2:16 PM, Jakob Bohm wrote: Here are a list of software where I have personally observed bad

Re: Sanctions short of distrust

On Tuesday, September 6, 2016 at 7:54:14 AM UTC-7, Jakob Bohm wrote: > On 06/09/2016 16:43, Martin Rublik wrote: > > On Tue, Sep 6, 2016 at 2:16 PM, Jakob Bohm wrote: > > > >> Here are a list of software where I have personally observed bad OCSP > >> stapling support: > >>

Re: Sanctions short of distrust

On 06/09/2016 16:43, Martin Rublik wrote: On Tue, Sep 6, 2016 at 2:16 PM, Jakob Bohm wrote: Here are a list of software where I have personally observed bad OCSP stapling support: IIS for Windows Server 2008 (latest IIS supporting pure 32 bit configurations): No

Re: Sanctions short of distrust

On Tue, Sep 6, 2016 at 2:16 PM, Jakob Bohm wrote: > Here are a list of software where I have personally observed bad OCSP > stapling support: > > IIS for Windows Server 2008 (latest IIS supporting pure 32 bit > configurations): No obvious (if any) OCSP stapling support.

Re: Sanctions short of distrust

On 06/09/2016 15:37, Kurt Roeckx wrote: On 2016-09-06 14:16, Jakob Bohm wrote: On 06/09/2016 10:25, Kurt Roeckx wrote: If you think there is something we can do in OpenSSL to improve this, please let us know. Here are a list of software where I have personally observed bad OCSP stapling

Re: Sanctions short of distrust

On 2016-09-06 14:16, Jakob Bohm wrote: On 06/09/2016 10:25, Kurt Roeckx wrote: If you think there is something we can do in OpenSSL to improve this, please let us know. Here are a list of software where I have personally observed bad OCSP stapling support: OpenSSL 1.0.x itself: There are

Re: Sanctions short of distrust

On 06/09/2016 10:25, Kurt Roeckx wrote: On 2016-09-06 10:13, Nick Lamb wrote: Quality of implementation for OCSP stapling seems to remain poor in at least apache and nginx, two of the most popular servers. Apache's in particular gives me that OpenSSL "We read this standards document and

Re: Sanctions short of distrust

On 2016-09-06 10:13, Nick Lamb wrote: Quality of implementation for OCSP stapling seems to remain poor in at least apache and nginx, two of the most popular servers. Apache's in particular gives me that OpenSSL "We read this standards document and implemented everything in it as a series of

Re: Sanctions short of distrust

On Tuesday, 6 September 2016 08:31:33 UTC+1, Kurt Roeckx wrote: > I would really like to see OCSP stapling as mandatory. There currently > only seem to be around 25% of the servers that do it, and the progress > seem to be very slow. I'm wondering if there is something we can do so > that it's

Re: Sanctions short of distrust

On 2016-09-05 17:55, Jakob Bohm wrote: Indeed, I have found that a number of common web server implementations simply lack the ability to do OCSP stapling at all. I would really like to see OCSP stapling as mandatory. There currently only seem to be around 25% of the servers that do it, and

Re: Sanctions short of distrust

On 03/09/2016 01:23, Matt Palmer wrote: On Fri, Sep 02, 2016 at 11:19:11AM +0100, Gervase Markham wrote: On 31/08/16 20:43, Nick Lamb wrote: >>> ... >> ... > ... 1. Implement "Require SCTs" for problematic CAs. Notify the CA they are obliged to CT log all certificates, inform subscribers etc.

Re: Sanctions short of distrust

Date: Sat, 3 Sep 2016 01:45:48 +0200 From: Patrick Figel <patfi...@gmail.com> Subject: Re: Sanctions short of distrust On 03/09/16 01:15, Matt Palmer wrote: On Fri, Sep 02, 2016 at 03:48:13PM -0700, John Nagle wrote: On 09/02/2016 01:04 PM, Patrick Figel wrote: On 02/09/16 21:14, John

Re: Sanctions short of distrust

On Sat, Sep 03, 2016 at 01:45:48AM +0200, Patrick Figel wrote: > On 03/09/16 01:15, Matt Palmer wrote: > > On Fri, Sep 02, 2016 at 03:48:13PM -0700, John Nagle wrote: > >> On 09/02/2016 01:04 PM, Patrick Figel wrote: > >>> On 02/09/16 21:14, John Nagle wrote: > 2. For certs under this root

Re: Sanctions short of distrust

On 03/09/16 01:15, Matt Palmer wrote: > On Fri, Sep 02, 2016 at 03:48:13PM -0700, John Nagle wrote: >> On 09/02/2016 01:04 PM, Patrick Figel wrote: >>> On 02/09/16 21:14, John Nagle wrote: 2. For certs under this root cert, always check CA's certificate transparency server. Fail if not

Re: Sanctions short of distrust

On Fri, Sep 02, 2016 at 11:19:11AM +0100, Gervase Markham wrote: > On 31/08/16 20:43, Nick Lamb wrote: > > This suggests the need for some options short of distrust which can > > be deployed instead, but Mozilla does not seem to have any. If in > > fact it already does, this would be a great place

Re: Sanctions short of distrust

On Fri, Sep 02, 2016 at 03:48:13PM -0700, John Nagle wrote: > On 09/02/2016 01:04 PM, Patrick Figel wrote: > >On 02/09/16 21:14, John Nagle wrote: > >>2. For certs under this root cert, always check CA's certificate > >>transparency server. Fail if not found. > > > >To my knowledge, CT does not

Re: Sanctions short of distrust

On 09/02/2016 01:04 PM, Patrick Figel wrote: On 02/09/16 21:14, John Nagle wrote: 2. For certs under this root cert, always check CA's certificate transparency server. Fail if not found. To my knowledge, CT does not have any kind of online check mechanism. SCTs can be embedded in the

Re: Sanctions short of distrust

On 02/09/16 21:14, John Nagle wrote: > 2. For certs under this root cert, always check >CA's certificate transparency server. Fail > if not found. To my knowledge, CT does not have any kind of online check mechanism. SCTs can be embedded in the certificate (at the time of

Re: Sanctions short of distrust

September 2016 11:19:49 UTC+1, Gervase Markham wrote: Have you considered what was done for CNNIC? In that case, we distrusted all certificates issued after a certain time. We used a whitelist for determining this, but it would be possible to use the notBefore date in the certificate. A CA could

Re: Sanctions short of distrust

Thanks for your feedback Gerv, On Friday, 2 September 2016 11:19:49 UTC+1, Gervase Markham wrote: > Have you considered what was done for CNNIC? In that case, we distrusted > all certificates issued after a certain time. We used a whitelist for > determining this, but it would be possible to use

Re: Sanctions short of distrust

On 02/09/2016 12:19, Gervase Markham wrote: On 31/08/16 20:43, Nick Lamb wrote: This suggests the need for some options short of distrust which can be deployed instead, but Mozilla does not seem to have any. If in fact it already does, this would be a great place to say what they are and

Re: Sanctions short of distrust

On 31/08/16 20:43, Nick Lamb wrote: > This suggests the need for some options short of distrust which can > be deployed instead, but Mozilla does not seem to have any. If in > fact it already does, this would be a great place to say what they > are and discuss why they haven't been able to be used

Re: Sanctions short of distrust

(I'm replying to the topic as posed in the abstract and as a user with Mozilla hat off. No suggestion of applicability to cases currently under discussion should be inferred.) On Wed, Aug 31, 2016 at 10:43 PM, Nick Lamb wrote: > 1. Implement "Require SCTs" for problematic

Re: Sanctions short of distrust

On 01/09/2016 09:30, Ryan Sleevi wrote: On Thursday, September 1, 2016 at 12:07:48 AM UTC-7, Hanno Böck wrote: Good thing: Can be easily tested by others whether a CA implements it and it may reduce misissuances. I'm inclined to say every CA should implement CAA, but it seems last time this

Re: Sanctions short of distrust

Hi Nick, I want to thank you for bringing this up, because we always seem to have the same kind of discussions when something happened. Ryan's mail has a bunch of other suggestions for what we can do. 1. Implement "Require SCTs" for problematic CAs. Is there a reason we don't require

Re: Sanctions short of distrust

On Thursday, September 1, 2016 at 12:07:48 AM UTC-7, Hanno Böck wrote: > Good thing: Can be easily tested by others whether a CA implements it > and it may reduce misissuances. > > I'm inclined to say every CA should implement CAA, but it seems last > time this was discussed in the

RE: Sanctions short of distrust

ed problem. Best Regards, Richard -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+richard=wosign@lists.mozilla.org] On Behalf Of Hanno B?ck Sent: Thursday, September 1, 2016 3:07 PM To: dev-security-policy@lists.mozilla.org Subject: Re: Sanctions short o

Re: Sanctions short of distrust

On Wed, 31 Aug 2016 12:43:38 -0700 (PDT) Nick Lamb wrote: > 1. Implement "Require SCTs" for problematic CAs. Notify the CA they > are obliged to CT log all certificates, inform subscribers etc. or > their subscriber's certificates will suddenly be invalid in Firefox > from

Sanctions short of distrust

A recurring theme of m.d.s.policy is that a CA behaves in a way that falls short, sometimes far short of the reasonable expectations of relying parties and yet in the end Mozilla doesn't end up distrusting that CA because of the direct impact on relying parties, the indirect impact on