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

Wes Hardaker <wjhns1@hardakers.net> Fri, 05 August 2016 21:05 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 3B95312D09A; Fri, 5 Aug 2016 14:05:13 -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 OZq3Z6OE4G36; Fri, 5 Aug 2016 14:05:12 -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 EFF4312D099; Fri, 5 Aug 2016 14:05:11 -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 04E0C23A0A; Fri, 5 Aug 2016 14:05:10 -0700 (PDT)
From: Wes Hardaker <wjhns1@hardakers.net>
To: Ben Campbell <ben@nostrum.com>
References: <20160706222617.26800.68512.idtracker@ietfa.amsl.com> <0lfurjyg6o.fsf@wjh.hardakers.net> <7A3FCC93-B4C1-4695-B8C6-22C8972A7844@nostrum.com>
Date: Fri, 05 Aug 2016 14:05:09 -0700
In-Reply-To: <7A3FCC93-B4C1-4695-B8C6-22C8972A7844@nostrum.com> (Ben Campbell's message of "Fri, 08 Jul 2016 16:56:37 -0500")
Message-ID: <0loa570vwa.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; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/NlVON23OnUYuKgl7Mui9rbJe-No>
Cc: tjw.ietf@gmail.com, dnsop-chairs@ietf.org, Wes Hardaker <wjhns1@hardakers.net>, dnsop@ietf.org, draft-ietf-dnsop-dnssec-roadblock-avoidance@ietf.org, The IESG <iesg@ietf.org>
Subject: Re: [DNSOP] Ben Campbell'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:05:13 -0000

"Ben Campbell" <ben@nostrum.com> writes:

[everything else addressed but I had a question about this last one:]

>>> -8: Seems like there could be  more to say about the potential
>>> consequences about the “fail or proceed without security” decision
>>> in 6
>>> and 6.1.
>>
>> I think the world is very much at a loss as to the best thing to do in
>> that case.  And is likely very case specific.  Military installations
>> tend to be a bit more strict about continuing through to a
>> unacceptable
>> security certificate, eg.  I'm not sure we can enumerate every
>> context,
>> but rather say each local policy will need to do what is appropriate
>> for them.
>>
>
> I think it would be useful to say _that_. (as in "here's a security
> consideration people need to, well, consider")

How's this sound as a concluding sentence:

      <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.
  new:  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>

It's not an easy thing without introducing more "temporal" text into the document
-- 
Wes Hardaker
Parsons