On Thu, Nov 15, 2018 at 10:16:55AM +0100, azul wrote:
Hi,
Thus if presented with a new address test+foo(_at_)spodhuis(_dot_)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(_at_)spodhuis(_dot_)org>; the software can then record a mapping
of
test+foo(_at_)spodhuis(_dot_)org -> test(_at_)spodhuis(_dot_)org in
OpenPGP recipient key
selection preferences. When later sending email to
test+foo(_at_)spodhuis(_dot_)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(_at_)spodhuis(_dot_)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
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp