Re: [TLS] TLS Proxy Server Extension

David McGrew <mcgrew@cisco.com> Mon, 01 August 2011 19:32 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 ED14A11E8147 for <tls@ietfa.amsl.com>; Mon, 1 Aug 2011 12:32:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.733
X-Spam-Level:
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 mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sYzJu+nGUeTY for <tls@ietfa.amsl.com>; Mon, 1 Aug 2011 12:32:23 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 3836211E8144 for <tls@ietf.org>; Mon, 1 Aug 2011 12:32:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mcgrew@cisco.com; 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 mtv-core-4.cisco.com ([171.68.58.9]) by rcdn-iport-9.cisco.com with ESMTP; 01 Aug 2011 19:32:30 +0000
Received: from stealth-10-32-254-211.cisco.com (stealth-10-32-254-211.cisco.com [10.32.254.211]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p71JWSx8005377; Mon, 1 Aug 2011 19:32:29 GMT
Message-Id: <4CD821BE-2BB9-474A-8720-C86B4120444E@cisco.com>
From: David McGrew <mcgrew@cisco.com>
To: mrex@sap.com
In-Reply-To: <201108011650.p71Goc7j021785@fs4113.wdf.sap.corp>
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: <201108011650.p71Goc7j021785@fs4113.wdf.sap.corp>
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: 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- 
bifurcated-key-00.

David