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