Re: [DNSOP] comments on draft-muks-dnsop-dns-message-checksums

Mukund Sivaraman <muks@isc.org> Mon, 02 November 2015 06:48 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 577C21A00D0 for <dnsop@ietfa.amsl.com>; Sun, 1 Nov 2015 22:48:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.611
X-Spam-Level:
X-Spam-Status: No, score=-1.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 p1FSQ0qJ7-qE for <dnsop@ietfa.amsl.com>; Sun, 1 Nov 2015 22:48:36 -0800 (PST)
Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 133131A00DF for <dnsop@ietf.org>; Sun, 1 Nov 2015 22:48:36 -0800 (PST)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx.ams1.isc.org (Postfix) with ESMTPS id E0C681FCABE; Mon, 2 Nov 2015 06:48:32 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 8D6A3160046; Mon, 2 Nov 2015 06:49:08 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 7A6181600AA; Mon, 2 Nov 2015 06:49:08 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id gB2hk-SxyGAw; Mon, 2 Nov 2015 06:49:08 +0000 (UTC)
Received: from zmail1.isc.org (zmail1.isc.org [149.20.0.12]) by zmx1.isc.org (Postfix) with ESMTP id 61378160046; Mon, 2 Nov 2015 06:49:08 +0000 (UTC)
Date: Mon, 02 Nov 2015 06:48:31 +0000
From: Mukund Sivaraman <muks@isc.org>
To: 神明達哉 <jinmei@wide.ad.jp>
Message-ID: <381755481.1183728.1446446911406.JavaMail.zimbra@isc.org>
In-Reply-To: <CAJE_bqeuBrpp4X=N-Sm+zLs2sOSkgD1Fu0rPkY+L2RNNA1kbzw@mail.gmail.com>
References: <CAJE_bqeuBrpp4X=N-Sm+zLs2sOSkgD1Fu0rPkY+L2RNNA1kbzw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Originating-IP: [149.20.0.17]
X-Mailer: Zimbra 8.6.0_GA_1162 (ZimbraWebClient - FF41 (Linux)/8.6.0_GA_1162)
Thread-Topic: comments on draft-muks-dnsop-dns-message-checksums
Thread-Index: QOd8f8AUrdQxuEaPWuqNrM/rjeIL5A==
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/qOQYK73VsKOLyzzT3ANYOKiQqd4>
Cc: dnsop <dnsop@ietf.org>
Subject: Re: [DNSOP] comments on draft-muks-dnsop-dns-message-checksums
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: Mon, 02 Nov 2015 06:48:37 -0000

Hi Jinmei

Thank you for the review.

----- Original Message -----
> From: "神明達哉" <jinmei@wide.ad.jp>
> To: "dnsop" <dnsop@ietf.org>
> Sent: Monday, November 2, 2015 1:31:56 PM
> Subject: [DNSOP] comments on draft-muks-dnsop-dns-message-checksums

> I've read draft-muks-dnsop-dns-message-checksums-01.  I think it's
> quite well written.
> 
> I have a couple of comments about the draft:
> 
> 1. I wonder whether this should be merged to draft-ietf-dnsop-cookies,
>   as both try to solve the same/similar problems with quite similar
>   approaches (note: I believe I understand the difference, and I'm
>   not saying dnsop-cookies will make dns-message-checksums
>   unnecessary).

I'm open to merging this with DNS cookies. OTOH, there have been suggestions of adding a dependency on DNS cookies (instead of using the NONCE field) that I'm now not in favour of (which I'll address separately).

> 2. Regarding the possibility of downgrade attack, you might want to a
>   perhaps obvious (and weak) counter measure: cache the availability
>   of the feature per peer and use it as a hint for further queries.

This was also proposed by Shane Kerr. He is planning on contributing a section to the draft towards this.

I'll be uploading another revision soon that uses SHA-256, and clarifies some more things that were learned during BIND implementation (e.g., TSIG).

Mukund