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

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

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

> 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

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

> 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". >

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

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.

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

> 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

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

> 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

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

> > 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

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

> 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

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

> > 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,

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

> 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

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

> 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

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

> 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

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

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

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

> 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

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

> 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

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

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

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

> 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

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

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

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

> 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

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

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

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

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

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

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 >

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

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