Re: [Sks-devel] heads-up: another attack tool, using SKS as FS

[Jeremy T. Bouse]

On 7/14/2018 9:42 AM, Hendrik Visage wrote:
>
>
>> On 14 Jul 2018, at 13:04 , Gabor Kiss > > wrote:
>>
 Then let's drop keys that don't contain a valid email address in
 the key id.
>>>
>>> How do you propose to validate the email address?
>>>
>>> (Hint: this is a surprisingly hard problem.)
>>
>> See also "web of trust" and "strong set".
>> Addresses should/can be checked by humans worldwide who sign/certify
>> the key.
>
> I’ve been trying to get mine “signed” by Web-Of-Trust for years now…
> also not that “easy” ;(
>
    Find a local Debian Developer... Most of the Debian Developers are
part of the strong set and they're all over the globe.
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] heads-up: another attack tool, using SKS as FS

[Hendrik Visage]

> On 14 Jul 2018, at 13:27 , Tom at FlowCrypt  wrote:
> 
> > How do you propose to validate the email address?
> 
> I'm using a library to parse the uid as email, name and a comment. For the 
> email, I'm using a very, very long regex. Of the 5M keys available in SKS 
> dumps, very few uids are miscategorized.
> 
> It may be hard to do with 100% accuracy, but it's unsurprisingly easy do well 
> enough.

The words “machine learning” comes to mind… wonder if somebody with 
Amazon/Google/Azure contacts might be able to reach out and ask for 
sponsorship???


---
Hendrik Visage
HeViS.Co Systems Pty Ltd
T/A Envisage Systems / Envisage Cloud Solutions
+27-84-612-5345 or +27-21-945-1192
hvis...@envisage.co.za





signature.asc
Description: Message signed with OpenPGP
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] heads-up: another attack tool, using SKS as FS

[Hendrik Visage]

> On 14 Jul 2018, at 13:04 , Gabor Kiss  wrote:
> 
>>> Then let's drop keys that don't contain a valid email address in the key id.
>> 
>> How do you propose to validate the email address?
>> 
>> (Hint: this is a surprisingly hard problem.)
> 
> See also "web of trust" and "strong set".
> Addresses should/can be checked by humans worldwide who sign/certify the key.


I’ve been trying to get mine “signed” by Web-Of-Trust for years now… also not 
that “easy” ;(

---
Hendrik Visage
HeViS.Co Systems Pty Ltd
T/A Envisage Systems / Envisage Cloud Solutions
+27-84-612-5345 or +27-21-945-1192
hvis...@envisage.co.za





signature.asc
Description: Message signed with OpenPGP
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] heads-up: another attack tool, using SKS as FS

[Human at FlowCrypt]

Thanks Andrew for pointing it out. We could grandfather such keys if their
uid length fits within a limit (256 bytes?). But do not return such keys in
search results, except when searched directly by fingerprint or longid.

Newly uploaded keys without valid uid email address would not be accepted.

Speaking of preventing abuse, only email addresses and key ids should get
indexed for search, and only strict match should be allowed.

On Sat, Jul 14, 2018, 19:30 Andrew Gallagher  wrote:

>
> > On 14 Jul 2018, at 09:34, Human at FlowCrypt 
> wrote:
> >
> > > > Could this be mitigated by validating email addresses as they come
> in?
> >
> > > No, because ID fields are not required to be email addresses.
> >
> > Then let's drop keys that don't contain a valid email address in the key
> id.
>
> You do realise that the largest use case for PGP keys is package
> distribution, and many well known package distributors deliberately use
> signing keys with no email address?
>
> A
>
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] heads-up: another attack tool, using SKS as FS

[Andrew Gallagher]

> On 14 Jul 2018, at 09:34, Human at FlowCrypt  wrote:
> 
> > > Could this be mitigated by validating email addresses as they come in?
> 
> > No, because ID fields are not required to be email addresses. 
> 
> Then let's drop keys that don't contain a valid email address in the key id.

You do realise that the largest use case for PGP keys is package distribution, 
and many well known package distributors deliberately use signing keys with no 
email address?

A

___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] heads-up: another attack tool, using SKS as FS

[Tom at FlowCrypt]

> How do you propose to validate the email address?

I'm using a library to parse the uid as email, name and a comment. For the
email, I'm using a very, very long regex. Of the 5M keys available in SKS
dumps, very few uids are miscategorized.

It may be hard to do with 100% accuracy, but it's unsurprisingly easy do
well enough.


On Sat, Jul 14, 2018, 18:37 Robert J. Hansen  wrote:

> > Then let's drop keys that don't contain a valid email address in the key
> id.
>
> How do you propose to validate the email address?
>
> (Hint: this is a surprisingly hard problem.)
>
> ___
> Sks-devel mailing list
> Sks-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/sks-devel
>
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] heads-up: another attack tool, using SKS as FS

[Gabor Kiss]

> > Then let's drop keys that don't contain a valid email address in the key id.
> 
> How do you propose to validate the email address?
> 
> (Hint: this is a surprisingly hard problem.)

See also "web of trust" and "strong set".
Addresses should/can be checked by humans worldwide who sign/certify the key.

Gabor

___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] heads-up: another attack tool, using SKS as FS

[Robert J. Hansen]

> Then let's drop keys that don't contain a valid email address in the key id.

How do you propose to validate the email address?

(Hint: this is a surprisingly hard problem.)

___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] heads-up: another attack tool, using SKS as FS

[Human at FlowCrypt]

> > Could this be mitigated by validating email addresses as they come in?

> No, because ID fields are not required to be email addresses.

Then let's drop keys that don't contain a valid email address in the key id.

We should want to solve this, not stick our heads in the sand.

On Sat, Jul 14, 2018, 14:56 Andrew Gallagher  wrote:

>
> > On 14 Jul 2018, at 01:57, Ryan Hunt  wrote:
> >
> > Could this be mitigated by validating email addresses as they come in?
>
> No, because ID fields are not required to be email addresses.
>
> A
>
> ___
> Sks-devel mailing list
> Sks-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/sks-devel
>
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] heads-up: another attack tool, using SKS as FS

[Robert J. Hansen]

> I think the time has come where we have to re-evaluate what the
> keyservers are *for*. Once we answer that, we answer what should be
> done about it.

I agree, although I think maybe you're not taking it far enough.

What threats should we be defending against?

The original idea of a keyserver network came out of the early 1990s.
It was the product of that vision -- where even liberal democracies of
the West were tightly controlling crypto and the general belief was that
even nations like the US and UK might make it illegal to use strong
crypto.  We also believed governments would try to coerce keyserver
operators into cooperating with man-in-the-middle attacks, and that
keyservers would be high-value targets because they were the principal
way people could look up certificates.

This vision informed pretty much every single engineering decision that
went into the keyserver network.  It is still the vision influencing the
keyserver network today.

It is also, as near as I can tell, batshit nonsense.  AFAIK, _no_
keyserver operator in the West has ever been served with a court
instrument compelling cooperation with MITM attacks or removing a key
from the server or whatever.  In 26 years this fear has literally never
come to pass.

Maybe we should rethink our threat model.

___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] heads-up: another attack tool, using SKS as FS

[Andrew Gallagher]

> On 14 Jul 2018, at 01:57, Ryan Hunt  wrote:
> 
> Could this be mitigated by validating email addresses as they come in?

No, because ID fields are not required to be email addresses. 

A

___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] heads-up: another attack tool, using SKS as FS

[Robert J. Hansen]

> In the new era key owners have to proof their identity. Practically
> speaking key servers accept only keys belonging to the strong set.
> (At least in first step.)

Who says the next technology needs to be key servers?  That seems like
an assumption worth challenging.

I'm not throwing this out as a completed idea.  About twelve years ago I
looked into something that could be used as a replacement keyserver
technology; it went as far as me preparing a grant proposal to look into
it further.  Unfortunately, I no longer have the paper.  :(  Working off
half-remembered memories:

=

Joke was the "Jabber-oriented key exchanger".  The idea was to have an
XMPP bot which could remember key submissions, respond to queries, and
send notifications.  Alice might start by telling Joke, "I control key
0xDEADBEEF, which I've enclosed in this message."  Joke would send back
a 128-bit base-64 random challenge for Alice to sign and send back.  If
Alice did, her public key would get entered into a database with indexes
of both Alice's JabberID (JID), the key's fingerprint, the last time
Alice connected, and so on.  Alice could of course put additional user
IDs on the key, and Joke was free to store as many or as few of them as
it wished or apply whatever standards were necessary.

Bob would then send a message to Joke.  "When al...@example.org updates
her cert, please send the update to this JID."  So when later on Alice
updates her key and sends it on to Joke, not only does Joke update its
record in its database but it also informs b...@example.com about the
change.  When Bob's Jabber agent receives the message, it updates Bob's
local keystore.  Presto: we've solved the problem of ensuring key
updates are distributed in a timely fashion (which SKS never solved, nor
even attempted to).

If a user doesn't connect to Joke for three years, the user's account
(and keys) are deleted; this helps prevent cruft from building up on the
servers.

Joke servers can be kept in sync without resorting to special-case
technology.  Distributed database replication is a pretty
well-established discipline.  Two Joke servers with MySQL backends?
Pretty easy.

What this would destroy is *untrusted* federation.  In a distributed
MySQL database, nodes need to be able to trust that others aren't
malicious.  Federated Joke is possible, but requires trust between
instances -- but that's manageable, really.  I think you could imagine a
federation of university-sponsored Joke servers that would have local
points-of-presence on almost every continent.

=

Don't get me wrong: this is nowhere near a ready-for-implementation
idea.  (It was once upon a time, but once upon a time was a long time
ago, and this outline is all I remember off the top of my head.)  But it
should hopefully go to show you that we don't *have* to repeat the
architecture of the SKS network.  We can do things differently.  Any
discussion about an SKS replacement that doesn't start from a completely
blank sheet is, IMO, starting off wrong.

___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] heads-up: another attack tool, using SKS as FS

[Kiss Gabor (Bitman)]

On Fri, 13 Jul 2018, Ryan Hunt wrote:

> Sooner or later you guys need
> start looking forward, if mistakes were made in the past ignoring them is not
> going to solve anything.

> Ignore the users, your the sysops.. Either SKS will die, or the entire thing
> is going to have to be scrapped and redesigned with something that can permit
> removal of keys, or drop all support for images and start validating key
> holders.. none are ideal, but one is pretty clearly better than the others to
> me.


My 2 cents.

The current infrastructure must be wiped out. It is a dead duck.

In the new era key owners have to proof their identity. Practically
speaking key servers accept only keys belonging to the strong set.
(At least in first step.)
Moreover key owners must add an UID with this text:

"I want this key to be provided by public databases.
I understand and I agree that it cannot be deleted any more."

And yes. Key servers have to do cryptographic operations.

Later, when we find a sophisticated algorithm, key deletion could be
triggered by adding another properly signed UID:

"I want this key to be deleted from public databases.
Thanks guys for your efforts. :-)"

Regards

Gabor

___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] heads-up: another attack tool, using SKS as FS

[Robert J. Hansen]

> Does a user revolt even matter as the SKS pool is dismantled by
> continuous attacks?

"We had to burn the village in order to save it!", I see.

There are three questions:

1.  Can SKS be saved?
2.  If so, how?
3.  If not, what next?

I believe the answers are "no", "N/A", and "I don't know yet."

If you're pitching a "let's drop all photo IDs", you're in effect
answering them "no", "N/A", and "let's make sure dropping photo IDs are
part of the next spec".  Which may be a good idea, don't get me wrong,
but it's not part of a saving-SKS discussion.

___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] heads-up: another attack tool, using SKS as FS

[Tom at FlowCrypt]

> Is it possible without facing a user revolt?  No.

SKS does do key parsing though, and we could surely figure out just how big
the photo-id is in bytes. I suggest to impose a limit. Does it really need
to be any bigger than 10kB? My suggestion:

- impose a 10kB image size limit
- max one image per key
- max 20 uids per key
- max 1kb length per uid



On Sat, Jul 14, 2018 at 3:37 AM, Robert J. Hansen 
wrote:

> > IMHO Photo-ID should be dropped entirely, I see no point and its just
> > ripe for abuse like this..
>
> Unfortunately, we really can't.  They've been part of OpenPGP
> certificates for just about twenty years now.  They are an expected part
> of the certificate.  Users already scream bloody murder about GnuPG and
> Enigmail dropping support for SE packets and those have been deprecated
> since 2003.  The idea of just waving a wand and getting rid of a
> non-deprecated part of a public key is just ... no.
>
> Is it technically possible?  Yes.  But it would require a significant
> amount of redesign: we'd have to parse out the key, recognize images,
> drop them, etc.  Right now SKS does *zero* cryptographic verification of
> the key data; we'd need to change SKS to introduce at least some crypto
> support.
>
> Is it possible without facing a user revolt?  No.
>
> ___
> Sks-devel mailing list
> Sks-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/sks-devel
>
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] heads-up: another attack tool, using SKS as FS

[Ryan Hunt]

Does a user revolt even matter as the SKS pool is dismantled by continuous 
attacks?

I think a significant amount of redesign is required to save the SKS network at 
this point, the crusades against SKS have just been ratcheting up and they are 
winning IMO, I dropped my server from the pool eons ago because of how much 
time was required to keep my server alive and healthy, it was like having a 
toddler that never ever grew up.. Sooner or later you guys need start looking 
forward, if mistakes were made in the past ignoring them is not going to solve 
anything.

Over a decade ago we were all discussing what would happen if child pornography 
was uploaded to the pool, and here we are still with our heads stuck in the 
sand.. IMHO its about time we just nuked that issue from orbit. Ignore the 
users, your the sysops.. Either SKS will die, or the entire thing is going to 
have to be scrapped and redesigned with something that can permit removal of 
keys, or drop all support for images and start validating key holders.. none 
are ideal, but one is pretty clearly better than the others to me.

-Ryan

> On Jul 13, 2018, at 9:37 PM, Robert J. Hansen  wrote:
> 
>> IMHO Photo-ID should be dropped entirely, I see no point and its just
>> ripe for abuse like this..
> 
> Unfortunately, we really can't.  They've been part of OpenPGP
> certificates for just about twenty years now.  They are an expected part
> of the certificate.  Users already scream bloody murder about GnuPG and
> Enigmail dropping support for SE packets and those have been deprecated
> since 2003.  The idea of just waving a wand and getting rid of a
> non-deprecated part of a public key is just ... no.
> 
> Is it technically possible?  Yes.  But it would require a significant
> amount of redesign: we'd have to parse out the key, recognize images,
> drop them, etc.  Right now SKS does *zero* cryptographic verification of
> the key data; we'd need to change SKS to introduce at least some crypto
> support.
> 
> Is it possible without facing a user revolt?  No.
> 
> ___
> Sks-devel mailing list
> Sks-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/sks-devel


___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] heads-up: another attack tool, using SKS as FS

[Robert J. Hansen]

> IMHO Photo-ID should be dropped entirely, I see no point and its just
> ripe for abuse like this..

Unfortunately, we really can't.  They've been part of OpenPGP
certificates for just about twenty years now.  They are an expected part
of the certificate.  Users already scream bloody murder about GnuPG and
Enigmail dropping support for SE packets and those have been deprecated
since 2003.  The idea of just waving a wand and getting rid of a
non-deprecated part of a public key is just ... no.

Is it technically possible?  Yes.  But it would require a significant
amount of redesign: we'd have to parse out the key, recognize images,
drop them, etc.  Right now SKS does *zero* cryptographic verification of
the key data; we'd need to change SKS to introduce at least some crypto
support.

Is it possible without facing a user revolt?  No.

___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] heads-up: another attack tool, using SKS as FS

[Ryan Hunt]

IMHO Photo-ID should be dropped entirely, I see no point and its just ripe for 
abuse like this.. We should not be relying on that w/cryptography.. If I’m 
going to sign your key and validate I know you then I should be validating your 
the holder of that private key with an exchange first (much like I am proposing 
with adding your key to SKS network).. then really what does it matter what 
image is stored with the public key after that since the private key holder 
could manipulate that. Honestly it was eons ago when I last went to a key 
signing, but the few I did go to back in my College days never required a photo 
in the public key.

-Ryan

> On Jul 13, 2018, at 9:01 PM, Tom at FlowCrypt  wrote:
> 
> > that would probably be an incomplete mitigation:
> 
> Sounds better than no solution!
> 
> > -people can use the photo id field instead
> 
> Size limit can be enforced.
> 
> > -people can use valid e-mail addresses under an own domain ("catch-all")
> 
> As long as it can validate, seems fine to me. Better than no verification.
> 
> > -your keyserver suddenly can be abused for email spamming
> 
> Any online service that allows registrations can be abused for email 
> spamming, if you consider registration emails an "email spam".
> 
> 
> 
> Another limitation: you cannot apply the email verification process to the 
> recon algo, because the user would get flooded with verification emails. That 
> means you could have a malicious SKS implementation flooding others with 
> non-verified emails. Again, not perfect, but a good start.
> 
> 
> 
> On Sat, Jul 14, 2018 at 2:50 AM, Tobias Frei  > wrote:
> Hi Ryan,
> 
> that would probably be an incomplete mitigation:
> 
> -people can use the photo id field instead
> -people can use valid e-mail addresses under an own domain ("catch-all")
> -your keyserver suddenly can be abused for email spamming
> 
> Best regards
> Tobias Frei
> 
> 
> 
> Am 14.07.2018 um 02:57 schrieb Ryan Hunt:
> Could this be mitigated by validating email addresses as they come in? Like 
> sending an encrypted mail to the said address with a return token, If the 
> token is not provided the key is never put into the SKS rotation?
> 
> I think a solution like this would be much more effective, and if there was 
> some desire to conform to GDPR at some point it would be pretty much required 
> first step because I cannot see how we could possibly remove keys without a 
> command signed by that key, and putting this in place would make that ‘no 
> more difficult to remove than it was to add’..
> 
> Regards,
> -Ryan Hunt
> 
> On Jul 13, 2018, at 11:20 AM, Phil Pennock  > wrote:
> 
> Signed PGP part
> Heads-up:
> 
> https://medium.com/@mdrahony/are-pgp-key-servers-breaking-the-law-under-the-gdpr-a81ddd709d3e
>  
> 
> https://github.com/yakamok/keyserver-fs 
> 
> https://lobste.rs/s/sle0o4/are_pgp_key_servers_breaking_law_under 
> 
> 
> This `keyserver-fs` is software to attack SKS, using it as a filesystem, in
> what appears to be a deliberate attack on the viability of continuing to
> run a keyserver.
> 
> The author is upset that there's no deletion, so is pissing in the pool.
> 
> -Phil
> 
> 
> 
> 
> ___
> Sks-devel mailing list
> Sks-devel@nongnu.org 
> https://lists.nongnu.org/mailman/listinfo/sks-devel 
> 
> 
> 
> ___
> Sks-devel mailing list
> Sks-devel@nongnu.org 
> https://lists.nongnu.org/mailman/listinfo/sks-devel 
> 
> 
> ___
> Sks-devel mailing list
> Sks-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/sks-devel

___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] heads-up: another attack tool, using SKS as FS

[Tom at FlowCrypt]

> that would probably be an incomplete mitigation:

Sounds better than no solution!

> -people can use the photo id field instead

Size limit can be enforced.

> -people can use valid e-mail addresses under an own domain ("catch-all")

As long as it can validate, seems fine to me. Better than no verification.

> -your keyserver suddenly can be abused for email spamming

Any online service that allows registrations can be abused for email
spamming, if you consider registration emails an "email spam".



Another limitation: you cannot apply the email verification process to the
recon algo, because the user would get flooded with verification emails.
That means you could have a malicious SKS implementation flooding others
with non-verified emails. Again, not perfect, but a good start.



On Sat, Jul 14, 2018 at 2:50 AM, Tobias Frei 
wrote:

> Hi Ryan,
>
> that would probably be an incomplete mitigation:
>
> -people can use the photo id field instead
> -people can use valid e-mail addresses under an own domain ("catch-all")
> -your keyserver suddenly can be abused for email spamming
>
> Best regards
> Tobias Frei
>
>
>
> Am 14.07.2018 um 02:57 schrieb Ryan Hunt:
>
>> Could this be mitigated by validating email addresses as they come in?
>> Like sending an encrypted mail to the said address with a return token, If
>> the token is not provided the key is never put into the SKS rotation?
>>
>> I think a solution like this would be much more effective, and if there
>> was some desire to conform to GDPR at some point it would be pretty much
>> required first step because I cannot see how we could possibly remove keys
>> without a command signed by that key, and putting this in place would make
>> that ‘no more difficult to remove than it was to add’..
>>
>> Regards,
>> -Ryan Hunt
>>
>> On Jul 13, 2018, at 11:20 AM, Phil Pennock 
>>> wrote:
>>>
>>> Signed PGP part
>>> Heads-up:
>>>
>>> https://medium.com/@mdrahony/are-pgp-key-servers-breaking-th
>>> e-law-under-the-gdpr-a81ddd709d3e
>>> https://github.com/yakamok/keyserver-fs
>>> https://lobste.rs/s/sle0o4/are_pgp_key_servers_breaking_law_under
>>>
>>> This `keyserver-fs` is software to attack SKS, using it as a filesystem,
>>> in
>>> what appears to be a deliberate attack on the viability of continuing to
>>> run a keyserver.
>>>
>>> The author is upset that there's no deletion, so is pissing in the pool.
>>>
>>> -Phil
>>>
>>>
>>>
>>
>> ___
>> Sks-devel mailing list
>> Sks-devel@nongnu.org
>> https://lists.nongnu.org/mailman/listinfo/sks-devel
>>
>>
> ___
> Sks-devel mailing list
> Sks-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/sks-devel
>
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] heads-up: another attack tool, using SKS as FS

[Tobias Frei]

Hi Ryan,

that would probably be an incomplete mitigation:

-people can use the photo id field instead
-people can use valid e-mail addresses under an own domain ("catch-all")
-your keyserver suddenly can be abused for email spamming

Best regards
Tobias Frei


Am 14.07.2018 um 02:57 schrieb Ryan Hunt:

Could this be mitigated by validating email addresses as they come in? Like 
sending an encrypted mail to the said address with a return token, If the token 
is not provided the key is never put into the SKS rotation?

I think a solution like this would be much more effective, and if there was 
some desire to conform to GDPR at some point it would be pretty much required 
first step because I cannot see how we could possibly remove keys without a 
command signed by that key, and putting this in place would make that ‘no more 
difficult to remove than it was to add’..

Regards,
-Ryan Hunt


On Jul 13, 2018, at 11:20 AM, Phil Pennock  wrote:

Signed PGP part
Heads-up:

https://medium.com/@mdrahony/are-pgp-key-servers-breaking-the-law-under-the-gdpr-a81ddd709d3e
https://github.com/yakamok/keyserver-fs
https://lobste.rs/s/sle0o4/are_pgp_key_servers_breaking_law_under

This `keyserver-fs` is software to attack SKS, using it as a filesystem, in
what appears to be a deliberate attack on the viability of continuing to
run a keyserver.

The author is upset that there's no deletion, so is pissing in the pool.

-Phil





___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel



___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] heads-up: another attack tool, using SKS as FS

[Ryan Hunt]

Could this be mitigated by validating email addresses as they come in? Like 
sending an encrypted mail to the said address with a return token, If the token 
is not provided the key is never put into the SKS rotation?

I think a solution like this would be much more effective, and if there was 
some desire to conform to GDPR at some point it would be pretty much required 
first step because I cannot see how we could possibly remove keys without a 
command signed by that key, and putting this in place would make that ‘no more 
difficult to remove than it was to add’..

Regards,
-Ryan Hunt

> On Jul 13, 2018, at 11:20 AM, Phil Pennock  
> wrote:
> 
> Signed PGP part
> Heads-up:
> 
> https://medium.com/@mdrahony/are-pgp-key-servers-breaking-the-law-under-the-gdpr-a81ddd709d3e
> https://github.com/yakamok/keyserver-fs
> https://lobste.rs/s/sle0o4/are_pgp_key_servers_breaking_law_under
> 
> This `keyserver-fs` is software to attack SKS, using it as a filesystem, in
> what appears to be a deliberate attack on the viability of continuing to
> run a keyserver.
> 
> The author is upset that there's no deletion, so is pissing in the pool.
> 
> -Phil
> 
> 


___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] heads-up: another attack tool, using SKS as FS

[Matthew Walster]

This is why we can't have nice things.

M

On Fri, 13 Jul 2018, 19:20 Phil Pennock, 
wrote:

> Heads-up:
>
>
> https://medium.com/@mdrahony/are-pgp-key-servers-breaking-the-law-under-the-gdpr-a81ddd709d3e
>  https://github.com/yakamok/keyserver-fs
>  https://lobste.rs/s/sle0o4/are_pgp_key_servers_breaking_law_under
>
> This `keyserver-fs` is software to attack SKS, using it as a filesystem, in
> what appears to be a deliberate attack on the viability of continuing to
> run a keyserver.
>
> The author is upset that there's no deletion, so is pissing in the pool.
>
> -Phil
> ___
> Sks-devel mailing list
> Sks-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/sks-devel
>
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

[Sks-devel] heads-up: another attack tool, using SKS as FS

[Phil Pennock]

Heads-up:

 
https://medium.com/@mdrahony/are-pgp-key-servers-breaking-the-law-under-the-gdpr-a81ddd709d3e
 https://github.com/yakamok/keyserver-fs
 https://lobste.rs/s/sle0o4/are_pgp_key_servers_breaking_law_under

This `keyserver-fs` is software to attack SKS, using it as a filesystem, in
what appears to be a deliberate attack on the viability of continuing to
run a keyserver.

The author is upset that there's no deletion, so is pissing in the pool.

-Phil


signature.asc
Description: Digital signature
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel