Re: [openpgp] Context Parameters for Signing and Encryption
Marcus Brinkmann <marcus.brinkmann@rub.de> Tue, 07 February 2023 12:57 UTC
Return-Path: <marcus.brinkmann@rub.de>
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 D6246C14F730 for <openpgp@ietfa.amsl.com>; Tue, 7 Feb 2023 04:57:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.396
X-Spam-Level:
X-Spam-Status: No, score=-4.396 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, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rub.de
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hABxElofex7J for <openpgp@ietfa.amsl.com>; Tue, 7 Feb 2023 04:57:34 -0800 (PST)
Received: from out1.mail.ruhr-uni-bochum.de (out1.mail.ruhr-uni-bochum.de [134.147.53.149]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2B99C14F72D for <openpgp@ietf.org>; Tue, 7 Feb 2023 04:57:32 -0800 (PST)
Received: from mx1.mail.ruhr-uni-bochum.de (localhost [127.0.0.1]) by out1.mail.ruhr-uni-bochum.de (Postfix mo-ext) with ESMTP id 4PB37Z1qXcz8SGs; Tue, 7 Feb 2023 13:57:30 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=rub.de; s=mail-2017; t=1675774650; bh=ErtxCVGnujnnPn3cDYVJ2eL+afO6FN5MueLuw3h7+KI=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=K2F/IsWkzvBC40y/+J2Sr/1bHGtBAJ0RXLII6MBnVWCtbhgnj7f8piXgPYynUUTsL WGEIueu7aqk6qd4Es8ypUrQHxCE0tMSgREMb37GclyNIMUZS7qhYdt2MPc2zmwxDD9 yY7Fe3aKwgpjVNpc9iwTJH3ZOi1qgvfIk5fOLWC0=
Received: from out1.mail.ruhr-uni-bochum.de (localhost [127.0.0.1]) by mx1.mail.ruhr-uni-bochum.de (Postfix idis) with ESMTP id 4PB37Z14FHz8SHb; Tue, 7 Feb 2023 13:57:30 +0100 (CET)
X-RUB-Notes: Internal origin=IPv6:2a05:3e00:c:1001::8693:2aec
X-Envelope-Sender: <marcus.brinkmann@rub.de>
Received: from mail2.mail.ruhr-uni-bochum.de (mail2.mail.ruhr-uni-bochum.de [IPv6:2a05:3e00:c:1001::8693:2aec]) by out1.mail.ruhr-uni-bochum.de (Postfix mi-int) with ESMTPS id 4PB37Y4Bk6z8SJK; Tue, 7 Feb 2023 13:57:29 +0100 (CET)
X-Virus-Status: Clean
X-Virus-Scanned: clamav-milter 0.103.7 at mx1.mail.ruhr-uni-bochum.de
Received: from smtpclient.apple (p5dca432b.dip0.t-ipconnect.de [93.202.67.43]) by mail2.mail.ruhr-uni-bochum.de (Postfix) with ESMTPSA id 4PB37X6zspzDgyd; Tue, 7 Feb 2023 13:57:28 +0100 (CET)
X-Virus-Status: Clean
X-Virus-Scanned: clamav-milter 1.0.0 at mail2.mail.ruhr-uni-bochum.de
From: Marcus Brinkmann <marcus.brinkmann@rub.de>
Message-Id: <CEAED2AC-6FF8-4C1D-AFB1-CC8799749FCE@rub.de>
Content-Type: multipart/alternative; boundary="Apple-Mail=_3FEA8BF9-9646-4460-A617-96BDBBD75A23"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.300.101.1.3\))
Date: Tue, 07 Feb 2023 13:57:18 +0100
In-Reply-To: <e739c67e-b1e5-bcd7-9826-fb3a1665cf90@mtg.de>
Cc: Daniel Kahn Gillmor <dkg@fifthhorseman.net>, openpgp@ietf.org
To: Falko Strenzke <falko.strenzke@mtg.de>
References: <87y1pcm3go.fsf@fifthhorseman.net> <e739c67e-b1e5-bcd7-9826-fb3a1665cf90@mtg.de>
X-Mailer: Apple Mail (2.3731.300.101.1.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/Png55beP4Cpk5P7xkK8AH4SpwtM>
Subject: Re: [openpgp] Context Parameters for Signing and Encryption
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.39
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: Tue, 07 Feb 2023 12:57:38 -0000
HI, Thank you for asking this question. I am one of the authors of the paper, so I am partial to that question and can not answer for everybody. But I want to elaborate on the concerns of false positives as they relate to the decryption context. - our study showed that 8 out of 11 email clients did not modify the original email headers and bodies. - 2 out of 11 did modify the original headers or body, but not in a way that would affect decryption context strings - only outlook.com <http://outlook.com/> did substantial changes to the email breaking the decryption context string, but these modifications also break OpenPGP encryption in general! MS Exchange/Outlook was always an outlier in this regard, possibly because they convert MIME emails to X.400 data structures and later reassembly them, which is a lossy process. However, in the meantime, outlook.com <http://outlook.com/> at least changed its implementation and last time I checked some of these issues were fixed. However, I do not monitor this continuously, so I can not say how it is now. So, we found good compatibility. We only tested 11 email services, but these are responsible for a huge majority of the world’s email traffic and users. I also want to point out that although some changes may be harmless (for example reordering or merging multiple to/from header fields), in general changes to the header fields that are included in the decryption context policy are indistinguishable from an attack. In this sense, the mechanism is working as intended. Also, one could feasibly create more complicated decryption context string mechanisms that are tolerant to benign modifications (for example, all addresses in to-fields could be merged and sorted alphabetically), if that is desired. Saying that any non-zero false positive rate is unacceptable seems to be equivalent to saying that email providers should be able to do arbitrary changes to email headers and bodies that are submitted. Under that policy, email-based end-to-end security (where email is more than just an unreliable transport of an opaque payload) seems pretty hopeless. Thanks, Marcus — Dipl.-Math. Marcus Brinkmann Lehrstuhl für Netz- und Datensicherheit Ruhr Universität Bochum Universitätsstr. 150, Geb. ID 2/461 D-44780 Bochum Telefon: +49 (0) 234 / 32-25030 http://www.nds.rub.de/chair/people/mbrinkmann > Am 07.02.2023 um 13:13 schrieb Falko Strenzke <falko.strenzke@mtg.de>: > > I briefly looked into https://www.nds.ruhr-uni-bochum.de/media/nds/veroeffentlichungen/2020/12/06/schwenk2020.pdf > > As I understand, the mitigation they propose will lead to false positives under certain circumstances, depending on on involved MTAs. "We evaluated how eleven popular email service providers [...]". Is this really sufficient? I am far from being an expert in mail delivery, but in my understanding any commercial or self-hosted MTA could have a different effect on their countermeasure, potentially leading to false positives. False positives here seems to mean an undecipherable message arriving at the recipient. > > Has someone looked into how far the context parameters that OpenPGP would support would be affected by this? In my opinion, a false positive rate > 0 would be unacceptable and probably lead to clients not implementing that feature. > > Maybe someone with a greater understanding of this topic can elaborate on this. > > - Falko > > Am 05.02.23 um 18:23 schrieb Daniel Kahn Gillmor: >> Hi folks -- >> >> we need to resolve whether there will be a context parameter added to >> the crypto-refresh, for signing, and for encryption. i'd like folks to >> be clear aobut whether they're talking about signing or encryption, but >> we can use this thread for both. >> >> The mechanisms and use cases for signing and encryption are likely to be >> different. >> >> See https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/145 and earlier >> discussion on this list for background. >> >> The main questions: >> >> - Should we provide a context parameter for signing for v5 signatures? >> >> - Should we provide a context parameter for encryption for v2 SEIPD >> packets? >> >> >> Interesting subquestion for either of the above: >> >> - if so, how do we specify or register the context parameter for >> different use domains of use? How do we even define these different >> "domains"? >> >> An MR that says "yes, add a context parameter for both" and "don't specify any >> specific context or set up a registry for either" is at: >> https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/214 >> >> Please use this thread for this discussion, but remember to clarify >> whether you're thinking/talking about signing and encryption. >> >> --dkg >> >> >> _______________________________________________ >> openpgp mailing list >> openpgp@ietf.org <mailto:openpgp@ietf.org> >> https://www.ietf.org/mailman/listinfo/openpgp > -- > MTG AG > Dr. Falko Strenzke > Executive System Architect > > Phone: +49 6151 8000 24 > E-Mail:falko.strenzke@mtg.de <mailto:falko.strenzke@mtg.de> > Web:mtg.de <https://www.mtg.de/> > > > MTG Exhibitions – See you in 2023 > > <uI22KwkDEHtrKhZ4.png> <https://community.e-world-essen.com/institutions/allExhibitors?query=true&keywords=mtg> <Jmi6e4BcxM5Ku0A1.png> <https://www.itsa365.de/de-de/companies/m/mtg-ag> > > MTG AG - Dolivostr. 11 - 64293 Darmstadt, Germany > Commercial register: HRB 8901 > Register Court: Amtsgericht Darmstadt > Management Board: Jürgen Ruf (CEO), Tamer Kemeröz > Chairman of the Supervisory Board: Dr. Thomas Milde > > This email may contain confidential and/or privileged information. If you are not the correct recipient or have received this email in error, > please inform the sender immediately and delete this email. Unauthorised copying or distribution of this email is not permitted. > > Data protection information: Privacy policy <https://www.mtg.de/en/privacy-policy>_______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp
- [openpgp] Context Parameters for Signing and Encr… Daniel Kahn Gillmor
- Re: [openpgp] Context Parameters for Signing and … Falko Strenzke
- Re: [openpgp] Context Parameters for Signing and … Marcus Brinkmann
- Re: [openpgp] Context Parameters for Signing and … Daniel Huigens
- Re: [openpgp] Context Parameters for Signing and … Daniel Kahn Gillmor
- Re: [openpgp] Context Parameters for Signing and … Daniel Huigens
- Re: [openpgp] Context Parameters for Signing and … Daniel Kahn Gillmor
- Re: [openpgp] Context Parameters for Signing and … Andrew Gallagher
- Re: [openpgp] Context Parameters for Signing and … Daniel Huigens
- Re: [openpgp] Context Parameters for Signing and … Marcus Brinkmann
- Re: [openpgp] Context Parameters for Signing and … Andrew Gallagher
- Re: [openpgp] Context Parameters for Signing and … Bruce Walzer
- Re: [openpgp] Context Parameters for Signing and … Steffen Nurpmeso