Some months ago, ETSI released the TS103 523-3, which describes the usage of an implementation variant of TLS
v1.3 for the Middle Box Security Protocol.
The key complaint is that TLS v1.3 does
not allow passive decryption, which is necessary to comply with requests from
authorities to have clear text information of an exchange of traffic. This,
because TLS v1.3 does not support RSA key exchange and uses ephemeral Diffie-Hellman,
instead of static Diffie-Hellman key exchange. These two improvements
constitute a high degree of security compared to the previous version of TLS.
I have seen some comments on social
networks complaining about the nature of ETSI’s technical specification, which
would constitute a downgrade of the security level of the data in transit for
the users. And, well, I have some quick thoughts about this.
eTLS features a scheme for longer-lived
static Diffie-Hellman keys and allow to re-use the keys across multiple
sessions. These characteristics pose high risks, since it would imply to go
back to a similar state that we had in TLS v1.2. But if we analyze the use
cases under which eTLS is used, I see no difference with common practices in
Internet Service Providers (ISP) regarding the routing of encrypted user
traffic.
The most common use case is described in
clause 4.2.1 (eTLS with enterprise servers) which describes the situation when a
customer wants to access some content offered by an ISP.
It describes that TLS v1.3 is used up to
the border firewall, and from that point on, eTLS is used between firewall and
internal servers.
I find that is a usual practice to break
the TLS connection at some point inside the ISP. It may be at the border
firewall or in an internal device such as a WAF (Web Application Firewall).
This is done to manipulate the user flows in the internal infrastructure. That
is the case when it is necessary to perform load balancing between servers. The
key idea in here is that the encryption of this data in transit is managed internally
by the ISP, secured by certificates between the involved servers. The
confidentiality and integrity of the data is not lost and the ISP can have the
way to manage the traffic to offer a better service.
In summary, TLS v1.3 would be used over
the public Internet (where the most dangerous threats are located), and the
less secure eTLS is used inside ISP premises (where one suppose that the
threats are reduced).
Now, the worry is about how the ISP is
going to manage the static keys (their life cycle management, up to their
destruction to guarantee forward secrecy), assure their chain of custody and
ensure that there is no abuse of privileges from employees that could use these
powerful “keys” to read personal data. This is a topic that relates to the
trust that we deposit in our service providers.
