‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Thursday, November 15, 2018 11:42 AM, Benjamin Kaduk
<kaduk(_at_)mit(_dot_)edu> wrote:
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
The MUA could always have some kind of warning in this situation if the UserID
match isn't recognized ("recognized" matches could include subaddresses, etc.
but would be at the MUA's discretion). I'd leave this up to the MUA
implementation.
-Bart
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp
signature.asc
Description: OpenPGP digital signature
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp