sks-devel
[Top][All Lists]
Advanced

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

Re: [Sks-devel] keyserver.gingerbear.net: Dynamic IP Update didn't


From: Daniel Kahn Gillmor
Subject: Re: [Sks-devel] keyserver.gingerbear.net: Dynamic IP Update didn't
Date: Fri, 13 Mar 2009 13:34:40 -0400
User-agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103)

On 03/13/2009 01:19 PM, David Shaw wrote:
> If a misbehaving peer can cause problems with sks, a misbehaving peer
> can still cause problems with sks even if the connection is
> authenticated.  Not the authenticating and/or encrypting connections
> is necessarily bad, but it doesn't really solve the memory problem.

agreed!  The memory issue ultimately needs to be addressed no matter
what.  But in the current situation, anyone who can control the network
can trigger the memory failure (by masquerading as a peer), whereas with
TLS protected gossip, only authenticated peers are capable of exercising
that particular codepath in SKS.  That's a much smaller pool.

> I suppose it might help keep out a potential malicious gossiper, but
> (and correct me if I'm wrong) aren't the gossip connections configured
> manually anyway?

They are.  And if a peer demonstrated repeated misbehavior i'd probably
want to delist them anyway, even if i thought that SKS was impervious to
any sort of attack through the recon interface.  Without TLS, though, i
can't even tell whether the remote peer is actually the remote peer.

FWIW, i actually do think there's some merit for private
keyserver-to-keyserver connections as well, but i don't think the
arguments for that are as universally applicable as the arguments for
authenticated and integrity-checked gossip.

        --dkg

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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