sks-devel
[Top][All Lists]
Advanced

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

Re: [Sks-devel] Broken keyservers (413 Request Entity Too Large)


From: Arnold
Subject: Re: [Sks-devel] Broken keyservers (413 Request Entity Too Large)
Date: Thu, 04 Sep 2014 22:28:23 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.5.0

On 04-09-14 22:13, Kim Minh Kaplan wrote:
> David Benfell wrote:
>> On Thu, Sep 04, 2014 at 02:31:38PM +0200, Arnold wrote:
>>> On 04-09-14 08:16, Christoph Egger wrote:
>>>> Seems uploading my gpg key (d49ae731) to pool.sks-keyservers.net fails
>>>> for several of the hosts in rotation:
>>>
>>> The question is: is the key too large, or should we accept keys of *every* 
>>> size?
>>>
>>> Accepting every key size does not scale well in the long term. It can also 
>>> lead to
>>> a nasty DOS attack: upload many huge keys to eat all the public key server
>>> resources. We currently have no means to remove keys or specific key data.
>>>
>> Actually, I think this isn't the problem you're making it out to be.
>>
>> Ellyptic Curve Cryptography keys are much smaller and will be
>> supported in GPG 2.1. Some implementations of 2.0 also seem to support
>> these keys currently.
>>
>> The largest RSA key size I've seen implemented is 8192. This is in APG
>> (the Android variant). I would suggest setting an upper bound of
>> 16384.
> 
> Obviously Arnold is not referring to the cryptographic key size but to
> the complete OpenPGP key size, the whole shebang. 0xd49ae731 has many
> uids each signed with loads of signatures. It is close to one million
> bytes in its armored form.

Indeed.

> Still I do not see how limiting the size of a single key would protect
> the SKS key servers from a DOS. To an attacker uploading many huge
> keys has about the same difficulty as uploading many many big keys.

Yes, that is true. However, not limiting the key size (or taking effort to raise
the limit that seems to be in effect) will not help in any way. With a limited 
key
size as first step, it is easier to implement further measures like limiting the
amount of keys one can upload per hour from a given IP subnet (IPv6 proof ;-) )

Fortunately, currently we suffer no attacks, but (like many open standards and 
open
software) we take good intentions for granted. It won't harm us to think about 
the
weaknesses of our system and then decide (educated) if we take the risk or take
measures.

Arnold



reply via email to

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