Re: [Sks-devel] withdrawal of service: sks.spodhuis.org

[Shengjing Zhu]

Hi Haw,

On Sun, Jul 15, 2018 at 9:17 AM Haw Loeung  wrote:
>
> On Fri, Jul 13, 2018 at 07:53:01PM +0100, Andrew Gallagher wrote:
> > I am still willing to help with possible upgrades and/or
> > replacements for the SKS network. At this point I have come to
> > believe that a minimal network containing only key material, SBINDs
> > and revocations (no id packets, no third party sigs) is the absolute
> > maximum functionality we can hope to sustain in the long term. And
> > for this to be bulletproof, all such material must be
> > cryptographically verified (otherwise people could just create
> > “random” key material containing arbitrary data).
>
> If it helps others, we have a patched SKS packaged to exclude the bad
> key (one of them at least)[1]. A couple of others in my team did all
> the work so I can't comment on the details.
>

Could you provide the patch on bitbucket[1], I'm not sure if Kristian
will accpet it or not.
But I'd like to see it in patch form and include it in my own build.

[1] https://bitbucket.org/skskeyserver/sks-keyserver/


-- 
Regards,
Shengjing Zhu

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

Re: [Sks-devel] withdrawal of service: sks.spodhuis.org

[Tom at FlowCrypt]

> Does anyone in the pool run hockeypuck? How compatible is its recon with
others running sks-keyserver?

Yes, here is one: http://keyserver.snt.utwente.nl

(see https://sks-keyservers.net/status/ and
http://keyserver.snt.utwente.nl:11371/pks/lookup?op=stats )

However, it was kicked out of the pool because "SKS version < 1.1.6" as per
https://sks-keyservers.net/status/ks-status.php?server=keyserver.snt.utwente.nl

It does seem to be syncing well - key diff 1,385 looks great to me even
compared to servers that are in the pool.

I'm adding Robert in copy in case he's able to share his experience running
the Hockeypuck server. Robert, if this email can reach you, We'd be
interested to know how is the server coping with recent issues that were
affecting the SKS network? How stable do you find Hockeypuck overall, how
much dev-ops do you need to do?




On Sun, Jul 15, 2018 at 1:21 AM, Haw Loeung 
wrote:

> On Sun, Jul 15, 2018 at 11:17:20AM +1000, Haw Loeung wrote:
> > On Fri, Jul 13, 2018 at 07:53:01PM +0100, Andrew Gallagher wrote:
> > > I am still willing to help with possible upgrades and/or
> > > replacements for the SKS network. At this point I have come to
> > > believe that a minimal network containing only key material, SBINDs
> > > and revocations (no id packets, no third party sigs) is the absolute
> > > maximum functionality we can hope to sustain in the long term. And
> > > for this to be bulletproof, all such material must be
> > > cryptographically verified (otherwise people could just create
> > > “random” key material containing arbitrary data).
> >
> > If it helps others, we have a patched SKS packaged to exclude the bad
> > key (one of them at least)[1]. A couple of others in my team did all
> > the work so I can't comment on the details.
> >
>
> I should also add, you'll then need to drop the key from the DB with:
>
> $ sks drop 8C070D00D81E934B3C79247175E6B4BC
>
>
> Regards,
>
> Haw
>
> ___
> 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] withdrawal of service: sks.spodhuis.org

[Haw Loeung]

On Fri, Jul 13, 2018 at 07:53:01PM +0100, Andrew Gallagher wrote:
> I am still willing to help with possible upgrades and/or
> replacements for the SKS network. At this point I have come to
> believe that a minimal network containing only key material, SBINDs
> and revocations (no id packets, no third party sigs) is the absolute
> maximum functionality we can hope to sustain in the long term. And
> for this to be bulletproof, all such material must be
> cryptographically verified (otherwise people could just create
> “random” key material containing arbitrary data).

If it helps others, we have a patched SKS packaged to exclude the bad
key (one of them at least)[1]. A couple of others in my team did all
the work so I can't comment on the details.

There's also work being done to spin up a few SKS servers to trial
hockeypuck.


Regards,

Haw


[1]https://launchpad.net/~canonical-sysadmins/+archive/ubuntu/sks-public


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

Re: [Sks-devel] withdrawal of service: sks.spodhuis.org

[Daniel Roesler]

Does anyone in the pool run hockeypuck? How compatible is its recon
with others running sks-keyserver?

Daniel

On Sat, Jul 14, 2018 at 5:52 AM, Human at FlowCrypt  wrote:
> One more apology - there does seem to be recent activity when you look at
> the repo owner: https://github.com/hockeypuck
>
> Though not loads of activity, still more code contributions than the SKS
> repo: https://bitbucket.org/skskeyserver/sks-keyserver/commits/all
>
> It may be worth considering.
>
> On Sat, Jul 14, 2018 at 12:19 PM, Human at FlowCrypt 
> wrote:
>>
>> Sorry, I hadn't noticed that you linked specifically the conflux
>> (reconciliation code). That is indeed a good start if someone wanted to take
>> the time to understand it.
>>
>> On Sat, Jul 14, 2018, 20:16 Human at FlowCrypt 
>> wrote:
>>>
>>> Hockeypuck has not had any commits in years, if I saw correctly.
>>>
>>> It cannot process some of the keys (maybe for a good reason, but it will
>>> clog the recon mechanism nevertheless, I suppose).
>>>
>>> I think it was a great effort, but apparently not maintained.
>>>
>>> If the recon process could be updated with mechanism where some
>>> implementations could seamlessly choose not to import certain keys, I think
>>> hockeypuck would be a great alternative. It may need to be forked.
>>>
>>>
>>> On Sat, Jul 14, 2018, 19:33 Moritz Wirth  wrote:

 Though I am not sure, https://github.com/hockeypuck/conflux may be worth
 a look.

 If somebody has a short How-To for installing hockeypuck (and importing
 a keydump..), I am happy to test if it is more stable than sks :)

 Best regards,

 Moritz


 Am 14.07.18 um 02:50 schrieb Tom at FlowCrypt:

 I would have loved to write an alternative SKS implementation that
 addresses the issues we were seeing recently. However, this:

 Set Reconciliation with Nearly Optimal Communication Complexity
 Practical Set Reconciliation


 is preventing me from doing so. I'm a software engineer, not a
 mathematician, and I have little willingness to attempt implementing an
 algorithm nobody understands.

 I wish the title said "simple" and "resilient" rather than "with nearly
 optimal communication complexity", and the contents matched the title.

 The pool of engineers willing and able to get us out of this mess would
 be much larger.

 On Fri, Jul 13, 2018 at 11:23 PM, Andrew Gallagher 
 wrote:
>
>
> > On 13 Jul 2018, at 22:43, Moritz Wirth  wrote:
> >
> > FWIW, has anybody even started working on a fix for any of the bugs?
>
> There has been a fair bit of discussion, but no consensus has been
> reached, apart from a general agreement that major changes to the recon
> model will be required, and that these will be necessarily
> backwards-incompatible. That’s generally where the discussion dries up.
>
> I get the impression that everyone is holding fire until there is some
> sign that one particular form of breakage will be more broadly acceptable
> than the others.
>
> 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
>

___
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

[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] withdrawal of service: sks.spodhuis.org

[Human at FlowCrypt]

One more apology - there does seem to be recent activity when you look at
the repo owner: https://github.com/hockeypuck

Though not loads of activity, still more code contributions than the SKS
repo: https://bitbucket.org/skskeyserver/sks-keyserver/commits/all

It may be worth considering.

On Sat, Jul 14, 2018 at 12:19 PM, Human at FlowCrypt 
wrote:

> Sorry, I hadn't noticed that you linked specifically the conflux
> (reconciliation code). That is indeed a good start if someone wanted to
> take the time to understand it.
>
> On Sat, Jul 14, 2018, 20:16 Human at FlowCrypt 
> wrote:
>
>> Hockeypuck has not had any commits in years, if I saw correctly.
>>
>> It cannot process some of the keys (maybe for a good reason, but it will
>> clog the recon mechanism nevertheless, I suppose).
>>
>> I think it was a great effort, but apparently not maintained.
>>
>> If the recon process could be updated with mechanism where some
>> implementations could seamlessly choose not to import certain keys, I think
>> hockeypuck would be a great alternative. It may need to be forked.
>>
>>
>> On Sat, Jul 14, 2018, 19:33 Moritz Wirth  wrote:
>>
>>> Though I am not sure, https://github.com/hockeypuck/conflux may be
>>> worth a look.
>>>
>>> If somebody has a short How-To for installing hockeypuck (and importing
>>> a keydump..), I am happy to test if it is more stable than sks :)
>>>
>>> Best regards,
>>>
>>> Moritz
>>>
>>> Am 14.07.18 um 02:50 schrieb Tom at FlowCrypt:
>>>
>>> I would have loved to write an alternative SKS implementation that
>>> addresses the issues we were seeing recently. However, this:
>>>
>>>- Set Reconciliation with Nearly Optimal Communication Complexity
>>>
>>>- Practical Set Reconciliation
>>>
>>>
>>>
>>> is preventing me from doing so. I'm a software engineer, not a
>>> mathematician, and I have little willingness to attempt implementing an
>>> algorithm nobody understands.
>>>
>>> I wish the title said "simple" and "resilient" rather than "with nearly
>>> optimal communication complexity", and the contents matched the title.
>>>
>>> The pool of engineers willing and able to get us out of this mess would
>>> be much larger.
>>>
>>> On Fri, Jul 13, 2018 at 11:23 PM, Andrew Gallagher 
>>> wrote:
>>>

 > On 13 Jul 2018, at 22:43, Moritz Wirth  wrote:
 >
 > FWIW, has anybody even started working on a fix for any of the bugs?

 There has been a fair bit of discussion, but no consensus has been
 reached, apart from a general agreement that major changes to the recon
 model will be required, and that these will be necessarily
 backwards-incompatible. That’s generally where the discussion dries up.

 I get the impression that everyone is holding fire until there is some
 sign that one particular form of breakage will be more broadly acceptable
 than the others.

 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] withdrawal of service: sks.spodhuis.org

[Human at FlowCrypt]

Sorry, I hadn't noticed that you linked specifically the conflux
(reconciliation code). That is indeed a good start if someone wanted to
take the time to understand it.

On Sat, Jul 14, 2018, 20:16 Human at FlowCrypt  wrote:

> Hockeypuck has not had any commits in years, if I saw correctly.
>
> It cannot process some of the keys (maybe for a good reason, but it will
> clog the recon mechanism nevertheless, I suppose).
>
> I think it was a great effort, but apparently not maintained.
>
> If the recon process could be updated with mechanism where some
> implementations could seamlessly choose not to import certain keys, I think
> hockeypuck would be a great alternative. It may need to be forked.
>
>
> On Sat, Jul 14, 2018, 19:33 Moritz Wirth  wrote:
>
>> Though I am not sure, https://github.com/hockeypuck/conflux may be worth
>> a look.
>>
>> If somebody has a short How-To for installing hockeypuck (and importing a
>> keydump..), I am happy to test if it is more stable than sks :)
>>
>> Best regards,
>>
>> Moritz
>>
>> Am 14.07.18 um 02:50 schrieb Tom at FlowCrypt:
>>
>> I would have loved to write an alternative SKS implementation that
>> addresses the issues we were seeing recently. However, this:
>>
>>- Set Reconciliation with Nearly Optimal Communication Complexity
>>
>>- Practical Set Reconciliation
>>
>>
>>
>> is preventing me from doing so. I'm a software engineer, not a
>> mathematician, and I have little willingness to attempt implementing an
>> algorithm nobody understands.
>>
>> I wish the title said "simple" and "resilient" rather than "with nearly
>> optimal communication complexity", and the contents matched the title.
>>
>> The pool of engineers willing and able to get us out of this mess would
>> be much larger.
>>
>> On Fri, Jul 13, 2018 at 11:23 PM, Andrew Gallagher 
>> wrote:
>>
>>>
>>> > On 13 Jul 2018, at 22:43, Moritz Wirth  wrote:
>>> >
>>> > FWIW, has anybody even started working on a fix for any of the bugs?
>>>
>>> There has been a fair bit of discussion, but no consensus has been
>>> reached, apart from a general agreement that major changes to the recon
>>> model will be required, and that these will be necessarily
>>> backwards-incompatible. That’s generally where the discussion dries up.
>>>
>>> I get the impression that everyone is holding fire until there is some
>>> sign that one particular form of breakage will be more broadly acceptable
>>> than the others.
>>>
>>> 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] withdrawal of service: sks.spodhuis.org

[Human at FlowCrypt]

Hockeypuck has not had any commits in years, if I saw correctly.

It cannot process some of the keys (maybe for a good reason, but it will
clog the recon mechanism nevertheless, I suppose).

I think it was a great effort, but apparently not maintained.

If the recon process could be updated with mechanism where some
implementations could seamlessly choose not to import certain keys, I think
hockeypuck would be a great alternative. It may need to be forked.


On Sat, Jul 14, 2018, 19:33 Moritz Wirth  wrote:

> Though I am not sure, https://github.com/hockeypuck/conflux may be worth
> a look.
>
> If somebody has a short How-To for installing hockeypuck (and importing a
> keydump..), I am happy to test if it is more stable than sks :)
>
> Best regards,
>
> Moritz
>
> Am 14.07.18 um 02:50 schrieb Tom at FlowCrypt:
>
> I would have loved to write an alternative SKS implementation that
> addresses the issues we were seeing recently. However, this:
>
>- Set Reconciliation with Nearly Optimal Communication Complexity
>
>- Practical Set Reconciliation
>
>
>
> is preventing me from doing so. I'm a software engineer, not a
> mathematician, and I have little willingness to attempt implementing an
> algorithm nobody understands.
>
> I wish the title said "simple" and "resilient" rather than "with nearly
> optimal communication complexity", and the contents matched the title.
>
> The pool of engineers willing and able to get us out of this mess would be
> much larger.
>
> On Fri, Jul 13, 2018 at 11:23 PM, Andrew Gallagher 
> wrote:
>
>>
>> > On 13 Jul 2018, at 22:43, Moritz Wirth  wrote:
>> >
>> > FWIW, has anybody even started working on a fix for any of the bugs?
>>
>> There has been a fair bit of discussion, but no consensus has been
>> reached, apart from a general agreement that major changes to the recon
>> model will be required, and that these will be necessarily
>> backwards-incompatible. That’s generally where the discussion dries up.
>>
>> I get the impression that everyone is holding fire until there is some
>> sign that one particular form of breakage will be more broadly acceptable
>> than the others.
>>
>> 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

[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] withdrawal of service: sks.spodhuis.org

[Moritz Wirth]

Though I am not sure, https://github.com/hockeypuck/conflux may be worth
a look.

If somebody has a short How-To for installing hockeypuck (and importing
a keydump..), I am happy to test if it is more stable than sks :)

Best regards,

Moritz


Am 14.07.18 um 02:50 schrieb Tom at FlowCrypt:
> I would have loved to write an alternative SKS implementation that
> addresses the issues we were seeing recently. However, this:
>
>   * Set Reconciliation with Nearly Optimal Communication Complexity
> 
>   * Practical Set Reconciliation
> 
>
>
> is preventing me from doing so. I'm a software engineer, not a
> mathematician, and I have little willingness to attempt implementing
> an algorithm nobody understands.
>
> I wish the title said "simple" and "resilient" rather than "with
> nearly optimal communication complexity", and the contents matched the
> title. 
>
> The pool of engineers willing and able to get us out of this mess
> would be much larger.
>
> On Fri, Jul 13, 2018 at 11:23 PM, Andrew Gallagher
> mailto:andr...@andrewg.com>> wrote:
>
>
> > On 13 Jul 2018, at 22:43, Moritz Wirth  > wrote:
> >
> > FWIW, has anybody even started working on a fix for any of the bugs?
>
> There has been a fair bit of discussion, but no consensus has been
> reached, apart from a general agreement that major changes to the
> recon model will be required, and that these will be necessarily
> backwards-incompatible. That’s generally where the discussion
> dries up.
>
> I get the impression that everyone is holding fire until there is
> some sign that one particular form of breakage will be more
> broadly acceptable than the others.
>
> 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

[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