Re: [TLS] TLS Proxy Server Extension

David McGrew <mcgrew@cisco.com> Tue, 26 July 2011 17:38 UTC

Return-Path: <mcgrew@cisco.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5565211E80EC for <tls@ietfa.amsl.com>; Tue, 26 Jul 2011 10:38:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Of1aNelv2zt0 for <tls@ietfa.amsl.com>; Tue, 26 Jul 2011 10:38:41 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 7BA0811E8073 for <tls@ietf.org>; Tue, 26 Jul 2011 10:38:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mcgrew@cisco.com; l=3877; q=dns/txt; s=iport; t=1311701921; x=1312911521; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=ab1F44YxC3HLmPP89wiwRTR8HEtAvNj4RpHw3Dv0ALc=; b=mV1d6Wh4H33idzBfcn/kbrFoRmuEkqz1rzvglpyjvkUcqjpoVSkL5amx oFU0m3uJXWfdvGsoKT5J9Nkbo0fTyGEyyEh4rQXoZDreVabBmhxRTtpUg OD0bUbvvFdIOWWNCByJa56AWCkbLC8dhzXL6m69bRAsp2laaMaDQrKRQ7 I=;
X-IronPort-AV: E=Sophos;i="4.67,270,1309737600"; d="scan'208";a="6571450"
Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-1.cisco.com with ESMTP; 26 Jul 2011 17:38:41 +0000
Received: from [130.129.23.131] ([10.86.245.219]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id p6QHcd8i004161; Tue, 26 Jul 2011 17:38:40 GMT
Message-Id: <99392979-0293-4EAA-BF8A-EE1F7588CC04@cisco.com>
From: David McGrew <mcgrew@cisco.com>
To: "Yngve N. Pettersen" <yngve@opera.com>
In-Reply-To: <op.vy8foys4kvaitl@lessa-ii.oslo.os>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Tue, 26 Jul 2011 10:38:39 -0700
References: <E210EEE3-1855-4513-87E3-C315E611AB5E@cisco.com> <op.vy8foys4kvaitl@lessa-ii.oslo.os>
X-Mailer: Apple Mail (2.936)
Cc: Philip Gladstone <pgladstone@cisco.com>, tls@ietf.org
Subject: Re: [TLS] TLS Proxy Server Extension
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Jul 2011 17:38:42 -0000

Hi Yngve,

On Jul 26, 2011, at 8:23 AM, Yngve N. Pettersen wrote:

> Hi,
>
> I just skimmed the start of the document
>
> I assume, from context, that your use case is for proxies that  
> perform an authorized MITM "attack" on the TLS connection by issuing  
> specific "fake" certificates for the site you are connecting to,  
> decrypting/re-encrypting the encrypted data, and not a proxy that  
> uses the normal HTTP CONNECT request and just passes packets back  
> and forth and the TLS connection is end-to-end. Right?
>

right.


> If so, that should perhaps be made clearer in the introduction and  
> abstract, possibly by using a different term for the proxy? My  
> association with "proxy" is generally the ordinary CONNECT packet  
> forwarding proxy, not the MITM proxy.

Yes, I think so.

>
> IMO, when you authorize a proxy to MITM your connections, you also  
> implicitly accept the security policies of the proxy, and whatever  
> encryption and certificate it trusts.
>

Right, this is what happens at present.

> As an alternative way forward, might it not be an equally good way  
> forward to require the proxy to either negotiate the same encryption  
> methods with the client as it negotiated with the server, or  
> alternatively, only offer the mutually acceptable set of cipher  
> suites for the client and proxy (perhaps with an addition for better  
> suites, allowing an encryption upgrade)?

Agreed that it is a good idea for the proxy to offer a subset of the  
ciphersuites offered by the client.  But this only covers the crypto  
policy - it doesn't address the problem of how the client can decide  
whether or not it trusts the server on the other side of the proxy,  
for the particular application in use.  Section 2 of the draft  
outlines this in some more detail.

As a side note, I think that for almost all purposes, the ciphersuites  
offered by the proxy should be a subset of those offered by the  
client.  The one scenario where we might decide that it is a good idea  
to allow the proxy to offer other ciphersuites is the case in which  
the client and server do not have a mutually acceptable ciphersuite;  
in this case the proxy is acting like a translator.   I am not  
thrilled about this scenario, because it implies that there is lack of  
interoperability which I think should be avoided if/when possible, but  
I do not think that it would make sense to exclude the scenario.

thanks,

David

>
>
> On Tue, 26 Jul 2011 17:01:31 +0200, David McGrew <mcgrew@cisco.com>;  
> 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
>>
>>
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>
>
> -- 
> Sincerely,
> Yngve N. Pettersen
>
> ********************************************************************
> Senior Developer                     Email: yngve@opera.com
> Opera Software ASA                   http://www.opera.com/
> Phone:  +47 24 16 42 60              Fax:    +47 24 16 40 01
> ********************************************************************