Re: [TLS] TLS Proxy Server Extension

David McGrew <mcgrew@cisco.com> Fri, 29 July 2011 20:42 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 13A2E5E8016 for <tls@ietfa.amsl.com>; Fri, 29 Jul 2011 13:42:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.818
X-Spam-Level:
X-Spam-Status: No, score=-102.818 tagged_above=-999 required=5 tests=[AWL=-0.219, 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 K2KHxWwyeuVd for <tls@ietfa.amsl.com>; Fri, 29 Jul 2011 13:42:28 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 764215E8028 for <tls@ietf.org>; Fri, 29 Jul 2011 13:42:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mcgrew@cisco.com; l=2636; q=dns/txt; s=iport; t=1311972147; x=1313181747; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=Pghry9DLs8Ggt4GkXTfprmbJUxzjyOZqP2Ad4s7EC/w=; b=BKYd5EFObH1kfsu1r9iw5boD/SkwR92p+yVeYX0Kbcm/OxMqq0Mqbb1N fPM208nENXljDdMeu9Zu5b/4cBaIwmAQToezFUx6tibKwN51ia/nlz9VY cYdttfab44j8aCRDqsgGUjXlk+fBMVhXjVAvxY57do+IVdSZMuXSE212T M=;
X-IronPort-AV: E=Sophos;i="4.67,288,1309737600"; d="scan'208";a="7918027"
Received: from mtv-core-4.cisco.com ([171.68.58.9]) by rcdn-iport-7.cisco.com with ESMTP; 29 Jul 2011 20:42:26 +0000
Received: from stealth-10-32-254-214.cisco.com (stealth-10-32-254-214.cisco.com [10.32.254.214]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p6TKgOxx019094; Fri, 29 Jul 2011 20:42:24 GMT
Message-Id: <68B86175-4A5D-4B4D-B995-D498A42F3973@cisco.com>
From: David McGrew <mcgrew@cisco.com>
To: Marsh Ray <marsh@extendedsubset.com>
In-Reply-To: <4E32FCFA.3050808@extendedsubset.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Fri, 29 Jul 2011 13:42:23 -0700
References: <E210EEE3-1855-4513-87E3-C315E611AB5E@cisco.com> <4E32D033.7020601@extendedsubset.com> <7F97B097-BF00-432E-849E-D6DCA6DA470E@checkpoint.com> <4E32FCFA.3050808@extendedsubset.com>
X-Mailer: Apple Mail (2.936)
Cc: Philip Gladstone <pgladstone@cisco.com>, "tls@ietf.org" <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: Fri, 29 Jul 2011 20:42:29 -0000

Hi Marsh,

On Jul 29, 2011, at 11:33 AM, Marsh Ray wrote:

> On 07/29/2011 11:52 AM, Yoav Nir wrote:
>>
>> This draft does not invent TLS proxies or even standardize them.
>
> The IETF defines no such thing as a "TLS proxy". I don't even see  
> how such a thing can be defined without violating some basic  
> guarantees of the protocol, but I'm open to being educated on that.
>
>> It invents a way for the client to recover some of the information  
>> that
>> is lost because of the existing use of TLS proxies.
>
> I'm really sympathetic to the necessity of the lesser evil in  
> practice.
>
> But "TLS proxies" currently work poorly today because they are  
> underspecified and they violate certain protocol assumptions.  
> Sometimes they end up weakening security and breaking higher-layer  
> stuff.
>
>> I can see how this draft could be extended to support client
>> certificates, but that would require changes to the server as well,
>> and a change to the state machine that elevates this draft in the new
>> taxonomy from "trivial" to "significant",
>
> That would be a good thing in my view because the underlying changes  
> actually are significant.
>
>> so we probably don't want
>> that at all. But client certificates are already broken now behind a
>> TLS proxy.
>
> What is this "TLS proxy" of which you speak? I see no SHOULDs or  
> MUSTs or which apply to it, much less any cryptographic guarantees  
> about it.
>
> More importantly, what is its security model?

Some appropriate security goals are outlined in Section 6.  They are  
client-oriented; as you pointed out, ideally the server would gain  
some assurances about the client as well.

>
> All I see usually amounts to "convince the client to install our  
> trusted root and then the MitM can get away with almost anything".  
> Perhaps this draft is admirable in that it defines a mechanism with  
> which the MitM MAY choose to communicate certain info to the client,  
> but I feel it is handwaving over the deeper questions and tacking  
> features on top of an architecture which isn't really defined at all.

I would be interested to hear your thoughts on what sort of  
architecture would be good.

It might be appropriate to have the certificate held by the proxy have  
an attribute that states that it is a proxy.  An attribute could be  
used to limit the scope of the proxy as well, based on e.g. DNS.  That  
sort of mechanism would ensure that a proxy would be known to the  
client; it couldn't hide its presence just by not sending the TLS  
Proxy Extension.

David