[Top] [All Lists]

Re: Packet length: header vs. context

2007-01-06 07:34:59

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 ;)