Re: [TLS] TLS Proxy Server Extension

[Martin Rex <[e-mail]>]

David McGrew wrote:
> 
> >
> > Cryptographic security of the TLS protocol is clearly unaffected
> > from sharing the traffic encryption keys with the proxy.
> 
> It would be an exceedingly brittle solution to build a system that  
> would be cryptographically insecure if proxies added or changed a  
> single byte, then insist and hope that proxies never modify the data  
> stream.

Full agreement.  Adding a client-side proxy into TLS authentication
that terminates the clients SSL connection would be an extremely brittle
solution and an unconditionally bad idea.


> 
> > What happens is that the proxy may remove confidentiality of the
> > data and look at the data before passing along the original, encrypted
> > data the the rightful communication peer.
> >
> > It is a design property of the TLS protocol that having access
> > to the traffic encryption keys does not allow _you_ to subvert other
> > characteristics of the protocol beyond the confidentiality.
> 
> That property does not hold for any use of authenticated encryption,  
> including that of RFC 5288 or the two drafts using CCM.


Which means that security-wise those cipher suites are substantially
weaker than tls cipher suites which provide encryption and integrity
by independent means.

Such cipher suites should not be enabled by default unless without
considering the security impact for the usage scenario / environment
where they should be used.


> 
> >> A malware-screening proxy needs to be able to modify the traffic
> >> flowing through it.  It would be pointless for it to detect malware,
> >> and then pass it on to the client!
> >
> > Huh?  The peer does not get anything that the proxy does not forward.
> > And if there is something goofy. the proxy simply terminates the
> > connection (both connection. that to the real server and that to the
> > real client).
> 
> What I have been told is that there are proxies that don't work that  
> way, and it is not realistic to expect them to work that way.   Rather  
> than debate that point on the list, let's seek out some objective data.


Would you prefer to document instead what current proxies are doing
and have the IETF rubber stamp that surveillance/wirtap techology
as a standard?

 
>
> > For the purpose of malware screening, the proxy having only the  
> > traffic
> > encryption keys is perfectly sufficient.  And because it is perfectly
> > sufficient, the MAC keys fall under constitutional protection and
> > requesting them would be unlawful.
> 
> Not using end-to-end message authentication is unconstitutional?
> But decryption in the middle is OK?


It would only be OK for the limited purpose where the central malware
scanner works as an agent under direction and control of the client only
(no central reporting, no company policy) as an alternative solution to
having the client process the data locally as it leaves the TLS tunnel.


-Martin

> 
> If I rushed to conclusions on this topic, I might think that we are  
> violating the constitution because we haven't signed our emails with  
> SMIME or PGP.  That can't be right, so apparently a more detailed  
> analysis is needed.

Our consitutional protections (for communication privacy) are independent
from what technical measures you employ to ensure privacy.  They apply
to cleartext communcation as well.  Central scanning of EMails for
malware is commonplace, but it can scan only non-encrypted EMails.


TLS was designed to be secure end-to-end.  And you're trying to
take characteristic away from TLS by trying make the IETF standardize
wiretapping/surveillance technology for TLS?  I strongly dislike the idea.

There is technology similar to what you're proposing as TLS proxy
on the market and sold for the purpose of allegedly lawful intercept
of HTTPS/TLS traffic.  NO, I don't want the IETF to publish RFCs
on what these boxes look like.

Instead, we're actively working in the DANE working group on solutions
to break any such gear that exploits the weaknesses in the
(lack-of) trust model of the TLS X.509 PKI.


-Martin