The pool is shrinking

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
91 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

Re: The pool is shrinking

Stefan Claas
Todd Fleisher wrote:

> > On Aug 16, 2019, at 10:24 AM, Stefan Claas <[hidden email]> wrote:
> >
> > DevPGSV Pablo wrote:
> >
> > O.k. I must admit I did not thought about the centralization issue,
> > people might have.
> >
> > Well, then operators could put that on a link of their own WWW key
> > server interface and Kristian could add only a column in his pool
> > page, indicating that server x,y,z has a canary, without taking any
> > actions.
> >
> > Even if Kristian does not like the idea than at least people could
> > see that operators are willing to support the idea.
>
> I don’t understand what benefit having operators post warrant canaries is
> supposed to provide in the context of the SKS network.

The purpose of this suggestion is to bring back a little bit more trust in
a Network, which is currently broken by design. People, like me, do not
like the idea of sharing dumps to 3rd parties (hello GDPR), without our
consent.

Operators should protect the database as best as possible.

Dumps can be used for a variety of tasks. I remember rjh once saying that
people asked him if they can trust the key servers. Does this trust mean:
Can a key been removed or faked, or a dump been used for analyzing social
graphs of non-trained dissidents, activists etc. who, not knowing better
before, signed each others key publicity. (A WWW key server interface in
its current form may reveal such info too, but IHMO not so quickly.)

Regards
Stefan



--
box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56
GPG: C93E252DFB3B4DB7EAEB846AD8D464B35E12AB77 (avail. on Hagrid, WKD)

_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

Re: The pool is shrinking

Stefan Claas
Stefan Claas wrote:

> Dumps can be used for a variety of tasks. I remember rjh once saying that
> people asked him if they can trust the key servers. Does this trust mean:
> Can a key been removed or faked, or a dump been used for analyzing social
> graphs of non-trained dissidents, activists etc. who, not knowing better
> before, signed each others key publicity. (A WWW key server interface in
> its current form may reveal such info too, but IHMO not so quickly.)

And one more point. Publicity available dumps made it possible to bootstrap
key server in non-so-democratic countries, where people are probably not
allowed to use strong encryption, like PGP ... Let alone that when you travel
for holidays in such a country one may have then also 'little' problems.

Regards
Stefan

--
box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56
GPG: C93E252DFB3B4DB7EAEB846AD8D464B35E12AB77 (avail. on Hagrid, WKD)

_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

Re: The pool is shrinking

Stefan Claas
In reply to this post by Todd Fleisher
Todd Fleisher wrote:

> I will also point out there is a movement amongst several major software
> distributions that bring PGP support to the masses (especially as it relates
> to email) that are migrating away from the SKS network in large part because
> of this very issue (https://keys.openpgp.org/about/usage
> <https://keys.openpgp.org/about/usage>). And while there are other use cases
> for the SKS network for sure, I believe the ongoing issue where keys can be
> rendered un-importable by malicious third parties without warning threatens
> its very existence and needs to be dealt with before it’s too late.

You may check out also the new Mailvelope Key Server:

https://keys.mailvelope.com/

And don't forget keybase is growing fast:

Stats
Keys: 2,020,113
Humans: 405,032
Teams: 68,144

And finally individuals can run their own WKD instance.

You guys need a lot of brainstorming IMHO on how to improve the SKS
infrastructure to get back users. Maybe it would be a good idea to
get the hockeypuck author on board, because it is written in Golang
and I assume that there are more Golang programmers available to help
you guys out, compared to OCaml programmers.

Regards
Stefan

--
box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56
GPG: C93E252DFB3B4DB7EAEB846AD8D464B35E12AB77 (avail. on Hagrid, WKD)

_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

Re: The pool is shrinking

Robert J. Hansen-3
In reply to this post by stuff
> Hansen its 2019 not 1990 and you need to evolve your thinking beyond your own personal interests!

Yawn.  Call me when you've given up on the ad hominem.

> Do you think the GDPR is a bad thing?

I think it's a law enacted by a nation I'm not party to and am not
obligated to obey.  That means any and all arguments that start with
"but it's the law!" are meaningless for me and many others.  It may be
your law but it's not mine and I'm not obligated to follow it.

> Do you think people having the right to better privacy is bad?

Of course not.  But you seem to believe the GDPR is clearly a win for
the liberties of all people involved, whereas the truth is it
prioritizes one kind of liberty for one person (your right to be
private) above another kind of liberty for another person (my right to
share facts with others).

It's okay for people to disagree with the tradeoffs of liberty that are
baked into laws.  That's called political dissent, and respecting
dissent is every bit as important as respecting privacy.

Start showing some.

_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

Re: The pool is shrinking

stuff
In reply to this post by Stefan Claas
I was not aware of mailvelopes keyserver, looks good!

Yakamo

On Fri, 16 Aug 2019 21:31:55 +0200
Stefan Claas <[hidden email]> wrote:

> Todd Fleisher wrote:
>
> > I will also point out there is a movement amongst several major software
> > distributions that bring PGP support to the masses (especially as it relates
> > to email) that are migrating away from the SKS network in large part because
> > of this very issue (https://keys.openpgp.org/about/usage
> > <https://keys.openpgp.org/about/usage>). And while there are other use cases
> > for the SKS network for sure, I believe the ongoing issue where keys can be
> > rendered un-importable by malicious third parties without warning threatens
> > its very existence and needs to be dealt with before it’s too late.
>
> You may check out also the new Mailvelope Key Server:
>
> https://keys.mailvelope.com/
>
> And don't forget keybase is growing fast:
>
> Stats
> Keys: 2,020,113
> Humans: 405,032
> Teams: 68,144
>
> And finally individuals can run their own WKD instance.
>
> You guys need a lot of brainstorming IMHO on how to improve the SKS
> infrastructure to get back users. Maybe it would be a good idea to
> get the hockeypuck author on board, because it is written in Golang
> and I assume that there are more Golang programmers available to help
> you guys out, compared to OCaml programmers.
>
> Regards
> Stefan
>
> --
> box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56
> GPG: C93E252DFB3B4DB7EAEB846AD8D464B35E12AB77 (avail. on Hagrid, WKD)
>
> _______________________________________________
> Sks-devel mailing list
> [hidden email]
> https://lists.nongnu.org/mailman/listinfo/sks-devel


--


_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

Re: The pool is shrinking

Stefan Claas
[hidden email] wrote:

> I was not aware of mailvelopes keyserver, looks good!

Indeed! I just did a quick test and compared to Hagrid
my CA sig3 from Governikus is not stripped off. :-)

Regards
Stefan

--
box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56
GPG: C93E252DFB3B4DB7EAEB846AD8D464B35E12AB77 (avail. on Hagrid, WKD)

_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

Re: The pool is shrinking

Andrew Gallagher
In reply to this post by Stefan Claas

> On 16 Aug 2019, at 19:48, Stefan Claas <[hidden email]> wrote:
>
> People, like me, do not
> like the idea of sharing dumps to 3rd parties (hello GDPR), without our
> consent.

There is no net difference between distributing a dump and peering with another sks server. I don’t understand why you keep going on about dumps and not peering. They are the same thing from a data protection POV.

A
_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

Re: The pool is shrinking

Andrew Gallagher
In reply to this post by Stefan Claas

> On 16 Aug 2019, at 20:31, Stefan Claas <[hidden email]> wrote:
>
> You guys need a lot of brainstorming IMHO on how to improve the SKS
> infrastructure to get back users.

I dunno, I’ve been brainstorming pretty hard on this list recently... :-p

> Maybe it would be a good idea to
> get the hockeypuck author on board, because it is written in Golang
> and I assume that there are more Golang programmers available to help
> you guys out, compared to OCaml programmers.

The issue is less about the programming (or the programming language) and more about the protocol. If we had agreement on a replacement protocol then anyone reasonably competent could program it. I know of three SKS *protocol* implementations in the wild. Any or all of these could be upgraded to the new protocol - IFF we had a) broad agreement on what the new protocol was *for*, and b) a robust specification.

A
_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

Re: The pool is shrinking

Stefan Claas
In reply to this post by Andrew Gallagher
Andrew Gallagher wrote:

>
> > On 16 Aug 2019, at 19:48, Stefan Claas <[hidden email]> wrote:
> >
> > People, like me, do not
> > like the idea of sharing dumps to 3rd parties (hello GDPR), without our
> > consent.
>
> There is no net difference between distributing a dump and peering with
> another sks server. I don’t understand why you keep going on about dumps and
> not peering. They are the same thing from a data protection POV.

O.k. I understand your point, but what I like to say is that I or anybody
else can download a dump without running a key server. While running a
key server requires a dump, it would be really nice if dumps are only
available to a (trusted) pool of operators, as long as the current SKS
model is still available on the Internet.

Regards
Stefan

--
box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56
GPG: C93E252DFB3B4DB7EAEB846AD8D464B35E12AB77 (avail. on Hagrid, WKD)

_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

Re: The pool is shrinking

Stefan Claas
In reply to this post by Andrew Gallagher
Andrew Gallagher wrote:

>
> > On 16 Aug 2019, at 20:31, Stefan Claas <[hidden email]> wrote:
> >
> > You guys need a lot of brainstorming IMHO on how to improve the SKS
> > infrastructure to get back users.
>
> I dunno, I’ve been brainstorming pretty hard on this list recently... :-p
>
> > Maybe it would be a good idea to
> > get the hockeypuck author on board, because it is written in Golang
> > and I assume that there are more Golang programmers available to help
> > you guys out, compared to OCaml programmers.
>
> The issue is less about the programming (or the programming language) and
> more about the protocol. If we had agreement on a replacement protocol then
> anyone reasonably competent could program it. I know of three SKS *protocol*
> implementations in the wild. Any or all of these could be upgraded to the new
> protocol - IFF we had a) broad agreement on what the new protocol was *for*,
> and b) a robust specification.

I recently came across dkg's draft. (sorry I don't have a link currently handy)

Since he is a respected community member, at least in the GnuPG ML, maybe his
draft could be used as a reference, to come up with specs, discussed here,
which a programmer could make a software of. At least his draft could be used
as a guideline for discussions.

Regards
Stefan


--
box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56
GPG: C93E252DFB3B4DB7EAEB846AD8D464B35E12AB77 (avail. on Hagrid, WKD)

_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

Re: The pool is shrinking

H Visage
In reply to this post by Stefan Claas


> On 16 Aug 2019, at 22:45 , Stefan Claas <[hidden email]> wrote:
>
> O.k. I understand your point, but what I like to say is that I or anybody
> else can download a dump without running a key server. While running a
> key server requires a dump, it would be really nice if dumps are only
> available to a (trusted) pool of operators, as long as the current SKS
> model is still available on the Internet.

Well… here you’ll have to define “trusted”… Am I (being a South African with SKS servers in South Africa, France, Canada &  Singapore) being trust worthy for a GDPR? Which of my servers may or may not peer with each other as a side note? Now if I load a dump in FRance, may I peer with my RSA server? or should I load the dump in RSA and peer with my France server? If I receive a GDPR take down, does it only apply to my server(s) in France, or what if my RSA servers are providing a VPN/TOR endpoint via a FRance server, is that also under the GDPR?

The fact that the dumps exist, ACROSS THE GLOBE, makes any GDPR related discussion IMHO a very mute point once the data have entered the SKS server network.

It’s like unseeing a naked photo of person… it’s just not “possible”.

I would echo what everybody should know and understand: a PUBLIC KEY is by definition *PUBLIC*, NOTHING PRIVATE about it… BY DEFINITION.

SKS network contains *PUBLIC* keys. It’s purpose, is to PUBLICLY make your communications, signed/etc. with the associated *private* key, by directed to you and associated with you to proof that it was *you* that signed/produced/etc. that piece of communication. That purpose would be to know that the communication was not forged as you, and thus people can take that piece of communications as being your words spoken and trusted as it was not somebody else faked you. It is also a mechanism that you can receive communications, meant only for your eyes (I meant *private* key :) )that nobody else can decode (given they’ve not compromised your private key).

The fact that the SKS network had been and probably will still be abused/DoSed/etc. we can’t deny, but once people becomes silly, as I see this whole GDPR discussions have been, I have but one set of advice: Either you fix it, or you get out of the SKS server network… let those that run the SKS servers have the pains/legal battles/etc. when they are attacked by the GDPR enforcers, we’ll fight that battle, no need to make our lives worse off if you can’t add positive value…

Yours enjoying his pop-corn reading these debates

Hendrik




_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: The pool is shrinking

Stefan Claas
Hendrik Visage wrote:

> SKS network contains *PUBLIC* keys. It’s purpose, is to PUBLICLY make your
> communications, signed/etc. with the associated *private* key, by directed to
> you and associated with you to proof that it was *you* that
> signed/produced/etc. that piece of communication. That purpose would be to
> know that the communication was not forged as you, and thus people can take
> that piece of communications as being your words spoken and trusted as it was
> not somebody else faked you. It is also a mechanism that you can receive
> communications, meant only for your eyes (I meant *private* key :) )that
> nobody else can decode (given they’ve not compromised your private key).
>
> The fact that the SKS network had been and probably will still be
> abused/DoSed/etc. we can’t deny, but once people becomes silly, as I see this
> whole GDPR discussions have been, I have but one set of advice: Either you
> fix it, or you get out of the SKS server network… let those that run the SKS
> servers have the pains/legal battles/etc. when they are attacked by the GDPR
> enforcers, we’ll fight that battle, no need to make our lives worse off if
> you can’t add positive value…
>
> Yours enjoying his pop-corn reading these debates

O.k. let's forget for a moment the GDPR.

Would you or any other SKS operator in 2019 agree that a person should
have the right that his / her public key can be removed from the SKS
network if he / she asks for?

An example: You have children and you recommend as an privacy advocate
and parent that your minors should use PGP.

A nasty classmate signs your daughters pub key with bad things. Teenagers
usually smarter than their parents may not handle such a situation well,
like us old PGP farts.

Please explain in 2019 to you friends, wishing to learn secure email
communications, that they should use PGP, while everybody can sign
their pub key with arbritary  (and illegal) data, thanks to SKS.

They will for sure show you a stinking finger.

A public key in 2019 does not mean that it can be used for nasty
things, while a public key holder can not defend him  / her self!

May I ask why you SKS operators did not implemented GnuPG's
feature the --no-modifiy flag? It is not a brand new feature ...

Regards
Stefan

--
box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56
GPG: C93E252DFB3B4DB7EAEB846AD8D464B35E12AB77 (avail. on Hagrid, WKD)

_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

Re: The pool is shrinking

Ryan Hunt-3
Its quite simple really, you sign a revocation of the key and create a new one, just like you'd do if you ever suspected your private key had been compromised. 

-R

On Fri, Aug 16, 2019 at 3:29 PM Stefan Claas <[hidden email]> wrote:
Hendrik Visage wrote:

> SKS network contains *PUBLIC* keys. It’s purpose, is to PUBLICLY make your
> communications, signed/etc. with the associated *private* key, by directed to
> you and associated with you to proof that it was *you* that
> signed/produced/etc. that piece of communication. That purpose would be to
> know that the communication was not forged as you, and thus people can take
> that piece of communications as being your words spoken and trusted as it was
> not somebody else faked you. It is also a mechanism that you can receive
> communications, meant only for your eyes (I meant *private* key :) )that
> nobody else can decode (given they’ve not compromised your private key).
>
> The fact that the SKS network had been and probably will still be
> abused/DoSed/etc. we can’t deny, but once people becomes silly, as I see this
> whole GDPR discussions have been, I have but one set of advice: Either you
> fix it, or you get out of the SKS server network… let those that run the SKS
> servers have the pains/legal battles/etc. when they are attacked by the GDPR
> enforcers, we’ll fight that battle, no need to make our lives worse off if
> you can’t add positive value…
>
> Yours enjoying his pop-corn reading these debates

O.k. let's forget for a moment the GDPR.

Would you or any other SKS operator in 2019 agree that a person should
have the right that his / her public key can be removed from the SKS
network if he / she asks for?

An example: You have children and you recommend as an privacy advocate
and parent that your minors should use PGP.

A nasty classmate signs your daughters pub key with bad things. Teenagers
usually smarter than their parents may not handle such a situation well,
like us old PGP farts.

Please explain in 2019 to you friends, wishing to learn secure email
communications, that they should use PGP, while everybody can sign
their pub key with arbritary  (and illegal) data, thanks to SKS.

They will for sure show you a stinking finger.

A public key in 2019 does not mean that it can be used for nasty
things, while a public key holder can not defend him  / her self!

May I ask why you SKS operators did not implemented GnuPG's
feature the --no-modifiy flag? It is not a brand new feature ...

Regards
Stefan

--
box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56
GPG: C93E252DFB3B4DB7EAEB846AD8D464B35E12AB77 (avail. on Hagrid, WKD)

_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel

_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

Re: The pool is shrinking

H Visage
In reply to this post by Stefan Claas


> On 16 Aug 2019, at 23:29 , Stefan Claas <[hidden email]> wrote:
>
> Hendrik Visage wrote:
>
>> SKS network contains *PUBLIC* keys. It’s purpose, is to PUBLICLY make your
>> communications, signed/etc. with the associated *private* key, by directed to
>> you and associated with you to proof that it was *you* that
>> signed/produced/etc. that piece of communication. That purpose would be to
>> know that the communication was not forged as you, and thus people can take
>> that piece of communications as being your words spoken and trusted as it was
>> not somebody else faked you. It is also a mechanism that you can receive
>> communications, meant only for your eyes (I meant *private* key :) )that
>> nobody else can decode (given they’ve not compromised your private key).
>>
>> The fact that the SKS network had been and probably will still be
>> abused/DoSed/etc. we can’t deny, but once people becomes silly, as I see this
>> whole GDPR discussions have been, I have but one set of advice: Either you
>> fix it, or you get out of the SKS server network… let those that run the SKS
>> servers have the pains/legal battles/etc. when they are attacked by the GDPR
>> enforcers, we’ll fight that battle, no need to make our lives worse off if
>> you can’t add positive value…
>>
>> Yours enjoying his pop-corn reading these debates
>
> O.k. let's forget for a moment the GDPR.
>
> Would you or any other SKS operator in 2019 agree that a person should
> have the right that his / her public key can be removed from the SKS
> network if he / she asks for?
The method to do that, is to have a valid period, and then before the valid period expires, the user can resign a new
key with the old key, or he/she/they/them/whatever could just let that expire.

The user that want that key to be removed, either doesn’t understand the principles/ideas of the need/use for the
PUBLICLY available public keys, or is hiding something that they shouldn’t have done in the first place.

> An example: You have children and you recommend as an privacy advocate
> and parent that your minors should use PGP.

> A nasty classmate signs your daughters pub key with bad things. Teenagers
> usually smarter than their parents may not handle such a situation well,
> like us old PGP farts.

Well, the   “bad” things, and the “sign” is a method to prosecute (with quite a high confidence level) the guilty party
to the point where the punishment should be a deterrent enough for future bullies to be fearful of.

The specifics is (a) an indication of a badly educated bully, and (b) a bad family structure of the victim (Personal points of views and beliefs)
that gets worsened by the facts that the guilty aren’t properly punished, (We have police states, but the criminals have more rights than the civilians
that can’t even protect themselves against the perpetrators with enough force to deter the perpetrators ;( )

Things like GDPR are nice “laws”, but a toothless setup other than a monetary slap on the wrists for the big guys.

> Please explain in 2019 to you friends, wishing to learn secure email
> communications, that they should use PGP, while everybody can sign
> their pub key with arbritary  (and illegal) data, thanks to SKS.

The signature is a indication of who knows you, and SKS is a mechanism, not the only mechanism to setup a web of trusts

> They will for sure show you a stinking finger.

You aren’t forced to be part of, nor use, the SKS.

> A public key in 2019 does not mean that it can be used for nasty
> things, while a public key holder can not defend him  / her self!

I may have an outer wall that get’s grafiti all the time… I can’t protect that every single minute of the day…
but I can proof it is my home given the fact that only I have a set of keys that will open the (full of grafiti) garage door!!

that public key’s “signing” is the perpetrator that acknowledges it’s my key, even if/when he/she/they/them/whatever
put horrible things on it, they are still the ones that can be shown as the ones that did it…

> May I ask why you SKS operators did not implemented GnuPG's
> feature the --no-modifiy flag? It is not a brand new feature …

Perhaps as it’s not running GnuPG/pgp inside the SKS key servers ;)
SKS is just a mechanism to share (decentralized) a blob of data with a random number ID


— Hendrik

_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: The pool is shrinking

Stefan Claas
In reply to this post by Ryan Hunt-3
Ryan Hunt wrote:

> Its quite simple really, you sign a revocation of the key and create a new
> one, just like you'd do if you ever suspected your private key had been
> compromised.

Excuse me, I can't follow you (maybe a language barrier from my side).

If something nasty or bad sticks on my pub key people later can see
this, regardless if the key is revoked or not. They maybe simply assume
that the writing on my key is true? or false? because I can't get rid
of such nasty or false claims.

Like I said I can handle this as old fart, but you can't expect this
from other people, new to the PGP/SKS ecosystem.

Regards
Stefan

--
box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56
GPG: C93E252DFB3B4DB7EAEB846AD8D464B35E12AB77 (avail. on Hagrid, WKD)

_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

Re: The pool is shrinking

Stefan Claas
In reply to this post by H Visage
Hendrik Visage wrote:

> > On 16 Aug 2019, at 23:29 , Stefan Claas <[hidden email]> wrote:

> > Please explain in 2019 to you friends, wishing to learn secure email
> > communications, that they should use PGP, while everybody can sign
> > their pub key with arbritary  (and illegal) data, thanks to SKS.
>
> The signature is a indication of who knows you, and SKS is a mechanism, not
> the only mechanism to setup a web of trusts

??? Mr. or Mrs. X signs my pub key, put some 'funny stuff' on it, without
my knowledge and I should know these people? Or look at prominent people's
keys with lots of sigs, while the key holder does not sign back ... Do
you think that those prominent key holders know the signers, or could
it be the case that those are only fan sigs, bringing no weight to the
WoT?

> > They will for sure show you a stinking finger.
>
> You aren’t forced to be part of, nor use, the SKS.

Correct. I recently saw that my current pub key was uploaded, while
I am no longer part of SKS. Others may think that I am still using
SKS. :-(
 

> > A public key in 2019 does not mean that it can be used for nasty
> > things, while a public key holder can not defend him  / her self!
>
> I may have an outer wall that get’s grafiti all the time… I can’t protect
> that every single minute of the day… but I can proof it is my home given the
> fact that only I have a set of keys that will open the (full of grafiti)
> garage door!!
>
> that public key’s “signing” is the perpetrator that acknowledges it’s my key,
> even if/when he/she/they/them/whatever put horrible things on it, they are
> still the ones that can be shown as the ones that did it…

??? Then please tell us who did the 'funny' sigs on Facebook's pub key.

> > May I ask why you SKS operators did not implemented GnuPG's
> > feature the --no-modifiy flag? It is not a brand new feature …
>
> Perhaps as it’s not running GnuPG/pgp inside the SKS key servers ;)

Mmmhhh ... and nobody liked to tackle this issue ...

> SKS is just a mechanism to share (decentralized) a blob of data with a random
> number ID

Yes, unfortunately.

Regards
Stefan





--
box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56
GPG: C93E252DFB3B4DB7EAEB846AD8D464B35E12AB77 (avail. on Hagrid, WKD)

_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

GDPR (equine corpse) (WAS: Re: The pool is shrinking)

brent s.
SO for starters, please keep this off the "pool is shrinking" thread.
I'd like to see that thread relevant to resolving resiliency issues of
the SKS network, given that's the actual purpose behind starting that
thread. GDPR is off-topic to that thread and, quite frankly, it's
getting *extremely* annoying seeing GDPR bickering in a thread I'm
trying to follow for technical solutions to an actual technical problem.

There are countless threads hrmming and hawwing about GDPR on this list.
Because frankly, there's no answer that's going to make everyone happy -
largely due to a vast misunderstanding both about how HKP(S) and SKS
*work*, what the GDPR actually *says*, and its actual functional *limits*.

That said, these are indisputable *facts*:

1.) The GPG/PGP/OpenPGP[0] Web-of-Trust model and SKS network are
designed to:

   a.) be DECENTRALIZED.

   b.) be a *PUBLIC* SERVICE.

   c.) have immutable keys and signatures (keys and signatures are
designed to be tamper-proof, or at the LEAST tamper-evident), and

   d.) have keys *unable to be removed*, only revoked. The syncing
protocol simply *does not* allow this, and there are numerous posts
explaining why. There is plenty of theory as to why allowing this would
be bad practice as well, none of which have to do with GDPR - they are
purely cryptographic theory applications in nature.

2.) Dumps are considered best-practice (nay, operationally required) to
turn up a new keyserver.

   a.) Just as individual keyserver operators have deltas that vary from
the pool, so will their keydumps.

   b.) This, dumps will be different from keyserver to keyserver.

   c.) As pointed out, dumps are a great boon especially to maintaining
keyservers in political climates that may be hostile to GPG concepts. As
such, enforcing a requirement of positive personal identification
*simply* to fetch the dump is antithetical to that purpose, as it puts
said would-be operator at risk.

3.) The purpose of keyservers is for users to *look up and fetch a
(public) key*.

4.) *Real* identifiable personal information is by *no means* a
requirement for the creation of a key, nor making it available on a
keyserver. Granted, you're going to face some challenges at a
traditional keysigning party, but simply


Now for the GDPR relevance.

All of the attributes of point #1 are *required* to have a system that
keeps key integrity. There's a lot of talk about Keybase, but they're a
third party and they are a single point of control. They may *say*
they're GDPR-compliant, and they may *appear* to be GDPR-compliant, but
what guarantee can be provided that they aren't providing this
information to law enforcement/other government agencies/business/the
like? GDPR proponents put *far* too much faith in a piece of paper.
Sure, the Keybase software is open source. The entity, Keybase.io, is
not (and as such, so are its operations). I have nothing against Keybase
the entity. I like them. They've done great things for public crypto.
That doesn't mean I necessarily trust them (which is why I refuse to use
my private key with them; I do it all through GPG pipes - I may not know
the entirety of my system and the code that runs on it, but I know my
system and the code that runs on it better than I do Keybase).

Additionally, Keybase provides no safeguard against data harvesting. You
can go to any user's profile, copy their ASCII-armored public key by
clicking on the key fingerprint, and piping that into "gpg
--list-packets". Tada. You now have the same info you would on any SKS
server. Which brings me to my next point...

Putting your faith entirely in GDPR is a grave mistake, because
something (as shown) can be GDPR-compliant and lead one entirely to put
MORE faith in something despite there being no reason to, thus exposing
MORE of your own information. A piece of paper will not fix bad OPSEC.
Period. If you have a risk model where the information you attach to a
key is an issue, that is - quite frankly - a "you" problem and you
shouldn't be creating keys that can be tied to your identity.

For the armchair lawyers, the actual offical text of the GDPR can be
found here[1a] with a slightly more navigation-friendly interface
here[1b].[2]

Take special notice of Article 89[3].

This means not only are keydumps allowed for research (§2), but the SKS
in general (ESPECIALLY US servers and operators, which I'll get to in a
moment) is exempt - we provide "...archiving purposes in the public
interest" (§3). Frankly put, we make GPG *work*. GPG is a *very*
valuable public tool - zero-trust-model public cryptography is
impossible without the Web-of-Trust. Ergo, exempt. It's that simple. I
notice I'm the only one actually referencing the GDPR so far in this
discussion instead of what the nominal "I" *think* it means. Read it
sometime if you're going to concern-troll over it.

IANAL, but only one person in this discussion has mentioned that they
HAVE consulted one that specializes in data privacy - who confirms that
specifically, for a US keyserver operator operating a US keyserver, GDPR
has *absolutely no bearing* even if we *weren't* exempt. Just as the
DMCA has no bearing in, say, GB or CN as it is US legislature, so does
the GDPR not have any bearing in the US as it is EU legislature. A US
business' *EU presence* may be threatened by GDPR, but not the US entity
itself.

Lastly, enough with the strawmanning. Of *course* people are concerned
with privacy. *We wouldn't be running keyservers if we weren't.*[4] We
recognize the technological *requirements* of public cryptography, and
we recognize that quite frankly the GDPR has no bearing on them.
Frankly, the attempt to question their concern for privacy simply
because they don't support a certain legislation *that isn't even
enforceable on them* is transparently disgusting, juvenile,
thick-headed, and frankly has no place on this list.

Now. Can we actually talk about USEFUL things, like an SKS rewrite or
HKP(S) overhaul?

Thanks.


[0] I will use the generic term "GPG" moving forward to refer to the
OpenPGP standards and protocols, GPG, HKP(S), etc.
[1][a]
https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0679&from=EN
   [b] https://gdpr-info.eu/
[2] I am not associated with any of the mentioned/referenced/linked-to
organization(s)/firm(s).
[3] https://gdpr-info.eu/art-89-gdpr/
[4] And yes, this includes the blatant "think of the/your children"
attempt as well. This is no less than an attempt at emotional
manipulation, and will not be tolerated in civil discussion.


On 8/16/19 18:24, Stefan Claas wrote:

> Hendrik Visage wrote:
>
>>> On 16 Aug 2019, at 23:29 , Stefan Claas <[hidden email]> wrote:
>
>>> Please explain in 2019 to you friends, wishing to learn secure email
>>> communications, that they should use PGP, while everybody can sign
>>> their pub key with arbritary  (and illegal) data, thanks to SKS.
>>
>> The signature is a indication of who knows you, and SKS is a mechanism, not
>> the only mechanism to setup a web of trusts
>
> ??? Mr. or Mrs. X signs my pub key, put some 'funny stuff' on it, without
> my knowledge and I should know these people? Or look at prominent people's
> keys with lots of sigs, while the key holder does not sign back ... Do
> you think that those prominent key holders know the signers, or could
> it be the case that those are only fan sigs, bringing no weight to the
> WoT?
>
>>> They will for sure show you a stinking finger.
>>
>> You aren’t forced to be part of, nor use, the SKS.
>
> Correct. I recently saw that my current pub key was uploaded, while
> I am no longer part of SKS. Others may think that I am still using
> SKS. :-(
>  
>>> A public key in 2019 does not mean that it can be used for nasty
>>> things, while a public key holder can not defend him  / her self!
>>
>> I may have an outer wall that get’s grafiti all the time… I can’t protect
>> that every single minute of the day… but I can proof it is my home given the
>> fact that only I have a set of keys that will open the (full of grafiti)
>> garage door!!
>>
>> that public key’s “signing” is the perpetrator that acknowledges it’s my key,
>> even if/when he/she/they/them/whatever put horrible things on it, they are
>> still the ones that can be shown as the ones that did it…
>
> ??? Then please tell us who did the 'funny' sigs on Facebook's pub key.
>
>>> May I ask why you SKS operators did not implemented GnuPG's
>>> feature the --no-modifiy flag? It is not a brand new feature …
>>
>> Perhaps as it’s not running GnuPG/pgp inside the SKS key servers ;)
>
> Mmmhhh ... and nobody liked to tackle this issue ...
>
>> SKS is just a mechanism to share (decentralized) a blob of data with a random
>> number ID
>
> Yes, unfortunately.
>
> Regards
> Stefan
>
>
>
>
>

--
brent saner
https://square-r00t.net/
GPG info: https://square-r00t.net/gpg-info


_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel

signature.asc (916 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: GDPR (equine corpse) (WAS: Re: The pool is shrinking)

Robert J. Hansen-3
> IANAL, but only one person in this discussion has mentioned that they
> HAVE consulted one that specializes in data privacy - who confirms that
> specifically, for a US keyserver operator operating a US keyserver, GDPR
> has *absolutely no bearing* even if we *weren't* exempt.

Minor nit: that was the advice I received, tailored to my specific
situation.  Other US-based operators in different situations may have
different legal exposure.  The more connections a US operator has to the
EU, the greater the EU's ability to apply leverage.


_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel

signature.asc (837 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: GDPR (equine corpse) (WAS: Re: The pool is shrinking)

Stefan Claas
In reply to this post by brent s.
brent s. wrote:

> 4.) *Real* identifiable personal information is by *no means* a
> requirement for the creation of a key, nor making it available on a
> keyserver. Granted, you're going to face some challenges at a
> traditional keysigning party, but simply

How about email submission like we had in the '90s and getting
rid of --send-keys or the WWW submit button?

I believe installing postfix or exim etc. can be easily done
by operators and a person could quickly write a script which
then pipes the received keys to the database.

Regards
Stefan

--
box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56
GPG: C93E252DFB3B4DB7EAEB846AD8D464B35E12AB77 (avail. on Hagrid, WKD)

_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

Re: GDPR (equine corpse) (WAS: Re: The pool is shrinking)

brent s.
On 8/17/19 8:08 AM, Stefan Claas wrote:

> brent s. wrote:
>
>> 4.) *Real* identifiable personal information is by *no means* a
>> requirement for the creation of a key, nor making it available on a
>> keyserver. Granted, you're going to face some challenges at a
>> traditional keysigning party, but simply
>
> How about email submission like we had in the '90s and getting
> rid of --send-keys or the WWW submit button?
>
> I believe installing postfix or exim etc. can be easily done
> by operators and a person could quickly write a script which
> then pipes the received keys to the database.
>
> Regards
> Stefan
>
I'm going to anticipate what you're suggesting this solves - that only
key owners can upload their own key by ensuring the sender matches one
of the key's identities. There's flaws with that:

1.) You've now broken the ability to upload keys with no real
identifiable information (i.e. no real email address), thus *forcing*
users of a keyserver to provide personal identifiable information. This
breaks anonymity.

2.) Key signatures (key signatures are called "certifications" in the
design documentation) are now broken since signers cannot upload key
signatures, breaking the Web-of-Trust. When you upload a certification,
you are uploading the updated public key. You can strip certifications
from a key, you can't strip a key from certifications. See RFC 4880[0] §
11.1[1]. Actually, read the whole RFC. It's insightful and gives a lot
of knowledge into the output from "gpg --list-packets".

   a.) inb4 "But why can't the signer just send the updated key to the
key owner, and the owner can upload it?"

       See #1. While I have this feature in a keysigning tool I wrote[2]
(which is currently incredibly messy and needs a major refactoring, I
know), it still only works if the signed key has a valid email address
and it furthermore would still require a valid email address by the
owner to upload to a keyserver if email addresses were received by mail
(even if the signed key was passed to the owner via a previously agreed
upon non-email/alternate email communication).

   b.) Remember, key signatures are intended for public consumption -
it's how trust is arbitrated via the Web-of-Trust so you can apply trust
levels to keys that you yourself have not been able to directly verify
with the owner. The Web-of-Trust is not flat, it's by degrees (e.g. "Bob
signed Alice's key, and I trust Bob's veracity in checking validity of
key ownership completely because I know how thorough he is, so I can
apply a medium level of trust to this key locally" - which also, thanks
to the Web-of-Trust, allows others to trust Alice AND Bob's key because
you trust Bob.[3]

   c.) Similarly, this also requires the *signer* to expose a real email
address to the owner of the key they signed at the LEAST, breaking the
*signer's* option for anonymity (and requires that at LEAST the key
owner know beforehand which communication identity the signed key is
coming from).

3.) This also depends further on an MTA being run on keyservers (or at
the least in tandem with them by the same operator). Running a mail
server is not a demand to be made lightly on anyone, given that mail is
a quagmire that the inexperienced should not approach lightly. There's a
reason that many places have a single operator designated entirely to
the maintenance of their email.



[0] https://tools.ietf.org/html/rfc4880
[1] https://tools.ietf.org/html/rfc4880#section-11.1
[2] https://git.square-r00t.net/OpTools/tree/gpg/kant
[3] https://www.gnupg.org/gph/en/manual/x547.html
    (pay close attention to paragraphs 3 and 4)

--
brent saner
https://square-r00t.net/
GPG info: https://square-r00t.net/gpg-info


_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel

signature.asc (916 bytes) Download Attachment
12345