Support email 'verification' using WKD as 'proof' #20

Open
opened 3 months ago by caesar · 7 comments
caesar commented 3 months ago

Normally, email is obviously a very hard thing to verify in a public / stateless way.

However, it just occurred to me that WKD might be a solution, for those domains which support it (sorry Gmail users).

Since WKD 'authoritatively' associates a GPG key with an email address, a WKD lookup returning a key with the appropriate fingerprint could be considered to validate a claim on that email address.

Since GPG keys already 'claim' email addresses, this needn't be explicit: every email identity in a key could automatically be subjected to verification by WKD lookup. (If the domain doesn't support WKD, that shouldn't be shown as a red-cross 'failed verification', though, as it's potentially outside the user's control.)

Normally, email is obviously a very hard thing to verify in a public / stateless way. However, it just occurred to me that WKD might be a solution, for those domains which support it (sorry Gmail users). Since WKD 'authoritatively' associates a GPG key with an email address, a WKD lookup returning a key with the appropriate fingerprint could be considered to validate a claim on that email address. Since GPG keys already 'claim' email addresses, this needn't be explicit: every email identity in a key could automatically be subjected to verification by WKD lookup. (If the domain doesn't support WKD, that shouldn't be shown as a red-cross 'failed verification', though, as it's potentially outside the user's control.)
Owner

I'm not convinced a valid WKD key counts as a verified email address. WKD looks like an email address but it isn't: it's just says "user A" has uploaded a key on "server B".

I agree there is no reason for a service provider that provides both email and WKD to give "bob" the email address to one person and "bob" the WKD identifier to another person! It makes no sense.

But still, the link between email and WKD is indirect.

Yeah, email is a difficult beast :/

I'm not convinced a valid WKD key counts as a verified email address. WKD looks like an email address but it isn't: it's just says "user A" has uploaded a key on "server B". I agree there is no reason for a service provider that provides both email and WKD to give "bob" the email address to one person and "bob" the WKD identifier to another person! It makes no sense. But still, the link between email and WKD is indirect. Yeah, email is a difficult beast :/
Poster

Hmm, that's an interesting way to look at it, but I have to say I'm not convinced.
The WKD page on gnupg.org and the WKD spec itself are both quite clear that it is "a service to locate OpenPGP keys by mail address".

Further, it's specifically intended to be a secure way to obtain a trusted OpenPGP key corresponding to a given email address, versus using a public keyserver.

Obviously it's not a technical requirement that this has to be the case, but it's a requirement of the spec. Of course, a malicious server might choose not to follow the spec / to return an invalid key. But the same applies to every other type of claim too.

Other than the potential case of an actively malicious server, are you aware of any example of a server which (contrary to the spec) serves keys for a WKD request which do not correspond to the equivalently-named email address at that same domain?


On a slight tangent, it also occurred to me that it would be theoretically possible to "outsource" email verification to keys.openpgp.org, because it is a verifying keyserver. Theoretically, for any key that can be obtained from it, it has verified that the user actually owns that email address.
But I do not for a moment suggest we do so; that would be a terrible idea on multiple levels.

Hmm, that's an interesting way to look at it, but I have to say I'm not convinced. The [WKD page on gnupg.org](https://wiki.gnupg.org/WKD) and [the WKD spec itself](https://datatracker.ietf.org/doc/draft-koch-openpgp-webkey-service/) are both quite clear that it is "a service to locate OpenPGP keys by mail address". Further, it's specifically intended to be a *secure* way to obtain a *trusted* OpenPGP key corresponding to a given email address, versus using a public keyserver. Obviously it's not a *technical requirement* that this *has to be* the case, but it's a requirement of the spec. Of course, a malicious server might choose not to follow the spec / to return an invalid key. But the same applies to every other type of claim too. Other than the potential case of an actively malicious server, are you aware of any example of a server which (contrary to the spec) serves keys for a WKD request which do not correspond to the equivalently-named email address at that same domain? --- On a slight tangent, it also occurred to me that it would be *theoretically possible* to "outsource" email verification to `keys.openpgp.org`, because it is a *verifying* keyserver. Theoretically, for any key that can be obtained from it, it has verified that the user actually owns that email address. But I do not for a moment suggest we do so; that would be a terrible idea on multiple levels.
Poster

a malicious server might choose not to follow the spec / to return an invalid key. But the same applies to every other type of claim too.

Now I think about it, I suppose this is not strictly true. Many proofs are attested on a different domain from the keyserver, meaning impersonation would not be possible without collusion from both parties.
In the case of WKD it would be possible under some circumstances for a compromised host to both serve a false key and intercept your mail.
But the same vulnerability does apply to any proof hosted on the same domain as the WKD server, such as DNS claims, as well as hosted services like Gitea, Mastodon, etc.

Which makes me wonder if, for added security (not just for a hypothetical email claim, but for all claims), DOIP should try to retrieve keys from both WKD and HKP, and show a big warning if keys with different fingerprints are received. 🤔

> a malicious server might choose not to follow the spec / to return an invalid key. But the same applies to every other type of claim too. Now I think about it, I suppose this is not strictly true. Many proofs are attested on a different domain from the keyserver, meaning impersonation would not be possible without collusion from both parties. In the case of WKD it would be possible under some circumstances for a compromised host to both serve a false key *and* intercept your mail. But the same vulnerability does apply to any proof hosted on the same domain as the WKD server, such as DNS claims, as well as hosted services like Gitea, Mastodon, etc. Which makes me wonder if, for added security (not just for a hypothetical email claim, but for all claims), DOIP should try to retrieve keys from *both* WKD *and* HKP, and show a big warning if keys with different fingerprints are received. 🤔
Owner

The WKD page on gnupg.org and the WKD spec itself are both quite clear that it is "a service to locate OpenPGP keys by mail address".

And spec:

This specification describes a service to locate OpenPGP keys by mail address using a Web service and the HTTPS protocol

Good point. I have read the WKD spec two times I think while implementing it on my server and somehow, I've managed to always miss this nuance. It's not meant to just be a way to distribute arbitrary keys. It's meant to distribute them using the email address they are linked to as identifier.

That convinces me that we could consider WKD as "proof" of email address. Malicious servers could always interfere but only up to a limit as serving the wrong public key in the worst key makes a claim impossible to verify, but wouldn't allow for the verification of fake claims (I think! I need to think this through in my head)

Only downside: we could only verify one of the UIDs via WKD. Hmm unless for each UID, we quickly fetch the key and if the fingerprint matches, we can verify each UID using a separate WKD request.

Which makes me wonder if, for added security (not just for a hypothetical email claim, but for all claims), DOIP should try to retrieve keys from both WKD and HKP, and show a big warning if keys with different fingerprints are received. 🤔

And what about those that only use one protocol? Is that like "half" verified? And HKP+WKD is "full" verified?

In any case, I like the idea of combining HKP+WKD but we should be mindful of people that do not have the skills and/or means to have WKD.

Or is this specifically to verify WKD? And is HKP considered by default "safe"?

> The WKD page on gnupg.org and the WKD spec itself are both quite clear that it is "a service to locate OpenPGP keys by mail address". And spec: > This specification describes a service to locate OpenPGP keys by mail address using a Web service and the HTTPS protocol Good point. I have read the WKD spec two times I think while implementing it on my server and somehow, I've managed to always miss this nuance. It's not meant to just be a way to distribute arbitrary keys. It's meant to distribute them using the email address they are linked to as identifier. That convinces me that we could consider WKD as "proof" of email address. Malicious servers could always interfere but only up to a limit as serving the wrong public key in the worst key makes a claim impossible to verify, but wouldn't allow for the verification of fake claims (I think! I need to think this through in my head) Only downside: we could only verify one of the UIDs via WKD. Hmm unless for each UID, we quickly fetch the key and if the fingerprint matches, we can verify each UID using a separate WKD request. > Which makes me wonder if, for added security (not just for a hypothetical email claim, but for all claims), DOIP should try to retrieve keys from both WKD and HKP, and show a big warning if keys with different fingerprints are received. 🤔 And what about those that only use one protocol? Is that like "half" verified? And HKP+WKD is "full" verified? In any case, I like the idea of combining HKP+WKD but we should be mindful of people that do not have the skills and/or means to have WKD. Or is this specifically to verify WKD? And is HKP considered by default "safe"?
Poster

That convinces me that we could consider WKD as "proof" of email address.

Good 😉 I think it makes sense. It's as secure as many of the other claims, I believe, and the relationship is explicit as discussed.

Only downside: we could only verify one of the UIDs via WKD. Hmm unless for each UID, we quickly fetch the key and if the fingerprint matches, we can verify each UID using a separate WKD request.

I would treat it like any other claim. Yes, if the key is fetched with WKD in the first place, one of the claims is already verified. But the others can be verified by fetching the key for each identity and checking that it has the same fingerprint, like we would do with #19 (Git forges) and #1 (Facebook) for example. It's the same logic.


Regarding the secondary idea of comparing WKD to HKP as an extra security check (not really relevant to the main issue of "claiming" an demail address):

And what about those that only use one protocol? Is that like "half" verified? And HKP+WKD is "full" verified?

In any case, I like the idea of combining HKP+WKD but we should be mindful of people that do not have the skills and/or means to have WKD.

I was thinking of this more as a sort of "failsafe": If the key exists on both WKD and HKP but with different fingerprints, assume something is wrong, and show a warning.
But now I'm less sure that that would make sense. Sure, it would mean something's wrong – but in most circumstances, couldn't a malicious party who can substitute a false key via WKD also send a new key to the keyservers too? So it might not add much in the way of security checks.

Or is this specifically to verify WKD? And is HKP considered by default "safe"?

Not at all, WKD should generally be considered safer than HKP, becaue there are less intermediaries to trust. That's one of the main reasons for WKD to exist in the first place.

But for the main point of this issue, "claiming" an email address, WKD is all that matters, since HKP can't prove ownership of an email address in the same way.
Let's leave the secondary issue, of possibly comparing the two sources, for future consideration. 🙂

> That convinces me that we could consider WKD as "proof" of email address. Good 😉 I think it makes sense. It's as secure as many of the other claims, I believe, and the relationship is explicit as discussed. > Only downside: we could only verify one of the UIDs via WKD. Hmm unless for each UID, we quickly fetch the key and if the fingerprint matches, we can verify each UID using a separate WKD request. I would treat it like any other claim. Yes, if the key is fetched with WKD in the first place, one of the claims is already verified. But the others can be verified by fetching the key for each identity and checking that it has the same fingerprint, like we would do with #19 (Git forges) and #1 (Facebook) for example. It's the same logic. --- Regarding the secondary idea of comparing WKD to HKP as an extra security check (not really relevant to the main issue of "claiming" an demail address): > And what about those that only use one protocol? Is that like "half" verified? And HKP+WKD is "full" verified? > > In any case, I like the idea of combining HKP+WKD but we should be mindful of people that do not have the skills and/or means to have WKD. I was thinking of this more as a sort of "failsafe": *If* the key exists on both WKD and HKP but with different fingerprints, assume something is wrong, and show a warning. But now I'm less sure that that would make sense. Sure, it would mean something's wrong – but in most circumstances, couldn't a malicious party who can substitute a false key via WKD also send a new key to the keyservers too? So it might not add *much* in the way of security checks. > Or is this specifically to verify WKD? And is HKP considered by default "safe"? Not at all, WKD should generally be considered safer than HKP, becaue there are less intermediaries to trust. That's one of the main reasons for WKD to exist in the first place. But for the main point of this issue, "claiming" an email address, WKD is all that matters, since HKP can't prove ownership of an email address in the same way. Let's leave the secondary issue, of possibly comparing the two sources, for future consideration. 🙂
Owner

the relationship is explicit as discussed.

Sorry for being like this… For the record, I want it stated that I do not believe the relationship is "explicit". An encrypted email arriving in the correct inbox containing a link being clicked is "explicit". WKD is a fundamentally different technology than email and both are entirely unrelated, except that the spec says they should be linked.

"Because the spec says so" is a good enough argument for me to accept it but still, I wouldn't qualify the relationship as "explicit".

I've said it, it's written down, I will now no longer pester anyone anymore with this distinction 😅


Re WKD as WKD proof: overall sounds good. Need to ponder the arguments here a bit more.

Re WKD as HKP proof: I see your point. It would complicate the entire story quite a bit. As you said, "for future consideration".

since HKP can't prove ownership of an email address in the same way.

Only valid for keys.openpgp.org (and thus invalid for HKP in general): they only return keys if the UID email addresses have been verified (by email link!). So keys.openpgp.org is quite a secure way to prove an email address. HKP in general is not.

I think both WKD and keys.openpgp.org-only could benefit from a small green tick confirming the email address.

I was thinking of this more as a sort of "failsafe"

I try to be careful with "negative" demonstrations. It's hard to claim something is fishy when it could either be just a mistake somewhere or even intentional. I don't know why anyone would do otherwise, but there's no reason the key on HKP should match the key on WKD for the same email address. I mean, it would be weird to not have them match, but in the end, that's not my business. It could be intentional.

I think I'd rather "augment" a validity then "diminish" it. IMHO

> the relationship is explicit as discussed. Sorry for being like this… For the record, I want it stated that I do not believe the relationship is "explicit". An encrypted email arriving in the correct inbox containing a link being clicked is "explicit". WKD is a fundamentally different technology than email and both are entirely unrelated, except that the spec says they should be linked. "Because the spec says so" is a good enough argument for me to accept it but still, I wouldn't qualify the relationship as "explicit". I've said it, it's written down, I will now no longer pester anyone anymore with this distinction 😅 --- Re WKD as WKD proof: overall sounds good. Need to ponder the arguments here a bit more. Re WKD as HKP proof: I see your point. It would complicate the entire story quite a bit. As you said, "for future consideration". > since HKP can't prove ownership of an email address in the same way. Only valid for keys.openpgp.org (and thus invalid for HKP in general): they only return keys if the UID email addresses have been verified (by email link!). So keys.openpgp.org is quite a secure way to prove an email address. HKP in general is not. I think both WKD and keys.openpgp.org-only could benefit from a small green tick confirming the email address. > I was thinking of this more as a sort of "failsafe" I try to be careful with "negative" demonstrations. It's hard to claim something is fishy when it could either be just a mistake somewhere or even intentional. I don't know why anyone would do otherwise, but there's no reason the key on HKP should match the key on WKD for the same email address. I mean, it would be weird to not have them match, but in the end, that's not my business. It could be intentional. I think I'd rather "augment" a validity then "diminish" it. IMHO
Poster

Ehh, what do I find when I go browsing issues on keyoxide-web… Wiktor thought of this months ago 😀

keyoxide/keyoxide-web#95

Ehh, what do I find when I go browsing issues on keyoxide-web… Wiktor thought of this months ago 😀 https://codeberg.org/keyoxide/keyoxide-web/issues/95
Sign in to join this conversation.
No Milestone
No project
No Assignees
2 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.