[gnso-rds-pdp-wg] Use case for WHOIS/RDP

Deacon, Alex Alex_Deacon at mpaa.org
Tue Aug 16 18:37:02 UTC 2016 

My key point was that this is a very important use case to add to our list and that we should always be encouraging the use of encryption - no matter what the mechanisms may be.   Also I specifically avoided getting into the details of the varying CA authentication mechanisms and business models.   While the recent email on potential innovation of the CA biz has been interesting its clearly out of scope for this WG.

Alex

On Aug 15, 2016, at 3:58 PM, Ayden Férdeline <icann at ferdeline.com<mailto:icann at ferdeline.com>> wrote:

The key point I was raising was that there isn’t a difference between the encryption keys of domain-validated certificates, be they issued by Let’s Encrypt or a paid CA. The level of encryption is the same. That being said, I would like to return to my question about the use case itself: how could the CAs accomplish their desired task if, theoretically, the RDS could not accommodate their needs in the same manner that the WHOIS protocol does at present?
- Ayden

-------- Original Message --------
Subject: Re: [gnso-rds-pdp-wg] Use case for WHOIS/RDP
Local Time: August 15, 2016 11:48 PM
UTC Time: August 15, 2016 10:48 PM
From: gregshatanipc at gmail.com<mailto:gregshatanipc at gmail.com>
To: Geoffrey_Noakes at symantec.com<mailto:Geoffrey_Noakes at symantec.com>
Alex_Deacon at mpaa.org<mailto:Alex_Deacon at mpaa.org>,icann at ferdeline.com<mailto:icann at ferdeline.com>,Dean_Coclin at symantec.com<mailto:Dean_Coclin at symantec.com>,gnso-rds-pdp-wg at icann.org<mailto:gnso-rds-pdp-wg at icann.org>

I see that Geoff has provided some actual facts, to replace both your speculation and mine.  That should improve everyone's understanding of this use case.

I'll let Alex and/or Geoff respond on the difference between various types and levels of certificates, including the difference in value.  I don't think anyone but you implied that there's no difference between a free Let's Encrypt certificate and a $399 Symantec certificate, in spite of your attempt to hang that on Alex.  A little research shows quite a number of "value added" differences.  That said, Let's Encrypt does seem to be quite a disruptive force in the certificate market, but I don't see the relevance of that to our study of this use case.

Greg

On Mon, Aug 15, 2016 at 6:25 PM, Geoffrey Noakes <Geoffrey_Noakes at symantec.com<mailto:Geoffrey_Noakes at symantec.com>> wrote:
Ayden, the “types of checks” done for SSL/TLS certs fall into 3 categories:

·        DV (domain validation): the most basic form of authentication performed by the CA.  It essentially checks to see if the application for a cert has control over the domain for which the cert will be issued.

·        OV (organization validation): the CA checks information about the organization (e.g., the company or business entity) that has applied for the cert.

·        EV (extra validation): in addition to the OV checks, the CA checks for whether the individual who is applying for the cert is authorized to do so.

The processes for OV and EV authentication is defined by the CA/Browser Forum at https://cabforum.org/extended-validation/.

Netcraft is a third-party organization which monitors the number of publicly-facing SSL/TLS certs.  A Netcraft report with data from July 2016 is attached – they saw ~5.5m certificates.

It is good to think of SSL/TLS certs as being like subscriptions – they each have a period of being valid, and they are usually renewed at the end of their periods.  I am unaware of any publicly-available data on the variety of periods, but anecdotally, many are annual.  Let’s Encrypt uses a 6 month period for theirs, and some are as low as a week (these a unusual).

I am unaware of any report that shows sales data related to SSL/TLS certs – most CAs are either private (and do not report numbers) or are parts of larger organizations (like Symantec, where I work, and do not break out sales numbers at that level).  My sense is that the SSL/TLS cert business is less than $1b/year.

Thanks…

Geoff




From: gnso-rds-pdp-wg-bounces at icann.org<mailto:gnso-rds-pdp-wg-bounces at icann.org> [mailto:gnso-rds-pdp-wg-bounces at icann.org<mailto:gnso-rds-pdp-wg-bounces at icann.org>] On Behalf Of Deacon, Alex
Sent: Monday, August 15, 2016 3:06 PM
To: Ayden Férdeline <icann at ferdeline.com<mailto:icann at ferdeline.com>>
Cc: gnso-rds-pdp-wg at icann.org<mailto:gnso-rds-pdp-wg at icann.org>

Subject: Re: [gnso-rds-pdp-wg] Use case for WHOIS/RDP


Hi Ayden,

Lets not forget that in terms of protecting user privacy the use of encryption is vital, so I believe this is an important use case.   All web server certificates, no matter which flavor of CA is used (from self-signed, to free to high-end) will result in data encryption at the transport layer.   While the encryption is the same (assuming properly configured servers/clients)  the difference between TLS certs is the level of authentication of the entity the server represents.

Its way out of scope to dive deeper into the various CA business models, but search for Domain Validated, Organizational Validated and Extended Validated for more details on some of the various levels of “authentication”.

Alex




On Aug 15, 2016, at 2:41 PM, Ayden Férdeline <icann at ferdeline.com<mailto:icann at ferdeline.com>> wrote:

Thanks for this clarification, Theo. What would be the difference between these basic SSL certificates and those offered freely by, say, Let's Encrypt? (I'm just trying to get a sense of what forms of identity validation are used besides automated WHOIS/DNS checks here, and to understand whether or not other identity checks might be economical for the Digital Certificate Authority. Thanks.)

- Ayden

-------- Original Message --------
Subject: Re: [gnso-rds-pdp-wg] Use case for WHOIS/RDP
Local Time: August 15, 2016 9:00 PM
UTC Time: August 15, 2016 8:00 PM
From: gtheo at xs4all.nl<mailto:gtheo at xs4all.nl>
To: icann at ferdeline.com<mailto:icann at ferdeline.com>,Geoffrey_Noakes at symantec.com<mailto:Geoffrey_Noakes at symantec.com>
gnso-rds-pdp-wg at icann.org<mailto:gnso-rds-pdp-wg at icann.org>


Hi Ayden,
These types of SSL certificates are pretty cheap and the verification is pretty simple. Can be through a verification by email or a code in the name servers, as long you can prove control over the domain name.
The Extended Validation SSL certificates require way more verification. These are the ones you usually see for web shops and have this "green" bar in the web browser.
Best regards,
Theo Geurts



On 15-8-2016 20:16, Ayden Férdeline wrote:
If I understand this use case correctly, when an SSL certificate is purchased, your system is sending an automated message to the registrant or the technical contact's email address as listed in WHOIS records. If the recipient of this email clicks a URL, it validates the certificate?

If this is the case, I would like to understand how commonplace this practice is. Are these emails only sent once, when the certificate is initially purchased? I cannot imagine a significant volume of these certificates are purchased on a daily basis, and I struggle to believe that there could be more than, say, 200 such certification bodies globally. If my assumptions are correct, are we talking, here, about a use case applicable to only a handful of businesses worldwide? Businesses selling these certificates for large volumes of money?

The other issue I see is that there is very little verification of information in WHOIS as it stands today. To rely on the email addresses stored in WHOIS to authenticate a certificate strikes me as flawed. Would it not be more appropriate for the Certification Authority to visit the domain name in question, call the phone number listed on their website, and to clarify with the contact that claims to have purchased your service that they have purchased your service? If the website does not list even the number for a switchboard, perhaps that should raise red flags?

- Ayden

-------- Original Message --------
Subject: [gnso-rds-pdp-wg] Use case for WHOIS/RDP
Local Time: August 15, 2016 6:40 PM
UTC Time: August 15, 2016 5:40 PM
From: Geoffrey_Noakes at symantec.com<mailto:Geoffrey_Noakes at symantec.com>
To: gnso-rds-pdp-wg at icann.org<mailto:gnso-rds-pdp-wg at icann.org>


I’ve attached a use case for WHOIS/RDP.

Thanks…

Geoff




From: Lisa Phifer [mailto:lisa at corecom.com]
Sent: Monday, August 15, 2016 10:37 AM
To: Geoffrey Noakes <Geoffrey_Noakes at symantec.com><mailto:Geoffrey_Noakes at symantec.com>
Subject: RE: Use Case



Hi Geoff, it's <gnso-rds-pdp-wg at icann.org<mailto:gnso-rds-pdp-wg at icann.org>>

For further info, see mailing list archives:  http://mm.icann.org/pipermail/gnso-rds-pdp-wg/

As a WG member, you are on that mailing list, so if you're not currently receiving email from that list, please let me or the GNSO secretariat gnso-secs at icann.org<mailto:gnso-secs at icann.org> know.

Thanks again
Lisa


At 11:19 AM 8/15/2016, Geoffrey Noakes wrote:



Lisa, what is the “WG email list” email address?

From: Lisa Phifer [ mailto:lisa at corecom.com]
Sent: Monday, August 15, 2016 10:17 AM
To: Geoffrey Noakes <Geoffrey_Noakes at symantec.com<mailto:Geoffrey_Noakes at symantec.com>>
Subject: RE: Use Case

Thanks Geoff and welcome back. I hope you had an excellent vacation.

I will upload your case to the WG's table of example use cases and see that the case is included on the 23 August call agenda.

In addition, it is best if you would also email this example use case directly to the WG email list so that any comments that may be provided on the mailing list in advance of the call will be sent to your attention.

Best, Lisa


At 11:11 AM 8/15/2016, you wrote:

+Lisa (we had a side conversation about this), plus some Symantec employees who are involved in this

Chuck, I am just back from a week of PTO.  I’ve attached a markup of a document originally authored by Scott Hollenbeck of VeriSign, which is essentially the use case for a CA’s use of WHOIS.

I would prefer the August 23 date – I am on jury duty the week of August 29-September 2.

Thanks…

Geoff



From: Gomes, Chuck [ mailto:cgomes at verisign.com]
Sent: Monday, August 15, 2016 9:53 AM
To: Geoffrey Noakes < Geoffrey_Noakes at symantec.com<mailto:Geoffrey_Noakes at symantec.com>>
Cc: RDS-Leaders-List ( gnso-next-gen-rds-lead at icann.org<mailto:gnso-next-gen-rds-lead at icann.org>) < gnso-next-gen-rds-lead at icann.org<mailto:gnso-next-gen-rds-lead at icann.org>>
Subject: Use Case

Geoff,

You volunteered to prepare a use case for Certificate Authorities.  We hope to discuss that use case in the WG meeting on either August 23 or August 30?  Which date would work better for you?  In either case, we would need the use case to be submitted to the WG list 24 hours in advance.

Hope you are having a good vacation.

Chuck





_______________________________________________

gnso-rds-pdp-wg mailing list

gnso-rds-pdp-wg at icann.org<mailto:gnso-rds-pdp-wg at icann.org>

https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg


_______________________________________________
gnso-rds-pdp-wg mailing list
gnso-rds-pdp-wg at icann.org<mailto:gnso-rds-pdp-wg at icann.org>
https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg




---------- Forwarded message ----------
From: Mike Prettejohn <mhp at netcraft.com<mailto:mhp at netcraft.com>>
To: Diana Marin Severino <Diana_Marin_Severino at symantec.com<mailto:Diana_Marin_Severino at symantec.com>>, Sue Coakley <Sue_Coakley at symantec.com<mailto:Sue_Coakley at symantec.com>>, Vijay NS <Vijay_NS at symantec.com<mailto:Vijay_NS at symantec.com>>, Sonya Perez <Sonya_Perez at symantec.com<mailto:Sonya_Perez at symantec.com>>, Eric Lipman <Eric_Lipman at symantec.com<mailto:Eric_Lipman at symantec.com>>, Laura Aviles <Laura_Aviles at symantec.com<mailto:Laura_Aviles at symantec.com>>, Jeffrey Whale <Jeffrey_Whale at symantec.com<mailto:Jeffrey_Whale at symantec.com>>, Alex Wong <Alex_Wong at symantec.com<mailto:Alex_Wong at symantec.com>>, Landon Borup <Landon_Borup at symantec.com<mailto:Landon_Borup at symantec.com>>, Alain Allen <Alain_Allen at symantec.com<mailto:Alain_Allen at symantec.com>>, Frank Agurto-Machado <Frank_Agurto-Machado at symantec.com<mailto:Frank_Agurto-Machado at symantec.com>>, Charlene Mike-Billstrom <Charlene_Mike-Billstrom at symantec.com<mailto:Charlene_Mike-Billstrom at symantec.com>>, Rick Andrews <Rick_Andrews at symantec.com<mailto:Rick_Andrews at symantec.com>>, Anna Sampson <Anna_Sampson at symantec.com<mailto:Anna_Sampson at symantec.com>>, Eiji Yahagi <Eiji_Yahagi at symantec.com<mailto:Eiji_Yahagi at symantec.com>>, Tomonori Sato <Tomonori_Sato at symantec.com<mailto:Tomonori_Sato at symantec.com>>, Christiaan De Villiers <Christiaan_DeVilliers at symantec.com<mailto:Christiaan_DeVilliers at symantec.com>>, Dean Coclin <Dean_Coclin at symantec.com<mailto:Dean_Coclin at symantec.com>>, Hari Veladanda <Hari_Veladanda at symantec.com<mailto:Hari_Veladanda at symantec.com>>, Robert Hoblit <Robert_Hoblit at symantec.com<mailto:Robert_Hoblit at symantec.com>>, Marisa Luke <Marisa_Luke at symantec.com<mailto:Marisa_Luke at symantec.com>>, Roxane Divol <Roxane_Divol at symantec.com<mailto:Roxane_Divol at symantec.com>>, Norie Sato <Norie_Sato at symantec.com<mailto:Norie_Sato at symantec.com>>, Masato Hayashi <Masato_Hayashi at symantec.com<mailto:Masato_Hayashi at symantec.com>>, DL-VSN-Data Analysis <DL-VSN-DataAnalysis at symantec.com<mailto:DL-VSN-DataAnalysis at symantec.com>>, Bill Ng <Bill_Ng at symantec.com<mailto:Bill_Ng at symantec.com>>, Geoffrey Noakes <Geoffrey_Noakes at symantec.com<mailto:Geoffrey_Noakes at symantec.com>>, Tracy Chao <Tracy_Chao at symantec.com<mailto:Tracy_Chao at symantec.com>>, Tri Tang1 <Tri_Tang at symantec.com<mailto:Tri_Tang at symantec.com>>, Jeff Barto <Jeff_Barto at symantec.com<mailto:Jeff_Barto at symantec.com>>, Theresa Garza <Theresa_Garza at symantec.com<mailto:Theresa_Garza at symantec.com>>, Sven Skerka <Sven_Skerka at symantec.com<mailto:Sven_Skerka at symantec.com>>, Helen Bates <Helen_Bates at symantec.com<mailto:Helen_Bates at symantec.com>>, Jonathan Skinner <Jonathan_Skinner at symantec.com<mailto:Jonathan_Skinner at symantec.com>>, Kevin Brown <Kevin_Brown at symantec.com<mailto:Kevin_Brown at symantec.com>>, Minori Nakanishi <Minori_Nakanishi at symantec.com<mailto:Minori_Nakanishi at symantec.com>>, "leeanne_dewit at netcraft.com<mailto:leeanne_dewit at netcraft.com>" <leeanne_dewit at netcraft.com<mailto:leeanne_dewit at netcraft.com>>, "antec.com at netcraft.com<mailto:antec.com at netcraft.com>" <antec.com at netcraft.com<mailto:antec.com at netcraft.com>>, "tristan_fourcault at symantec.com<mailto:tristan_fourcault at symantec.com>" <tristan_fourcault at symantec.com<mailto:tristan_fourcault at symantec.com>>, Jun Kamimura <Jun_Kamimura at symantec.com<mailto:Jun_Kamimura at symantec.com>>, Shusuke Nakagawa <Shusuke_Nakagawa at symantec.com<mailto:Shusuke_Nakagawa at symantec.com>>, Lisa Low <Lisa_Low at symantec.com<mailto:Lisa_Low at symantec.com>>, Alejandro Borgia <Alejandro_Borgia at symantec.com<mailto:Alejandro_Borgia at symantec.com>>, Belinda Charleson <Belinda_Charleson at symantec.com<mailto:Belinda_Charleson at symantec.com>>, Timothy Willey <Timothy_Willey at symantec.com<mailto:Timothy_Willey at symantec.com>>, Wasi Wahid <Wasi_Wahid at symantec.com<mailto:Wasi_Wahid at symantec.com>>, Jo Ann Lambkin <JoAnn_Lambkin at symantec.com<mailto:JoAnn_Lambkin at symantec.com>>, Abhijit Solanki <Abhijit_Solanki at symantec.com<mailto:Abhijit_Solanki at symantec.com>>, Donald Baker <Donald_Baker at symantec.com<mailto:Donald_Baker at symantec.com>>, Harbir Singh <Harbir_Singh at symantec.com<mailto:Harbir_Singh at symantec.com>>, Michael Klieman <Michael_Klieman at symantec.com<mailto:Michael_Klieman at symantec.com>>, Takashi Abe <Takashi_Abe at symantec.com<mailto:Takashi_Abe at symantec.com>>, Helen Lew <Helen_Lew at symantec.com<mailto:Helen_Lew at symantec.com>>, Jack Kato <Jack_Kato at symantec.com<mailto:Jack_Kato at symantec.com>>, Nicolas Popp <Nicolas_Popp at symantec.com<mailto:Nicolas_Popp at symantec.com>>, Bartosz Begej <Bartosz_Begej at symantec.com<mailto:Bartosz_Begej at symantec.com>>, Jon Kerr <Jon_Kerr at symantec.com<mailto:Jon_Kerr at symantec.com>>, Roxane Jerbi <Roxane_Jerbi at symantec.com<mailto:Roxane_Jerbi at symantec.com>>, Tim Gallo <tim_gallo at symantec.com<mailto:tim_gallo at symantec.com>>, Gautam Kanaparthi <Gautam_Kanaparthi at symantec.com<mailto:Gautam_Kanaparthi at symantec.com>>, Thomas La <Thomas_La at symantec.com<mailto:Thomas_La at symantec.com>>, James Duff <James_Duff at symantec.com<mailto:James_Duff at symantec.com>>, "aidan_calvert at symantec.com<mailto:aidan_calvert at symantec.com>" <aidan_calvert at symantec.com<mailto:aidan_calvert at symantec.com>>, Ian McShane <Ian_Mcshane at symantec.com<mailto:Ian_Mcshane at symantec.com>>, Yoshimasa Hiraiwa <Yoshimasa_Hiraiwa at symantec.com<mailto:Yoshimasa_Hiraiwa at symantec.com>>, Robert Lin <Robert_Lin at symantec.com<mailto:Robert_Lin at symantec.com>>, Albert Cooley <Albert_Cooley at symantec.com<mailto:Albert_Cooley at symantec.com>>, Mirco Reimann <Mirco_Reimann at symantec.com<mailto:Mirco_Reimann at symantec.com>>, Jessica Crewse <Jessica_Crewse at symantec.com<mailto:Jessica_Crewse at symantec.com>>, Jason Luong <Jason_Luong at symantec.com<mailto:Jason_Luong at symantec.com>>, Rory Tavares <Rory_Tavares at symantec.com<mailto:Rory_Tavares at symantec.com>>, Asad Faruqui <Asad_Faruqui at symantec.com<mailto:Asad_Faruqui at symantec.com>>, Karina Stiller <Karina_Stiller at symantec.com<mailto:Karina_Stiller at symantec.com>>, Pavan Bhat <Pavan_Bhat at symantec.com<mailto:Pavan_Bhat at symantec.com>>, "jeannette_duong at symantec.c<mailto:jeannette_duong at symantec.c>" <jeannette_duong at symantec.c<mailto:jeannette_duong at symantec.c>>, "om at netcraft.com<mailto:om at netcraft.com>" <om at netcraft.com<mailto:om at netcraft.com>>, Terri Parker <Terri_Parker at symantec.com<mailto:Terri_Parker at symantec.com>>, "K.J.Hari Hara Krishnan" <Hari_Krishnan at symantec.com<mailto:Hari_Krishnan at symantec.com>>, Anna Brannan <Anna_Brannan at symantec.com<mailto:Anna_Brannan at symantec.com>>, Graeme Watts <Graeme_Watts at symantec.com<mailto:Graeme_Watts at symantec.com>>, Russel Scovel <Russel_Scovel at symantec.com<mailto:Russel_Scovel at symantec.com>>, Maren Peasley <maren_peasley at symantec.com<mailto:maren_peasley at symantec.com>>, Tiphany Zellers <Tiphany_Zellers at symantec.com<mailto:Tiphany_Zellers at symantec.com>>, Randy Clark <randy_clark at symantec.com<mailto:randy_clark at symantec.com>>, Susanne Lambert <Susanne_Lambert at symantec.com<mailto:Susanne_Lambert at symantec.com>>, Alex Black <Alex_Black at symantec.com<mailto:Alex_Black at symantec.com>>, Davin Pick <Davin_Pick at symantec.com<mailto:Davin_Pick at symantec.com>>, Akhil Verma <Akhil_Verma at symantec.com<mailto:Akhil_Verma at symantec.com>>, Micheal Brown <Micheal_Brown at symantec.com<mailto:Micheal_Brown at symantec.com>>, Lee-Lin Thye <Lee-Lin_Thye at symantec.com<mailto:Lee-Lin_Thye at symantec.com>>, Suhasini Anand <Suhasini_Anand at symantec.com<mailto:Suhasini_Anand at symantec.com>>, Victoria Cloutier <Victoria_Cloutier at symantec.com<mailto:Victoria_Cloutier at symantec.com>>, Philip Antoniadis <Philip_Antoniadis at symantec.com<mailto:Philip_Antoniadis at symantec.com>>, Ruth Singh <Ruth_Singh at symantec.com<mailto:Ruth_Singh at symantec.com>>, Thiago Lacerda <Thiago_Lacerda at symantec.com<mailto:Thiago_Lacerda at symantec.com>>, "nilanjana_majumdar at symantec.com<mailto:nilanjana_majumdar at symantec.com>" <nilanjana_majumdar at symantec.com<mailto:nilanjana_majumdar at symantec.com>>, "Sarah Mellor (CS)" <Sarah_Mellor at symantec.com<mailto:Sarah_Mellor at symantec.com>>, Valerie Tsai <Valerie_Tsai at symantec.com<mailto:Valerie_Tsai at symantec.com>>, Deepika Chauhan <Deepika_Chauhan at symantec.com<mailto:Deepika_Chauhan at symantec.com>>, Angelique Pereira <Angelique_Pereira at symantec.com<mailto:Angelique_Pereira at symantec.com>>, Rachel Yokum <Rachel_Yokum at symantec.com<mailto:Rachel_Yokum at symantec.com>>, Charlotte Pommier <Charlotte_Pommier at symantec.com<mailto:Charlotte_Pommier at symantec.com>>, Ramana Murthy <Ramana_Murthy at symantec.com<mailto:Ramana_Murthy at symantec.com>>
Cc:
Date: Thu, 7 Jul 2016 16:27:35 +0000
Subject: Netcraft Secure Server Survey July 2016

Follow us on Twitter<http://www.twitter.com/Netcraft> & Facebook<http://www.facebook.com/Netcraft>

<http://www.netcraft.com/>
<ATT00001.png>


Netcraft Secure Server Survey July 2016




The Netcraft Secure Server Survey for July 2016 is now available.

You can find the data to which you subscribe at:

  *   https://ssl.netcraft.com/surveys/analysis/https/2016/Jul/
  *   https://ssl.netcraft.com/clients/iug3ore/symantec//Jul2016domain.csv.gz
  *   https://ssl.netcraft.com/clients/iug3ore/symantec//Jul2016.csv.gz

July 2016 Highlights
July Trends

Netcraft's July 2016 SSL Server Survey found 5,516,471 distinct valid third-party certificates<https://ssl.netcraft.com/surveys/analysis/https/2016/Jul/glossary#valid_third_party>, representing a monthly gain of 188,016 (+3.5%).

Let's Encrypt gained a further 120,000 certificates in July, making up 64% of the total increase across all certificate authorities this month. This gain was enough to push Let's Encrypt into third place, with a total of 770,000 certificates.

GoDaddy has fallen to fourth place after losing 4,900 certificates since last month, and now has a market share of 13.52%. GoDaddy remains significantly ahead of fifth-placed GlobalSign, leading by 406,000 certificates and 7.35 percentage points of market share.

Comodo also grew significantly this month, increasing its total count of certificates by 56,000. Much of this growth can be attributed to its Western Digital and cPanel, Inc. sub-CAs . Due to the sheer volume of Let's Encrypt's growth, Comodo lost a very small amount of market share, dropping to 30.52%, despite having the second-largest absolute gain of certificates.

GlobalSign lost 4,900 certificates as 12,000 Shopify, Inc. web stores replaced GlobalSign certificates with ones issued by Let's Encrypt.

Within the DV market, Let's Encrypt now has slightly more than half as many DV certificates as the first-placed Comodo. Although Symantec only took second place in the DV market from GoDaddy last month, it has now been relegated to third place despite gaining 6,000 certificates and increasing its lead over GoDaddy to 25,000.

The DV market has seen significant change over the past 12 months: In the July 2015 survey GoDaddy was the largest issuer of DV certificates with a market share of 30.5% followed closely by Symantec and Comodo, and there were no Let's Encrypt certificates. There are now 1.8 million more DV certificates (+73.2%) with a majority of this growth focused in just two CAs: Comodo (+871,000) and Let's Encrypt (+770,000).

The Extended Validation market once again saw Comodo gain the most certificates with an increase of 494. Almost all of the top ten EV certificate issuers gained certificates this month with Network Solutions being the lone exception, losing 23. Symantec maintains its dominant market position at 48.4% market share.

Symantec continues to achieve the most estimated monthly revenue (using list prices<https://ssl.netcraft.com/surveys/analysis/https/2016/Jul/CMatch/pricing/>) from its certificates; it issued 87,000 certificates in March to give estimated monthly revenue of $28.9 million. Comodo issued more than twice as many certificates, 205,000, yet has significantly smaller estimated revenue of $18.9 million. A majority of Symantec's revenue is derived from the much more expensive Organisation Validated and Extended Validation certificates, markets in which Comodo plays a smaller part.

Comodo abandons attempt to trademark "Let's Encrypt"

In October 2015 Comodo filed three trademark applications for "Let's Encrypt", "Comodo Let's Encrypt" and "Let's Encrypt with Comodo". All three applications were abandoned on June 24th 2016 after Let's Encrypt publicly pleaded<https://letsencrypt.org//2016/06/23/defending-our-brand.html>for Comodo to abandon its trademark application. Let's Encrypt claimed its lawyers had been requesting Comodo drop its applications since March 2016 without success.

After Let's Encrypt's blog post was published, Comodo's CEO engaged with commentators on Comodo's forum<https://forums.comodo.com/general-discussion-off-topic-anything-and-everything/shame-on-you-comodo-t115958.0.html;msg837411#msg837411>alleging that Let's Encrypt had copied Comodo's 90-day certificate business model. Later in the same thread, Robin Alden confirmed that Comodo was intending to let the trademark application lapse and had no intention of pursuing them after Let's Encrypt became operational. He explained that "Josh [Aas, the ISRG Executive Director] was wrong when he said we'd 'refused to abandon our applications'. We just hadn't told LE we would leave them to lapse."

Let's Encrypt was officially announced in November 2014, almost a year before Comodo's trademark application. It issued its first certificate in September 2015, before it launched in April 2016 after a short public beta period.

ChaCha20-Poly1305 Cipher Suites

RFC 7905<https://tools.ietf.org/html/rfc7905>, published in June 2016, specifies seven new cipher suites for TLS that combine the ChaCha20 variant of the ChaCha stream cipher with the Poly1305 one-time authenticator method. The new cipher suites provide a replacement to the RC4 stream cipher which was prohibited for TLS<https://tools.ietf.org/html/rfc7465> in February 2015 on the grounds that it no longer provided a sufficient level of security.

Both ChaCha20 and Poly1305 are designed with high performance in mind and the combination of the two is reportedly comparable to RC4 in speed.

ChaCha20-Poly1305 isn't new; a draft specification<https://tools.ietf.org/html/draft-agl-tls-chacha20poly1305-04> written by Google was published in November 2013 which proposed three cipher suites. The Chrome browser has contained support for this older version of the specification since November 2013 and CloudFlare began using it in February 2015. Some changes have been made over the course of the standardisation process which has now been completed and the RFC approved.

Apple updates App Transport Security

Apple announced at its Worldwide Developer Conference (WWDC) [slides]<http://devstreaming.apple.com/videos/wwdc/2016/706sgjvzkvg6rrg9icw/706/706_whats_new_in_security.pdf> that all App Store apps will be required to use App Transport Security from the start of 2017. ATS is designed to improve the security of apps by specifying minimum requirements<https://developer.apple.com/library/ios/documentation/General/Reference/InfoPlistKeyReference/Articles/CocoaKeys.html#//apple_ref/doc/uid/TP40009251-SW35> for the HTTP connections that they make.

ATS requires that all connections are HTTPS over TLS 1.2, that the cipher suite must support forward secrecy, and that the certificate must be signed using the SHA-2 hashing algorithm.

ATS was introduced with iOS 9 in September 2015 and is enabled by default although it is currently possible to specify that ATS should be disabled for connections to certain domains or disabled globally. After the end of 2016, exceptions to the fundamental aspects of ATS will only be granted to Apps with valid justification – for example if you must communicate with a third-party service that you cannot control. Other exceptions, such as the requirement for perfect forward secrecy may be automatically approved. Apple also announced the introduction of support for Certificate Transparency. In order to enforce CT, the developer must specify a list of domains for which to require CT, and in order for the check to pass Apple require proofs from at least two CT logs.

StartCom launch and then retract StartEncrypt

On 6th June, StartCom announced StartEncrypt<https://www.startssl.com/NewsDetails?date=20160606>, a product designed to automatically acquire and install certificates using its StartAPI. On the 4th July, StartCom announced<https://www.startssl.com/NewsDetails?date=20160606>that StartEncrypt would be replaced with a new protocol based on ACME. ACME is undergoing IETF standardisation after being first used by Let's Encrypt.

StartAPI was launched at the end of April 2016 and allowed users to programmatically acquire certificates as well as complete the validation processes required to prove domain ownership. StartEncrypt was the official client application which was released just over a month later. The proprietary software can be used to obtain any class of certificate and install it automatically both on Windows and Linux servers.

A number of serious issues<https://www.computest.nl/blog/startencrypt-considered-harmful-today/> have already been discovered since the release of the initial version of the StartEncrypt client, these allowed a user to gain valid SSL certificates by tampering with the URL used to verify control of a domain. StartCom was quick to respond to this issue, taking the API offline on the same day that the issue was disclosed and issuing an updated client less than a week later.

The issues lay with the way in which ownership of the domain was verified. In order to prove domain ownership the user must upload a file to a specified path on the domain, but the path used could be specified by the user, the check also followed redirects and didn't verify the file type of the response it received. Combined these issues led to users being able to acquire a valid certificate for any website that allowed file uploading or contained an open redirect, examples include sites such as Dropbox, GitHub, Facebook, PayPal and Google. While the vulnerability was demonstrated with a proof of concept, there is no evidence that the API was mis-used or certificates issued for domains which the applicant did not control.

Another bug<https://www.startssl.com/NewsDetails?date=20160323>in the StartEncrypt system meant that certificates issued using the program were not logged to Certificate Transparency servers. StartCom had stated that all of its SSL certificates would be published to CT logs as of 23rd March.

Let's Encrypt leak user email addresses

On the 11th June an automated email script designed to alert users of an update to Let's Encrypt's subscriber agreement accidentally also leaked the email addresses of 7,617 users. The script prepended the email addresses of the users it had already emailed to the beginning of the message.

Let's Encrypt were alerted to the mistake 33 minutes after the emails began to send and subsequently stopped the script after it had sent 7,618 emails, 1.9% of the total it was expected to send.

An initial statement<https://community.letsencrypt.org/t/email-address-disclosures-preliminary-report-june-11-2016/16867> by Josh Aas the Executive Director of ISRG was published less than two hours after the incident originally occurred with a longer analysis<https://community.letsencrypt.org/t/email-address-disclosures-june-11-2016/17025> following on the 14th June.

Symantec acquire Blue Coat

Symantec has agreed to acquire the market leading web security company Blue Coat for $4.65 billion<https://www.symantec.com/en/uk/about/newsroom/press-releases/2016/symantec_0612_01>. The deal will see Blue Coat CEO Greg Clark appointed as the new CEO of Symantec, the post is currently vacant following Mike Brown's departure in April.

The acquisition will boost Symantec's enterprise security offerings and is expected to mean that 62% of the company's revenue<http://www.reuters.com/article/us-bluecoat-m-a-symantec-idUSKCN0YZ0BM> will be derived from the enterprise security market.

Blue Coat and Symantec recently made headlines<http://www.theregister.co.uk/2016/05/27/blue_coat_ca_certs/> after Symantec issued an intermediate CA certificate for Blue Coat Public Services. Blue Coat creates security systems that include the capability to man-in-the-middle encrypted traffic, designed for use in corporate networks. Some reports of the use of Blue Coat systems by foreign governments have prompted criticism, although Blue Coat has consistently denied having any direct involvement.

The existence of the sub-CA was incorrectly reported as allowing Blue Coat the ability to create trusted certificates for arbitrary domains; however, Symantec confirmed<http://www.symantec.com/connect/blogs/symantec-protocol-keeps-private-keys-its-control> that "private keys for the Blue Coat Intermediate CA were in Symantec's control at all times" and "the only certificates that could be issued from this Intermediate CA were limited solely to ones for the bluecoat.com<http://bluecoat.com/> domain.".

Other News

  *   Microsoft update cipher suites<https://support.microsoft.com/en-us/kb/3161639> for IE and Edge.
  *   Mozilla adding support for reading from Windows Cert Stores<https://cabforum.org/2016/05/25/2016-05/> to Firefox.
  *   GitHub Pages officially support HTTPS<https://github.com/blog/2186-https-for-github-pages> and new sites enforce it.
  *   Amazon is now HTTPS site wide.
  *   UK government updates security guidelines<https://gdstechnology.blog.gov.uk/2016/06/28/updating-our-security-guidelines-for-digital-services/> to enforce HTTPS, HSTS and DMARC by October 2016.
  *   Microsoft Edge adds support for TLS False Start and TCP Fast Open<https://blogs.windows.com/msedgedev/2016/06/15/building-a-faster-and-more-secure-web-with-tcp-fast-open-tls-false-start-and-tls-1-3/>.


Copyright © Netcraft 2016. All Rights Reserved.


_______________________________________________
gnso-rds-pdp-wg mailing list
gnso-rds-pdp-wg at icann.org<mailto:gnso-rds-pdp-wg at icann.org>
https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20160816/d2720f19/attachment.html>

More information about the gnso-rds-pdp-wg mailing list