Re: [DNSOP] New Version Notification for draft-muks-dnsop-dns-message-checksums-00.txt

Mukund Sivaraman <muks@isc.org> Wed, 30 September 2015 15:40 UTC

Return-Path: <muks@isc.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F9DA1B5EBD for <dnsop@ietfa.amsl.com>; Wed, 30 Sep 2015 08:40:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level:
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no
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 3X7H6fcxX4Lq for <dnsop@ietfa.amsl.com>; Wed, 30 Sep 2015 08:40:42 -0700 (PDT)
Received: from mail.banu.com (mail.banu.com [IPv6:2a01:4f8:140:644b::225]) by ietfa.amsl.com (Postfix) with ESMTP id BEF3B1B5EA7 for <dnsop@ietf.org>; Wed, 30 Sep 2015 08:40:42 -0700 (PDT)
Received: from jurassic.l0.malgudi.org (unknown [115.118.157.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.banu.com (Postfix) with ESMTPSA id 198152BA0A7E; Wed, 30 Sep 2015 15:40:38 +0000 (GMT)
Date: Wed, 30 Sep 2015 21:10:33 +0530
From: Mukund Sivaraman <muks@isc.org>
To: Paul Hoffman <paul.hoffman@vpnc.org>
Message-ID: <20150930154033.GA6114@jurassic.l0.malgudi.org>
References: <20150928155157.GB19077@jurassic.l0.malgudi.org> <BB4FDC1E-4FC7-4583-8314-5D3BBCB3531A@hopcount.ca> <20150930023229.GA11615@jurassic.l0.malgudi.org> <9A059CF2-96EE-4B68-8EF2-370CD8ABFDD8@hopcount.ca> <8D53DD17-95BF-43D2-BFE7-C77D1FF3C301@vpnc.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="wac7ysb48OaltWcw"
Content-Disposition: inline
In-Reply-To: <8D53DD17-95BF-43D2-BFE7-C77D1FF3C301@vpnc.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/5mBpqovo2cIOvjUchrVvhEq3TzM>
Cc: dnsop@ietf.org, Joe Abley <jabley@hopcount.ca>
Subject: Re: [DNSOP] New Version Notification for draft-muks-dnsop-dns-message-checksums-00.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Sep 2015 15:40:48 -0000

Hi Paul

On Wed, Sep 30, 2015 at 08:08:16AM -0700, Paul Hoffman wrote:
> >To choose an extreme example, it seems likely that choosing to calculate a
> >parity bit would be much computationally cheaper than calculating a
> >SHA-256 digest. However, a parity bit would not offer much protection
> >against off-path attacks.
> 
> Indeed. And this still calls into question whether trying to engineer a
> solution like this is a better idea than just using TCP.

Joe is talking about the case when a simple parity bit algorithm is in
use where it is trivial to attack the scheme. I may not have followed
what you are referring to in your reply. Are you saying that when using
a cryptographic hash (such as even SHA-1), the CHECKSUM method is
vulnerable?

The topic of why TCP is not ready yet to be used exclusively has been
addressed in this thread, or another adjacent thread about CHECKSUM. We
aren't exclusively using it and until that switch is flipped which is
still far away, we need to protect UDP.

		Mukund