Re: [openpgp] Mitigation of Attacks on Email End-to-End Encryption

Benjamin Kaduk <kaduk@mit.edu> Mon, 09 November 2020 22:29 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: openpgp@ietfa.amsl.com
Delivered-To: openpgp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08F2C3A104B; Mon, 9 Nov 2020 14:29:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 nJM7tEKde163; Mon, 9 Nov 2020 14:29:17 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 3D78B3A1490; Mon, 9 Nov 2020 14:28:42 -0800 (PST)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 0A9MSats032668 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 9 Nov 2020 17:28:41 -0500
Date: Mon, 09 Nov 2020 14:28:36 -0800
From: Benjamin Kaduk <kaduk@mit.edu>
To: Marcus Brinkmann <marcus.brinkmann=40rub.de@dmarc.ietf.org>
Cc: openpgp@ietf.org
Message-ID: <20201109222836.GB39170@kduck.mit.edu>
References: <80af2d9c-f646-4167-209d-5fb35c880682@rub.de> <20201108072642.GP39170@kduck.mit.edu> <8a3aaa89-c95f-ebfe-944a-343939aba884@rub.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <8a3aaa89-c95f-ebfe-944a-343939aba884@rub.de>
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/5I6_LhWfiG0igAmeAUDiB7HkyW4>
Subject: Re: [openpgp] Mitigation of Attacks on Email End-to-End Encryption
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <openpgp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/openpgp>, <mailto:openpgp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/openpgp/>
List-Post: <mailto:openpgp@ietf.org>
List-Help: <mailto:openpgp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/openpgp>, <mailto:openpgp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Nov 2020 22:29:19 -0000

On Mon, Nov 09, 2020 at 02:10:31PM +0100, Marcus Brinkmann wrote:
> Hi,
> 
> Thanks for reminding me about previous efforts for header protection. We
> mention Memory Hole in the paper, but a longer discussion had to be left
> out because of the page limit.
> 
> The main point to keep in mind is that if protected headers are
> encrypted, they can't be verified before decryption. This means that
> there is a window for an attacker to potentially exploit. The semantics
> of AEAD ensure that no unauthenticated plaintext is emitted, closing
> this gap conclusively.
> 
> Having two (or more!) sets of headers, one unprotected and one
> protected, can also be very error prone and lead to usability issues.
> 
> Previous efforts have focussed on privacy, rather than as a defense to
> attacks. That said, our analysis of headers used in REPLY actions should
> be very relevant to other efforts protecting headers as well.

Indeed, and thanks again.

-Ben