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
- Re: [DNSOP] Ben Campbell's No Objection on draft-… Ben Campbell
- Re: [DNSOP] Ben Campbell's No Objection on draft-… Wes Hardaker
- [DNSOP] Ben Campbell's No Objection on draft-ietf… Ben Campbell
- Re: [DNSOP] Ben Campbell's No Objection on draft-… Wes Hardaker
- Re: [DNSOP] Ben Campbell's No Objection on draft-… Ben Campbell
- Re: [DNSOP] Ben Campbell's No Objection on draft-… Wes Hardaker