Re: Packet length: header vs. context
Jon Callas <jon@callas.org> Tue, 09 January 2007 01:03 UTC
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H45P4-0007qo-TO for openpgp-archive@lists.ietf.org; Mon, 08 Jan 2007 20:03:50 -0500
Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H45P2-0006QI-T4 for openpgp-archive@lists.ietf.org; Mon, 08 Jan 2007 20:03:50 -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 l090Zkfs087351 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Jan 2007 17:35:46 -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 l090Zk9V087350; Mon, 8 Jan 2007 17:35:46 -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 merrymeet.com (dsl093-068-160.sfo1.dsl.speakeasy.net [66.93.68.160]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l090ZiET087344 for <ietf-openpgp@imc.org>; Mon, 8 Jan 2007 17:35:45 -0700 (MST) (envelope-from jon@callas.org)
Received: from keys.merrymeet.com (dsl093-068-161.sfo1.dsl.speakeasy.net [66.93.68.161]) (Authenticated sender: jon) by merrymeet.com (Postfix) with ESMTP id 714C246E8CD for <ietf-openpgp@imc.org>; Mon, 8 Jan 2007 16:35:44 -0800 (PST)
Received: from [63.251.255.205] ([63.251.255.205]) by keys.merrymeet.com (PGP Universal service); Mon, 08 Jan 2007 16:35:44 -0800
X-PGP-Universal: processed; by keys.merrymeet.com on Mon, 08 Jan 2007 16:35:44 -0800
In-Reply-To: <E1H3mGE-0006wa-00@medusa01.cs.auckland.ac.nz>
References: <E1H3mGE-0006wa-00@medusa01.cs.auckland.ac.nz>
Mime-Version: 1.0 (Apple Message framework v752.3)
Message-Id: <63976A6F-D5AD-4435-B50A-999F4234C238@callas.org>
Cc: OpenPGP <ietf-openpgp@imc.org>
From: Jon Callas <jon@callas.org>
Subject: Re: Packet length: header vs. context
Date: Mon, 08 Jan 2007 16:35:02 -0800
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>
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
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.1 (/)
X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793
-----BEGIN PGP SIGNED MESSAGE----- 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. Jon -----BEGIN PGP SIGNATURE----- Version: PGP Universal 2.5.2 Charset: US-ASCII wj8DBQFFouNgsTedWZOD3gYRAuzyAJ9iqDne/UTQl+14S6X5muT0eNzlnACg4j4l o3rr5YbHfS9vy52V3Rf35T8= =TLKD -----END PGP SIGNATURE-----
- 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