[Cfrg] PAKE Selection Process: Round 2, Documents for Stage 4

Björn Haase <bjoern.haase@endress.com> Mon, 10 February 2020 14:50 UTC

Return-Path: <bjoern.haase@endress.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C84312022D for <cfrg@ietfa.amsl.com>; Mon, 10 Feb 2020 06:50:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=endress.com header.b=VyVDkgqZ; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=endress.com header.b=URmu72UX
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WIAEbODylz_o for <cfrg@ietfa.amsl.com>; Mon, 10 Feb 2020 06:50:52 -0800 (PST)
Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10044.outbound.protection.outlook.com [40.107.1.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0138120227 for <cfrg@irtf.org>; Mon, 10 Feb 2020 06:50:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=endress.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=e1sbFXElLnKzrYNAqGo97IRUo3owN0zVTQfocdqUOl8=; b=VyVDkgqZn7b2TGqIurd80YzRm5mFmh/urUCu1iz3Gf0CyKcdO3uOHgA6Hjvj8ceHDOjDIfuIOYSoK46swCQgqcqt5fe3+Ac52yaKkaO3RRLpH9Fx4ZG9fWQgaC6tlAE95ukJ0HSDf5qxATL7b6DsyiEAJ18bdTwKeqDeexB9mQY=
Received: from AM4PR0501CA0045.eurprd05.prod.outlook.com (2603:10a6:200:68::13) by DB7PR05MB5691.eurprd05.prod.outlook.com (2603:10a6:10:81::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2707.21; Mon, 10 Feb 2020 14:50:48 +0000
Received: from VE1EUR03FT035.eop-EUR03.prod.protection.outlook.com (2a01:111:f400:7e09::204) by AM4PR0501CA0045.outlook.office365.com (2603:10a6:200:68::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2707.21 via Frontend Transport; Mon, 10 Feb 2020 14:50:48 +0000
Authentication-Results: spf=pass (sender IP is 13.79.242.66) smtp.mailfrom=endress.com; irtf.org; dkim=fail (body hash did not verify) header.d=endress.com;irtf.org; dmarc=pass action=none header.from=endress.com;
Received-SPF: Pass (protection.outlook.com: domain of endress.com designates 13.79.242.66 as permitted sender) receiver=protection.outlook.com; client-ip=13.79.242.66; helo=iqsuite.endress.com;
Received: from iqsuite.endress.com (13.79.242.66) by VE1EUR03FT035.mail.protection.outlook.com (10.152.18.110) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.2665.18 via Frontend Transport; Mon, 10 Feb 2020 14:50:47 +0000
Received: from mail pickup service by iqsuite.endress.com with Microsoft SMTPSVC; Mon, 10 Feb 2020 15:50:46 +0100
Received: from EUR05-AM6-obe.outbound.protection.outlook.com ([104.47.18.111]) by iqsuite.endress.com over TLS secured channel with Microsoft SMTPSVC(8.5.9600.16384); Mon, 10 Feb 2020 15:50:45 +0100
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=chikvrViLcS9/ckErd6VR4i7lSYvK+Ka1Pm5wioVRKTy+g7PMLyJfzoUsROrrVlXBXP8S9JtoLhHQkJMKXC6wPfN+6iwSU4tzK6Q5Q9js3AunGevx3Ze5q6t65qaw2AR7MDbzOm/W0z1dqcxSgHYGZyewNHYh7JTJR+YhIKtMGoRcQ9o5Z9eRKb5WAwkmeRVAXvbPVVRMXPNhEQz/2mbH1zUzevWa7w5zR2HRiV/gCBMCuCytLtdj3yP9gfFXlidTQWJDHYL5esAzwWrrxGrGOzoIgotbWFYmfgOvc0ek+HkRChKdDwvEDjpFl08m2C0SFOURV3AV3DjpDUw+H223g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fgmqIU3/N1U0AdBYiK6JMg/yCkFtLCtzDT+M6aUny1s=; b=O5b6EMeBm2Cp111/EUG6tap79gHDELDSnBDdNLxEiK/3r1qmO0U4jIS6l+LkxtJN5uDIuX3q3evDplrnnAhzIIFkT5P9OIL0m3uXrAbhKgkXO5eNE4PzWPmK0AUduUlZ+dcmGGb/Bu3FQxdwump0D8EOTtesrfkWBszEgK9xU3a3EgRHDo2fw6mYl4iz1Tu4mywD8j9WxwZOUDVkqzQ1ke3e8i9+Vz9DGHSw70LCoSLq7lQiJMimgySoEPtctqmbiqDLOhkncFWS5888eh45rGEDVIElzxlN8acQpkIDv/fEv0aXMJaO/bTGzkee3ID28XaBFSnwfft8eawWYJ36ow==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=endress.com; dmarc=pass action=none header.from=endress.com; dkim=pass header.d=endress.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=endress.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fgmqIU3/N1U0AdBYiK6JMg/yCkFtLCtzDT+M6aUny1s=; b=URmu72UXSo8BO3XNG5OpDWxluJ4eAVXXH3C0vwHZ8hxNO8HD7tgUogdWC16ve7j2d5Ud8+zSHf8udgWP49zZiA5AFu3bCVJzvYX9F50qXVP9i0vPFz99QFvK3i/VtF44U51CY1DFVJtNfHllrKDx4oJ708KdJn13EDqzEAMAFZc=
Received: from AM0PR05MB4786.eurprd05.prod.outlook.com (52.133.57.143) by AM0PR05MB5986.eurprd05.prod.outlook.com (20.178.117.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2707.26; Mon, 10 Feb 2020 14:50:44 +0000
Received: from AM0PR05MB4786.eurprd05.prod.outlook.com ([fe80::5511:16a9:b981:b642]) by AM0PR05MB4786.eurprd05.prod.outlook.com ([fe80::5511:16a9:b981:b642%5]) with mapi id 15.20.2707.028; Mon, 10 Feb 2020 14:50:44 +0000
From: =?utf-8?B?QmrDtnJuIEhhYXNl?= <bjoern.haase@endress.com>
To: cfrgirtf.org <cfrg@irtf.org>
Thread-Topic: PAKE Selection Process: Round 2, Documents for Stage 4
Thread-Index: AdXgIWeh4fUKIGRSREi8Wgq/SqeMZA==
Date: Mon, 10 Feb 2020 14:50:44 +0000
Message-ID: <AM0PR05MB47863A24C0EC4648B0ECFDC583190@AM0PR05MB4786.eurprd05.prod.outlook.com>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_2988f0a4-524a-45f2-829d-417725fa4957_Enabled=True; MSIP_Label_2988f0a4-524a-45f2-829d-417725fa4957_SiteId=52daf2a9-3b73-4da4-ac6a-3f81adc92b7e; MSIP_Label_2988f0a4-524a-45f2-829d-417725fa4957_Owner=bjoern.haase@endress.com; MSIP_Label_2988f0a4-524a-45f2-829d-417725fa4957_SetDate=2020-02-10T08:36:18.1763788Z; MSIP_Label_2988f0a4-524a-45f2-829d-417725fa4957_Name=Not Protected; MSIP_Label_2988f0a4-524a-45f2-829d-417725fa4957_Application=Microsoft Azure Information Protection; MSIP_Label_2988f0a4-524a-45f2-829d-417725fa4957_ActionId=b60b0182-f617-4e15-a6ce-44c2d57336b4; MSIP_Label_2988f0a4-524a-45f2-829d-417725fa4957_Extended_MSFT_Method=Automatic
Authentication-Results-Original: spf=none (sender IP is ) smtp.mailfrom=bjoern.haase@endress.com;
x-originating-ip: [93.240.145.106]
x-ms-publictraffictype: Email
X-MS-Office365-Filtering-Correlation-Id: ac8e48d5-3979-44b2-244a-08d7ae389d2b
X-MS-TrafficTypeDiagnostic: AM0PR05MB5986:|DB7PR05MB5691:
X-Microsoft-Antispam-PRVS: <DB7PR05MB569164A1E42A2859F27FBF5A83190@DB7PR05MB5691.eurprd05.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;OLM:10000;
x-forefront-prvs: 03094A4065
X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009020)(4636009)(136003)(376002)(39860400002)(346002)(396003)(366004)(189003)(199004)(55016002)(9686003)(76116006)(66946007)(966005)(64756008)(66446008)(66476007)(33656002)(478600001)(5660300002)(66556008)(71200400001)(52536014)(6506007)(66574012)(8676002)(186003)(316002)(81166006)(6916009)(7696005)(81156014)(86362001)(26005)(85182001)(85202003)(8936002)(2906002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR05MB5986; H:AM0PR05MB4786.eurprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: endress.com does not designate permitted sender hosts)
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam-Untrusted: BCL:0;
X-Microsoft-Antispam-Message-Info-Original: NftrBVUUqhZ16X6AKz1bhCPAhmWnZNlYBjVha0LQD8N9Jtaj+DtUCWfskqUkYnWMAvnSfEa1M0NltGHH5h61Wnp1xXq/TrN9qPqTec9/3Q7IhqHTYUz25slYf68wzJG8Z2yPeHy/qq32C+a57gCOzpmMCSF/Wa5PQoPJR+iYwT0xOOOR/9clvFZD8lURbFZFGM2txHgoIUcMNc1bcKvNicIPdsi2N7V8MFetbIZZ8GewU+WAgd66JV6+GzUalOkg10smQuAWCP0mWq0hoHKI1UmCtLNWq7PPVh9pk+XubmnOYObnSNVaGBSvFcfhNOCgOEgyt1N1c4sad4MotKrJTQGq4vqoPwMhWgH684xo7Pw/+5B6wt7yfe9mDQm4XVsPhzIqyCENtqJGshFA1yG0vFduiLZNBfpAaCAtQb0Tk0Z8TyQlyG0gIaS4jdG2StLOdbpSmY837rx+SvNm67GgAKmsOBndZXu/X5VQxU7AvNyLHZrYI3mzFVWice/FtAAJWHQ+ffMhNv7YJadkZfX5tA==
x-ms-exchange-antispam-messagedata: 1sVAljerMPJThwXAwOsNZgsvo9w1xKd5PeeJ6SF1PHVAQaeYK0BccEkyafR9jupqYN8DBE+1VIXIXNBh+my0gbCD1P3ntXJxYFiVpwfDVTVJFDO+h+MZxwpmFJjlvgh+o0XcoxoFRHEt+OMHPwcOZw==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR05MB5986
X-OriginalArrivalTime: 10 Feb 2020 14:50:45.0587 (UTC) FILETIME=[79986230:01D5E021]
X-Trailer: 1
X-GBS-PROC: p80nxHum6fWX6t/ZhXm7TXVwTx8fSEmCJVAeCJ51NaA=
X-GRP-TAN: IQNE02@1B600B0B813046699E9A84FF9083989A
X-iqsuite-process: processed
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped: VE1EUR03FT035.eop-EUR03.prod.protection.outlook.com
X-Forefront-Antispam-Report: CIP:13.79.242.66; IPV:; CTRY:IE; EFV:NLI; SFV:NSPM; SFS:(10009020)(4636009)(346002)(376002)(136003)(396003)(39860400002)(199004)(189003)(85182001)(6916009)(478600001)(966005)(336012)(85202003)(70206006)(70586007)(5660300002)(81156014)(186003)(15974865002)(26005)(6506007)(9686003)(7696005)(356004)(52536014)(86362001)(55016002)(2906002)(66574012)(316002)(8676002)(33656002)(8936002)(81166006); DIR:OUT; SFP:1101; SCL:1; SRVR:DB7PR05MB5691; H:iqsuite.endress.com; FPR:; SPF:Pass; LANG:en; PTR:InfoDomainNonexistent; A:1; MX:1;
X-MS-Office365-Filtering-Correlation-Id-Prvs: d3dffbd1-85b7-462a-00b0-08d7ae389b56
X-Forefront-PRVS: 03094A4065
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: ViWoeQu591OTgYLAItwXI+P8p7A4NECbN2IU/ezjSc2OhoGE+rxilWDIEXosQnlmPEhIbQd+Vtcc/vl0hqxBJs7HL1j/hcewylaD37VA6+G2Z2huCk2BDkQB4NF/iEy00xnLGKKyZCgptFWJB0VviOslAvUHgh2zLcM5l7KgzNTLjqVRFAXmy6barOvHGe6L6/t9RGjDmzQYYYf9bAGWJC6Yp0SXm4t3WyfekqKS4Gs3PmAjVqJzjaqxIq4In9W96AOcNYyfuVvH8tXf6DTnfyf3MMtP3M29a3HEr78sq4peSmOb87tQX44A/vW4RRcmPrytwYgXNZiA8b/v8QuKLpLvYZN72WzQUx3eBNfIwq0NzGWvIWXSgirap1jKhkxSmRTZIkw0M34cQFrHygaMJyiP0B1UXmAQ1Z2wxCYn+7l6djNrHZVD5Kz7wAmp1kb2c5mWrx84ACoAbfXolBw1Yu2degOZXOYtG+aMqNkwgRWWji5V8MZqYXromKOOAd2Xx9X3B/Y0yVrsKq+oNTH9Ng==
X-OriginatorOrg: endress.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Feb 2020 14:50:47.3505 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: ac8e48d5-3979-44b2-244a-08d7ae389d2b
X-MS-Exchange-CrossTenant-Id: 52daf2a9-3b73-4da4-ac6a-3f81adc92b7e
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=52daf2a9-3b73-4da4-ac6a-3f81adc92b7e; Ip=[13.79.242.66]; Helo=[iqsuite.endress.com]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR05MB5691
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/eRNe0SYH3lwHifwZkmqHRy4pdNE>
Subject: [Cfrg] PAKE Selection Process: Round 2, Documents for Stage 4
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Feb 2020 14:50:56 -0000

Dear CFRG,

as requested for the beginning of stage 4 of the second round of the PAKE selection process, I have compiled the additional documentation at the following places.

Paper: 
https://github.com/BjoernMHaase/AuCPace/blob/master/aucpace_security_analysis_20200208.pdf

Internet Drafts:
https://tools.ietf.org/html/draft-haase-aucpace-01
https://tools.ietf.org/html/draft-haase-cpace-01

Reference implementations:
https://github.com/BjoernMHaase/AuCPace


Please find a short version of my replies below:

Question 2):
"(to CPace and AuCPace): Can you propose a modification of CPace and AuCPace (preserving all existing good properties of these PAKEs) with a correspondingly updated security proof (maybe, in some other security models), addressing the issue of requiring the establishment of a session identifier (sid) during each call of the protocol for the cost of one additional message?"

Reply to 2) :
I have re-reviewed this issue and integrated the alternative approach as suggested by Ran Canetti on the CFRG list in the paper and security analysis (see “paper” link above). The specification in the CPace and AuCPace internet drafts now also correspond to this approach. With this method, there is no longer the need for an additional communication round.

Question 3):
 "(to all 4 remaining PAKEs) : Can the nominators/developers of the protocols please re-evaluate possible IPR conflicts between their candidates protocols and own and foreign patents? Specifically, can you discuss the impact of U.S. Patent 7,047,408 (expected expiration 10th of march 2023) on free use of SPAKE2 and the impact of EP1847062B1 (HMQV, expected expiration October 2026) on the free use of the RFC-drafts for OPAQUE?"

Reply to 3):
I have re-visited all patents and did not find any IPR that might generate conflicts with CPace and AuCPace. The topic of the mapping algorithms is resolved in my opinion with the latest changes in the hash_to_curve draft (which avoids the “-1 non-s	quare” topic and the “three-polynomial” issue for SSWU).

In contrast, in the course of this research I came to the conclusion that SPAKE2 is probably affected by US 7,047,408. The exceptional feature is that the duration of this patent seems to have been extended to a period of exceptional 23 years instead of 20 years! I have double-checked and that seems indeed to be legally possibly in the US. I have just filed a corresponding IPR disclosure.

Question 4): 
"(to all 4 remaining PAKEs) What can be said about the property of "quantum annoyance" (an attacker with a quantum computer needs to solve [one or more] DLP per password guess) of the PAKE?"

Reply to 4):

As previously noted also by “Steve Thomas”, for CPace an active adversary needs to solve at least one DLP per password guess this also holds for the conventionally augmented AuCPace variant. 

The additional guarantee of “pre-computation attack resistance” provided by the OPRF construction of strong AuCPace, however will not be preserved. This means that the *strong* AuCPace protocol will fall back the conventionally augmented AuCPace in the post-quantum world, which itself is again quantum annoying.  (This comes as a consequence of the issue with the "static Diffie-Hellmann oracle topic" regarding the OPAQUE OPRF, as brought up recently by Steve Thomas recently on the crypto panel list).

Question 5):  "(to all 4 remaining PAKEs) What can be said about "post-quantum preparedness" of the PAKE?"

Reply to 4):

In the Internet Drafts regarding CPace and AuCPace I have added a short discussion on this topic.

I believe that the fact that CPace and AuCPace don’t actually require a full group structure but only operations in a "group modulo negation" might provide a path for using isogeny-based cryptography as kind of a drop-in replacement for the Diffie-Hellmann substeps. 

While primitives such as SIKE and CSIDH provide functionality similar to a DH secret establishment (where both parties contribute to the key), there is no such equivalent of “point addition” in the isogeny world. In my opinion, for the augmentation layer of AuCPace, the mechanisms on isogenies for Diffie-Hellmann-style secret establishment could already be used as-is. For the application in CPace (with the need of an isogeny-equivalent of a secret password-derived base point), there is ongoing research which is, however, not yet stabilized and mature in my opinion. Here I have added a links regarding possible migration paths regarding CPace in the security considerations section of the internet draft.

Additionally, the modularized security analysis of CPace as a building block of AuCPace allows for replacing the CPace component by any future balanced post-quantum PAKE (in the style that Hugo suggests for OPAQUE).
 For instance, I believe it to be promising to consider constructions based on the LWE problem where the matrices are kept secret and derived from a password and an ephemeral session id, in the style of "New hope" which uses SHAKE for generation of ephemeral LWE matrices. Still again, this topic, just as the isogenies, would require significant future research in my opinion.

I am unfortunately not aware of any current concept regarding a post quantum primitive for the OPRF construction as needed for *strong* AuCPace.

Yours,

Björn Haase


P.S.: A compilation regarding my personal view on the current state of the selection process is found at

https://github.com/BjoernMHaase/fe25519/blob/master/Slides_PAKE_selection_at_CFRG_Brainpool_20200115.pdf 

I tried to be as objective as one could reasonably be expecting from an individual having own nominations running.


Mit freundlichen Grüßen I Best Regards 

Dr. Björn Haase 


Senior Expert Electronics | TGREH Electronics Hardware
Endress+Hauser Conducta GmbH+Co.KG | Dieselstrasse 24 | 70839 Gerlingen | Germany
Phone: +49 7156 209 377 | Fax: +49 7156 209 221
bjoern.haase@endress.com |  www.conducta.endress.com 



Endress+Hauser Conducta GmbH+Co.KG
Amtsgericht Stuttgart HRA 201908
Sitz der Gesellschaft: Gerlingen
Persönlich haftende Gesellschafterin:
Endress+Hauser Conducta Verwaltungsgesellschaft mbH
Sitz der Gesellschaft: Gerlingen
Amtsgericht Stuttgart HRA 201929
Geschäftsführer: Dr. Manfred Jagiella

 
Gemäss Datenschutzgrundverordnung sind wir verpflichtet, Sie zu informieren, wenn wir personenbezogene Daten von Ihnen erheben.
Dieser Informationspflicht kommen wir mit folgendem Datenschutzhinweis (https://www.endress.com/de/cookies-endress+hauser-website) nach.

 

Disclaimer: 

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you receive this in error, please contact the sender and delete the material from any computer. This e-mail does not constitute a contract offer, a contract amendment, or an acceptance of a contract offer unless explicitly and conspicuously designated or stated as such.