Re: [TLS] TLS Proxy Server Extension

Matt McCutchen <> Fri, 29 July 2011 04:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 41AAC11E8084 for <>; Thu, 28 Jul 2011 21:33:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qS7BYPg0H9rS for <>; Thu, 28 Jul 2011 21:33:22 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 4FBB711E807F for <>; Thu, 28 Jul 2011 21:33:22 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id 10FFE3BC06C; Thu, 28 Jul 2011 21:33:22 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws;; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s=; b=oC5yPoPJBy1UrlNq6ueK75gAbippVLEoyYJPK8WpJj9 btgkE/C7LZA+5OEQEmcmL1uCKdlKtALtTvWbPE7CmX2Uez4IBltwJ32Fla3F4dTf OMHdm3neBuFy8/jsGMzEjQIxO9FmLbpGvAxVMRtXd2Fpg3drK/p1WslKkWiGCMwU =
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h= subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s=; bh=/nnVwCFzA/DeVymf6ve9lPVoXOo=; b=Dl09ETwwQm imMboiZmsKXAfd/OvDm56o7h50XHLBAD6aVebelnYatzgd/oHaD2pXt7Meaj4DVO ZS8cBaFXA208yHx4P7fKDW77n//qERjyfUdgvNNuIdeBHSnIQ3PKn1d3Lqnpodjb 7dmI33abPd6daAV3AQlkAtLiPte8WiS1s=
Received: from [] ( []) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id 7C96E3BC06A; Thu, 28 Jul 2011 21:33:21 -0700 (PDT)
From: Matt McCutchen <>
To: "David A. McGrew" <>
In-Reply-To: <>
References: <> <1311734551.7071.72.camel@localhost> <>
Content-Type: text/plain; charset="UTF-8"
Date: Fri, 29 Jul 2011 00:33:19 -0400
Message-ID: <1311913999.2035.28.camel@localhost>
Mime-Version: 1.0
X-Mailer: Evolution 2.32.3
Content-Transfer-Encoding: 7bit
Cc: Philip Gladstone <>,
Subject: Re: [TLS] TLS Proxy Server Extension
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 29 Jul 2011 04:33:23 -0000

On Thu, 2011-07-28 at 12:48 -0700, David A. McGrew wrote:
> > - If you're going to require support from the client, you might as  
> > well
> > do something to support client authentication on the server-side
> > connection, e.g., tunnel the PKCS#11 protocol back to the client.
> It would be great to promote client authentication, though I'm not  
> exactly sure what you are proposing.  Do you mean to pass PKCS#11  
> through a TLS extension?

No, I imagine PKCS#11 would use several round trips, so a new
ContentType would be needed.  It's probably possible to define a more
efficient protocol than a serialization of PKCS#11, but also more work.
Whatever the protocol would be, it has to nest to handle multiple

> > - It would be better design to put the whole certificate acceptance  
> > test
> > (trust anchor validation + server name check) on the client.  Schemes
> > such as DANE replace the certificate acceptance test as a whole.
> I also have the sense that it is best to have the client do all the  
> work in most cases.   But do you think it would be OK to eliminate the  
> possibility that the proxy does some of the work?

Not sure.  Do you have a use case for the proxy doing some or all of the
work?  My point was that splitting the server name check from the trust
anchor validation is specific to PKIX certificate acceptance and serves
no purpose that I can foresee, while doing the whole test on the client
often makes sense because the client is prepared to do the whole test in
the absence of a proxy.

> > - One approach would be to do a real escrowed TLS where the client
> > negotiates directly with the server but releases the confidentiality  
> > key
> > and optionally also the integrity key to the proxy.  This subsumes all
> > of the above concerns but doesn't allow the proxy to manipulate the
> > handshake in any finer way than blocking the connection if it doesn't
> > like the outcome.
> I think that propagating secret or private keys from one device to  
> another is not a good idea, for crypto reasons which are outlined in  
> Section 6 of the draft.

I missed the potential attack when the stream is edited under a single
integrity key.  And indeed, I am having trouble coming up with any
scheme that is fundamentally simpler than two separate TLS connections
and does not introduce security problems.  You may still wish to provide
as much client-to-server negotiation transparency as possible.

Another comment:

>    The ProxyInfo
>    proposal [...]
>    allows the client to refuse to deal with untrusted proxies.

This has to be understood carefully.  An "untrusted proxy" is just a
MITM attacker.  In general, we already have a mechanism for refusing to
deal with them: it's called server authentication.  The above benefit
exists /compared to the alternative/ of a proxy trust anchor.