The Secure (Bitcoin) Internet

We see many sites moving more and more to application-level encryption such that they can protect the transport of sensitive data.

 

IPv6 is THE killer application for SSL. Not that SSL needs help, it is flawed.

IPv6 provides support for encryption within the protocol. This is a key differentiator, when we compare it to IPv4, where encryption was provided by the application. IPSec can be used with IPv4. That said, IPSec is tacked onto IPv4, whereas it is fundamental to IPv6. The standards require mandatory IPSec (with all the associated crypto code), it is not just an add-on. IPv6 requires crypto.

On top of that, endpoint authentication is also provided in IPv6, something that was overlooked in IPv4.

IPv6 does not come even close to solving all the world’s security woes, and nor could a simple protocol ever attempt to do such. That said, all it needs to do to kill off SSL is to:

  1. be as effective as SSL or better,
  2. have a wide deployment.

IPv6 will provide the latter point. When IPv6 finally becomes the norm, IPSec will become ubiquitous. It will be deployed far wider than SSL ever was. Next, it simplifies things for developers. Crypto is difficult. Developers make mistakes again and again in implementing crypto. The centralised control and deployment of “network crypto” is a good thing.

As for being as good or better than SSL, well SSL is flawed — it was from the start, and it remains flawed. This point is moot as it would be difficult to make the protocol worse.

IPSec allows the application to call for authentication separate from encryption for use in situations where encryption is prohibited or prohibitively expensive. This is, AH headers can provide integrity and end-point authentication without the overhead of encryption.

For most machines, Intel’s decision to incorporate AES processing into the CPU will greatly alleviate the costs of encryption. This will of course not completely remove the CPU costs from large e-commerce websites, but it will make it simpler for the user of such a site.

Now, SSL will have a particularly difficult time with many of the extensions that IPv6 is introducing. The new privacy extended IPv6-addresses generated CGA (cryptographically generated addresses) will:

  • maintain privacy
  • add accountability for link administrators

IPv6 will even add a Host ID that can be used as a token to access to a network. The big issue is that we will expect multiple addresses per node, so “who needs spoofing?”

The combination of multiple IP addresses and CGA makes a difficult time for existing implementations of SSL. We could determine to try and fix SSL, but the issue here is simply why?

IPv6 has encryption built in. The IPv6 security protocols include:

  • Authentication Header (AH) [RFC4302] and
  • Encapsulating Security Payload (ESP) [RFC4303].

These work through Security Associations. What a SA is, and how they work, how they are managed, associated processing are all defined in [RFC4301].

The death knell for SSL really comes as the algorithms for authentication and encryption in IPv6 are defined as being mandatory. These algorithms are defined for use with AH and ESP in [RFC4835], and for IKEv2 in [RFC4307]. Basically, IPv6 already has a tunnelling and transport encryption protocol incorporated that has to be deployed. Why have SSL embedded within IPSec?
AH provides:

  • integrity.
  • data-origin authentication.
  • optional (at the discretion of the receiver) anti-replay features.

IPSec implementations MUST support ESP and MAY support AH.

ESP provides:

  • integrity.
  • data-origin authentication.
  • optional (at the discretion of the receiver) anti-replay features.
  • confidentiality (NOT recommended without integrity).

On top of this, for each IPSec implementation there is a nominal Security Association Database. The SA contains much more than I have included below, but this covers some of what is necessary for this post:

  • Each entry defines the parameters associated with one SA.
  • Each SA has an entry in the SAD.
  • The SPD has pointers to SAD entries, when IPSec have to be used (PROTECT).
  • Anti-Replay Window: a 64-bit counter and a bit map (or equivalent) used to determine whether an inbound AH or ESP packet is a replay.
  • AH Information: authentication algorithms, keys lifetimes, etc.

Now, when you consider as well that [RFC4941] describes an extension to IPv6 stateless address auto configuration that makes nodes generate global-scope addresses that change over time. We have multiple addresses per host that move, update change. We see that this standard allows:

  • The IPv6 addresses on a given interface generated via stateless auto configuration contain the same interface ID,
  • occurs regardless of where within the Internet the device connects, and
  • this facilitates the tracking of individual devices.

Again, why would we bother with SSL?
Once a business starts to see that they have encryption and authentication services at the end-point and over the layer three level to and from the host and server, they will not bother with the notion of application-layer security. As such, SSL will become redundant.

Why would a business have both a secure and an open website? Why would they implement separate controls for email, the web, file sharing, and all other applications they run.

No, simply put, SSL is flawed, but at least we can see a slow death as the uptake of IPv6 replaces the existing IP stacks host by host.



Never miss a story from Craig Wright (Bitcoin SV is the original Bitcoin)