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

Benjamin Kaduk <kaduk@mit.edu> Thu, 15 November 2018 19:42 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 32E4A130E5E for <openpgp@ietfa.amsl.com>; Thu, 15 Nov 2018 11:42:51 -0800 (PST)
X-Quarantine-ID: <GHuzNSYTfgO2>
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 GHuzNSYTfgO2 for <openpgp@ietfa.amsl.com>; Thu, 15 Nov 2018 11:42:49 -0800 (PST)
Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (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 CF0DC130E97 for <openpgp@ietf.org>; Thu, 15 Nov 2018 11:42:48 -0800 (PST)
X-AuditID: 12074425-09fff700000031d0-71-5bedcc340a2b
Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id BA.40.12752.53CCDEB5; Thu, 15 Nov 2018 14:42:46 -0500 (EST)
Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-2.mit.edu (8.14.7/8.9.2) with ESMTP id wAFJgfmN013725; Thu, 15 Nov 2018 14:42:42 -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 wAFJga3q020980 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 15 Nov 2018 14:42:39 -0500
Date: Thu, 15 Nov 2018 13:42:36 -0600
From: Benjamin Kaduk <kaduk@mit.edu>
To: azul <azul@riseup.net>
Cc: openpgp@ietf.org
Message-ID: <20181115194235.GH70453@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> <20181115045743.GE70453@kduck.kaduk.org> <a7263dab-9949-4a75-bd81-9db0dbad0ab8@riseup.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <a7263dab-9949-4a75-bd81-9db0dbad0ab8@riseup.net>
User-Agent: Mutt/1.9.1 (2017-09-22)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNIsWRmVeSWpSXmKPExsUixG6nomt25m20waRFGhY7pq1mtGj495Dd gcljyZKfTB4/nixhCWCK4rJJSc3JLEst0rdL4MpYNfEFS8FfvorPK/8yNTC28nQxcnJICJhI HN5zlbGLkYtDSGANk8TD7avYIZyNjBJ/Dz1khnDuMklMnj2LHaSFRUBVYt7JaWA2m4CKREP3 ZWYQW0RASmJ271KWLkYODmYBEYnjO1JBwsICBhJTZv5jA7F5gbatenmUCWLmayaJf1tWQSUE JU7OfMICYjMLaEnc+PeSCWKOtMTyfxwgYU4BO4mmvTPAykUFlCX29h1in8AoMAtJ9ywk3bMQ uhcwMq9ilE3JrdLNTczMKU5N1i1OTszLSy3StdDLzSzRS00p3cQIDlMX1R2Mc/56HWIU4GBU 4uE1KH8bLcSaWFZcmXuIUZKDSUmUd58fUIgvKT+lMiOxOCO+qDQntfgQowQHs5IIr1sdUI43 JbGyKrUoHyYlzcGiJM77R+RxtJBAemJJanZqakFqEUxWhoNDSYI36TRQo2BRanpqRVpmTglC momDE2Q4D9DwulMgw4sLEnOLM9Mh8qcYFaXEeS+AJARAEhmleXC9oDQikb2/5hWjONArwrx6 ICt4gCkIrvsV0GAmoMEnpr4GGVySiJCSamBMinp3zyIjeelf2QkGIW28913Sn5s8Y2x5b+3e 4cKSu1/I8p79a9tmc80r71mW9ec//brtgv/8s0cqJq1Pe+ZzSGxV/CHmfvFl/D+C5lSKdX/9 713Wp1R1rXdV5qFtP1Ob6gIzMstV/7ezi0y+fTv3UMecGCH2Pb5X3/SflahNiLjZPuHkFw8l luKMREMt5qLiRAD6QMV6/gIAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/rRdoNV9sW0HLIBB1PvRIVx8ZEiw>
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 19:42:58 -0000

On Thu, Nov 15, 2018 at 10:16:55AM +0100, azul wrote:
> Hi,
> 
> >> 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?
> As far as i understand the compromised WKD could easily send you
> an attacker controlled key with a valid UID as well.
> 
> Why would the different UID make the attack any worse?

It seems like there's a transparency difference --if the WKD gives me a
totally spoofed key (valid/expected UID but attacker-controlled key
material) then that key could/should be on the keyservers, and the actual
holder of that UID can notice it and take action.  If I as the WKD consumer
get wholly redirected to the attacker's real key/UID, the actual intended
recipient doesn't have any way to discover that there was an attack.

-Ben