IETF Logo Mail Archive

Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-07

Warren Kumari <warren@kumari.net> Sat, 24 March 2018 10:45 UTC

Return-Path: <warren@kumari.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 B526412D77D for <dnsop@ietfa.amsl.com>; Sat, 24 Mar 2018 03:45:00 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com
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 G1-j124xosjx for <dnsop@ietfa.amsl.com>; Sat, 24 Mar 2018 03:44:58 -0700 (PDT)
Received: from mail-wr0-x22d.google.com (mail-wr0-x22d.google.com [IPv6:2a00:1450:400c:c0c::22d]) (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 EBBB91241F8 for <dnsop@ietf.org>; Sat, 24 Mar 2018 03:44:57 -0700 (PDT)
Received: by mail-wr0-x22d.google.com with SMTP id z8so14404023wrh.7 for <dnsop@ietf.org>; Sat, 24 Mar 2018 03:44:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=XM7/vAWYvd5/xwSfkLpMqS1DfLbfi+vmCJs7LSfHjE8=; b=uUyAfhpqLWJMA4l33fQBD9wruGrEWykSi0qQNtxfxLSqzBKQFLLIfnX0DqeL/UFtRk fH69Z2rcAml9H/lD0QQt7CY2G99ThPNpWCfK0AWInyROkObzf/soCyiyxG8jb3ct7Ha7 aT6cpJ6qSvpKSci19mKp3IVziiUP0N3uvgsLb8OvaJNXEFcHrenFrSRnTRZ8f2L0Id3v j9rcv2fOwQvWdl/5s5HHLnzKzoQsoVzAEUIn2avMqzp1f3Nw98LMLQ/Z0F36abyvdGGg Tcvv0WdOBOUdSqcUMtYwSS9mRlP+eetGPim0Ri+KcCn0s6Mk/VMWIDH3jgNHmWhsmBhj XSAA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=XM7/vAWYvd5/xwSfkLpMqS1DfLbfi+vmCJs7LSfHjE8=; b=ElKTnKECDoWaNFdLlPUrF9HXf10ZnW4Ehb8t2sLQE1B7QTFIKqFz8Hr9TVUqZL3+Tk Ft0X/ns3mTtrnpNW880baltqSMbptDM4rcra5IWtLDd6jU8R/gs3KBqG+KgL7ouFOofY 0czYLbvzcGWWzgj14X8NTU5TlOqaVhbaDddpJ6UaqmUModr5Llyjec64q6vRpl3FzCa7 Pv6mL7Ih0atfFV83d1uJnd88PVlokZgyWW8d3IugqCXlU90q9n6UVHGnR++u5OHGlUx8 O04YKCacytO4O+OUO6kCy6JNubiYAb5ddL139b0mr1PHliCjH6BWPRrfJc6A30Wql/5k Derw==
X-Gm-Message-State: AElRT7GVuRhyAEASRLgl2ZIRNBgk4wlGtbAdBdoaspSTlsp5kXqf6THY gyBTWRQUgN5fEV3hLYNIxlDF0B3Z0bBufqVqPJlwwA==
X-Google-Smtp-Source: AG47ELsMzb5QNuR6eHAeLsVcPtLhqZhSpFHHjvZNFBxmF/zSLFS2LES287F8F+t73y4qfi/ZbYxLxv77zAX92JgWnAc=
X-Received: by 10.223.131.229 with SMTP id 92mr22587817wre.249.1521888295670; Sat, 24 Mar 2018 03:44:55 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.226.76 with HTTP; Sat, 24 Mar 2018 03:44:15 -0700 (PDT)
In-Reply-To: <20180323175345.GU94914@registro.br>
References: <83786E94-ABCA-43F9-A038-F8F61C93E797@isc.org> <2B6DE54A-3814-4DC4-B9BA-864D5DEA75C5@verisign.com> <39F8C4FF-411D-4499-99BD-C382156293EC@vpnc.org> <CA+nkc8D89V=Mfp72fXvuOX-XYZGhFGWUed9jKQ2BooG774Xf_g@mail.gmail.com> <20180323175345.GU94914@registro.br>
From: Warren Kumari <warren@kumari.net>
Date: Sat, 24 Mar 2018 10:44:15 +0000
Message-ID: <CAHw9_iKaS1K0dOp_y_suUA2agHKNwJT63kQwfJLHCNqqTchpGw@mail.gmail.com>
To: Frederico A C Neves <fneves@registro.br>
Cc: Bob Harold <rharolde@umich.edu>, dnsop <dnsop@ietf.org>, Paul Hoffman <paul.hoffman@vpnc.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/xN_T966kKQInmdEVGpzNrIKzH5U>
Subject: Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-07
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
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: Sat, 24 Mar 2018 10:45:03 -0000

On Fri, Mar 23, 2018 at 5:53 PM, Frederico A C Neves <fneves@registro.br> wrote:
> On Fri, Mar 23, 2018 at 01:22:42PM -0400, Bob Harold wrote:
>> On Fri, Mar 23, 2018 at 1:19 PM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
>>
>> > +1 to the title “A Root Key Trust Anchor Sentinel for DNSSEC”.
>> >
>> > +1 to option #2 with the spelling correction.
>> >
>> > --Paul Hoffman
>> >
>> >
>> +1
>
> Agree with both.

Awesome, thanks - this seems to be the consensus.


A new version of I-D, draft-ietf-dnsop-kskroll-sentinel-08.txt
has been successfully submitted by Warren Kumari and posted to the
IETF repository.

Name:           draft-ietf-dnsop-kskroll-sentinel
Revision:       08
Title:          A Root Key Trust Anchor Sentinel for DNSSEC
Document date:  2018-03-24
Group:          dnsop
Pages:          15
URL:
https://www.ietf.org/internet-drafts/draft-ietf-dnsop-kskroll-sentinel-08.txt
Status:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-kskroll-sentinel/
Htmlized:       https://tools.ietf.org/html/draft-ietf-dnsop-kskroll-sentinel-08
Htmlized:
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-kskroll-sentinel
Diff:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-kskroll-sentinel-08

Abstract:
   The DNS Security Extensions (DNSSEC) were developed to provide origin
   authentication and integrity protection for DNS data by using digital
   signatures.  These digital signatures can be verified by building a
   chain of trust starting from a trust anchor and proceeding down to a
   particular node in the DNS.  This document specifies a mechanism that
   will allow an end user and third parties to determine the trusted key
   state for the root key of the resolvers that handle that user's DNS
   queries.  Note that this method is only applicable for determing
   which keys are in the trust store for the root key.

   There is an example / toy implementation of this at http://www.ksk-
   test.net .

   [ This document is being collaborated on in Github at:
   https://github.com/APNIC-Labs/draft-kskroll-sentinel.  The most
   recent version of the document, open issues, etc should all be
   available here.  The authors (gratefully) accept pull requests.  Text
   in square brackets will be removed before publication. ]

   [ NOTE: This version uses the labels "kskroll-sentinel-is-ta-<key-
   tag>", "kskroll-sentinel-not-ta-<key-tag>"; older versions of this
   document used "_is-ta-<key-tag>", "_not-ta-<key-tag>".  Also note
   that the format of the tag-index is now zero-filled decimal.
   Apolgies to those who have began implmenting.]

W



>
> But let me emphasize Joao's point, we need to pick those now and move
> forward.
>
> Fred
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

v2.23.0 | Report a Bug | By Email