Re: [DNSOP] The DNSOP WG has placed draft-wessels-edns-key-tag in state "Candidate for WG Adoption"

Mark Andrews <marka@isc.org> Thu, 05 November 2015 23:11 UTC

Return-Path: <marka@isc.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF1351B3D34; Thu, 5 Nov 2015 15:11:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 Kbc5PxJiR_GH; Thu, 5 Nov 2015 15:11:39 -0800 (PST)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A11ED1B3D33; Thu, 5 Nov 2015 15:11:39 -0800 (PST)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx.pao1.isc.org (Postfix) with ESMTPS id B2B293493C2; Thu, 5 Nov 2015 23:11:37 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id D4DEC160031; Thu, 5 Nov 2015 23:11:40 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id C3D86160076; Thu, 5 Nov 2015 23:11:40 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 9G6nIg97VF6J; Thu, 5 Nov 2015 23:11:40 +0000 (UTC)
Received: from rock.dv.isc.org (c122-106-161-187.carlnfd1.nsw.optusnet.com.au [122.106.161.187]) by zmx1.isc.org (Postfix) with ESMTPSA id 7ABBF160031; Thu, 5 Nov 2015 23:11:40 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 6EB773BF219B; Fri, 6 Nov 2015 10:11:35 +1100 (EST)
To: Bob Harold <rharolde@umich.edu>
From: Mark Andrews <marka@isc.org>
References: <20151105021917.11963.34087.idtracker@ietfa.amsl.com> <CA+nkc8A7LrA8E1V3TsNoFjqDcU0UwuZH=FcG+t_HtAtPSrKK7Q@mail.gmail.com>
In-reply-to: Your message of "Thu, 05 Nov 2015 12:01:58 -0500." <CA+nkc8A7LrA8E1V3TsNoFjqDcU0UwuZH=FcG+t_HtAtPSrKK7Q@mail.gmail.com>
Date: Fri, 06 Nov 2015 10:11:35 +1100
Message-Id: <20151105231135.6EB773BF219B@rock.dv.isc.org>
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/DNkPuvjQc2PmmhGuL9liCc62pWs>
Cc: dnsop-chairs@ietf.org, IETF DNSOP WG <dnsop@ietf.org>, IETF Secretariat <ietf-secretariat-reply@ietf.org>, draft-wessels-edns-key-tag@ietf.org
Subject: Re: [DNSOP] The DNSOP WG has placed draft-wessels-edns-key-tag in state "Candidate for WG Adoption"
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
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: Thu, 05 Nov 2015 23:11:41 -0000

In message <CA+nkc8A7LrA8E1V3TsNoFjqDcU0UwuZH=FcG+t_HtAtPSrKK7Q@mail.gmail.com>
, Bob Harold writes:
> 
> On Wed, Nov 4, 2015 at 9:19 PM, IETF Secretariat <
> ietf-secretariat-reply@ietf.org> wrote:
> 
> >
> > The DNSOP WG has placed draft-wessels-edns-key-tag in state
> > Candidate for WG Adoption (entered by Tim Wicinski)
> >
> > The document is available at
> > https://datatracker.ietf.org/doc/draft-wessels-edns-key-tag/
> >
> >
> > I freely admit to not being an expert on DNSSEC.  Some questions, if they
> make sense:
> 
> 5.2.1 - If the Stub Resolver is validating, then perhaps the recursive
> resolver should just pass the stub resolver's list of keys, so the Auth
> server knows whether the stub can validate with the new keys?  The
> Recursive will likely send other queries with its own key set, so the Auth
> server can get both sets of information - but will it understand the
> difference, or should we send forwarded keys separately?
> 
> In general, this lets us know that some servers have the new key, but is
> there any way in the process where we can mark a key as 'old' but still
> usable and wait until resolvers quit sending it, before we remove it?  Or
> is that too complicated?

You don't need to wait for resolvers to stop using a key.  You only
need to wait until they are using the new key.

If we have multiple instances of the option in opt record.

e.g.
	TAG <old>  TAG <old> <new>  TAG <new>

then you wait for "TAG <old>" to disappear from the incoming queries
before removing the old key.

e.g.
	TAG <old> <new>  TAG <new>

Now to get counts you need resolvers to count the unique clients
including themselves seen over a period and include those numbers
as well.

	TAG <count> <keyid> ....

If you have the union you get this sort of pattern

	TAG <old>
	TAG <old> <new>
	TAG <new>

And you don't know when you can safely withdraw the old key.

If you have the intersection get this sort of pattern

	TAG <old>
	TAG 				The intesection set is empty
	TAG <old> <new> or TAG <new>
	TAG <new>

Mark

> -- 
> Bob Harold
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org