Summary of Porto security discussion

[wrygiel]

Since I'm the one who is required to design and explain everyone how all these new protocols will work like, I guess I should start with a detailed summary of what we have actually agreed in Porto. For all of those who didn't follow the discussion closely, and also for the developers from the future, if they want to know a bit about EWP history. ;)

Comments are welcome.

What WP4 expected to deal with in Porto

As you know, initially WP4 planned to make use of TLS for every one of the four security aspects:

1. For client authentication, we required TLS Client Certificate.
2. For server authentication, we required TLS Server Certificate.
3. For request encryption, we relied on TLS.
4. For response encryption, we relied on TLS.

There were some problems with the first one of these points. So, when we arrived in Porto, we expected that the long-term security setup will look mostly the same - we expected only the first of these points to change:

1. For client authentication, we would require HTTP Signatures.
2. For server authentication, we would still require TLS Server Certificate (plus, in case of some APIs, maybe HTTP Signatures for non-repudiation).
3. For request encryption, we would still rely on TLS.
4. For response encryption, we would still rely on TLS.

What went differently

However, during the meeting in Porto, it has been accepted (somewhat against WP4's arguments) that TLS cannot be trusted.

• Some partners fear that some other partners' machines may use some old operating systems (like Windows XP) which would allow attacker's root certificates to be remotely installed on them, allowing for man-in-the-middle attacks during transport.

  WP4's counter-argument: We could require specific root certificates to be used, and/or remotely verify if partners use up-to-date technologies (there exist some ways of doing that, although they are limited).

• Some partners don't trust their own internal networks, or the internal networks of other partners. In this setup, TLS is terminated when it enters the partner's network, and data is then sent unencrypted through this network. And this allows man-in-the-middle attacks from within the server's internal network.

  WP4's counter-argument: If TLS terminators are used, then it's the partner's responsibility to trust their own internal networks (as explained, for example, here).

Discussion followed, and resulted in a much larger set of changes than WP4 expected (especially in aspects covering request and response encryption).

What we agreed on

As it turned out, WP4 is now required to specify a set of security standards that could be used as an alternative to TLS (including protection against replay-attacks, etc.):

1. For client authentication, we will require HTTP Signatures, as planned.
2. For server authentication, we will require TLS Server Certificate, plus an additional HTTP Signature in case of selected APIs. This prevents the attacker in the server's internal network to modify the response.
3. For request encryption, we will still rely on TLS, but - in cases when private data is being sent - we will additionally allow for request bodies to be additionally encrypted to prevent the attacker in the server's internal network to overhear the request.
4. For response encryption, we would still rely on TLS, but - in cases when private data is being sent - we will additionally allow for response bodies to be additionally encrypted to prevent the attacker in the server's internal network to overhear the response.

Impact on the future of EWP

Obviously, this introduces more complexity for all "current" implementers. But what's more important is that it also increases the cost of keeping the network secure "over the years":

• Previously, we built on TLS, and in this way we "delegated" most of the problems - in regard to, for example, obsolete certificate hashing algorithms - to the future TLS library implementers. We simply required every server to keep their TLS libraries up-to-date, and their TLS terminators "close enough" to the actual endpoint. In Porto it was however decided that we cannot trust partners to do that.

• Now, we will need to cope with an increased number of security problems internally. It's not TLS library implementers who will need to fix things, it's us. For example, once a particular hashing algorithm we use gets deprecated, new authentication/encryption methods will need to be introduced in EWP and the existing ones will be deprecated. This won't happen often, but it's quite certain that it will eventually happen.

• In fact, it's even a little possible that we will return to the original TLS security after some years, once security experts decide that, for example, TLS in version X.Y.Z is "trustworthy enough".

All of this causes the number of combinations in which these methods can be used to increase:

• Previously, there were only two combinations to consider:
  • Anonymous client with TLS request expecting a regular TLS response.
  • Authenticated client with TLS request expecting a regular TLS response.
• Now, we will have some more. Both clients and servers might support (or require) different types of authentication, or encryption, e.g.
  • Anonymous client with non-encrypted request expecting non-encrypted response
  • Anonymous client with encrypted request expecting encrypted response
  • Authenticated client with non-encrypted request expecting a non-encrypted response
  • Authenticated client with encrypted request expecting encrypted response
  • Authenticated client with encrypted request expecting encrypted response, but they expect the response to be encrypted with some newer kind of encryption protocol
  • etc. (support for different algorithms of encryption and signature may vary over the years)

On the bright side ;)

• When deployed over "bad TLS", it definitelly increases the security.
• When deployed over "good TLS", it doesn't decrease the security.
• We can do all future changes in a backward-compatible manner. The network will work without interruptions, if new nodes introduce new protocols while still supporting the older ones for some time.
• Security algorithms get deprecated very slowly. Future deprecation changes shouldn't cause much trouble.
• These "four security aspects" don't seem to clash with each other much, it seems that we can design a way of replacing any single one without affecting all the others.