Re: The TLS hammer and resource integrity

On 29/03/2012 12:43 a.m., Roberto Peon wrote:
> Ensuring security of the endpoints is probably outside the purvue of 
> the WG, however interesting it is.
>
> That being said,  we should probably assume that the hosts aren't 
> compromised because otherwise it really doesn't matter what we do.
>
> Our task is thus to somehow secure the communications channel. If you 
> make SSL implementation optional on the server side, you suffer from a 
> downgrade attack whereby an intermediary (potentially malicious), 
> denies you all security on the communications channel.
> If this decision is made, it must be made by the client for the 
> client<->intermediary connection.

This argument holds no water with intermediaries involved (legit or 
otherwise). Remember that intermediary plays the role of both client AND 
server simultaneously.  Sure the client can determine the strength of 
client<->intermediary security level. But then the intermediary has 
equal power to determine the weakness of intermediary<->server hop. 
Oops, malicious intermediary just downgraded the end-to-end security 
using the very control you gave the client. When the control is all 
one-sided (client OR server determining things) downgrade is easy.

It would be better for both security and integrity to allow both ends to 
prescribe their requirements. If either client or server is unable to 
comply with the others requirements TLS can't be used on that hop. 
Client must find another route in order to meet their policy needs. Very 
Expensive, but adds better assurity of real end-to-end security in 
comparison with trying to use TLS to bridge a weak intermediary node.
  Even with that strictest of strict security measures a malicious 
intermediary able to negotiate strong TLS with both ends can create a 
weak hop between the apparently secure ends.

The final solution boils down to a web of trust at a hop-by-hop level 
down the whole chain. How-to is up for grabs.

AYJ

Received on Wednesday, 28 March 2012 12:42:13 UTC