Re: Packet length: header vs. context
Jon Callas <jon@callas.org> Mon, 08 January 2007 00:14 UTC
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3i9i-0007XM-6T for openpgp-archive@lists.ietf.org; Sun, 07 Jan 2007 19:14:26 -0500
Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3i9g-0003Ub-Le for openpgp-archive@lists.ietf.org; Sun, 07 Jan 2007 19:14:26 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l07NuBh8084007 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 7 Jan 2007 16:56:11 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l07NuBeC084006; Sun, 7 Jan 2007 16:56:11 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from merrymeet.com (dsl093-068-160.sfo1.dsl.speakeasy.net [66.93.68.160]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l07NuAgb084000 for <ietf-openpgp@imc.org>; Sun, 7 Jan 2007 16:56:10 -0700 (MST) (envelope-from jon@callas.org)
Received: from keys.merrymeet.com (dsl093-068-161.sfo1.dsl.speakeasy.net [66.93.68.161]) (Authenticated sender: jon) by merrymeet.com (Postfix) with ESMTP id DED474690D3 for <ietf-openpgp@imc.org>; Sun, 7 Jan 2007 15:56:09 -0800 (PST)
Received: from [66.93.68.165] ([66.93.68.165]) by keys.merrymeet.com (PGP Universal service); Sun, 07 Jan 2007 15:56:09 -0800
X-PGP-Universal: processed; by keys.merrymeet.com on Sun, 07 Jan 2007 15:56:09 -0800
In-Reply-To: <459ECBC5.3010101@ece.cmu.edu>
References: <459ECBC5.3010101@ece.cmu.edu>
Mime-Version: 1.0 (Apple Message framework v752.3)
Message-Id: <AF6FB1BD-FB2C-45AB-A183-3F9BE38D54D0@callas.org>
Cc: ietf-openpgp@imc.org
From: Jon Callas <jon@callas.org>
Subject: Re: Packet length: header vs. context
Date: Sun, 07 Jan 2007 15:56:08 -0800
To: Levi Broderick <lpb@ece.cmu.edu>
X-Mailer: Apple Mail (2.752.3)
X-PGP-Encoding-Version: 2.0.2
X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: 7bit
X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ian touched on many of the salient points of this dilemma. The most correct answer to the problem you pose is "mu." This is something that you have to make a personal decision on. Let's suppose that the standard said something definitive on this. Many people have gotten into a lot of trouble by over-implementing standards. Let's suppose, for example, that you reject the key. Let's then suppose that someone finds that they can't import in keys that were created with software X on OS Y with a key size of a prime number of bits. Well -- what do you do? There are people who want to use your code and can't, and it's not your fault. Screw 'em, they're the ones who got the standard wrong. But when it turns out that the problem is that your software doesn't work with the new OpenPGP in Linux that runs underneath Windows Mobile Horizon that ships in the new Apple iTunesFone (when it creates keys 1987 bits long (selected because it's a prime number *and* the year programmer's GF was born -- cool, huh?)) and because of it, people can't download music from WalMart's GNU Music Share -- well, the story on Slashdot is going to have *your* software's name on the headline, not theirs. You'll be changing your code to ignore that one extra byte because otherwise every phone in Korea has to be re-flashed, and it's faster for you to change than them. (Something similar to this happened to PGP once, but I changed the name of the country in my explanation.) An alternative to just accepting that packet would be to lop off the extra data (which will be ignored), and make the length correct. When you implement a protocol, there are often more choices than being anal or passing idiocy through. In the one you've given, it's almost certainly true that you can tweak the packet to the right size and not affect anything else. So why not do so? It might also be a good thing to tell the people who are doing something dumb that they're doing something dumb, but don't expect them to fix it tomorrow, especially since there's a workaround. When it's been a couple of years and no fix has arrived, you have earned the right to be snarky, but by then you probably forgot the workaround you put in your code, too. As for your second question -- where partial lengths can be used -- what's your real question? Do you want to use them in places other than data packets? Is someone subjecting you to them and it's a pain in the neck to parse them? It's Sunday afternoon and I need to run some errands, so I don't want to go crawl through the spec. I *believe* that they can be used anywhere. But I also believe they shouldn't be used everywhere. In the case of a 400-byte packet header, whatever would possess someone to do that? Yeah, I'm sure it's legal, but don't do it. If it's the software I'm responsible for that's doing something cringe-worthy, I'm sorry. Partial lengths exist so that you can process arbitrarily large chunks of data that don't fit in memory and might even be inconvenient for you to know the size of a priori. That really means data packets. However, as a software engineer, I think that even if some idiot chopped up a 400-byte key packet into 2-byte partials, your software ought to work. If it doesn't, you have to consider who the idiot is. That brings us back to the original consideration. Welcome to being a software engineer. Sometimes the things we have to do because other people are idiots suck. A sense of humor helps deal with it, but doesn't prevent it from sucking. Jon -----BEGIN PGP SIGNATURE----- Version: PGP Universal 2.5.2 Charset: US-ASCII wj8DBQFFoYiZsTedWZOD3gYRAjbyAJwLiOgAYYHSjANqhkaPDpKZ9V1b8QCgpFr3 eLbCx4/y6vWM8hIeqYHNh9k= =jbmi -----END PGP SIGNATURE-----
- Packet length: header vs. context Levi Broderick
- Re: Packet length: header vs. context Ian G
- Re: Packet length: header vs. context Jon Callas
- Re: Packet length: header vs. context Levi Broderick
- Re: Packet length: header vs. context Jon Callas
- Re: Packet length: header vs. context Jon Callas
- Re: Packet length: header vs. context Peter Gutmann
- Re: Packet length: header vs. context Ian G
- Re: Packet length: header vs. context Ian G
- Re: Packet length: header vs. context "Hal Finney"
- Re: Packet length: header vs. context Jon Callas