Re: [DNSOP] EDNS reply option to list unsupported options from query

Mukund Sivaraman <muks@isc.org> Mon, 28 September 2015 17:31 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 E0B0C1AD0D2 for <dnsop@ietfa.amsl.com>; Mon, 28 Sep 2015 10:31:21 -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 I5WBXAYD8fTg for <dnsop@ietfa.amsl.com>; Mon, 28 Sep 2015 10:31:20 -0700 (PDT)
Received: from mail.banu.com (mail.banu.com [IPv6:2a01:4f8:140:644b::225]) by ietfa.amsl.com (Postfix) with ESMTP id 90DF71AD0D1 for <dnsop@ietf.org>; Mon, 28 Sep 2015 10:31:20 -0700 (PDT)
Received: from jurassic.l0.malgudi.org (unknown [117.215.83.26]) (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 5946A2BA0B6F; Mon, 28 Sep 2015 17:31:17 +0000 (GMT)
Date: Mon, 28 Sep 2015 23:01:13 +0530
From: Mukund Sivaraman <muks@isc.org>
To: Paul Hoffman <paul.hoffman@vpnc.org>
Message-ID: <20150928173113.GA23351@jurassic.l0.malgudi.org>
References: <20150928170341.GA23119@jurassic.l0.malgudi.org> <560974DC.8050605@redbarn.org> <20150928171452.GB23119@jurassic.l0.malgudi.org> <439F89B9-1CF0-4F12-A47C-6D11EB252766@vpnc.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="bp/iNruPH9dso1Pn"
Content-Disposition: inline
In-Reply-To: <439F89B9-1CF0-4F12-A47C-6D11EB252766@vpnc.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/Z--unzIzW-5FYbXckZrMsU6P72o>
Cc: dnsop@ietf.org
Subject: Re: [DNSOP] EDNS reply option to list unsupported options from query
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, 28 Sep 2015 17:31:22 -0000

Hi Paul

On Mon, Sep 28, 2015 at 10:19:20AM -0700, Paul Hoffman wrote:
> Paul's "no" (which I agree with) shows what might be a fatal flaw in

Even if Paul had said "yes", this security consideration still exists
(see below). The reason why I sent the EDNS option handling email was
because it sometimes is not apparent with newer options if it was left
out because there was no support, or because of some other condition.

> draft-muks-dnsop-dns-message-checksums: an attacker just needs to send
> fragments that look like they say "I don't understand the new EDNS0 option".
> Does that make sense?

I really appreciate the sharp review. This was also pointed out by Ray
Bellis during internal review. It is listed in the github repo under
security considerations. The latest version of this draft in text form
is here:

http://users.isc.org/~muks/draft-muks-dnsop-dns-message-checksums.txt

As with any new protocol, if the protocol is not supported on both ends,
nothing can be done for it. The SHOULDs turn to MUSTs at some point when
support is widespread. Currently it's the client's choice on what action
to take if the option is missing from a reply.

		Mukund