[DNSOP] comments on draft-mglt-dnsop-dnssec-validator-requirements-05

"Rose, Scott (Fed)" <scott.rose@nist.gov> Wed, 19 July 2017 12:49 UTC

Return-Path: <scott.rose@nist.gov>
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 210BE131CEE for <dnsop@ietfa.amsl.com>; Wed, 19 Jul 2017 05:49:11 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.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 nVDe0uoeH0UT for <dnsop@ietfa.amsl.com>; Wed, 19 Jul 2017 05:49:08 -0700 (PDT)
Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0129.outbound.protection.outlook.com [23.103.201.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD4C41288B8 for <dnsop@ietf.org>; Wed, 19 Jul 2017 05:49:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=OGaDMOcmzvFJMVpjSJsaJzXn/UQ3I/KmYK7B5JBZjUg=; b=axr8mHNN3tbRztVuLx1erDHZ9g36RNBy6q48U6dSYlU7xKTJg2+IKRjwgYfuPKWFyY622Iv27oTx7VNsTpItnf2g49TE1tny647/2ZOwzFu2gKyErRH8aZXSdvmbi7g7WRHf7LZqYwhlxeX3GelUt4QUaQG57FVp/50l4aC69wM=
Received: from SN1PR09MB0797.namprd09.prod.outlook.com (10.162.101.143) by SN1PR09MB0798.namprd09.prod.outlook.com (10.162.101.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.13; Wed, 19 Jul 2017 12:49:07 +0000
Received: from SN1PR09MB0797.namprd09.prod.outlook.com ([10.162.101.143]) by SN1PR09MB0797.namprd09.prod.outlook.com ([10.162.101.143]) with mapi id 15.01.1261.024; Wed, 19 Jul 2017 12:49:07 +0000
From: "Rose, Scott (Fed)" <scott.rose@nist.gov>
To: "dnsop@ietf.org" <dnsop@ietf.org>
Thread-Topic: comments on draft-mglt-dnsop-dnssec-validator-requirements-05
Thread-Index: AQHTAIk9FpNu0UgNwkSwkWyYAuxdTA==
Date: Wed, 19 Jul 2017 12:49:07 +0000
Message-ID: <SN1PR09MB07972DFA5FDC8C2582057850F0A60@SN1PR09MB0797.namprd09.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nist.gov;
x-originating-ip: [129.6.218.243]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; SN1PR09MB0798; 7:Rlvz/sLCljHFVg5K5eNZtmMJZMbOtBHw8kV47lVBpEFGZ0fQXAHa4Q7nUbWKXRDwjBRSyE7OSqSp8i7Rhfzgm+1o13ZkjsAbyp3qRN7I5DWJDzVyfmpzslWFwNcGbl3Q4vrPL1CMlPIohaD2cmB5jLfxOHdy/t9zQ29dTrk2NkV9MMdPzgz+mWRisKGC9wKjkuQbqWB0iUzVmlvCOIpLSMUR96HRAqh1uJRdq3D7AB+HvN9qITRRRmmztzJzKj9ErPg2IHbYsFOx2pF1EtzxuL01Wk1tx9bLXfgDA/cl1rZVRk5+f8cgMON/guUb7aY9CYE+x/PKVTifYtUtgAbsE45Va/Vg1lvw7OvDWlkOt80/7MIcEh0eqScpa996XtG4TfXeNZeUW8VOTEMiyjyGiCxD1CNhfdAU7kbNA6fXaJ8iLd4nf3K4OVKM9e7EYzXqKJenNR0UdNarTBiEGsxCS4ZPiWOOZJ++MWTCYWUyQ/sZCP++UvUoodrXW70gFqmzsG06qK+uWTK1sZXhTa+T9VeSojr5/VeTpMLlWpi67Om0PPrJdwKN+Mxz0piF/lWXBGc0Ky+4Lh2zY7luKK/iMCT8OScEikQBu9Jkyijx/q4V6Dg34BMRweu+Mwyr3Jy+8hyh/UodLLqg0Gre5zWpp6e/3GxvXZvoYvS+qTCYfW9lZyIWjxmDPe90zByqgGeHXDX+FpLzrsW7RQeIoMgXplLf9jFkuXTxjvsMsxOH1jZlDaCu4Eb3Hq2xaIKuqYB58OEsFcfpRLO8OT5xjUMcgqkSD9unLAiF3be+hbmXG0c=
x-ms-office365-filtering-correlation-id: 3f96be63-1c47-4580-ff44-08d4cea48b48
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(48565401081)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:SN1PR09MB0798;
x-ms-traffictypediagnostic: SN1PR09MB0798:
x-exchange-antispam-report-test: UriScan:(133145235818549)(209352067349851)(236129657087228)(247924648384137);
x-microsoft-antispam-prvs: <SN1PR09MB0798DF5C1CBDF1BE14076ADFF0A60@SN1PR09MB0798.namprd09.prod.outlook.com>
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(2017060910075)(5005006)(8121501046)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(3002001)(6055026)(6041248)(20161123558100)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:SN1PR09MB0798; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:SN1PR09MB0798;
x-forefront-prvs: 0373D94D15
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39850400002)(39450400003)(39860400002)(39840400002)(39400400002)(39410400002)(38730400002)(6506006)(8676002)(110136004)(54356999)(14454004)(77096006)(2906002)(189998001)(33656002)(53936002)(6606003)(5640700003)(6916009)(86362001)(54896002)(99286003)(50986999)(9686003)(55016002)(3280700002)(478600001)(6436002)(2351001)(19627405001)(3660700001)(230783001)(74316002)(2501003)(6116002)(2900100001)(66066001)(102836003)(8936002)(7736002)(3846002)(1730700003)(81166006)(5660300001)(25786009)(7696004); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR09MB0798; H:SN1PR09MB0797.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_SN1PR09MB07972DFA5FDC8C2582057850F0A60SN1PR09MB0797namp_"
MIME-Version: 1.0
X-OriginatorOrg: nist.gov
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jul 2017 12:49:07.2232 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR09MB0798
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/-vy8jg24RqkPGs-yGC7aRzkCO_4>
Subject: [DNSOP] comments on draft-mglt-dnsop-dnssec-validator-requirements-05
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, 19 Jul 2017 12:49:11 -0000

I think this draft is a good idea and should be adopted, but needs some improvements first.


1. In Section 4: "unsecure" should be "insecure".


2. REQ2: What should happen when there are multiple trust anchors, but only one failed to validate? E.g. a validator has both the root and .exampleTLD in its trust store, but missed the root rollover. The .exampleTLD key still validates, but the root doesn't. Should all validation stop? Or set a warning, but continue to validating (succeeding only for .exampleTLD)?


3. REQ18: I don't think I understand this. Wouldn't the best way to see which algorithm(s) are in use for a given zone would be just to send a query? Authoritative zones really may not "know" any algorithm besides SHA-1, as it is likely not doing online signing, but serving whatever a signing utility chose.


4. Should there be a mention as to which algorithms a validator should support? It may not require a direct reference to whichever RFC is current, but simply listing the IANA maintained registry and say "implement all the MUSTs and probably the SHOULDs too". Something like the following:


Algorithm Usage in Validators


DNSSEC signatures can be generated by different digital signatures algorithms. The current list of algorithms defined for use with DNSSEC is published in an IANA maintained registry [insert IANA link here]. Validators have to be able to understand and validate different algorithms that may be in common use with DNSSEC. The DNSSEC digital signature registry table is regularly updated with guidance as to which algorithms are considered MANDATORY and/or RECOMMENDED. In order to be effective, a validator MUST understand all digital signature algorithms marked as MANDATORY and SHOULD understand all digital signature algorithms marked as RECOMMENDED.


REQXX: Validators MUST implement all MANDATORY digital signature algorithms and SHOULD implement all RECOMMENDED digital signature algorithms.


Note: This wording isn't the best, and needs some work. I also don't know if the SHOULD in the REQ should be changed to a MAY, but I would prefer SHOULD.


Scott