heads-up: another attack tool, using SKS as FS

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

heads-up: another attack tool, using SKS as FS

Phil Pennock-17
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
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel

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

Re: 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, <[hidden email]> 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
[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: heads-up: another attack tool, using SKS as FS

Ryan Hunt-3
In reply to this post by Phil Pennock-17
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 <[hidden email]> 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
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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
> [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: 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel


_______________________________________________
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: heads-up: another attack tool, using SKS as FS

Ryan Hunt-3
In reply to this post by Tobias Frei
So when you respond back to the server with your token we simply check that your a human being.. also throttling and delays could be put in place to mitigate the effects of someone breaking past the bot detection as far as spam is concerned.. I’m not concerned with people putting private info in personally, just negating silly detail of service tactics like we are seeing here.

-Ryan

> On Jul 13, 2018, at 8:50 PM, Tobias Frei <[hidden email]> 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 <[hidden email]> 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
>> [hidden email]
>> https://lists.nongnu.org/mailman/listinfo/sks-devel
>
> _______________________________________________
> 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: heads-up: another attack tool, using SKS as FS

Ryan Hunt-3
In reply to this post by Tom at FlowCrypt
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel


_______________________________________________
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


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

Re: heads-up: another attack tool, using SKS as FS

Robert J. Hansen-3
> 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
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

Re: heads-up: another attack tool, using SKS as FS

Ryan Hunt-3
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 <[hidden email]> 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
> [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: heads-up: another attack tool, using SKS as FS

Tom at FlowCrypt
In reply to this post by Robert J. Hansen-3
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 <[hidden email]> 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
[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: heads-up: another attack tool, using SKS as FS

Robert J. Hansen-3
In reply to this post by Ryan Hunt-3
> 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
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

Re: heads-up: another attack tool, using SKS as FS

Gabor Kiss
In reply to this post by Ryan Hunt-3
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
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

Re: heads-up: another attack tool, using SKS as FS

Robert J. Hansen-3
> 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 [hidden email] 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 [hidden email] 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
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

Re: heads-up: another attack tool, using SKS as FS

Andrew Gallagher
In reply to this post by Ryan Hunt-3

> On 14 Jul 2018, at 01:57, Ryan Hunt <[hidden email]> 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
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

Re: heads-up: another attack tool, using SKS as FS

Andrew Gallagher
In reply to this post by Robert J. Hansen-3

On 14 Jul 2018, at 04:37, Robert J. Hansen <[hidden email]> 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.

It depends on what we believe keyservers are for. If they are a method for obtaining a complete key by looking up a user ID, then you’re right, it’s a non starter. But I don’t believe that’s what keyservers should be for any more, because I don’t believe that can be done without abuse.

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.

A

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

Re: heads-up: another attack tool, using SKS as FS

Robert J. Hansen-3
> 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
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

Re: heads-up: another attack tool, using SKS as FS

Human at FlowCrypt
In reply to this post by Andrew Gallagher
> > 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 <[hidden email]> wrote:

> On 14 Jul 2018, at 01:57, Ryan Hunt <[hidden email]> 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
[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: heads-up: another attack tool, using SKS as FS

Robert J. Hansen-3
> 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
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

Re: 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
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

Re: heads-up: another attack tool, using SKS as FS

Tom at FlowCrypt
In reply to this post by Robert J. Hansen-3
> 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 <[hidden email]> 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
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel

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