Re: [DNSOP] Reminder: WGLC for draft-ietf-dnsop-nsec-aggressiveuse ends Tonight

Tony Finch <dot@dotat.at> Mon, 10 October 2016 12:37 UTC

Return-Path: <dot@dotat.at>
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 692F4129631 for <dnsop@ietfa.amsl.com>; Mon, 10 Oct 2016 05:37:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_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 xka4ZbUtxt67 for <dnsop@ietfa.amsl.com>; Mon, 10 Oct 2016 05:37:32 -0700 (PDT)
Received: from ppsw-31.csi.cam.ac.uk (ppsw-31.csi.cam.ac.uk [131.111.8.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFB0012961E for <dnsop@ietf.org>; Mon, 10 Oct 2016 05:37:31 -0700 (PDT)
X-Cam-AntiVirus: no malware found
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
Received: from grey.csi.cam.ac.uk ([131.111.57.57]:34199) by ppsw-31.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.137]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1btZpf-000sOb-L4 (Exim 4.86_36-e07b163) (return-path <dot@dotat.at>); Mon, 10 Oct 2016 13:37:27 +0100
Date: Mon, 10 Oct 2016 13:37:27 +0100
From: Tony Finch <dot@dotat.at>
To: Warren Kumari <warren@kumari.net>
In-Reply-To: <CAHw9_i+vJjy-ARvkN1s33AUXdMaKbOsKRUhRLhxEFm1yiijN3A@mail.gmail.com>
Message-ID: <alpine.DEB.2.11.1610101317510.31786@grey.csi.cam.ac.uk>
References: <1fc274b9-2164-1933-54e3-ce47ff48c8a3@gmail.com> <alpine.DEB.2.11.1610061100020.31786@grey.csi.cam.ac.uk> <CAHw9_i+vJjy-ARvkN1s33AUXdMaKbOsKRUhRLhxEFm1yiijN3A@mail.gmail.com>
User-Agent: Alpine 2.11 (DEB 23 2013-08-11)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/BHmu79CuT0RRXLcHyCLPrhIBdu0>
Cc: Tim Wicinski <tjw.ietf@gmail.com>, Akira Kato <kato@wide.ad.jp>, dnsop <dnsop@ietf.org>
Subject: Re: [DNSOP] Reminder: WGLC for draft-ietf-dnsop-nsec-aggressiveuse ends Tonight
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, 10 Oct 2016 12:37:34 -0000

Warren Kumari <warren@kumari.net> wrote:
>
> >
> > Wildcards
> >
> > Should the box in section 7 say "positive responses" instead of "negative
> > responses"?
> >
> > If so, there should probably also be a cross-ref to RFC 4035 section 5.3.4
> > and RFC 5155 section 8.8 which both discuss validating positive wildcard
> > responses. Similar to my suggestions for 5.1 and 5.2 above. I can provide
> > text if you want.
>
> NOT DONE.
> Yes please. That would be awesome!

Thinking about wildcards makes me wonder if we need to approach this whole
idea from two directions - firstly, how the validator proves to itself
that it can synthesize a negative response or a wildcard response; and
secondly, how it can prove that it did the right thing to a downstream
validator. At the moment the draft talks about the first aspect, but not
very much the second.

Specifically,

Should we treat synthesis as if the cache is pretending to be an
authoritative server?

e.g. for wildcards and NSEC3, something like,

	When synthesizing a wildcard response from its cache, the
	validating resolver MUST include all the records specified in
	RFC 5155 section 7.2.5 (for negative responses) or section 7.2.6
	(for positive responses). That is, it MUST generate a response
	that matches what an authoritative server would send. If the
	required records are not present in the cache, the resolver SHALL
	query upstream instead of synthesizing the response.

If this makes sense then the other cases should be adjusted to describe
things in a similar way, e.g. referring to section 7 of RFC 5155 instead
of (or as well as?) section 8, and section 3.1 instead of / as well as
section 5 of RFC 4035.

Tony.
-- 
f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/  -  I xn--zr8h punycode
Plymouth, Biscay: Northeast 4 or 5, backing southeast 5 or 6. Slight or
moderate. Showers. Good.