Re: [Sks-devel] Re: Debian SKS packages was: [pgp-keyserver-folk] new pgp key server

[Yaron Minsky]

On Sun, 19 Sep 2004 16:20:30 -0400, David Shaw <address@hidden> wrote:
> On Sun, Sep 19, 2004 at 02:42:34PM -0400, Yaron Minsky wrote:
> > On Sun, 19 Sep 2004 11:33:55 -0400, David Shaw <address@hidden> wrote:

> > Interesting.  This wouldn't be difficult from the way SKS handles
> > things.  Basically, SKS first parses the key down to the packet level,
> > which works without problems for this key.  Things like MPIs are only
> > looked at within the packet level.  If one such is found to be bogus,
> > the packet could then easily be thrown out.  I'm somewhat surprised
> > it's not handled similarly in GPG.
> 
> But that's a problem also - you can't packetize something if the
> packet boundaries are bogus.  Or rather you can, but you don't know
> what you're going to get.

I'm not sure what you mean.  You can just handle this at different
levels.  The packet-level structure of this key must be A-OK, since
otherwise SKS would have barfed on it.  Once you break it up into
packets, you can dissect those.  If any of the packets are bogus, you
toss them out.  It seems simple enough, and I don't see what the
pitfalls are of doing this.

> This particular form of bogosity is just syntax and can easily be
> checked even without crypto.  It's a public key (or subkey, or
> signature) with specified length X, that contains contents that add up
> to more or less than X.  This can happen because MPIs have their own
> length specified.  In a corruption case, the internal parts may not
> add up to (or may add up to more than) the outer part.
> 
> For example, take the broken subpacket we've been talking about.  It
> is an old-style #14 public subkey packet with the 3-octet header (2
> octet length).  The length is 269 bytes.  We have the usual few bytes
> of header, a version byte (4), 4 bytes for the creation date
> (1061237196), 1 byte for algorithm (Elgamal encrypt-only).  That
> leaves 263 bytes unaccounted for.  Next come the MPIs.  The first MPI
> for Elgamal is the prime p.  The 2 length bytes say it is 1024 bits
> long, so we read 128 bytes more.  That leaves 133 bytes of the
> original packet unaccounted for.  The next MPI is the Elgamal
> generator g.  The 2 length bytes say it is 30918 bits long, so we read
> 3865 bytes.... and bzzt!  We've walked off the end of the packet.
> This packet is corrupt, and no crypto was needed to verify it.
> 
> The problem here is what, exactly, is corrupt?  Are one or more of the
> MPIs broken... or is the original packet length wrong?  Either way,
> the packet is shot, but in the first case it is possible to drop the
> packet and keep going.  In the latter case, you have to stop since you
> have no way of knowing where you are in the datastream any longer.

Well, sure you do.  Basically, your only hope for getting any data out
is that the packet structure is intact.  So you should try to parse
the key under that assumption.  No value is added by giving up when
the MPI is too long.  This is especially true in a world with
keyservers like PKS and SKS that combine keys without considering the
contents in detail.

You point out that this is a basic syntactic bug in the key format,
and that it should be easy to discard the bogus packets.  That's true,
but how much of the syntax of the RFC should I enforce?  I'm sure
there are lots of syntactic grounds on which one could toss out keys,
even though those keys might be perfectly well parseable with GPG and
PGP.  The goal, I thought, was for keyservers to be generally lax, and
for client software to clean up after.    I still feel like SKS is
basically doing the right thing here, and that the problem is that GPG
isn't cleaning up the bad data well enough.  (That said, just fixing
GPG isn't a great solution, given the installed-base problem.)

> GnuPG, perhaps conservatively, kicks out the whole key import if it
> detects this problem.  That a reasonable solution for a keyserver as
> well.  It could theoretically try and accept the part of the key
> before the corruption was detected, but it doesn't do that today.
> 
> I'm somewhat leery of the idea of a keyserver trying to do repair work
> on corrupt keys.  I figure the key is busted.  Kick it back to the
> submitter (or just drop it if learned from another server) and let the
> original submitter fix it.

Yeah, but what do we do about corrupted keys already in the database,
or keyservers that are in the network but aren't up to date, so they
keep on spewing broken keys into the database.

The solution I like is to have an _optional_ key cleaner, for
presentation use only.  You could set a flag and get the raw key out. 
In addition, new keys that are broken should be rejected, as you
suggest, but I think the cleaner is still necessary.

> David
>