IETF Logo Mail Archive

Re: [openpgp] Remove email metadata by encrypting headers using the published DKIM key

Kai Engert <kaie@kuix.de> Thu, 23 June 2022 16:37 UTC

Return-Path: <kaie@kuix.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 5EFF8C15D893 for <openpgp@ietfa.amsl.com>; Thu, 23 Jun 2022 09:37:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.983
X-Spam-Level:
X-Spam-Status: No, score=-3.983 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, NICE_REPLY_A=-1.876, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kuix.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 fi0yY50qGL6V for <openpgp@ietfa.amsl.com>; Thu, 23 Jun 2022 09:37:15 -0700 (PDT)
Received: from cloud.kuix.de (cloud.kuix.de [93.90.207.85]) (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 31B5FC13CD8F for <openpgp@ietf.org>; Thu, 23 Jun 2022 09:37:14 -0700 (PDT)
Received: from [10.137.0.4] (p5dd42650.dip0.t-ipconnect.de [93.212.38.80]) by cloud.kuix.de (Postfix) with ESMTPSA id 2F831196907; Thu, 23 Jun 2022 16:37:12 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kuix.de; s=2018; t=1656002232; bh=AWicLHGZ5HQL840VKvI+VunH0arxxgXHzohBgZLpnLU=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=fQrfk5NWqJTu2D5FThHFGAqeupRkRuzPavcElVQo5coekg1KOlju0qvxVkDD6DYz+ 7Iped3DVO+b9pp5wP/KPWsG5+y09/vLifUbGnuWY+0WHCubRCDaIFzuvvOwtRhKurp gZIRev2SQzQXOWc0j0/f5ch1gdREq2/5tylDD421HQHKkq6ajyxtGEb304mrsuzIRv 9H0jUERzL0wkpj//mtK8YFjFjqSRjFVi1GFrqoV7pLKG+6Cxd9l2f8+ibyxZ8Y+126 s39Qhq4O8c4eBxLb9Dt5gb1USQsZL8eIelZrZnTQdk8W01pSOTZSdHKDO3PCCaElbk mgtvT1awlph0g==
Message-ID: <419f3afb-d066-17e5-a88b-9b9509715d99@kuix.de>
Date: Thu, 23 Jun 2022 18:37:10 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0 Thunderbird/102.0
Content-Language: en-US
To: Tobias Mueller <tobi@cryptobit.ch>
Cc: openpgp@ietf.org
References: <f9585e88-635b-4385-afca-0de845acb875@kuix.de> <1e12d6982101bbe6c3c534f2848431a08598c10c.camel@cryptobit.ch>
From: Kai Engert <kaie@kuix.de>
In-Reply-To: <1e12d6982101bbe6c3c534f2848431a08598c10c.camel@cryptobit.ch>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/IxywM6ac2nF9qvvijyDPUZkIxYs>
Subject: Re: [openpgp] Remove email metadata by encrypting headers using the published DKIM key
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: Thu, 23 Jun 2022 16:37:19 -0000

On 23.06.22 10:45, Tobias Mueller wrote:
> 
> I guess the changes your idea brings are big enough to warrant a
> separate DKIM-like mechanism, maybe a "DomainKeys Encrypted Mail" (DKEM)
> that works about the same as DKIM.

I like the acronym DKEM. However, I'd rather define the M in DKEM as 
"Metadata", not Mail, because this isn't about encrypting all of the 
mail, only some of the headers.


> Compared to DKIM, though, the recipient server cannot process mails when
> the key is not available (or a wrong key is used) which seems like a
> rather big obstacle.

True, it would be required to demand that a sending agent checks the key 
source (e.g. DNS) right before sending it, to ensure the key information 
is fresh.

It the receiving server cannot decrypt, because a false key was used, or 
because the key is no longer available, the email must bounce. (It 
cannot do anything else without knowing the recipients.)

Kai

v2.23.0 | Report a Bug | By Email