Re: [openpgp] Web Key Directory I-D -07

Benjamin Kaduk <kaduk@mit.edu> Thu, 15 November 2018 04:57 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 E155E12F295 for <openpgp@ietfa.amsl.com>; Wed, 14 Nov 2018 20:57:53 -0800 (PST)
X-Quarantine-ID: <Tu2uJg4AEubr>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char 9C hex): Received: ...s kaduk@ATHENA.MIT.EDU)\n\t\234by outgoing.mit[...]
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 Tu2uJg4AEubr for <openpgp@ietfa.amsl.com>; Wed, 14 Nov 2018 20:57:51 -0800 (PST)
Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (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 26A941271FF for <openpgp@ietf.org>; Wed, 14 Nov 2018 20:57:50 -0800 (PST)
X-AuditID: 12074424-143ff70000002c2a-cf-5becfccb3c4a
Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 11.A7.11306.CCCFCEB5; Wed, 14 Nov 2018 23:57:48 -0500 (EST)
Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-3.mit.edu (8.14.7/8.9.2) with ESMTP id wAF4vkm7015261 for <openpgp@ietf.org>; Wed, 14 Nov 2018 23:57:47 -0500
Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) œby outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id wAF4vhNs008789 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <openpgp@ietf.org>; Wed, 14 Nov 2018 23:57:46 -0500
Date: Wed, 14 Nov 2018 22:57:43 -0600
From: Benjamin Kaduk <kaduk@mit.edu>
To: openpgp@ietf.org
Message-ID: <20181115045743.GE70453@kduck.kaduk.org>
References: <878t1xoz37.fsf@wheatstone.g10code.de> <9J2v287mmh9FWFLrXjxZGnVjA8HNCHpPc2wyEDDqhGeKAhE7grR6JKFMRoHJfKSq9qcjDGRNfoJ5sEODERtP0Q==@protonmail.com> <alpine.LRH.2.21.1811141020570.2540@bofh.nohats.ca> <20181115030305.GA14179@osmium.pennocktech.home.arpa>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20181115030305.GA14179@osmium.pennocktech.home.arpa>
User-Agent: Mutt/1.9.1 (2017-09-22)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGIsWRmVeSWpSXmKPExsUixCmqrXvmz5tog4XbrSwa/j1kd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXRtf3j+wFL8Qr3ky4wtTAOF+4i5GTQ0LAROJ37ybGLkYuDiGB NUwSnb/XMkM4Jxgl2tovskA4X5gkpqzZwgLSwiKgKtH86w8biM0moCLR0H2ZGcQWERCRaJu9 ix3EFhYwkJgy8x9YDS/QiqPLdjJBDOphkrh9/CMrREJQ4uTMJ2BDmQW0JG78ewlUxAFkS0ss /8cBEuYUcJLoOnsUbKaogLLE3r5D7BMY+Wch6Z6FpHsWQvcCRuZVjLIpuVW6uYmZOcWpybrF yYl5ealFuuZ6uZkleqkppZsYQcHH7qKyg7G7x/sQowAHoxIP7wmrN9FCrIllxZW5hxglOZiU RHnTwl5FC/El5adUZiQWZ8QXleakFh9ilOBgVhLhXVADVM6bklhZlVqUD5OS5mBREuf9I/I4 WkggPbEkNTs1tSC1CCYrw8GhJMH78zdQo2BRanpqRVpmTglCmomDE2Q4D9Dw+j8gw4sLEnOL M9Mh8qcYFaXEeWeBNAuAJDJK8+B6QclBInt/zStGcaBXhHmXgVTxABMLXPcroMFMQINPTH0N MrgkESEl1cCYbnRp7ZqjJu/2aW5bsi3KK1FJNLfi7fWtSp6eV324Ptyo2hgXdC3D8q+8x43X 5yMz64pKL4kGnvC/yu8Wrpnn9OzJRu75J1o3705UTH/y+qb1/WD3zZabKlnM3myLUOx2nGty m7PoWCazV/qFg/NK93WZXvrw+VzUurd+i+Yx7klUebqcf5ayEktxRqKhFnNRcSIABhlyVekC AAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/BtswWtTbAR3LYHVKT56ViQCkhHA>
Subject: Re: [openpgp] Web Key Directory I-D -07
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: Thu, 15 Nov 2018 04:57:54 -0000

On Wed, Nov 14, 2018 at 10:03:07PM -0500, Phil Pennock wrote:
> On 2018-11-14 at 10:26 -0500, Paul Wouters wrote:
> > On Tue, 13 Nov 2018, Bart Butler wrote:
> > > So if I request from ProtonMail Bart.Butler@protonmail.com, I would get a key back with bartbutler@protonmail.com, and the clients could then prompt on unrecognized types of mismatches if desired because they would know that the server is returning the canonical form of the address.
> > 
> > We went through this with OPENPGPKEY and SMIMEA. You will get the SMTP
> > people blocking your draft when you try to interpret (or like above,
> > even rewrite) addresses based on "common mail provider rewrites". Their
> > firm believe is only receiving SMTP servers can interpret email addresses.
> 
> Bart isn't suggesting encoding common rewrites into OpenPGP, although I
> believe that Werner might be.  As an MTA maintainer, I think Bart's
> suggestion is entirely appropriate and inline with the ethos of
> federated SMTP.  I'll proceed on the assumption that my analysis of
> Bart's intent is correct.  Bart, please correct me if wrong.
> 
> In Bart's suggestion, the WKD server, run within the same autonomous
> mail-system (or email administrative domain) as the SMTP servers, can
> decide to map addresses and return a key suitable for use for that email
> address.  This does not change where the MUA should send email, but does
> adjust how a well-integrated MUA might choose an appropriate OpenPGP key
> for use for a given email address.
> 
> This is entirely in line with the federated design and only the owner of
> the systems at that location getting to make such decisions.  There are
> implications around caching, because such a rewrite becomes a long-term
> commitment if it's to be stored as ancillary data in the keyring for
> choosing the correct key.
> 
> Thus if presented with a new address test+foo@spodhuis.org and needing
> to get a key for it, with Bart's proposal, the MUA and the OpenPGP
> client software can make no assumptions.  It must not normalize anything
> to the left of the '@' sign.  But the MUA can use WKD and get back a key
> for <test@spodhuis.org>;; the software can then record a mapping of
> test+foo@spodhuis.org -> test@spodhuis.org in OpenPGP recipient key
> selection preferences.  When later sending email to
> test+foo@spodhuis.org, the SMTP transaction proceeds unmodified: the MUA
> does not rewrite the recipient, you have to preserve the address
> as-given.  The remapped OpenPGP key selection proceeds as suggested
> though.  If sending email to test+bar@spodhuis.org then another WKD
> lookup needs to be made.  (Future work might look at protocols for
> indicating patterns to avoid repeated lookups).

I'm probably confused, but is this implying that WKD would insert a new
"lookup" operation such that a compromised WKD could cause me to encrypt a
message to an attacker-controlled key (with different UID) when I am trying
to encrypt to a non-attacker peer?

Thanks,

Ben