Re: [DNSOP] Alissa Cooper's No Objection on draft-ietf-dnsop-dnssec-roadblock-avoidance-04: (with COMMENT)

Wes Hardaker <wjhns1@hardakers.net> Fri, 05 August 2016 21:23 UTC

Return-Path: <wjhns1@hardakers.net>
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 802CD12D10F; Fri, 5 Aug 2016 14:23:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.488
X-Spam-Level:
X-Spam-Status: No, score=-5.488 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287, 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 zUywY-WUNIcA; Fri, 5 Aug 2016 14:23:49 -0700 (PDT)
Received: from mail.hardakers.net (mail.hardakers.net [168.150.236.43]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19A8012B041; Fri, 5 Aug 2016 14:23:49 -0700 (PDT)
Received: from localhost (50-1-20-198.dsl.static.fusionbroadband.com [50.1.20.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.hardakers.net (Postfix) with ESMTPSA id 5862F23A0C; Fri, 5 Aug 2016 14:23:47 -0700 (PDT)
From: Wes Hardaker <wjhns1@hardakers.net>
To: Alissa Cooper <alissa@cooperw.in>
References: <20160706182619.26808.76748.idtracker@ietfa.amsl.com>
Date: Fri, 05 Aug 2016 14:23:47 -0700
In-Reply-To: <20160706182619.26808.76748.idtracker@ietfa.amsl.com> (Alissa Cooper's message of "Wed, 06 Jul 2016 11:26:19 -0700")
Message-ID: <0l1t2229lo.fsf@wjh.hardakers.net>
User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.5 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/kjUrHXPBl3EO7vVB-fm3M_oVkJA>
Cc: tjw.ietf@gmail.com, dnsop@ietf.org, draft-ietf-dnsop-dnssec-roadblock-avoidance@ietf.org, dnsop-chairs@ietf.org, The IESG <iesg@ietf.org>
Subject: Re: [DNSOP] Alissa Cooper's No Objection on draft-ietf-dnsop-dnssec-roadblock-avoidance-04: (with COMMENT)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.17
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: Fri, 05 Aug 2016 21:23:50 -0000

"Alissa Cooper" <alissa@cooperw.in> writes:

> - Agree with Terry's DISCUSS.

Fixed, FYI (Terry agrees with the solution at least; see that thread).
>
> - Sec. 2: The last paragraph here isn't really about "goals" and seems
> like it belongs more appropriately in Sec 3.

Good point.  Moving it to a new "NOTE" in section 3.

> - Sec 6.1: I thought recently gathered data has been pointing to the
> futility of popping up security warnings (e.g.,
> http://neurosecurity.byu.edu/media/Anderson_et_al._CHI_2015.pdf). Does it
> really make sense to recommend warning users in a BCP? What are users
> expected to do as a result? Is there any evidence about the proportion of
> users who even know what DNSSEC is?

I'll have to read your paper, thanks for the pointer.

As to section 6.1, it seems like in a BCP we should say *something*
about what to do.  Thus, the current text says this:

      <section title="What To Do">
	<t>If Host Validator detects that DNSSEC resolution is not
	possible it SHOULD log the event and/or SHOULD warn user. In
	the case there is no user no reporting can be performed thus
	the device MAY have a policy of action, like continue or
	fail. Until middle boxes allow DNSSEC protected information to
	traverse them consistently, software implementations may need
	to offer this choice to let users pick the security level they
	require.</t>
      </section>

I supposed we could replace "warn" with something like "report an error
to the user"?  I think that's better so am making that change.

-- 
Wes Hardaker
Parsons