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

"Ben Campbell" <ben@nostrum.com> Mon, 08 August 2016 16:17 UTC

Return-Path: <ben@nostrum.com>
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 01F7712D0AC; Mon, 8 Aug 2016 09:17:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.147
X-Spam-Level:
X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] 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 tvOII91MooPw; Mon, 8 Aug 2016 09:17:25 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7024112B01B; Mon, 8 Aug 2016 09:17:25 -0700 (PDT)
Received: from [192.168.11.1] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u78GH9XY061036 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 8 Aug 2016 11:17:10 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [192.168.11.1]
From: Ben Campbell <ben@nostrum.com>
To: Wes Hardaker <wjhns1@hardakers.net>
Date: Mon, 08 Aug 2016 11:17:09 -0500
Message-ID: <9895D200-2615-4C43-B0D9-4A3B51B81865@nostrum.com>
In-Reply-To: <0loa570vwa.fsf@wjh.hardakers.net>
References: <20160706222617.26800.68512.idtracker@ietfa.amsl.com> <0lfurjyg6o.fsf@wjh.hardakers.net> <7A3FCC93-B4C1-4695-B8C6-22C8972A7844@nostrum.com> <0loa570vwa.fsf@wjh.hardakers.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Mailer: MailMate (1.9.4r5234)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Fh4J7UPOK-n0QZu3tOPQEoR9TAY>
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] 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: Mon, 08 Aug 2016 16:17:27 -0000

On 5 Aug 2016, at 16:05, Wes Hardaker wrote:

> "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

I have no objection to adding that that, but I was thinking along the 
lines of "Note that continuing without DNSSEC protection in the absence 
of a notification or report could lead to situations where users assume 
a level of security does not exist."

Thanks!

Ben.