Re: Packet length: header vs. context

[Ian G <[e-mail]>]

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