Some comments on draft-ietf-tls-sni-encryption-03:
Section 2.3 “End-to-end alternatives”
“Enterprises can deploy monitoring software to control usage of the enterprises [sic] computers.”
At the moment enterprises have the option of installing a firewall performing SNI filtering to black-list connections to certain websites. With SNI encryption this becomes ineffective. This draft should describe the privacy impact of enterprises adopting the proposed mitigation strategy of deploying monitoring software. Similarly, the privacy impact of introducing “opt in” filtering of DNS and packet marking to determine QoS should be addressed. The privacy gains of encrypting SNI need to be weighed against the privacy losses of adopting these mitigations and at the moment this draft does not do that.
Section 3.6 “Proper security context”
This section currently describes one class of solutions where there is a single TLS handshake between the client and the multiplexed server or fronting service, but there is another class, where the TLS handshake is between the client and the protected service. The text in this section should be expanded to encompass both classes (or it could be written as two separate sections if clearer). The text should also draw out that the client and the protected service are placing a great deal of trust in the fronting service, which becomes a very powerful part of the network and hence a very attractive target for attackers or malicious operators.
As a suggestion, consider the following alternative text for section 3.6:
We can design solutions in which the multiplexed server or a fronting service act as a relay to reach the protected service. Some of those solutions involve just one TLS handshake between the client and the multiplexed server (or fronting service). Others involve just one TLS handshake between the client and the protected service.
In the first case, the master secret is verified by verifying a certificate provided by the multiplexed server (or fronting service), but not by the protected service. In the second case, the master secret is verified by verifying a certificate provided by the protected service.
In the first case, the client is exposed to a Man-In-The-Middle attack by the multiplexed server (or fronting service). The client does not verify the identity of the protected service, and thus data exchanged between the client and the protected service can be learned by the attacker. In the second case, the client does not verify the identity of the multiplexed server (or fronting service), thus it is possible for an attacker to perform a Man-In-The-Middle attack between the client and the multiplexed server (or fronting service). Thus it would be possible for the attacker to learn the identity of the protected service.
These designs require that the client has some reasonable trust in these fronting services. If the fronting service is acting maliciously, it may re-direct the client's TLS connection to another service other than the intended protected service. The service receiving the client's TLS connection may not have any way of verifying that the client intended to reach that particular service if it is not able to decrypt the client's SNI; thus the protected service also has to have reasonable trust in the fronting service. If the fronting service is not strongly authenticated, it can be spoofed by an adversary or be subject to MITM attack.
The multiplexed server or the fronting services could be pressured by adversaries. By design, they could be forced to deny access to the protected service, or to divulge which client accessed it. But if MITM is possible, the adversaries would also be able to pressure them into intercepting or spoofing the communications between client and protected service.
These approaches therefore concentrate trust in the multiplexed servers and fronting services, making them attractive targets for adversaries, or for operators of these services to install monitoring, redirection and censorship mechanisms. It is desirable for the identity of these multiplexed servers and fronting services to be strongly authenticated and verifiable by both the client and the protected service.
huitema
commented
5 years ago
Some comments on draft-ietf-tls-sni-encryption-03:
Section 2.3 “End-to-end alternatives”
“Enterprises can deploy monitoring software to control usage of the enterprises [sic] computers.” At the moment enterprises have the option of installing a firewall performing SNI filtering to black-list connections to certain websites. With SNI encryption this becomes ineffective. This draft should describe the privacy impact of enterprises adopting the proposed mitigation strategy of deploying monitoring software. Similarly, the privacy impact of introducing “opt in” filtering of DNS and packet marking to determine QoS should be addressed. The privacy gains of encrypting SNI need to be weighed against the privacy losses of adopting these mitigations and at the moment this draft does not do that.
Section 3.6 “Proper security context”
This section currently describes one class of solutions where there is a single TLS handshake between the client and the multiplexed server or fronting service, but there is another class, where the TLS handshake is between the client and the protected service. The text in this section should be expanded to encompass both classes (or it could be written as two separate sections if clearer). The text should also draw out that the client and the protected service are placing a great deal of trust in the fronting service, which becomes a very powerful part of the network and hence a very attractive target for attackers or malicious operators.
As a suggestion, consider the following alternative text for section 3.6:
We can design solutions in which the multiplexed server or a fronting service act as a relay to reach the protected service. Some of those solutions involve just one TLS handshake between the client and the multiplexed server (or fronting service). Others involve just one TLS handshake between the client and the protected service.
In the first case, the master secret is verified by verifying a certificate provided by the multiplexed server (or fronting service), but not by the protected service. In the second case, the master secret is verified by verifying a certificate provided by the protected service.
In the first case, the client is exposed to a Man-In-The-Middle attack by the multiplexed server (or fronting service). The client does not verify the identity of the protected service, and thus data exchanged between the client and the protected service can be learned by the attacker. In the second case, the client does not verify the identity of the multiplexed server (or fronting service), thus it is possible for an attacker to perform a Man-In-The-Middle attack between the client and the multiplexed server (or fronting service). Thus it would be possible for the attacker to learn the identity of the protected service.
These designs require that the client has some reasonable trust in these fronting services. If the fronting service is acting maliciously, it may re-direct the client's TLS connection to another service other than the intended protected service. The service receiving the client's TLS connection may not have any way of verifying that the client intended to reach that particular service if it is not able to decrypt the client's SNI; thus the protected service also has to have reasonable trust in the fronting service. If the fronting service is not strongly authenticated, it can be spoofed by an adversary or be subject to MITM attack.
The multiplexed server or the fronting services could be pressured by adversaries. By design, they could be forced to deny access to the protected service, or to divulge which client accessed it. But if MITM is possible, the adversaries would also be able to pressure them into intercepting or spoofing the communications between client and protected service.
These approaches therefore concentrate trust in the multiplexed servers and fronting services, making them attractive targets for adversaries, or for operators of these services to install monitoring, redirection and censorship mechanisms. It is desirable for the identity of these multiplexed servers and fronting services to be strongly authenticated and verifiable by both the client and the protected service.
-- Mark