Re: [TLS] TLS Proxy Server Extension

David McGrew <> Mon, 01 August 2011 19:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id ED14A11E8147 for <>; Mon, 1 Aug 2011 12:32:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.733
X-Spam-Status: No, score=-102.733 tagged_above=-999 required=5 tests=[AWL=-0.134, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id sYzJu+nGUeTY for <>; Mon, 1 Aug 2011 12:32:23 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 3836211E8144 for <>; Mon, 1 Aug 2011 12:32:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=1069; q=dns/txt; s=iport; t=1312227150; x=1313436750; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=8CPVIf/qTux4ovPah8X+0ItXATtWuT+BdHfozMwOTSU=; b=IKlE1QZbytmwJ7WETaukPWVl0Z42mXhmjuUxPmqufSr5fa35Q9AkX802 47UzAqraNswezdn4tu2bNC1zAfwfXxT8J9Hbb+TsWRric3yzYCV5mWNjm UGXWSYuNnlcMnCA8A8T9sekhRVz2rN/9kWdsX77ML92U6x09dXitlJ1Ns M=;
X-IronPort-AV: E=Sophos;i="4.67,301,1309737600"; d="scan'208";a="8547735"
Received: from ([]) by with ESMTP; 01 Aug 2011 19:32:30 +0000
Received: from ( []) by (8.14.3/8.14.3) with ESMTP id p71JWSx8005377; Mon, 1 Aug 2011 19:32:29 GMT
Message-Id: <>
From: David McGrew <>
In-Reply-To: <>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Mon, 1 Aug 2011 12:32:28 -0700
References: <>
X-Mailer: Apple Mail (2.936)
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: Mon, 01 Aug 2011 19:32:24 -0000

On Aug 1, 2011, at 9:50 AM, Martin Rex wrote:

> David McGrew wrote:
>> 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.

calling authenticated encryption "weaker" is wrong.  I believe what  
you mean to say is that it doesn't have this side property that you  
think is important.  Perhaps it is important, but it is not security  
property.  Historically, several real world protocols and systems have  
weakness due to poor design decisions with respect to combining  
authentication and encryption, and the use of AEAD prevents that sort  
of problem.

As a side note: AEAD algorithms could be designed that have the  
property that you want, and in fact Ken Grewal and Men Long proposed  
exactly such a thing as a variant of GCM; see draft-grewal-aes-gcm-