Re: [Sks-devel] sks pool membership registration

[Kristian Fiskerstrand]

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

On 06/26/2013 09:48 PM, Phil Pennock wrote:
> On 2013-06-26 at 14:20 -0400, Daniel Kahn Gillmor wrote:
>> kristian, you're doing a much-appreciated job maintaining the SKS
>> pools. I was wondering if you'd consider allowing members of the
>> pool(s) to register an e-mail address associated with their
>> server, to receive notifications when their server gets ejected
>> from the pool.
>> 
>> For example, i'd like to be able to communicate with you (out of
>> band, perhaps) and say "my keyserver, zimmermann.mayfirst.org,
>> belongs in the ha pool.  please have your system send me an alert
>> if it gets removed from that pool".

Hi Daniel,

First of all, thanks for your thoughts. Indeed; this was why we, as
Phil pointed out, added the server contact configuration directive; To
be able to have better communication between the keyserver operators.
When it comes to automatic notification from the pool software, it is
something I've been pondering from time to time, however I've so far
always concluded that the additional complexities weren't worthwhile.

My primary intention with the pool is to have enough good servers in
it, to at any time provide a good experience for OpenPGP users. To be
able to provide information to server operators as a benefit of that,
given that the information is collected anyways, is an added bonus,
but it isn't vital for the pool per se. As such this has to be a
balancing act vs design complexity and server resources that might
compromise the primary goal.

Also, I immediately see some possible drawbacks. Say for instance my
IPv6 connection drops down and people somehow are signed up to receive
messages when they drop out of that subpool, suddenly I've spammed
half (or actually more than that) of the operators :) But adding to
that, as I'm performing polling from a single location (albeit
correcting the data by using measuring stations around for the
geographical sub-pools), connectivity issues, or simply polling a
server when it is busy will lead to it being excluded for the next
hour. This really isn't an issue for the user experience, but it would
contribute to noise if automatic messages were sent out.

> 
> We added "Server contact:" to the stats page, configured by 
> "server_contact:" in sksconf, which lets folks set the PGP keyid of
> the operator, without directly putting email addresses into a
> scrapeable page, and Kristian collects that already, showing it as
> address@hidden after some server names.
> 

Indeed

> Perhaps we should add a "pool_policy:" statement, which applies to 
> everyone running any kind of pool, with a very simple grammar?
> 

See above re complexity. For instance this would only apply if the
keyserver responds and the software can read the status page. If the
intent is to have a hidden server, it would still show up if the
server doesn't respond. I can (to some extent) see the value in this
if the purpose is to not want the traffic/use from the public, however
it is far simpler for me to just add such servers to the global
exclude list, and IMHO if that is the purpose, only accepting certain
IP ranges to use the server (or a non-standard port) intuitively makes
more sense to me.

> Key:     hkpsport=11373 Action:  HKPS service offered, any SRV
> records should reference this port; if port is not 443, do not
> include in non-SRV pool definitions.
> 

The pool crawler actually detects non-443 port HKPS servers already
using the SRV record, however offering this in DNS is currently
disabled due to the GnuPG issues involved (1446,1447).

- -- 
- ----------------------------
Kristian Fiskerstrand
Twitter: @krifisk
- ----------------------------
Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
- ----------------------------
Testis unus, testis nullus
A single witness is no witness
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.1.0-beta210 (GNU/Linux)

iQIcBAEBCAAGBQJRy0wEAAoJEJjgB+fVz3pu7fUP/2i5263+GL1qqL/XfCHwetIS
OlsNAwa6o8RegRFYitjVxNNqMkz+OEEwcjBeADnwpoYEiyXMisJdNhW+X1/0P2YZ
weGkvJ/3LaY5OFu8uRoK8smDaEyiL5DiqbN762s7ffYT3UFZDWEo3uoUgMrNfmez
DGHuKnBwaAGJby9wka21urCNgsFDdtdHoZSv9kkzWnuOXJB6ditcWsiNyDSA2w7T
U0K+z/C5BpYfityQ8kN2NCT0N9nVaJlCkN/HWrWO4J3Y09AnzyLHi81FcaT/cYqT
LQG8HGBpXMPbBf4vc6Mj1jIVdWT3n1YHgXMJZ4FI+uTvQnQBNUPgKiwor61a6i+J
HD2rzM+tpsQ9evQUMH7vBULzYv3sHqKks5QxG2kdZkNfQDnnLDzMIkP4/LSFIzD1
EPbcy+6Oxg+Q26U/1gup/4UixqYZF8a4rPML3t5WMfVacNowAPtzU/mA08iwFObU
3Ajrga/QwsMh/Z61ByKH9Oak63btM/1qrsHTPZLz8H8ILHp4lDOZFpOZwhCPrz4s
L2/NPQbT10d384ySKko9K2Hlwv/5MYHto2CnbmmNaQW/shMwoHd0TScbGIQVmm68
5eAPIpvf1uydBH7p4ewEgJ2V5omBybuoUS4ySAPKzi3v08NLkGASJkAP1lsTxB8z
kP5LIAWg/lkpZ/ojlPcz
=XDcX
-----END PGP SIGNATURE-----