Re: [Cfrg] Using ephemeral DH in lieu of fresh nonces

"Scott Fluhrer (sfluhrer)" <sfluhrer@cisco.com> Mon, 22 June 2020 17:04 UTC

Return-Path: <sfluhrer@cisco.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 B908E3A0D81 for <cfrg@ietfa.amsl.com>; Mon, 22 Jun 2020 10:04:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.497
X-Spam-Level:
X-Spam-Status: No, score=-9.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=TloauEgf; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=xEBlKjNZ
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 gwxNmmlde9jj for <cfrg@ietfa.amsl.com>; Mon, 22 Jun 2020 10:04:50 -0700 (PDT)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E3A83A0D78 for <cfrg@ietf.org>; Mon, 22 Jun 2020 10:04:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=28158; q=dns/txt; s=iport; t=1592845490; x=1594055090; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=kZj4nzOi+/X40TbtjmHk644SHGHyS8YWFiQD82LTcGE=; b=TloauEgfa5NAoKUCkZOHUpWrTFLU81soaoVb9xdxTrpHrNYndVjwavmn gnGuDI0UMHF7S9TZe6p+ty0VfhF/La8KgO291hVtWkTjKBd7SnfGGluQw cT78H/GMxavtR3mHE0VVdCUBlBaa0lCA9dsBKxDtghuy59nV65taCjdu1 w=;
IronPort-PHdr: =?us-ascii?q?9a23=3AV8i6mh2QAbgonj/DsmDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxWFuadniFbCXo/W8ehVzeHRtvOoVW8B5MOHt3YPONxJWg?= =?us-ascii?q?QegMob1wonHIaeCEL9IfKrCk5yHMlLWFJ/uX3uN09TFZX0Y1TZoXe/9yQDXB?= =?us-ascii?q?74MFk9KuH8AIWHicOx2qi78IHSZAMdgj27bPtyIRy6oB+XuNMRhN5pK706zV?= =?us-ascii?q?3CpX4bdg=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CwAAA75PBe/4gNJK1mDggEAQEBAQE?= =?us-ascii?q?BAQEBAQMBAQEBEgEBAQECAgEBAQGCCoEjL1EHb1gvLAqEGoNGA41DgQGXU4F?= =?us-ascii?q?CgRADVQsBAQEMAQEYAQkHBAIEAQGERwIXghQCJDgTAgMBAQsBAQUBAQECAQY?= =?us-ascii?q?EbYVbDIVyAQEBAQECAQEQEQoTAQEsDA8CAQYCEQQBAQEnAwICAiULFAkIAgQ?= =?us-ascii?q?BEggagwWBfk0DLgEOmnqQaAKBOYhhdoEygwEBAQWBNgKDaxiCDgMGgTiCZ4Z?= =?us-ascii?q?YgWElgR4agUE/JmtDgU9JBy4+gVSBCAEBAQEBFoERARIBIxUWCYJeM4ItjnY?= =?us-ascii?q?HgyyGOospj0mBAgqCWohCkQeCcYkkkmaPXIFPihWUMwIEAgQFAg4BAQWBaiJ?= =?us-ascii?q?mcHAVO4JpUBcCDYhIhTIkCQMXg06CUIJEhQQFATcBdAIBAQESIAIGAQcBAQM?= =?us-ascii?q?JfI57AYEQAQE?=
X-IronPort-AV: E=Sophos;i="5.75,268,1589241600"; d="scan'208,217";a="529937241"
Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 22 Jun 2020 17:04:47 +0000
Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by alln-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 05MH4kSp031395 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 22 Jun 2020 17:04:46 GMT
Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 22 Jun 2020 12:04:46 -0500
Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 22 Jun 2020 12:04:45 -0500
Received: from NAM12-MW2-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 22 Jun 2020 12:04:45 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=faCccyU5fOaZqw3trDGBxfE8rLQxN+4xPRo4wFDC95pBLC9uHHDVVex6eVThJaiMFi1c3xTrzHT2KPagYzaJqy9b58Hh8eVIu5noNP92Tbp8bJlVYzLzDMbY3m62QqXXrjWPzCDHElZVPKenODngXH3A/9yCBD6zxHe1tEKeg3hk7FfThHAEDrqNwgu5KlM30/t60SxF/+u7Wu0g8vgdSramhHSPHaMnbG7N2N4CpallDrSzMKL1iwzv3M1Pz4IN8h/27ZaBgDMShDeJBjdvO7LmAMbx7QqIgffDiu8usWz234BJFV/3LYVfq2TyVKVQUNTMjLGzzm6D+wNZtBtbFw==
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=kZj4nzOi+/X40TbtjmHk644SHGHyS8YWFiQD82LTcGE=; b=Bu+7MS/xU5a5tukhqkkXqR0G5frC5BekStGCk+t/ErJc00L0NBynq3Tp/8E6B3U42/Ixc+LnG+dHuo2TsdsSQmfgGZhdplCRPcKVzchwZZioUWGH+J46Qt1ksvaDQTYNAnAxeqnDclX2g7OYe6vDmp/BKxQFq6u6OjtuwCm7j9vZ+3vaIdW0IqyHuG5Uyg4UVMGJUNsLKfHen4MpvsHv1/2kY9yPfDjZQcDzOvVzUR0K1k+EDb14dGip3GZ6g2CKOYFvsENwBSDZZVmVeHMNUpn/SSAm/q9pG84d7fDZKIY5m5xgIoeSa/Ay+0eT8tr+IQx68fLDypl/78NiqhklNA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kZj4nzOi+/X40TbtjmHk644SHGHyS8YWFiQD82LTcGE=; b=xEBlKjNZOufXOARfPYIigacd0k0m0JNzl9uIkFUxUoj6J19hrL6bBuRUtGz4z7kKVPdoICO/f38wtKT+cmF5aT17cuVlezF4YaT7Ht/ojgIo0rbz1OiDJyH0SQTsnq9+pR1HBwSrcyN5gCyTVgQp+n8SwbxSz35Iya/axgFE1WU=
Received: from BN7PR11MB2641.namprd11.prod.outlook.com (2603:10b6:406:b1::25) by BN6PR11MB3937.namprd11.prod.outlook.com (2603:10b6:405:77::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.22; Mon, 22 Jun 2020 17:04:44 +0000
Received: from BN7PR11MB2641.namprd11.prod.outlook.com ([fe80::35bd:ecae:1e28:58f5]) by BN7PR11MB2641.namprd11.prod.outlook.com ([fe80::35bd:ecae:1e28:58f5%5]) with mapi id 15.20.3109.027; Mon, 22 Jun 2020 17:04:44 +0000
From: "Scott Fluhrer (sfluhrer)" <sfluhrer@cisco.com>
To: Dan Brown <danibrown@blackberry.com>, Hugo Krawczyk <hugo@ee.technion.ac.il>, Loup Vaillant-David <loup@loup-vaillant.fr>, "<cfrg@ietf.org>" <cfrg@ietf.org>
Thread-Topic: [Cfrg] Using ephemeral DH in lieu of fresh nonces
Thread-Index: AQHWSKYvujC5Bl0SoU+h9VgbiG3oEajkv8IAgAAbEYA=
Date: Mon, 22 Jun 2020 17:04:43 +0000
Message-ID: <BN7PR11MB2641AC625A04DBFCFC2F4C11C1970@BN7PR11MB2641.namprd11.prod.outlook.com>
References: <326ebefc65c17f7fc11879b9b966a1e4585b1f16.camel@loup-vaillant.fr> <CADi0yUM6MQd0TPczK+YKSdbu1nzFaV+peC_0yf9Soat8d3+eLg@mail.gmail.com> <72d8587f17c94dfd8b67570f6a59037f@blackberry.com>
In-Reply-To: <72d8587f17c94dfd8b67570f6a59037f@blackberry.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: blackberry.com; dkim=none (message not signed) header.d=none;blackberry.com; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [173.38.117.76]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: b684ccbd-1d71-470e-d0e8-08d816ce5c59
x-ms-traffictypediagnostic: BN6PR11MB3937:
x-microsoft-antispam-prvs: <BN6PR11MB3937498236777440BE78DA08C1970@BN6PR11MB3937.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 0442E569BC
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: U/pLVB9vMIIJE4R7BvPisZNkO9Gt1AJui6BhEUO6ziK8KxzNSi7axw2rBrCxer9wEWlBakIW0wKCiF85WQnC/zRsNYWudkqBtTLVNawL/mzaKJU0agle1kZwlzYJmAODAs0SRT/Ae5aiHEWqN3OJXCdQAObsxm4plB+mOiFZejOQ9XkXv/swbfO0CK0n8TGawmoFiGrOR/av1fX+idFWCOoi8bYnXLK+HexRDwt9wimwHaiPbUpGmX71MoTmTKe75pE9k7zJhMOHgEUmfTrnPqEfH+yd8q78/C04G3jl1Sed6Lc0efHi7w8P5WV9dQV3lrIUS1al1PYNZng+KfTeoDwhL1S8Pa51zkqToCitCeRgwuwRDIgmHlUSEq6uy7cslGqJ5bgQoT0fGdmWGP9uIidwaMKQYbYJSejLwnkJNyH1UvtwvZW7qeo81wygwiqw
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN7PR11MB2641.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(366004)(346002)(376002)(396003)(39860400002)(55016002)(86362001)(71200400001)(9686003)(2906002)(7696005)(8936002)(8676002)(316002)(110136005)(66556008)(64756008)(66476007)(83380400001)(33656002)(66946007)(66446008)(76116006)(5660300002)(186003)(26005)(53546011)(52536014)(166002)(478600001)(966005)(6506007)(491001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: 4qQhbxpys7vdQK/dpCJGLBmzrJ0630rrVqKCsOZXhrPLcOXBIqnXmUWCosdxje2P2qCpZIVFlpzWc7khqZUe39QtZiXtyKtJ7seBoRUVZVezakRQD4rPXOSM20kRbJvs0f84Zv4KSgcaM1PCjcApYPZlr23hQeNiblNnIRTdUGkmO2n0DsgVPJ1SRT1K4l1IPXpoFj+2HuKb5228LFs90Omjt/mOae9Uos7Qp6IPVg6dIpiNt5zzwwZ1y3EOI1jSudoBO1/IEE4LDEdiiqAKPtvNr8zigGqSwZT+W22Zd4ciFJ824KDDKYuEkEsHzmB8DcvJYT1E/fL7xAmyK8b/BUeileqdgbLUlwB5PIkoB5u7yZ1z3D/Zbj3bJlt0X09LfJznaSGFMrfL4lIS50aWQKy80+FvHoV9JO+vCFHF4SJ+/4qFBoYXyjD6VlQchFSm1X5HHYgABP2ji+i4qTWsX7cetlVe6xjiK3M/y7Oebzk=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_BN7PR11MB2641AC625A04DBFCFC2F4C11C1970BN7PR11MB2641namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: b684ccbd-1d71-470e-d0e8-08d816ce5c59
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jun 2020 17:04:43.8920 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: IKNuoiiqaNEcu7fxejYr/l57qUt9oCyR3Mwt2v0R85RisRQndaVnYS4SUBd2h+LHLmXzexvPrnumKlIQ75HQVg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR11MB3937
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.12, xch-rcd-002.cisco.com
X-Outbound-Node: alln-core-3.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/X57COMuN8jb2v3Fw2b2gs7Orhr4>
Subject: Re: [Cfrg] Using ephemeral DH in lieu of fresh nonces
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, 22 Jun 2020 17:04:53 -0000

As for subliminal channels to exfiltrate keys, ephemeral DH can do that just fine (it just takes longer).

To exfiltrate a key (one bit at a time), one simple way you can do that is, when you need to send the next ephemeral DH key share, you generate one honestly, and check its lsbit; if it is not the bit you want to leak, then you multiple the key share by the generator (and increment the private value by 1), and repeat your check.  This means that the lsbits of the successive key shares you send spell out the key.  There are more sophisticated ways to do this; this is just a simple example.

What a nonce gives you is an easy-to-use way to exfiltrate multiple bits at once; however I don’t know if the difference in exploitability difficulty is really that significant.

From: Cfrg <cfrg-bounces@irtf.org> On Behalf Of Dan Brown
Sent: Monday, June 22, 2020 11:20 AM
To: Hugo Krawczyk <hugo@ee.technion.ac.il>il>; Loup Vaillant-David <loup@loup-vaillant.fr>fr>; <cfrg@ietf.org> <cfrg@ietf.org>
Subject: Re: [Cfrg] Using ephemeral DH in lieu of fresh nonces

Hi Hugo,
Good points about the advantages of nonces with ephemeral DH (for PAKE or TLS, etc.).
What about the disadvantages, such as misuse of nonces as a subliminal channel to exfiltrate keys?

Perhaps some protocols are already mitigate this disadvantage (e.g. strict patterned nonces, counters).  Perhaps nonce-misuse is non-issue due to the obscure threat model and due to the abundance of other subliminal channels (timing, non-crypto nonces, etc.)

Best regards,
​​​​​
Dan

From: Cfrg <cfrg-bounces@irtf.org<mailto:cfrg-bounces@irtf.org>> On Behalf Of Hugo Krawczyk
Sent: Monday, June 22, 2020 11:02 AM
To: Loup Vaillant-David <loup@loup-vaillant.fr<mailto:loup@loup-vaillant.fr>>; <cfrg@ietf.org<mailto:cfrg@ietf.org>> <cfrg@ietf.org<mailto:cfrg@ietf.org>>
Subject: [Cfrg] Using ephemeral DH in lieu of fresh nonces

In the email below, Loup raises a natural question: Why not reuse ephemeral DH values in a protocol instead of fresh nonces?

Formalisms apart, fresh non-repeating session identifiers are essential for many reasons: against replay attacks, for binding session flows together, avoiding  "composition attacks" (e.g., where flows from different sessions are mixed-and-matched), ensuring domain separation, etc. A natural implementation of session id's uses session-specific fresh random nonces. An equally natural question (and I think your email was referring to this issue) is why not use the ephemeral DH in lieu of random nonces, after all these values are selected as fresh random values for each session.

A generic reason (which I strongly advocate) for not doing so is that one should avoid having the same element in the protocol to serve  two separate functionalities/roles (in this case it would be using a DH value as key share and also as nonce/sessionid). This results in fragile protocols that can easily go wrong with variants of the protocol or when the protocol evolves over time, and is prone to bad implementations. For example, if one of the roles of this element is not  required anymore (due to changes in the protocol or changes in the setting where the protocol operates), the element may be changed "without remembering" that it had this other role.

Concretely, in the case of using ephemeral DH values for freshness, there are good practical examples where security breaks with the dual use of these values. For example, an application may decide (e.g., for performance reasons) that they do not need "perfect" forward secrecy, but that a one-minute forward-secrecy window of repeated ephemeral DH values is enough for the application. With repeated DH values used as session ids, the uniqueness of the session id is gone.  This is also the case of applications that need to avoid forward secrecy at all (see requests for a static version of TLS 1.3 in the TLS mailing list). Yet another example is the SIGMA-I protocol (used in TLS 1.3 and IKEv1). If the initiator sends g^x in the first message, this value can be used against replay attacks in the responder's signature. Then, someone decides (and there may be good reasons for that) to send g^x only in the third message and you lose your anti-replay mechanism.

Mea culpa: I have used ephemeral DH values in the dual functionality of key shares and session identifiers in several of my papers for the sake of analysis/notation simplicity. But you should not do it when building real-world implementations. In the SIGMA instantiation in draft-krawczyk-cfrg-opaque, for example, nonces are used in addition to DH values. (See also appendix B of https://webee.technion.ac.il/~hugo/sigma-pdf.pdf<https://urldefense.proofpoint.com/v2/url?u=https-3A__webee.technion.ac.il_-7Ehugo_sigma-2Dpdf.pdf&d=DwMFaQ&c=yzoHOc_ZK-sxl-kfGNSEvlJYanssXN3q-lhj0sp26wE&r=qkpbVDRj7zlSRVql-UonsW647lYqnsrbXizKI6MgkEw&m=r1zeEz6DEF0-bdDU7a7UYsRe6vNvnWpEk4pzla6k_Ow&s=XaZPR3wmEdhE0biqIgP9ZcuesZGSBCE_0gDBnILUtek&e=> )

Hugo

On Fri, Jun 19, 2020 at 12:34 PM Loup Vaillant-David <loup@loup-vaillant.fr<mailto:loup@loup-vaillant.fr>> wrote:
>>From the latest draft:

  https://tools.ietf.org/html/draft-haase-cpace-01<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dhaase-2Dcpace-2D01&d=DwMFaQ&c=yzoHOc_ZK-sxl-kfGNSEvlJYanssXN3q-lhj0sp26wE&r=qkpbVDRj7zlSRVql-UonsW647lYqnsrbXizKI6MgkEw&m=r1zeEz6DEF0-bdDU7a7UYsRe6vNvnWpEk4pzla6k_Ow&s=AuO92opvT_bYl9sYBgQ79RpgQzjqQZfXef0Dl192XxY&e=>

""" Let sid be a session id byte string chosen for each protocol
""" session before protocol execution; The length len(sid) SHOULD be
""" larger or equal to 16 bytes.

""" It is RECOMMENDED sid, is generated by sampling ephemeral random
""" strings.

Unlike ZPAD, The draft doesn't explain this recommendation.
What problem may occur if we omit sid altogether?

Even if G ends up being reused across several sessions, I don't believe
there's any way to tell, because Ya and Yb are uniformly distributed if
ya and yb are indeed random. I feel like I'm missing something.

Loup.


_______________________________________________
Cfrg mailing list
Cfrg@irtf.org<mailto:Cfrg@irtf.org>
https://www.irtf.org/mailman/listinfo/cfrg<https://urldefense.proofpoint..com/v2/url?u=https-3A__www.irtf.org_mailman_listinfo_cfrg&d=DwMFaQ&c=yzoHOc_ZK-sxl-kfGNSEvlJYanssXN3q-lhj0sp26wE&r=qkpbVDRj7zlSRVql-UonsW647lYqnsrbXizKI6MgkEw&m=r1zeEz6DEF0-bdDU7a7UYsRe6vNvnWpEk4pzla6k_Ow&s=TnDdq0O8w7uMnPtXoYDGprqQPk_1YZfKPZTB-b4rv3o&e=>
________________________________
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.