This section belies a misunderstanding of the TCP/IP layers:
Generally speaking, all data in transit should be encrypted at the [transport layer](https://en.wikipedia.org/wiki/Transport_layer) ([OSI layer](https://en.wikipedia.org/wiki/OSI_model) 4). Previous hurdles such as CPU performance and private key/certificate management are now handled by CPUs having instructions designed to accelerate encryption (eg: [AES support](https://en.wikipedia.org/wiki/AES_instruction_set)) and private key and certificate management being simplified by services like [LetsEncrypt.org](https://LetsEncrypt.org) with major cloud vendors providing even more tightly integrated certificate management services for their specific platforms.
Beyond securing the transport layer, it is important to determine what data needs encryption at rest as well as what data needs extra encryption in transit (at the [application layer](https://en.wikipedia.org/wiki/Application_layer), OSI layer 7). For example, passwords, credit card numbers, health records, personal information, and business secrets require extra protection, especially if that data falls under privacy laws, e.g., EU's General Data Protection Regulation (GDPR), or regulations such as PCI Data Security Standard (PCI DSS). For all such data:
The first paragraph seems to be arguing that HTTPS (the main protocol LetsEncrypt issues certificates for) runs at the transport layer, when a sidebar in the linked Wikipedia page shows HTTPS, SSH, and other encrypted protocols as being in the Application layer. In fact, the word "encrypt" does not even appear on the Wikipedia Transport Layer page, because encryption is not part of TCP or UDP.
The second paragraph confuses things further by saying that data may need extra encryption at the application layer, which is the only place it can actually happen.
For instance, say I wanted to follow this advice and add transport layer encryption to my HTTPS server. How would I do that? I don't want to completely rule out that this is possible--I haven't been to an IETF meeting in years--but I suspect no such mechanism exists and this section needs to be reworded. Here's a suggestion:
Generally speaking, all data in transit should be encrypted at the [application layer](https://en.wikipedia.org/wiki/Application_layer) ([OSI layer](https://en.wikipedia.org/wiki/OSI_model) 7). Previous hurdles such as CPU performance and private key/certificate management are now handled by CPUs having instructions designed to accelerate encryption (eg: [AES support](https://en.wikipedia.org/wiki/AES_instruction_set)) and private key and certificate management being simplified by services like [LetsEncrypt.org](https://LetsEncrypt.org) with major cloud vendors providing even more tightly integrated certificate management services for their specific platforms.
Beyond securing the application layer, it is important to determine what data needs encryption at rest. For example, passwords, credit card numbers, health records, personal information, and business secrets require extra protection, especially if that data falls under privacy laws, e.g., EU's General Data Protection Regulation (GDPR), or regulations such as PCI Data Security Standard (PCI DSS). For all such data:
This section belies a misunderstanding of the TCP/IP layers:
The first paragraph seems to be arguing that HTTPS (the main protocol LetsEncrypt issues certificates for) runs at the transport layer, when a sidebar in the linked Wikipedia page shows HTTPS, SSH, and other encrypted protocols as being in the Application layer. In fact, the word "encrypt" does not even appear on the Wikipedia Transport Layer page, because encryption is not part of TCP or UDP.
The second paragraph confuses things further by saying that data may need extra encryption at the application layer, which is the only place it can actually happen.
For instance, say I wanted to follow this advice and add transport layer encryption to my HTTPS server. How would I do that? I don't want to completely rule out that this is possible--I haven't been to an IETF meeting in years--but I suspect no such mechanism exists and this section needs to be reworded. Here's a suggestion: