Re: [DNSOP] I-D Action: draft-ietf-dnsop-kskroll-sentinel-03.txt

"Wessels, Duane" <dwessels@verisign.com> Wed, 28 February 2018 22:45 UTC

Return-Path: <dwessels@verisign.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 7CDEB126FDC for <dnsop@ietfa.amsl.com>; Wed, 28 Feb 2018 14:45:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.311
X-Spam-Level:
X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verisign.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 IZAazegZSuC8 for <dnsop@ietfa.amsl.com>; Wed, 28 Feb 2018 14:45:47 -0800 (PST)
Received: from mail2.verisign.com (mail2.verisign.com [72.13.63.31]) (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 6DF72126FB3 for <dnsop@ietf.org>; Wed, 28 Feb 2018 14:45:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=4623; q=dns/txt; s=VRSN; t=1519857947; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=MuFz60jZ+X/i/SJHf2u0qYitiIfTaN5/a5u1KBJcjCI=; b=QcMhtXBJGrQdHpNBNI83LPueDZDI/GNN9atHXIBtYZ7NJEUr/uNChp3k CMOa3yzXVdBVqDxkWVFFzE3O3FT5WkCAVXbwp1xSrZlhFQlNLPw0lPpO8 JPlLJBPF2OOX5UmijmtUYttsoBlqXdIUu7BH4BUomJxZKCTyqQ12+Ml/0 2LLfgfroe5PfmXwh7WqQbdXTzNfsWcGVIMU7p25+zzDeBLQ/KbyjVSGhU AapnZxIC2nJivzFzy6d7zwXCzN8yZTriqzC1s6YN2U5m7ofE10skSBxsi jdmhHn0bdPKYSPycj4NzK0wRHa3wV/5UulTBBEg2kFcjhhHwSsKElaDzh Q==;
X-IronPort-AV: E=Sophos;i="5.47,406,1515456000"; d="scan'208";a="3778183"
IronPort-PHdr: 9a23:eBO0ph+welBDOP9uRHKM819IXTAuvvDOBiVQ1KB31O0cTK2v8tzYMVDF4r011RmVBd6ds6oMotGVmpioYXYH75eFvSJKW713fDhBt/8rmRc9CtWOE0zxIa2iRSU7GMNfSA0tpCnjYgBaF8nkelLdvGC54yIMFRXjLwp1Ifn+FpLPg8it2O2+55Pebx9UiDahfLh/MAi4oQLNu8cMnIBsMLwxyhzHontJf+RZ22ZlLk+Nkhj/+8m94odt/zxftPw9+cFAV776f7kjQrxDEDsmKWE169b1uhTFUACC+2ETUmQSkhpPHgjF8BT3VYr/vyfmquZw3jSRMMvrRr42RDui9b9mRh/2hikaKz43/mLZisJyg6JavB2vqBNwzpXIYIGMMfpyYr/Rcc8ESWdHQ81fVzZBAoS5b4YXAeYOPfhXr5Lmp1QQqRu+HhGgD/7hxD9VnHD227M13+o8GgzBwQMhEcwBsG/PrNrrMKcSSvu4zLfWwjXZbvNWwjb96IfOchw7vf6MWrdwfNPXxEIyGQ3FiVCQppbkPzOTzukNsHOb7+l5WeKzlWEnsB1xriKpxsgylonFno0VylHY9SV53YY6Pse0R1J8Yd6hCJdQtj+VN5d4Qs84RGFooik6xqUYtp+0ZicKzYwnxxrBZPCdb4eI5RfjWeCMKjl7nHJoYK+ziwqo/US9yODxWNO43EtKoydLiNXAqH8A2hPL5sSaVvdx5Fqt1DST2wzJ9+1JLkM5mbDGJ5MixLM7i4Advl7ZHiDsnUX7lKqWdkI59ee28+nnebDmpoOEN49zlwH+LrwimsyhDuQ8NQgDR3OU+f661LH++U34T7BKgec3kqndt5DaONgbqrKkDwNPzIYs9Qy/Dza90NQZknkHKkhJdw6Aj4jsI13OIfb4Aumjg1m0jTtn2+rKMqDjD5jDNHTPjbfscLhn50JCxwc+wshT55dOBbEAJPLzVFXxtNvdDhIhLgO1zfjoCM5m1owAXWKPGbSUML3Mvl+S5+IvOOiMZIATuDrnN/cl4PvugWcjmVABZampwYcXaHegE/t7JUWZen3sgs8aHGcLoAU+UOLqhEeFUT5JaHbhF547sz09E4W+RdPPQJuqmJSA0Tu1WJpMaTYVJEqLFCKiSIifQPoIc2baDtJolDFOHeytVII6zhyqryfkxqBmNevb/GsTspe1h4s93PHaiRxnrW88NM+ayWzYF2w=
X-IPAS-Result: A2H0AAA7MJda//SZrQpdGgEBAQEBAgEBAQEIAQEBAYQ2gRgKjW2PchGBBZFigWJnFIE/GyAHChgNgQmDfgICAoMqGAECAQEBAQEBAgECgRCCOCINBEsqAwEBAQEBASUBAQEBAQEBAQEBAQEBAQEBGgINIgsELAEBAQECAQEBODQQCwIBCA0LHhAnCyUCBBOCc4IhGK4chHKDcoIWAQEBBwEBAQEBAQEBAR+FI4N/gWUpgwSDLgEBAQEBAReBPhiDPYIyBY1yhUeHGQMGAoZOjApOg2eIWod4ggKEPgGCbAIECwIZAYEuHoILcBUZISoBghgJhFF3AYlaLIEDgRcBAQE
Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01 [10.173.152.255]) by brn1lxmailout01.verisign.com (8.13.8/8.13.8) with ESMTP id w1SMjhMW006377 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <dnsop@ietf.org>; Wed, 28 Feb 2018 17:45:43 -0500
Received: from BRN1WNEXMBX02.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0301.000; Wed, 28 Feb 2018 17:45:42 -0500
From: "Wessels, Duane" <dwessels@verisign.com>
To: dnsop <dnsop@ietf.org>
Thread-Topic: [DNSOP] I-D Action: draft-ietf-dnsop-kskroll-sentinel-03.txt
Thread-Index: AQHTsOXcn2wfNY6diEyZnaMW68nK+Q==
Date: Wed, 28 Feb 2018 22:45:41 +0000
Message-ID: <39567D9A-312D-42A8-A108-C8F7EE249668@verisign.com>
References: <151984683961.5212.6854317117587193083@ietfa.amsl.com>
In-Reply-To: <151984683961.5212.6854317117587193083@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.170.148.18]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <A58E86BC47ED8642B0C3C6B7F57511CE@verisign.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/fdrG9jJBJTq1oTSAuFbXnTFaoGs>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-kskroll-sentinel-03.txt
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: Wed, 28 Feb 2018 22:45:49 -0000

Thanks for the update.

IMO this document really needs a Privacy Considerations section and maybe also some additions to the Security Considerations.  Whereas the signals in 8145 are between the validator and the zone owner, this technique enables third parties (with either good or bad intentions) to learn something about the security configuration of recursive name servers.  Possibly all of them.

Similarly, I think the document could be more transparent and consistent about who is able to make the determinations.  For example it currently says:

   "allow an end user to determine the trusted key state"

   "allow a user to determine the state of their DNS resolution system"

   "allow us to infer a trust key state"

   "allow the client to determine the category"

I'd like to see at least in the abstract "...allows end users and third parties to determine..."


All of the examples with "2222" should now be zero padded:

$ grep ta-2222 draft-ietf-dnsop-kskroll-sentinel-03.txt 
      kskroll-sentinel-is-ta-2222.example.com.  IN AAAA 2001:db8::1
      kskroll-sentinel-not-ta-2222.example.com.  IN AAAA 2001:db8::1
   http://kskroll-sentinel-is-ta-2222.example.com/1x1.gif,
   http://kskroll-sentinel-not-ta-2222.example.com/1x1.gif).
   ta-2222.example.com name normally (it contacts the example.com
   kskroll-sentinel-not-ta-2222.example.com name.  Once again, it
   sentinel-is-ta-2222", but he cannot fetch "kskroll-sentinel-not-ta-
   sentinel-is-ta-2222", it does *not* have the (new, 2222) KSK in it's
   fetch the "kskroll-sentinel-is-ta-2222" resource, but he can fetch
   the "kskroll-sentinel-not-ta-2222" resource.  This tells Ed that his

DW



> On Feb 28, 2018, at 11:40 AM, internet-drafts@ietf.org wrote:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Domain Name System Operations WG of the IETF.
> 
>        Title           : A Sentinel for Detecting Trusted Keys in DNSSEC
>        Authors         : Geoff Huston
>                          Joao Silva Damas
>                          Warren Kumari
> 	Filename        : draft-ietf-dnsop-kskroll-sentinel-03.txt
> 	Pages           : 13
> 	Date            : 2018-02-28
> 
> 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 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-<tag-
>   index>", "kskroll-sentinel-not-ta-<tag-index>"; older versions of
>   this document used "_is-ta-<tag-index>", "_not-ta-<tag-index>".  Also
>   note that the format of the tag-index is now decimal.  Apolgies to
>   those who have began implmenting.]
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-kskroll-sentinel/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-dnsop-kskroll-sentinel-03
> https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-kskroll-sentinel-03
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-kskroll-sentinel-03
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop