Re: [DNSOP] WG review of draft-ietf-homenet-dot-03

Paul Vixie <paul@redbarn.org> Tue, 21 March 2017 05:23 UTC

Return-Path: <paul@redbarn.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A7B8129462 for <dnsop@ietfa.amsl.com>; Mon, 20 Mar 2017 22:23:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 mvX0MdKvvik1 for <dnsop@ietfa.amsl.com>; Mon, 20 Mar 2017 22:23:45 -0700 (PDT)
Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF2D2128C82 for <dnsop@ietf.org>; Mon, 20 Mar 2017 22:23:45 -0700 (PDT)
Received: from [IPv6:2001:559:8000:c9:dc3:59e3:1fa5:69dc] (unknown [IPv6:2001:559:8000:c9:dc3:59e3:1fa5:69dc]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 4FF1261F96 for <dnsop@ietf.org>; Tue, 21 Mar 2017 05:23:45 +0000 (UTC)
Message-ID: <58D0B8E0.3050505@redbarn.org>
Date: Mon, 20 Mar 2017 22:23:44 -0700
From: Paul Vixie <paul@redbarn.org>
User-Agent: Postbox 5.0.11 (Windows/20170302)
MIME-Version: 1.0
To: dnsop@ietf.org
References: <60C85486-E351-4C42-ADEB-FCBB56F4EA27@fugue.com> <AB11455F-7E43-4CB3-9F13-DB6A09F739EB@vigilsec.com> <CEC8CC6A-861A-471C-B7FA-4BB05C81CCF0@gmail.com> <F7AA49EF-2708-4948-9B60-6660DA6BC841@vigilsec.com> <734EC35A-4B1F-43EB-BE37-C34CA46BDA26@fugue.com> <203D2BEA-1008-48A0-9CE2-1FD621C6117F@shinkuro.com> <3134EDC2-FB00-41EA-8338-6E6B196137F1@fugue.com> <572B4EBA-F37F-4E92-A252-44BAF5DE7FF5@shinkuro.com> <20170321004827.GA25754@mournblade.imrryr.org> <72896FC4-5F63-4880-8C4B-A941A63B91B6@fugue.com> <20170321021538.GB25754@mournblade.imrryr.org> <58D0B64F.7000503@redbarn.org>
In-Reply-To: <58D0B64F.7000503@redbarn.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/yQOQTQmNzqMgoaNHl2gbGq27jAQ>
Subject: Re: [DNSOP] WG review of draft-ietf-homenet-dot-03
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
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: Tue, 21 Mar 2017 05:23:48 -0000


Paul Vixie wrote:
> 
> Viktor Dukhovni wrote:
>> ...
>>
>> What's attractive here, is that real resolvers (local to the same
>> device) already have the requisite feature-set, and there's no need
>> to augment stub resolvers with features already handled by local
>> recursive resolvers.  If a device is too dumb to run a separate
>> resolver process, I don't expect it'll have a trustworthy DNSSEC
>> implementation in its stub resolver.
> 
> trusting a dns response's AD bit to tell you that the responder has done
> careful signature checking all the way back to a trust anchor you have
> confidence in, doesn't fit the hotel or coffee shop scenario -- you do
> not want your hotel or coffee shop in the role of making a secure
> introduction between you and your bank, for example.

since the hotel is unlikely to transmit on an interface that's local to
the same device, let me amend this as follows:

trusting the AD bit just because the packet appears to have been
generated locally is a dangerous model. if the specification requires
that the stub have explicit and non-default cause for confidence in the
sender's identity and fidelity, then there's no way to test for this,
and since there's no way to test for it, it won't be widely implemented.
time to market is the primary driver for a product or service's lifetime
revenue envelope, and any requirement that won't face acceptance and/or
interoperability testing, WILL be left out.

the thing you CAN test for is whether the signatures are valid. which is
why first dan kaminsky and later paul wouters wanted to send the full
signature chain. perhaps that can be merged in here: if the stub
resolver can see the full signature chain and do its own validation,
then it ought to believe that the data is authentic. this would put the
burden on system vendors to put signature chain gathering/expansion into
their on-device RDNS or DNS Proxy, so that local stubs saw same.

-- 
P Vixie