Re: [TLS] TLS Proxy Server Extension

[David McGrew <[e-mail]>]

Hi Yoav,

thanks for the good suggestions.

David

On Jul 26, 2011, at 2:17 PM, Yoav Nir wrote:

>
> On Jul 26, 2011, at 11:01 AM, David McGrew wrote:
>
>> Hi,
>>
>> I would like to request feedback on a new draft that Philip Gladstone
>> and I put together, which aims to solve some of the security problems
>> that happen when there is a (HTTP) proxy present and TLS is in use.
>> The approach is to require the proxy to provide the client with
>> additional information that the client can use to make a well- 
>> informed
>> decision about the security of the session.  This draft was put
>> together too late to request a slot at the WG meeting this week, but
>> if you have thoughts on either the goals or the mechanism, we can
>> discuss either in person or on the list.
>>
>> David
>>
>> http://tools.ietf.org/html/draft-mcgrew-tls-proxy-server-00
>
> Hi Dave.
>
> I like this draft. TLS proxies are becoming a fact of life. They  
> still have significant drawbacks in that the "fake" certificates  
> that they generate are not identical to the original certificates.  
> For example, the fake certificates cannot be EV certificates, and  
> therefore the users lose the "green-bar" indication.
>
> I don't know if you're following the LockFoo discussion on WebSec,  
> but all of those locks would cause a hard-fail for clients  
> connecting to sites that have specified them. As security people we  
> might think "good!", but that would actually be a bar to  
> implementations of LockFoo more than it would be a bar to deployment  
> of TLS proxies. Giving the client access to the original  
> certificates would allow the browser to overcome this limitation.
>
> A similar argument also applies to DANE. If the DNS entry identifies  
> the key, the certificate or the CA, then the "fake" certificate  
> would cause an error. Access to the original certificate chain  
> allows the client to eliminate the error message, although I am not  
> sure how the browser UI would indicate an EV certificate proxied  
> through a non-EV proxy.
>
> I am wondering why you would need the ConnectionSecurityParameters  
> structure. Wouldn't the 2-byte ciphersuite be a more compact way to  
> represent this information?
>
> Also I would add text about EV certificates (and maybe also the  
> LockFoo cases of DANE and WebSec) to the motivation section.
>
> Yoav
>