Re: Packet length: header vs. context
Ian G <iang@systemics.com> Sat, 06 January 2007 14:34 UTC
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3CdD-0005Tm-Gj for openpgp-archive@lists.ietf.org; Sat, 06 Jan 2007 09:34:47 -0500
Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3CdA-0006o0-JE for openpgp-archive@lists.ietf.org; Sat, 06 Jan 2007 09:34:47 -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 l06E9aeX082089 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 6 Jan 2007 07:09:36 -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 l06E9adS082088; Sat, 6 Jan 2007 07:09:36 -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 www2.futureware.at ([217.19.43.211]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l06E9YLX082079 for <ietf-openpgp@imc.org>; Sat, 6 Jan 2007 07:09:35 -0700 (MST) (envelope-from iang@systemics.com)
Received: from [127.0.0.1] (localhost [127.0.0.1]) by www2.futureware.at (Postfix) with ESMTP id B85DC226222; Sat, 6 Jan 2007 15:09:36 +0100 (CET)
Message-ID: <459FADA8.20204@systemics.com>
Date: Sat, 06 Jan 2007 15:09:44 +0100
From: Ian G <iang@systemics.com>
User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207)
MIME-Version: 1.0
To: Levi Broderick <lpb@ece.cmu.edu>
Cc: ietf-openpgp@imc.org
Subject: Re: Packet length: header vs. context
References: <459ECBC5.3010101@ece.cmu.edu>
In-Reply-To: <459ECBC5.3010101@ece.cmu.edu>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
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.0 (/)
X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca
Levi Broderick wrote: > (resending, as the original message seems to be MIA) > > Consider the following scenario: > > An implementation is parsing a public-key packet. The packet header > gives a body length of 600 bytes; this is then buffered into memory. > The software successfully parses all the data in the packet body - > everything from the packet version number to the final MPI that it was > expecting - and realizes that it has only read 400 bytes. > > Even if the public key data was successfully parsed, should the > implementation consider the packet to be malformed and reject the key? > Or should the leftover data be considered optional and be ignored? I > think it makes more sense to error out, but the RFC draft and mailing > list archives seem to be silent on this issue. This sounds like one of those philosophical questions about coding, and it may be that the draft would be better off remaining silent on that question. The GNU world characterised this as "be precise in what you send, be liberal in what you read." That is, be accomodating when finding input. In this context the answer to the above question is "accept the key." I think it was Dan Bernstein (?) who said something different. He said, "in security work, be precise in what you send, and precise in what you read." So his answer would be "reject the key." I like the second answer for security work, but OpenPGP is somewhat in between these worlds; there are several implementations and they all have foibles, and the coding history goes back a long time. It is a fact of life that there have been "disagreements" on how to interpret certain things, and differing implementations have had to deal with it; we can't just "start again" with all the implementations. How to deal with that world? I would say that (a) your market will tell you, and (b) you might want a third mode of "accept but warn" alongside "reject" and "accept." Finally, the ID has passed the point of minor tweaks. We've been at this for a decade now. No more changes please, seal the document and let's move on. I vote NO to any changes, even without knowing what they are ;) iang
- 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