Re: Packet length: header vs. context

Jon Callas <> Tue, 09 January 2007 01:03 UTC

Received: from [] ( by with esmtp (Exim 4.43) id 1H45P4-0007qo-TO for; Mon, 08 Jan 2007 20:03:50 -0500
Received: from ([]) by with esmtp (Exim 4.43) id 1H45P2-0006QI-T4 for; Mon, 08 Jan 2007 20:03:50 -0500
Received: from (localhost []) by (8.13.5/8.13.5) with ESMTP id l090Zkfs087351 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Jan 2007 17:35:46 -0700 (MST) (envelope-from
Received: (from majordom@localhost) by (8.13.5/8.13.5/Submit) id l090Zk9V087350; Mon, 8 Jan 2007 17:35:46 -0700 (MST) (envelope-from
X-Authentication-Warning: majordom set sender to using -f
Received: from ( []) by (8.13.5/8.13.5) with ESMTP id l090ZiET087344 for <>; Mon, 8 Jan 2007 17:35:45 -0700 (MST) (envelope-from
Received: from ( []) (Authenticated sender: jon) by (Postfix) with ESMTP id 714C246E8CD for <>; Mon, 8 Jan 2007 16:35:44 -0800 (PST)
Received: from [] ([]) by (PGP Universal service); Mon, 08 Jan 2007 16:35:44 -0800
X-PGP-Universal: processed; by on Mon, 08 Jan 2007 16:35:44 -0800
In-Reply-To: <>
References: <>
Mime-Version: 1.0 (Apple Message framework v752.3)
Message-Id: <>
Cc: OpenPGP <>
From: Jon Callas <>
Subject: Re: Packet length: header vs. context
Date: Mon, 8 Jan 2007 16:35:02 -0800
To: Peter Gutmann <>
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
Precedence: bulk
List-Archive: <>
List-Unsubscribe: <>
List-ID: <>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793

Hash: SHA1

On Jan 7, 2007, at 8:37 PM, Peter Gutmann wrote:

> And before Jon Postel said that, the MIT hackers said "Look for  
> anything that
> says 'Don't to X', then try as many variations of X as possible.   
> "Postel's
> Law" is great for interoperability, terrible for security.

I'll disagree just a bit, Peter, because one of the best ways to get  
security is a lack of interoperability. Rip your network cable out of  
the wall and you have great security.

Yes, if you maximize interoperability, it has effects on security.  
Yes, you can come up with an interoperability hack that is cringe- 
worthy from a security standpoint. Yes, the Internet as we know it is  
riddled with them. But the Internet as we know it out-competed other,  
more secure systems, and succeeded against them because it viewed  
interoperability as the primary virtue (and had an attitude about  
security that included lines like, "polite clients don't *do* that").

"Postel's Law" is a valuble rule of thumb. You *should* (maybe that  
should be SHOULD) be conservative in what you generate and liberal in  
what you accept. It just shouldn't override everything else. The more  
that the rough consensus of implementors succeeds at the former, the  
less it needs to do of the latter. Writing software is an art, not a  
state machine. It needs wisdom.

The example we got here was a good one because there's no obvious  
most right answer. My opinion is that the best answer is to fix up  
the bad data and proceed. That has its own drawbacks. Just accepting  
it is probably worst, but rejecting it isn't that much better.

Interoperability matters. Without it, we don't need security.


Version: PGP Universal 2.5.2
Charset: US-ASCII