Domain services in addition to certificate services

Although I completely agree with all that you have said, I would like to offer a suggestion that may make things a little easier overall for everyone involved.

The idea is to allow for the inclusion of domain name registry services to complement the certificate services.

  1. LE would be 100% certain of the domains each customer controls. Essentially removing the challenge authentication step and problems arising from them.
  2. The certificates can be issued for periods much longer than 90 days. Possible for up to the maximum allowed domain renewal periods ~39 months?. Naturally, measures should be taken to revoke certificates that change out from LE domain registration services - to cover cases like when a domain is sold or deregistered.

I believe that if done right, offering domain registry services, as an added service, could add a steady revenue stream, increase customer loyalty, reduce the overhead and frequency of certificate issuance, thus reducing customer complaints, and also reduce the risk and complexity of securing the web.

Note: I did not come up with this idea on my own. I noticed it as part of the Symantec Encryption Everywhere program.

1 Like

Thanks for the idea! I've moved it to a new thread since it's a pretty separate topic (though I see how it relates to the original thread, in terms of reducing the support burden).

This is an interesting idea, but I think getting into the domain name registrar business is a pretty big deal; we'd need to make arrangements with lots of different registries.

It's worth noting that this is coming down to 2 years. But also, running the registry doesn't solve all of the issues with longer certificates, like recovering from key compromise.

2 Likes

In my opinion, LE did a very reasonable step towards shorter certificate lifetimes. This should be enforced. Automatic revocation on transfer-out must be discussed very deeply: what if the domain just changes the registrar but wants to keep the certificates?

Further more: even having the customer's data via domain registration, the authorization step cannot be simply removed. Domain ownership and technical delegation are two distinct things, otherwise ISPs weren't able to issue certificates in an automatic way without user intervention.

Lets Encrypt should stay an independent CA, if the ISRG is about to build a registrar service, this should not in any way be related to Let's Encrypt.

2 Likes

Then they can renew their certs via any of the current methods (with 90 day limits).
Or, if the remaining life is less then 90 days then it makes little difference.

If we accept the responsibility, and maybe even prove that we are responsible, we should be allowed longer time.
I think that whole argument is mute when only ciphers with forwarding secrecy are used.
The real risk is in private key compromise and LE allows for private key reuse.
If the private key is unchanged and compromised, what difference would changing the public cert everyday make?

Then those two separate entities would be unable to collaborate. As is today with LE and every registrar.
Removing the whole point/advantage of the proposal.
There are many reasons on both sides - I still feel that the pros outweigh the cons.

Even keeping the 90 day limit, combining CA and registrar services would add another method of authentication and could make things easier for wild card certs (due: Jan 2018).

1 Like

Well, you mentioned revokation upon sale or close. Sale could mean transfer-out, and this is not an atomic operation. Would there be a one-day period in which the current certificate stays unrevoked?

One more thing to add: Let's Encrypt is a non-profit, ISRG is a public benefit organization. Symantec is neither and sold their whole CA business in the mean time, due to some bad security issues.

It could actual be longer than one day (but no longer than 90 days) and could be specified in the agreement.
I would think that no longer than 30 days would be more than sufficient.

1 Like


Why ninety-day lifetimes for certificates?
Nov 9, 2015 • Josh Aas, ISRG Executive Director

https://letsencrypt.org/about/
"We want to create a more secure and privacy-respecting Web."
One of the key principles behind Let’s Encrypt is:
Secure: Let’s Encrypt will serve as a platform for advancing TLS security best practices, both on the CA side and by helping site operators properly secure their servers.

But since that writing:
3B accounts were stolen from Yahoo!.
360M user names and passwords were stolen from MySpace.
145.5M people lost PII from Equifax.
130M credit and debit card numbers were exposed from Heartland.

So my question is:

  1. How does shortening the lifetime make for “a more secure” Internet?

Taking into account that more than 10% of the ‌Internet uses CDNs - which is a glaringly obvious “man-in-the-middle” just waiting to be exploited.
Data in transit is a moving target which is much harder to hit than your data at rest at Target® - yes, pun intended - 41M customer payment card accounts were breached form Target Brands, Inc. in 2013.

Securing the Internet would be better served by securing all the data; both, while at rest and while in motion - especially when data is handled by CDNs.
If the data itself is verifiably encrypted/signed, the delivery method becomes almost irrelevant.

To that end, I propose we basically crypto-lock all our “valuable” information, then store it anywhere, and only provide decryption keys to those that require access.

1 Like

well the “but since that writing” point most probably have NOTHING to do with HTTPS in the first place but the fact that
a) the server was not secured so attackers could get the data
b) the data, especially the passwords were badly secured (e.g. in yahoo’s case hashed with MD5)

as you said, data at rest vs at target. and HTTPS cannot be used for data at rest, you need something else for that, like doing the handling of payments and other secure data on a "“blackbox server” which is even a blackbox for the web server and the webserver just forwards all the secure data to it and make sure the server can ONLY be accessed by those APIs from any server, and only a highly secure admin login can get into the server itself.

so the webserver would tell the Security server “I have a login for user x with password y” and then the sec server could
a) also handle the sessions
b) just tell a (signed) Okay or not okay message and the web server then does the session handling.

and for things like Payments, the webserver would just tell the securityserver “The user x wants to pay amount y with CC information z”

and now there are 2 options for the security server as well
a) the security server handles all the payment interactions by itself and replies with the result
b) the security server tells the web server how to interact with the payment service (API URLs and so on) and the webserver does the interaction.

and while I honestly think that 90 days are annoying at any place where you cant properly automate the stuff there certainly are good reasons for shorter cert times.

Simply said, revocation handling on anything except for EV certs is plain trash.

go open chrome on your phone and type in:
revoked.grc.com

more likely than not you will not get a cert warning but a site stating that your browser is revocation unaware.

more on that here:
https://www.grc.com/revocation.htm

CDNs on the other end, are their complete own problem, yeah it is possible that CDNs can get problems, but especially making the delivery of static stuff, especially BIG static stuff or static stuff that gets a metric ton of accesses (or both) can really have help from that standpoint, Steam for example is using akamai as a CDN, and guess what, even they get DoS big time when the Summer and xmas come due to the sheer amount of people. imagine the situation without CDN, with the servers experiencing a much heavier load due to also having to also deal with static files.

I would much rather imagine the situation with a secure CDN system :sunny:

[ADD]

Yes, but a cert not limited to just HTTPS.

1 Like