Re: [Sks-devel] Keyservers and GDPR

[Phil Pennock]

On 2019-05-26 at 10:43 +0200, Werner Koch wrote:
> On Sat, 25 May 2019 14:53, i...@zeromail.org said:
> You mean from the left over 5 servers in the default hkps pool:
> 
>  pgpkeys.eu   51.38.91.189AS16276 (UK)
>  pgpkeys.uk   192.146.137.98  AS57672 (UK)
>  pgpkeys.co.uk192.146.137.99  AS57672 (UK)
>  fks.pgpkeys.eu   46.4.246.179AS24940 (DE, Hetzner)
>  keys2.kfwebs.net 37.191.231.105  AS57963 (NO) 
> 
> which according to rumours have only two or three different operators?

My old SKS membership file had both pgpkeys.co.uk and pgpkeys.eu
maintained by Daniel Austin; the off-by-one for pgpkeys.uk suggests
Daniel runs that one too.  That covers the first four.

kfwebs.net is Kristian Fiskerstrand, who runs the pool tracking system
and sks-keyservers.net.

hkps is limited because Kristian doesn't hand out certs to anyone who
shows up with a new keyserver and asks; he tends to do so with people
who've been around and part of the community, because of the fairly
obvious problems with assuming TLS is buying you anything when entirely
unknown-to-others folks run the servers.  Kristian takes a lot of flak
for not giving people the power they want just because they ask for it.

With the various problems of SKS today, I tentatively suggest that not
defaulting to the HKPS pool and choosing a different target for the
keys.gnupg.net CNAME might be beneficial.

 has the criteria; I
suspect that >> subset.pool.sks-keyservers.net << is likely to be the
best choice for GnuPG; the meaning of "subset" changes over time,
picking newer servers, but for a while now that's been "updated SKS
software able to handle Curve25519 keys".

Spitballing crazy design now:

The only way to get back HKPS while still having diversity and yet still
some accountability is likely to be by requiring DNSSEC-signed
reverse-DNS which points to matching DNSSEC-signed forward DNS to prove
domain matching, and a trigger record in DNS indicating to use TLS; once
there's a forward-name which doesn't require central coordination, you
can verify normally and "anyone" can run a keyserver again.  With all
the pros and cons that entails.

GnuPG can pretty much define what it wants here.  Including changing the
URL scheme name if needed to avoid confusion.  TLSA records are
available for opportunistic TLS.  Effectively, "DANE for HKP with
work-arounds to handle the pool nature and bounce into a verifiable name
for arbitrary pool names".  Shove a TLSA record in reverse DNS to
indicate it's supported and you're good.  Hrm, probably don't strictly
need the reverse DNS to be DNSSEC-signed, as long as the
TLSA-or-other-marker is present and the forward DNS is still signed.

There's ways around it, but none of it will make folks who object to
DNSSEC happy.  Tough.

-Phil

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

Re: [Sks-devel] [openpgp] Modelling an abuse-resistant OpenPGP keyserver

[Phil Pennock]

On 2019-04-04 at 18:41 -0400, Daniel Kahn Gillmor wrote:
> I've documented some thoughts on how to resist this abuse in a new
> Internet Draft:
> 
>
> https://datatracker.ietf.org/doc/draft-dkg-openpgp-abuse-resistant-keystore/

Hey, this is good stuff.  Thanks.

The references section uses my name in the SKS reference.  While I
certainly wrote much of (a vast majority of?) the SKS operational
documentation, I did not write SKS and am no longer at all involved in
it.  Another person's name should probably go there.

The rest of this mail is on just one topic; otherwise it'll get too long.

Others are suggesting blockchain approaches.  This makes the reason that
I stopped volunteering my time and resources to host an SKS instance, and
helping others to do so, relevant: people create spamming tools which
make it easier for non-technical users to abuse the append-only trust
stores; history has shown that this ease-of-abuse barrier-lowering does
directly lead to more abuse, including attempts to just spoil the entire
keyserver system.

In my jurisdiction (and under my own ethical code) the big concern was
child porn: not because it's a sane means of distribution, but because
of the spoiling effect.  Even without graphical-representation attribute
packets, there is speech which causes trouble in some parts of the
world.  Eg, in Europe, folks can insist upon having their own data be
removed.  This happened, a decade ago, leading Peter Palfrader to shut
down his keyserver after receiving a legal demand to delete a key from
the keyservers.

So locking down towards a "blockchain" approach (with whichever subset
of functionality the speaker intends that to mean, usually just a merkle
tree), trendy as it might be, risks creating a system where the
operators don't dare host the data sets.  Financial blockchain systems
might be able to bear the risk because once there's money involved,
there will be pushback against censorship, but a OpenPGP key blockchain
would not have that politically powerful vested interest protection.

An append-only system where the operator of a keyserver has no ability
to filter what makes it onto local storage would not entice this former
keyserver operator back into the fold.

It turns out that "ability to resist censorship by governments with
global reach" is not directly the biggest threat model and trying to
protect against it will hinder protections against the actual abuse
observed.  As long as OpenPGP client implementations don't get tied into
only one keyserver interaction method, and instead keep WKD and other
approaches, there are plenty of ways to get keys out there; preferred
keyserver annotations help too.  Folks who need to bypass extreme
censorship will likely need to use private keyserver setups, eg run
along SecureDrop by friendly organisations.

-Phil

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

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

[Phil Pennock]

Folks, with immediate effect, I am withdrawing sks.spodhuis.org from
service and it will not be returning in its current form.

I am about to disable the DNS in spodhuis.org, while leaving the SKS
service itself running, so that clients using pools will not be
adversely impacted.  I'll give it a few hours for pools to update and
caches to expire, before turning off SKS itself.

I have already disabled SKS recon.

It's been an educational ride.

I'm willing to fight jurisdictional overreach, but with Yet Another
Attack Tool to abuse the resources which I provide out of my pocket,
combined with large chunks of the traffic appearing to be to support
operational incompetence by certain software publishers, I don't see
that I'm successfully spending my money to good effect, supporting a
community of users who care about verifiable integrity and some privacy.

With the latest attack tool providing for generic filesystem storage
such that attaching a file doesn't even require understanding how to use
a user-attribute packet, the threat of KP upload has just increased by
an order of magnitude.  I'm not willing to be part of that.

My key remains available at the URL in the OpenPGP: header of all my
emails, and via finger: (for my name @ my domain).  I'll explore WKD
again, sometime later this year.

Regards,
-Phil, surrendering


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

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

[Phil Pennock]

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


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

Re: [Sks-devel] SKS intermittently stalls with 100% CPU & rate-limiting

[Phil Pennock]

On 2018-06-25 at 13:08 +0200, Paul Fontela wrote:
> I have tried almost everything, from downloading a dump and starting the
> server sks again to reinstall system and everything else, the result is
> always the same, it works well for a while, sometimes an hour sometimes
> a little more and suddenly it it freezes the key server, reaching 80%
> RAM, which makes it unstable and inoperable.

That sounds like recon gone wild, normally a sign that you're peering
with someone who is very much behind on keys.  The recon system only
works if your peers are "mostly up-to-date".

This is why we introduced the template for introducing yourself to the
community, in the Peering wiki page, showing how many keys you have
loaded.  It cut down on people joining with 0 keys, expecting recon to
do all the work, and new peers complaining that their SKS was hanging.

Per  the lower bound of keys to be
included is:  5105570
You have: 5109664

Using  as a
starting point, and skipping your in-house 11380 peers, opening all the
others up in tabs and looking (I don't have this scripted) we see:

  5109604  keys.niif.hu
  5065412  keys.sbell.io
  5107576  sks.mbk-lab.ru
  5109585  pgp.neopost.com
  5108773  pgp.uni-mainz.de
  5109639  pgpkeys.urown.net
  4825075  pgp.key-server.io
sks.funkymonkey.org
  5084241  keyserver.iseclib.ru
  5109254  keyserver.swabian.net
  5109628  sks-cmh.semperen.com
keys-02.licoho.de
  5109629  keyserver.dobrev.eu
  5109121  sks.mirror.square-r00t.net
  5109629  keyserver.escomposlinux.org
  5108778  keyserver.lohn24-datenschutz.de

If your in-house peers are way behind, fix that.

Comment out all peers with fewer than 5_100_000 keys.  Restart sks and
sks-recon.

The 284,000 key difference is pretty severe.  Since that peer isn't
getting updates, they're probably hanging on peering and causing even
more problems for you.

Disable peering _at least_ with those three hosts.


Whenever SKS isn't performing right, the _first_ step after looking for
errors in logs should always be a Peering Hygiene Audit.  Find the peers
who are sufficiently behind that their keeping the peering up is
anti-social and likely causing _you_ problems, comment out the peering
entries, restart (for a completely clean slate) and then reach out to
those peers to ask "Hey, what's up?".

Regards,
-Phil

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

Re: [Sks-devel] Keyserver Network Down?

[Phil Pennock]

On 2018-06-20 at 00:35 +0200, Kristian Fiskerstrand wrote:
> Seems to be a very high request for mongodb release key, so forcing
> caching on the front-end helps relaxing SKS quite a bit, see

Last Friday I investigated and while adjusting my logging to capture the
HTTP verb/method, accidentally logged the entire request for a duration
of 1 minute 33 seconds.  In that time, of the 324 requests logged, two
two most frequent were:

  142  MongoDB 3.4 Release Signing Key 
   10  MongoDB 3.2 Release Signing Key 

That's almost half the traffic for keys related to one project.

This tied into an eyeball-visible (might be illusion, I don't have
insight analysis tools set up) swing of presented hostnames towards
`keys.gnupg.net` (the common CNAME) instead of the normal pool name.

I walked away from computers for the weekend, for various reasons, but
realizing how much I was spending out of my own pocket now just to
support some company doing stupid things with key distribution factored
into it.  I think there's still some value to running a keyserver so I'm
not ready to give up yet, but I came this --->.<--- close on Friday.

-Phil

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

Re: [Sks-devel] disk full, keys.niif.hu crashed

[Phil Pennock]

On 2018-06-15 at 12:40 -0400, tiker wrote:
> The problems seem to be caused by a large key.  There's at least 2
> different hash values for this key (so probably recently updated) and
> one of the versions of the key is 22mb.  The size is causing timeouts on
> some reverse proxies and the constant retries is causing the .log files
> to be created and growing in the DB directory.

The current advice over at
https://bitbucket.org/skskeyserver/sks-keyserver/wiki/Peering is to set
client_max_body_size to 8 MiB.

> I don't think I want to post the key ID here because it's hard on the
> servers grabbing this key but someone should look at it and figure out
> what to do with this.  My node only seems to sync with about 10% of its
> peers.

Is this something with a binary image attribute?  :(

-Phil

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

Re: [Sks-devel] disk full, keys.niif.hu crashed

[Phil Pennock]

On 2018-06-15 at 09:40 +0200, André Keller wrote:
> On 15.06.2018 05:54, Kiss Gabor (Bitman) wrote:
> > Yesterday at 18:15 (CEST) keys.niif.hu started to produce tons
> > of logs in /var/lib/sks/DB. In less than 2 hours the 40 GB filesystem
> > got fulfilled.
> > Deleting files and restarting processes did not help:
> 
> keys.communityrack.org shares the same fate. Trying to get it online
> again...

sks-peer.spodhuis.org saw a spike at the same time, AWS CloudWatch
metrics show that the dedicated EBS volume used for /var/sks hit 175,000
write operations per minute, when it's usually around 22,000 peaking
around 56,000.

The write _bytes_ is peaking around the same as normal, so throughput is
probably capping out.  I actually used some of the burst credits I had.

I'm in the middle of migrating OS-view metrics monitoring, in part to
handle having moved SKS into AWS, and don't currently have graphs
showing change in used capacity.  I'm currently at 30GB in use.

I see no change in rate of new keys or updated keys.  I do see 21GiB in
use for the DB directory.

-Phil

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

Re: [Sks-devel] pool status page, not recognizing hkps

[Phil Pennock]

On 2018-06-05 at 02:53 +0200, Paul Neuwirth wrote:
> my keyserver keyserver.swabian.net has also hkps enabled on port=20
> 443 since several months now.
> But in the pool status page I do not see hkps enabled.
> Do I miss a DNS entry? or is something different wrong with my setup?

https://bitbucket.org/skskeyserver/sks-keyserver/wiki/TLS%20Configuration

I've updated it to be clearer about the need for manual action to join
the pool and to link to the instructions for doing so.

-Phil

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

Re: [Sks-devel] sks-peer.spodhuis.org: 2nd migration imminent

[Phil Pennock]

On 2018-05-21 at 02:46 -0400, Phil Pennock wrote:
> If there's anyone who would like to de-peer, please let me know.

No complaints, that's nice.  :)

> Otherwise, tomorrow evening (I think) I'll uncomment the membership
> entries on the new host and repoint spodhuis.org DNS, then take down the
> old instance a bit later (after a DNS TTL or so).

As expected, some clients held onto DNS for longer than others.  There
are still some clients using the old IP, although that may well be pool
inclusion.  I do not expect any peers to be stuck though.  It's been 24½
hours on a 5 minute TTL.  I'm about to take down sks-paris.

Today I re-deployed sks-ohio with a fresh image containing the latest
Ubuntu kernel today's security fixes (Spectre Variant 4, mostly) and
the outage lasted longer than the expected 1 minute, because I hadn't
updated the image to pull from the correct encrypted repository of TLS
keys, so it was missing the key/cert for sks-ohio and nginx didn't
start.  Oops!  Fixed.

  https://sks-ohio.pennock.tech/pks/lookup?op=stats

FWIW, to better track this down in future, I'm now generating _some_
logs for HKP requests.  This does not include IP address.  I'll follow
up with a second email to not bury a privacy change deep in this mail.

-Phil


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

[Sks-devel] sks-peer.spodhuis.org: 2nd migration imminent

[Phil Pennock]

Folks,

Rather than wait to get hit with GPDR stuff to do with running a
keyserver, I'm doing the saner thing, as an American: I'm moving my
instance to the USA, so that it is not in EU jurisdiction.  It's a free
service, provided as a public good, and it's not worth the risk to me.

If there's anyone who would like to de-peer, please let me know.
Otherwise, tomorrow evening (I think) I'll uncomment the membership
entries on the new host and repoint spodhuis.org DNS, then take down the
old instance a bit later (after a DNS TTL or so).

The new instance can currently be reached at:
  http://sks-ohio.pennock.tech:11371/pks/lookup?op=stats
but it will "be" sks-peer.spodhuis.org/sks.spodhuis.org for continuity.
It's running in AWS, us-east-2 (Ohio), from AMIs built under my control,
same as the sks-paris instance (but a little more automated).

sks-ohio should be fully up-to-date before anyone else peers with
it; I snapshotted the /srv/sks EBS volume from sks-paris, copied it to
us-east-2, and used it as /srv/sks on the new server after modifying
only membership and sksconf; sks-paris and sks-ohio are peering with
each other and exchanging keys fine.  If any problems crop up, I'll
delay peering with anyone else while I fix those problems.

Regards,
-Phil


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

Re: [Sks-devel] Inconsistency on vindex page with machine-readable flag set or unset?

[Phil Pennock]

On 2018-05-09 at 19:11 +0100, Paul M Furley wrote:
> Hi folks, I'd appreciate your input, I'm not sure if this is a bug in
> SKS or a fault in my understanding.

Bug.

> It seems there used to be an expiry (the one referenced above) but the
> most recent selfsig removed the expiry date.

> So what am I missing? Why is the machine-readable page giving that
> 2018-05-09 expiry timestamp?

>From code inspection: the filter goes over the creation times and uses
the timestamp from the last creation time, but the list it iterates over
is populated from `get_key_exptimes` which ends with:

  in
  match exptime_delta with
| None -> (None,None)
| Some _ -> (ctime,exptime_delta)

I suspect that the `None` line there should be yielding (ctime,None)
instead of (None,None); in other words, the four lines above should just
become:

  in
  (ctime,exptime_delta)

The mRindex.ml code is the only place that get_key_exptimes is called,
and looks to handle the Some unpacking safely already, so it should be
safe to change, but I'm not set up to play around with this right now to
confirm and see if there are negative side-effects.

-Phil

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

Re: [Sks-devel] SKS apocalypse mitigation

[Phil Pennock]

On 2018-05-05 at 10:27 +0100, Andrew Gallagher wrote:
> Sorry for the double. We don’t need to modify the protocol to enable
> such checks. Whenever a server tries to recon with us, we can perform
> a callback against its status page and run whatever sanity tests we
> want before deciding whether to allow recon to proceed. This could be
> rolled out without any need for coordination. 

You'll need to ensure that initial_stat defaults to true and so forth
then, since by default keyservers don't calculate the stats at startup,
so such a keyserver won't be able to start peering for up to a day (3am
by default).

It's probably reasonable to change the default, but you'll want to make
this explicit when you draw up your full workflow.

Note though that the status pages are intended for humans and SKS the
keyserver can speak SKS and reconcile with other codebases, such as
Hockeypuck, which uses a different output format.  You'll probably want
to look into standardizing on something like a JSON output format, with
fallback to heuristic matching upon the output formats used by the two
current codebases.

But still my point stands: the moment you change to defaulting to
recon-open-to-everyone the scope of what counts as a security
vulnerability changes, and being open to anyone causing unbounded
computation will be a DoS security vulnerability.  With enough other
issues being tackled, I nudge once more to reconsider such a change.

-Phil

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

Re: [Sks-devel] SKS apocalypse mitigation

[Phil Pennock]

On 2018-05-05 at 08:53 +0100, Andrew Gallagher wrote:
> > On 5 May 2018, at 08:48, Phil Pennock <sks-devel-p...@spodhuis.org> wrote:
> > If you peer with someone with no keys
> > loaded, it will render your server nearly inoperable.
> 
> I was aware that recon would fail in this case but not that the failure mode 
> would be so catastrophic. Is there no test for key difference before recon is 
> attempted?

It's the calculation of the key difference which is the problem.  That's
what recon is.

Recon figures out the difference in the keys present.  It's highly
efficient for reasonable deltas in key counts.  Yaron Minskey wrote
papers on the topic, leading to his academic degree; they're linked
from:
  https://bitbucket.org/skskeyserver/sks-keyserver/wiki/Home

After recon figures out what the local server needs, it then requests
those keys using HKP.

While you could modify the protocol to do something like announce a
key-count first, that's still only protection against accidental
misconfiguration: worthwhile and a nice-to-have if there's ever an
incompatible protocol upgrade anyway, to have a safety auto-cutoff to
back up the manual checks people do, but not protection against malice.

Fundamentally, reconciliation between datasets requires computation.
You can add safety cut-offs, and rate-limits per IP and CPU limits per
request and various other things, but none of those help if you're
trying to protect the keyservers from a half of the apocalypse
scenarios.

-Phil

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

[Sks-devel] sks-peer.spodhuis.org: migration & changes

[Phil Pennock]

Folks, I've moved sks-peer.spodhuis.org, details below.  If you're a
peer and not happy at this change, let me know and we can de-peer.

Before: jail on a FreeBSD box in private colo in NL.
Now: EC2 instance in Paris (eu-west-3) running Ubuntu Bionic.

The service is mostly the same, no changes to HTTPS identity,
administrators, etc etc.  Just moved to be isolated.  However, I'm
currently running on the default sks package, so without the long-keyid
patch.

The AMI is my own, built from the official Ubuntu Bionic Beaver 18.04
AMI (ami-f3211396 in us-east-2) using Packer, which did the basic
tuning.

I'm using /srv/sks as a separate EBS volume which can be detached.  I
built using a c5.large instance, which was nice and fast, with the
storage being a 100GB provisioned-IOPS volume.  After building and
debugging, I nuked the c5.large, downgraded the volume to GP2, and made
a t2.small, which is what I'm running with now.

IP addresses should be stable: it's an elastic IP for IPv4, and a
standalone ENI which has the IPv6 address, so that shouldn't change
either: if I rebuild, I'll reattach.  The DNS is unconnected to AWS and
is DNSSEC-signed, so the IPs should be verifiable.

Mailsync is not yet enabled.  My peering spidering is not yet live on
this new host.  At some point I'll probably recreate the entire thing on
FreeBSD, if only because of ... severe philosophical differences with
systemd-resolved and the amount of head-banging it took to get Unbound
in service.

But it's there, it's live.  Let's see if this one can manage to stay up
without the BDB layer suddenly deciding it can't find anything.

-Phil


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

Re: [Sks-devel] Anyone successfully running SKS on FreeBSD 11.1 ?

[Phil Pennock]

On 2018-04-12 at 14:35 +, Daniel Austin wrote:
> Both of my SKS instances are running under FreeBSD 11.1-RELEASE-p8 (amd64) 
> (i've not installed -p9 yet)

> I use my own package builder, but here's my details for ocaml package:

Poudriere?  Me too.  Alas:

> Version: 4.02.3

This is the version of OCaml I'm deliberately avoiding because it's
generating code susceptible to integer overflows.

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223039

-Phil

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

[Sks-devel] Anyone successfully running SKS on FreeBSD 11.1 ?

[Phil Pennock]

I updated my system from FreeBSD 10.3 to 11.1, which for the most part
has gone far better than expected.  The one dark spot is SKS.

The daemon keeps running away chewing CPU and not responding; ktrace
shows that it's doing nothing but _umtx_op() calls, which is kernel
support for userland threads.

OCaml 4.05.0 and my own patched code, so it's possible that I broke
something at some point in my patches.  Berkeley DB 5.3.  Code unmodified
since the version which was running fine on FreeBSD 10.3, only
recompiled since then.

I did a fresh keydump download and install; it took around 8 hours for a
fastbuild, which is significantly longer than I expected.  (Dell
Poweredge hardware, Intel etc etc).

If there's anyone out there on FreeBSD, can you share tips please?
Anything in particular you did to build with an OCaml other than the one
in Ports, which has the "generate code susceptible to integer overflow
attack" vulnerability?  My knowledge of the OCaml ecosystem is poor, I
poked and prodded until I got ocamlbrew appearing to give me working
binaries and I followed the exact same steps when I rebuilt.

Thanks,
-Phil


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

[Sks-devel] New wiki page: TLS Configuration

[Phil Pennock]

Folks,

  https://bitbucket.org/skskeyserver/sks-keyserver/wiki/TLS%20Configuration

New wiki page.  Explains the issues with TLS configuration, says what
should be done, and has a section for walk-throughs on a
per-frontend-server basis.  That section has been populated with one
initial sub-section: nginx.

Feedback welcome.  Extra server configs welcome.

This was inspired by DKG mentioning TLS session tickets and my thinking
"good point" followed by "hrm, we should document this some more".

Regards,
-Phil


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

Re: [Sks-devel] SKS apocalypse mitigation

[Phil Pennock]

On 2018-03-24 at 19:01 +0100, Kristian Fiskerstrand wrote:
> I agree with this as well, UAT generally have very limited value, so if
> we introduce a filter to skip all UATs I'm all fine with making that a
> requirement across severs in sks-keyservers.net pools. That isn't
> something that restricts servers overall, but anyhow...

We can do this without incompatibility-triggering filters and without
flag days.

We have KDB and PTree.  Add a third DB, Filtered.

The Filtered does not store the values, only the keys of things "we
don't want".  Value might record a reason and a date, for debugging.

Treat items in Filtered as part of "what we have" for reconciliation to
find the set difference.  That way you never request them.  Return HTTP
"410 Gone" for attempts to retrieve things which are marked Filtered.
That way clients don't try to authenticate and you just say "that might
have once existed, but no longer does".  Include a custom HTTP header
saying "SKS-Filtered: something".

Then it's a policy change to not accept UATs and to mark them as things
to be filtered out instead, and a clean-up tool to walk the existing DBs
and decide what should be in Filtered.  There will be down-time of some
extent, since SKS doesn't like sharing the DBs.

An SKS version which understands "SKS-Filtered:" headers will add an
entry to its own Filtered DB but _not_ delete stuff already in other
DBs.  It should record "I've seen that some peers are unwilling to
provide this to me, I can mark it as unavailable and include it in the
set of things I won't request in future".

Refusing to delete is a protection against someone finding a loophole
where information about other attributes is returned in response for a
request for one attribute, where a bad peer could delete data on your
server.

You won't be asking through reconciliation for something you already
had, thus the deletion prohibition won't be an issue.  You can probably
default to not allowing upload of anything which is in Filtered.  This
provides a DoS opportunity for someone malicious to try to prevent new
signatures flowing.  *shrug*

Each server can update at its own pace, but the pool definitions can be
changed, to encourage a certain pace.  Servers which continue to not
understand 410/SKS-Filtered: will keep asking for keys, becoming more
and more of a burden on others, so there will be incentive to drop
peering before too long.  But returning 410 should be a fast lookup and
the burden not too heavy, so we can afford to give it a 4-6 month window
of interop.

If you want your keys available, always, then take steps to host the
service which makes them available.  WKD, Finger, just an HTTP server,
something.  (Notably, most of these leave a trail of accountability,
unlike the PGP keyservers).  The SKS flood-fill public pool is living on
borrowed time and is not a strategy for continued availability.  We
keyserver operators are running something as a public good, for public
convenience, not operating critical infrastructure.  Disappearance of
public keyservers would be a major inconvenience, but not a disaster.

-Phil


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

Re: [Sks-devel] TLS 1.3 and HKPS pool

[Phil Pennock]

On 2018-03-23 at 13:55 +, Daniel Kahn Gillmor wrote:
> Sadly, SNI iand ALPN are both still in the claer in the TLS 1.3
> handshake.

Ah, thank you.  I hadn't read the draft, but have just read the relevant
parts of v26.  I don't recall what source I read which led me to believe
otherwise, other than that it was a source I considered reliable enough
to not double-check.  And now I've repeated misinformation.  I'm sorry.

-Phil

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

Re: [Sks-devel] TLS 1.3 and HKPS pool

[Phil Pennock]

On 2018-03-19 at 22:14 +0100, Kristian Fiskerstrand wrote:
> On 03/19/2018 10:08 PM, Phil Pennock wrote:
> > Do we care?
> 
> I'm tempted to say no..

Another point in favor of that: I'd forgotten that TLS1.3 moves
certificate exchange to be protected by the session, so encrypted.  Thus
I suspect that we won't have SNI available for choosing TLS versions and
ciphersuites until after TLS1.3 has already been negotiated.

I could do something like bring up another IPv6 address with a listening
server, but that would still need manual hacks in the pool-server
software to even know that IP address is worthy of consideration.

-Phil


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

[Sks-devel] TLS 1.3 and HKPS pool

[Phil Pennock]

Folks,

TLS 1.3 is nearing finalization and has done a bunch of work to try to
get through middleboxes, but will probably still cause issues for some
small percentage of clients behind corporate firewalls.

This will affect servers in pools which offer HKPS on port 443.  It
might lead to sporadic server failure for clients, after years of
getting better.

Do we care?

Is there anything sane to be done, for the pools?

I'm tentatively thinking that we can rely upon the
`*.pool.sks-keyservers.net` entry in the certs from Kristian's pool, to
add an experimental `tls13.pool.sks-keyservers.net` pool; we could ask
keyserver operators to hold off on enabling TLS1.3 on the normal vhost
and set `tls13` to be willing to negotiate TLS1.3.

Any PGP client which doesn't match wildcards ... won't be affected
unless and until someone tries to use the new name.

Thoughts?  Anything along the lines of "yes, but only for one year, then
we will want it in the main pool"?  _Anything_ other than "whatever, we
don't care" will require more checks from the pool maintenance software.

(Various bits of tuning available for experiments but not sure of the
utility of them; eg, `tls13-min`, `tls13-only`, and so forth).

Regards,
-Phil


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

Re: [Sks-devel] Operational question for all

[Phil Pennock]

On 2018-03-14 at 01:26 -0400, Jeremy T. Bouse wrote:
>     First of all the cluster is in a private subnet with no direct
> internet so it gets NAT'd outbound from an IP address that would not
> match the inbound IP address to be used.

Membership tests from your peers would reject this.

>As I understand it the gossip port (11370/tcp) is not
> HTTP based so it couldn't go through an ALB (application) and would need
> to be pass-thru so that would mean NLB (network) or ELB (classic). The
> HKP port (11371/tcp) could still be ran through any LB but since you can
> only have a container configured to join one LB that would likely mean
> needing to use an ELB so I could perform pass-thru for gossip and
> HTTP/HTTPS for HKP port wheere the NLB would just pass-thru both to the
> container.

Oh eww, I'd missed that ECS containers can only be in one LB.  That's
... horrible.

How about using IPv6 and peering IPv6-only?  As long as you don't set
the v6 gateway to egress-only, and if you set the networking mode to
`awsvpc` then you get ENIs on each task ... though I'm not seeing a way
to attach a persistent ENI to get fixed addresses.

It might be worth considering dynamic DNS which is updated every time
a task is started or stopped, so that you peer with a changing set of
IPv6 addresses?

Or wait to see what Amazon announce in their EKS tech talk on Monday, to
see if their EKS will be flexible enough that a Kubernetes service
definition could be rigged up which lets you use the same IP for inbound
and outbound?

-Phil

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

Re: [Sks-devel] Out of the pool

[Phil Pennock]

On 2018-01-26 at 09:48 +0100, Kiss Gabor (Bitman) wrote:
> > If enough people are sending the signal to regenerate stats every hour,
> > then the distribution of total key counts would cluster around a higher
> > value, so that people who rely solely upon daily key generation might
> > drop more than two stddevs below the mean (of numbers after outlier
> > exclusion).

> BTW. Let's assume a TLA wants to control HKP traffic of a target
> person. (Someone who is worthing some investments like Snowden or
> Assange.) A possible attack vector is this:

A few innocent servers which announce a high fake number are likely to
be dropped in the first-pass outlier exclusion, the bit which keeps
keyservers with 0 keys, or 10,000 keys, from dragging down the numbers,
and also any idiots who bump the number up far too far.

Then the mean and stddev are calculated over what's left, so "probably
reasonable" servers.  Which might include some which are too many.

But part of the point of "mean - 2*stddev" (which, from memory (not
rechecked) is the approach Kristian copied from me :) ) is that if the
spread increases because of that sort of behavior, then the stddev
increases.  Assuming a normal distribution, you'd be dropping the
smallest 2% of servers.  Assuming a non-normal distribution, you're
still only dropping a small percentage.

Thus if a server is only calculating stats once per day, then with
enough servers calculating hourly, and a high enough rate of new key
influx, it's conceivable that you'd get dropped.  It's why there's also
a fudge-factor in the cut-off limit (300 or so, when I last looked) to
account for "how many updates in the course of a day" to let most
servers stay in the pool anyway.

The idea is to exclude _broken_ keyservers, since with SKS working the
keys will all get out "soon enough" anyway.

Fixes under keyserver operator control:
 * add a cron-job to signal SKS to regenerate stats

Fixes under Kristian's control:
 * use his stats on keyserver metrics to derive a better constant
   fudge-factor to keep most servers in the pool, and add a recurring
   calendar event to double-check that number every 6 months

Looks like the fudge-factor needs to account for 1200 new keys per day,
now.

-Phil

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

Re: [Sks-devel] Out of the pool

[Phil Pennock]

On 2018-01-24 at 09:59 -0600, Timothy A. Holtzen wrote:
> Interesting,  I think it is actually jumping in and out of the pool.  It
> was in briefly yesterday but then when the next check came around it was
> back out.  So maybe it is an intermittent problem or there is some kind
> of timeout happening.

If enough people are sending the signal to regenerate stats every hour,
then the distribution of total key counts would cluster around a higher
value, so that people who rely solely upon daily key generation might
drop more than two stddevs below the mean (of numbers after outlier
exclusion).

SKS has a signal (in the man-page IIRC) which will trigger an update of
the stats reported in the info page, and used by the pool maintenance
software to decide which keyservers are up-to-date.  Send that signal
once an hour, see if that changes the situation?

-Phil

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

[Sks-devel] Keyserver pools: show, don't tell

[Phil Pennock]

Folks,

Anyone can run a keyserver pool in DNS.  There are at least two
codebases for generating the data needed (I know of stuff in PHP and
Go).

The only thing special about Kristian's pools is that, in the opinion of
people making decisions which impact others, they've been well run for
long enough that they're worth using as a default.  (I run my own pool
as an experiment, because I wanted to learn and to not have a
monoculture, but in practice for real deployment, I use one of
Kristian's pools (when not using a specific server)).

So people point CNAMEs at one of Kristian's pools, and some of those
become bundled as default.  There's inertia, but mostly people are
sticking with demonstrated competence.

If anyone believes they can run pool definitions better, then do so.
Demonstrate that you can walk the walk, not just talk the talk.  Make
something which works, and work with other people to get them to buy
into your scheme, as Kristian did with his HKPS setup.

If you make something which is better, then folks will start to use it.
GnuPG might.  Any of the new competitors to GnuPG might.  GnuPG defaults
to a hostname under their control and can repoint DNS to a different
pool if they feel it appropriate to do so.

My own thoughts on the security model we have today:
  http://www.openwall.com/lists/oss-security/2017/12/10/1

In the absence of _showing_ a better _pool_ system, working in practice,
all this talk I've just forced myself to wade through is IMO not helpful
for SKS development or operations and not appropriate for this
mailing-list.

Once we have another pool with a different security model for TLS, which
operators can choose to start using, _then_ we have something which
might be relevant for this mailing-list.

-Phil, speaking only for myself.  I might be wrong.

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

Re: [Sks-devel] spodhuis keyserver down, pending OCaml CVE updates

[Phil Pennock]

On 2017-10-03 at 17:28 -0400, Phil Pennock wrote:
> TL;DR: sks-peer.spodhuis.org down until further notice, when I get time
> to investigate properly.  Down by administrator action.  No need to
> deconfigure peering.

I generated a PGP keydump as of the time I took it down and put the
files somewhere accessible:

http://pennocktech-pgp-keydumps.s3-website.us-east-2.amazonaws.com/20171004/

us-east-2 is in Ohio, USA.

(There's only one other keydump on the site, from May; I've got all the
steps documented to do full keydumps with only a brief outage, but
haven't gotten around to automating it).

-Phil

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

[Sks-devel] spodhuis keyserver down, pending OCaml CVE updates

[Phil Pennock]

TL;DR: sks-peer.spodhuis.org down until further notice, when I get time
to investigate properly.  Down by administrator action.  No need to
deconfigure peering.

Fuller version:

Today an advisory came through for Ubuntu updating their OCaml packages
to deal with a CVE in OCaml, where the compiler produces code which is
exploitable for code execution via buffer overflow.  Fixed in OCaml
4.03.

https://usn.ubuntu.com/usn/usn-3437-1/
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-8869

This appears to have been publicly discussed in April 2016, but not
patched for that OS until today.  I'm on FreeBSD.  My OCaml is 4.02.3.

http://www.securityfocus.com/bid/89318/discuss states that OCaml 4.02.3
and earlier are vulnerable.  I see no local patches in FreeBSD Ports.  I
have not investigated in depth, nor do I have time to investigate,
whether or not SKS is an exploitable path or whether all reads are
sufficiently bound that an attacker can't inject enough data to attack.

Because I don't have time for this, per https://sks.spodhuis.org/
> This service may be withdrawn at any time and without notice to
> end-users.  (Peers will be notified).

The service is temporarily withdrawn.  I don't think it's necessary to
update any peering configurations, just know that this is deliberate and
you don't need to reach out.

When I get time to look in more depth (not before this weekend as the
soonest opportunity) or if updates for the compiler come through on
FreeBSD and I can just install updated compiler packages and then
rebuild SKS, then service will be restored.

I'm not chasing this any further today.
-Phil


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

Re: [Sks-devel] hg workflow pointers

[Phil Pennock]

On 2017-08-11 at 00:50 -0400, Daniel Kahn Gillmor wrote:
> One thing that might really sway me here would be if we could support a
> distributed view of the bug-tracker as well, but i don't know of any
> service that does that effectively right now.

Some candidates for consideration are listed in:
  https://dist-bugs.branchable.com/software/

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

Re: [Sks-devel] How can I tell if the server running recon properly

[Phil Pennock]

On 2017-07-18 at 00:03 +0800, Shengjing Zhu wrote:
> Reconciliation attempt from unauthorized host 

So something in the setup is terminating external TCPv4 connections and
opening new ones to proxy onwards, or masquerading inbound connections.
This won't work well with SKS.

> I don't know why the host ip(where the docker runs) is shown there.
> Maybe the log means every peer's ip, that sks sees, is the ip of the docker
> host, not the real ip which peer's domain resolves. So I wonder do all
> my peers successfully recon with me in the past year?...

At a guess: IPv6.  [2001:da8:d800:f001::99] is probably routed directly
to the container.  So any of your peers with IPv6 connectivity is
exchanging keys with you over IPv6.

> Then I setup another instance to peer with it. It seems there's no
> problem even the confused log showed.

That will not be going through the docker host's masquerading.

> But I do want to know how can I ensure the recon is working properly in
> my docker environment.

Test with IPv4 connections _from_ outside the Docker
host/cluster/whatever.

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

Re: [Sks-devel] Error with sks-recon.service

[Phil Pennock]

On 2017-06-20 at 15:13 -0400, Lully Troconis wrote:
> I started a new SKS keyserver on agora.cenditel.gob.ve:11371 and add 4
> servers for peers, but the recon process don't start

> sks[972]: Fatal error: exception Bdb.DBError("BDB1546 unable to join the
> environment")

Did you do some DB maintenance work (eg, `db_recover`) as root instead
of as the SKS user?  Leaving DB files owned by root, instead of the SKS
user?  Or even the directories themselves?

I suspect that you need to stop all SKS processes, do a full `chown -R`
on the KDB and PTree directories, do a db_recover as the SKS user, use
`ls -l` to make sure all is happy, then try starting service back up
again.

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

Re: [Sks-devel] Issue caused by recon process using IP address instead of hostname

[Phil Pennock]

On 2017-06-13 at 14:24 -0400, Rob Debouter wrote:
> If I understand the recon process correctly, it reads the peers from the 
> membership file, performs a DNS lookup to retrieve the IP and uses the IP 
> address for all communications.  The TCP connection from client to server is 
> done on port 11370, receives a list possible key changes by hash values and 
> the client then attempts to connect to the server by IP:11371.
> 
> In my case, my reverse proxy returns an http 400 - invalid hostname response 
> during the recon process.  I'm using [2] as a reverse proxy instead of 
> something local on my node because it's a Raspberry Pi 3 and I didn't want to 
> take resources away from SKS.  I'm also already using this reverse proxy for 
> other applications so I'm using it for SKS as well.

To double-check, the problematic response is on port 11371, not port
11370, right?

This is part of why whatever listens on port 11371 must NOT use
virtual-hosting on port 11371.  Do whatever you want on ports 80 or 443,
but all traffic on 11371 needs to be passed through.  This shouldn't be
a hardship, nothing else should be expecting to listen on that port.

If you don't pass through on 11371 then you also can't be part of the
public pools, where you don't know ahead of time the hostnames or CNAMES
to pools which might be used (eg, keys.gnupg.net points to
pool.sks-keyservers.net at present).

And if you're not part of the public pools, then others might ask why
they should pay for bandwidth and processing to provide a service to
you.  Some people will shrug and be happy to, but others won't.

The SKS mesh is very informal, but works through almost everyone
choosing to provide public service back.  You can run private servers
peering to one public server, and do whatever you want on those, but
everyone chips into the public pool first.  (Various servers can be seen
peering with publicly-unresolvable names, so we know this is happening,
and the more surreptitiously-inclined might choose to alter the SKS
codebase to just not report some peers when asked by the outside world.)

-Phil

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

Re: [Sks-devel] Long-form keyids and ocaml 4.02.3

[Phil Pennock]

On 2017-06-05 at 00:31 +0200, Kristian Fiskerstrand wrote:
> which is used in cryptokit, which brings up the question of not
> embedding it in [2]

Sounds sane to me.

For clarity, the only part of the PR which touches cryptokit is an
update to the `.hgignore` file, to exclude the extracted files so that
Mercurial behaves better when creating commits.

Since mercurial supports globs in `.htignore`, it might be better to
just switch to `cryptokit-*` if this needs to be kept at all after
dropping cryptokit.

I don't think that dropping cryptokit blocks this PR; in fact, having
this PR makes it easier to use newer OCaml and thus move forward.


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

Re: [Sks-devel] Long-form keyids and ocaml 4.02.3

[Phil Pennock]

On 2017-06-04 at 17:41 +0200, Kristian Fiskerstrand wrote:
> Should be a pull request against the main repo for that. The
> build-cleaner patches are likely most interesting, and dkg has some work
> on it already.

Ah, didn't know we'd switched to a PR model.

https://bitbucket.org/skskeyserver/sks-keyserver/pull-requests/52/build-cleaner/diff

Once that's in, can look at the other.

>The last time I looked into it a number of the issues
> we're seeing in build is related to cryptokit, and we likely should
> discuss whether its time to dis-embed the library from the source (

No problems with cryptokit for me, using 1.7.  I see from Mercurial
commit-log that this doesn't build with older versions of OCaml.  It
looks like this comes down to being willing to specify which version
ranges of the OCaml releases we're supposed to work with.  How far back,
at what price?

> The 64 bit keyid references etc are not necessarily material, we use
> those for internal identifiers anyways but don't display it in the
> WebUI.

I know.  I needed the long form in the UI to be able to copy/paste data
for analysis and have a reasonable set of keyid specifiers to use.  The
UI is more than just "looks pretty" (or not).

So the patch is entirely about exposing the long-form to those using the
keyserver.  https://sks.spodhuis.org/ has this functionality, with the
HTML form on that page including the option to turn it on or off, so
people can decide if it seems useful.

> People should download the public keyblocks and do their own
> operations on them given their own trustdb/wot calculation rather than
> relying on a third party that doen't provide a security assertion to
> begin with.

When folks are deliberately colliding the short-form, it's useful to be
able to point others at listings which cover enough to look at, without
folks having to download and install tools locally.  It's not perfect,
sure, but when you look at:

  https://sks.spodhuis.org/pks/lookup?op=index=on=0x70096AD1
  https://sks.spodhuis.org/pks/lookup?op=index=on=0xC1DB921F

it's enough to tell them apart and determine what to call them to tell
them apart when discussing them.

It lets me point to the collisions and say "Look at these keys claiming
to belong to Gunnar Wolf; the 673 one claims to predate the 15F one, but
how do we know for sure?" and leads into a better discussion.

-Phil


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

[Sks-devel] Long-form keyids and ocaml 4.02.3

[Phil Pennock]

On 2017-01-16 at 18:36 -0500, Phil Pennock wrote:
> On 2017-01-16 at 16:56 -0500, Phil Pennock wrote:
> > sks-peer.spodhuis.org (serving clients as sks.spodhuis.org) is currently
> > reporting version 1.1.6+; if it stops reporting "+" then I discovered
> > something broke and reverted.
> > 
> > The code is the build-cleaner branch in my bitbucket clone:
> > 
> >   https://bitbucket.org/philpennock/sks-keyserver-philp/branch/build-cleaner
> > 
> > There are two changesets:

> The code running now includes two more changesets, which can be seen at:
> 
>   https://bitbucket.org/philpennock/sks-keyserver-philp/branch/opt-long-keyids
> 
> On the SKS keyserver, including the `longkeyid` bool flag in the query
> string will result in the visible display including the 16-character
> format keyid.
> 
>   
> https://sks.spodhuis.org/pks/lookup?op=vindex=0x4D1E900E14C1CC04=on
> 
> Use https://sks.spodhuis.org/ to see this in action: it's in the form as
> an option.

This has been stable for the past five months; one initial instance of
corruption appears to have been a coincidence around DB startup and
probably my messing up something with the snapshots.  Everything has
been stable and reliable.

I just pushed one more commit on the branch, so that the long-form keyid
will also appear in non-verbose indices.  Before, it was in verbose
indices and would propagate through as a URL parameter, but didn't
actually affect the visible rendering in non-verbose (op=index rather
than op=vindex).

https://sks.spodhuis.org/pks/lookup?op=index=on=0x4D1E900E14C1CC04

So we have newer-OCaml cleanup in the first branch "build-cleaner" and
then some desirable feature changes in a subordinate branch
"opt-long-keyids".

Anyone with commit on the main repo want to consider merging these?

-Phil


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

Re: [Sks-devel] wserver_timeout value causing cascading failure?

[Phil Pennock]

On 2017-04-24 at 13:53 -0400, Jonathon Weiss wrote:
> An important note here is that I'm using Apache as a proxy for SKS (on
> 80, 443, and 11371).
> 
> If I understand how SKS works, it can accept and hold onto multiple
> client connections at once, but only processes them serially.

> 3) Any suggestions on what to do if/when wserver_timeout=1 becomes
>insufficient?

The general model for tiered servers proxying connections is that each
server uses a timeout for the backend, or is given a timeout by the
backend, a little less than the timeout for the requests inbound to the
server.  "Tower of Hanoi Timeouts", per:

  https://medium.com/@liquidgecka/tower-of-hanoi-timeouts-c9476d96ca4b

That's based on an assumption of parallel handling by the backend; for
the SKS case, using ToHT along with making sure that the reverse proxy
only hands off one connection at a time should avoid the cascade.

Also: what does SKS do with multiple requests on one connection, does it
answer each, thus not getting around to requests on the next connection,
ever?

I haven't used Apache in some years, but from
https://httpd.apache.org/docs/trunk/mod/mod_proxy.html I think that you
want:

  ProxyPass "/pks" "http://localhost:11371/; max=1 disablereuse=On

-Phil

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

Re: [Sks-devel] Peers

[Phil Pennock]

On 2017-04-05 at 23:30 +0200, Peter Sunde Kolmisoppi wrote:
> Setting up a keyserver and looking for peers!
> The machine is located in sweden and will be used for research and internal 
> pgp signing / checking, and not public facing.

If the :11371 port is open to the world, to support roaming users, then
you're going to end up in the public pools anyway.

Every keyserver exports its status on a special URL, including a list of
which services it peers with.  Anyone can then spider the mesh and build
lists of keyservers.  This is how sks-keyservers.net does it and that
pool is what keys.gnupg.net is aliased to.

So either you'll need to not allow :11371 outside your network, or
you'll need to arrange with pool operators to be manually excluded.  The
only pool operator I know of which is worth worrying about is
sks-keyservers.net.

-Phil

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

Re: [Sks-devel] ECC HTTPS certs for HKPS

[Phil Pennock]

On 2017-04-02 at 18:07 +0200, Kristian Fiskerstrand wrote:
> But I'm really more curious to arguments to switching to ecc in general :)

My argument is to switch to being dual-stack RSA+ECC and confirming that
this can safely be done, and providing a single-stack keyserver to make
it easier to test what would happen in a world where RSA is disabled.

Algorithmic breaks could come at any time.  I'd be much happier without
one, but I also like to have contingency plans in place.

For SSH, I have RSA+NISTECC+Edwards keys and push the three as a group
to anywhere which takes them.  I can disable one and not suffer on most
services.  A couple of services which are RSA+DSA only will break if RSA
is the one to go, since DSA in SSH maxes out at 1024 bits so I don't use
it.

For TLS, the draft adding Edwards curve stuff is nearing RFC publication
(AIUI) so we're close to having Ed25519 in TLS.

I'd like to know that I could disable the first to break (eg, NIST ECC)
and still have the others work.  I could even temporarily disable all
RSA in the event of implementation vulnerability disclosure (again)
until I get a chance to patch the stack and then generate fresh keys.

The goal being to keep working and not cut things off suddenly but to
always have a Plan B.  The details of ECC vs CEILIDH vs Naccache–Stern
vs Purple Fairy Dust are irrelevant, it's "having a Plan B" that I care
about.

-Phil


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

Re: [Sks-devel] ECC HTTPS certs for HKPS

[Phil Pennock]

On 2017-03-31 at 20:47 -0500, Daniel Kahn Gillmor wrote:
> thanks for doing this testing, Phil.  Can you clarify what you mean by
> "dual-stack" ?  do you mean "offering both RSA and ECC certs" or
> something else?

Yes, "RSA and ECC".  Sorry, thought I'd captured all the times I wrote
"dual-stack" in this context.

On 2017-04-01 at 13:19 +0200, Pete Stephenson wrote:
> ECC and/or RSA before presenting the appropriate certificate. However,
> the difference between theory and practice is that in theory, there is
> no difference.

Indeed, thus my post.  :)

We need to know it won't break clients.  So, setting up a keyserver
where dual-stack is present and asking people to point clients at it,
should help.

-Phil

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

[Sks-devel] ECC HTTPS certs for HKPS

[Phil Pennock]

Folks,

Is anyone interested in testing client/tooling interop with an HKP
keyserver (SKS) which has ECC keys/certs in front of it?  I need to
renew my sks-keyservers cert within the next month and when I asked
Kristian last year, dual-stack was to-be-investigated, so I figure I
should investigate a little now.

Hostname below.
Certs are from my private CAs because dual-stack is a pain with the free
CAs I know of and I'm not spending $$ on this experiment.  :)

Tested with GnuPG 2.1.19 on three OSes and works fine.  The key is going
to depend upon the TLS support of the OpenPGP client; for sufficiently
recent GnuPG, I _think_ that's normally GnuTLS, although ntbtls might
sometimes be used?  What other HKP-speaking OpenPGP clients are folks
using?  What about other tooling, for admin work?  Does anything break
with dual-chain RSA/ECC?

* Linux GnuPG=2.1.19 GnuTLS=3.4.17 works
* FreeBSD GnuPG=2.1.19 GnuTLS=3.5.9 works
* macOS GnuPG=2.1.19 GnuTLS=3.5.10 works
... which pretty much just tells me that modern GnuTLS handles ECC just
fine.  I'd like reports from older libraries, and other OpenPGP clients,
please?

CA roots available, with PGP detached signatures, from:
  https://www.security.spodhuis.org/
and you minimally need the `globnixCA5` root for ECC.

The keyserver is my usual keyserver, just accessed under some different
hostnames.

 * hkps://keyserver-ecc-nist.spodhuis.org
 * (currently the same: hkps://keyserver-ecc.spodhuis.org )
 * hkps://keyserver.spodhuis.org

The keyserver.spodhuis.org setup is dual-stack with RSA and ECDSA both.
(RSA cert from `globnixCA4`).

That dual-RSA/ECC hostname also has SRV records which GnuPG 2.1.19 both
uses and unfortunately caches the ports cross-scheme, so if you
accidentally use hkp:// or schema-less access and then try hkps://
you'll get errors because of the GnuPG bug.  `gpgconf --kill dirmngr` is
the easiest way to nuke it and let it be restarted with a clean slate.

(At some point in the future, "keyserver-ecc" will be dual NIST/X25519
certs, which is why it exists now; the X25519-in-TLS draft is AIUI
nearing publication as an RFC).

With GnuPG, the CA PEM needs to be included in the file named in the
`hkp-cacert` configuration option, in ~/.gnupg/dirmngr.conf for newer
GnuPG or ~/.gnupg/gpg.conf for older GnuPG and then used with:

  gpg --keyserver hkps://keyserver-ecc.spodhuis.org --recv-key 
0x4D1E900E14C1CC04


Thanks,
-Phil


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

Re: [Sks-devel] CNAMEs for sks pool

[Phil Pennock]

On 2017-02-19 at 16:59 -0500, Fabian Santiago wrote:
> may i ask, what are all of the CNAMEs for the pool? Thanks.

Nobody knows for sure.  There can be arbitrary names.

This is covered in:
  https://bitbucket.org/skskeyserver/sks-keyserver/wiki/Peering

  Beware that for port 11371 traffic, you must be able to handle
  requests with any Host: header, for the various pools and CNAMEs which
  exist, and you must accept requests with no User-Agent: header set, as
  at least one major OpenPGP HKP client refuses to set a User-Agent
  field when talking to keyservers.

You don't need to accept unknown names on ports 80/443.

The most _common_ CNAMEs are at:
  https://www.sks-keyservers.net/overview-of-pools.php
and also "keys.gnupg.net", which points to one of those.

Other people can set up their own CNAMEs; Kristian's service is widely
used, including by gnupg.net, but not in any way especially privileged.

-Phil

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

Re: [Sks-devel] Long keyids (64-bit) instead of short (32-bit)?

[Phil Pennock]

On 2017-01-25 at 13:04 -0600, Gunnar Wolf wrote:
> Anyway — I was looking for a way to make SKS present 64-bit long
> keyids (say, 673A03E4C1DB921F) instead of only 32-bit ones — Not only

https://bitbucket.org/philpennock/sks-keyserver-philp/branch/opt-long-keyids

See my recent post to the list, subject-line mentioning ocaml.

I've been running with these changes and they seem stable.  I had one
bout of BDB corruption but (1) db_recover fixed it and (2) it hasn't
reoccurred so I'm starting to think that it's just coincidental timing.

If you're not building with the 4.02.whatever ocaml then read the
messages in the thread, see the other branch which had those changes and
generate a patch from the commits only in the opt-long-keyids branch.

> Any ideas on how to do this? Is it a configurable option even (or
> should we expect this change only for a new release)?

It would have to be a new release.  Someone actually experienced with
ocaml needs to look at my changes and decide which are safe to pull in.

-Phil


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

Re: [Sks-devel] spodhuis keyserver: ocaml 4.02.3

[Phil Pennock]

On 2017-01-16 at 16:56 -0500, Phil Pennock wrote:
> sks-peer.spodhuis.org (serving clients as sks.spodhuis.org) is currently
> reporting version 1.1.6+; if it stops reporting "+" then I discovered
> something broke and reverted.
> 
> The code is the build-cleaner branch in my bitbucket clone:
> 
>   https://bitbucket.org/philpennock/sks-keyserver-philp/branch/build-cleaner
> 
> There are two changesets:

Oh right, there was a reason I went into this code in the first place.

The code running now includes two more changesets, which can be seen at:

  https://bitbucket.org/philpennock/sks-keyserver-philp/branch/opt-long-keyids

On the SKS keyserver, including the `longkeyid` bool flag in the query
string will result in the visible display including the 16-character
format keyid.

  
https://sks.spodhuis.org/pks/lookup?op=vindex=0x4D1E900E14C1CC04=on

Use https://sks.spodhuis.org/ to see this in action: it's in the form as
an option.

(I wanted to be able copy/paste something where I needed the long-form
for a bunch of sigs).

-Phil


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

[Sks-devel] spodhuis keyserver: ocaml 4.02.3

[Phil Pennock]

sks-peer.spodhuis.org (serving clients as sks.spodhuis.org) is currently
reporting version 1.1.6+; if it stops reporting "+" then I discovered
something broke and reverted.

The code is the build-cleaner branch in my bitbucket clone:

  https://bitbucket.org/philpennock/sks-keyserver-philp/branch/build-cleaner

There are two changesets:

 * stop hard-coding gcc; ocaml on FreeBSD is built with clang and since
   I switched sks to clang a year ago, I've had no more issues with
   "badness" when telling sks to write stats via signal from cron.

 * make it compile with ocaml 4.02.3

The dev mode forces warnings to be errors; since I was in here anyway,
and I have 4.02.3 as the system ocaml, I decided to hack away grossly to
get things working again.

The main issues appear to my ocaml-naive eyes to be that a bunch of
aliases in StdLabels are giving deprecation warnings, and the syntactic
sugar for setting a byte in a string via `<-` is not available with the
replacement BytesLabels module.

In the first few files, I only changed the places which had to be
changed to get the source to compile, deciding that if stuff like
String.length was type-happy then so was I.  I got a little more
aggressive in later files.

A few apparently-unused functions got deleted, because they led to type
complaints.  Strange that the only remaining functions to cause issues
were all unused.  I'm hoping that there's no
reflection-constructing-function-names magic going on.

I see key retrievals happening, and uploading an existing key with no
changes works fine, so I'm just leaving this running to see what
happens.

(Before switching binaries, I stopped SKS, did a DB recover and took a
filesystem snapshot, so worst case scenario I restore the snapshot and
downgrade the binary to release, then catch up on some missing updates).

-Phil


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

Re: [Sks-devel] Searching for freebsd leads to server crash, http erro 500

[Phil Pennock]

On 2017-01-15 at 14:50 +, David Evans wrote:
> Seaching for 'freebsd' leads to a server crash with exceptions raised and 
> returning http error code 500 - internal server error.

Trying on my server:

-8< cut here >8-
2017-01-16 16:01:09 Error handling request 
(GET,/pks/lookup?op=index=freebsd,[
accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
accept-encoding:gzip, deflate, sdch, br
accept-language:en-US,en;q=0.8,en-GB;q=0.6
connection:close
dnt:1
host:sks.spodhuis.org:443
referer:https://sks.spodhuis.org/
upgrade-insecure-requests:1
user-agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_2) AppleWebKit/537.36 
(KHTML, like Gecko) Chrome/55.0.2883.95 Safari/537.36
x-forwarded-for:192.0.2.1
x-real-ip:192.0.2.1]): Invalid_argument("Too many responses")
-8< cut here >8-

(I've stripped my real current IP)

The server is still running.  It has not crashed.  It errored and
returned an appropriate HTML page in a 500 HTTP response.

So an exception was raised, and was handled, because there were too many
matches.

I'm not sure I want a public interface trying much harder to put load on
my machine when handling anonymous queries.  Perhaps a total count would
be nice, but ... I can live with the current behaviour as acceptable.

If you want to do serious analysis on basic keywords, I suggest grabbing
one of the public dumps of the dataset and doing off-line analysis.

-Phil

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

Re: [Sks-devel] Advertising temporary disconnections?

[Phil Pennock]

On 2017-01-10 at 18:49 -0600, Gunnar Wolf wrote:
> I have seen several messages lately on this list regarding temporary
> (i.e. a day or two, AFAICT) server disconnections.

> [...]  means that either they won't act on
> it, or that they will need to manually disable/re-enable my server in
> their membership files... I never felt the need to say publicly.
> 
> Now, what would the general feeling be on this? Do we expect
> privately-run SKS servers to have a four-nines, five-nines or such
> uptime?

My thoughts:

There's no expectation of uptime, but there are people who check into
the status of their peerings and shoot out messages saying "Hey, did you
know that your server is down?" or perhaps just bulk-disable servers
which are down when they happen to look.

I don't expect my peers to manually disable/re-enable their peering with
my server if I announce maintenance.  There's no need: the
reconciliation will handle it fine.  You only really need to worry about
peers which are far behind in key count, because of the burden.

The announcement is thus not a request for action.  It's a notice to
support inaction: "Don't worry about it, it's expected, all is fine,
don't spend your time digging into it or mailing me."

I'm interested in knowing about other opinions.

-Phil

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

Re: [Sks-devel] Server Broken

[Phil Pennock]

On 2016-11-20 at 22:52 +, Yaakov M wrote:
> I am really Thinking other alternatives to SKS with stronger Database
> any ideas ?

A list of known PGP keyservers is at:

  https://people.spodhuis.org/phil.pennock/pgp-keyservers

You probably want to look at HockeyPuck, which uses PostgreSQL as a
backend.

-Phil

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

Re: [Sks-devel] peer request for pgp.uplinklabs.net

[Phil Pennock]

On 2016-08-30 at 06:52 -0700, Steven Noonan wrote:
> I'm looking for peers for a new SKS keyserver installation.

When validating your email, GnuPG 2.1.15 complains:

gpg: WARNING: This subkey has been revoked by its owner!
gpg: reason for revocation: Key is no longer used
gpg: revocation comment: gpg 2.1 stored the private key in a funny place

Want to try again signing with a subkey which has not had a revocation
signature published?  :)  (That subkey only seems to exist at all on
your keyserver, not others, so if not using your keyserver, we can't
verify).

Regards,
-Phil


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

Re: [Sks-devel] Peer request

[Phil Pennock]

On 2016-08-29 at 23:52 +0100, Danny Horne wrote:
> Just noticed (unless that's a typo) that you're about 4,000 keys short
> of the current numbers.  When did you take this dump and was it the most
> current?

   Date New Updated
2016-08-29  938 929
2016-08-28  678 943
2016-08-27  623 432
2016-08-26  863 382
2016-08-25  1008372
2016-08-24  950 427
2016-08-23  963 522
2016-08-22  840 468

So we're running at 6023 new keys since the 22nd, so 4000 behind seems
perfectly reasonable for "a recent keydump from within the past week".

Most dumps are weekly.

-Phil

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

Re: [Sks-devel] Get SKS to listen on port 80

[Phil Pennock]

On 2016-08-25 at 21:37 +0100, Danny Horne wrote:
> I've googled this and can't find an answer.  The SKS man page states -
> 
> -use_port_80
> Have the HKP interface listen on port 80, as well as the hkp_port.
> 
> I've added 'use_port_80:'  to sksconf but it doesn't listen on port 80

Port 80 is a privileged port, being numbered less than 1024.  On Unix
systems, by default, you require elevated privileges to be able to bind
to that port.

Dedicated web-servers typically start as root to do things like bind
ports before dropping privilege to a run-time user.  Since SKS is
"single-request-at-a-time", with no ability to handle concurrent
requests, one slow request by one user can slow everything down.  Thus
roughly everyone today puts a reverse proxy in front of SKS, to handle
the requests and get the SKS communication done as quickly as possible,
not blocking other requests.

You probably should not run SKS as root.  If you _really_ want to have
SKS directly bind port 80, then look into what your OS requires for
this.  On a Linux system, the `CAP_NET_BIND_SERVICE` capability should
suffice; if your filesystem permits capabilities, then:

setcap cap_net_bind_service=+ep /path/to/executable/of/sks

But really, really truly, please just use a reverse proxy which can
handle caching, static assets, and batching access to the "real" SKS.

Many helpful instructions are in:

  https://bitbucket.org/skskeyserver/sks-keyserver/wiki/Peering

Regards,
-Phil

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

Re: [Sks-devel] sks-peer.spodhuis.org maintainer PGP key update

[Phil Pennock]

On 2014-08-29 at 14:22 -0400, Phil Pennock wrote:
> I have a new(ish) PGP key, which is in the strong set and which I am now
> finally set up to conveniently use with email, so I can switch away from
> using my old 1024/DSA key 0x403043153903637F.
> 
> I am now using 0x4D1E900E14C1CC04 4096/RSA.  This key is signed by the
> old one, with a signing policy statement which references text saying
> "it's one of my keys", so rather than mess around to try to send this
> one message with the old key, I think this should be sufficient for
> folks to verify authenticity.
> 
> pub   4096R/0x4D1E900E14C1CC04 2013-10-22
>   Key fingerprint = ACBB 4324 393A DE35 15DA  2DDA 4D1E 900E 14C1 CC04
> [...]
> sig 3   P0x403043153903637F 2013-10-22 never   Phil Pennock 
> 
>Signature policy: https://www.security.spodhuis.org/PGP/policy/self
> 
> If you are peering with me, please update your membership line with:
> 
> sks-peer.spodhuis.org 11370  # Phil Pennock <keyser...@spodhuis.org> 
> 0x4D1E900E14C1CC04

Just to say: I'm about to issue a superseded revocation for the old key,
so if you still have 0x403043153903637F listed in your membership file
for me, please do switch it to record: 0x4D1E900E14C1CC04

pub   rsa4096/0x4D1E900E14C1CC04 2013-10-22 [SC]
  Key fingerprint = ACBB 4324 393A DE35 15DA  2DDA 4D1E 900E 14C1 CC04

Since the old key is about to be revoked, I'm only signing this email
with the newer key; the signature policy should provide assurance that
the holder of the old key asserts that the "new" key replaces it.

After almost three years and a Strong Set MSD of less than 5, I think
it's safe to switch, and more formally revoke the old key.

-Phil


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

Re: [Sks-devel] spodhuis keyserver: status update

[Phil Pennock]

On 2016-08-17 at 06:29 +0200, Gabor Kiss wrote:
> According to
> https://sks-keyservers.net/status/ks-status.php?server=sks.spodhuis.org
> you did not delete keys.niif.hu, however we are not peering since 2011.

Oh?  What happened to trigger the removal on your side?

> Generally the "Cross-peered" column of the table shows that you have
> only six real peers.

That's buggy.  I _peer_ under the name `sks-peer.spodhuis.org` and
always have done, and that's always been what I ask peers to put in
their membership files: the serving name and the peering name are
distinct, for reasons which I've outlined before.

I've just sampled a few of those "Not OK" entries and they're all
peering correctly with "sks-peer.spodhuis.org" but the status page is
failing to handle that and reporting as "Not OK".

This is a bug on Kristian's side.
The peering itself works just fine.

So in fact, six of my peers are incorrectly listing "sks.spodhuis.org"
instead of "sks-peer.spodhuis.org" and as a result are showing up as
"OK".

Regards,
-Phil

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

Re: [Sks-devel] couple questions

[Phil Pennock]

On 2016-06-10 at 18:45 -0400, Fabian Santiago wrote:
> You're right, it does work that way and I have it up now as such. I was hung 
> up I guess on why it doesn't work as advertised.
> 
> See attached strace. This is above my head.

This strace'd systemd but did not strace sks itself.

SKS by default loads the configuration file as `./sksconf`, so whatever
the working directory of the `sks db` and `sks recon` processes is,
that's where the configuration file should be.  The configuration file
is best, because otherwise you're looking at some intricate balancing of
configuration for "recon" and "db" to make sure things work.

You can just run `strace sks help` to not do anything but show the help
text, but after SKS has loaded its configuration.  I use FreeBSD, so am
using ktrace/kdump, but below is a highlight of what I see in the
output, after searching forward with my text viewer ("less") for the
name of the configuration file, "sksconf".  This is how you find what
files a process was trying to access.

What you _probably_ want to do is use:

sks db -basedir /path/to/runtime/directory

and in your runtime directory have symlinks pointing to the real
configuration files somewhere under /etc/.

And hey, I just discovered that my `server_contact` field is
out-of-date, by reading my own trace output.  :)

-Phil

-8< ktrace sks help >8--
 32366 sks  CALL  stat(0x801dc9f40,0x7fffe8d8)
 32366 sks  NAMI  "./sksconf"
 32366 sks  STRU  struct stat {dev=293016077, ino=15, mode=0100644, 
nlink=1, uid=0, gid=0, rdev=4294967295, atime=1399850869.655568857, 
stime=1426291686.685482306, ctime=1426291686.685482306, 
birthtime=1399850869.655568857, size=437, blksize=4096, blocks=9, flags=0x800 }
 32366 sks  RET   stat 0
 32366 sks  CALL  open(0x801c170f0,0,0)
 32366 sks  NAMI  "./sksconf"
 32366 sks  RET   open 4
 32366 sks  CALL  fcntl(0x4,F_SETFD,FD_CLOEXEC)
 32366 sks  RET   fcntl 0
 32366 sks  CALL  lseek(0x4,0,SEEK_CUR)
 32366 sks  RET   lseek 0
 32366 sks  CALL  read(0x4,0x801f52050,0x1)
 32366 sks  GIO   fd 4 read 437 bytes
   "basedir: /var/sks/
hostname: sks.spodhuis.org
nodename: sks.spodhuis.org
server_contact: 0x403043153903637F
from_addr: keys...@sks.spodhuis.org
membership_reload_interval: 1
initial_stat:
recon_address: 94.142.242.225 2a02:898:31:0:48:4558:73:6b73
hkp_address: 127.0.0.3
pagesize: 16
ptree_pagesize: 8
# With BDB 5.x, pagesize to 128, ptree_pagesize to 16
#
# Cache size limit (in MB) can limit the damage of misbehaving peers
cache: 80
   "
 32366 sks  RET   read 437/0x1b5
-8< ktrace sks help >8--

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

Re: [Sks-devel] keys.gnupg.net anomaly

[Phil Pennock]

On 2016-04-28 at 16:22 +0200, Kiss Gabor (Bitman) wrote:
> I found requests for https://keys.gnupg.net/ in my Apache logs
> on keys.niif.hu. Of course they were unsuccessful because
> my HTTP daemon is not set up to provide this virtual site.

> Phil Pennock writes on http://sks.spodhuis.org/:
> | End-users should use a pool definition, such as keys.gnupg.net which will
> | alias into an operational pool.
> 
> So this seems to be a well known situation but I don't believe
> it would be a wise thing.

This is only required for port 11371 and is explicitly covered in
  https://bitbucket.org/skskeyserver/sks-keyserver/wiki/Peering

} HTTP Performance
} [...]
} Beware that for port 11371 traffic, you *must* be able to handle
} requests with _any_ `Host:` header, for the various pools and CNAMEs
} which exist, and you *must* accept requests with no `User-Agent:`
} header set, as at least one major OpenPGP HKP client refuses to set a
} User-Agent field when talking to keyservers.

This is handled in all of the configuration examples provided.  SKS on
its own doesn't look at Host: headers and if you put a proxy in front of
it (as you should because of the single-request-at-a-time implementation
of SKS) then ideally you'll preserve this host-agnostic behaviour on
port 11371 if you wish to be a part of the public pools.

Ideally the pool DNS maintenance checks would enforce this.  The code is
available at:
  https://git.sumptuouscapital.com/
and I'm pretty sure that Kristian takes patches.

What hostnames you handle on 80/443 is a different matter.  For myself,
I prefer to avoid serving real content on arbitrary hostnames (DNS
rebinding attacks, etc) so always have a catchall dummy default with no
content.  For the SKS IP address though, the server configuration
includes the `/pks/` handling fragment even on that vhost, so that HKP
works.  I then have a vhost configuration for known pools which also
includes the `/pks/` config fragment, but has:

location / {
rewrite ^ $scheme://sks.spodhuis.org$request_uri redirect;
}

so that requests for any other resource will receive redirects; this
way, if someone browses to http://ha.pool.sks-keyservers.net/ and hits
my server, they'll get a redirect _before_ getting the HTML which
includes other page resources, so other server operators won't be hit
with arbitrary URI loads because of my site.

-Phil

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

Re: [Sks-devel] keyserver stats gathering

[Phil Pennock]

On 2016-02-24 at 06:17 +, Mire, John wrote:
> What is the process for the keyserver status page generation 
> (https://sks-keyservers.net/status/)
>  i.e., what scripts/queries are executed against the individual keyserver? 
> How often?
> Campus is setting up Palo Alto firewalls with traffic/application inspection 
> and profiling

It's an HTTP request, against the regular HKP service, just on a special
endpoint; eg:

  http://sks.spodhuis.org:11371/pks/lookup?op=stats

The only thing different about this is `op=stats` instead of `op=index`
or whatever.

This is considered public information, because your peers expect to be
able to look at this to diagnose problems with the peering: your
problems can become their problems, if you fall too far behind.

Kristian has some PHP scripts which do the work for the
sks-keyservers.net pages; I have other tooling, others will use
browsers.  Kristian's service is considered "canonical" by most, but is
not in any way using privileged access.

If you start blocking "unusual" requests for the stats which aren't at
DoS levels then you'll upset your peers and lose peering.

-Phil

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

[Sks-devel] sks-keyservers pool max diff: needs update?

[Phil Pennock]

Hey,

When eyeballing the list of servers in and out of the pools at:
  https://sks-keyservers.net/status/
I notice that a large number of the servers _in_ the pool have a
positive delta of 450-500.  That's _above_ the mean.  Assuming an even
distribution, a similar number will be that far _below_ the mean.

But the max difference is 300, so most of the servers which are
operating normally but that far behind the average, at the moment of
being polled, don't get listed as healthy.

It looks like there's about 20 servers being excluded, simply because
the threshold for this calculation is based on an absolute number of
keys changing, so a given update rate, but fortunately more people are
using PGP now.

I think that "300" needs updating, to 500 or so.

Case in point: my server was Δ-333 when last polled, but is currently
Δ+512 above mean.

-Phil


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

Re: [Sks-devel] SkierPGP

[Phil Pennock]

On 2015-08-24 at 08:50 +1200, Mike Forbes wrote:
 Has anyone had any experience with https://github.com/SkierPGP/Skier ?

Experience, no, but I just took a look and these are my initial
impressions.

It doesn't speak SKS so can't interop with SKS or Hockeypuck.

It uses HTTP for key distribution, asking peers for a list of all new
keys since a given timestamp and then fetching those.  This makes some
interesting assumptions about the suitability of a timestamp as an
indexing mechanism for consistency in a distributed system not under
centralized control.  It also immediately POSTs a newly uploaded key to
all peers, resulting in fan-out and an interesting DoS vector.

Looks like a reasonable choice to explore for a company/site's internal
PGP keyserver, only holding local keys, if not going to use LDAP.  I'd
be rather hesitant to rely upon this for global synchronization at this
time.

Thanks, added to the list at:
  http://people.spodhuis.org/phil.pennock/pgp-keyservers

-Phil

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

Re: [Sks-devel] where are the good init files for FreeBSD?

[Phil Pennock]

On 2015-02-20 at 19:24 -0800, David Benfell wrote:
 In a recent discussion, Phil mentioned he had some more recent init
 files for sks for FreeBSD.

I included them in that mail; part of a thread, but I changed the
Subject to FreeBSD init scripts.

https://lists.nongnu.org/archive/html/sks-devel/2015-02/msg00060.html

Content is inline there; I PGP-signed the mail, so if you dig the
original mail out of your history, you should be able to verify.

 I don't know why the old ones have broken. But they're dead, Jim. I am
 able to run sks by su'ing into the sks user; cd'ing into the home
 directory and running 'sks db' and 'sks recon' by hand. The init
 scripts I have instantly fail with no log messages whatsoever. I'm
 clueless.

The new ones are unlikely to help.  I don't know which scripts you're
using, it's _possible_ that the `db_recover` invocation is not in those,
in which case the new script might help after all.

 Also, it sounded like what Phil is doing has an additional dependency.
 What is it?

The `runit` Port; it's a more modern implementation of some of the
system management functionality; the accessory tools therein are more
widely used and debugged.

Don't worry about supervise; that is a different approach, which the db
start script supports with `startfg` instead of `start`, so that the
init script doesn't actually daemonize.  If you don't want to learn
about supervise or the like, then it's just additional complexity which
you likely don't need.

But really, until you can get sks to run when manually started from the
command-line, no automatic method of running sks is really likely to
help.

Make sure that you have the `DB_CONFIG` file from before, or that you're
setting pagesizes correctly in `sksconf`.  Try setting `debuglevel` and
then `debug`, then look at the logs.

-Phil

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

Re: [Sks-devel] FreeBSD init scripts

[Phil Pennock]

On 2015-02-14 at 14:52 +0100, Johan van Selst wrote:
 Phil Pennock wrote:
  On 2015-02-13 at 10:54 -0800, David Benfell wrote:
   On FreeBSD, we seem not to have checkpath, at least in the places
   where I looked. I have tweaked init scripts crafted by--I think--Phil
   Pennock a while ago; the FreeBSD port doesn't include them, and Phil's
   need to be updated and probably worked into something a lot more
   robust.
  You should probably start with my current scripts, then; I use these in
  a dedicated jail, I switched to using supervise to keep sks alive
  (clang-built binary problems) and so I'm using chpst from the runit
  Port.
 
 This looks very useful indeed. Do you mind if I include these in
 the standard FreeBSD port? Other suggestions to improve the current
 port are welcome as well.

I don't mind at all; however, the init script used by sv is a gross
hack.  That doesn't need to be used as-is, unless you too notice sks
crashes.  I haven't chased down the root cause, but Kristian suspects a
clang issue contrasting with, I think, gcc used in cryptokit?  I forget
the details, I really need to spend time revisiting this.

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

[Sks-devel] FreeBSD init scripts

[Phil Pennock]

On 2015-02-13 at 10:54 -0800, David Benfell wrote:
 On FreeBSD, we seem not to have checkpath, at least in the places
 where I looked. I have tweaked init scripts crafted by--I think--Phil
 Pennock a while ago; the FreeBSD port doesn't include them, and Phil's
 need to be updated and probably worked into something a lot more
 robust.

You should probably start with my current scripts, then; I use these in
a dedicated jail, I switched to using supervise to keep sks alive
(clang-built binary problems) and so I'm using chpst from the runit
Port.

I've not felt the need to chown existing files from my start-up scripts,
because I don't do things like rebuild databases across untrusted data
as the root user: that way lies system compromises.  I do have `recover`
available as an init-script command, though, thus `service sks-db
recover` does things as the right user.

-Phil

--8 cut here: /etc/sv/sks-db/run 8
#!/bin/sh
exec service sks-db onestartfg
8 cut here 8--


8 cut here: sks-db 8--
#!/bin/sh

# PROVIDE: sks-db
# REQUIRE: DAEMON
# BEFORE: sks-recon

. /etc/rc.subr

name=sks_db
rcvar=sks_db_enable
command=/usr/local/bin/sks
pidfile=/var/run/sks_db.pid
start_cmd=sks_db_start_cmd
start_precmd=sks_db_start_precmd
extra_commands=recover rotate statsgen startfg
recover_cmd=sks_db_recover_cmd
rotate_cmd=sks_db_rotate_cmd
statsgen_cmd=sks_db_statsgen_cmd
startfg_cmd=sks_db_startfg_cmd
startfg_precmd=sks_db_start_precmd

load_rc_config $name
: ${sks_db_user=sks}
: ${sks_db_group=sks}
: ${sks_db_chdir=/var/sks}
: ${sks_db_limits_enable=NO}
: ${sks_db_limits_args=-U $sks_db_user}
: ${sks_db_recover_onstart=NO}
: ${sks_db_recover_bin=db_recover-5.3}

PATH=/usr/local/sbin:/usr/local/bin:$PATH

as_user()
{
/usr/local/sbin/chpst -u $sks_db_user $@
}

sks_db_start_precmd()
{
if checkyesno sks_db_recover_onstart
then
sks_db_recover_cmd
fi

if checkyesno sks_db_limits_enable
then
eval `/usr/bin/limits -aBe ${sks_db_limits_args}` 2/dev/null
else
return 0
fi
}

sks_db__do_chdir()
{
local d=$sks_db_chdir
[ .$1 != . ]  d=$d/$1
cd $d
if [ $? -ne 0 ]; then
warn Failed to chdir to $d
return 1
fi
}

# Want to be able to pkill as the sks user, based off the pidfile
sks_db__fix_pidfile()
{
chgrp $sks_db_group $pidfile
chmod g+r $pidfile
}

sks_db_start_cmd()
{
echo Starting sks db.
sks_db__do_chdir || return 1
# don't use as_user since daemon invokes it
/usr/sbin/daemon -f -p $pidfile \
/usr/local/sbin/chpst -u $sks_db_user \
$command $sks_db_flags db
sks_db__fix_pidfile
}

sks_db_startfg_cmd()
{
echo Starting sks db (in foreground).
sks_db__do_chdir || return 1
exec /usr/local/sbin/chpst -u $sks_db_user \
$command $sks_db_flags db
}

sks_db_recover_cmd()
{
echo Recovering sks dbs.
local dir
for dir in KDB PTree
do
echo  ... $dir
sks_db__do_chdir $dir || return 1
as_user $sks_db_recover_bin
done
echo Cleaning up old diffs
sks_db__do_chdir || return 1
find . -name diff-\*.txt -maxdepth 1 -mtime +1w -execdir rm {} \;
echo Done.
}

sks_db_rotate_cmd()
{
echo Rotating logs.
sks_db__do_chdir || return 1
local logdir x
logdir=OLD-Logs/$(date +%Y%m%d)
mkdir -p $logdir
for x in *.log
do
echo  ... $x
as_user touch $x.NEW  \
mv $x $logdir/$x  \
mv $x.NEW $x
bzip2 -9 $logdir/$x 
done
wait
}

sks_db_statsgen_cmd()
{
if [ -f /etc/sv/sks-db/supervise/pid ]; then
if [ -f /etc/sv/sks-db/supervise/stat ]  [ $(cat 
/etc/sv/sks-db/supervise/stat) = run ]; then
# this relies upon us having exec'd sks above, otherwise the pid might be the 
wrapper init script
rc_pid=$(cat /etc/sv/sks-db/supervise/pid)
fi
fi
kill -s USR2 $rc_pid
}

required_dirs=${sks_db_chdir}/KDB
run_rc_command $1
8 cut here 8--


--8 cut here: sks-recon 8-
#!/bin/sh

# PROVIDE: sks-recon
# REQUIRE: DAEMON sks-db

. /etc/rc.subr

name=sks_recon
rcvar=sks_recon_enable
command=/usr/local/bin/sks
pidfile=/var/run/sks_recon.pid
extra_commands=clean
start_cmd=sks_recon_start_cmd
start_precmd=sks_recon_start_precmd
clean_cmd=sks_recon_clean_cmd

load_rc_config $name
: ${sks_recon_user=sks}
: ${sks_recon_group=sks}
: ${sks_recon_chdir=/var/sks}
: ${sks_recon_limits_enable=NO}
: ${sks_recon_limits_args=-U

[Sks-devel] sks-peer.spodhuis.org behind

[Phil Pennock]

Folks,

My keyserver is 8k keys behind; sks-recon was not running.

I've tried using runit but some failure modes meant that this caused
more problems that it solved (concurrent processes, etc).  I should find
time to spend looking into it more, but don't currently have that,
sorry.

I've restarted recon.  Kristian and I have been talking about this, and
I (still) owe him one recompiled SKS binary using gcc instead of clang
for the extensions -- _might_ be a FreeBSD / clang issue.

Apologies for the slight hit on load -- 8k keys isn't far enough behind
for reconciliation to be horrible, but it's enough for me to feel
guilty.

Hrmph, no core-dump for this one.  Ah well.

-Phil


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

[Sks-devel] sks-peer.spodhuis.org maintainer PGP key update

[Phil Pennock]

Folks,

I have a new(ish) PGP key, which is in the strong set and which I am now
finally set up to conveniently use with email, so I can switch away from
using my old 1024/DSA key 0x403043153903637F.

I am now using 0x4D1E900E14C1CC04 4096/RSA.  This key is signed by the
old one, with a signing policy statement which references text saying
it's one of my keys, so rather than mess around to try to send this
one message with the old key, I think this should be sufficient for
folks to verify authenticity.

pub   4096R/0x4D1E900E14C1CC04 2013-10-22
  Key fingerprint = ACBB 4324 393A DE35 15DA  2DDA 4D1E 900E 14C1 CC04
[...]
sig 3   P0x403043153903637F 2013-10-22 never   Phil Pennock 
censored-against-spambots
   Signature policy: https://www.security.spodhuis.org/PGP/policy/self

If you are peering with me, please update your membership line with:

sks-peer.spodhuis.org 11370  # Phil Pennock keyser...@spodhuis.org 
0x4D1E900E14C1CC04

Thank you,
-Phil


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

Re: [Sks-devel] PTree corrupted

[Phil Pennock]

On 2014-08-22 at 10:10 +0200, Horváth Dávid wrote:
 PTree often crash in my server.
 Log:
 
 2014-08-18 14:27:38 Requesting 2 missing keys from ADDR_INET
 [80.241.60.3]:11371, starting with 1AFFB478E0DC9C6F6A3BEB58E5E6EED4
 2014-08-18 14:27:38 2 keys received
 2014-08-18 14:27:38 setting synctime to 1408372058.589961
 2014-08-18 14:27:38 Added 3 hash-updates. Caught up to 1408372058.589961
 2014-08-18 14:27:38 Enabling gossip
 2014-08-18 14:27:39 Raising Sys.Break -- PTree may be corrupted:
 Failure(remove_from_node: attempt to delete non-existant element from
 prefix tree)

Per http://keyserver.dacr.hu:11371/pks/lookup?op=stats you are running
SKS 1.1.3.  You need to be running at least 1.1.4 to have the fixes for
PTree corruption.

In short: you're running on a system where gettimeofday() is not
returning unique values -- perhaps under a poorly tuned VM hosting
environment, perhaps on an OS which just does not offer a high
resolution gettimeofday() timer.

This was fixed in SKS 1.1.4 by wrapping gettimeofday() to force the
value to always go up.  That version was released in October 2012.  The
current release is SKS 1.1.5.

Upgrade SKS or fix your OS / VM.  Upgrading SKS is going to be simpler.

-Phil

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

Re: [Sks-devel] quality of keyservers offering hkps

[Phil Pennock]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 2014-08-14 at 13:30 +0200, Matthias Schreiber wrote:
 On 14. August 2014 05:31:40 MESZ, Phil Pennock sks-devel-p...@spodhuis.org 
 wrote:
 
 What is the threat model which you are trying to protect against?
 
 As the public keys themselves are of cause nothing which needs to be secured, 
 I see these two possible aspects:
 
 - meta data like 'who up-/downloaded which keys' could be revealed
 - mitm attacks  may manipulate up-/downloaded keys
 
 Or am I thinking in the wrong direction?

No, but it's important to understand something about keyservers.  The
data which they hold is unauthenticated, and anyone can run a keyserver.

For context before I continue: I run an HKPS keyserver, was one of the
first to do so, and have worked with Kristian on the setup and with the
GnuPG developers on establishing which identity should be verified.  So
I support HKPS as a feature and I _cautiously_ support it for a public
pool, but I worry about the false sense of security it engenders.

If an acronym agency is not running a public keyserver, under an
innocuous name, then they're slipping.  It's the easiest way to
automatically get a feed of every PGP public key created and uploaded
for general use.  Great ingress, can check for names and pseudonyms
immediately and schedule some keys for priority factoring.

If an acronym agency is not running a set of public keyservers, logging
all client queries, to get a statistical sample of communicant flows,
then they're slipping.

Kristian is not in a position to filter the keyservers in his pool by
the affiliation, public or hidden, of the keyserver operators.
Selection is entirely based on technical merit, as assessed by a few
simple heuristics.  It is likely that at _least_ one of the currently
participating members works for an acronym agency.  Frankly, while it
would be nice if no keyserver operators did so, if you have no
connection or affiliation with the operator of the keyserver you use,
then it's naive to _demand_ that the operators conform to your desired
profiles and requirements.

Thus, if you run an organisation where you care about traffic analysis
and communicant pairing, then you should run your own PGP keyserver and
get people in your organisation to exclusively use that keyserver.  If
you have the resources to run a keyserver, bias towards only using your
own.

The _default_ keyservers are a selection of publicly available
keyservers where *NO* warranties are made about who is running them.

So, to your two points, let's first look at when using the general
pool and then when using a particular keyserver

 * meta data revelation: far easier to perform, and harder to detect, to
   just run an SKS keyserver publicly, under a pseudonym used by an
   agency employee.  Run up HTTPS with a high quality cert, make sure
   you pass every quality assessment for the cert and HTTPS TLS
   negotiation.  Provide a great service.  Locks out analysis by people
   at other (foreign, or just competing) agency and still gives you full
   logs.

   MITM is usually detectable, even if just after the fact (oops, where
   did that BGP announcement come from?).  Running quality servers which
   people appreciate, and _choose_ to use, is absolutely legal, requires
   no wiretapping, no warrants, and lets you keep the usual, routine
   logs.  Everything is above board, legally, in just about every
   jurisdiction.  It's a no-brainer.

 * MITM attacks: similarly, no need, just write logic into the
   keyserver, or between the front-end proxy and the server, to filter
   results for keys of interest.  Do it behind the HTTPS, so that you
   don't need to tamper with the quality and are not detectable, and do
   it on your own systems, when queried, so that no laws are broken and
   no warrants required.

So, for the general pool, I think revisiting the threat model may be of
use.

Having HKPS available, and of good quality, is useful for those of us
who do not work for an acronym agency, to help protect end-users against
attack when their client resolves to one of our servers.  It keeps us
from becoming complicit.  It increases the chances of tampering becoming
evident.  It's chicken soup for the soul.  It's good to have this, for
the pool, to increase the difficulty of attack against queries going to
non-agency servers.  But for the end-user, using HKPS with the public
pools is like playing Russian Roulette: sooner or later, the chamber is
loaded with a bullet and you lose.

HKPS available and verifiable protects against regimes outside of the
nation where the keyserver is (and their spying allegiance nations).  So
for folks going into the Middle East, using a keyserver pool constrained
to the USA is probably a good call, as long as you also use a validating
DNS resolver (with a trusted root key set), so that DNS attacks can't
redirect you to a member of another pool in a nation friendly to the
local regime of concern.  Kristian has set

Re: [Sks-devel] quality of keyservers offering hkps

[Phil Pennock]

On 2014-08-14 at 00:33 +0200, Matthias Schreiber wrote:
 after reading the posts related to protocols and cipher suites started
 by Pete last week [1] I wanted to check the settings of the keyservers
 in the hkps pool using the SSL Server Test from Qualys [2] in order to
 evaluate the quality of the applied settings.

What is the threat model which you are trying to protect against?

-Phil

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

Re: [Sks-devel] Looking for peers

[Phil Pennock]

On 2014-07-31 at 19:18 +0200, Pete Stephenson wrote:
 This server is physically located in Amsterdam, NL and currently only
 has IPv4 connectivity. IPv6 connectivity should (hopefully) be added
 in the next few months.
 
 The server is listening on ports 11371 and 80 and is behind a reverse
 proxy on both ports.
 
 I loaded a dump from http://keyserver.secretresearchfacility.com/dump/
 dated today. My server currently has 3680247 keys loaded.
 
 For operational issues, please contact me directly.
 
 ams.sks.heypete.com 11370 # Pete Stephenson p...@heypete.com
 0x1C600C6CCEA44628D2439A139A5CC3A485EB9F44

Hi Pete,

I've added your server, please add mine:

sks-peer.spodhuis.org 11370  # Phil Pennock keyser...@spodhuis.org 
0x403043153903637F

My server, too, is in Amsterdam, so should be a nice fast route hopping
over AMS-IX.  :)

Thanks,
-Phil


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

[Sks-devel] sks-peer.spodhuis.org outage - apology

[Phil Pennock]

Sorry folks, I goofed up yesterday and didn't notice until just now.
Almost 20 hours of outage.

After sks-peer.spodhuis.org moved to new hardware, with a newer OS, I
set it up running in a FreeBSD Jail (they're _much_ nicer to create with
ZFS available).

Over the weekend, I set up poudriere to provide packages locally and
used an overlay to create meta-packages for each jail.  Last last night,
when very tired, I audited and decided I wasn't using daemontools
anywhere and didn't know why it was even installed, since I normally use
runit, so I nuked it.  I suspect that when I checked all the services, I
just checked that http://sks.spodhuis.org/ loaded in a browser instead
of checking the actual SKS service.

I just noticed that SKS wasn't running on my box (yes, I need real
monitoring for it) and investigated; turns out, there was one jail where
daemontools was used instead of runit, since I'd just migrated my
previous setup across.

# pkg -j sks install daemontools
# service jail restart sks
# fgrep daemontools /jails/sks/var/log/messages 
May 11 17:47:19 sks pkg: daemontools-0.76_16 installed
Jun 16 01:01:46 sks pkg: daemontools-0.76_16 deinstalled
Jun 16 21:00:38 sks pkg: daemontools-0.76_16 installed

Those timestamps are created by pkg and so have picked up a $TZ of EDT,
GMT-4.  The outage began 20 minutes after deinstall with a restart of
the jail, to test everything.

I think a simple HTTP prober for my monitoring, which checks
`:11371/pks/lookup?op=stats`, is in my near future.

-Phil

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

Re: [Sks-devel] Peering request from Zurich / Switzerland

[Phil Pennock]

On 2014-06-05 at 19:37 +0200, MSW-Technologies.de wrote:
 we have just set up a public keyserver located at:
 
 gpg.directory 11370
 
 The server is operated by NAG Netbone Digital AG (RIPE member) in Zurich,
 Switzerland.

According to http://gpg.directory:11371/pks/lookup?op=stats you are
running SKS 1.1.3 -- this has a known cross-site scripting
vulnerability, so you're soon going to be ineligible to be a member of
the main serving pool, if that matters to you.

The pool in question is pool.sks-keyservers.net, which is the target of
the keys.gnupg.net CNAME.

There's some good information at https://sks-keyservers.net/ which it
might be worth having someone read.

You also _appear_ to not have a front-end reverse-proxy in front of your
server, which is why you're showing in red at
https://sks-keyservers.net/status/.  You should be aware that SKS
serves a single request at a time, in the one thread, before accepting
the next request, so one slow client can DoS your service.  Best current
practice is to deploy with a reverse proxy in front.

You might find this wiki page helpful:
 https://bitbucket.org/skskeyserver/sks-keyserver/wiki/Peering

Regards,
-Phil
-- 
My employer, Apcera Inc, is hiring sysadmin; primarily San Francisco:
 http://www.apcera.com/jobs/#operations-engineer
(but all the mistakes in this email are made in my personal capacity)

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

Re: [Sks-devel] Dirmngr now supports hkps

[Phil Pennock]

On 2014-05-07 at 22:19 +0200, Kristian Fiskerstrand wrote:
 On 05/07/2014 08:51 PM, Werner Koch wrote:
  On Wed,  7 May 2014 18:17,
  kristian.fiskerstr...@sumptuouscapital.com said:
  I strongly suggest using the original hostname provided as SNI
  when performing keyserver lookups, this is also consistent with
  current
  
  Okay.  What about a dirmngr options to enable or disable the use of
  the pool name?
 
 As long as the hostname provided by the client is used by default for
 (i) HTTP Host: and; (ii) in the context of TLS for SNI (c.f. arguments
 similar to those presented in issue1447[0]) I don't have any arguments
 against a tunable option to change the behavior.

Likewise, but I'll emphasize that the default needs to be to use the
original supplied hostname (ie, poolname) instead of the resolved server
name.

Remember that each keyserver is independently run.  It's fairly rare for
one organisation to run more than one keyserver in the public pools
(except behind loadbalancers, to present as one).  The pool names are a
layer above that and are not privileged.  Anyone can run a pool.  This
egalitarianism is deliberate, and avoids a few issues: we have two sets
of open source software for spidering the keyservers and maintaining
public pools, so anyone who disagrees with a decision by Kristian can
quite legitimately be told to run their own pool definition and pointed
at resources to help them do so.

The only complexity is when adding hostname verification to the mix; up
until that point, any keyserver which is a candidate for inclusion in
pools using Kristian's software has been verified to handle unknown
Host: headers and still work, so that aliases such as keys.gnupg.net
will work.

So my keyserver, which presents to end-users as sks.spodhuis.org, has
a cert from my own CA for that vhost and dispatches on SNI to select it.
For the hostname hkps.pool.sks-keyservers.net, I have a separate
key/cert pair and the cert is signed by Kristian's CA.  I am willing to
work with others, if I recognise them and don't have particular reason
to object, to add more keys/certs for other hostnames representing
pools.

Each keyserver _is_ in N1 pools.  It can be in N2 HKPS pools.  It
happens that at present there's only one HKPS pool, but given some of
the demands being made on the sks mailing-list now, on CA practices for
the demo HKPS pool run by Kristian, I think and _hope_ that we'll soon
see some more.

Each pool necessarily uses its own CA.  No one CA can be enforced or
reasonably required as being used for hostnames other than the pool
name.

Thus HKPS clients should default to preserving the original hostname if
they want to be able to select a CA based on the pool.  The current
design of CA management/selection for keyservers in GnuPG, including the
new dirmngr support, has to use the pool name in TLS SNI and Host: to
work.

If someone wants to design another validation mechanism for TLS public
keys when used for HKPS, perhaps based around OpenPGP (Monkeysphere?)
then that might be worthwhile to pursue.

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

Re: [Sks-devel] Changes to sks-keyservers.net pools

[Phil Pennock]

On 2014-05-06 at 17:53 +0200, Dinko Korunic wrote:
 IMO delisting is fine as long as there is proper communication
 involved and people actually are aware that's going on -- I'm sure
 that not all the SKS administrators read the sks-devel on a
 daily/weekly basis.

For clarity, this becomes: there's a chance that for a window of a
couple of weeks, the only SKS administrators who will be in the
rarely-used subset pool will be those who read SKS email daily.

There's a chance that Kristian's main pool will become a set of servers
run only by administrators who check their email at least every 45 days.
This being the pool of keyservers which are the default for a number of
mainstream clients.

I'm really not seeing a problem with this.

The merits of an individual keyserver being run for its own use are
different from the merits of a hostname being used for some pool of
keyservers.  There is plenty of justification for making sure that the
hostname for the predominant pool used by people who don't change their
keyserver definition from the default resolves only to servers which
are able to get a security update out within 45 days.

-Phil

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

[Sks-devel] sks-peer.spodhuis.org moving

[Phil Pennock]

I have lowered the DNS TTL on sks-peer.spodhuis.org in advance of IP
address changes.

At some point in the next couple of weeks, the service will move across
to new hardware (plus a new OS, etc).  There will be a DB dump and an
outage, probably coming back up on a newer BDB version.  The IPv4
address will almost certainly change, the IPv6 address might stay the
same.  (Ah, routed netblocks, how I love thee).

I don't expect to need to send out emails closer to the time: it should
just look like a down peer and come back, with DNS re-resolved, and some
peerings perhaps being temporarily stale on old IPs -- everything in the
peering meshes should self-heal, given time.

The X.509 keys and certificates for HTTPS/HKPS will migrate, unchanged.

Thanks,
-Phil


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

Re: [Sks-devel] Configuring the reverse proxy to support large keys - HTTP error 413

[Phil Pennock]

On 2014-04-28 at 13:32 -0400, Jeremy T. Bouse wrote:
 I don't know about the others on the list but my configuration follows
 the recommendations from
 https://bitbucket.org/skskeyserver/sks-keyserver/wiki/Peering which has
 never stated anything about this issue as long as I've been following
 it. Do we need to make changes to the documentation that's already out
 there?

Speaking as the primary author of that page:

It's a wiki page.  It is updated as and when we discover new operational
issues which affect peering; one of the pieces of advice was also
updated with something which affected general usability, despite not
being a peering issue, because it's the closest thing we've got to an
operational best practices document to cover known issues to beware of.
It did affect whether or not the keyserver is fit to be included in
pool definitions, as does this new discovery.

Bitbucket's wiki controls mean that anyone can edit the page; the docs
note that a bitbucket account isn't even needed.

 As to the key you selected to test with it's no surprising it's a large
 upload given that it's weasel's old 1024D Debian key with over 3K
 signatures and one of the strong set keys as he stays high in the WoT.
 His new 4096R key (62AF4031C82E0039) already have over 1K signatures on
 it. In that case where do we set a sane upper bound as it will only
 continue to grow on keys that make it into the strong set with thousands
 of signatures?

There are a couple of issues here.  The most severe is that _any_ limit
means that someone malicious can block upload of updates of any key they
like, simply by adding a large number of signatures to the key.
Further, appropriate attribution data might be used to turn this into a
steganographic storage pool, provided for free by keyserver operators,
so we don't want to make it unlimited.

For now, if it's taken 15 years for someone keen on key signings to
reach a 1MB limit, then I think that 8MB, covering 120 years of
activity at such a rate, is likely to be enough for most normal mortal
human beings.  It's certainly enough to set as a limit for now, while we
hem and haw over whether or not we need to extend HKP to support partial
upload concepts and whether we've finally reached the point where
there's enough impetus for distributed key blacklists that someone
volunteers code for a workable proposal which keyserver operators are
willing to use.

-Phil


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

Re: [Sks-devel] status page

[Phil Pennock]

-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

Re: [Sks-devel] status page

[Phil Pennock]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 2014-04-19 at 02:21 +0200, Simon Lange wrote:
 Am 18.04.2014 23:16, schrieb Phil Pennock:
  -Phil
 
 *PLONK*

Could someone please do me a kindness and pass on a message to Mr Lange?

Maintaining a keyserver peering requires the ability to communicate,
because each peer is able to cause operational problems for the other.
If we can't communicate, I am unwilling to peer because when problems
happen, they can't be resolved.

So applying a killfile rule (which is what plonk means to me) while
maintaining a peering is deeply problematic.

Thus I have removed the line for his keyserver from the membership file
of my keyserver.

Thanks,
- -Phil
-BEGIN PGP SIGNATURE-

iQEcBAEBCAAGBQJTUgyYAAoJEKBsj+IM0duFIecH/j25Kewr6MY6HBa8QPzpLFff
H+Zrmu3yZujeEWKCIyCflrsjsOrOrN2dwr3nhK3zgkRHurCAGDB2+iQkHFey30O4
j/N8z/oNKq/kZdvB1fsDtO6O4YU3LrzKHvVVWc3jDqmA77SpSKsQP1AQ84GiwF8U
evtqF+qeu7LankiwPqy5KWABETRAfiy1L6/olqclVGgGxWWzSldUi+JVY8HY1Zpg
4znz43oUStyTnv1xKzzlHwQD+5VGx+vmEbRQ1T0QynMf5II/P7E8z0smKG4RaSsC
lAAxg0kj5SpaFMc8Dwv8RY5Zbw5BfDoxLiIax2W5QlelSgh07WxZWFbsJX8CrJw=
=GYhD
-END PGP SIGNATURE-

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

Re: [Sks-devel] SKS peering request [sks-server.randala.com]

[Phil Pennock]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 2014-04-06 at 13:49 +0300, Martin Papik wrote:
 And my impression is that 1.1.3 is okay, a number of the servers
 visible on https://sks-keyservers.net/status/ are 1.1.3, and so far
 the only difference I came across is that 1.1.3 doesn't export server
 contact, which doesn't bother me overly. Is there a better reason to
 upgrade?

If your machine is actually a VM rather than raw metal, then 1.1.4 is
almost essential to avoid database corruption issues (Use unique
timestamps for keydb to reduce occurrances of Ptree corruption).  Some
caching and other fixes.  The main other reason is to support ECC PGP
keys.  If you care about ECC, you'll want 1.1.4 or better.

I believe that Kristian is currently trying to coordinate getting some
final changes in before a 1.1.5 release which will have enough cleanups
and improvements in ECC and web security areas that it should be
considered a really really should upgrade release.

The key aspect here is that OS packaging doesn't tend to draw clean
distinctions between stable dependencies which other software relies
upon and service applications which are the reason this machine
exists.  Often, for the latter group you want to try to stay very close
to the upstream most-recent release.

As a classic example of the trade-offs: I'm involved with Exim.  If you
have a system which just needs to send the occasional email and you want
package installation to handle setting up new role email addresses and
mailing-list integration for you, then you likely don't care about the
most recent version and you want to stick to the configuration layouts
provided by the OS packager.  On the other hand, if you're running a
mail-server, then this is entirely the wrong approach, because the
emphasis shifts to where the whole point of the server is this software
and you'll want the latest improvements and fixes from upstream which
reduce the problems when talking with others, you'll want support for
current trends in email security and you'll want to have a configuration
designed to be evaluated efficiently, for the million+ emails per day
you handle per machine, instead of the 5.

So, figure out why you're running SKS and what your goals are.  Decide
if it's important to you for your server to be included in public pool
definitions run by others, to provide a public service, or if you just
care about local users and being useful enough to the community that
others are prepared to bear the cost of providing you with feeds, so
that you can connect into the mesh.  (There is operational risk for the
stability of your server, for each peer you have, as each peer is able
to DoS your service with resource consumption attacks).

Once you know your answers to those issues, you'll know if you want to
(1) stick with the minimal OS version which can talk to other servers;
(2) run the most recent release, within T time of a new release;
(3) run a local build from Mercurial tip.

Regards,
- -Phil
-BEGIN PGP SIGNATURE-

iQEcBAEBCAAGBQJTQePhAAoJEKBsj+IM0duF2OsIAKRPIPRA3OVMVJjR48+rIXM3
JzfywdJlYObA+BdZKpNxl2M4BQjLXvTc2qVQGcG0Pl0g0yjvFG9MWti8dhN9XzFv
QLpzIqUVYZHW+kcih6r0PBws9t1PKwloVz6o2HkpCeN45/I2z2LcHLsfb60OlDAE
FekCZH4x0hctHZBcnnuxtBi7gG5S4LRyXWZgGdocF0QVNloe/zwB9CIMZ4BVdICa
5cFJBL+Bd5fvh+vVGewRqCPE4bRPNCXZ7egleaf2NOKNjfNzlvgIbU5U4DdbOuMW
1L8pWvCwR+b26rdg4ti5Re5B7lldjeSwBFJp9gSt7cgtwPLIBo6yujbAPFJC0QY=
=qPa9
-END PGP SIGNATURE-

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

Re: [Sks-devel] Keydump file format documentation?

[Phil Pennock]

On 2014-03-12 at 11:35 -0700, Philip White wrote:
 I want to develop a program that analyzes the PGP web of trust. To do this, I 
 figure the best source is the keydump file. The problem is, it's a binary 
 file and I don't see any documentation for the binary file format. Given 
 enough time and effort I can probably read the source code of `sksserver` and 
 figure out how the file is encoded, but I wonder if there's a better way.
 
 Has anyone documented the file format? Alternately, is anyone willing to 
 document it?
 
 P.S. I don't want to develop my program in O'Caml, if I can help it, so I 
 don't want to simply reuse the file parsing libraries. :)

Your first tool for debugging a file format is the file command, which
might be used like this:

% file sks-dump-.pgp
sks-dump-.pgp: GPG key public ring

The answer might be wrong, but it provides a good starting point for
investigation.  In this case, the answer is mostly correct (except that
it's not GPG-specific).

You can find documentation in RFC 4880.  It actually doesn't say much
and disavows full knowledge, but the Traditionally, a keyring is simply
a sequential list of keys comment may help.

You can get an overview using gpg like so:

% gpg --list-packets  sks-dump-.pgp | less

and you can find parsing libraries in various languages.

-Phil

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

Re: [Sks-devel] Keydump makes DB unavailable

[Phil Pennock]

On 2014-01-28 at 16:54 -0500, Phil Pennock wrote:
 That's off the top of my head, but I don't create dumps (my recovery
 strategy is to use the dumps created by others and let SKS reconcile).
 Those who do create dumps may be able to help refine this.
 
 Perhaps we can add a wiki page enumerating a debugged list of steps?

I've _very_ quickly thrown together a basic page, a chunk of which was
copy/paste from that email.  The page is not yet authoritative, but at
least provides something as a starting point to be refined and improved
to get towards a state where people like it as much as they seem to like
the Peering document.

https://bitbucket.org/skskeyserver/sks-keyserver/wiki/DumpingKeys

I don't know what the privilege model is at Atlassian for editing that
wiki; whether anyone with an account can edit, or only people with
repository permissions.  Minimally, we have something which other
committers can refine.  I don't have time to shepherd this now, so
please don't run changes by me!  If you see a problem, fix it. :)

-Phil

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

Re: [Sks-devel] Keydump makes DB unavailable

[Phil Pennock]

On 2014-01-28 at 11:49 +0100, Frank de Bot wrote:
 I was trying to dump my keyserver database with 'sks dump 5000
 dump.new'. This goes well for a brief moment, but at a certain point my
 keyserver is unavailable and generates these errors:
 
 command handler error in callback.: Bdb.DBError(BDB0060 PANIC: fatal
 region error detected; run recovery)
 
 I already did db_recover53 n KDB and PTree, but it didn't helped.
 
 Do I need to rebuild my database or is something else wrong?

The keyserver needs to be off-line while you dump.

The best approach is probably to have a filesystem which supports
snapshots, and do something like:

 1. shut down SKS
 2. db_recover (both KDB and PTree)
 3. db_archive (both KDB and PTree)
 4. take filesystem snapshot
 5. start up SKS
 6. mount filesystem snapshot elsewhere
 7. run `sks dump` from the snapshot
 8. delete the snapshot

That's off the top of my head, but I don't create dumps (my recovery
strategy is to use the dumps created by others and let SKS reconcile).
Those who do create dumps may be able to help refine this.

Perhaps we can add a wiki page enumerating a debugged list of steps?

If the DB areas have been recovered, so that the logs have been
replayed, does `sks dump` need the FS mounted read-write or would a
read-only mount work?  Are there still systems where snapshots can only
be mounted read-only, or is that now an entirely historical concern?
I know that FreeBSD UFS snapshots are mountable read-write and ZFS
snapshots can be used as the basis for a clone, which is read-write.

-Phil

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

Re: [Sks-devel] IPv4 vs. IPv6? -- Reconciliation attempt from unauthorized host, but host is authorized

[Phil Pennock]

On 2013-12-02 at 01:30 -0500, Daniel Kahn Gillmor wrote:
 On 11/27/2013 04:30 PM, Phil Pennock wrote:
  If you're free to do so on this box, you can change the global state
  with the `net.ipv6.bindv6only` sysctl; set it to 1 from 0.
 
 hm, this seems like it would have cascading effects over other listening
 services on this machine, including the reverse proxy, whose
 configuration i would need to change if i was to diverge from the system
 defaults.

Thus free to do so -- apparently, you're not.

 well, i'm certainly fine with depending on ocaml 3.11 for modern
 versions of sks.  But it seems like there are two approaches that could
 be taken to fix it, and only one of them ought to rely on IPV6_V6ONLY:
 
  a) sks could set IPV6_V6ONLY on all listening sockets, and require the
 administrators to explicitly list IPv4 addresses differently from IPv6
 addresses, or

No, the point of IPV6_V6ONLY is that you don't need to explicitly list
all addresses.  If you do explicitly list addresses, then you don't have
:: listening, so you don't have IPv4-mapped IPv6 addresses appearing.

  b) sks could simply realize that :::XX.YY.ZZ.WW is the same as
 XX.YY.ZZ.WW when doing comparison testing for IP-address-based
 authorization.  This seems like it would be a change in same_inet_addr
 in membership.ml, and wouldn't require either system re-configuration,
 service re-configuration, or new versioned dependencies.
 
 doesn't (b) seem like the more conservative approach to resolve the
 concern raised here for dual-stack hosts?  or are there other reasons
 why (a) might be necessary?

It encodes a lot of protocol-specific knowledge and canonicalisation.

The basic issue is that there are sockets which are multi-protocol,
which was probably a design mistake.  The options are:

1. handle multi-protocol, try to unwind compatibility layers and fudge
   things about later.
2. bind a socket per address family, ensure the address families remain
   distinct, let people run with defaults, of 0.0.0.0 and ::.
3. be broken by default and require people to have manual configuration
   to fix it, but it is at least then really fixed, by being worked
   around.

SKS currently uses approach 3.  You have to explicitly configure the
addresses, to make things work.  No maintstream software is this broken,
but it does have the advantage of ensuring SKS knows which source IP
address to use, so on systems with IPv6 privacy extensions the recon
source filtering can still work.

Your (b) corresponds to approach 1.  Eww, no.

The normal software approach for robust production-grade applications is
2.  The only downside is that it assumes that source IP addresses are
equivalent, which will break recon filtering if there's a system with
multiple IP addresses.  That's the downside of using source IP address
as a security mechanism in a world of IPv6, where the designers assumed
people would have outgrown that.  It's also not a reason to keep things
as they are, since people clearly are running with the defaults, and on
systems which don't set v6only on IPv6-accepting sockets, it appears to
work fine.  So we have _some_ systems being pushed into explicit
configuration, based on local system defaults, and _all_ systems
requiring explicit address configuration, per recon and the line of
argument which says you must configure addresses manually.

I do address this in the Peering document, I do state You should
explicitly set all public addresses used and the document has (for a
long time now) explicitly warned about :::0:0/96 addresses.

IMO, SKS should either set v6only on the accepting sockets explicitly,
or remove the defaults and treat :: and 0.0.0.0 as a configuration
error, since the status quo uses inconsistent logic to defend its
stance.


On 2013-12-03 at 12:11 +0100, Karl Schmitz wrote:
 maybe you should suggest adding the IPv4 compatibility DNS record (i.e.,
 *sks-peer  :::94.142.241.93*) to the administrator of
 sks-peer.spodhuis.org.

Not going to happen.  The idea of  is to return an IPv6 address
which can be used over an IPv6 connection.  The use of an IPv6 socket to
handle an IPv4 connection is a local implementation detail.

I don't know why
http://tools.ietf.org/html/draft-itojun-v6ops-v4mapped-harmful-02
never made any more progress than it did, but the points (as was normal,
for itojun (RIP)) were valid.

-Phil

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

Re: [Sks-devel] sks behind lighttpd reverse proxy

[Phil Pennock]

On 2013-12-02 at 09:08 +0100, Simon Lange wrote:
 if u put it behind a lighttpd reverse proxy for ports 11370 and 11371 it
 wont work anymore.
 11370 (recon) isnt operational anymore. communication is broken.

Recon is not HTTP, so an HTTP proxy in the middle will break things.

Ideally you run SKS 11371 on localhost, use the HTTP proxy to expose
that to the outside world, but leave 11370 directly connected.  It's a
different process, so stalls affect your peering but don't interfere
with serving.

For me, my `sksconf` file contains:

membership_reload_interval: 1
initial_stat:
recon_address: 94.142.241.93 2a02:898:31:0:48:4558:73:6b73
hkp_address: 127.0.0.1 ::1

 11371 almost same. gpg client does not work anymore. a keysearch with
 gpg wont find ANYTHING anymore as long the lighttpd reverse proxy is
 between. only via browser (firefox, chrome, IE, ...) it works. same for
 443 reverseproxy to 11371.

The configuration in:

  https://bitbucket.org/skskeyserver/sks-keyserver/wiki/Peering

was contributed, and worked for the person who provided it to us.

 any help is welcome

When I connect using:

% gpg --keyserver-options debug,verbose --keyserver keys.s-l-c.biz \
--recv-key 0x4D1E900E14C1CC04

I get a response from lighttpd, but nothing indicating that the request
was sent to SKS as the actual backend.  Compare and contrast:

% curl -i 'http://keys.s-l-c.biz:11371/pks/lookup?op=stats'
HTTP/1.1 200 OK
Via: 1.1 keys.s-l-c.biz:11371 (lighttpd)
Server: sks_www/1.1.4
[...]

vs:

% gpg [...]
[...]
 GET /pks/lookup?op=getoptions=mrsearch=0x4D1E900E14C1CC04
 HTTP/1.1
Host: keys.s-l-c.biz:11371
Accept: */*
Pragma: no-cache
Cache-Control: no-cache

 HTTP/1.1 200 OK
 Via: 1.1 keys.s-l-c.biz:11371 (lighttpd)
 Content-Length: 0
 Connection: close
 Date: Mon, 02 Dec 2013 21:05:08 GMT
* Server lighttpd/1.4.30 is not blacklisted
 Server: lighttpd/1.4.30

So in a request for the _stats_ page, the `Server:` header is being set
by SKS, but in a request for the keys, the `Server:` header is being
generated by lighttpd itself.

I can reproduce this with curl(1) if I suppress sending a `User-Agent:`
header.

So I think that you have some anti-abuse filter in place which rejects
requests with no `User-Agent:` header.  The GnuPG folks have so far been
philosophically opposed to setting such a header.

Remove that filter for port 11371 and you should be good.  If you can
let us know which setting it was, we can update the Peering wiki page
with a cautionary note.

-Phil


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

Re: [Sks-devel] sks behind lighttpd reverse proxy

[Phil Pennock]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 2013-12-02 at 22:49 +0100, Simon Lange wrote:
 however. gpg does not send any header and therefore THAT was the
 problem. so if you use some kind of aggressive antidos mechanism like
 sorting out not compliant http clients (like gpg) you run into the problem.

For clarity: RFC2616 merely classes User-Agent: as a SHOULD, not a
MUST.  See section 14.43.  It would be nice if it were more common,
and for normal HTTP traffic I agree it's not unreasonable to filter
based upon it.

I believe that the GnuPG developers are concerned around leaking
information which can be used to fingerprint a client and causing even
more privacy problems.

 11370 has a connection throttle and of course is not reverse proxied. it
 was only for one day after a sks pool admin did wrote us we have to put
 everything behind reverse proxy. we did and ran into problems.  ;)

For clarity, once more: Kristian's intent was to let you know that _if_
you care about your server being present in the pool set which he
maintains, _then_ you would need to set up a reverse proxy; this is a
topic which has come up a few times on this list in the past few months.

You run your server, others don't run it for you.  You are under no
obligation to provide a public service: as long as you can find people
happy to peer with you and donate their own bandwidth to keeping you
up-to-date, even if you're not providing a public service, then you'll
be fine.

But providing something back to the public good should make it easier
for you to maintain enough peerings for resiliency, and thank you for
doing so!

- -Phil
-BEGIN PGP SIGNATURE-

iQEcBAEBCAAGBQJSnQboAAoJEKBsj+IM0duFmnEIAJjUJtdsHxAq1Kw4UN3IPsvZ
lG+ftmWaLZe19R4UkBTpFU50zxTlyodn7rHfFzI/G7O95ZPFVaHSecuEkfB+1YwD
AEa2xVAKCJWWMMJ2dn4t5iXj6DP2b4Sgm6K5TJmKCuJzRTIh/czNGZVqQSLaObMe
1hTIFYNhR/id1s4jKhX6C2OI9MKhRFagW4+X7wcaG+5ZiZnGXLsEcN2Ew1G+dq04
JAsAt6rHlbFXXWEOPRAqO4Y9ZJtxFhUSJ2mx2N3Ztbbwqyf76VPLpCmU+G1SHxd4
IifGRbZeN/4dCA3XFSGJyjpcEnHJ/FZL82vjW3DfpBPA0uCTBFJEvAk/B3/QkA0=
=C42x
-END PGP SIGNATURE-

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

[Sks-devel] wiki man-page link; readthedocs.org ?

[Phil Pennock]

I received an off-list report that the man-page link at:
  https://bitbucket.org/skskeyserver/sks-keyserver/wiki/Documentation
was broken; it seems that registration of minskyprimus.net has lapsed
and the domain is now being squatted.

I've temporarily updated the page to point to an instance of the page
which I've shoved up on my server.  It's the result of pod2html using
the Mercurial source as of commit 4069c369eaaa, which is a tip commit by
John Clizbe on June 19th.  I see no commits since then to the master
repo.

I looked first for a documentation-server and didn't see anything
readily suitable, without repo commit access to configure it.  I think
that a better solution is probably to use https://readthedocs.org/ and
point to the documentation there.

To that end, I've done preliminary setup, although build fails because
of a lack of conf.py:

  https://readthedocs.org/projects/sks/

If anyone with commit access (to SKS itself, mine is just to the wiki)
thinks this is the right approach, let me know and I can continue with
setup based on a fork of the master repo, then merge back in, or give
other people maintainer access to the RTD project.

-Phil

8 cut here 8--
% hg diff -c tip 
diff --git a/Documentation.wiki b/Documentation.wiki
--- a/Documentation.wiki
+++ b/Documentation.wiki
@@ -4,7 +4,7 @@
 
 The official documentation for SKS is:
 
-  * The [[http://minskyprimus.net/sks/sks-man.html|man page]]
+  * The [[http://sks.spodhuis.org/sks-man.html|man page]]
   * The 
[[https://bitbucket.org/skskeyserver/sks-keyserver/src/tip/README.md|README]] 
from the source distribution.
 
 Within this Wiki, you might start at the [[Peering]] page, for advice on setup 
and social issues.
8 cut here 8--

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

Re: [Sks-devel] wiki man-page link; readthedocs.org ?

[Phil Pennock]

On 2013-12-01 at 21:34 -0500, Phil Pennock wrote:
 I looked first for a documentation-server and didn't see anything
 readily suitable, without repo commit access to configure it.  I think
 that a better solution is probably to use https://readthedocs.org/ and
 point to the documentation there.

Hrm, I was under the impression that readthedocs supported various input
documentation formats, and that sphinx was similarly flexible.
Apparently I was wrong on both counts.  It has to be Sphinx, and Sphinx
only appears to accept reStructuredText, so I can't shove POD into it.

This was my mistake.  I've gone ahead and deleted the readthedocs.org
project for SKS.

If anyone knows of a similar documentation hosting project which might
be a better match, please do let me know.

(I mostly use GitHub and/or godoc.org for my current work).

-Phil

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

Re: [Sks-devel] IPv4 vs. IPv6? -- Reconciliation attempt from unauthorized host, but host is authorized

[Phil Pennock]

On 2013-11-27 at 12:57 -0500, Daniel Kahn Gillmor wrote:
 i'm running sks 1.1.4 on Debian GNU/Linux, wheezy, amd64 (x86_64)
 platform.
 
 I see the following situation in the logs of the recon process (this is
 just an example, it seems to happen to all my IPv4 peers):
 
 2013-11-27 12:37:17 address for sks-peer.spodhuis.org:11370 changed from [] 
 to [ADDR_INET [2a02:898:31:0:48:4558:73:6b73]:11370, ADDR_INET 
 [94.142.241.93]:11370]
 2013-11-27 12:37:17 Reconciliation attempt from unauthorized host ADDR_INET 
 [:::94.142.241.93]:54518.  Ignoring

This to me smells of a binding issue, where your v6 sockets are
accepting IPv4 addresses but SKS isn't handling that pattern.

If you're free to do so on this box, you can change the global state
with the `net.ipv6.bindv6only` sysctl; set it to 1 from 0.

If my recollection is accurate, when we were discussing IPv6 in SKS and
I provided my patches and commented upon Kim's (the ones which went in),
the O'Caml runtime did not support accessing the `setsockopt(2)` call
needed to tune this on a per-socket basis.  You're looking for the
`IPV6_V6ONLY` socket option at `IPPROTO_IPV6` level.

google(SKS IPV6_V6ONLY) yields:
  https://lists.nongnu.org/archive/html/sks-devel/2009-03/msg00170.html

So, if I was right in 2009, then with O'Caml 3.11 you can fix this.

-Phil

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

Re: [Sks-devel] Looking to join some pools

[Phil Pennock]

On 2013-11-25 at 11:14 -0600, Cyrus Vaziri wrote:
 I have established an sks keyserver and am ready to pair it with some
 existing pools.  In hopes of maintaining good etiquette I am requesting
 permission to sync with any willing participants.  My key database is
 current with the latest static key dumps.  Apologies in advance if this
 is the wrong venue to make this request.

You don't include any information about your server.  People might be
willing, but many of us want to poke at your /pks/lookup?op=stats page
first, to confirm that things are set up sanely.

Adding a peer is not entirely safe: you have the potential to DoS your
peers.  So it's wise to give things a quick look over to decide whether
or not to proceed.

You might read:
  https://bitbucket.org/skskeyserver/sks-keyserver/wiki/Peering
which will help you get started with getting a server into a fit state
for peering and asking for peers a way which will get you more replies.

-Phil

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

Re: [Sks-devel] Setting up hkps

[Phil Pennock]

On 2013-11-12 at 13:54 +0400, Dmitry Yu Okunev (pks.mephi.ru) wrote:
 Hello.
 
 On 11/12/2013 01:29 PM, David Benfell wrote:
  On Tue, 2013-11-12 at 10:16 +0100, Filip Stefaniak wrote:
  1) Do I need a real certificate (bought CAs) or can be it
  self-generated, self-signed certificate?
  
  You send a certificate request to Kristian Fiskerstrand. He's running
  his own certificate authority for this purpose and will generate a
  certificate from your request.
 
 Good news. However is there essential reason why Kristian's CA better
 than cacert.org's?

Yes: we're abusing the whole purpose of CAs, ensuring that anyone who
can run a keyserver competently can claim to be one common shared
hostname.

Any real CA will scream and block that.

Note: you can and should set up TLS SNI support in your webserver to be
able to use different certs for different hostnames.  So for your _own_
hostname, you use a cert from as real a CA as you want.

Kristian's CA is entirely around whether or not, when asked to present
credentials for the hostname hkps.pool.sks-keyservers.net, you will be
able to do so.

So https://sks.spodhuis.org/ has a cert from my own CA, because that's
all I care about for that hostname.  When that same host is accessed
with a hostname pool.sks-keyservers.net or *.pool.sks-keyservers.net
then I present a certificate from Kristian.  I can do similarly for
other hostnames.

Absent DNSSEC, the client can't chain hostnames to ask for a cert from
the real final hostname, so each extra hostname to be supported needs
a key.

*But*: stop and ask what you're protecting against.  This is public
data, so the only thing to be protected is against tampering or traffic
analysis.  In both cases, you don't know who is running the keyserver
if you use a pool hostname, so you have no protection from https.

Kristian's PKI for this is a decent experiment and a good way of making
sure we all know _how_ to run HKPS, and helping to make sure there's a
common baseline for making sure client tools work.  It's *not* a good
real solution for production usage.  For that, you should use your own
server, accessed under your own hostname, with a certificate from an
authority you trust locally.

(See also: an article on PGP by me in December's ;login: magazine)

-Phil


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

Re: [Sks-devel] Peering request

[Phil Pennock]

On 2013-11-04 at 22:36 +0100, Johan Bakker wrote:
 Hi all,

Hoi Johan,

 I just finished a new SKS keyserver installation. The server is located
 in the netherlands and connected by both IPv4 and IPv6.

It may be, but SKS is not responding on the IPv6 address.

It also doesn't _look_ as though you have a reverse proxy set up in
front, which you might want to fix: SKS is single-threaded,
request-at-a-time and prone to being DoS'd by a slow client, unless you
set up an HTTP reverse proxy in front, to take responsibility for
dealing with slow clients.

There are more details on setup, with suggested configurations, at:

https://bitbucket.org/skskeyserver/sks-keyserver/wiki/Peering

If you at least fix the IPv6, I'll be very happy to set up peering; my
machine is in NL, on the Coloclue network.

mvg,
-Phil

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

Re: [Sks-devel] reverse proxies and the pool

[Phil Pennock]

-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160

On 2013-10-30 at 19:34 +0100, Kristian Fiskerstrand wrote:
 You'll find this in the wiki[0], and for load balanced nginx I've also
 written a post on [1].
 
 References:
 [0] https://bitbucket.org/skskeyserver/sks-keyserver/wiki/Peering
 [1] http://blog.sumptuouscapital.com/2013/10/load-balancing-sks/

Hrm, say you have two instances, one only peering with the other, as
you describe.  Then during reconciliation of the two, when they're
talking to each other, they're likely to be busy at the _same_ time, so
load balancing isn't buying you much then.  It seems more that you'll
want to be biasing towards the internal-only one, so that what you're
buying protection against is the external peering occupying your
gateway.

In fact, it looks more like you want either:

 (1) at least two instances which are not gateway instances and not
 peering with each other; reverse proxy upstreams pointing to just
 those two
 (2) the same three instances total, all able to peer with each other,
 and the reverse proxy talking to all three (but with the gateway
 de-preferenced)

Otherwise, while what you describe is strictly better than a single
instance, I'm not sure its as much better as might immediately be
inferred without more analysis.

- -Phil
-BEGIN PGP SIGNATURE-

iEYEAREDAAYFAlJxhuoACgkQQDBDFTkDY398PwCfYwDyljXNRGnOUjxmhUr373Da
DF8AnR3IWZX38CPumUtF6SMuw5zJGTMa
=AfhV
-END PGP SIGNATURE-

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

Re: [Sks-devel] Seeking for gossiping peers for http://sks01.keyhub.io:11371

[Phil Pennock]

On 2013-10-28 at 09:00 -0500, John Clizbe wrote:
 Umm, what does peering have to do with the SKS version that one would refuse
 to peer with a server running a version prior to 1.1.3?

In addition to Sebastian Wiesinger's point about pre-1.1.2 POST issues,
I'll note:

 * The wiki Peering page has details on more core issues about versions

 * There are social, as well as purely technical, issues around peering.
   Some of those social issues have technical roots.

   Peering SKS is a matter of trust between operators; a misbehaving
   server can cascade operational issues onto its peers, most notably by
   being too far behind the current key count and causing the peers' CPU
   burden to go up during reconciliation.

   In any issue where you're asking strangers to trust you to run a
   service well, it is Helpful to demonstrate that you're willing to put
   in the effort to run that service well; unless we know someone from
   elsewhere, the best clue we each have is did they put in the work to
   provide a good initial setup?

   Being willing to find more recent versions of SKS than are packaged
   by default with the OS is a sign that the other person is taking the
   setup seriously.  It's not a guarantee that the peering will be
   well-run, but it demonstrates that:

1) they can do some basic package management beyond installing
   default packages, within a GUI
2) they can follow a somewhat technical setup guide, so are not
   likely to cause you to grit your teeth later in basic
   hand-holding while debugging an operational problem
3) if the install is being done on a whim, they're not being
   entirely cavalier about the setup

All of this is in a Peering wiki page because that's the name I chose
for it, and I chose that name because this affects an install of SKS
which you want to peer with others.  SKS can be run standalone, you can
do whatever you want with such a setup, nobody gets to tell you
otherwise (as long as you comply with the code license).  It's only when
you want to set up operational links with others that people like having
a reference point for encouraging current best practices.

I'm flattered that the page has come to be so well regarded.  :)

-Phil


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

Re: [Sks-devel] reverse proxies and the pool

[Phil Pennock]

On 2013-10-28 at 21:53 +0100, Gabor Kiss wrote:
 These efforts with HA pool reminds me bikeshedding.
 Wasting time with unremarkable things.

If there are three big problems, tackling them one by one while not
tackling the hardest _yet_ is not bikeshedding: it's improving the state
of affairs in manageable chunks, working slowly to gain consensus in a
community project.

Refusing to solve any of the problems because there's one really big
problem outstanding just leaves us in a worse state of affairs.  The
perfect is the enemy of the good.  Folks working to solve this does not
take away energy from anyone working on solving the really big problem,
does not work at cross-purposes to it and generally is constructive.

 I just don't agree with this step because I truly think its benefits
 are illusory and it is devaluation of efforts of enthusiastic
 volunteers who make sacrifies for the public.

The benefits are a more reliably fast response from PGP keyservers by
the general public using the normal names (eg, keys.gnupg.net which is
a CNAME to pool.sks-keyservers.net.)  This is not illusory: it reduces
frustration and helps PGP usage become more automatic, rather than
something to be disabled because it's causing problems and keeping the
email from getting out.

Anyone can volunteer to run a keyserver, and they can use whatever
configuration they like (as long as they can find peers).  Nobody is
proposing to stop peering with a non-proxied server.  You can use your
own keyserver, and you can encourage your friends to use your keyserver,
and you should do so to help preserve communicant privacy.

At question here is _one_ of the pool-maintainers, who runs the pools
which are normal, working to change the pool which various people use
as a default, until such time as they know someone they trust to
preserve their privacy and so can choose to use a specific keyserver.

Anyone can run a pool if they disagree with Kristian's decisions;
Kristian's developed a good reputation and is generally trusted, so
folks in other projects go so far as to pick his pool as the default.

Kristian's PHP keyserver-pool software is open sourced:

  https://code.google.com/p/sks-keyservers-pool/

My own keyserver-pool software (Golang, some scripting for DNS) is open
source:

  https://github.com/philpennock/sks_spider

So that's two available code-bases, in a choice of languages, for anyone
to run a pool and compete in an open market for mindshare, by running
the best service which they think people will like.

I, for one, think that it's good that there is a population of
keyservers with different policies which different people can layer
pools over the top of, for the public good.  I think it's good that
there's no cabal forcing certain behaviour, just some guidance which
most people follow because it makes life easier.  Any forced
restrictions are purely technical (eg, stopping peering with software
which is so old that peering is just broken).

I think that the goal of making the default serving pool be as fast and
responsive as possible, without one slow client affecting every other
user, is a good one.  I think that switching the default to HA should
happen at some point, the only question is when.

If we have enough reverse-proxy servers to provide decent latency to
every part of the world, then any time after now seems to be a
technically sound choice.  So, it seems to me that asking for input,
and if that has a rough consensus of yes then providing advance
notice, then making the change, is a very open and clear way to proceed
in how Kristian runs the volunteer service which _he_ runs.

To the extent that anyone other than Kristian has a vote as anything
more than a courtesy: I vote yes, it would be good for the main pool to
be HA-only, with a sub-pool for non-ha perhaps, and I think that a one
month lead-time would be very generous, giving people who want to stay
in the default pool but who haven't deployed a reverse proxy yet plenty
of time to do so.

-Phil


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

Re: [Sks-devel] disunitedstates.com now available on IPv6

[Phil Pennock]

-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160

On 2013-10-10 at 18:58 -0700, David Benfell wrote:
 I'm accepting hkp requests either at disunitedstates.com or at
 sks.disunitedstates.com . I'm doing recon only through

If I go to:
  http://sks.disunitedstates.com:11371/pks/lookup?op=stats
then I get a 404 from Apache.

- -Phil
-BEGIN PGP SIGNATURE-

iEYEAREDAAYFAlJYSywACgkQQDBDFTkDY39WEgCePIh/kDbzfkHISvqyvbx7jBqK
gYEAn0gkAL0buEmFiX5NhzRZf0Oq9vyf
=29hN
-END PGP SIGNATURE-

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

[Sks-devel] Apache reverse proxies: ProxyVia On advised

[Phil Pennock]

Folks,

Thanks to Todd Lyons checking in about the setup of his new server and
it not showing up as HA, I've updated the the contributed sample config
for Apache in the Peering wiki page:

https://bitbucket.org/skskeyserver/sks-keyserver/wiki/Peering#!apache

In short, adding ProxyVia On will result in seeing a header such as:

  Via: 1.1 sks.mrball.net:11371

in the responses.  This is needed if you want your server to show up in
the HA pool maintained by Kristian.

Regards,
-Phil


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

Re: [Sks-devel] why does SKS have /dev/random open for writing?

[Phil Pennock]

On 2013-09-19 at 13:31 -0400, Daniel Kahn Gillmor wrote:
 hi SKS folks--
 
 I was just looking at the behavior of sks 1.1.4, and i noticed that it
 seems to have /dev/random open for writing:
 
 0 zimmermann:~# lsof /dev/random 
 COMMAND PID   USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
 sks 742 debian-sks3w   CHR1,8  0t0 1244 /dev/random
 sks 756 debian-sks3w   CHR1,8  0t0 1244 /dev/random
 0 zimmermann:~# 

Something hinky here, as for me fd 3 is always the fd opened on the
pid-file, which I would expect to be opened for writing-only.  That's
managed by the daemon wrapper with which I start sks, so that sks
inherits it as an open fd.  I wonder if there's something glitchy in
your start-up/daemon-supervision configuration?  /dev/random being
specified as the pidfile ...

-Phil

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

[Sks-devel] Legalese for mismatched expectations

[Phil Pennock]

-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160

The world is changing, more people are trying out security technologies,
and if you think many people using PGP before didn't know what they were
doing, I think the next couple of years will drive a few more PGP folks
to drink.

One issue that arises is that as the userbase of a product shifts, and
their expectations of what the product provides shift, assumptions which
were fine before might stop being fine afterwards.  A lot of people now
want to have security, for free, with no understanding, and have it
somehow be PRISM-proof.  As someone in the USA who runs a PGP
keyserver for the general public, I need to take reasonable steps to
make sure that I convey clearly what a keyserver does or does not
provide for the people using it.

As a first step, earlier I updated the text on
http://sks.spodhuis.org/ with a new third paragraph, in HTML strong,
pointing out some security implications.  I probably need to find time
to mess with fonts to not have my CSS tell folks to use a font where
strong isn't very strong.

Here's what I came up with:

  Note: this service is provided free, to the public, in the hopes that
  it might prove useful. No warranty is provided, nor any offer of
  continuing service or access. By using this service, you MUST
  understand that presence of data in the keyserver (pools) in no way
  connotes trust. Anyone can generate a key, with any name or email
  address, and upload it. All security and trust comes from evaluating
  security at the “object level”, via PGP Web-Of-Trust signatures. This
  keyserver makes it possible to retrieve keys, looking them up via
  various indices, but the collection of keys in this public pool is
  KNOWN to contain malicious and fraudulent keys. It is the common
  expectation of server operators that users understand this and use
  software which, like all known common OpenPGP implementations,
  evaluates trust accordingly. This expectation is so common that it is
  not normally explicitly stated.

Perhaps others can improve upon this.

- -Phil
-BEGIN PGP SIGNATURE-

iEYEAREDAAYFAlIhMW4ACgkQQDBDFTkDY38rWgCcDVJ7i/wCvJyoX9DgoVp6utFA
A7MAn26C5K2TYNjs3oR/texosvG7kQm0
=IpKy
-END PGP SIGNATURE-

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

Re: [Sks-devel] Legalese for mismatched expectations

[Phil Pennock]

-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160

On 2013-08-31 at 02:57 +0200, Christoph Anton Mitterer wrote:
 On Fri, 2013-08-30 at 20:46 -0400, Jeffrey Johnson wrote: 
  Too many words, keep it KISS in plain speak.
 Agreed...

If I were smart enough to include the needed information in fewer words,
it would use fewer words.  Explicit suggestions appreciated, but needs
to be shorter is kind of obviously true.

 First, it's not our job to educate people with respect to
 cryptography/security in general...

It might not be our job, but in the jurisdiction I live in, there are
nasty concepts like attractive nuisance, where you can be minding your
own business, avoiding putting up barriers, and when someone else gets
in trouble through their own mistakes, you get in trouble for having a
garden without secure fences.

That's just the most obvious analogy; in the USA, there are all sorts of
nasty ways that providing a public service to others can leave you
legally exposed to the consequences of someone's ignorance.

When experts say surely nobody could blame us, judges say it's your
fault.  Especially if the experts can be painted as remote robots and
it's an election season (since many judges are elected too).

So, I am absolutely going to have warning text, even if it's not my
job to take responsibility for the ignorance of others.

- -Phil
-BEGIN PGP SIGNATURE-

iEYEAREDAAYFAlIheiQACgkQQDBDFTkDY3/DhwCfUQO3TkOjeDGZjWyic8k8KmvH
GRIAn2KHXiTAZzG+PghpwjOZxCJtwDac
=atH9
-END PGP SIGNATURE-

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

Re: [Sks-devel] sks recon failed with Sys_error(Bad file descriptor) during reload

[Phil Pennock]

On 2013-08-29 at 15:39 -0400, Daniel Kahn Gillmor wrote:
 This continues to happen with sks 1.1.4.
 
 it seems that sometimes, sending a SIGHUP to my sks recon process causes
 it to terminate, and other times it does not.

I wonder if what's happening is that a call elsewhere is failing with
EINTR and that's not being handled?

I haven't had time to hack on it but it seems to me that some of the
recent signals-based functionality would be better done by adding
commands to sks which communicate through the sockets, so that
sks membership-reload uses recon_com_sock to request an update, which
can be handled without having to worry about signals.

-Phil


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

Re: [Sks-devel] keyserver.sincer.us needs more peers

[Phil Pennock]

On 2013-08-22 at 01:35 +0200, Petru Ghita wrote:
 keyserver.sincer.us needs more peers as it seems it's falling out of the
 pool due to not having enough connectivity and therefore missing keys.

You have plenty of peers, that's not the problem.

One reliable peer is enough to stay up-to-date.  More peers adds more
resiliency.  Even having just three is probably fine, but more than that
means you survive disappearing hosts, etc.

I *suspect* that this is fallout from the increased rate of key
generation post-PRISM combined with more folks using cron to trigger
stats regeneration every hour, instead of once a day.

When everyone had stats generated once per day, the standard deviation
(stddev, σ) of the key counts is broad enough to cover the distribution
of keys received during the course of the day.  As more people generate
stats hourly (by sending SIGUSR2 to sks) the stddev shrinks and folks
who only generate stats daily will, during the course of the day, appear
to be behind until their daily stats generation kicks in.

There are two fixes:

 1. pool maintenance allowing for an increased daily jitter, as a result
of the increased rate of keys post-PRISM
 2. any operator who actually cares whether or not they're in the pool
can send SIGUSR2 to their SKS every hour or so.

Honestly, when you drop out of the pool temporarily, you stop donating
free bandwidth to the public, it's not really a bad thing. ;)

-Phil

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

Re: [Sks-devel] Proxy config issue and question

[Phil Pennock]

On 2013-08-20 at 13:30 -0400, James Cloos wrote:
  PP == Phil Pennock sks-devel-p...@spodhuis.org writes:
 PP Use:
 PP   https://bitbucket.org/skskeyserver/sks-keyserver/wiki/Peering#!nginx
 
 Too bad that isn't what shows up when searching for example configs.

Write a blog post and link to it, help improve the reputation of the
wiki site so that search engines rank it more highly.  :)

There's not much else we can do, besides put correct information out
there.

 I'm sure I'm not the only one who used goog as a reminder and ended up
 with a config like the one I quoted.

People are wrong on the Internet.  It happens.

 It would be better were the proxy able to listen(2) on 0.0.0.0 a/o ::.

Depending upon your setup, you very possibly can.  On Unix systems with
a BSD sockets API (which is all of the Unices that are left, I think),
a specific binding takes precedence over an INADDR_ANY binding.

Debugging that and helping people through just leads to more confusion,
as we then have to talk about layers of binding and more specific
binding, and debug server software which sees INADDR_ANY and iterates
the interfaces, binding to each IP in turn to prevent this masking
behaviour (as some security-conscious software does).

So instead, the example configurations keep things as simple as
possible, both for simple to set up and simple to debug.

Once you have a working configuration, which you can revert back to if
things go wrong, you can of course experiment with better
configurations for your setup.

-Phil

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

Re: [Sks-devel] Proxy config issue and question

[Phil Pennock]

On 2013-08-19 at 17:59 -0400, James Cloos wrote:
 If one configures a proxy (such as nginx) with a config like:

Don't, because that's not what the Peering wiki page says to do and
advertises the wrong port.

Use:
  https://bitbucket.org/skskeyserver/sks-keyserver/wiki/Peering#!nginx

 Instead, you need to specify 'hkp_port: 11371' in sksconf and configure
 the proxy like:

 with listen directives for each specific address.

Yes, that's why the Peering wiki page explicitly does this: SKS needs to
listen on localhost, nginx (or other reverse proxy) on the public
addresses, using the same port number for each.  This is handled in the
examples for all three web-servers for which example configurations are
provided.

 Perhaps this is why some severs seem to lack some keys?

I doubt it.

The spiders tend to force port 11371; if you know of a server where
/pks/lookup?op=stats works on 11371 but shows a different port, then
please re-educate the server operator.

The peering code actually just uses the SKS reconciliation port +1,
not the value configured in sksconf, so peering will get the keys
through as long as you peer on 11370.

 Continuing on the nginx front, what is the optimal config for ports 80
 and 443, presuming that one wants to be able to serve other content on
 those ports in addition to /pks/?  I've tried several, and non worked
 reliably.

Make sure that /pks/ is passed through to SKS, no matter what hostname
is used, so that you can be in various pools.  For 443, additionally
look into what certificates you want to use, and read this page:

  http://www.sks-keyservers.net/overview-of-pools.php

for instructions on getting a cert for the hkps.pool.sks-keyservers.net
hostname.

You'll need to either have `default_server` on the listen lines for one
of the servers, or make sure you know which is first in the config
parsing for a given IP/port, so that on the default server for port 80
and 443, you can pass through /pks.

For myself, the various relevant server blocks just have:

location /pks {
proxy_pass http://127.0.0.1:11371;
proxy_set_header   Host $host:$server_port;
proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;
proxy_pass_header  Server;
add_header Via 1.1 sks.spodhuis.org:80 (nginx);
proxy_ignore_client_abort on;
}

The proxy_set_header rules are not needed, they just give SKS's own
debug logs more meaningful data.

-Phil

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

Re: [Sks-devel] Peering status of limited peers

[Phil Pennock]

On 2013-08-12 at 20:00 -0400, Phil Pennock wrote:
   http://people.spodhuis.org/phil.pennock/tmp/sks-degree7.png
 
 It's 4035x2505 and very readable.  600kB.
 
 Nodes without a non-zero keycount are dropped.  Edges which are not
 mutual are dropped (you only really peer if both sides agree you peer);
 thus there's a bias against recently added peerings, if one side does
 not have stats being regenerated after adding peers.
 
 Nodes with a green border have at least 7 peers.  Nodes with a red
 border do not.  I'm not debugging what happened to stinkfoot.org right
 now.  The only edges shown are those where at least one of the nodes is
 coloured red.

I realised later that night what the black border means: it means that
the host has no valid peerings, so a colour is not set.

So:
 * stinkfoot.org
 * keyserver.novomundo.com.br

do not have any functioning peering relationships and are not getting
PGP key updates.  Indeed, you can see the complete absence of updates
on:

  http://stinkfoot.org:11371/pks/lookup?op=stats
  http://keyserver.novomundo.com.br:11371/pks/lookup?op=stats

Both servers list peers, but none of those are shared peering
relationships.  Thus stinkfoot.org is 25k keys behind and
keyserver.novomundo.com.br is 250k+ keys behind.


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