sks-devel
[Top][All Lists]
Advanced

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

Re: [Sks-devel] Configuring the reverse proxy to support large keys - HT


From: Phil Pennock
Subject: Re: [Sks-devel] Configuring the reverse proxy to support large keys - HTTP error 413
Date: Mon, 28 Apr 2014 14:07:55 -0400

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

Attachment: pgpdGSzDCZiUc.pgp
Description: PGP signature


reply via email to

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