Discussion:
Proposal of OpenPGP Email Validation
(too old to reply)
n***@enigmail.net
2015-07-27 05:55:03 UTC
Permalink
Hi all,

in March we discussed here
"German ct magazine postulates death of pgp encryption"
and Patrick Brunschwig proposed a way to validate email addresses
http://lists.gnupg.org/pipermail/gnupg-users/2015-March/052882.html
In the past months I tried to come up with a concrete proposal.
I discussed it already with some people and
this is what I/we propose so far.
The proposal is not perfect and not completely worked out
but IMO it is ready for a broader discussion and review.

Thus, I am happy for any feedback
(details and general remarks)
both here and directly as email to me.

If the concept is possible and useful
the goal is to have a first validating keyserver proxy
(see the document for details what this is)
at the end of this year.
We have some guy willing to implement it
as part of a Bachelor thesis.

Best regards
Nico
--
Nicolai M. Josuttis
www.josuttis.de
mailto:***@enigmail.net
PGP fingerprint: CFEA 3B9F 9D8E B52D BD3F 7AF6 1C16 A70A F92D 28F5
--
Nicolai M. Josuttis
www.josuttis.de
mailto:***@enigmail.net
PGP fingerprint: CFEA 3B9F 9D8E B52D BD3F 7AF6 1C16 A70A F92D 28F5
Neal H. Walfield
2015-07-27 12:15:57 UTC
Permalink
Hi,

I guess you mean this:

The idea I have in mind is roughly as follows: if you upload a key to
a keyserver, the keyserver would send an encrypted email to every UID
in the key. Each encrypted mail contains a unique link to confirm the
email address. Once all email addresses are confirmed, the key is
validated and the keyserver will allow access to it just like with any
regular keyserver.

This approach is not going to stop a nation state. A nation state can
intercept the mail, decrypt it and follow the link.

For the same reason, it is not going to stop a user's ISP. Given
Microsoft's et al.'s willingness to cooperate with the NSA, these are
not very good starting conditions.

The approach also has another problem: which key servers are going to
do this? There are 100s of key servers. I'm not going to reply to
mails from each one, sorry.

This also seems like a nice way to spam someone. Generate a key,
upload it to a key server and they have a bunch of mails from the key
server. Based on this, I suspect that it won't take long for the key
servers to be blacklisted?

Have you considered these issues? Do you have any thoughts about how
to avoid these problems or do you think they are not real problems?


Regarding the design: personally, I wouldn't have the user follow a
link that includes a swiss number, but have the user reply to the
mail, include the swiss number and sign it.

I'd also consider having the key servers publish the validations. If
you chain the validations (include the hash of the previous validation
in the current validation) you can detect if the key servers serve a
fake key to a specific user.

Neal
Daniel Baur
2015-07-27 12:33:42 UTC
Permalink
Hello,
Post by Neal H. Walfield
This approach is not going to stop a nation state. A nation state can
intercept the mail, decrypt it and follow the link.
For the same reason, it is not going to stop a user's ISP. Given
Microsoft's et al.'s willingness to cooperate with the NSA, these are
not very good starting conditions.
As far as I understand, the email is encrypted with the public key of
the owner – so as long as we think that GPG is safe, Nico’s
verification-emails should be also safe.

What could be a problem: The state or the ISP could create a key-pair of
its own and upload it, intercept the mail and verify it.

Sincerely,
DaB.
MFPA
2015-07-27 22:56:50 UTC
Permalink
Hi


On Monday 27 July 2015 at 1:33:42 PM, in
Post by Daniel Baur
What could be a problem: The state or the ISP could
create a key-pair of its own and upload it, intercept
the mail and verify it.
That certainly would be a problem. I've no idea how likely.


- --
Best regards

MFPA <mailto:2014-667rhzu3dc-lists-***@riseup.net>

None are so fond of secrets as those who do not mean to keep them
n***@enigmail.net
2015-07-27 17:21:10 UTC
Permalink
Thanks, Neal for the feedback.
I will try to answer.
Post by Neal H. Walfield
Hi,
The idea I have in mind is roughly as follows: if you upload a key to
a keyserver, the keyserver would send an encrypted email to every UID
in the key. Each encrypted mail contains a unique link to confirm the
email address. Once all email addresses are confirmed, the key is
validated and the keyserver will allow access to it just like with any
regular keyserver.
Hmm, not quite right, there are two major points where I think
there is some misunderstanding:

First, I DON'T propose to use key servers here.
In agreement with Kristian Fiskerstrand we propose to give
other servers the task.
As written, these "validation servers" should ideally operate as key
server proxies, though, passing all requests to keyservers and responses
back to email clients, while in addition doing/triggering email validations.
But for ordinary keyservers validations servers "only" provide
validation signatures as any other email client can do.

Second, because the signatures sign UIDs (not keys),
each UID is individually signed.
A validation server could wait to upload the key to a key server
until the FIRST email address is signed.
But in principle, uploading a key or a new UID for the key
is different from triggering its validation (and as a result uploading
the corresponding validation signature to the UID(s)).
Post by Neal H. Walfield
This approach is not going to stop a nation state. A nation state can
intercept the mail, decrypt it and follow the link.
Sorry, don't know what a nation state is.
Post by Neal H. Walfield
For the same reason, it is not going to stop a user's ISP. Given
Microsoft's et al.'s willingness to cooperate with the NSA, these are
not very good starting conditions.
Although, Daniel answered, I didn't quite get the problem here
and would be happy if you prefer to explain the problem a bit in detail
(yes, sorry, I am not an expert).
Post by Neal H. Walfield
The approach also has another problem: which key servers are going to
do this? There are 100s of key servers. I'm not going to reply to
mails from each one, sorry.
Hmm, I though I discussed that but may be my wording was bad.
Indeed, there should only by one validation request per email address
each year.
For this, we'd trust multiple validation signatures. But yes,
as I wrote, we have to maintain white- and/or black lists then
(in email clients or where ever).
And yes, THIS can be(come) a problem.
Post by Neal H. Walfield
This also seems like a nice way to spam someone. Generate a key,
upload it to a key server and they have a bunch of mails from the key
server. Based on this, I suspect that it won't take long for the key
servers to be blacklisted?
We though about that, but right I didn't write anything about it.
We might follow the following rule:
- Once validated, no re-validations can be triggered
within the 12 months the signature is valid
(may be unless the owner of the key itself troggers the re-validation)
- But yes, then we have the problem of others uploading
faked keys (the problem we want to solve).
First: May be it's fine that people get informed that
faked keys are uploaded.
At least I personally would like to know that.
Then: I could trigger my own validation and as written
in the first bullet disable any other validations
unless triggered by me.
Thus, once there is a successful validation
this is no loner a problem.
Post by Neal H. Walfield
Have you considered these issues? Do you have any thoughts about how
to avoid these problems or do you think they are not real problems?
At least a part of them, I hope.
But I would not be surprised having overlooked some stuff.
You are the experts.
I only want to solve the problem.

And indeed , the question, how to avoid to many validation requests
while at the same time having multiple validation servers
is something I am pretty unsure about details.
I am happy for any help here.
Post by Neal H. Walfield
Regarding the design: personally, I wouldn't have the user follow a
link that includes a swiss number, but have the user reply to the
mail, include the swiss number and sign it.
OK, that's of course also possible.
Any reason why this is something you prefer?
Post by Neal H. Walfield
I'd also consider having the key servers publish the validations. If
you chain the validations (include the hash of the previous validation
in the current validation) you can detect if the key servers serve a
fake key to a specific user.
OK, interesting idea.

Thanks a lot
Nico
Post by Neal H. Walfield
Neal
_______________________________________________
Gnupg-users mailing list
http://lists.gnupg.org/mailman/listinfo/gnupg-users
--
Nicolai M. Josuttis
www.josuttis.de
mailto:***@enigmail.net
PGP fingerprint: CFEA 3B9F 9D8E B52D BD3F 7AF6 1C16 A70A F92D 28F5
Neal H. Walfield
2015-07-27 19:08:43 UTC
Permalink
Hi Nico,

At Mon, 27 Jul 2015 19:21:10 +0200,
Post by n***@enigmail.net
Thanks, Neal for the feedback.
I will try to answer.
Post by Neal H. Walfield
Hi,
The idea I have in mind is roughly as follows: if you upload a key to
a keyserver, the keyserver would send an encrypted email to every UID
in the key. Each encrypted mail contains a unique link to confirm the
email address. Once all email addresses are confirmed, the key is
validated and the keyserver will allow access to it just like with any
regular keyserver.
Hmm, not quite right, there are two major points where I think
If this is not right please point me to the proposal. The above is
just a quote from the single source in your original email. After I
read that I will respond to your other questions / comments.

:) Neal
Juan Miguel Navarro Martínez
2015-07-27 19:22:08 UTC
Permalink
Post by Neal H. Walfield
If this is not right please point me to the proposal. The above is
just a quote from the single source in your original email. After I
read that I will respond to your other questions / comments.
:) Neal
It's attached in the OP named "OpenPGP-Email-Validation-20150726.pdf"
--
Juan Miguel Navarro Martínez

GPG Keyfingerprint:
5A91 90D4 CF27 9D52 D62A
BC58 88E2 947F 9BC6 B3CF
Werner Koch
2015-07-27 17:46:03 UTC
Permalink
Post by Neal H. Walfield
The approach also has another problem: which key servers are going to
do this? There are 100s of key servers. I'm not going to reply to
mails from each one, sorry.
As Nico described, PGP used a very simlar system to validate keys and
expire them based on the date of the last validation. However, that
system worked with because they control the central server and the
server did not sync with the other keyserver automatically. The
validation signature you find on some the keys are due to faulty manual
syncing (download from pgp.com upload to pgp.net). A solid approach for
central crypto server.
Post by Neal H. Walfield
I'd also consider having the key servers publish the validations. If
you chain the validations (include the hash of the previous validation
You can't do that due to the decentralized approach with no requirement
for the user to always upload to the same keyserver. Thus a server may
miss validation signatures not yet received from other servers.


Salam-Shalom,

Werner
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
Kristian Fiskerstrand
2015-07-27 17:54:14 UTC
Permalink
Post by Werner Koch
You can't do that due to the decentralized approach with no
requirement for the user to always upload to the same keyserver.
Thus a server may miss validation signatures not yet received from
other servers.
The way I read this proposal isn't about keyservers per se, but the
individual validation servers publishing a chained list (like a
blockchain) of its validations. There is merit to that proposal for
auditing purposes, although I'm not entirely sure how it'd work in
practice unless the blockchain itself was decentralized (it can't
function securely if completely local to validation server). iirc this
is what Google is doing with its approach as well[0].

References:
[0] http://www.certificate-transparency.org/
--
----------------------------
Kristian Fiskerstrand
Blog: http://blog.sumptuouscapital.com
Twitter: @krifisk
----------------------------
Public OpenPGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
----------------------------
"Knowing is not enough; we must apply. Willing is not enough; we must do."
(Johann Wolfgang von Goethe)
Werner Koch
2015-07-28 07:44:37 UTC
Permalink
Post by Kristian Fiskerstrand
The way I read this proposal isn't about keyservers per se, but the
individual validation servers publishing a chained list (like a
Right. I assume that these validation servers still work like the
the regualr keyservers and sync between them. The question about the
implementaion language of SKS indated to me that the validation servers
are based on that protocol and would thus also use the Gossip protocol.


Shalom-Salam,

Werner
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
n***@enigmail.net
2015-07-29 05:42:34 UTC
Permalink
Hi
On Monday 27 July 2015 at 1:15:57 PM, in
Post by Neal H. Walfield
Regarding the design: personally, I wouldn't have the
user follow a link that includes a swiss number, but
have the user reply to the mail, include the swiss
number and sign it.
Why not simplify the workflow:-
1. key reaches validation server.
2. for each UID containing an email address, validation server creates
a copy of the key stripped of all other UIDs.
3. validation server signs that copy of the key.
4. validation server pastes the signed key into an email, encrypts the
email to that key, and sends it to the email address in the UID.
5. user receives each email, decrypts it, and updates their local copy of
their key.
6. user uploads key now bearing the validation server's signatures to
a keyserver.
Interesting.
What comes into my mind is the following:
- This requires special email clients.
The benefit of the proposed workflow is that any existing client
can use it just by switching its keyserver to the validating
keyserver proxy.
IMO, that's a huge drawback, because any solution that
requires email client updates is a lot harder to establish.
- How to deal with existing keys?
Well probably the same
(upload a key for the first time and uploading it
for updates would run the saem workflow), right?
There is still the same level of assurance that the email address and
private key are controlled by the same entity. Advantages are:-
a. Nobody is asked to click links or reply to emails.
Hmm, isn't step 5 is kind of that?
In any case some confirmation email handling is required.
If this is done by the email client silently,
this also can be done by the email client in my proposal.
But again this requires supporting clients.
b. The validation server does not need to manage a "stack" of keys
awaiting feedback from the validation emails.
indeed, that's an argument
c. Changes to the user's key are uploaded to the keyserver by the
user, not by the validation server.
Is this a real benefit?

Thanks
Nico
--
Nicolai M. Josuttis
www.josuttis.de
mailto:***@enigmail.net
PGP fingerprint: CFEA 3B9F 9D8E B52D BD3F 7AF6 1C16 A70A F92D 28F5
n***@enigmail.net
2015-07-29 06:28:26 UTC
Permalink
Post by n***@enigmail.net
b. The validation server does not need to manage a "stack" of keys
awaiting feedback from the validation emails.
indeed, that's an argument
Hmm, but IMO we anyway need a state in validation servers to deal with
different spam schemes
(i.e. avoiding that any request to a v-server sends an email).
--
Nicolai M. Josuttis
www.josuttis.de
mailto:***@enigmail.net
PGP fingerprint: CFEA 3B9F 9D8E B52D BD3F 7AF6 1C16 A70A F92D 28F5
Ingo Klöcker
2015-07-29 10:05:13 UTC
Permalink
Post by n***@enigmail.net
Why not simplify the workflow:-
1. key reaches validation server.
2. for each UID containing an email address, validation server creates
a copy of the key stripped of all other UIDs.
3. validation server signs that copy of the key.
4. validation server pastes the signed key into an email, encrypts the
email to that key, and sends it to the email address in the UID.
5. user receives each email, decrypts it, and updates their local copy of
their key.
6. user uploads key now bearing the validation server's signatures to
a keyserver.
There is still the same level of assurance that the email address and
private key are controlled by the same entity. Advantages are:-
c. Changes to the user's key are uploaded to the keyserver by the
user, not by the validation server.
Is this a real benefit?
A possible benefit would be that the user can choose not to upload the
validation signatures to the keyservers. With a minor change in step 1 (the
key owner uploads his key to the validation server without uploading it to a
keyserver) the UID validation would even work for keys which its owner does
not want to upload to a public keyserver.


Regards,
Ingo
MFPA
2015-07-29 12:41:42 UTC
Permalink
Hi


On Wednesday 29 July 2015 at 11:05:13 AM, in
Post by Ingo Klöcker
A possible benefit would be that the user can choose
not to upload the validation signatures to the
keyservers. With a minor change in step 1 (the key
owner uploads his key to the validation server without
uploading it to a keyserver) the UID validation would
even work for keys which its owner does not want to
upload to a public keyserver.
That would be good: mail clients that applied a rule to only use
validated keys would otherwise deny service when emailing somebody who
is trying to keep their key off the keyservers.



- --
Best regards

MFPA <mailto:2014-667rhzu3dc-lists-***@riseup.net>

If at first you don't succeed, destroy all evidence that you tried.
Kristian Fiskerstrand
2015-07-29 12:47:35 UTC
Permalink
Post by MFPA
Hi
On Wednesday 29 July 2015 at 11:05:13 AM, in
Post by Ingo Klöcker
A possible benefit would be that the user can choose not to
upload the validation signatures to the keyservers. With a minor
change in step 1 (the key owner uploads his key to the validation
server without uploading it to a keyserver) the UID validation
would even work for keys which its owner does not want to upload
to a public keyserver.
That would be good: mail clients that applied a rule to only use
validated keys would otherwise deny service when emailing somebody
who is trying to keep their key off the keyservers.
Are they really the target group for this proposal? Keep in mind this
would be in addition to the regular WoT model, so there is no DoS
based on that, per se (obviously you should never encrypt data to a
key that isn't verified on some level, even if just a heuristic
analysis based on public data and a local non-exportable signature).

If the key isn't on keyserver it defeats some of the purpose of this
being an easy to use for senders (while still providing _some_ level
of security).

- --
- ----------------------------
Kristian Fiskerstrand
Blog: http://blog.sumptuouscapital.com
Twitter: @krifisk
- ----------------------------
Public OpenPGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
- ----------------------------
"A committee is a group that keeps minutes and loses hours."
(Milton Berle)
MFPA
2015-07-29 14:02:37 UTC
Permalink
Hi


On Wednesday 29 July 2015 at 1:47:35 PM, in
Post by Kristian Fiskerstrand
Post by MFPA
That would be good: mail clients that applied a rule
to only use validated keys would otherwise deny
service when emailing somebody who is trying to keep
their key off the keyservers.
Are they really the target group for this proposal?
The target group for an email address validation certificate on my key
would be people who wanted to email me.



- --
Best regards

MFPA <mailto:2014-667rhzu3dc-lists-***@riseup.net>

Humility is no substitute for a good personality.
Kristian Fiskerstrand
2015-07-29 14:13:06 UTC
Permalink
[Sent from my HTC, as it is not a secured device there are no cryptographic
keys on this device, meaning this message is sent without an OpenPGP
signature. In general you should *not* rely on any information sent over
such an unsecure channel, if you find any information controversial or
un-expected send a response and request a signed confirmation]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Hi
On Wednesday 29 July 2015 at 1:47:35 PM, in
Post by Kristian Fiskerstrand
Post by MFPA
That would be good: mail clients that applied a rule
to only use validated keys would otherwise deny
service when emailing somebody who is trying to keep
their key off the keyservers.
Are they really the target group for this proposal?
The target group for an email address validation certificate on my key
would be people who wanted to email me.
You are still in control of that given that you can (i) opt not to click
the validation link, so other users defer back to WoT, same as today (ii)
elect not to give any ownertrust to the CA
MFPA
2015-07-29 12:25:31 UTC
Permalink
Hi


On Wednesday 29 July 2015 at 6:42:34 AM, in
Post by n***@enigmail.net
- This requires special email clients.
How would this require a special email client?

OpenPGP-aware email clients I have used have a simple way to save a
key from a message to the keyring by clicking a button or selecting a
menu option. And if the user's email client is not OpenPGP-aware, or
they use webmail, there is always copy and paste.
Post by n***@enigmail.net
The benefit of
the proposed workflow is that any existing client can
use it just by switching its keyserver to the
validating keyserver proxy.
I only suggested simplification of the workflow for actually
validating/signing the keys. The user can still just switch their
keyserver of choice to the validating proxy.
Post by n***@enigmail.net
How to
deal with existing keys? Well probably the same
(upload a key for the first time and uploading it
for updates would run the saem workflow), right?
Yes. And for automatic re-validations, before my step 1 (key reaches
validation server) the proxy server would consult its list of which
keys it signed when and fetch them for revalidation.
Post by n***@enigmail.net
There is still the same level of assurance that the
email address and private key are controlled by the
same entity. Advantages are:-
a. Nobody is asked to click links or reply to emails.
Hmm, isn't step 5 is kind of that?
No. Step 5 is that the user receives an encrypted email to each
relevant email address containing a copy of their key with the
additional signature on just that UID, much as they might receive from
other attendees at a keysigning. If they wish, the user saves the
updated key to their keyring. And, again if they wish, the user
uploads their updated key to a keyserver.
Post by n***@enigmail.net
In any case some
confirmation email handling is required.
For each UID, the copy of the key containing a validation signature
over only that UID would be sent in an encrypted email to the email
address in that UID.

Receipt of the email containing the signed key confirms the ability to
receive messages sent to that email address.

And decryption of that email confirms access to the private key.

What else do you need to confirm?
Post by n***@enigmail.net
c. Changes to the user's key are uploaded to the
keyserver by the user, not by the validation
server.
Is this a real benefit?
It's the user's key. Denying them the choice by uploading your changes
directly to keyservers is pretty arrogant. Maybe you could have the
validating proxy upload the changes itself in the event the the key
you are validating does not have the keyserver no-modify flag set?


- --
Best regards

MFPA <mailto:2014-667rhzu3dc-lists-***@riseup.net>

Think for yourself.
Otherwise you have to believe what other people tell you.
Neal H. Walfield
2015-07-29 12:09:54 UTC
Permalink
At Wed, 29 Jul 2015 02:30:47 +0100,
On Monday 27 July 2015 at 1:15:57 PM, in
Post by Neal H. Walfield
Regarding the design: personally, I wouldn't have the
user follow a link that includes a swiss number, but
have the user reply to the mail, include the swiss
number and sign it.
Why not simplify the workflow:-
1. key reaches validation server.
2. for each UID containing an email address, validation server creates
a copy of the key stripped of all other UIDs.
3. validation server signs that copy of the key.
4. validation server pastes the signed key into an email, encrypts the
email to that key, and sends it to the email address in the UID.
5. user receives each email, decrypts it, and updates their local copy of
their key.
6. user uploads key now bearing the validation server's signatures to
a keyserver.
There is still the same level of assurance that the email address and
private key are controlled by the same entity. Advantages are:-
a. Nobody is asked to click links or reply to emails.
b. The validation server does not need to manage a "stack" of keys
awaiting feedback from the validation emails.
c. Changes to the user's key are uploaded to the keyserver by the
user, not by the validation server.
Personally, I think c is the killer in this plan: people aren't going
to bother to upload it (assuming they even get that far)!

Neal
MFPA
2015-07-29 13:05:49 UTC
Permalink
Hi


On Wednesday 29 July 2015 at 1:09:54 PM, in
people aren't going to bother to upload it (assuming
they even get that far)!
They have gone to the effort of sending it to the validation server
to obtain the validation signature. It is up to them whether they
publish it to a server, publicise it in some other way, send
it to their contacts directly, or just do nothing.


- --
Best regards

MFPA <mailto:2014-667rhzu3dc-lists-***@riseup.net>

Volvo, Video, Velcro. (I came, I saw, I stuck around.)
Neal H. Walfield
2015-07-29 13:16:55 UTC
Permalink
At Wed, 29 Jul 2015 14:05:49 +0100,
Post by MFPA
On Wednesday 29 July 2015 at 1:09:54 PM, in
people aren't going to bother to upload it (assuming
they even get that far)!
They have gone to the effort of sending it to the validation server
to obtain the validation signature. It is up to them whether they
publish it to a server, publicise it in some other way, send
it to their contacts directly, or just do nothing.
I suspect that >95% of users won't bother. This would defeat the
entire scheme, which requires widespread buy in to be successful.

Neal
Neal H. Walfield
2015-07-29 13:22:52 UTC
Permalink
At Wed, 29 Jul 2015 15:14:07 +0200,
If you replace "validation server" with "keysigning party participant" then
you get one of the ways participants of keysigning parties get their
signatures to the key owners. So, it's already done and people do upload their
signed keys. I don't see why people should behave differently for validation
servers.
Key signing parties are a surprisingly good example that demonstrate
my point. Key signing parties are a bizarre geek ritual. Most people
don't do it. And, I think, most people won't use the validation
servers.

Neal
MFPA
2015-07-27 13:16:49 UTC
Permalink
Hi


On Monday 27 July 2015 at 6:55:03 AM, in
Thus, I am happy for any feedback (details and general
remarks) both here and directly as email to me.
Comments in no particular order, just as they occurred to me when
looking through your paper:-



If a key is validated by the proxy, then subsequently uploaded again
with a new UID, does the new UID get a validation expiry date that
matches the rest of the key? Or does it get a standard 12-month
validation period, but still get re-validated the next time one of the
other UIDs needs it, so that all UIDs' validation expiry dates are
brought back into sync? And what if the upload with an extra UID hits
a different validation server?

If a third party has uploaded my key, or if the validation server is
automatically validating existing keys in response to certain events,
the validation emails are unsolicited by me. Most people will not
click a link in such an email.

If a third party who can intercept my emails has generated a key
containing my email address in a UID, all bets are off.

If an email provider provides public keys for their customers,
presumably those keys are unsuitable for mail encryption because the
provider may have access to the private key.

The configuration changes for email clients that you mention, things
like which keyserver to use and which keys to trust, need to be set in
GnuPG.conf (or maybe some form of GnuPG wrapper or plugin) so that
they are used by an email client that simply calls GnuPG and therefore
honours GnuPG's own settings. Same for trust models; maybe you should
consider suggesting a modified trust model for GnuPG that includes
options for handling validation signatures.

Blacklists should not be used *anywhere* as they are a form of
censorship and can be used for DOS attacks.

In your proposal for listing validation signatures in GnuPG:
"‘!’ after sig signals successful validation" - why is this needed?
Surely the mere presence of a validation signature signals successful
validation.

Why would the notation value be base64 encoded? What is the rationale
for preventing users from reading the notation values in a key
listing?

Notation version numbers. Rather than using different notation names
such as validation-***@enigmail.net, I would think it better to keep
the notation name standard and put the version number at the start of
the value string.



- --
Best regards

MFPA <mailto:2014-667rhzu3dc-lists-***@riseup.net>

Of course it's a good idea - it's mine!
n***@enigmail.net
2015-07-27 17:55:24 UTC
Permalink
Hi MFPA,
Thanks a lot for your feedback.
Post by MFPA
Hi
On Monday 27 July 2015 at 6:55:03 AM, in
Thus, I am happy for any feedback (details and general
remarks) both here and directly as email to me.
Comments in no particular order, just as they occurred to me when
looking through your paper:-
If a key is validated by the proxy, then subsequently uploaded again
with a new UID, does the new UID get a validation expiry date that
matches the rest of the key? Or does it get a standard 12-month
validation period, but still get re-validated the next time one of the
other UIDs needs it, so that all UIDs' validation expiry dates are
brought back into sync? And what if the upload with an extra UID hits
a different validation server?
Hmm, I didn't think about that in detail.
But I would assume that because each validation validates a specific
email address, a validation once each year is enough.
I see no problem with both attempts:
- - If the goal is to keep validations in sync,
key owners might have to confirm emails added over the year
earlier, which shouldn't be too bad.
- - If the goal is to reduce validation requests, I see no
problem to have different expiration dates.
I think, because each email should be validated from time to time anyway
(and this is an isolated process), each validation should give
the 12 month period for the specific email when it is validated.
Or do you see any problems?
Post by MFPA
If a third party has uploaded my key, or if the validation server is
automatically validating existing keys in response to certain events,
the validation emails are unsolicited by me. Most people will not
click a link in such an email.
OK, I agree (unless this feature is widely accepted ;-) ).
So may be, for the beginning, validations can only be triggered
when keys are uploaded (not when they are downloaded).
Post by MFPA
If a third party who can intercept my emails has generated a key
containing my email address in a UID, all bets are off.
This whole approach is NOT to make a perfect prove that the email
is correct.
It only says that the email did one day work for a validation
of any kind, which is more than what we have now.
That is, such a validation does not give full trust, it
would only give slightly more trust over emails that
do not have the validation.
But that might be enough to solve the faked key issue.
This is BTW no different than for any other validation email
in common systems. They also don't give more guarantee.
Thus this solution does NOT solve the problem of
interception of emails.
But it helps to detect them (if this happens the ct guys
know that the problem is a lot worse than they thought)
and helps in case this is the result of internet trolls.
Post by MFPA
If an email provider provides public keys for their customers,
presumably those keys are unsuitable for mail encryption because the
provider may have access to the private key.
It depends on whether and how far you trust the provider.
Reality looks different (see startmail, posteo, riseup, and many company
email servers).
I don't claim to solve any problem in that area.
User/clients might have to decide whether to trust
a validation notation given by posteo, riseup, google, ...
Post by MFPA
The configuration changes for email clients that you mention, things
like which keyserver to use and which keys to trust, need to be set in
GnuPG.conf (or maybe some form of GnuPG wrapper or plugin) so that
they are used by an email client that simply calls GnuPG and therefore
honours GnuPG's own settings. Same for trust models; maybe you should
consider suggesting a modified trust model for GnuPG that includes
options for handling validation signatures.
THAT's a bigger step, but if Gnu wants to support it
(which would mean that they think that this approach is fine),
I am happy if this happens.
For the moment I try to minimize additional requirements
to be able to support this approach pretty fast
(for people who want it).
And I really try to got at least some solution for this problem,
which I consider to be one show stopper to establish email encryption.
Post by MFPA
Blacklists should not be used *anywhere* as they are a form of
censorship and can be used for DOS attacks.
OK, don't we even have some blacklists in key servers? ;-)
But I agree, that's something we have to discuss or find out in detail.
Post by MFPA
"‘!’ after sig signals successful validation" - why is this needed?
Surely the mere presence of a validation signature signals successful
validation.
Hmm, Wener recommended to use
--check-sigs
rather than
--list.sigs
which then results in printing the '!'.
Isn't it necessary in your opinion?
Post by MFPA
Why would the notation value be base64 encoded? What is the rationale
for preventing users from reading the notation values in a key
listing?
Hmm, it was a recommendation by Kristina Fiskerstrand:
"the value should be base64 encoded to avoid some issues"
@Kristian: Can you elaborate on that?
Post by MFPA
Notation version numbers. Rather than using different notation names
the notation name standard and put the version number at the start of
the value string.
Thanks
Nico


- --
Nicolai M. Josuttis
www.josuttis.de
mailto:***@enigmail.net
PGP fingerprint: CFEA 3B9F 9D8E B52D BD3F 7AF6 1C16 A70A F92D 28F5
Kristian Fiskerstrand
2015-07-27 18:00:08 UTC
Permalink
Hi MFPA, Thanks a lot for your feedback.
..
Post by MFPA
Why would the notation value be base64 encoded? What is the
rationale for preventing users from reading the notation values
in a key listing?
Hmm, it was a recommendation by Kristina Fiskerstrand: "the value
elaborate on that?
It makes the information more compact and will make hkp vindex lists
look cleaner. Presuming this information contains data objects in json
format it will be interpreted by a parser, and raw data from
keyservers anyways shouldn't be trusted directly before validating the
signature (including its subpackets/notations) since no crypto has
been performed at that point.

- --
- ----------------------------
Kristian Fiskerstrand
Blog: http://blog.sumptuouscapital.com
Twitter: @krifisk
- ----------------------------
Public OpenPGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
- ----------------------------
"Knowing is not enough; we must apply. Willing is not enough; we must do
."
(Johann Wolfgang von Goethe)
MFPA
2015-07-28 17:57:29 UTC
Permalink
Hi


On Monday 27 July 2015 at 7:00:08 PM, in
Post by Kristian Fiskerstrand
It makes the information more compact and will make hkp
vindex lists look cleaner.
I thought Base64 encodes 3 bytes into 4, so has a 33% overhead.
Post by Kristian Fiskerstrand
Presuming this information
contains data objects in json format it will be
interpreted by a parser,
Couldn't human-readable data with a suitable field delimiter (such as
generated by GnuPG's "--with-colons" option) be interpreted by a
parser?
Post by Kristian Fiskerstrand
and raw data from keyservers
anyways shouldn't be trusted directly before validating
the signature (including its subpackets/notations)
since no crypto has been performed at that point.
Is that a good enough reason to deny the user the opportunity to read
the signature notation value data in a "--list-sigs" output?

What about in a "--check-sigs" output? The "!" would indicate the
validation signature signature could be trusted, but the Base64
encoding would obscure the detail about how the email address was
verified.


- --
Best regards

MFPA <mailto:2014-667rhzu3dc-lists-***@riseup.net>

Wait. You think I'm right?
Werner Koch
2015-07-29 08:08:39 UTC
Permalink
Post by MFPA
Couldn't human-readable data with a suitable field delimiter (such as
generated by GnuPG's "--with-colons" option) be interpreted by a
parser?
OpenPGP allows to indicate whether a notation data item is human
readable. Notation data generated by gpg are always flagged as human
readable and there has up to now be no request to add a feature to add
binary notation data - but it would be possible to do that.


Salam-Shalom,

Werner
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
MFPA
2015-07-28 17:26:07 UTC
Permalink
Hi


On Monday 27 July 2015 at 6:55:24 PM, in
Post by n***@enigmail.net
If the
goal is to keep validations in sync, key owners might
have to confirm emails added over the year earlier,
which shouldn't be too bad. - - If the goal is to
reduce validation requests, I see no problem to have
different expiration dates. I think, because each email
should be validated from time to time anyway (and this
is an isolated process), each validation should give
the 12 month period for the specific email when it is
validated. Or do you see any problems?
I just think if I was to receive revalidation requests all at the same
time I would be less likely to overlook those for little-used email
addresses I do not often check. It also keeps it neat.
Post by n***@enigmail.net
This whole approach is NOT to make a perfect prove that
the email is correct.
Nothing is perfect. Even meeting up and verifying government-issued ID
documents can be defeated by good quality fake documents.
Post by n***@enigmail.net
It only says that the email did
one day work for a validation of any kind, which is
more than what we have now.
We have the Web of Trust to demonstrate that. But those are generally
one-off signatures on a key, and may be quite a few years old. Some
email providers recycle addresses, so an address Bob used a few months
or years ago could now be under Alice's, or even Mallory's, control.

As far as I see it, your scheme adds two things: periodic
revalidation, and an easy way to get a signature on your key without
having to meet anybody.
Post by n***@enigmail.net
That is, such a validation
does not give full trust, it would only give slightly
more trust over emails that do not have the validation.
Indeed. I think an annual revalidation period strikes a reasonable
balance, although maybe there are email services that recycle
addresses more quickly than that.
Post by n***@enigmail.net
But that might be enough to solve the faked key issue.
Are there really many "faked" keys, rather than keys that are no
longer used, forgotten passphrase, lost private key, etc.?
Post by n***@enigmail.net
this solution does NOT solve the
problem of interception of emails. But it helps to
detect them
How does this help to detect interception of emails?
Post by n***@enigmail.net
It depends on whether and how far you trust the
provider. Reality looks different (see startmail,
posteo, riseup, and many company email servers). I
don't claim to solve any problem in that area.
User/clients might have to decide whether to trust a
validation notation given by posteo, riseup, google,
...
Company email servers, I would expect companies as a matter of course
to have a means to decrypt their employees' emails.

I'm shocked to read [0] that Riseup once had a webmail option that
stored the user's public and private keys. Riseup now tells [1] users
who want to use encrypted email to utilize an email client to send and
receive email, while keeping their private key stored safely on their
local machine.

[0] <https://help.riseup.net/en/email/webmail/where-is-imp>
[1] <https://help.riseup.net/en/security/message-security/openpgp#can-i-send-and-receive-encrypted-email-using-riseups-webmail>

Startmail sounds like a similar concept to Hushmail, which was
compromised by a court order obtained through a mutual assistance
treaty. It is not clear to me why Startmail would not be expected to
suffer the same fate.

Posteo looks interesting. But their overview says end-to-end
encryption is done by the user in addition to Posteo's own security
measures, so the user would have to generate and store their own keys.

And Google make a living out of exploiting data mined from users'
emails and search activities. Why would anybody trust them?
Post by n***@enigmail.net
Post by MFPA
In your proposal for listing validation signatures in
GnuPG: "‘!’ after sig signals successful validation" -
why is this needed? Surely the mere presence of a
validation signature signals successful validation.
Hmm, Wener recommended to use --check-sigs rather than
--list.sigs which then results in printing the '!'.
Isn't it necessary in your opinion?
Fair enough. The mere presence of a validation signature from the
validation server indicates successful validation of the email address
in the UID. The "!" after "sig" in the output of --check-sigs
indicates the signature has been checked and found to be "good" or
"valid".



- --
Best regards

MFPA <mailto:2014-667rhzu3dc-lists-***@riseup.net>

A woman's mind is cleaner than a man's: She changes it more often.
n***@enigmail.net
2015-07-28 19:17:28 UTC
Permalink
Hi,
thanks again for the great feedback.
Post by MFPA
Hi
On Monday 27 July 2015 at 6:55:24 PM, in
Post by n***@enigmail.net
If the
goal is to keep validations in sync, key owners might
have to confirm emails added over the year earlier,
which shouldn't be too bad. - - If the goal is to
reduce validation requests, I see no problem to have
different expiration dates. I think, because each email
should be validated from time to time anyway (and this
is an isolated process), each validation should give
the 12 month period for the specific email when it is
validated. Or do you see any problems?
I just think if I was to receive revalidation requests all at the same
time I would be less likely to overlook those for little-used email
addresses I do not often check. It also keeps it neat.
OK, I will add this as an argument.
Does anybody disagree?
Post by MFPA
Post by n***@enigmail.net
It only says that the email did
one day work for a validation of any kind, which is
more than what we have now.
We have the Web of Trust to demonstrate that. But those are generally
one-off signatures on a key, and may be quite a few years old. Some
email providers recycle addresses, so an address Bob used a few months
or years ago could now be under Alice's, or even Mallory's, control.
As far as I see it, your scheme adds two things: periodic
revalidation, and an easy way to get a signature on your key without
having to meet anybody.
Yep, sounds good to me.
May be an additional value is the goal to establish some
"common" validation signatures, which would allow to
use/trust these signatures by default.
Thus, we also introduce an easy way to benefit from a
validation (signature).
Post by MFPA
Post by n***@enigmail.net
That is, such a validation
does not give full trust, it would only give slightly
more trust over emails that do not have the validation.
Indeed. I think an annual revalidation period strikes a reasonable
balance, although maybe there are email services that recycle
addresses more quickly than that.
Finding the right balance is probably something we have to find out over
time. I would start very very conservatively, just not to annoy people.
Post by MFPA
Post by n***@enigmail.net
But that might be enough to solve the faked key issue.
Are there really many "faked" keys, rather than keys that are no
longer used, forgotten passphrase, lost private key, etc.?
AFAIK, there are not THAT many faked keys, but the problem exists
especially for key parties of our internet world
(a famous German magazine, at least one GPG tool, ...).
The problem is that the German magazine takes this as a show stopper
(both personally and publicly).
I really want to have them back on our road for more encryption
with OpenPGP.
And the "publicity" we get from not validating email addresses
is really a big problem (especially as fixing that problems sounds so
easy and obvious).
Thus, without fixing this, IMO the whole OpenPGP movement
has a reputation problem.
Post by MFPA
Post by n***@enigmail.net
this solution does NOT solve the
problem of interception of emails. But it helps to
detect them
How does this help to detect interception of emails?
Today, people with faked keys simply get unreadable emails,
but don't know whether there were trolls or spies at work.
After validating their own key, only one of two things can happen:
a) The faked key problem is solved, because people
now know, which of the available keys to prefer
(provided people trust the validation signature)
b) The faked key problem still exists, because a
validation signature to the faked key was
also added.
In this case we know that something more severe happened:
- either the confirmation email was intercepted
- or the validation server was corrupted
That is, either the problem is solved or
we know that the problem is more severe than just a work
of trolls only uploading a faked key for fun.
Post by MFPA
Post by n***@enigmail.net
It depends on whether and how far you trust the
provider. Reality looks different (see startmail,
posteo, riseup, and many company email servers). I
don't claim to solve any problem in that area.
User/clients might have to decide whether to trust a
validation notation given by posteo, riseup, google,
...
Company email servers, I would expect companies as a matter of course
to have a means to decrypt their employees' emails.
I'm shocked to read [0] that Riseup once had a webmail option that
stored the user's public and private keys. Riseup now tells [1] users
who want to use encrypted email to utilize an email client to send and
receive email, while keeping their private key stored safely on their
local machine.
[0] <https://help.riseup.net/en/email/webmail/where-is-imp>
[1] <https://help.riseup.net/en/security/message-security/openpgp#can-i-send-and-receive-encrypted-email-using-riseups-webmail>
Startmail sounds like a similar concept to Hushmail, which was
compromised by a court order obtained through a mutual assistance
treaty. It is not clear to me why Startmail would not be expected to
suffer the same fate.
Posteo looks interesting. But their overview says end-to-end
encryption is done by the user in addition to Posteo's own security
measures, so the user would have to generate and store their own keys.
And Google make a living out of exploiting data mined from users'
emails and search activities. Why would anybody trust them?
Interesting, but this is a different issue.
The question you raise is: (How far) Can we trust the email
provider/server regarding the handling of private keys.

Here in this proposal, IMO, we have a slightly different problem,
which makes corruption less likely.
The reason is:
If an email provider/server "G" gives the private key to the NSA
we don't know about it, because that's a private deal between G and NSA.
Thus, this breakage of privacy is hard to detect and therefore
not a big risk for G to do.

But if G claims that an email address was validated
although it was not, they express this as a public signature
visible to the whole world.
If they do that, people can/will find out and blame G.
But that's something G clearly wants to avoid
(they need trust by their customers).
Thus, they have much more interest not to signal validation
of a faked key because any violation here is easy to detect.

Best
Nico
--
Nicolai M. Josuttis
www.josuttis.de
mailto:***@enigmail.net
PGP fingerprint: CFEA 3B9F 9D8E B52D BD3F 7AF6 1C16 A70A F92D 28F5
MFPA
2015-07-29 00:48:54 UTC
Permalink
Hi


On Tuesday 28 July 2015 at 8:17:28 PM, in
Post by n***@enigmail.net
AFAIK, there are not THAT many faked keys, but the
problem exists especially for key parties of our
internet world (a famous German magazine, at least one
GPG tool, ...). The problem is that the German magazine
takes this as a show stopper (both personally and
publicly). I really want to have them back on our road
for more encryption with OpenPGP. And the "publicity"
we get from not validating email addresses is really a
big problem (especially as fixing that problems sounds
so easy and obvious). Thus, without fixing this, IMO
the whole OpenPGP movement has a reputation problem.
I understand what you are saying. I cannot help but think they are
making a mountain out of a molehill by characterising this minor
irritation as a "show stopper". Putting something in place to
counteract the issue is one approach. Would it not be an equally-valid
approach to educate them as to why it is a non-issue, which they could
then disseminate through their magazine?
Post by n***@enigmail.net
Today, people with faked keys simply get unreadable
emails, but don't know whether there were trolls or
spies at work.
They can, however, search on keyservers for the key to which the
message was encrypted. Or ask the sender where they got it and to
forward a copy for inspection.
Post by n***@enigmail.net
After validating their own key, only one
[snipped]
Post by n***@enigmail.net
either the
problem is solved or we know that the problem is more
severe than just a work of trolls only uploading a
faked key for fun.
Fair enough.
Post by n***@enigmail.net
But if G claims that an email address was validated
although it was not, they express this as a public
signature visible to the whole world. If they do that,
people can/will find out and blame G. But that's
something G clearly wants to avoid (they need trust by
their customers). Thus, they have much more interest
not to signal validation of a faked key because any
violation here is easy to detect.
The provider could claim the user's password must have been
compromised and that was how the validation occurred without the
user's knowledge. They could even make the user jump through password
reset and security question hoops the next time they log in. Anyway,
after ten minutes public attention will switch to something else.



- --
Best regards

MFPA <mailto:2014-667rhzu3dc-lists-***@riseup.net>

Adults are obsolete children.
Ingo Klöcker
2015-07-29 10:38:46 UTC
Permalink
Post by MFPA
On Tuesday 28 July 2015 at 8:17:28 PM, in
Post by n***@enigmail.net
AFAIK, there are not THAT many faked keys, but the
problem exists especially for key parties of our
internet world (a famous German magazine, at least one
GPG tool, ...). The problem is that the German magazine
takes this as a show stopper (both personally and
publicly). I really want to have them back on our road
for more encryption with OpenPGP. And the "publicity"
we get from not validating email addresses is really a
big problem (especially as fixing that problems sounds
so easy and obvious). Thus, without fixing this, IMO
the whole OpenPGP movement has a reputation problem.
I understand what you are saying. I cannot help but think they are
making a mountain out of a molehill by characterising this minor
irritation as a "show stopper".
Yes, he (not they!), the author of the article is doing exactly this.
Post by MFPA
Putting something in place to
counteract the issue is one approach. Would it not be an equally-valid
approach to educate them as to why it is a non-issue, which they could
then disseminate through their magazine?
I think that the author of the article knows that it's mostly a non-issue. He
still decided to write the article "Forged PGP Keys in the Wild" [1] and even
an accompanying editorial titled "Let PGP Die!" [2]. I guess he simply got
pissed because he received so many messages that were undecryptable with his
real key.

Luckily, there are also more sensible authors working for this magazine who
write good articles about OpenPGP.

I personally chose to ignore the stupid editorial. IMHO it does not deserve
more attention than any other rant written by a random troll. OTOH, the
article actually isn't that bad. It points out the issue with the missing
validation of email addresses in UIDs making a bit of a fuss about it, but
IIRC it also explains how to avoid falling into the trap of using a fake key.


Regards,
Ingo


[1] http://www.heise.de/artikel-archiv/ct/2015/06/160_Die-Schluessel-Falle
(German; needs to be bought)
[2] https://www.heise.de/artikel-archiv/ct/2015/06/3_Editorial (German; free)
n***@enigmail.net
2015-07-29 11:07:20 UTC
Permalink
Hmmm,

first i talked to him/them a couple of times personally
(there are multiple editors at that magazine)
about the issue in detail and tried to convince them following
the WoT without success.

Note that they just behave as ordinary users,
having not much time to deal with the problems of OpenPGP.
They get hundreds of emails per day and each email they
can't read is a significant problem because
the 2 seconds they have for reading emails turn out to
become minutes.
There should simply be no overhead in using OpenPGP
in the ordinary case for the ordinary user.

And I agree with that.
Usability is key for a broad acceptance.

I don't want to have the same problem.
And other tools also don't want to have it anymore
(e.g. the GPGTools.org guys have the same problem).

I see no reason NOT to solve this problem,
but I see many reasons to solve it.

Just saying "deal with it" simply means that
we place unneccesary burden on OpenPGP users.
IMO, that's a really bad approach.
Post by Ingo Klöcker
Post by MFPA
On Tuesday 28 July 2015 at 8:17:28 PM, in
Post by n***@enigmail.net
AFAIK, there are not THAT many faked keys, but the
problem exists especially for key parties of our
internet world (a famous German magazine, at least one
GPG tool, ...). The problem is that the German magazine
takes this as a show stopper (both personally and
publicly). I really want to have them back on our road
for more encryption with OpenPGP. And the "publicity"
we get from not validating email addresses is really a
big problem (especially as fixing that problems sounds
so easy and obvious). Thus, without fixing this, IMO
the whole OpenPGP movement has a reputation problem.
I understand what you are saying. I cannot help but think they are
making a mountain out of a molehill by characterising this minor
irritation as a "show stopper".
Yes, he (not they!), the author of the article is doing exactly this.
Post by MFPA
Putting something in place to
counteract the issue is one approach. Would it not be an equally-valid
approach to educate them as to why it is a non-issue, which they could
then disseminate through their magazine?
I think that the author of the article knows that it's mostly a non-issue. He
still decided to write the article "Forged PGP Keys in the Wild" [1] and even
an accompanying editorial titled "Let PGP Die!" [2]. I guess he simply got
pissed because he received so many messages that were undecryptable with his
real key.
Luckily, there are also more sensible authors working for this magazine who
write good articles about OpenPGP.
I personally chose to ignore the stupid editorial. IMHO it does not deserve
more attention than any other rant written by a random troll. OTOH, the
article actually isn't that bad. It points out the issue with the missing
validation of email addresses in UIDs making a bit of a fuss about it, but
IIRC it also explains how to avoid falling into the trap of using a fake key.
Regards,
Ingo
[1] http://www.heise.de/artikel-archiv/ct/2015/06/160_Die-Schluessel-Falle
(German; needs to be bought)
[2] https://www.heise.de/artikel-archiv/ct/2015/06/3_Editorial (German; free)
_______________________________________________
Gnupg-users mailing list
http://lists.gnupg.org/mailman/listinfo/gnupg-users
--
Nicolai M. Josuttis
www.josuttis.de
mailto:***@enigmail.net
PGP fingerprint: CFEA 3B9F 9D8E B52D BD3F 7AF6 1C16 A70A F92D 28F5
Kristian Fiskerstrand
2015-07-29 11:14:56 UTC
Permalink
Hmmm,
There should simply be no overhead in using OpenPGP in the ordinary
case for the ordinary user.
Any secure system needs proper operational security surrounding it,
that require user awareness. So if security/privacy is a priority,
there needs to be an overhead (it might even serve a purpose as it
reminds the user about the the proper procedures to follow).

Quick example; They can use OpenPGP all they want, doesn't help one
bit if the private keys are stored on the computer, running a 10 year
old version of Operating System XY with so many trojan horses working
on copying the private key data that they are fighting over the
resources on the computer.

To paraphrase Schneier, security isn't a product it is a process.

- --
- ----------------------------
Kristian Fiskerstrand
Blog: http://blog.sumptuouscapital.com
Twitter: @krifisk
- ----------------------------
Public OpenPGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
- ----------------------------
"Action is the foundational key to all success"
(Pablo Picasso)
MFPA
2015-07-29 13:42:38 UTC
Permalink
Hi


On Wednesday 29 July 2015 at 12:07:20 PM, in
Post by n***@enigmail.net
They get hundreds of emails per day and each email they
can't read is a significant problem because the 2
seconds they have for reading emails turn out to become
minutes.
I would expect each time they got "no secret key" they would spend a
couple of seconds to fire back an email of boilerplate text saying
they couldn't decrypt and containing the correct key.
Post by n***@enigmail.net
There should simply be no overhead in using
OpenPGP in the ordinary case for the ordinary user.
Any security measure has overhead. It takes longer to open a door if
you have to unlock it first, and then there's the overhead of having
Post by n***@enigmail.net
I see no reason NOT to solve this problem, but I see
many reasons to solve it.
I was just questioning whether it is really a problem. If it is, and
the effort to solve it is less than the effort to just deal with it,
then it should be solved.



- --
Best regards

MFPA <mailto:2014-667rhzu3dc-lists-***@riseup.net>

Experience is the name everyone gives to their mistakes
Ingo Klöcker
2015-07-29 13:33:04 UTC
Permalink
[Please do not CC me. I am subscribed.]
Post by n***@enigmail.net
I see no reason NOT to solve this problem,
but I see many reasons to solve it.
Just saying "deal with it" simply means that
we place unneccesary burden on OpenPGP users.
IMO, that's a really bad approach.
Sure. All I'm saying is that introducing a second centralized CA PKI does not
strike me as a good solution.

Actually, I think this is more of an educational or a social problem than it
is a technical problem. The problem you have to solve is that people blindly
trust the UIDs. You cannot counter people's ignorance about how OpenPGP and
the WoT works with technical means.


Regards,
Ingo
Werner Koch
2015-07-29 13:43:34 UTC
Permalink
Post by Ingo Klöcker
I personally chose to ignore the stupid editorial. IMHO it does not deserve
more attention than any other rant written by a random troll. OTOH, the
The publication came to a surprise to me given that we had a mail Q+A in
the week before to explain what keyservers are and what they are not. I
later heard rumors that he was working on that article for a year.

I spent some time to rebute it (in German):

http://rem.eifzilla.de/archives/2015/02/24/re-die-schlssel-falle



Salam-Shalom,

Werner
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
Werner Koch
2015-07-27 15:23:28 UTC
Permalink
Post by n***@enigmail.net
Thus, I am happy for any feedback
(details and general remarks)
Plain text would be appreciated. I accidentally accepted that 280k PDF
but sending such files to 2600 subscribes should be the exception.


Salam-Shalom,

Werner
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
Ingo Klöcker
2015-07-27 14:31:15 UTC
Permalink
Post by n***@enigmail.net
Hi all,
in March we discussed here
"German ct magazine postulates death of pgp encryption"
and Patrick Brunschwig proposed a way to validate email addresses
http://lists.gnupg.org/pipermail/gnupg-users/2015-March/052882.html
In the past months I tried to come up with a concrete proposal.
I discussed it already with some people and
this is what I/we propose so far.
The proposal is not perfect and not completely worked out
but IMO it is ready for a broader discussion and review.
This whole concept of a whitelist of "trusted validation servers" included in
the email clients sounds a lot like the CA certificate bundles included in
browsers and/or OSes. Who is going to maintain this whitelist? The email
client developers? The OS manufactures? Who is going to certify "trusted
validation servers", i.e. who is going to tell benign validation servers apart
from malignant validation servers?

Your proposal seems to repeat a lot of the (failed) concepts of the
centralized CA approach. For this reason I think the approach is doomed to
fail the same way the centralized CA approach has failed (even if everybody
seems to ignore its failure).

I'd rather put my bets on a DANE-based approach like
https://datatracker.ietf.org/doc/draft-ietf-dane-openpgpkey/


Regards,
Ingo
n***@enigmail.net
2015-07-27 18:19:07 UTC
Permalink
Hi Ingo,
thanks a lot for the feedback.
Post by Ingo Klöcker
Post by n***@enigmail.net
Hi all,
in March we discussed here
"German ct magazine postulates death of pgp encryption"
and Patrick Brunschwig proposed a way to validate email addresses
http://lists.gnupg.org/pipermail/gnupg-users/2015-March/052882.html
In the past months I tried to come up with a concrete proposal.
I discussed it already with some people and
this is what I/we propose so far.
The proposal is not perfect and not completely worked out
but IMO it is ready for a broader discussion and review.
This whole concept of a whitelist of "trusted validation servers" included in
the email clients sounds a lot like the CA certificate bundles included in
browsers and/or OSes. Who is going to maintain this whitelist? The email
client developers? The OS manufactures? Who is going to certify "trusted
validation servers", i.e. who is going to tell benign validation servers apart
from malignant validation servers?
I agree that this is a key issue/problem of the approach.
And indeed, I suggest to initially or by default give some trust
to some signatures.

Note that I propose different things, though:
1) A standard format for such validations.
This simply would help to be able to deal with any
validation approach.
2) A way to establish such validations
by using a validating key server proxy.
3) A whitelist.

I am happy to only have 1) and 2) and to teach people
to trust e.g. specific servers (and to mistrust others).

I only want to have a way to manage email validations
(a common technique where everybody wonders why this
is not supported).
This is the best I could come up with after discussing this
with several people.
And so far it would be a lot more than we have now.
It it might fix a problem which otherwise is a show stopper.

If this is not appropriate, what do YOU propose instead
for email validation?
So many processes in this world are today based on email validation.
Do you think that in general email validation is not the right approach
or do you propose something different?
Post by Ingo Klöcker
Your proposal seems to repeat a lot of the (failed) concepts of the
centralized CA approach. For this reason I think the approach is doomed to
fail the same way the centralized CA approach has failed (even if everybody
seems to ignore its failure).
I TRIED to avoid some of them:
- avoiding to many signatures
- providing no central solution
It's the best I could come up with.
I don't see any other form but may be you know better.
Tell me!
Post by Ingo Klöcker
I'd rather put my bets on a DANE-based approach like
https://datatracker.ietf.org/doc/draft-ietf-dane-openpgpkey/
I am happy with ANY solution here.
I don't know all the details about DANE, but as far as I know
it is promising but well not established yet.
If we don#t need my proposal, great!
But if establishing DANE will take more time or if there are
some flaws with it), I would like to have this solution
because IMO it would help.
But I might be wrong.

Thanks and all the best
Nico

BTW, the name sounds German and I am happy to discuss this whole issue
with you in person.
Post by Ingo Klöcker
Regards,
Ingo
--
Nicolai M. Josuttis
www.josuttis.de
mailto:***@enigmail.net
PGP fingerprint: CFEA 3B9F 9D8E B52D BD3F 7AF6 1C16 A70A F92D 28F5
Ingo Klöcker
2015-07-28 14:56:08 UTC
Permalink
Post by n***@enigmail.net
Post by Ingo Klöcker
This whole concept of a whitelist of "trusted validation servers" included
in the email clients sounds a lot like the CA certificate bundles
included in browsers and/or OSes. Who is going to maintain this
whitelist? The email client developers? The OS manufactures? Who is going
to certify "trusted validation servers", i.e. who is going to tell benign
validation servers apart from malignant validation servers?
I agree that this is a key issue/problem of the approach.
And indeed, I suggest to initially or by default give some trust
to some signatures.
1) A standard format for such validations.
This simply would help to be able to deal with any
validation approach.
2) A way to establish such validations
by using a validating key server proxy.
3) A whitelist.
I am happy to only have 1) and 2) and to teach people
to trust e.g. specific servers (and to mistrust others).
I only want to have a way to manage email validations
(a common technique where everybody wonders why this
is not supported).
This is the best I could come up with after discussing this
with several people.
And so far it would be a lot more than we have now.
It it might fix a problem which otherwise is a show stopper.
If this is not appropriate, what do YOU propose instead
for email validation?
So many processes in this world are today based on email validation.
Do you think that in general email validation is not the right approach
or do you propose something different?
I'm not against your proposal per se. In fact, I'm probably one of the few
people who actually think that the email validation done by PGP.com has some
value. Consequently, I am also seeing the value in your proposal.

I'm just having reservations with regard to the whitelists. See my reply to
Ludwig's reply.


Regards,
Ingo
Ludwig Hügelschäfer
2015-07-27 19:05:26 UTC
Permalink
Hi Ingo,
Post by Ingo Klöcker
This whole concept of a whitelist of "trusted validation servers"
included in the email clients sounds a lot like the CA certificate
bundles included in browsers and/or OSes. Who is going to maintain
this whitelist?
Whilelists: The OpenPGP-aware clients. There aren't so many of them,
so that's manageable.
Post by Ingo Klöcker
The email client developers? The OS manufactures? Who is going to
certify "trusted validation servers", i.e. who is going to tell
benign validation servers apart from malignant validation servers?
There is a community providing keyservers (such as
pool.sks-keyservers.net). My impression is that this network is well
maintained and has worked reliably the last years.

Why should there not be a similar community approach for setting up a
(smaller) network of validating key server proxies.
Post by Ingo Klöcker
I'd rather put my bets on a DANE-based approach like
https://datatracker.ietf.org/doc/draft-ietf-dane-openpgpkey/
DANE requires write access to DNS. I don't see that the average
OpenPGP user has facilities and knowledge to achieve setting up the
required DNS records. If you can't convince the big mail providers
(e.g. Google, GMX here in Germany, ...) to provide a reasonable
interface for their users, I'm afraid that this will not be a success,

Ludwig
Ingo Klöcker
2015-07-28 14:46:54 UTC
Permalink
Post by n***@enigmail.net
Hi Ingo,
Post by Ingo Klöcker
This whole concept of a whitelist of "trusted validation servers"
included in the email clients sounds a lot like the CA certificate
bundles included in browsers and/or OSes. Who is going to maintain
this whitelist?
Whilelists: The OpenPGP-aware clients. There aren't so many of them,
so that's manageable.
Speaking for KMail how can I be sure that somebody who claims that his
validation server can be trusted can actually be trusted and should therefore
be added to the whitelist? KDE avoids this problem for the CA certificate
bundle by relying on the certificate bundles provided by the Linux
distributors or by Mozilla.
Post by n***@enigmail.net
Post by Ingo Klöcker
The email client developers? The OS manufactures? Who is going to
certify "trusted validation servers", i.e. who is going to tell
benign validation servers apart from malignant validation servers?
There is a community providing keyservers (such as
pool.sks-keyservers.net). My impression is that this network is well
maintained and has worked reliably the last years.
Why should there not be a similar community approach for setting up a
(smaller) network of validating key server proxies.
Well, the keyservers do not make any claims with regard to the authenticity or
the integrity of the keys. Those checks are left to the clients. I do not have
to trust any of the keyservers.

The validating key server proxies claim validity of the UIDs (to a certain
degree). I can see myself marking such a proxy as trusted by adding it to my
gnupg.conf (or to KMail's configuration). But I cannot see myself adding such
a proxy to the whitelist that's shipped with KMail.

Another problem I see with whitelist management is revocation in case the
validation key of a validating proxy is compromised. Again, for the CA
certificate bundles that's handled by the distributors and not by individual
application developers.
Post by n***@enigmail.net
Post by Ingo Klöcker
I'd rather put my bets on a DANE-based approach like
https://datatracker.ietf.org/doc/draft-ietf-dane-openpgpkey/
DANE requires write access to DNS. I don't see that the average
OpenPGP user has facilities and knowledge to achieve setting up the
required DNS records. If you can't convince the big mail providers
(e.g. Google, GMX here in Germany, ...) to provide a reasonable
interface for their users, I'm afraid that this will not be a success,
I'm confident that the smaller mail providers who focus on security would be
willing to add such an interface. Frankly, I do not care that much for the big
mail providers. People who really value privacy should use mail providers that
value privacy.


Regards,
Ingo
MFPA
2015-07-28 18:46:18 UTC
Permalink
Hi


On Tuesday 28 July 2015 at 3:46:54 PM, in
Post by Ingo Klöcker
I'm confident that the smaller mail providers who focus
on security would be willing to add such an interface.
Frankly, I do not care that much for the big mail
providers.
Unless at least some of the major email providers were to provide a
means for these DNS entries to be added, any DNS-based approach has
very limited potential.
Post by Ingo Klöcker
People who really value privacy should use
mail providers that value privacy.
A person cannot usually dictate which mail provider is used by the
people with whom they exchange messages.



- --
Best regards

MFPA <mailto:2014-667rhzu3dc-lists-***@riseup.net>

It is not necessary to have enemies if you go out of your way to make friends hate you.
Werner Koch
2015-07-29 08:16:30 UTC
Permalink
Post by MFPA
Unless at least some of the major email providers were to provide a
means for these DNS entries to be added, any DNS-based approach has
very limited potential.
Right, but is the only solid way of doing it. The provider already have
the infrastructure to maintain the mail account and thus the costs of
adding a new data field a marginal.

Of course one could setup a service to do this for example by appending
foo.gnupg.net to the mail address before the lookup. However this
introduces a lot of costs (user help desk), annoyance (the user need to
register with that service), and centralization.
Post by MFPA
A person cannot usually dictate which mail provider is used by the
people with whom they exchange messages.
Iff enough people are interested in confidential mail communication
competition will force all providers to add this.


Shalom-Salam,

Werner
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
Ludwig Hügelschäfer
2015-07-28 20:06:03 UTC
Permalink
Post by Ingo Klöcker
Post by n***@enigmail.net
Hi Ingo,
(...)
Post by Ingo Klöcker
Post by n***@enigmail.net
Why should there not be a similar community approach for setting
up a (smaller) network of validating key server proxies.
Well, the keyservers do not make any claims with regard to the
authenticity or the integrity of the keys. Those checks are left to
the clients. I do not have to trust any of the keyservers.
The validating key server proxies claim validity of the UIDs (to a
certain degree). I can see myself marking such a proxy as trusted
by adding it to my gnupg.conf (or to KMail's configuration). But I
cannot see myself adding such a proxy to the whitelist that's
shipped with KMail.
Another problem I see with whitelist management is revocation in
case the validation key of a validating proxy is compromised.
Again, for the CA certificate bundles that's handled by the
distributors and not by individual application developers.
Let's concentrate on this one, I think this is the real tough task:
establishing a trust chain from the validating servers to the client.

There's one root certificate, signing the individual proxy certificates.

Each individual proxy has a certificate it is using for creating the
validating signatures.

Each client only needs to have the root certificate builtin. If it
encounters a validation proxy's certificate, it will download it.

If a proxy certificate is known compromised, the signature from the
root certificate is revoked.

If the root certificate is compromised (and revoked), the scheme will
require new client versions with a new root certificate builtin.

The client itself must refresh the root certificate and all downloaded
proxy certificates regularly.

This all requires a very small group of maintainers for the root
certificate (2 or 3 people), issueing and revoking signatures for
proxy certificates.

The client authors will need to have a trust chain to at least one
root certificate maintainer. This is also true for the proxy maintainers
.

This is my view of the problem :-)

Ludwig
MFPA
2015-07-29 00:10:08 UTC
Permalink
Hi


On Tuesday 28 July 2015 at 9:06:03 PM, in
Post by Ludwig Hügelschäfer
Let's concentrate on this one, I think this is the real
tough task: establishing a trust chain from the
validating servers to the client.
There's one root certificate, signing the individual
proxy certificates.
Sounds a lot like the discredited "trusted CA" system, used for TLS
and S/MIME?


- --
Best regards

MFPA <mailto:2014-667rhzu3dc-lists-***@riseup.net>

A woman's mind is cleaner than a man's: She changes it more often.
Patrick Brunschwig
2015-07-28 16:05:42 UTC
Permalink
Post by Ingo Klöcker
Post by n***@enigmail.net
Hi Ingo,
Post by Ingo Klöcker
This whole concept of a whitelist of "trusted validation servers"
included in the email clients sounds a lot like the CA certificate
bundles included in browsers and/or OSes. Who is going to maintain
this whitelist?
Whilelists: The OpenPGP-aware clients. There aren't so many of them,
so that's manageable.
Speaking for KMail how can I be sure that somebody who claims that his
validation server can be trusted can actually be trusted and should therefore
be added to the whitelist? KDE avoids this problem for the CA certificate
bundle by relying on the certificate bundles provided by the Linux
distributors or by Mozilla.
Let's face it: KDE doesn't /avoid/ this problem. It just shifts the
problem to someone else -- the Linux distributors or Mozilla ;)

-Patrick
Patrick Brunschwig
2015-07-27 15:51:56 UTC
Permalink
Post by Neal H. Walfield
Hi,
The idea I have in mind is roughly as follows: if you upload a key to
a keyserver, the keyserver would send an encrypted email to every UID
in the key. Each encrypted mail contains a unique link to confirm the
email address. Once all email addresses are confirmed, the key is
validated and the keyserver will allow access to it just like with any
regular keyserver.
This approach is not going to stop a nation state. A nation state can
intercept the mail, decrypt it and follow the link.
If the email can be decrypted, then any email can be decrypted, which
would turn OpenPGP useless.
Post by Neal H. Walfield
For the same reason, it is not going to stop a user's ISP. Given
Microsoft's et al.'s willingness to cooperate with the NSA, these are
not very good starting conditions.
If (and only if) the user stores his private key on his computer, and
the connection to the validating key server is HTTPS with PFS, I don't
really agree.

In any case, the target users are not the Edward Snowdens of this world,
but the 99% of people who just want to communicate easily with each
other and don't want to be bothered too much with key complicated key
lookup/verification scenarios.
Post by Neal H. Walfield
The approach also has another problem: which key servers are going to
do this? There are 100s of key servers. I'm not going to reply to
mails from each one, sorry.
The idea is that these servers are separate from the keyserver network.
That is, a relatively small set of servers that would only do validation
of email addresses. Validated keys would then be uploaded to normal key
servers.
Post by Neal H. Walfield
This also seems like a nice way to spam someone. Generate a key,
upload it to a key server and they have a bunch of mails from the key
server. Based on this, I suspect that it won't take long for the key
servers to be blacklisted?
True, but this only serves the purpose of spamming someone without any
further action. You cannot send specific text to those who get spammed,
that's thus not very interesting. But in general, that's certainly
something to consider (such as only accepting one key at a time and only
accepting N keys per hour from some IP address).
Post by Neal H. Walfield
Have you considered these issues? Do you have any thoughts about how
to avoid these problems or do you think they are not real problems?
Regarding the design: personally, I wouldn't have the user follow a
link that includes a swiss number, but have the user reply to the
mail, include the swiss number and sign it.
That's a good idea indeed.
Post by Neal H. Walfield
I'd also consider having the key servers publish the validations. If
you chain the validations (include the hash of the previous validation
in the current validation) you can detect if the key servers serve a
fake key to a specific user.
Sounds like a good idea.

-Patrick
Neal H. Walfield
2015-07-27 23:28:10 UTC
Permalink
At Mon, 27 Jul 2015 17:51:56 +0200,
Post by Patrick Brunschwig
Post by Neal H. Walfield
Hi,
The idea I have in mind is roughly as follows: if you upload a key to
a keyserver, the keyserver would send an encrypted email to every UID
in the key. Each encrypted mail contains a unique link to confirm the
email address. Once all email addresses are confirmed, the key is
validated and the keyserver will allow access to it just like with any
regular keyserver.
This approach is not going to stop a nation state. A nation state can
intercept the mail, decrypt it and follow the link.
If the email can be decrypted, then any email can be decrypted, which
would turn OpenPGP useless.
Sorry. This was definately unclear. What I meant is: a nation state
can create a "fake" key, upload it to the key server and intercept the
mail encrypted to the fake key thereby validating the fake key.
Post by Patrick Brunschwig
In any case, the target users are not the Edward Snowdens of this world,
but the 99% of people who just want to communicate easily with each
other and don't want to be bothered too much with key complicated key
lookup/verification scenarios.
This is a worthy goal :).

:) Neal
Neal H. Walfield
2015-07-28 07:22:23 UTC
Permalink
Hi,

Did you consider user a proof-of-work scheme? For instance, the user
does a 1 week PoW, signs the result and attackes it to the key. These
would be refreshed about once a year.

This eliminates the verification servers and the problems associated
with them (namely, people need to trust them and there can't be too
many of them).

It also increases usability: there are no emails. This can be done
completely by, say, gpg-agent in the background.

gpg (or the email clients) don't need to know about special
verification keys / signatures. They just check the proof of work and
sort the returned keys appropriately.

Neal
Ingo Klöcker
2015-07-28 15:06:28 UTC
Permalink
Post by Neal H. Walfield
Hi,
Did you consider user a proof-of-work scheme? For instance, the user
does a 1 week PoW, signs the result and attackes it to the key. These
would be refreshed about once a year.
Which problem do you propose to address with such a scheme? I can see the
zombie key issue being addressed by this, but this issue can as easily be
addressed by 1-year-key-expiration (where the PoW consists of extending the
expiration date).

I don't see how a PoW scheme addresses the fake key issue. Someone who is
motivated enough to create a fake key will most likely also be motivated
enough to add a PoW (at least, for the first year).


Regards,
Ingo
MFPA
2015-07-28 18:22:29 UTC
Permalink
Hi


On Tuesday 28 July 2015 at 8:22:23 AM, in
Post by Neal H. Walfield
Did you consider user a proof-of-work scheme? For
instance, the user does a 1 week PoW, signs the result
and attackes it to the key. These would be refreshed
about once a year.
Would this one-week PoW pause when the user shuts down and continue
when they boot it up? There are plenty of email users who do not leave
their computer running all the time.
Post by Neal H. Walfield
This eliminates the verification servers and the
problems associated with them (namely, people need to
trust them and there can't be too many of them).
It also eliminates any attempt to to establish a link between the key
and the email address in the UID.
Post by Neal H. Walfield
gpg (or the email clients) don't need to know about
special verification keys / signatures. They just
check the proof of work and sort the returned keys
appropriately.
Instead of one special signature notation type, we have another that
will be much larger?

- --
Best regards

MFPA <mailto:2014-667rhzu3dc-lists-***@riseup.net>

Censor: a man who knows more than he thinks you ought to.
Neal H. Walfield
2015-07-28 22:46:10 UTC
Permalink
At Tue, 28 Jul 2015 19:22:29 +0100,
Post by MFPA
On Tuesday 28 July 2015 at 8:22:23 AM, in
Post by Neal H. Walfield
Did you consider user a proof-of-work scheme? For
instance, the user does a 1 week PoW, signs the result
and attackes it to the key. These would be refreshed
about once a year.
Would this one-week PoW pause when the user shuts down and continue
when they boot it up? There are plenty of email users who do not leave
their computer running all the time.
Of course. A simple proof of work scheme is to find a hash that
starts with X zeros. This requires 2^X steps. In our case, the
prefix of the text would be the primary public key.
Post by MFPA
Post by Neal H. Walfield
This eliminates the verification servers and the
problems associated with them (namely, people need to
trust them and there can't be too many of them).
It also eliminates any attempt to to establish a link between the key
and the email address in the UID.
I'm not so sure. Recall that we are not attempting to protect against
attacks by nation states. As such, performing a week of computation
each year is going to be too much to maintain for those who upload
fake keys. Moreover, this will automatically purge old keys (or at
least rank them very low in search results). In other words, only
people who actually use a given key will bother performing the work.
Post by MFPA
Post by Neal H. Walfield
gpg (or the email clients) don't need to know about
special verification keys / signatures. They just
check the proof of work and sort the returned keys
appropriately.
Instead of one special signature notation type, we have another that
will be much larger?
What do you mean? A PoW is just a few dozen bytes large...

Neal
MFPA
2015-07-29 00:03:53 UTC
Permalink
Hi


On Tuesday 28 July 2015 at 11:46:10 PM, in
Post by Neal H. Walfield
Post by MFPA
It also eliminates any attempt to to establish a link
between the key and the email address in the UID.
I'm not so sure. Recall that we are not attempting to
protect against attacks by nation states. As such,
performing a week of computation each year is going to
be too much to maintain for those who upload fake keys.
And too much for people with multiple email addresses.
Post by Neal H. Walfield
Moreover, this will automatically purge old keys (or at
least rank them very low in search results). In other
words, only people who actually use a given key will
bother performing the work.
If the search results were returned in order of PoW date, newest
first, that would be great. Are they currently sorted at all, or
simply returned in the order in which they are found?

This still seems less rigorous to me than having to receive an email
sent to that address and decrypt it with that key. I guess it's a case
of swings and roundabouts.




- --
Best regards

MFPA <mailto:2014-667rhzu3dc-lists-***@riseup.net>

There is no snooze button for a cat that wants breakfast
Neal H. Walfield
2015-07-29 12:07:21 UTC
Permalink
At Wed, 29 Jul 2015 01:03:53 +0100,
Post by MFPA
On Tuesday 28 July 2015 at 11:46:10 PM, in
Post by Neal H. Walfield
Post by MFPA
It also eliminates any attempt to to establish a link
between the key and the email address in the UID.
I'm not so sure. Recall that we are not attempting to
protect against attacks by nation states. As such,
performing a week of computation each year is going to
be too much to maintain for those who upload fake keys.
And too much for people with multiple email addresses.
It doesn't have to be per-email address. It is sufficient to attach
it to the primary key.
Post by MFPA
This still seems less rigorous to me than having to receive an email
sent to that address and decrypt it with that key. I guess it's a case
of swings and roundabouts.
Well, I don't like the CA model and that's what Nico is basically
proposing (with less rigorous checks). Another huge disadvantage is
that user's have to actively participate by replying to emails /
visiting a link.

Using PoW, no human intervention is required and there is no central
authority. PoW relies on the assumption that conducting an attack is
too expensive to do / maintain.

:) Neal
MFPA
2015-07-29 13:41:07 UTC
Permalink
Hi


On Wednesday 29 July 2015 at 1:07:21 PM, in
Post by Neal H. Walfield
It doesn't have to be per-email address. It is
sufficient to attach it to the primary key.
Fair enough if it is just to signify the key is in current usage. But
I think it does have to be per-email address if the point is to
address the same issue as Nico's scheme.

The key announcements in Mike Ingle's Confidant Mail include a Proof
of Work, and I think they are done every few days. If you stop
using the key, it stops being announced and over time disappears from
the DHT. But the keys there do not have multiple addresses. (They
don't really even *need* an address, the fingerprint will suffice.)
<https://confidantmail.org/download/spec.pdf>
Post by Neal H. Walfield
Well, I don't like the CA model and that's what Nico is
basically proposing (with less rigorous checks).
Another huge disadvantage is that user's have to
actively participate by replying to emails / visiting a
link.
Yes, PoW has none of that.

If you went for a per-UID PoW and a common validation signature
notation with Nico's scheme ("type": "ProofOfWork" instead of
"enc-email"), the schemes could operate together as compatible
alternatives.


- --
Best regards

MFPA <mailto:2014-667rhzu3dc-lists-***@riseup.net>

Working hard. Please interrupt at once.
n***@enigmail.net
2015-07-29 16:24:08 UTC
Permalink
Post by MFPA
Post by Neal H. Walfield
Well, I don't like the CA model and that's what Nico is
basically proposing (with less rigorous checks).
Another huge disadvantage is that user's have to
actively participate by replying to emails / visiting a
link.
Yes, PoW has none of that.
If you went for a per-UID PoW and a common validation signature
notation with Nico's scheme ("type": "ProofOfWork" instead of
"enc-email"), the schemes could operate together as compatible
alternatives.
I am happy to propose other way of validation.
Unfortunately I didn't understand the PoW approach yet.

So, could somebody explain in a bit more detail how a PoW approach works?

In my scenario a user only has to do 2 easy and understandable things:
a) change the keyserver configuration:
I.e. replace a keyserver by a validating keyserver proxy
b) From time to time process an email asking for
email confirmation by clicking the appropriate link
IMO, that's easy,
that's something people are used to do
(when they register to other services),
that's rare enough to get accepted..

And it works with each existing email client
(where I can configure the keyserver).

So, how does the PoW approach works in practice?
How does this validate an email?
What has the user to do?
Does it work for each existing email client?

IMO anything more complicated makes acceptance more problematic.
E.g. using two servers (asking for validation at another server
than the keyserver) is IMO for most people simply a show stopper.
Even replying with a signed email IMO instead of
clicking a link sounds more complicated to me.
IMO, we should avoid any step that makes the scenario
more complex than necessary (without a significant win).

But as written, I didn't understand the PoW scenario yet.
may be the effective interaction (based on the UIs of existing
email clients) is not worse.

Sorry that I am not an expert in this area.
Nico
--
Nicolai M. Josuttis
www.josuttis.de
mailto:***@enigmail.net
PGP fingerprint: CFEA 3B9F 9D8E B52D BD3F 7AF6 1C16 A70A F92D 28F5
Viktor Dick
2015-07-30 06:04:28 UTC
Permalink
Post by n***@enigmail.net
So, could somebody explain in a bit more detail how a PoW approach works?
As far as I understand it, for any key that you have - regardless
whether you have access to the mail address in the uid - you can add
some signature where anyone with the public key can quickly check that
the person that posesses the private key has spent a specific amount of
computing power (p.e., 1 week with an average PC) to create this
signature. It is hard to create the signature (impossible without the
private key, a lot of computing power with it) but easy to check.
Essentially, you create the possibility to make a key 'premium' by
spending this time and hope that trolls who flood the keyservers with
fake keys will be deterred by the costs. Anyone who does not have any
problem with trolls can of course still upload a non-premium key.

I myself find the idea not so appealling. I would not like it if after
creating a key my machine had high CPU load for a couple of weeks. And I
doubt that many trolls will be deterred by it - the number of fake keys
per time interval will go down, but since they are anyhow going out of
their way to create problems for others without any gain for themselves,
I think a significant portion will still do it even if it costs more.

I rather like the idea of servers that offer to sign your key (or rather
a specific UID) and send it to your email, encrypted to you. For the
user this just means that if he has the problem of trolls using his
address he has to send his key to such a server or upload it in a
webinterface, then receive the mail, decrypt it and import the contained
signatures to his key, and optionally upload his new key to a keyserver
- with enigmail, for example, everything done within a few clicks.
Anyone who looks for a key to a specific mail address on a keyserver
will probably, when faced with multiple results, take the one that has
most signatures (and isn't expired) - especially if some of the
signatures are from email-verification-sounding hostnames. Therefore,
there is no necessity to create a whitelist of servers (but it can be
done, if a user decides to trust signatures of a specific server) and it
is still decentralized - anyone can set up such a verification server.
Of course with a lot of effort, a troll could still try to create a
complete fake network and cross-sign different keys. But here the amount
of work to be done for a troll is much bigger than that for a genuine
user, so hopefully it will not be a problem. It would also be possible
to check for known services if the signature is actually theirs (by
checking the key with that on the homepage or something like that), but
of course it should have been possible to do that with the original
recipient already...

These signatures should expire after a year or so, so keys where the
owner no longer has acces to the private key will loose these signatures
after a while. I myself have two older keys from early experiments
(where I did not specify an expiry date) uploaded to the keyserver
network, but I guess anyone who looks me up will take my current key,
because it has much more subkeys (which I now change every year) and
also some signatures.

Now that I think about it - if I search for the original author of the
c't article (***@ct.de), who complained about getting mails that were
encrypted to some fake key, I would assume that the keys 38EA4970 and
E1374764 are both genuine, because they both have not only selfsigs.
BTW, they are both signed by different keys with the UID
'***@ct.heise.de', so they already have a similar service in place -
of course I had to do a websearch to find if these keys are genuine,
which should probably be easier. I guess ideally the UID would contain a
weblink to a page that has the fingerprint and describes the service
shortly.

Regards,
Viktor
Ingo Klöcker
2015-07-30 08:17:44 UTC
Permalink
Post by Viktor Dick
Now that I think about it - if I search for the original author of the
encrypted to some fake key, I would assume that the keys 38EA4970 and
E1374764 are both genuine, because they both have not only selfsigs.
BTW, they are both signed by different keys with the UID
of course I had to do a websearch to find if these keys are genuine,
which should probably be easier. I guess ideally the UID would contain a
weblink to a page that has the fingerprint and describes the service
shortly.
I'm sorry to tell you that you have fallen into the trap. There is only one
genuine ***@ct.heise.de key the fingerprint of which is printed in each
issue of the c't magazine. The other one is a fake. And the fact that the fake
key with the author's email address is signed by different keys only means
that a lot of people have signed this fake key without following the proper
procedure of key validation (or that the trolls created even more fake keys to
sign the author's fake key to make it look more credible).


Regards,
Ingo
Viktor Dick
2015-07-30 08:27:37 UTC
Permalink
Post by Ingo Klöcker
I'm sorry to tell you that you have fallen into the trap. There is only one
issue of the c't magazine. The other one is a fake. And the fact that the fake
key with the author's email address is signed by different keys only means
that a lot of people have signed this fake key without following the proper
procedure of key validation (or that the trolls created even more fake keys to
sign the author's fake key to make it look more credible).
Not according to
http://www.heise.de/security/dienste/PGP-Schluessel-der-c-t-CA-473386.html
where three different keys are listed (two DSS and one RSA).
MFPA
2015-07-30 10:23:20 UTC
Permalink
Hi


On Thursday 30 July 2015 at 9:27:37 AM, in
Post by Viktor Dick
Post by Ingo Klöcker
I'm sorry to tell you that you have fallen into the trap. There is only one
issue of the c't magazine. The other one is a fake. And the fact that the fake
key with the author's email address is signed by different keys only means
that a lot of people have signed this fake key without following the proper
procedure of key validation (or that the trolls created even more fake keys to
sign the author's fake key to make it look more credible).
Not according to
http://www.heise.de/security/dienste/PGP-Schluessel-der-c-t-CA-473386.html
where three different keys are listed (two DSS and one
RSA).
I concur that the keys 38EA4970 and E1374764 both look likely to be
genuine. One has signatures from B3B2A12C, the other from DAFFB000.
The link above lists as "ct magazine CERTIFICATE <***@ct.heise.de>"
keys B3B2A12C and DAFFB000, as well as a third key BB1D9F6D.


As for the other non-revoked keys I found by searching for "schmidt
juergen heise de":-

all four are signed by a "ct magazine CERTIFICATE
<***@ct.heise.de>" key F6ADD6C2 that is not listed on the
magazine's page.

all four are also signed by a "ct magazine CERTIFICATE <ct
magazine CERTIFICATE>" key FB4DFDC6.

one of the four has a UID claiming itself to be another "ct
magazine CERTIFICATE <***@ct.heise.de>" as well as being
Juergen Schmidt's key.

Also all four have the same creation date.

I guess anybody being fooled didn't look at the page linked above, or
they would have used key 2C26A309 "ct magazine pgpCA CommunicationKey
2015 <***@ct.heise.de>" when contacting the magazine. (-;



- --
Best regards

MFPA <mailto:2014-667rhzu3dc-lists-***@riseup.net>

This message represents the official view of the voices in my head.
n***@enigmail.net
2015-07-30 12:43:35 UTC
Permalink
Indeed,

as written in the proposal
key 8B5A ABB1 A033 21CE C2FF C35F 3BA0 E844 EDEB DFE9
https://hkps.pool.sks-keyservers.net/pks/lookup?op=vindex&search=0x3BA0E844EDEBDFE9
is a faked key which is signed by a faked CA.
THAT's exactly the problem I want to fix!

And note that for ordinary users it is not that easy to find out
Yes, people could in this case double check with the web site of
the magazine. But they simply don't do that (including me and
a couple of other people here in this forum!).
As a result Jürgen aganin and again gets emails with the wrong key.
And I dind't get an answer from Jürgen ...
And ...
I want to avoid this unnessecary burdon.

BTW, as another example,
several keys of ***@gpgtools.org are faked
(search for these keys and the the interesting result).
Hi
On Thursday 30 July 2015 at 9:27:37 AM, in
Post by Viktor Dick
Post by Ingo Klöcker
I'm sorry to tell you that you have fallen into the trap. There is only one
issue of the c't magazine. The other one is a fake. And the fact that the fake
key with the author's email address is signed by different keys only means
that a lot of people have signed this fake key without following the proper
procedure of key validation (or that the trolls created even more fake keys to
sign the author's fake key to make it look more credible).
Not according to
http://www.heise.de/security/dienste/PGP-Schluessel-der-c-t-CA-473386.html
where three different keys are listed (two DSS and one
RSA).
I concur that the keys 38EA4970 and E1374764 both look likely to be
genuine. One has signatures from B3B2A12C, the other from DAFFB000.
keys B3B2A12C and DAFFB000, as well as a third key BB1D9F6D.
As for the other non-revoked keys I found by searching for "schmidt
juergen heise de":-
all four are signed by a "ct magazine CERTIFICATE
magazine's page.
all four are also signed by a "ct magazine CERTIFICATE <ct
magazine CERTIFICATE>" key FB4DFDC6.
one of the four has a UID claiming itself to be another "ct
Juergen Schmidt's key.
Also all four have the same creation date.
I guess anybody being fooled didn't look at the page linked above, or
they would have used key 2C26A309 "ct magazine pgpCA CommunicationKey
_______________________________________________
Gnupg-users mailing list
http://lists.gnupg.org/mailman/listinfo/gnupg-users
--
Nicolai M. Josuttis
www.josuttis.de
mailto:***@enigmail.net
PGP fingerprint: CFEA 3B9F 9D8E B52D BD3F 7AF6 1C16 A70A F92D 28F5
MFPA
2015-07-30 14:39:38 UTC
Permalink
On Thursday 30 July 2015 at 1:43:35 PM, in
BTW, as another example, several keys of
the the interesting result).
Sorry, I don't see a result that leaps out at me as interesting. Are
you willing to elaborate?



- --
Best regards

MFPA <mailto:2014-667rhzu3dc-lists-***@riseup.net>

Teamwork is essential - it allows you to blame someone else
Viktor Dick
2015-07-30 15:12:35 UTC
Permalink
Post by MFPA
On Thursday 30 July 2015 at 1:43:35 PM, in
BTW, as another example, several keys of
the the interesting result).
Sorry, I don't see a result that leaps out at me as interesting. Are
you willing to elaborate?
I'd say if one searches on a keyserver, it is pretty clear which key is
real. I'm a bit worried because when I search with Enigmail it does not
show the signatures, so from there they all seem equally valid.

Regards,
Viktor
Kristian Fiskerstrand
2015-07-30 15:32:47 UTC
Permalink
Post by Viktor Dick
Post by MFPA
On Thursday 30 July 2015 at 1:43:35 PM, in
faked (search for these keys and the the interesting result).
Sorry, I don't see a result that leaps out at me as interesting.
Are you willing to elaborate?
I'd say if one searches on a keyserver, it is pretty clear which
key is real. I'm a bit worried because when I search with Enigmail
it does not show the signatures, so from there they all seem
equally valid.
Instinctively this sounds flawed, the point is there is no way without
downloading the key and verifying the validation path through other
existing known good keys. If you rely solely on the number of
signatures that can easily be constructed, either through generating
new keys or due to the keyservers not doing any cryptographic
verification that the signatures themselves are correct.

... and that is intended behavior ...

- --
- ----------------------------
Kristian Fiskerstrand
Blog: http://blog.sumptuouscapital.com
Twitter: @krifisk
- ----------------------------
Public OpenPGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
- ----------------------------
Nil satis nisi optimum
Nothing but the best is good enough
MFPA
2015-07-30 23:11:35 UTC
Permalink
On Thursday 30 July 2015 at 4:12:35 PM, in
Post by Viktor Dick
Post by MFPA
On Thursday 30 July 2015 at 1:43:35 PM, in
BTW, as another example, several keys of
the the interesting result).
Sorry, I don't see a result that leaps out at me as
interesting. Are you willing to elaborate?
I'd say if one searches on a keyserver, it is pretty
clear which key is real.
Only if you download the key from the GPGTools website and find the
key-id first. (If the GPGTools team shows their key ID or Fingerprint
on their website, I failed to find it.)


My output from searching a keyserver for "gpgtools.org":-

- -----------------------------------------------------------------------

C:\TDM-GCC-32>gpg --search-keys ***@gpgtools.org
gpg: using character set 'utf-8'
gpg: data source: http://kronecker.scientia.net:11371
(1) GPGTools Team <***@gpgtools.org>
2048 bit RSA key 0xDE13CCD892EFC169, created: 2013-09-13, exp
ires: 2017-09-13
(2) GPGTools Team <***@gpgtools.org>
2048 bit RSA key 0x93F6E721F7D75F75, created: 2013-09-13, exp
ires: 2017-09-13
(3) GPGTools Team <***@gpgtools.org>
2048 bit RSA key 0x07F7603CC8F5BBF1, created: 2013-09-13, exp
ires: 2017-09-13
(4) *Key invalid; use 76D78F0500D026C4
GPG Tools Team <***@gpgtools.org>
2048 bit RSA key 0x929D128A9EA002BA, created: 2013-09-13, exp
ires: 2017-09-13
(5) George Nigg <***@gpgtools.org>
2048 bit RSA key 0xD0863D5E46FA0F9F, created: 2013-07-12, exp
ires: 2017-07-12
(6) GPGTools Team <***@gpgtools.org>
GPGMail Project Team (Official OpenPGP Key) <gpgmail-***@list
s.gpgma
GPGTools Project Team (Official OpenPGP Key) <gpgtools-***@list
s.gpgto
2048 bit DSA key 0x76D78F0500D026C4, created: 2010-08-19, exp
ires: 2018-08-19
Keys 1-6 of 6 for "***@gpgtools.org". Enter number(s), N)ext, or Q)uit >


- -----------------------------------------------------------------------


Number 6 has more UIDs but nothing in the search listing tells me any
key is clearly the one I want.

When verifying a software download, the search would be the other way
around. I would be checking a signature, so GnuPG would search the
server for the key-id that made the signature, the signature would be
good or bad, and the key would be the one their website says it should
be or it wouldn't. (OK, there would quite probably be certifications
vouching for the key as well, in case the site was hacked and now said
a different key.)
Post by Viktor Dick
I'm a bit worried because when
I search with Enigmail it does not show the signatures,
so from there they all seem equally valid.
I do not use Enigmail, so couldn't comment.

However, what would be different if one of the keys found happened to
carry one of your proposed?


- --
Best regards

MFPA <mailto:2014-667rhzu3dc-lists-***@riseup.net>

What's another word for synonym?
MFPA
2015-07-30 23:26:49 UTC
Permalink
On Friday 31 July 2015 at 12:11:35 AM, in
Post by MFPA
However, what would be different if one of the keys
found happened to carry one of your proposed?
Sorry, that should have been:-

What would be different if one of the keys found in the search
happened to carry one of the proposed email address validation
signatures?




- --
Best regards

MFPA <mailto:2014-667rhzu3dc-lists-***@riseup.net>

No matter what a man's past may have been, his future is spotless.
Viktor Dick
2015-07-31 05:43:29 UTC
Permalink
Post by MFPA
Only if you download the key from the GPGTools website and find the
key-id first. (If the GPGTools team shows their key ID or Fingerprint
on their website, I failed to find it.)
On the front page they have 'to verify the signature, please download
and import our <updated key>' right below the download button. There is
no fingerprint, but the whole key is there.
But I was talking about the fact that of the six results, one has
hundreds of signatures. Sure, in the web of trust concept this doesn't
mean anything unless there is a (short) trust chain from me to one of
these, but in practice this still significantly rises the chance that it
is the correct key (and it is, I checked with the one on their homepage).
Post by MFPA
My output from searching a keyserver for "gpgtools.org":-
'gpg --search-keys' does not seem to give a list of signatures (which
explains why enigmail also doesn't), I was searching using a web
interface. I guess this is because it is assumed that signatures do not
mean anything without a trust chain. But if I had to bet money on one of
the keys, I would still take the one with hundreds of signatures.
Post by MFPA
However, what would be different if one of the keys found happened to
carry one of your proposed email address validation signatures?
If I could quickly check (or rather, my client could do that
automatically) that the signature is also found on their web page, I can
assume that either the web page is fake (which is unlikely for something
known like ccc.de), it has been hacked (unlikely for a random troll) or
someone intercepted either my HTTP request or the original verification
e-mail (possible with a secret service, unlikely with a troll).
Therefore, it will raise my estimated probability that the owner of the
key also has access to the mailbox, which will pretty surely now be much
higher than for any fake key.
The advantage with respect to the proof of work concept is that the
procedure is asymmetric: it costs much more to troll than to verify a
genuine key.

Best regards,
Viktor
MFPA
2015-07-31 11:13:34 UTC
Permalink
Hi


On Friday 31 July 2015 at 6:43:29 AM, in
Post by MFPA
Post by MFPA
Only if you download the key from the GPGTools website and find the
key-id first. (If the GPGTools team shows their key ID or Fingerprint
on their website, I failed to find it.)
On the front page they have 'to verify the signature, please download
and import our <updated key>' right below the download button. There is
no fingerprint, but the whole key is there.
But I was talking about the fact that of the six results, one has
hundreds of signatures.
OK, you can go to a keyserver's web interface and see there are lots
of signatures there. But you cannot see that when searching the
keyserver using GnuPG, quite rightly since any signature you have not
(yet) been able to check and establish you trust it is just background
noise.
Post by MFPA
Sure, in the web of trust concept this doesn't
mean anything unless there is a (short) trust chain from me to one of
these, but in practice this still significantly rises the chance that it
is the correct key
Anybody of that opinion could be easily fooled by creating a few dozen
"fake" keys and signing one with the rest.
Post by MFPA
Post by MFPA
My output from searching a keyserver for
"gpgtools.org":-
'gpg --search-keys' does not seem to give a list of signatures (which
explains why enigmail also doesn't), I was searching using a web
interface. I guess this is because it is assumed that signatures do not
mean anything without a trust chain.
It's a fact, not just an assumption.
Post by MFPA
But if I had to bet money on one of
the keys, I would still take the one with hundreds of signatures.
How much would you pay for somebody to create a few dozen "fake" keys
and sign one with the rest?
Post by MFPA
Post by MFPA
However, what would be different if one of the keys
found happened to carry one of your proposed email
address validation signatures?
If I could quickly check (or rather, my client could do that
automatically) that the signature is also found on their web page, I can
assume that either the web page is fake (which is unlikely for something
known like ccc.de), it has been hacked (unlikely for a random troll) or
someone intercepted either my HTTP request or the original verification
e-mail (possible with a secret service, unlikely with a troll).
Therefore, it will raise my estimated probability that the owner of the
key also has access to the mailbox, which will pretty surely now be much
higher than for any fake key.
I guess your mail client would have to automatically check what is at
a URL given in a (self-)certification. Is that not an attack vector in
itself?

And wouldn't you have to download all the keys offered and check the
signatures in order to find the URLs to follow (or, indeed, the email
validation certificate notations)?
Post by MFPA
The advantage with respect to the proof of work concept is that the
procedure is asymmetric: it costs much more to troll than to verify a
genuine key.
Could the troll not reduce the cost by using something optimised for
the task, like a Bitcoin mining box as Werner mentioned? Or farm the
cost out by using a botnet to perform the PoWs?


- --
Best regards

MFPA <mailto:2014-667rhzu3dc-lists-***@riseup.net>

Hard work never killed anyone, but why take a risk?
MFPA
2015-07-30 12:21:21 UTC
Permalink
Hi


On Thursday 30 July 2015 at 7:04:28 AM, in
Post by Viktor Dick
Post by n***@enigmail.net
So, could somebody explain in a bit more detail how a PoW approach works?
As far as I understand it, for any key that you have -
regardless whether you have access to the mail address
in the uid - you can add some signature where anyone
with the public key can quickly check that the person
that posesses the private key has spent a specific
amount of computing power (p.e., 1 week with an average
PC) to create this signature. It is hard to create the
signature (impossible without the private key, a lot of
computing power with it) but easy to check.
That's my understanding, too.
Post by Viktor Dick
Essentially, you create the possibility to make a key
'premium' by spending this time and hope that trolls
who flood the keyservers with fake keys will be
deterred by the costs.
You can hope so, but is it reasonable to expect?
Post by Viktor Dick
Anyone who does not have any
problem with trolls can of course still upload a
non-premium key.
And anybody who doesn't trust Proof of Work as a validation could
trust only encrypted-mail validations. It would be simple, as PoW
validation signatures would be self-certs whereas enc-mail validation
certs would come from a validation server's key.
Post by Viktor Dick
I myself find the idea not so appealling. I would not
like it if after creating a key my machine had high CPU
load for a couple of weeks. And I doubt that many
trolls will be deterred by it - the number of fake keys
per time interval will go down, but since they are
anyhow going out of their way to create problems for
others without any gain for themselves, I think a
significant portion will still do it even if it costs
more.
I think a week of computing for the PoW is excessive. But if the
troll's CPU time is on a botnet, they won't care about the cost or
about slowing down their machine for a week.
Post by Viktor Dick
I rather like the idea of servers that offer to sign
your key (or rather a specific UID) and send it to your
email, encrypted to you. For the user this just means
that if he has the problem of trolls using his address
he has to send his key to such a server or upload it in
a webinterface, then receive the mail, decrypt it and
import the contained signatures to his key, and
optionally upload his new key to a keyserver - with
enigmail, for example, everything done within a few
clicks.
I prefer this method rather than clicking a link in an email. But
people are used to that scenario from website registrations, as long
as the email arrives within a couple of minutes of them registering on
the website.
Post by Viktor Dick
Anyone who looks for a key to a specific mail
address on a keyserver will probably, when faced with
multiple results, take the one that has most signatures
(and isn't expired) - especially if some of the
signatures are from email-verification-sounding
hostnames.
Surely, all signatures from keys that you do not already trust are
just ambient noise.
Post by Viktor Dick
Therefore, there is no necessity to create a
whitelist of servers (but it can be done, if a user
decides to trust signatures of a specific server) and
it is still decentralized - anyone can set up such a
verification server.
If it can be done without Big Brother creating a whitelist, it should
be.
Post by Viktor Dick
Of course with a lot of effort, a
troll could still try to create a complete fake network
and cross-sign different keys. But here the amount of
work to be done for a troll is much bigger than that
for a genuine user, so hopefully it will not be a
problem.
I imagine it would not be much of a problem for a troll to automate
most of the work. But unless they compromise some keys from genuine
validators, it's all in vain if people bother to check signatures.

Hold on, the magazine writer's problem is that people encrypt his
emails to the wrong key because they do not bother to check
signatures.
--
Best regards

MFPA <mailto:2014-667rhzu3dc-lists-***@riseup.net>

A closed mouth gathers no foot
Patrick Brunschwig
2015-07-29 15:49:10 UTC
Permalink
Post by Neal H. Walfield
At Wed, 29 Jul 2015 01:03:53 +0100,
Post by MFPA
On Tuesday 28 July 2015 at 11:46:10 PM, in
Post by Neal H. Walfield
Post by MFPA
It also eliminates any attempt to to establish a link
between the key and the email address in the UID.
I'm not so sure. Recall that we are not attempting to
protect against attacks by nation states. As such,
performing a week of computation each year is going to
be too much to maintain for those who upload fake keys.
And too much for people with multiple email addresses.
It doesn't have to be per-email address. It is sufficient to attach
it to the primary key.
This allows me to have ***@enigmail.net verified OK. Then I add a
new UID ***@evil.com and delete ***@enigmail.net from the key.
And then I upload my key to the keyservers network, and I'll end up
where we are now.
Post by Neal H. Walfield
Post by MFPA
This still seems less rigorous to me than having to receive an email
sent to that address and decrypt it with that key. I guess it's a case
of swings and roundabouts.
Well, I don't like the CA model and that's what Nico is basically
proposing (with less rigorous checks). Another huge disadvantage is
that user's have to actively participate by replying to emails /
visiting a link.
Using PoW, no human intervention is required and there is no central
authority. PoW relies on the assumption that conducting an attack is
too expensive to do / maintain.
The whole point of this exercise is to verify that the key and the email
address(es) belong _together_. I don't see how PoW could do this, or I
didn't understand it well enough.

-Patrick
Werner Koch
2015-07-30 11:04:29 UTC
Permalink
Post by Patrick Brunschwig
The whole point of this exercise is to verify that the key and the email
address(es) belong _together_. I don't see how PoW could do this, or I
didn't understand it well enough.
The idea with a regular PoW is that an attacker (well, script kiddie)
would look for a lower hanfing fruit than to create a faked key. The
PoW is expensive and thus the expectaion is that it would at best only
done for the first interval but not a second time

My points against PoW are:

- PoW is not green computing so it should only be done in rare cases.

- Users with low end devices are discriminated.

- With all that surplus Bitcoin mining rig we would soon see a lot of
faked keys just for the fun of it - or as a service.



Salam-Shalom,

Werner
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
listo factor
2015-07-31 07:15:23 UTC
Permalink
The problem with most "e-mail reform" proposals (this one included)
is that they don't address what is the primary problem of essential
users of the encrypted communication: that to their attackers the
knowledge of who communicates with whom is of greater value than
the content of the message. Without solving that primary problem,
the motivation for the adoption of any new scheme is either low
or non-existent.

Listo Factor
MFPA
2015-07-31 10:31:56 UTC
Permalink
On Friday 31 July 2015 at 8:15:23 AM, in
Post by listo factor
The problem with most "e-mail reform" proposals (this
one included) is that they don't address what is the
primary problem of essential users of the encrypted
communication: that to their attackers the knowledge of
who communicates with whom is of greater value than the
content of the message.
Taken in the round for general surveillance purposes, yes.

But for a relatively small number of messages, it's the content that
is more valuable. For example, if Bob emails Alice his credit card
details (or commercial secrets).
Post by listo factor
Without solving that primary
problem, the motivation for the adoption of any new
scheme is either low or non-existent.
One scheme that does address the metadata issue is Confidant Mail
<https://confidantmail.org/>.


- --
Best regards

MFPA <mailto:2014-667rhzu3dc-lists-***@riseup.net>

Editing is a rewording activity
Daniel Kahn Gillmor
2015-08-04 23:05:12 UTC
Permalink
Hi all---
Post by n***@enigmail.net
In the past months I tried to come up with a concrete proposal.
I discussed it already with some people and
this is what I/we propose so far.
Sorry to take a while to respond to this thread. I think a proposal for
an e-mail-validating keyserver/mail-loop can be evaluated in several
different ways. unfortunately, none of them look to me like they'll
solve the concerns of the c't editor automatically without introducing
other problems.

Some ways of looking at the problem:

0) is it OK to run an autonomous validating OpenPGP certification
agent?

I think the answer here is clearly "yes". OpenPGP keys make
certifications based on their own policies, and if you set up something
like this, you can set the policy to whatever you like. Some people
might even use it, like people used their PGP Global Directory as a
public attestation service.

1) What (if any) technical structure should there be for an autonomous
validating OpenPGP certification agent?

This thread discussed several options, including e-mail pingbacks,
requirements of PoW, notation data, etc. I don't have a strong opinion
on this, and i tend to think that a bit of experimentation with actually
running such an agent would be more fruitful than abstract discussion.

2) Should existing OpenPGP clients be willing to rely on certifications
made by such an autonomous validating OpenPGP certification agent?
if so, which one(s) ?

This is now asking the same question as "should browsers/OSes come with
a built-in list of X.509 trust anchors?" From the perspective of the
global network, where many people use the same tools but have different
and non-aligned goals and interests, the answer is clearly "no" to me.
But of course the practical answer to most deployed software
installations is "yes", because even extremely technically-sophisticated
people don't understand how to (or have a way to) configure their trust
anchors to align with their own interests.

Should OpenPGP implementations follow this model? I'm not convinced it
should: it creates high-value targets (the widely-relied-upon
certification agents), and provides little to no mechanisms for
oversight/auditing of those targets.

That said, the possibility of assigning marginal ownertrust to such an
agent, coupled with the existence and common usage of the keyserver
network makes it possible provide a bit more oversight on the use of
these high-valued keys than we have in the (current CT-less) X.509
ecosystem.


------

In summary, i would not want the responsibility of running one of these
agents myself. If one existed, i would be fine submitting my own
OpenPGP certificate to it for its certification, assuming its
certifications don't bloat my cert too much, and i'd be happy to give
feedback about its workflow/security posture to whoever is operating it.

I don't think that any special notations are necessary for such a use.
Just treat it as a special certification-only OpenPGP cert, and document
its certification policy clearly.

I'd be disappointed if GnuPG or other OpenPGP tools were to decide that
they "trusted" such an agent on behalf of all users.

So, does this solve the problem that the c't folks had? Not without a
lot of other tooling and incentives that don't exist yet. Could such an
agent be a useful contribution to a larger certification ecosystem?
Possibly, but we won't know that until someone is willing to step up to
be responsible for such an agent, and to try it out.

--dkg

Continue reading on narkive:
Loading...