Mailing List Archive

On Sun, Jan 17, 2021 at 10:27:24PM +0100, Stefan Claas via Gnupg-users <gnupg-users@gnupg.org> wrote:

> On Sun, Jan 17, 2021 at 10:16 PM Juergen Bruckner via Gnupg-users
> <gnupg-users@gnupg.org> wrote:
>
> Please try to accept that GitHub's SSL cert is *valid*, or do you think
> that a CA certifies and invalid cert?

Please try to accept that github's certificate is only
valid for the domains that the CA certified it as being
valid for (which are listed in the certificate itself
for all to see), and that it is not valid for any other
domain (that the CA did not certify it as being valid
for).

I thought the passport example was very good. A slight
tweak (for wildcard certificates) is to imagine a
passport that identifies a person and their children,
but not their grand children. I think such passports
exist (or used to), but only for very young children.
It's not a perfect analogy, but I hope it paints the
picture well enough.

cheers,
raf


_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Hi Stefan,

On Sun, 17 Jan 2021 19:41:44 +0100,
Stefan Claas via Gnupg-users wrote:
> Please try to accept that GitHub (and maybe in the future others as well)
> has *no* bad certificate!

As others have tried to explain: the certificate that github uses for
sub.sub.github.com is invalid for sub.sub.github.com; that certificate
is only valid for sub.github.com and github.com.

:) Neal

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

On 18/01/2021 00.43, Stefan Claas wrote:
> But what you say I was thinking about as well. My proposal was to include
> in the policy file fingerprint(s) of key(s) and generate an .ots file, from
> opentimestamps.org, from the policy file and put that .ots file somewhere.
> In the old days it was common, prior starting encrypted comms to compare
> fingerprints over other channels.

If you are coordinating the use of a separate channel to compare
fingerprints, you can also just coordinate where the public keys are to
be downloaded. As others have pointed out[1], it's even easier to set
up than WKD (no rules to follow). And if you're not using the whole
thing for e-mail, then you're probably not using an e-mail client with
automatic WKD retrieval. So there is no benefit of using WKD over
making up your own URL and telling that to your communication partners.

[1]: https://lists.gnupg.org/pipermail/gnupg-users/2021-January/064633.html

> And regarding secure domains, would you consider VPS servers secure
> too for WKD?

I don't know about the servers, my point was about the domain control.
Whoever can change the DNS records can just have them point to a
different server with their own (malicious) content. GitHub Pages as a
free web hosting service will certainly not give you the same security
guarantees as a hosting provider where you pay money to administer a
domain of your own.

> BTW. I did not received yet your reply for my two other accounts, hence the
> late reply.

Sorry, I don't quite understand. Would you like a reply to be addressed
directly in addition to the mailing list?

Kind regards
André

--
Greetings...
From: André Colomb <andre@colomb.de>

Hi Angel,

On Thu, 14 Jan 2021 01:47:12 +0100,
?ngel wrote:
> On 2021-01-13 at 10:12 +0100, Neal H. Walfield wrote:
> As such, I do think sequoia is non-conformant, although I'm
> more interested in determining the proper behaviour of a WKD client.
>
> ...
> I think it would be good that sq stopped after processing
>
> openpgpkey.foo.com, mainly to follow the principle of least surprise.
>
> If the key can only be placed in one place, then it MUST be good (or
> bad, but it will be consistent).

I've given this issue some more thought.

First, I don't think WKD is a strong authentication method. It is
sufficient for doing key discovery for opportunistic encryption (i.e.,
it's a reasonable guess), but I wouldn't want someone to rely on it to
protect them from an active adversary, or phishing attempts.

If you consider WKD to be a strong authentication mechanism, then you
are basically relying on X.509 plus a bit of brittleness (the
certificates aren't signed, only the TLS session is). So, if that's
your position, then just use S/MIME.

One way to increase protection for certificates is to certify them in
the usual OpenPGP manner. Of course, this begs the question: if you
certify them before you get them via WKD, is WKD really helping with
key discovery? Well, OpenPGP doesn't only have certifications, it
also has trusted introducers, i.e., CAs. So, a certificate could be
certified by someone else. Isn't that just X.509? Well no, X.509 de
facto relies on a few hundred global CAs (Symantec, TurkTrust, etc.),
but in OpenPGP everyone is by jure a CA. So, a domain administrator
could just set up a CA for their own domain. (In fact, OpenPGP CA
[1,2] makes this pretty easy.) This results in a federated system!
Now, individuals "just" need to designate a few CAs. Yes, it is still
work, but it is much less work. As admins are more technically
sophisticated, there are other things that they can do to improve
security. But, that's getting a bit off topic.

[1] https://gitlab.com/openpgp-ca/openpgp-ca
[2] https://openpgp-ca.gitlab.io/openpgp-ca/

Second, the attack that I'm most worried about with repect to WKD is a
DoS. It is trivial for an attacker to block WKD. They just need to
filter the DNS. In the privacy world, there are a lot of tools to do
just that. For instance, pi hole [3] blocks ads at the DNS level. It
could just as well be used to force the openpgpkeys subdomain to
revolve to localhost. Comcast, a major US ISP, used to do this type
of interception as a way to increase revenue: if a user typed in an
invalid domain, instead of return NXDOMAIN, Comcast would resolve it
and show the user some ads instead [4]. AIUI, they stopped doing this
due to general outrage, but that is little solace.

[3] https://docs.pi-hole.net/main/post-install
[4] https://www.pcworld.com/article/169723/article.html

This attack is likely to go unnoticed, firstly because most key
discovery is done in the background, and probably shouldn't actively
show errors messages to the user. But, more importantly, because
nothing else uses the openpgpkeys subdomain, everything else will
still appear to work!


In short: I understand the motivation for the subdomain. I understand
why one should first check there. But, I think we do our users a
disservice by not falling back to the direct method in the case of
DNS errors.

:) Neal

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Hello again Stefan

Am 17.01.21 um 22:27 schrieb Stefan Claas:
> On Sun, Jan 17, 2021 at 10:16 PM Juergen Bruckner via Gnupg-users
> <gnupg-users@gnupg.org> wrote:
>
> Hi Juergen.
>
>> Your showcase with github.io also says nothing else than that Sequoia
>> considers an invalid certificate to be correct. That this happens in
>> audited software says just as much about the value of the audit.
>
> Please try to accept that GitHub's SSL cert is *valid*, or do you think
> that a CA certifies and invalid cert?
>
[...]

For you to take notes:
The certificate used by github issued by the CA DigiCert Inc IS valid for:

- www.github.com
- github.com
- * .github.com
- github.io
- * .github.io
- githubusercontent.com
- * .githubusercontent.com

so that means the certificate MAY be valid for
- abc.github.io

but it MUST NOT be valid for
- foo.abc.github.com

This is stipulated in the guidelines of the CA / B forum to which all
CAs worldwide have to adhere. DigiCert Inc. is no exception.

So what some members have already said to you here applies.
Sequoia accepts an *invalid* certificate for the host
'foo.abc.github.io' and that is "failure by design".

That won't change if you claim the opposite a million times.

Best
Juergen
--
/¯\ No |
\ / HTML | Juergen Bruckner
X in | juergen@bruckner.email
/ \ Mail |

On 18/01/2021 11:07, Juergen Bruckner via Gnupg-users wrote:
> Sequoia accepts an *invalid* certificate for the host
> 'foo.abc.github.io' and that is "failure by design".

This is incorrect. Sequoia *does not* accept this invalid certificate.
Sequoia and gnupg only differ in their fallback behaviour after the
certificate has been correctly rejected.

--
Andrew Gallagher

Hello André,

Am 18.01.21 um 00:03 schrieb André Colomb:
> On 17/01/2021 21.39, Juergen Bruckner via Gnupg-users wrote:
>> And as far as Sequoia is concerned, Stefen's explanations only confirmed
>> that this is software that I definitely don't want to use.
>> Software that accepts an invalid digital certificate as correct, has no
>> place in an environment where security and confidentiality are concerned.
>> This is an  a b s o l u t e  NO-GO.
>
> To be fair, it's not quite that bad. Sequoia does recognize the invalid
> certificate as such, as Neal pointed out. It just doesn't scream out
> loud about it. Instead it goes on silently trying the direct method
> instead, for which everything is configured correctly in Stefan's setup.
>
> That is not following the current WKD draft correctly, as interpreted by
> the majority of those who spoke up IIRC. But so far no scenario was
> brought up where it poses an obvious security risk. More like hiding
> the problem from an admin trying to deliberately set up the advanced
> method and possibly ending up with some forgotten remains of the direct
> method having been used before.
>
> In my opinion, the WKD spec needs clear rules about cases when to switch
> to the direct method. And making it hinge solely on proper DNS
> configuration is perfectly fine. Having enough control over the domain
> is one more prerequisite (besides the CA stuff) which an impostor would
> need to get around. After all, the corresponding web server is trusted
> to deliver the correct OpenPGP public key for authenticated communication.
>
[...]

Yes, I will be fair and say that Sequoia works okay so far.
And yes, it is good to hear from Neal that Sequoia actually recognizes
this as an invalid certificate.
BUT, if a software claim to ensure secure communication, then this shown
behavior is unacceptable to me, at least a reference to the invalid
certificate should have to be shown.

Otherwise, the discussion now mainly revolves around the fact that
Stefan still claims the certificate is valid and Sequoia continues
because of this. (At least that's my understanding of Stefan's statements).

Best regards
Juergen

--
/¯\ No |
\ / HTML | Juergen Bruckner
X in | juergen@bruckner.email
/ \ Mail |

Hello Andrew,

Am 18.01.21 um 12:17 schrieb Andrew Gallagher via Gnupg-users:
> On 18/01/2021 11:07, Juergen Bruckner via Gnupg-users wrote:
>> Sequoia accepts an *invalid* certificate for the host
>> 'foo.abc.github.io' and that is "failure by design".
>
> This is incorrect. Sequoia *does not* accept this invalid certificate.
> Sequoia and gnupg only differ in their fallback behaviour after the
> certificate has been correctly rejected.
>
Yes I do understand that behavior, but that wasnt explained that way by
Stefan.

And I have understood it so far that Stefan claims Sequoia recognizes
this certificate as valid and therefore continues to work.

To my understanding, Stefen has not yet spoken of a "fallback".

He actually went so far, to urge Werner in a more than rude way to add
this (wrong) behavior into GnuPG.

For me personally, this is still a major obstacle to using Sequoia
productively or to recommend it to our customers. I still regard this
behavior as a gross error that needs to be fixed.

Best regards from Austria
Juergen

--
/¯\ No |
\ / HTML | Juergen Bruckner
X in | juergen@bruckner.email
/ \ Mail |

On 18/01/2021 11:33, Juergen Bruckner via Gnupg-users wrote:
> Hello Andrew,
>
> Am 18.01.21 um 12:17 schrieb Andrew Gallagher via Gnupg-users:
>> On 18/01/2021 11:07, Juergen Bruckner via Gnupg-users wrote:
>>> Sequoia accepts an *invalid* certificate for the host
>>> 'foo.abc.github.io' and that is "failure by design".
>>
>> This is incorrect. Sequoia *does not* accept this invalid
>> certificate. Sequoia and gnupg only differ in their fallback
>> behaviour after the certificate has been correctly rejected.
>>
> Yes I do understand that behavior, but that wasnt explained that way
> by Stefan.
>
> And I have understood it so far that Stefan claims Sequoia recognizes
> this certificate as valid and therefore continues to work.
>
> To my understanding, Stefen has not yet spoken of a "fallback".

Stefan's understanding of the issue is incomplete; Neal's detailed
explanation of 13th Jan above explains exactly what is going on, and it
does not involve incorrectly accepting invalid certs.

> He actually went so far, to urge Werner in a more than rude way to
> add this (wrong) behavior into GnuPG.

I agree that GnuPG is under no obligation to emulate Sequoia's behaviour
here, although it would of course be preferable if a consensus could be
arrived at.

> For me personally, this is still a major obstacle to using Sequoia
> productively or to recommend it to our customers. I still regard this
> behavior as a gross error that needs to be fixed.

I think this is unfair on Sequoia. They have deviated from a draft
standard, but they have made a prima-facie case for doing so. Was this
the correct decision? I don't know. Should this decision have been
flagged more prominiently? Perhaps. But remember that WKD is a key
discovery mechanism, not a validation mechanism. It is far from
unreasonable to consider prioritising availability over correctness.

Some things in security are absolutes, and some things are trade-offs.
IMO this issue falls squarely in the "trade-off" category. Perhaps we
could collectively take a breath before continuing.

--
Andrew Gallagher

Hello Andrew,

Am 18.01.21 um 13:17 schrieb Andrew Gallagher via Gnupg-users:
> On 18/01/2021 11:33, Juergen Bruckner via Gnupg-users wrote:
>> Hello Andrew,
>>
>> Am 18.01.21 um 12:17 schrieb Andrew Gallagher via Gnupg-users:
>>> On 18/01/2021 11:07, Juergen Bruckner via Gnupg-users wrote:
>>>> Sequoia accepts an *invalid* certificate for the host
>>>> 'foo.abc.github.io' and that is "failure by design".
>>>
>>> This is incorrect. Sequoia *does not* accept this invalid
>>> certificate. Sequoia and gnupg only differ in their fallback
>>> behaviour after the certificate has been correctly rejected.
>>>
>> Yes I do understand that behavior, but that wasnt explained that way
>> by Stefan.
>>
>> And I have understood it so far that Stefan claims Sequoia recognizes
>>  this certificate as valid and therefore continues to work.
>>
>> To my understanding, Stefen has not yet spoken of a "fallback".
>
> Stefan's understanding of the issue is incomplete; Neal's detailed
> explanation of 13th Jan above explains exactly what is going on, and it
> does not involve incorrectly accepting invalid certs.
>
>> He actually went so far, to urge Werner in a more than rude way to
>> add this (wrong) behavior into GnuPG.
>
> I agree that GnuPG is under no obligation to emulate Sequoia's behaviour
> here, although it would of course be preferable if a consensus could be
> arrived at.
>
>> For me personally, this is still a major obstacle to using Sequoia
>> productively or to recommend it to our customers. I still regard this
>>  behavior as a gross error that needs to be fixed.
>
> I think this is unfair on Sequoia. They have deviated from a draft
> standard, but they have made a prima-facie case for doing so. Was this
> the correct decision? I don't know. Should this decision have been
> flagged more prominiently? Perhaps. But remember that WKD is a key
> discovery mechanism, not a validation mechanism. It is far from
> unreasonable to consider prioritising availability over correctness.
>
> Some things in security are absolutes, and some things are trade-offs.
> IMO this issue falls squarely in the "trade-off" category. Perhaps we
> could collectively take a breath before continuing.
>
>
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
>

I fully agree!
nothing more to say!

--
/¯\ No |
\ / HTML | Juergen Bruckner
X in | juergen@bruckner.email
/ \ Mail |

Hi Neal,

On 18/01/2021 10.14, Neal H. Walfield wrote:
> First, I don't think WKD is a strong authentication method. It is
> sufficient for doing key discovery for opportunistic encryption (i.e.,
> it's a reasonable guess), but I wouldn't want someone to rely on it to
> protect them from an active adversary, or phishing attempts.

That's a very good point. In that regard, the spec should maybe present
the two methods as equal alternatives to be tried in a standardized
order until either one succeeds. Requiring to report configuration
failures is really out of scope for a protocol at that level, and the
end user can hardly do anything about it anyway.

Nevertheless, a big fat warning in the log / console would be appropriate.

> In short: I understand the motivation for the subdomain. I understand
> why one should first check there. But, I think we do our users a
> disservice by not falling back to the direct method in the case of
> DNS errors.

I suppose you mean other errors besides DNS?

Whichever method was intended to be used, the (weak) trust anchor is
always the returned DNS response, and therefore both methods would be
equally screwed if a failure can be induced at that level. Pointing the
DNS response for either example.com or openpgpkey.example.com to a
malicious webserver is no different. Both would need to be done for
e.g. the ACME (Let's Encrypt) verification server's perspective as well,
which is harder than a local network attack.

We need to remember that WKD is only a convenience mechanism for
discovery, not any kind of authentication. Sending encrypted e-mail to
a domain which was also used to retrieve the encryption public key adds
no protection against MITM, but only transport obscurity. But that
might still be better than no encryption at all, e.g. to set up an
out-of-band key verification.

Kind regards
André

--
Greetings...
From: André Colomb <andre@colomb.de>

On Mon, 18 Jan 2021 13:42:52 +0100,
Andr? Colomb wrote:
> On 18/01/2021 10.14, Neal H. Walfield wrote:
> > In short: I understand the motivation for the subdomain. I understand
> > why one should first check there. But, I think we do our users a
> > disservice by not falling back to the direct method in the case of
> > DNS errors.
>
> I suppose you mean other errors besides DNS?

Right, sorry!

> We need to remember that WKD is only a convenience mechanism for
> discovery, not any kind of authentication. Sending encrypted e-mail to
> a domain which was also used to retrieve the encryption public key adds
> no protection against MITM, but only transport obscurity. But that
> might still be better than no encryption at all, e.g. to set up an
> out-of-band key verification.

I agree.

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

On 2021-01-18 at 10:14 +0100, Neal H. Walfield wrote:
> I've given this issue some more thought.
>
> First, I don't think WKD is a strong authentication method. It is
> sufficient for doing key discovery for opportunistic encryption (i.e.,
> it's a reasonable guess), but I wouldn't want someone to rely on it to
> protect them from an active adversary, or phishing attempts.
>
> If you consider WKD to be a strong authentication mechanism, then you
> are basically relying on X.509 plus a bit of brittleness (the
> certificates aren't signed, only the TLS session is). So, if that's
> your position, then just use S/MIME.

Hi Neal

I have been also giving some thought to this in the recent days.
I think the issue here is the lack of a defined policy. Each user may
have a completely different policy, but that would affect how this
should be treated.

In some cases, the user trust on the key will just be inherited from
the https certificate of the sate where it was published. In others,
the key will be completely validated through WoT.

So, while in the first case a bad certificate would be a critical
failure, in the second the right thing would be to fetch the key
*even if the certificate was invalid*, as it is used purely for
discovery.

There is also the trust on the https CA itself. Which https CA should
the client trust? The https certificate was signed by a private CA, you
might not trust certain web CA for WKD, or you could want to augment
that set with e.g. the sks-keyservers CA.

We usually consider the OpenPGP keys as standalone entities, but the
client could be tagging the received keys: "received from keyserver X",
fetched via WKD (openpgpkey.foo.com) on $DATE, retrieved through WKD
using a broken https certificate, certificate validated with PKI, with
DANE, etc.

A client could be configured to take all of that into account for
computing the key trust in a way consistent with its user opinion.


All of that complexity for then having the end user, in almost every
case, merrily re-sending it in plain text if asked to. ¯\_(?)_/¯



Some other related ideas that crossed my mind:

- If you are allowing certificates, that an unknown CA (or maybe are
even self-signed), should the client insist in that the certificate
matches the presented hostname?

- Should the client attempt to detect openpgpkey wildcard records and
ignore the advanced method in such case? (this also covers ISP
hijacking NXDOMAIN, which I also thought in)
While it's easy to detect when this seems to be the case, that's still
an heuristic, and why should I be prevented from serving WKD from a
wildcard dns record if I want to ?

- An idea that seems worth considering, inspired by the way flowcrypt
does its check, is to fall back to the direct method if the openpgpkey
subdomain exists but it doesn't serve a policy file.

This would solve the issue of non-malicious NXDOMAIN hijackings or DNS
wildcards (assuming the certificate was valid).



(...)

> This attack is likely to go unnoticed, firstly because most key
> discovery is done in the background, and probably shouldn't actively
> show errors messages to the user. But, more importantly, because
> nothing else uses the openpgpkeys subdomain, everything else will
> still appear to work!

How do you envision the users to use WKD? I would generally expect key
retrieval to be a manual action, performed either from command line or
a GUI client, but in both cases it would be possible to show a
diagnostic about the non-working WKD.* And, even if the MUA was
configured to automatically fetch the recipients key every time, it
still needs a way to report back whether the message will be sent
encrypted, there is no key or it isn't trusted. Unless OpenPGP is being
used in a purely opportunistic way.


* However, an attack where your DNS server returned a fake NXDOMAIN
would be very hard to detect.


Best regards

Ángel


_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

On Mon, Jan 18, 2021 at 01:42:52PM +0100, Andr? Colomb <andre@colomb.de> wrote:

> We need to remember that WKD is only a convenience mechanism for
> discovery, not any kind of authentication.
>
> Kind regards
> Andr?

And it's discovery that begins with an email address. I
still can't work out what functionality WKD provides in
a situation that isn't email-related.

If you have a non email-related use case for obtaining
a key, why use a non-functioning email address
lookalike as a label for the key, and then require the
user to use WKD client software to obtain the key, when
you could even more easily just give the user a URL
which can act as the label for the key, and the user
could then use any simple HTTP client to obtain the key.

In other words, when there is no email address, there
is no link between an email address's domain and a
website with the same domain (and a presumed connection
between the administration of the email and web
services for that domain), what functionality does WKD
actually provide?

It's the existence of a working email address that the
user already possesses, in combination with the
presumed link between the administration of a mail
service and a web service, that make WKD able to
provide discovery that is automatic and reliable.
Without all of the above, there is no discovery,
reliable or otherwise, and it's not automatic,
because the user has to obtain the label first
somehow.

If you have to give the user a special new label that
they don't already possess (because it isn't a natural
email address), why can't that label be a URL instead?
Why do they need special WKD software when they could
use any HTTP client? What does the user gain from it?
What does the key owner gain from it?

Forgive me if I'm being ignorant and unimaginative, and
perhaps I should just stop trying to understand, but it
looks to me like a case of finding a hammer, and things
starting to look more and more nail-like.

There should be some benefit to be had from the
additional complexity of using WKD in the absence of
email, but I can't see what it is, and it hasn't been
explained (unless I missed that).

cheers,
raf


_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

On 2021-01-17 at 23:43 +0000, Stefan Claas via Gnupg-users wrote:
> I encountered only one MITM attack a couple of years ago so far, from an
> SKS user. He was a retired police officer from Austria, who contacted me.
> But what you say I was thinking about as well. My proposal was to include
> in the policy file fingerprint(s) of key(s) and generate an .ots file, from
> opentimestamps.org, from the policy file and put that .ots file somewhere.
> In the old days it was common, prior starting encrypted comms to compare
> fingerprints over other channels.

If you can safely publish that ots file, you could as well publish your
openpgp key in the same place.

And if you are exchanging fingerprints over a separate, secure channel,
you can use that to directly verify/fetch the key.


(It often makes sense to publish it in many redundant ways, but
strictly it _shouldn't_ be needed)


Best regards


_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

On Tue, 19 Jan 2021 10:11, raf said:

> And it's discovery that begins with an email address. I
> still can't work out what functionality WKD provides in
> a situation that isn't email-related.

The Web Key Directory maps mail addresses to a key. Mail addresses are
universal identifiers and thus they can be used in most context where
you need to lookup a key which is not under the control of your
organization.


Salam-Shalom,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.

On Mon, 18 Jan 2021 16:47:38 +0100,
?ngel wrote:
> So, while in the first case a bad certificate would be a critical
> failure, in the second the right thing would be to fetch the key
> *even if the certificate was invalid*, as it is used purely for
> discovery.

When you look up the openpgpkey.example.org domain, you are revealing
to anyone snooping DNS traffic that you are using OpenPGP and are
looking for a key related to example.org. That's a privacy issue.

When you send the HTTP GET request, you reveal what email address you
are interested in (yes, it is obfuscated by the hash, but that can
often be broken using a dictionary attack). That's an even bigger
privacy issue.

Given how easy it is to get a valid TLS certificate using Let's
Encrypt, I think it is better to flatout reject invalid TLS
certificates.

> - Should the client attempt to detect openpgpkey wildcard records and
> ignore the advanced method in such case? (this also covers ISP
> hijacking NXDOMAIN, which I also thought in)
> While it's easy to detect when this seems to be the case, that's still
> an heuristic, and why should I be prevented from serving WKD from a
> wildcard dns record if I want to ?

It's an interesting idea. But I'm afraid that it really complicates
the WKD client's implementation for marginal security improvements.

> - An idea that seems worth considering, inspired by the way flowcrypt
> does its check, is to fall back to the direct method if the openpgpkey
> subdomain exists but it doesn't serve a policy file.
>
> This would solve the issue of non-malicious NXDOMAIN hijackings or DNS
> wildcards (assuming the certificate was valid).

That's a neat idea.

> How do you envision the users to use WKD? I would generally expect key
> retrieval to be a manual action, performed either from command line or
> a GUI client, but in both cases it would be possible to show a
> diagnostic about the non-working WKD.* And, even if the MUA was
> configured to automatically fetch the recipients key every time, it
> still needs a way to report back whether the message will be sent
> encrypted, there is no key or it isn't trusted. Unless OpenPGP is being
> used in a purely opportunistic way.

First, I'd regularly refresh keys in the background using all
available methods (WKD, multiple keyservers, gpg sync-style key lists)
using something like parcimonie:

https://github.com/EtiennePerot/parcimonie.sh

Second, for key discovery, there are two main types of users. For
security-sensitive users (people whose threat model includes dying if
this type of information is revealed), we should probably make key
discovery via WKD a manual operation. For privacy-sensitive users,
I'd just transparently, and automatically look for a key when the user
types in an email address. For a bit more privacy, one could wait
until the user presses send so that any WKD lookup will normally
immediately be followed by an SMTP connection to the same domain. If
key discovery fails, the MUA could show an error ("can't encrypted,
because..."), or just send the message unencrypted, like Signal.

:) Neal

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

On Tue, 19 Jan 2021 09:28, Neal H. Walfield said:

> When you look up the openpgpkey.example.org domain, you are revealing
> to anyone snooping DNS traffic that you are using OpenPGP and are
> looking for a key related to example.org. That's a privacy issue.

No, it isn't. The next thing you do is to send the mail and get a
reply. Get real.


Salam-Shalom,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.

On Tue, Jan 19, 2021 at 2:36 AM Ángel <angel@pgp.16bits.net> wrote:
>
> On 2021-01-17 at 23:43 +0000, Stefan Claas via Gnupg-users wrote:
> > I encountered only one MITM attack a couple of years ago so far, from an
> > SKS user. He was a retired police officer from Austria, who contacted me.
> > But what you say I was thinking about as well. My proposal was to include
> > in the policy file fingerprint(s) of key(s) and generate an .ots file, from
> > opentimestamps.org, from the policy file and put that .ots file somewhere.
> > In the old days it was common, prior starting encrypted comms to compare
> > fingerprints over other channels.
>
> If you can safely publish that ots file, you could as well publish your
> openpgp key in the same place.
>
> And if you are exchanging fingerprints over a separate, secure channel,
> you can use that to directly verify/fetch the key.
>
>
> (It often makes sense to publish it in many redundant ways, but
> strictly it _shouldn't_ be needed)

My thinking is the following, if there would be a consensus for
this by the OpenPGP community, after discussing this, while
currently not breaking the specs, it could be arranged like thisl:

The submitting part of an policy file, containing the fingerprint(s)
can be done even on a compromised online computer, because
the policy file is immediately accepted by opentimestamps.org
and others and then included in the Bitcoin blockchain.

As suggestion, for easy implementation,, for WKD clients,
could be that then the policy.ots file is placed in the same
directory the policy file resides.

A policy file could look like this, with remark lines at the
beginning:

# WKD policy for sac001.github.io
# Maintainer: Stefan Claas, stefan@sac001.github.io
# Updated: current date of last update.
fingerprint #1
fingerprint #2
etc.

A WKD client could then fetch with an additional --all
parameter all three files and save them in the current working directory,
e.g pub key, policy file and policy.ots, thus allowing a
WKD users to quickly check, if desired, to compare
the downloaded data with the sha256 hash at opentimestamp.org
and others.

To make it for Mallory harder to exchange the whole directory
a WKD user could for example put in his MUA/NUA .signature
file the following:

WOH sha256 hash. instead of gpg pub key availabe at etc.

WOH = WKD-OTS-Hash

And a WKD client could do this as CLI app:

wkd get [--all] alice@example.com

Well, only a proposal.

Best regards
Stefan

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

On Tue, Jan 19, 2021 at 5:05 PM Stefan Claas
<spam.trap.mailing.lists@gmail.com> wrote:

> A policy file could look like this, with remark lines at the
> beginning:
>
> # WKD policy for sac001.github.io (WRONG)
# WKD policy file for https://sac001.github.io
> # Maintainer: Stefan Claas, stefan@sac001.github.io
> # Updated: current date of last update.
> fingerprint #1
> fingerprint #2
> etc.

Regards
Stefan

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

On Tue 2021-01-19 13:08:19 +0100, Werner Koch via Gnupg-users wrote:
> On Tue, 19 Jan 2021 09:28, Neal H. Walfield said:
>
>> When you look up the openpgpkey.example.org domain, you are revealing
>> to anyone snooping DNS traffic that you are using OpenPGP and are
>> looking for a key related to example.org. That's a privacy issue.
>
> No, it isn't. The next thing you do is to send the mail and get a
> reply.

I think it's fair to say that this is in fact a privacy issue, stemming
from the fact that the act of sending an e-mail to a given recipient
these days is largely invisible to the network monitor -- the user agent
typically speaks on the network only to user's mail submission agent
(and that only through an encrypted connection). any party monitoring
the user agent only sees the rough size of the message as it passes to
the MSA.

Given that situation, there are at least four different forms of privacy
leak (in descending order of importance) from using WKD:

- the DNS lookup Neal describes above typically happens in the clear,
and is visible to anyone watching your DNS traffic. (even with
encrypted DNS transport like DoT or DoH, your trusted resolver sees
it). Those same parties won't get to know that you're sending mail
to someone in that domain otherwise.

- When your client does the TLS handshake with openpgpkey.example.org
for the HTTPS lookup, that leaks the domain name in the SNI field.
This means that anyone observing your network traffic (even if you
were using encrypted DNS transport) *also* learns that you're sending
mail to someone in that domain. They would not know this
otherwise. (this can be fixed with TLS Encrypted Client Hello, but
that extension is still under development, must be supported by both
HTTPS client and server, and far from widespread)

- For many domains, the webserver operator is not the same party as the
party that operates the e-mail infrastructure. Thus, when a WKD
lookup is made, the webserver operator learns information that they
would not have access to without running the mailservers for the
domain. Note that the webserver operator also knows *exactly* which
address the user has looked up, not just the domain -- while the
local part is hashed, that hash can be reversed for low-entropy local
parts; and in the current WKD spec the client actually reverses it
directly with the l= query parameter.

- Finally, even if the webserver operator has access to the same
information as the mailserver, the recipient's key is often looked up
via WKD *before* the message is sent, so it's possible that the user
might not send the mail, or might only send the mail much later, or
from a different network. This is a temporal privacy leak, similar
in form to the "foo is typing…" notifications displayed by some
instant messengers.

Now, comparing any of these privacy leaks to the risks of sending e-mail
in the clear is another story -- people might well be willing to accept
the risks, or to be comfortable with them being mitigated by some of the
measures i've outlined above.

One could imagine a repressive regime on a crusade against leakers,
asking their local ISPs to inform them whenever someone prepares to send
an OpenPGP-encrypted e-mail to any e-mail address in the
@dissenting-newsroom.example domain, regardless of whether the message
is actually sent. Widespread use of WKD would facilitate this kind of
risk to press freedom, even if the would-be leakers (and the newsroom)
were careful to use mailservers outside of the national jurisdiction.

WKD offers a huge boost in the usability of OpenPGP for e-mail, but we
shouldn't claim that it doesn't introduce any new privacy concerns.

--dkg

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

On Tue, Jan 19, 2021 at 5:16 PM Stefan Claas
<spam.trap.mailing.lists@gmail.com> wrote:
>
> On Tue, Jan 19, 2021 at 5:05 PM Stefan Claas
> <spam.trap.mailing.lists@gmail.com> wrote:
>
> > A policy file could look like this, with remark lines at the
> > beginning:
> >
> > # WKD policy for sac001.github.io (WRONG)
> # WKD policy file for https://sac001.github.io
> > # Maintainer: Stefan Claas, stefan@sac001.github.io
> > # Updated: current date of last update.
> > fingerprint #1
> > fingerprint #2
> > etc.

And I guess Alice or Bob would be quite happy that this looks
GDPR compatible, e.g. only putting the fingerprints in the
policy file ... :-)

Regards
Stefan

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

On Tue, Jan 19, 2021 at 1:14 PM Werner Koch via Gnupg-users
<gnupg-users@gnupg.org> wrote:
>
> On Tue, 19 Jan 2021 09:28, Neal H. Walfield said:
>
> > When you look up the openpgpkey.example.org domain, you are revealing
> > to anyone snooping DNS traffic that you are using OpenPGP and are
> > looking for a key related to example.org. That's a privacy issue.
>
> No, it isn't. The next thing you do is to send the mail and get a
> reply. Get real.

I share the same sentiments as Neal, why?

I am aware that the whole WWW can be scraped or searched in about
a couple of minutes and let's say in my GitHub case I could imagine
that for an explicit openpgpkey subdomain it could be possible to
get all WKD directories, with an openpgpkey subdomain part, in
case GitHub would do this (which they will hopefully not do.)

And at least we have the direct-method for usage without an
openpgpkey sub or sub-sub domain part. So why give WKD
enthusiast not this option and out of curiousity please try to
explain to us why the current draft say MUST and not MAY
or SHOULD? I like to learn, because WKD is freaking cool
with OpenPGP apps, like sequoia-pgp or Mailvelope etc.

Best regards
Stefan

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

On Tue, Jan 19, 2021 at 7:06 PM Stefan Claas
<spam.trap.mailing.lists@gmail.com> wrote:
>
> On Tue, Jan 19, 2021 at 1:14 PM Werner Koch via Gnupg-users
> <gnupg-users@gnupg.org> wrote:
> >
> > On Tue, 19 Jan 2021 09:28, Neal H. Walfield said:
> >
> > > When you look up the openpgpkey.example.org domain, you are revealing
> > > to anyone snooping DNS traffic that you are using OpenPGP and are
> > > looking for a key related to example.org. That's a privacy issue.
> >
> > No, it isn't. The next thing you do is to send the mail and get a
> > reply. Get real.
>
> I share the same sentiments as Neal, why?
>
> I am aware that the whole WWW can be scraped or searched in about
> a couple of minutes and let's say in my GitHub case I could imagine
> that for an explicit openpgpkey subdomain it could be possible to
> get all WKD directories, with an openpgpkey subdomain part, in
> case GitHub would do this (which they will hopefully not do.)
>
> And at least we have the direct-method for usage without an
> openpgpkey sub or sub-sub domain part. So why give WKD
> enthusiast not this option and out of curiousity please try to
> explain to us why the current draft say MUST and not MAY
> or SHOULD? I like to learn, because WKD is freaking cool
> with OpenPGP apps, like sequoia-pgp or Mailvelope etc.

Example: Mallory sitting in the United States likes to prepare
a list (without my consent) and published on a U.S. site,
so that like SKS key server dumps the whole world can
obtain a list of all openpgpkey subdomains. So far so good.

Mr 'edge case' Stefan knows this and counterstrikes with
his domain radio-eriwan.su (which I own) and set's up for
Mr Mallory a WKD direct-method dir with n dummy keys.

Good luck Mr Mallory figuring out which domains have real
OpenPGP users keys hosted and which not.

Best regards
Stefan

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

On 2021-01-19 at 19:29 +0100, Stefan Claas wrote:
> Example: Mallory sitting in the United States likes to prepare
> a list (without my consent) and published on a U.S. site,
> so that like SKS key server dumps the whole world can
> obtain a list of all openpgpkey subdomains. So far so good.
>
> Mr 'edge case' Stefan knows this and counterstrikes with
> his domain radio-eriwan.su (which I own) and set's up for
> Mr Mallory a WKD direct-method dir with n dummy keys.
>
> Good luck Mr Mallory figuring out which domains have real
> OpenPGP users keys hosted and which not.
>
> Best regards
> Stefan

A list of all (well, most) openpgpkey subdomains can be easily created.
However, there is no need for or dummy keys.

Mallory sees that radio-eriwan.su supports WKD (this is immediate, it
doesn't matter if it uses the advanced or direct method). However, it
can't ask for all keys it stores. Mallory will need to ask for every
possible key:

Do you have an OpenPGP key for a@radio-eriwan.su ?
Do you have an OpenPGP key for b@radio-eriwan.su ?
Do you have an OpenPGP key for c@radio-eriwan.su ?
…
Do you have an OpenPGP key for z@radio-eriwan.su ?
Do you have an OpenPGP key for aa@radio-eriwan.su ?
Do you have an OpenPGP key for ab@radio-eriwan.su ?

and so on until

zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz
zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz
zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz
zzzzzzzzzzzzzzzzzzzzzzzzz@radio-eriwan.su

even if Mallory only checks email addresses with lowercase letters
(although they are not the only allowed characters in an email
address), he would need to ask for 5.8×10³³? email addresses. Just for
radio-eriwan.su

This can be optimized by checking instead the full space of sha-1
hashes, to "only" perform 1.46×10?? requests (assuming the server
doesn't validate the local part on WKD requests).

Anyway, such attack is completely unrealistic.

In order to get all keys Mallory would either need access to the server
files (e.g. it compromised the server, or the contents are published in
github), or the web server to have been (mis?)configured with Directory
Listings.

Best regards



_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users