Re: [TLS] TLS and middleboxes again

[Yoav Nir <[e-mail]>]

On Aug 26, 2011, at 1:53 PM, Juho Vähä-Herttua wrote:

> 26.8.2011 12:17, Yaron Sheffer kirjoitti:
>> I support this proposal. I think it is a lot more generic than the 
>> previous one, since it also supports mutual authentication (TLS-SRP) 
>> and client certs.
> 
> I support it as well,

This is meant as a straw man proposal. I still think that an actual proxy is better.

>> A few comments:
>> - On top of the encryption keys, we probably need to support sending 
>> the MAC keys. Subject to client and server policy of course.
> 
> I have no reason to support sending the MAC keys, and letting the proxy 
> to modify the actual contents of the connection sounds a bit scary to 
> me... What's the actual use case for this?

An attacker sends your gmail (or hotmail, of iCloud) account a document containing malicious macros. You click the document link within the website to download it. The middlebox detects the malware. Without MAC keys, it can only break the connection, which looks weird - like the download has failed. With MAC keys, it can redirect to a page that says "The file you tried to download contains the XXXXX virus", or it can even let you download a document that says that.

> 
>> - IMHO the following sentence is miguided, and opens a major security 
>> loophole: "If a KeyShareInfo record is received with an unknown 
>> certificate, [...] the user MAY be prompted to authorize the 
>> decryption, and optionally change the configuration to allow future 
>> decryption by this certificate." Users will always say Yes when 
>> otherwise their communication will be interrupted. In other words, the 
>> proxy certificates must only be provisioned off-line, in advance, when 
>> the user can still make reasoned decisions. [As an example of this 
>> user behavior, I just approved myself the IETF's own expired 
>> certificate...]
> 
> I'm not sure if KeyShareInfo with an unknown certificate should ever be 
> allowed... Configuring it as authorized might be even worse idea. Thank 
> you for the draft anyway, I think if implemented widely it would be a 
> better option than the proxy certificate currently used, because it's 
> much better to be able to only share the decryption keys without the MAC 
> keys.

I agree that configuration is a difficult issue, but I don't see how we can take the user out of the loop. I don't want to allow Starbucks to decrypt my TLS traffic, but I will probably accept this from my employer. These days we have a lot of unmanaged hardware at companies (a lot of Macs, and almost all cell-phones) and even more unmanaged browsers.