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

Greg Shatan gregshatanipc at gmail.com
Mon Aug 15 22:48:21 UTC 2016 

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> 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] *On Behalf Of *Deacon, Alex
> *Sent:* Monday, August 15, 2016 3:06 PM
> *To:* Ayden Férdeline <icann at ferdeline.com>
> *Cc:* 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> 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
>
> To: icann at ferdeline.com,Geoffrey_Noakes at symantec.com
>
> 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
>
> To: 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 <lisa at corecom.com>]
>
> *Sent:* Monday, August 15, 2016 10:37 AM
>
> *To:* Geoffrey Noakes <Geoffrey_Noakes at symantec.com>
> <Geoffrey_Noakes at symantec.com>
>
> *Subject:* RE: Use Case
>
>
>
>
>
>
>
> Hi Geoff, it's <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 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 <lisa at corecom.com>]
>
> *Sent:* Monday, August 15, 2016 10:17 AM
>
> *To:* Geoffrey Noakes <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 <cgomes at verisign.com>]
>
> Sent: Monday, August 15, 2016 9:53 AM
>
> To: Geoffrey Noakes < Geoffrey_Noakes at symantec.com>
>
> Cc: RDS-Leaders-List ( gnso-next-gen-rds-lead at icann.org) <
> 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
>
> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
>
>
>
> _______________________________________________
> gnso-rds-pdp-wg mailing list
> 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>
> To: Diana Marin Severino <Diana_Marin_Severino at symantec.com>, Sue Coakley
> <Sue_Coakley at symantec.com>, Vijay NS <Vijay_NS at symantec.com>, Sonya Perez
> <Sonya_Perez at symantec.com>, Eric Lipman <Eric_Lipman at symantec.com>, Laura
> Aviles <Laura_Aviles at symantec.com>, Jeffrey Whale <
> Jeffrey_Whale at symantec.com>, Alex Wong <Alex_Wong at symantec.com>, Landon
> Borup <Landon_Borup at symantec.com>, Alain Allen <Alain_Allen at symantec.com>,
> Frank Agurto-Machado <Frank_Agurto-Machado at symantec.com>, Charlene
> Mike-Billstrom <Charlene_Mike-Billstrom at symantec.com>, Rick Andrews <
> Rick_Andrews at symantec.com>, Anna Sampson <Anna_Sampson at symantec.com>,
> Eiji Yahagi <Eiji_Yahagi at symantec.com>, Tomonori Sato <
> Tomonori_Sato at symantec.com>, Christiaan De Villiers <
> Christiaan_DeVilliers at symantec.com>, Dean Coclin <Dean_Coclin at symantec.com>,
> Hari Veladanda <Hari_Veladanda at symantec.com>, Robert Hoblit <
> Robert_Hoblit at symantec.com>, Marisa Luke <Marisa_Luke at symantec.com>,
> Roxane Divol <Roxane_Divol at symantec.com>, Norie Sato <
> Norie_Sato at symantec.com>, Masato Hayashi <Masato_Hayashi at symantec.com>,
> DL-VSN-Data Analysis <DL-VSN-DataAnalysis at symantec.com>, Bill Ng <
> Bill_Ng at symantec.com>, Geoffrey Noakes <Geoffrey_Noakes at symantec.com>,
> Tracy Chao <Tracy_Chao at symantec.com>, Tri Tang1 <Tri_Tang at symantec.com>,
> Jeff Barto <Jeff_Barto at symantec.com>, Theresa Garza <
> Theresa_Garza at symantec.com>, Sven Skerka <Sven_Skerka at symantec.com>,
> Helen Bates <Helen_Bates at symantec.com>, Jonathan Skinner <
> Jonathan_Skinner at symantec.com>, Kevin Brown <Kevin_Brown at symantec.com>,
> Minori Nakanishi <Minori_Nakanishi at symantec.com>, "
> leeanne_dewit at netcraft.com" <leeanne_dewit at netcraft.com>, "
> antec.com at netcraft.com" <antec.com at netcraft.com>, "
> tristan_fourcault at symantec.com" <tristan_fourcault at symantec.com>, Jun
> Kamimura <Jun_Kamimura at symantec.com>, Shusuke Nakagawa <
> Shusuke_Nakagawa at symantec.com>, Lisa Low <Lisa_Low at symantec.com>,
> Alejandro Borgia <Alejandro_Borgia at symantec.com>, Belinda Charleson <
> Belinda_Charleson at symantec.com>, Timothy Willey <
> Timothy_Willey at symantec.com>, Wasi Wahid <Wasi_Wahid at symantec.com>, Jo
> Ann Lambkin <JoAnn_Lambkin at symantec.com>, Abhijit Solanki <
> Abhijit_Solanki at symantec.com>, Donald Baker <Donald_Baker at symantec.com>,
> Harbir Singh <Harbir_Singh at symantec.com>, Michael Klieman <
> Michael_Klieman at symantec.com>, Takashi Abe <Takashi_Abe at symantec.com>,
> Helen Lew <Helen_Lew at symantec.com>, Jack Kato <Jack_Kato at symantec.com>,
> Nicolas Popp <Nicolas_Popp at symantec.com>, Bartosz Begej <
> Bartosz_Begej at symantec.com>, Jon Kerr <Jon_Kerr at symantec.com>, Roxane
> Jerbi <Roxane_Jerbi at symantec.com>, Tim Gallo <tim_gallo at symantec.com>,
> Gautam Kanaparthi <Gautam_Kanaparthi at symantec.com>, Thomas La <
> Thomas_La at symantec.com>, James Duff <James_Duff at symantec.com>, "
> aidan_calvert at symantec.com" <aidan_calvert at symantec.com>, Ian McShane <
> Ian_Mcshane at symantec.com>, Yoshimasa Hiraiwa <
> Yoshimasa_Hiraiwa at symantec.com>, Robert Lin <Robert_Lin at symantec.com>,
> Albert Cooley <Albert_Cooley at symantec.com>, Mirco Reimann <
> Mirco_Reimann at symantec.com>, Jessica Crewse <Jessica_Crewse at symantec.com>,
> Jason Luong <Jason_Luong at symantec.com>, Rory Tavares <
> Rory_Tavares at symantec.com>, Asad Faruqui <Asad_Faruqui at symantec.com>,
> Karina Stiller <Karina_Stiller at symantec.com>, Pavan Bhat <
> Pavan_Bhat at symantec.com>, "jeannette_duong at symantec.c"
> <jeannette_duong at symantec.c>, "om at netcraft.com" <om at netcraft.com>, Terri
> Parker <Terri_Parker at symantec.com>, "K.J.Hari Hara Krishnan" <
> Hari_Krishnan at symantec.com>, Anna Brannan <Anna_Brannan at symantec.com>,
> Graeme Watts <Graeme_Watts at symantec.com>, Russel Scovel <
> Russel_Scovel at symantec.com>, Maren Peasley <maren_peasley at symantec.com>,
> Tiphany Zellers <Tiphany_Zellers at symantec.com>, Randy Clark <
> randy_clark at symantec.com>, Susanne Lambert <Susanne_Lambert at symantec.com>,
> Alex Black <Alex_Black at symantec.com>, Davin Pick <Davin_Pick at symantec.com>,
> Akhil Verma <Akhil_Verma at symantec.com>, Micheal Brown <
> Micheal_Brown at symantec.com>, Lee-Lin Thye <Lee-Lin_Thye at symantec.com>,
> Suhasini Anand <Suhasini_Anand at symantec.com>, Victoria Cloutier <
> Victoria_Cloutier at symantec.com>, Philip Antoniadis <
> Philip_Antoniadis at symantec.com>, Ruth Singh <Ruth_Singh at symantec.com>,
> Thiago Lacerda <Thiago_Lacerda at symantec.com>, "
> nilanjana_majumdar at symantec.com" <nilanjana_majumdar at symantec.com>,
> "Sarah Mellor (CS)" <Sarah_Mellor at symantec.com>, Valerie Tsai <
> Valerie_Tsai at symantec.com>, Deepika Chauhan <Deepika_Chauhan at symantec.com>,
> Angelique Pereira <Angelique_Pereira at symantec.com>, Rachel Yokum <
> Rachel_Yokum at symantec.com>, Charlotte Pommier <
> Charlotte_Pommier at symantec.com>, Ramana Murthy <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>
> [image: Netcraft] <http://www.netcraft.com/> 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
> 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
> 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/20160815/b93b4ae4/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ATT00001.png
Type: image/png
Size: 7175 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20160815/b93b4ae4/ATT00001.png>

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