Section 3.6:
The downside is the the
client will not verify the identity of the fronting service with
risks discussed in , but solutions will have to mitigate this risks.
Overall, end-to-end TLS to the protected service is preferable.
"the the" => "that the"
"discussed in ," presumably was intended to include a reference to... something.
"this risks" => "these risks"
Section 3.7:
These applications
too will benefit of SNI encryption. HTTP only methods like those
described in Section 4.1 would not apply there. In fact, even for
the HTTPS case, the HTTPS tunneling service described in Section 4.1
is compatible with HTTP 1.0 and HTTP 1.1, but interacts awkwardly
with the multiple streams feature of HTTP 2.0 [RFC7540]. This points
to the need of an application-agnostic solution, that would be
implemented fully in the TLS layer.
"benefit to" => "benefit from"
"HTTP only" => "HTTP-only"
"HTTP 2.0" => "HTTP/2"
"solution, that would" => "solution which can"
Section 4.2
This requires a
controlled way to indicate which fronting ferver is acceptable by the
hidden service.
"ferver" => "server"
We can observe that content distribution network have a similar
requirement. They need to convince the client that "www.example.com"
can be accessed through the seemingly unrelated "cdn-node-
xyz.example.net". Most CDNs have deployed DNS-based solutions to
this problem.
It might be worth mentioning that when a CDN deploys a "DNS-based solution to this problem," it also holds the authoritative certificate of the origin.. There is simultaneously verification of a relationship between the origin and the CDN (because the certificate can be verified) and a risk that the CDN can spoof the content from the origin.
Section 5
Having described in 2.3 that encrypting SNI will simultaneously thwart invasions of the TLS exchange whose purpose is to improve some forms of security, I suspect this is worth a mention in the Security Considerations as well..
Section 7
"Martin Rex Martin Thomson and" => "Martin Rex, Martin Thomson, and"
huitema
commented
5 years ago
Section 3.6: The downside is the the client will not verify the identity of the fronting service with risks discussed in , but solutions will have to mitigate this risks. Overall, end-to-end TLS to the protected service is preferable.
"the the" => "that the" "discussed in ," presumably was intended to include a reference to... something. "this risks" => "these risks"
Section 3.7: These applications too will benefit of SNI encryption. HTTP only methods like those described in Section 4.1 would not apply there. In fact, even for the HTTPS case, the HTTPS tunneling service described in Section 4.1 is compatible with HTTP 1.0 and HTTP 1.1, but interacts awkwardly with the multiple streams feature of HTTP 2.0 [RFC7540]. This points to the need of an application-agnostic solution, that would be implemented fully in the TLS layer.
"benefit to" => "benefit from" "HTTP only" => "HTTP-only" "HTTP 2.0" => "HTTP/2" "solution, that would" => "solution which can"
Section 4.2 This requires a controlled way to indicate which fronting ferver is acceptable by the hidden service.
"ferver" => "server"
We can observe that content distribution network have a similar requirement. They need to convince the client that "www.example.com" can be accessed through the seemingly unrelated "cdn-node- xyz.example.net". Most CDNs have deployed DNS-based solutions to this problem.
It might be worth mentioning that when a CDN deploys a "DNS-based solution to this problem," it also holds the authoritative certificate of the origin.. There is simultaneously verification of a relationship between the origin and the CDN (because the certificate can be verified) and a risk that the CDN can spoof the content from the origin.
Section 5
Having described in 2.3 that encrypting SNI will simultaneously thwart invasions of the TLS exchange whose purpose is to improve some forms of security, I suspect this is worth a mention in the Security Considerations as well..
Section 7
"Martin Rex Martin Thomson and" => "Martin Rex, Martin Thomson, and"