[arch-d] Chaff in protocols

"Martin Thomson" <mt@lowentropy.net> Thu, 27 June 2019 04:12 UTC

Return-Path: <mt@lowentropy.net>
X-Original-To: architecture-discuss@ietfa.amsl.com
Delivered-To: architecture-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B7BC12012A for <architecture-discuss@ietfa.amsl.com>; Wed, 26 Jun 2019 21:12:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=sd2jIZFf; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=qp/CIogm
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Q1KO2u51xqe for <architecture-discuss@ietfa.amsl.com>; Wed, 26 Jun 2019 21:12:55 -0700 (PDT)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E1E61200FF for <architecture-discuss@ietf.org>; Wed, 26 Jun 2019 21:12:55 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 5584521C4D for <architecture-discuss@ietf.org>; Thu, 27 Jun 2019 00:12:54 -0400 (EDT)
Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Thu, 27 Jun 2019 00:12:54 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:date:from:to:subject:content-type; s= fm2; bh=vr2EN0chq3KX5ciwca58jZiooDMyyJm0McYU5Dg+PtQ=; b=sd2jIZFf WOfySwbHtXUCotwU/TCgpBMs3R9zsKLOGxFwak7pjQv4DTP2+ElnzC1qJVn5fWr0 rF5mMAbRawvLIqZB+NyeBcaiYT3OIZo7ym3gLlz69VjbUMhqeJTlho3lRYmBKXrE Zfo8xtMDEzYBW9x/oPfJVgRvX+L5vXG7dCO8CAOEgjdJwK0vbaLFyW92nwNpGRnJ +PMYwORG8+PvxdYLTIVK34OIhwu3F1X5eNb/iL9wUKlHlUepKYe+F0oV4r+lncKz bEobzEgh85jwkXn6DS8B5x6P5IVpKcEdoOy1mthQDw0+44pLWBHUWFNMHCha39WG jCZHDgLbWlc6ug==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=vr2EN0chq3KX5ciwca58jZiooDMyy Jm0McYU5Dg+PtQ=; b=qp/CIogmoozmosYTroC73ZpPWcbaXwS0rXjVUya8u1xrJ MFHIVp/3OIq2/5MBsxr3yZmB027bP+N3la2IuTKlsadtN31ziPrdi9kl8RlSWRS7 n5zkW5nn+LTr8bQ6CvUFhxHL0R8DwE9qqGBwnp4iW3YcH5LFjSrK2Aq//+Ts/Nat Ewgob0oElG9eISuxcON1K3BOzVt8QIYzryx7nZC4cbnEgQcpku4Ff1e+uxGfJjMK KQfBiSmYm1zH2AOyHbjWnDa28zaywK3bm44jHGrR4cmAEdeUdJCCSMQg4eL0T9gO UC4dHP7jEE/kw3UlKvzqB6zQFqKROUxGvBi8SVd9A==
X-ME-Sender: <xms:RUIUXTrht4-1wGsrTGM6hXHFSl9p88tiHQqARrWylkGCcYcoz2BIQA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrudejgdekvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkfffhvffutgesthdtredtre ertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohifvghn thhrohhphidrnhgvtheqnecuffhomhgrihhnpeifihhkihhpvgguihgrrdhorhhgpdhgih hthhhusgdrtghomhenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhr ohhphidrnhgvthenucevlhhushhtvghrufhiiigvpedt
X-ME-Proxy: <xmx:RUIUXZII9anDMdI2lhpO58jHrrPtiEx4pzkbLgEVWAnBAFPmffN7Mw> <xmx:RUIUXWOJUO1qNd3guVfaApoLRowkA0X3MUZW2Xs395yJbyyD9SiHeQ> <xmx:RUIUXUpGhR64QUM_tkwdPQQaDgt1Yag_lq3ds6vW_NCxBYNwhK8X-A> <xmx:RkIUXT7xZk8vbn8lOtzZkoKJbz1wzi92TaiSuo_ZvbcHmw1eElKEcQ>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 7004AE00A2; Thu, 27 Jun 2019 00:12:53 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.1.6-730-g63f2c3b-fmstable-20190622v1
Mime-Version: 1.0
Message-Id: <a33aad56-7ca9-4913-98a7-dd96113815e7@www.fastmail.com>
Date: Thu, 27 Jun 2019 14:12:54 +1000
From: Martin Thomson <mt@lowentropy.net>
To: architecture-discuss@ietf.org
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/architecture-discuss/-08yKd2cMpEo-O__rlLQSBRKkVc>
Subject: [arch-d] Chaff in protocols
X-BeenThere: architecture-discuss@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: open discussion forum for long/wide-range architectural issues <architecture-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/architecture-discuss/>
List-Post: <mailto:architecture-discuss@ietf.org>
List-Help: <mailto:architecture-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Jun 2019 04:12:57 -0000

Esteemed colleagues,

The IAB is looking for historical examples of deliberate additions to a protocol that are added not to enable new behaviour, but to test that the ability to do so remains viable.

This comes up in the context of assessing the concept of "grease" (see draft-ietf-tls-grease), a practice of adding meaningless extension points to messages in the hope that it will reveal, and perhaps prevent, intolerance toward real extensions.  This is a practice we have seen deployed with some success in TLS.  That has produced some enthusiasm about the practice.  I think that it would be fair to say that the IAB maintains some reservations about the general applicability of the technique.

Are there protocols (in either specification or deployment) that have experimented with this sort of thing in the past?

The concept of fuzzing software isn't new (see https://en.wikipedia.org/wiki/Fuzzing) and testing for resilience to unusual behaviour is similarly well-established (e.g., https://github.com/Netflix/chaosmonkey).  But are there cases of this in network protocols prior to its use in TLS?

Regards,
Martin