sks-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Sks-devel] status page


From: Phil Pennock
Subject: Re: [Sks-devel] status page
Date: Fri, 18 Apr 2014 17:16:17 -0400

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 2014-04-18 at 20:24 +0200, Simon Lange wrote:
>        the reason why a reverse proxy is "required" is, because some
> require additional "security" at the nodes.

False.

The SKS software is single threaded and handles a single request at a
time.  One client can hold open a connection and prevent anyone else
from using your server.

Anyone can run a pool definition, using whatever criteria they like.
There is no requirement to be in any pool.  Equally, there is no
requirement for anyone else to peer with you.  If you can find people
willing to peer with you while you don't work to fit in any pools, then
that's okay -- nobody but you and your peers has any business telling
you what to do.  So far, mostly, keyserver operators have been willing
to add peers without checks for pool-worthiness because so far, mostly,
new community members have worked to be members of the main pools, so
there has been no need.

Kristian's pools list only keyservers which he thinks are suitable to be
listed as defaults for end-users.  The rules change over time as we
learn and develop; Kristian has always clearly communicated changes to
this mailing-list.

Amongst other things, his requirements include keyservers which won't
hang because some other client is holding open a connection, so that
the keyservers are not going to be seen as "broken, never working",
leading end-users to disable PGP.  Other requirements include
"up-to-date", "able to peer reliably", "not so buggy as to cause interop
problems", and more.

>                                                    yesterday i learned i
> have to give up control who is using his domain with my services. :/

False.  As long as you can find people who will peer with you, you do
not need to be in any pools at all.

> currently for :80 i do accept all for ^(.*)pool.sks-keyservers.net and

Note that Kristian's pool is considered well-run and is used as the
target of CNAMEs by other people.  Most notably, `keys.gnupg.net` is a
CNAME to `pool.sks-keyservers.net`.

So if you only whitelist for a pattern which, when unbroken, is:

 ^(?:.+\.)?pool\.sks-keyservers\.net

then you've broken access by people using the default configuration of
GnuPG.  Kristian doesn't want those people to experience a broken
service, so you don't get listed.

Kristian _could_ decide to only support certain CNAMEs, then
exhaustively test for all of those working, then going through the
song-and-dance of de-listing most sites when he adds one more CNAME.
Instead, he just says "to be listed in my pools, then on port 11371, all
HTTP requests under `/pks/` should be passed to SKS, no matter what is
in the Host: header".  This creates less stress, less bureaucracy, less
of a culture of having to ask permission for every action.

> domains using our services. its a matter of respect AND security. its an
> optin feature not a optout.

Absolutely: you don't need to be listed in a pool, there is no hard
requirement for it.

_I_ won't give away _my_ bandwidth for free to provide others with keys
if they're not giving back to the community by being listed in public
pools.  That's my choice, in not subsidising other peoples' businesses
and hobbies from my own pocket more than I already do with my time on
open source projects.

That's okay.  You and I don't have to peer.  There is no one right way,
no authority saying everyone must peer, no right to peering, no
expectation that everyone agree.

You can probably find other people who will peer with you.

> (11371). there is absolutely no reason for a via (which may exposes the
> used software)

It helps debug operational problems.  When you ready the configuration
advice on:
  <https://bitbucket.org/skskeyserver/sks-keyserver/wiki/Peering>
you're reading the results of that debugging, as we've found various
problems and confirmed that avenues of debugging were correct, looking
around at other keyservers.  Speaking as someone who has helped debug a
few major issues and done most of the writing for that document, I'm
grateful to those who make it easy for others to work with them instead
of demanding that permission be requested before knowing what's going
on.  I'll certainly spend far more of my time debugging servers which
are candidates for Kristian's pool and which make data available than I
will on other servers.

You don't need to expose full version, but revealing "Apache/2" provides
enough for most debugging.  If revealing even that much makes you
vulnerable, then you have bigger problems, because more intrusive
platform fingerprinting by those of malicious intent will identify your
platform anyway.

> FQDNs to use that specifiy service. dont allow anyone except fqdn which
> did ask before is far more secure. (e.g. i dont want any raccist website
> to advertise with MY services under THEIR domain, but because i cannot
> KNOW all such domains, its better to deny all and allow a few).

Go ahead, use that policy.  Find others who agree, create pool
definitions which tightly control which final hostnames can be used.

Kristian has made his pool software freely available for others to use:
  https://code.google.com/p/sks-keyservers-pool/
I have made my own pool software freely available for others to use:
  https://github.com/philpennock/sks_spider

You have two platforms available for you to run pools using whatever
criteria you like.  Go for it.  Just don't expect anybody to take you
seriously if you try telling us what criteria we are *allowed* to use
for our own pools.

> this is not a rant, but maybe sounds rude to some.

It was a rant.  Your claiming otherwise did not make it not a rant and
did not change it from being a set of demands on how others work, on how
others should change what they do to suit you, how you get control over
what other people can do and how they can communicate.

Thank you for making your keyserver usable by the pools.  I may
strenuously disagree with your stance and your demands, but as long as
you're providing a public service, I'm happy to continue peering with
you.  If you change your mind about providing a public service which can
be freely listed by anyone, please do let me now and I will remove your
system from my peering membership list.

- -Phil
-----BEGIN PGP SIGNATURE-----

iQEcBAEBCAAGBQJTUZYZAAoJEKBsj+IM0duFWqcH/A170Yy4ttcrpOe9WxMIvZqQ
EJmt2KoYnI/N1Ln+dN9hlMqhXwV1JxFosQaJBRvQdTonaLbtukowYKsSBN/gGggG
7E1bj5q9ronjABNXdtIwFMEeT3P1+WJyAbKEr5KdIR6OPG+h543w97DXeMsJCgOP
6nxIXnJB64/9DyH1J1zeS4fH+Dqse1ZI7mO3/NadESfOrgEvPhwr4D/TK4pCqDQu
AznUuvpjzOfnSk0iurtP3l8HdS9lIIhJh5bFHgGvC7tlJtedL516XHcK+0iVSji1
9Iw/JRPNKhjB09Wv2uAvOFfWNn+LA+YTUudlEGJAx35x1JjSIwpJEFyxiFM052A=
=0dPE
-----END PGP SIGNATURE-----



reply via email to

[Prev in Thread] Current Thread [Next in Thread]