From nobody Tue Oct 3 05:30:40 2017 Return-Path: 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 E49D41345C9 for ; Tue, 3 Oct 2017 05:30:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk 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 XJ4on_TsAByd for ; Tue, 3 Oct 2017 05:30:34 -0700 (PDT) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [146.101.78.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E31751345CC for ; Tue, 3 Oct 2017 05:30:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1507033826; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references; bh=otwgG7OQjYt63K5nucMay3XNMzUwd8Bhj/7xFNpzSno=; b=ZhlZl4EY2l4gs05uNYJPcqcfubBO/3/TWq7G5Hr9iE6z14s/cH4grzL+QU4YGx3y9DArhyuH72Dp0PY+3pV0MlQyI+3lBwLZJrL0saWkBJxxyhERTmb8kvJy2f7i+aik3/LPdN3HA3BVKF36FoKjqOBMf8sikyOD47ICwLsmUQA= Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-am5eur03lp0111.outbound.protection.outlook.com [213.199.154.111]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-9-w5yFpAZzNESJT29x4fbMsw-1; Tue, 03 Oct 2017 13:30:22 +0100 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB1137.eurprd07.prod.outlook.com (10.163.188.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.5; Tue, 3 Oct 2017 12:30:21 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::6d:9ebf:900:b590]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::6d:9ebf:900:b590%14]) with mapi id 15.20.0077.018; Tue, 3 Oct 2017 12:30:21 +0000 From: Tim Chown To: Stuart Cheshire CC: "dnssd@ietf.org" , dnsop Thread-Topic: [DNSOP] DNSSD (DNS-Based Service Discovery) testing at IETF 100 Hackathon Thread-Index: AQHTPENglj2HCSob30eA6UMFkAgI4w== Date: Tue, 3 Oct 2017 12:30:20 +0000 Message-ID: <2BA087ED-A935-43C1-BCDE-2D79519A66D4@jisc.ac.uk> References: <23952FC2-2FB5-4FE1-BBDC-F577CCEFB043@apple.com> In-Reply-To: <23952FC2-2FB5-4FE1-BBDC-F577CCEFB043@apple.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3273) x-originating-ip: [194.82.140.195] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM3PR07MB1137; 20:w4kiGfbsY0eW3AJo64jNHXjXOTYQfZqPdrpVRXihgNi5LAgahRHCP/hVWwp9Atcph1yfdqp7BVi5IKvK4gQlwJFdPyt5I9EPMxdsgtZteX2p+TcouCv3KELx1q3rz9KIct56d2MMQBmRgOv11TeEPVrMnBSrubHUmI0Y6RJj/aY= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 862acb14-b0e3-42bc-a9db-08d50a5a835e x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:AM3PR07MB1137; x-ms-traffictypediagnostic: AM3PR07MB1137: x-exchange-antispam-report-test: UriScan:(80524489315369)(31960201722614); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(93006095)(93001095)(3002001)(10201501046)(6041248)(20161123564025)(20161123562025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123558100)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM3PR07MB1137; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM3PR07MB1137; x-forefront-prvs: 044968D9E1 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(376002)(346002)(189002)(199003)(24454002)(105586002)(786003)(97736004)(478600001)(53546010)(72206003)(316002)(16799955002)(6486002)(83716003)(33656002)(229853002)(54906003)(106356001)(57306001)(2900100001)(25786009)(66066001)(5250100002)(4326008)(6506006)(53936002)(3846002)(6512007)(82746002)(86362001)(36756003)(6116002)(102836003)(101416001)(6436002)(6306002)(5660300001)(2906002)(14454004)(2950100002)(76176999)(81166006)(50986999)(189998001)(3660700001)(81156014)(305945005)(68736007)(8676002)(7736002)(8666007)(3280700002)(99286003)(6246003)(50226002)(6916009)(42882006)(74482002)(8936002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1137; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Oct 2017 12:30:20.9521 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB1137 X-MC-Unique: w5yFpAZzNESJT29x4fbMsw-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [DNSOP] DNSSD (DNS-Based Service Discovery) testing at IETF 100 Hackathon X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Oct 2017 12:30:37 -0000 SGksDQoNCj4gT24gMjkgU2VwIDIwMTcsIGF0IDAyOjExLCBTdHVhcnQgQ2hlc2hpcmUgPGNoZXNo aXJlQGFwcGxlLmNvbT4gd3JvdGU6DQo+IA0KPiBUZWQgTGVtb24gYW5kIEkgYXJlIHBsYW5uaW5n IG9uIGRvaW5nIGFuIGludGVyb3AgdGVzdCBvZiBvdXIgRE5TU0QgY29kZSBhdCB0aGUgSUVURiAx MDAgSGFja2F0aG9uLg0KPiANCj4gRGV0YWlscyBjYW4gYmUgZm91bmQgaGVyZToNCj4gDQo+IDxo dHRwczovL3d3dy5pZXRmLm9yZy9yZWdpc3RyYXRpb24vTWVldGluZ1dpa2kvd2lraS9kb2t1LnBo cD9pZD0xMDBoYWNrYXRob24+DQo+IA0KPiBXZSBhcmUgcGxhbm5pbmcgdG8gdGVzdCB0aGUgZm9s bG93aW5nIHByb3RvY29sczoNCj4gDQo+IEROUyBTdGF0ZWZ1bCBPcGVyYXRpb25zICA8aHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtZG5zb3Atc2Vzc2lvbi1zaWduYWw+DQo+ IEROUyBQdXNoIE5vdGlmaWNhdGlvbnMgICA8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWlldGYtZG5zc2QtcHVzaD4NCj4gU2VydmljZSBEaXNjb3ZlcnkgUHJveHkgIDxodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1kbnNzZC1oeWJyaWQ+DQo+IFNlcnZpY2Ug RGlzY292ZXJ5IFJlbGF5ICA8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNjdGwt ZG5zc2QtbWRucy1yZWxheT4NCj4gU2VydmljZSBEaXNjb3ZlcnkgQnJva2VyIDxodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc2N0bC1kaXNjb3ZlcnktYnJva2VyPg0KPiANCj4gV2Ug d2VsY29tZSBvdGhlcnMgdG8gam9pbiB1cyBhdCB0aGUgSGFja2F0aG9uLiBQbGVhc2UgbGV0IHVz IGtub3cgaWYgeW914oCZZCBsaWtlIHRvIGNvbWUgYWxvbmcgYW5kIGpvaW4gaW4gdGhlIHRlc3Rp bmcuDQoNClRoaXMgaXMgZXhjZWxsZW50LCB0aGFua3MgU3R1YXJ0Lg0KDQpXaGV0aGVyIHBlb3Bs ZSBwbGFuIHRvIHRha2UgcGFydCBvciBub3QgaW4gdGhlIGhhY2thdGhvbiwgcmV2aWV3cyBhbmQg Y29tbWVudHMgcGFydGljdWxhcmx5IG9uIHRoZSBuZXcgZHJhZnRzIHdvdWxkIGJlIHdlbGNvbWVk Lg0KIA0KVGlt From nobody Tue Oct 3 09:46:52 2017 Return-Path: X-Original-To: dnsop@ietf.org Delivered-To: dnsop@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 47BEF134F4A; Tue, 3 Oct 2017 09:46:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: warren@kumari.net, dnsop@ietf.org, dnsop-chairs@ietf.org, smccammon@amsl.com X-Test-IDTracker: no X-IETF-IDTracker: 6.63.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150704921024.30625.11571622685996668554.idtracker@ietfa.amsl.com> Date: Tue, 03 Oct 2017 09:46:50 -0700 Archived-At: Subject: [DNSOP] dnsop - Update to a Meeting Session Request for IETF 100 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Oct 2017 16:46:50 -0000 An update to a meeting session request has just been submitted by Stephanie McCammon, on behalf of the dnsop working group. --------------------------------------------------------- Working Group Name: Domain Name System Operations Area Name: Operations and Management Area Session Requester: Stephanie McCammon Number of Sessions: 2 Length of Session(s): 2 Hours, 1 Hour Number of Attendees: 160 Conflicts to Avoid: First Priority: dprive dnssd homenet dhc doh Second Priority: v6ops intarea trans ideas Third Priority: 6man grow opsarea opsawg pcp saag sidr People who must be present: Suzanne Woolf Joel Jaeggli Warren Kumari Tim Wicinski Resources Requested: Special Requests: If either session is slotted for Friday, please make it the second 1 hour session. thanks --------------------------------------------------------- From nobody Fri Oct 6 06:56:27 2017 Return-Path: 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 6B1061349CC for ; Fri, 6 Oct 2017 06:56:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 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_HI=-5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz 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 xWtckY0-DwXR for ; Fri, 6 Oct 2017 06:56:24 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (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 0EF3C1349C8 for ; Fri, 6 Oct 2017 06:56:23 -0700 (PDT) Received: from [IPv6:2001:1488:fffe:6:bc7e:ccff:fea4:1d71] (unknown [IPv6:2001:1488:fffe:6:bc7e:ccff:fea4:1d71]) by mail.nic.cz (Postfix) with ESMTPSA id 0EDEE61109 for ; Fri, 6 Oct 2017 15:56:21 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1507298181; bh=mjws3+d/HrZQ1nYOMsfev2rTfdgvrW5IKDsglcqR71k=; h=To:From:Date; b=X/cHYKgFEX3vTy+kmHyGwV4IPvuXVOuNzOQ58gIzTyjUoliz8LR38GE+mteOKRvpO gwdX0jqqOHmHTa/Ea0+q/XlWOk2cdy75VozGtDH4uvKiKN6XdeyuTG5epLyi0xW8wh Q1dFjnQGhRnA1VS0xCkrtNoFKELIMJj1R8Koj9EM= To: dnsop@ietf.org References: From: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= Organization: CZ.NIC Message-ID: Date: Fri, 6 Oct 2017 15:56:20 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [DNSOP] draft-ietf-dnsop-dns-rpz X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Oct 2017 13:56:26 -0000 Hello dnsop, draft-ietf-dnsop-dns-rpz expired on 2017-09-10, i.e. did not receive any update from 2017-03-09. Is there a real apetite for work on this document? We are considering RPZ implementation for Knot Resolver next year but if the document is not going to move forward I would rather close the ticket and be done with it. I certainly do commit to implementing ever-changing protocol without readily available description ... Is there anyone interested in the document except me and the appointed editor? Thank you for replies. Petr Špaček @ CZ.NIC On 18.7.2017 14:13, Suzanne Woolf wrote: > Dear colleagues, > > > As you might recall, we had a call for adoption for draft-vixie-dns-rpz > just before IETF 98 in March. We had a lively discussion and decided to > adopt the document for further work in the WG as an Informational RFC. > > However, the chairs then discovered we’d made a mistake in adopting the > draft with the copyright that reserved rights in derivative works to the > original authors. This isn’t allowed for a Working Group document (see > RFC5378, Section 3.3). > > We’ve talked since then with the authors about how we might move forward > with the draft. They had concerns, which had already been discussed on > the list, about some of the views of the WG on the applicability of RPZ. > > We believe we’ve found a way forward that meets their concerns and the > needs of the WG. We propose that: > > 1. The draft adopts the following language in the Introduction: > > This document describes an existing and widely deployed method by > which a security policy can be applied to DNS responses, possibly > causing an end system to receive responses that do not correspond to > actual DNS zone content. Such policy-based responses might prevent > access to selected HTTP servers, or redirect users to "walled > gardens", or block objectionable email, or otherwise defend against > DNS content deemed malicious by the RDNS operator and the end-user. > > This method describes its policy using a specially formatted DNS > Zone called a Response Policy Zone (RPZ), and is an instance of a > more general mechanism called a "DNS Firewall." Like other > mechanisms called "firewalls," response policy zones (RPZ) can be > used to block both wanted as well as unwanted data.  RPZ ought not > be used to interfere with data desired by recipients. In other > words, RPZ should be deployed only with the permission of every > affected RDNS end-users. > > This document does not recommend the use of RPZ in any particular > situation or instead of other mechanisms including those more > commonly called "firewalls."  This document lacks an applicability > statement for that reason, and because it merely describes a > currently common practice, without recommending or criticising that > practice. By design and expectation, response policy zones (RPZ) > must be seen as a defensive and virtuous tool, or it will either not > be used, or will be bypassed by end-users. > > > 2. We had already limited the the scope of the document to describing > the current protocol, with any discussion of proposed changes left to a > later document if people want to do that work. That limitation stands. > The intended document status is Informational. > > 3. The copyright is changed to the standard boilerplate required for a > WG draft. > > > If this is acceptable to the WG, we’ll keep the new draft with these > changes as a WG draft.  > > If not, the draft will be dropped as a WG item. The authors can seek > publication of the document as an independent submission or outside of > the RFC series. > > If you have a comment on this, please make it succinctly and soon. > > > thanks, > Suzanne & TIm From nobody Fri Oct 6 07:32:13 2017 Return-Path: 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 4E1091342E2 for ; Fri, 6 Oct 2017 07:32:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.664 X-Spam-Level: X-Spam-Status: No, score=0.664 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, SPF_SOFTFAIL=0.665] autolearn=no 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 b2XpFjwP3ZEw for ; Fri, 6 Oct 2017 07:32:09 -0700 (PDT) Received: from mail.banu.com (mail.banu.com [46.4.129.225]) by ietfa.amsl.com (Postfix) with ESMTP id 172691323B8 for ; Fri, 6 Oct 2017 07:32:09 -0700 (PDT) Received: from jurassic (unknown [115.117.161.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.banu.com (Postfix) with ESMTPSA id 034EF56A00F9; Fri, 6 Oct 2017 14:32:06 +0000 (GMT) Date: Fri, 6 Oct 2017 20:02:03 +0530 From: Mukund Sivaraman To: Petr =?utf-8?B?xaBwYcSNZWs=?= Cc: dnsop@ietf.org Message-ID: <20171006143203.GA7941@jurassic> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.9.0 (2017-09-02) Archived-At: Subject: Re: [DNSOP] draft-ietf-dnsop-dns-rpz X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Oct 2017 14:32:11 -0000 Hi Petr On Fri, Oct 06, 2017 at 03:56:20PM +0200, Petr Špaček wrote: > Hello dnsop, > > draft-ietf-dnsop-dns-rpz expired on 2017-09-10, i.e. did not receive any > update from 2017-03-09. > > Is there a real apetite for work on this document? No answer for this question, but see below... > We are considering RPZ implementation for Knot Resolver next year but if > the document is not going to move forward I would rather close the > ticket and be done with it. I certainly do commit to implementing > ever-changing protocol without readily available description ... I can't tell you whether to implement RPZ or not, but maybe the following will be useful from an implementation perspective. Whether IETF adopts it or not, RPZ is has been an existing real protocol in operational use for several years now (with implementations and data (zone) providers). The old RPZ specification was obsolete and this draft is the only current spec that describes RPZ as it is used today. For this reason at least, BIND will follow this spec whether it is a dnsop adopted document or is maintained outside IETF. If for some reason the co-authors abandon it (highly unlikely as they seem to have a business case for it), we at ISC will likely pick it up as it is a BIND feature. (We were going to do so about 1-1.5 years ago when we found that the old draft was outdated, and contacted Vixie about it.) It follows that if you want to support the RPZ zone syntax that is used in feeds provided by several vendors, this draft is the only current and correct spec as of now. No comment about whether dnsop should adopt it or about the philosophical side. Mukund From nobody Fri Oct 6 08:01:11 2017 Return-Path: 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 553EA1349EF for ; Fri, 6 Oct 2017 08:01:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, SPF_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 07Z2bCaBCMno for ; Fri, 6 Oct 2017 08:01:09 -0700 (PDT) Received: from calcite.rhyolite.com (calcite-v6.rhyolite.com [IPv6:2001:470:4b:581::3]) (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 961BC1349E7 for ; Fri, 6 Oct 2017 08:01:08 -0700 (PDT) Received: from calcite.rhyolite.com (localhost [127.0.0.1]) by calcite.rhyolite.com (8.15.2/8.15.2) with ESMTPS id v96F0prr028990 (CN=www.rhyolite.com version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for env-from ; Fri, 6 Oct 2017 15:00:51 GMT Received: (from vjs@localhost) by calcite.rhyolite.com (8.15.2/8.15.2/Submit) id v96F0paX028988 for dnsop@ietf.org; Fri, 6 Oct 2017 15:00:51 GMT Date: Fri, 6 Oct 2017 15:00:51 GMT From: Vernon Schryver Message-Id: <201710061500.v96F0paX028988@calcite.rhyolite.com> To: dnsop@ietf.org In-Reply-To: X-DCC-Rhyolite-Metrics: calcite.rhyolite.com; whitelist Archived-At: Subject: Re: [DNSOP] draft-ietf-dnsop-dns-rpz X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Oct 2017 15:01:10 -0000 > From: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= > draft-ietf-dnsop-dns-rpz expired on 2017-09-10, i.e. did not receive any > update from 2017-03-09. > > Is there a real apetite for work on this document? The change described in Suzanne Woolf's mail that you quoted is awaiting a "make is so" order from the chairs. I'd like to see the document get an official number, but https://tools.ietf.org/html/draft-ietf-dnsop-dns-rpz-00 looks like stable online storage (pending that applicability text). > We are considering RPZ implementation for Knot Resolver next year but if > the document is not going to move forward I would rather close the > ticket and be done with it. I certainly do commit to implementing > ever-changing protocol without readily available description ... RPZ is not currently an ever-changing protocol. Some of the controversy surrounding the document has been caused by Paul's and my insistance on restricting the current document to a description of the almost 8 year old notion of RPZ instead of fixing, improving, or extending it. If you will include hooks for an RPZ implementation in your shipped code as opposed to modified source in a 'contrib' directory that users must compile specially, I'd be happy to try to propose such hooks. In other words, I could try to make a patch for Knot Resolver like the patch that I wrote for Unbound (without cost to NLnet Labs). If you prefer, you could write the code. Vernon Schryver vjs@rhyolite.com From nobody Fri Oct 6 08:28:35 2017 Return-Path: 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 267B71349F4 for ; Fri, 6 Oct 2017 08:28:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 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_HI=-5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz 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 YL-yYnEwjcq2 for ; Fri, 6 Oct 2017 08:28:26 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (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 7FD4F133059 for ; Fri, 6 Oct 2017 08:28:26 -0700 (PDT) Received: from [IPv6:2001:1488:fffe:6:bc7e:5cff:fe79:ae7b] (unknown [IPv6:2001:1488:fffe:6:bc7e:5cff:fe79:ae7b]) by mail.nic.cz (Postfix) with ESMTPSA id CD4E461136; Fri, 6 Oct 2017 17:28:24 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1507303704; bh=OS+Oadf+37/Ac9mNxS4ppBZrRr9mZQH4NEN8jqH0pjA=; h=To:From:Date; b=I2pV2KhjyykDQmHMMkIJMWoXrJ/p9LHKuhn7PuS5W4JvtLG1YLTvVC+7dMmDv2kwG Z4oW3AetmVzumjciMinRdhBRXi4pd1oqra2tL1RcRNLTsa0+J64Rt6DgfVpMGFBFpu BDmo7ettrqqO0u8yv/dF5+Y66lKyx1+s0J1Su0ic= To: Vernon Schryver References: <201710061500.v96F0paX028988@calcite.rhyolite.com> Cc: dnsop@ietf.org From: =?UTF-8?B?VmxhZGltw61yIMSMdW7DoXQ=?= Message-ID: Date: Fri, 6 Oct 2017 17:28:24 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <201710061500.v96F0paX028988@calcite.rhyolite.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [DNSOP] draft-ietf-dnsop-dns-rpz X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Oct 2017 15:28:35 -0000 Hi. On 10/06/2017 05:00 PM, Vernon Schryver wrote: > If you will include hooks for an RPZ implementation in your shipped > code as opposed to modified source in a 'contrib' directory that > users must compile specially, I'd be happy to try to propose such > hooks. In other words, I could try to make a patch for Knot Resolver > like the patch that I wrote for Unbound (without cost to NLnet Labs). > If you prefer, you could write the code. The current very limited implementation of RPZ in knot-resolver [1] is done via a couple dozen lines of lua code, i.e. only JIT-compiled.  The approach might remain similar, perhaps a bit more modularized, but in any case I expect it would be included by default, so I wouldn't fear about users having to recompile. [1] https://gitlab.labs.nic.cz/knot/knot-resolver/blob/v1.4.0/modules/policy/policy.lua#L294 --Vladimir From nobody Fri Oct 6 09:01:02 2017 Return-Path: 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 E71281349F4 for ; Fri, 6 Oct 2017 09:00:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, SPF_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 BH_BhYyGOm5i for ; Fri, 6 Oct 2017 09:00:58 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F7021331D9 for ; Fri, 6 Oct 2017 09:00:58 -0700 (PDT) Received: from [IPv6:2001:559:8000:c9:d5f2:bb80:f31d:6e7f] (unknown [IPv6:2001:559:8000:c9:d5f2:bb80:f31d:6e7f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id C5FD061FA3; Fri, 6 Oct 2017 16:00:57 +0000 (UTC) Message-ID: <59D7A8B9.4020606@redbarn.org> Date: Fri, 06 Oct 2017 09:00:57 -0700 From: Paul Vixie User-Agent: Postbox 5.0.19 (Windows/20170908) MIME-Version: 1.0 To: =?UTF-8?B?VmxhZGltw61yIMSMdW7DoXQ=?= CC: Vernon Schryver , dnsop@ietf.org References: <201710061500.v96F0paX028988@calcite.rhyolite.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [DNSOP] draft-ietf-dnsop-dns-rpz X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Oct 2017 16:01:00 -0000 Vladimír Čunát wrote: > Hi. > > On 10/06/2017 05:00 PM, Vernon Schryver wrote: >> If you will include hooks for an RPZ implementation in your shipped >> code as opposed to modified source in a 'contrib' directory that >> users must compile specially, I'd be happy to try to propose such >> hooks. In other words, I could try to make a patch for Knot Resolver >> like the patch that I wrote for Unbound (without cost to NLnet Labs). >> If you prefer, you could write the code. > > The current very limited implementation of RPZ in knot-resolver [1] is > done via a couple dozen lines of lua code, i.e. only JIT-compiled. The > approach might remain similar, perhaps a bit more modularized, but in > any case I expect it would be included by default, so I wouldn't fear > about users having to recompile. let me clarify. there is an rpz implementation for bind9 and unbound which is mostly outside the server itself. so, it's a duplication of effort for bind9, which has its own internal implementation of rpz, but it's new functionality for unbound, which does not have rpz built in. this rpz implementation consists of a daemon, a command line tool, a shared library, and a shared memory (mmap'd file) segment. the api for the shared library is meant to be not just name server implementation (thus, it works on bind9 and unbound), but also policy implementation (thus, it could work for a policy system other than rpz, though we've not tested it.) the implementation we have (farsight security) is not open source, but, the API is entirely unencumbered. thus, someone other than us could implement a shared library and associated software that spoke to this API and could be dynamically loaded by bind9, unbound, and any other impementation of that API. patches to make knot-recursive speak this API are what vernon offered. those patches, like the API it speaks to, are entirely unencumbered, and would therefore be compatible with your license. in fact the patches to make knot-recursive speak to this API would be donated to you and would become your property and would have only your license. farsight's implementation of this API is called fastrpz. we don't give it away to the whole community; only to people who operate passive dns sensors for SIE. we fully expect to see fully open source competitors for our implementation of this API from other members of the community in the fullness of time. the API now has a name, the response policy service (RPS). please contact vernon directly if you'd be willing to accept a donation of patches to make knot-resolver able to call the RPS API, and thus, able to dynamically load any shared library that implements the RPS API. please contact me directly if any of you would be willing to operate a passive DNS sensor for SIE, in exchange for a right-to-use license for the fastrpz implementation of the RPS API, or perhaps data trades &etc. -- P Vixie From nobody Fri Oct 6 09:39:06 2017 Return-Path: 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 875B3134A72 for ; Fri, 6 Oct 2017 09:39:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PP_MIME_FAKE_ASCII_TEXT=0.001, SPF_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 A754z5-iylqe for ; Fri, 6 Oct 2017 09:39:03 -0700 (PDT) Received: from calcite.rhyolite.com (calcite-v6.rhyolite.com [IPv6:2001:470:4b:581::3]) (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 63A73134A7C for ; Fri, 6 Oct 2017 09:38:56 -0700 (PDT) Received: from calcite.rhyolite.com (localhost [127.0.0.1]) by calcite.rhyolite.com (8.15.2/8.15.2) with ESMTPS id v96Gclfb082321 (CN=www.rhyolite.com version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for env-from ; Fri, 6 Oct 2017 16:38:47 GMT Received: (from vjs@localhost) by calcite.rhyolite.com (8.15.2/8.15.2/Submit) id v96Gckki082320 for dnsop@ietf.org; Fri, 6 Oct 2017 16:38:46 GMT Date: Fri, 6 Oct 2017 16:38:46 GMT From: Vernon Schryver Message-Id: <201710061638.v96Gckki082320@calcite.rhyolite.com> To: dnsop@ietf.org In-Reply-To: X-DCC-Rhyolite-Metrics: calcite.rhyolite.com; whitelist Archived-At: Subject: Re: [DNSOP] draft-ietf-dnsop-dns-rpz X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Oct 2017 16:39:05 -0000 > From: =?UTF-8?B?VmxhZGltw61yIMSMdW7DoXQ=?= > The current very limited implementation of RPZ in knot-resolver [1] is > done via a couple dozen lines of lua code, i.e. only JIT-compiled.  The > approach might remain similar, perhaps a bit more modularized, but in > any case I expect it would be included by default, so I wouldn't fear > about users having to recompile. > > [1] > https://gitlab.labs.nic.cz/knot/knot-resolver/blob/v1.4.0/modules/policy/policy.lua#L294 I wish I wouldn't offend people when I point out that a mechanism that uses local zone files is not a very limited response policy zone implementation. Such things might be far better than real "rpz", but they're not "rpz". (I can make a case for them being better although I don't buy it, perhaps because I'm biased.) Overwriting public DNS data triggered by qnames has always been trivial, but that is not "rpz." Simply fire up a local authority server with your own "DNS lies" and point your resolvers to it, perhaps with custom "hints" files. If you're running combined authority/resolver code such as BIND, simply add some local zone files. But such ad hoc authority server schemes as well as the new so called "rpz" schemes of adding local zone files to resolvers the lack features that motiviated the original implementation of real RPZ including: - distributed policy zones, including from external organizations This sounds minor, but it is major. It's related to why so few organizations maintain their own anti-spam DNS blacklists. You could use FTP, rsync, HTTP, etc. and a cron job, but in practice you won't. And if you did, it updates would have latencies of hours or days instead of seconds with real RPZ. - dynamically combine policy from multiple sources In theory this could be done with some perl, awk, or even Bourne shell code, but not in practice at scale. - policies triggered by the contents of A and AAAA responses or by the names or IP addresses of authorities The bad guys can and do register new domains faster than you can update your local blacklist, faster than they can hijack new IP addresses for those new domains, and faster than they'd like to establish new authorities serving those new domains. - no need to restart the resolver to reload the zone This not only minimizes end user disruption when the zones are reloaded but allows organization-wide policy changes with latencies measured in seconds. In other words, hacking local zone file qname overrides into a resolver is not hard (including CNAME and DNAME chains). The horrid code involves triggering on A or AAAA contents and authority names and addresses...well there're also SOA timers, IXFR, AXFR, Notify, and TSIG, but that code is less horrid than voluminous. Please don't misunderstand me as saying no one else can or should write real RPZ code. Many people could and I really wish they would. That's why I spent a lot effort outside my comfort zone on the I-D. What bugs me are implementations of so called RPZ and RRL that share only the acronyms with the BIND stuff. Vernon Schryver vjs@rhyolite.com From nobody Fri Oct 6 11:13:55 2017 Return-Path: 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 C5AD8134BCE for ; Fri, 6 Oct 2017 11:13:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.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 0iarV4Kzabt0 for ; Fri, 6 Oct 2017 11:13:50 -0700 (PDT) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (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 56874134BD0 for ; Fri, 6 Oct 2017 11:13:48 -0700 (PDT) Received: by mail-qt0-x229.google.com with SMTP id o52so32968723qtc.9 for ; Fri, 06 Oct 2017 11:13:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ViNlVODREeHQ5RzfrocGjbX2YGos4JkfU9t6J1TUpxk=; b=FrFT0bYsBBYTJmUHwi+xuhaeOKNa51XMGkYoF4NfGcovBhKcf2IHxPNnMcaGo9OEoj dllNM7F3kbViKYuZHSLUUZAxBEtDfeWsCvnTKGuhwDHQ13G1tCrh2Qocsrins5SJHxTS 2tfg36xeRnY5Q0o/GAmyI59M71OKSmBRA7TFw= 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; bh=ViNlVODREeHQ5RzfrocGjbX2YGos4JkfU9t6J1TUpxk=; b=E/VCo2qHpLshtVDUruCAQFGXWKZG3R0DGn4KI7KgNvlgq97wMzvymnDFK5+GmRLxIb LWlKtOy9I5agrKgBjcceK9R+Z5uc9YSruccuEOrxOOfD3ZYkuTcNlGYjK0J+nehTQqnV E1W/tcdIID7DFn0xrJVeoePBL80lKNf+/9Eub69pSf5lCme5VqpQVskiVX5PpUTIsksi W1/AMIWLF6FuE1JXdSCACl8GV+9UjpYbsGArTz0TRfD7rAr5VXVbtxQyQDp0EVwcEXlr hJh8g3yGBhel8G6MnFMOGrSSsao2auT4fvugnTilMybE2bR33H84Bk+lQgVgcBTOC/OS 5/oA== X-Gm-Message-State: AMCzsaVcF7uiZ2NK8tceSlBNOCOVhMEwG4Dm2uCozRhL4R8dy6k2/G8k zH9JDQDzN6Q7aT/X1+WwWijhKX7UeaZ376QYEbklOWau5JQ= X-Google-Smtp-Source: AOwi7QBYITyAXF7VkDKOaplCbL05ZbbXGX2Wd9suN5xICD+h/x9ozuxcpCCz3d94AbVG43TdBuic4HzU6qGD+0tz9m0= X-Received: by 10.129.5.14 with SMTP id 14mr2316823ywf.463.1507313627324; Fri, 06 Oct 2017 11:13:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.16.194 with HTTP; Fri, 6 Oct 2017 11:13:46 -0700 (PDT) In-Reply-To: <201710061638.v96Gckki082320@calcite.rhyolite.com> References: <201710061638.v96Gckki082320@calcite.rhyolite.com> From: =?UTF-8?Q?Marek_Vavru=C5=A1a?= Date: Fri, 6 Oct 2017 11:13:46 -0700 Message-ID: To: Vernon Schryver Cc: dnsop Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [DNSOP] draft-ietf-dnsop-dns-rpz X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Oct 2017 18:13:52 -0000 Hi Vernon, There's a functionality [1] to do all these things (and more), you just can't read/write complicated rules from RPC compatible format (DNS zone files). Feel free to contribute of course. Marek [1]: http://knot-resolver.readthedocs.io/en/stable/modules.html#dns-application-firewall On Fri, Oct 6, 2017 at 9:38 AM, Vernon Schryver wrote: >> From: =?UTF-8?B?VmxhZGltw61yIMSMdW7DoXQ=?= > >> The current very limited implementation of RPZ in knot-resolver [1] is >> done via a couple dozen lines of lua code, i.e. only JIT-compiled. The >> approach might remain similar, perhaps a bit more modularized, but in >> any case I expect it would be included by default, so I wouldn't fear >> about users having to recompile. >> >> [1] >> https://gitlab.labs.nic.cz/knot/knot-resolver/blob/v1.4.0/modules/policy/policy.lua#L294 > > I wish I wouldn't offend people when I point out that a mechanism > that uses local zone files is not a very limited response policy > zone implementation. Such things might be far better than real > "rpz", but they're not "rpz". (I can make a case for them being > better although I don't buy it, perhaps because I'm biased.) > > Overwriting public DNS data triggered by qnames has always been trivial, > but that is not "rpz." Simply fire up a local authority server with > your own "DNS lies" and point your resolvers to it, perhaps with custom > "hints" files. If you're running combined authority/resolver code > such as BIND, simply add some local zone files. But such ad hoc > authority server schemes as well as the new so called "rpz" schemes > of adding local zone files to resolvers the lack features that motiviated > the original implementation of real RPZ including: > > - distributed policy zones, including from external organizations > This sounds minor, but it is major. It's related to why so few > organizations maintain their own anti-spam DNS blacklists. > You could use FTP, rsync, HTTP, etc. and a cron job, but in > practice you won't. And if you did, it updates would have > latencies of hours or days instead of seconds with real RPZ. > > - dynamically combine policy from multiple sources > In theory this could be done with some perl, awk, or even > Bourne shell code, but not in practice at scale. > > - policies triggered by the contents of A and AAAA responses or by > the names or IP addresses of authorities > The bad guys can and do register new domains faster than you can > update your local blacklist, faster than they can hijack new IP > addresses for those new domains, and faster than they'd like to > establish new authorities serving those new domains. > > - no need to restart the resolver to reload the zone > This not only minimizes end user disruption when the zones > are reloaded but allows organization-wide policy changes with > latencies measured in seconds. > > In other words, hacking local zone file qname overrides into a > resolver is not hard (including CNAME and DNAME chains). The horrid > code involves triggering on A or AAAA contents and authority names > and addresses...well there're also SOA timers, IXFR, AXFR, Notify, > and TSIG, but that code is less horrid than voluminous. > > Please don't misunderstand me as saying no one else can or should > write real RPZ code. Many people could and I really wish they > would. That's why I spent a lot effort outside my comfort zone on > the I-D. What bugs me are implementations of so called RPZ and RRL > that share only the acronyms with the BIND stuff. > > > Vernon Schryver vjs@rhyolite.com > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > From nobody Fri Oct 6 13:08:57 2017 Return-Path: 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 0AC6E134C88 for ; Fri, 6 Oct 2017 13:08:55 -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_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 KLGygS_igmHL for ; Fri, 6 Oct 2017 13:08:53 -0700 (PDT) Received: from calcite.rhyolite.com (calcite-v6.rhyolite.com [IPv6:2001:470:4b:581::3]) (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 79D8F134C84 for ; Fri, 6 Oct 2017 13:08:53 -0700 (PDT) Received: from calcite.rhyolite.com (localhost [127.0.0.1]) by calcite.rhyolite.com (8.15.2/8.15.2) with ESMTPS id v96K8Zxc062071 (CN=www.rhyolite.com version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for env-from ; Fri, 6 Oct 2017 20:08:36 GMT Received: (from vjs@localhost) by calcite.rhyolite.com (8.15.2/8.15.2/Submit) id v96K8Z3M062070 for dnsop@ietf.org; Fri, 6 Oct 2017 20:08:35 GMT Date: Fri, 6 Oct 2017 20:08:35 GMT From: Vernon Schryver Message-Id: <201710062008.v96K8Z3M062070@calcite.rhyolite.com> To: dnsop@ietf.org In-Reply-To: X-DCC-Rhyolite-Metrics: calcite.rhyolite.com; whitelist Archived-At: Subject: Re: [DNSOP] draft-ietf-dnsop-dns-rpz X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Oct 2017 20:08:55 -0000 > From: =?UTF-8?Q?Marek_Vavru=C5=A1a?= > There's a functionality [1] to do all these things (and more), you > just can't read/write complicated rules from RPC compatible format > (DNS zone files). Feel free to contribute of course. On the contrary, as far as I can see from the table in http://knot-resolver.readthedocs.io/en/stable/modules.html none the features that originally justified RPZ are present in the Knot mechanism. It lacks - distributed, simultaneous multi-source polices - IP triggers - full client-IP triggers - redirecting to walled gardens - NSDNAME and NSIP triggers (although those were added after my first versions by user demand) - walled gardens (according to the table, but I don't understand how that is missing) The Knot mechanism might be a lot better than RPZ, but it is *NOT* RPZ. Because it uses a different rule source-resolver protocol, it can be neither a subset nor a superset of RPZ. Calling it "rpz" is like calling the ancient DEC name scheme (I've forgotten its name) or NIS (YP) "DNS." Those things could do things that DNS cannot do. The DEC protocol was arguably better all around than DNS, but it was not DNS, no matter how often or how hard its advocates tried to sell as DNS. One might say "it's a subset without the bits that some mistakenly claim are important and it uses an incompatible protocol but it's still rpz," but that would be like saying a Chevrolet Spark is a subset of a 40 ton tractor, or vice versa. https://www.google.com/search?q=Chevrolet+spark https://www.google.com/search?q=60+ton+tractor That the Spark is more useful to more people and that most people could not use a large tractor does not make one a subset of the other. They simply differ. Again, the Knot mechanism might be better than RPZ, especially if it were given a few of what seem to me like easy additions. RPZ has suffered from feaping creaturism; something simpler could be better. But please don't call it RPZ, because it is not RPZ. Vernon Schryver vjs@rhyolite.com From nobody Mon Oct 9 13:17:42 2017 Return-Path: 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 DDA2E1321DF for ; Mon, 9 Oct 2017 13:17:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] 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 xMuZCSYDEoxH for ; Mon, 9 Oct 2017 13:17:37 -0700 (PDT) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (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 9ED251342E5 for ; Mon, 9 Oct 2017 13:17:36 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id b189so25465074wmd.4 for ; Mon, 09 Oct 2017 13:17:36 -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; bh=AC6APZWEy+NqYKQd04qOiSG3g8i/i5cTMW+pLuxGc24=; b=TyUzQHZMlxV5Wwxu7DmhKLceel8PeNgGnf6gI/XY4Pkh+vafMRPYKUcJGYwFNYQMn4 mFoW9QEg8cvB3+msrKpI1BDIhhsXNn5h4P6neUWicRxF1YVxZqFH/NHe3eK6RlBD0+vw jf0rMItx8QShxVQ4nfc2mrieCCvYVCo1kxLpmyzlWDSxy//T1VOyTgy+z2vjrEidRSd7 xcuQtzCZhGCiiu/LOY8KLEW6Tq/EoryS0bnV14zvVpDX1OBvNL5gxfa+ZhyveH7FLBPv e4I14VhTEkw2GfKEktdSWc5GIjbetIz+d0r+p/OQhi30dg8054cGPaKp6JwlfjLUAG8s WB2Q== 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; bh=AC6APZWEy+NqYKQd04qOiSG3g8i/i5cTMW+pLuxGc24=; b=tleAq74p663dKWiHKWbMgPhWkyowUZKhQ04PLZAY48rTmlVXnkBCP/9lHATWVvrcwv CJI3vdHSLt0NOn6LAzbYA0wCMUbl9BhSePFls3sLGhm9DEgpXj62/DOivVAApY9x5/W3 1yY2N9LCytiuMA7QPmbc5YAPlszZmuHOuDIlr7BX4Ez6xKUHqoh5HJLz4HE68KfQGIg1 y1h5PX3SgUodFF3xc4kfHPl2EqeSOtQp5K+jYPSzheSjBLf/Oqr6Bp34p0R7jrOEVMhj Cj6t3rHNffpmbRM0imtop/uW3eoC5QEdiaMYcguKu51lqc++GqDhlYF6omK+W+vAh41L GMBA== X-Gm-Message-State: AMCzsaXbyqQWWAOldkfFEsi02gE9Zoxyt7K8wtadXM00RVQhA14l+6yX Lt9cI8wargGq0VAr1HAusF1UuDfim7BOGjCN5yUiQSMei8o= X-Google-Smtp-Source: AOwi7QD97/enPgeIOdj9Ph62bbRrPgDQogKoIC/2MwGsE2/9k+e7OJS8Hl3f9eJ9GRvinP4G/jELZVfslwMB5gMHFDI= X-Received: by 10.223.133.179 with SMTP id 48mr2460102wrt.184.1507580254924; Mon, 09 Oct 2017 13:17:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.187.12 with HTTP; Mon, 9 Oct 2017 13:16:54 -0700 (PDT) In-Reply-To: References: <20170911013510.17202.qmail@ary.lan> From: Warren Kumari Date: Mon, 9 Oct 2017 13:16:54 -0700 Message-ID: To: Wes Hardaker Cc: John Levine , dnsop Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [DNSOP] DNSOP Call for Adoption - draft-west-let-localhost-be-localhost X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Oct 2017 20:17:41 -0000 [ Top-post - replying midway through because this seemed like the most related email :-) ] So, I've been noodling over this for quite a while, and I've refined my views -- the more I think about it, the more I think that "querying the DNS for localhost (or .localhost) is an error " -- and that NXDOMAIN is the correct answer. This name doesn't, and shouldn't exist in the DNS, and by happy coincidence ( :-P ) there is no root delegation for this, and so there is no action needed there. For the same reason, this shouldn't need to be added to locally served zones, no special handling should be performed by DNS servers[0], and all of section 4.3 can go away (the normal DNSSEC behavior is the "right" behavior). Some resolvers are currently replying with an address for 'localhost.' and this behavior should be removed. So, for foo.localhost.example.com -- I feel that it is unreasonable to retroactively declare that the string is somehow reserved all throughout the DNS namespace, and things like http://localhost.net/ exist (perhaps they "shouldn't", but...), but I could be convinced that I'm wrong here. Stub resolver libraries must return 127.0.0.1 or ::1 for localhost., or, probably .localhost (but I could easily be convinced that only 'localhost' is valid). Stub resolvers must also not apply any sort of search list processing to these names. So, that's my (new) views, and the thread seemed to have stalled. I believe that the security implications of having localhost queries leak into the DNS is bad, and there is significant evidence that this is happening. I get that there is no answer that will make everyone happy, but now that we've had some time to mull over this, where did we end up? W On Mon, Sep 11, 2017 at 10:21 PM, Wes Hardaker wrote: > "John Levine" writes: > >> It seems to me that if someone has enough programming skill to write a >> DNSSEC verifier for her cache or stub resolver, she has enough skill >> to treat localhost as a special case. > > I've been trying to figure out for a few days now how to insert my > opinion. It's kinda like the above but not. Specifically, we have > multiple naming systems already, and I'd argue that localhost actually > isn't in the DNS naming system. There is no authoritative source for > it. In fact, DNSSEC proves this. > > Instead, localhost is a operating system convention, a /etc/hosts name, > an NIS name, or one of the other things that is able to resolve that > name. But the DNS is not where that resolution comes from. > > Now, how do we ensure that a conflict never happens? That's a better > discussion and there are a few options ranging from policy to ensure > it's never assigned, to actually registering it, to... > -- > Wes Hardaker > USC/ISI > > _______________________________________________ > 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 From nobody Mon Oct 9 13:20:32 2017 Return-Path: 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 97AB113304B for ; Mon, 9 Oct 2017 13:20:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.102 X-Spam-Level: X-Spam-Status: No, score=-5.102 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eff.org 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 Gjzcc1DE_GAB for ; Mon, 9 Oct 2017 13:20:28 -0700 (PDT) Received: from mail2.eff.org (mail2.eff.org [173.239.79.204]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3042132924 for ; Mon, 9 Oct 2017 13:20:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject; bh=pyY9rQRwYdSPWBY2CwQNRnNKvZuFCVx+vqTrKXPbpQs=; b=jLH1AFvhEhUIxGutJ7shB+3od0/sDWQZBtkFI9PMhz/wTGWw13LPy75i7WbTm5UoBzZDG3EwMWaqS0zhjtlr6PWrVv2THRzxpBWRffR0lM+hO9uG+HekcqJiYNksuWHzW00ufbhK2yiaVpYE4zYIWJPXzFqsSpSaeuVHyNNRz34=; Received: ; Mon, 09 Oct 2017 13:20:25 -0700 To: Warren Kumari , Wes Hardaker Cc: dnsop , John Levine References: <20170911013510.17202.qmail@ary.lan> From: Jacob Hoffman-Andrews Message-ID: Date: Mon, 9 Oct 2017 13:20:27 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [DNSOP] DNSOP Call for Adoption - draft-west-let-localhost-be-localhost X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Oct 2017 20:20:30 -0000 On 10/09/2017 01:16 PM, Warren Kumari wrote: > So, that's my (new) views, and the thread seemed to have stalled. I > believe that the security implications of having localhost queries > leak into the DNS is bad, and there is significant evidence that this > is happening. I get that there is no answer that will make everyone > happy, but now that we've had some time to mull over this, where did > we end up? My feeling of the list is that your view matches the rough consensus: stub resolvers are responsible for resolving localhost to 127.0.0.1, and queries for localhost should not hit the network, as described in the draft. From nobody Tue Oct 10 02:12:42 2017 Return-Path: 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 8E593134B2D for ; Tue, 10 Oct 2017 02:12:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 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_HI=-5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz 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 kYH28kNG-0J5 for ; Tue, 10 Oct 2017 02:12:35 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (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 0A382134B29 for ; Tue, 10 Oct 2017 02:12:34 -0700 (PDT) Received: from [IPv6:2001:1488:fffe:6:31:37ff:fe20:4a03] (unknown [IPv6:2001:1488:fffe:6:31:37ff:fe20:4a03]) by mail.nic.cz (Postfix) with ESMTPSA id 5FEAD60114 for ; Tue, 10 Oct 2017 11:12:32 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1507626752; bh=OgmP37ppmM/SjJlUM7qO2K+Ou51GZk2gMu3Uxw/laCE=; h=To:From:Date; b=LCLcDdBeJiF/+xP7HhnwogvOzfr3xSvoNNa2FSVq9PnrIq7UQDXze3grg4yXRo7GJ JYJgF0X5OwjrPQHmLEMKHuZKal5cuosgKXp/bqMLxvyFbYuCIv3X5gkc2lkP0WFH2D /vF2OcEU9B74XR3SSN6UKKBhfRS0oqTBj6jnlHi8= To: dnsop@ietf.org References: <20170911013510.17202.qmail@ary.lan> From: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= Organization: CZ.NIC Message-ID: <89a93742-2917-2125-df8f-b14905218d0f@nic.cz> Date: Tue, 10 Oct 2017 11:12:32 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [DNSOP] DNSOP Call for Adoption - draft-west-let-localhost-be-localhost X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Oct 2017 09:12:41 -0000 On 9.10.2017 22:20, Jacob Hoffman-Andrews wrote: > On 10/09/2017 01:16 PM, Warren Kumari wrote: >> So, that's my (new) views, and the thread seemed to have stalled. I >> believe that the security implications of having localhost queries >> leak into the DNS is bad, and there is significant evidence that this >> is happening. I get that there is no answer that will make everyone >> happy, but now that we've had some time to mull over this, where did >> we end up? > My feeling of the list is that your view matches the rough consensus: > stub resolvers are responsible for resolving localhost to 127.0.0.1, and > queries for localhost should not hit the network, as described in the draft. I agree, consider it as one data point in your "rough consensus" estimation. -- Petr Špaček @ CZ.NIC From nobody Thu Oct 12 00:37:21 2017 Return-Path: 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 5A0B1133052 for ; Thu, 12 Oct 2017 00:37:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, URIBL_BLOCKED=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 Sh0u6hwrlBV4 for ; Thu, 12 Oct 2017 00:37:18 -0700 (PDT) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (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 4437F132143 for ; Thu, 12 Oct 2017 00:37:18 -0700 (PDT) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 7F0A328010A for ; Thu, 12 Oct 2017 09:37:15 +0200 (CEST) Received: by mx4.nic.fr (Postfix, from userid 500) id 7A381280BE3; Thu, 12 Oct 2017 09:37:15 +0200 (CEST) Received: from relay01.prive.nic.fr (unknown [10.1.50.11]) by mx4.nic.fr (Postfix) with ESMTP id 73A2C28010A for ; Thu, 12 Oct 2017 09:37:15 +0200 (CEST) Received: from b12.nic.fr (b12.users.prive.nic.fr [10.10.86.133]) by relay01.prive.nic.fr (Postfix) with ESMTP id 711B8663E080 for ; Thu, 12 Oct 2017 09:37:15 +0200 (CEST) Received: by b12.nic.fr (Postfix, from userid 1000) id 653AA40964; Thu, 12 Oct 2017 09:37:15 +0200 (CEST) Date: Thu, 12 Oct 2017 09:37:15 +0200 From: Stephane Bortzmeyer To: dnsop@ietf.org Message-ID: <20171012073715.l2youlg64ddrgtc5@nic.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: Debian GNU/Linux 9.1 X-Kernel: Linux 4.9.0-3-amd64 x86_64 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: NeoMutt/20170113 (1.7.2) X-Bogosity: No, tests=bogofilter, spamicity=0.000000, version=1.2.2 X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2017.10.12.73017 Archived-At: Subject: [DNSOP] DNS ideas for the IETF 100 Hackathon ? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Oct 2017 07:37:20 -0000 There are not a lot of DNS proposals for the next hackathon, in Singapore . Volunteers welcome! There are several drafts we discuss about which have no running code, this could be an opportunity to start it. From nobody Mon Oct 16 14:35:08 2017 Return-Path: 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 3907713247A for ; Mon, 16 Oct 2017 14:35:06 -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_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 zbXrU2K9U6U1 for ; Mon, 16 Oct 2017 14:35:03 -0700 (PDT) Received: from mail.hardakers.net (dawn.hardakers.net [IPv6:2001:470:1f00:187::1]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C71DC1331E7 for ; Mon, 16 Oct 2017 14:35:03 -0700 (PDT) Received: from localhost (50-1-20-198.dsl.static.fusionbroadband.com [50.1.20.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.hardakers.net (Postfix) with ESMTPSA id 1F8C022637; Mon, 16 Oct 2017 14:35:02 -0700 (PDT) From: Wes Hardaker To: Michael StJohns Cc: dnsop@ietf.org References: <840723c3-899a-f57b-caa1-48f14b3686e8@nthpermutation.com> Date: Mon, 16 Oct 2017 14:34:59 -0700 In-Reply-To: <840723c3-899a-f57b-caa1-48f14b3686e8@nthpermutation.com> (Michael StJohns's message of "Fri, 29 Sep 2017 14:49:06 -0400") Message-ID: User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [DNSOP] Responding to MSJ review of the previous rfc5011-security-considerations X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Oct 2017 21:35:06 -0000 Mike, Here's some responses to your comments from last time out. I'm only including the ones that needed a response or had an actionable item. 1.12 FIXED Section 4.1: This doesn't actually describe what's in 5011 - ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ specifically bullet 3 was modified to clarify your concerns, but isn't what was in 5011. You need to have both here. + Result: Intro paragraph added to note we're paraphrasing 5011 at a very high level only. + MSJ responds: Nope - not fixed.=C2=A0 You have "This document discusses the following scenario, which is one of many possible combinations of operations defined in Section 6 of RFC5011:" followed by "3. Begin to exclusively use recently published DNSKEYs to sign the appropriate resource records." 5011 does not define this as a possible operation. Instead: "This document discusses the following scenario which is a combination of the operations of sections 6.1 and 6.2 but ignores the guidance of the first paragraph of section 6 which recommends at least two keys per trust point at all times." + Result: changed the sentence in question to: This document discusses the following scenario, which the principle way RFC5011 is currently being used (even though Section 6 of RFC5011 suggests having a stand-by key available) 1.16 FIXED2 Section 5.1.1 - You're missing a *very* important point here - ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ that DNSKEY RRSets may be signed ahead of their use. You need to assume that once signed, they are available to be published - even by an attacker. So wherever you have "signature lifetime" you want something like "latest signature expiration of any DNSKEY RRSet not containing the new key" or at least you want to calculate the date/time value based on that. + Result: There are two issues here: 1. When we discuss the exact requirements for publication, we should be very very clear about the timing requirements. I agree. 2. We're trying to pass on the concept of the attack in this section, not necessarily a description that exactly covers all possibilities. So, though I'm all for making it as accurate as we can, I don't think we should make the example text so confusing to cover all the corner cases that no one can follow it. 3. It doesn't benefit an attacker to publish the signatures ahead of time. So you're right that anyone can publish new signatures, it really doesn't affect the timing required by the publisher to wait, which is the point of this draft. 4. The important take away I take from your text is that any delay between signing and publication will affect the length of time to wait, and I'm sure this is what you mean by needing to calculate via wall-clock (since everything should be based on sigexpiration). With this goal in mind, I've cleaned up the text a bit to make it a bit more clear. + MSJ Responds about point 3: The attacker doesn't publish the signatures - the publisher has signatures it won't be using....=C2=A0=C2=A0=C2=A0 the publisher signs = stuff way in advance of publication because getting people together and getting the HSM unlocked to sign things is a big huge expensive production. If the publisher doesn't think to modify its signing schedule in advance of a 5011 action, then your interval calculations are less then useless. + Fair point, thanks for clarifying. I've added the following text to 5.1.1: Note that for simplicity we assume the signer is not pre-signing and creating "valid in the future" signature sets that may be stolen and replayed even later. I've also changed the terminology of sigExpirationTime: sigExpirationTime: The amount of time remaining before any existing RRSIG's Signature Expiration time is reached. Note that for organizations pre-creating signatures this time may be fairly lengthy unless they can be significantly assured their signatures can not be replayed at a later date. sigExpirationTime will fundamentally be the RRSIG's Signature Expiration time minus the RRSIG's Signature Inception time when the signature is created. 1.17 NOTHINGTODO Section 5.1.1 doesn't actually apply if you use the 5011 r= ollover ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= ~~~~~~~~ approach (section 6.3). E.g. K_old (and any RRSets it signed) will be revoked the first time K_new is seen and K_standby is the signing key. At this point this reduces to a normal denial of service attack (where you prevent new data from being retrieved by the resolver). You'd need a different section to do that analysis. [And thinking about it, why is there any practical difference between this attack and a normal denial of service attack in the first place?] + Result: As we've both agreed in the past, the attack described in our 5.1.1 section only applies when you sign exclusively with a key that is too new. So, yes when you are using K_standby, the attack in question doesn't work. We're only describing the case where there either isn't a K_standby, or when K_standby is also newer than our 'waitTime' time. + And, yes by preventing a new key from being accepted as a trust anchor, this is a denial of service attack. Though one with potentially serious ramifications since it may require manual intervention on all the devices affected by it (unlikely a network-based DDoS attack, it doesn't stop when the attacker stops sending packets; this is long lived until the configuration is manually fixed). + MSJ responds: Section 5.1.1 does not apply to preventing a resolver from seeing a revocation.=C2=A0 The calculations are different.=C2=A0=C2=A0 You could= add a new section describing the revocation attack, but I think all you need to do is note that at the beginning of 5.1.1 and point to section 6.2 as the mitigation math. + Result: 5.1.1 does not now say that it applies to revocation and specifically discusses "The timing schedule listed below is based on a Trust Anchor Publisher publishing a new Key Signing Key (KSK), with the intent that it will later become a trust anchor." 1.19 FIXED Section 6 - the formulas are wrong. I also don't understand ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ where you got MAX(originalTTL/2,15 days) - there's no support for this in the text. You're misreading the commas. One of the terms in the outer max clause is "MAX(original TTL of K_old DNSKEY RRSet) / 2". This is slightly different than what is in the "1/2*OrigTTL" clause in 5011 itself. This is because if the publisher changes TTLs over the course of signing, you have to take the maximum value of any of them, not just the most recent. (though, to be super-accurate you need to do some math which we might want to describe about when a given TTL is published vs when Knew is introduced). Anyway, in the end, the formula in ours draft directly derives from what is in yours. We do take into account the possibility of multiple TTLs for a given signature set, which 5011 doesn't take into account (and to some extent, it's less important, but only further shows how much variance a resolver might have before accepting a new trust anchor). A clear piece of advice for an eventual BCP would be to not change TTLs at the same time you start any 5011 publication or revocation process. + MSJ responds: Note that in 6.1 you have 5 terms, but in the fully expanded equation in 6.1.6 you have 4.=C2=A0 You're missing the safetyMargin which you didn= 't actually define completely in section 6.1.5. + Result: I think you mean activeRefreshOffset, as safetyMargin was defin= ed (though we had to change it again due to the possibility of extremely short TTLs). But I have added the expansion of activeRefreshOffset to the equation; thanks for catching that. I haven't changed the definition since I don't see any missing pieces to it (or to the safetyMargin definition). --=20 Wes Hardaker USC/ISI From nobody Mon Oct 16 14:41:02 2017 Return-Path: X-Original-To: dnsop@ietf.org Delivered-To: dnsop@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BE9D12426E; Mon, 16 Oct 2017 14:41:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dnsop@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150819006058.427.2289841156754727879@ietfa.amsl.com> Date: Mon, 16 Oct 2017 14:41:00 -0700 Archived-At: Subject: [DNSOP] I-D Action: draft-ietf-dnsop-rfc5011-security-considerations-06.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Oct 2017 21:41:01 -0000 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 : Security Considerations for RFC5011 Publishers Authors : Wes Hardaker Warren Kumari Filename : draft-ietf-dnsop-rfc5011-security-considerations-06.txt Pages : 15 Date : 2017-10-16 Abstract: This document extends the RFC5011 rollover strategy with timing advice that must be followed in order to maintain security. Specifically, this document describes the math behind the minimum time-length that a DNS zone publisher must wait before signing exclusively with recently added DNSKEYs. It contains much math and complicated equations, but the summary is that the key rollover / revocation time is much longer than intuition would suggest. If you are not both publishing a DNSSEC trust anchor, and using RFC5011 to update that trust anchor, you probably don't need to read this document. This document also describes the minimum time-length that a DNS zone publisher must wait after publishing a revoked DNSKEY before assuming that all active RFC5011 resolvers should have seen the revocation- marked key and removed it from their list of trust anchors. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc5011-security-considerations/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dnsop-rfc5011-security-considerations-06 https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-rfc5011-security-considerations-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-rfc5011-security-considerations-06 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/ From nobody Mon Oct 16 15:29:43 2017 Return-Path: X-Original-To: dnsop@ietf.org Delivered-To: dnsop@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A3EF132055; Mon, 16 Oct 2017 15:29:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dnsop@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150819297595.21601.3511845605115441073@ietfa.amsl.com> Date: Mon, 16 Oct 2017 15:29:35 -0700 Archived-At: Subject: [DNSOP] I-D Action: draft-ietf-dnsop-extended-error-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Oct 2017 22:29:36 -0000 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 : Extended DNS Errors Authors : Warren Kumari Evan Hunt Roy Arends Wes Hardaker David C Lawrence Filename : draft-ietf-dnsop-extended-error-00.txt Pages : 9 Date : 2017-10-16 Abstract: This document defines an extensible method to return additional information about the cause of DNS errors. The primary use case is to extend SERVFAIL to provide additional information about the cause of DNS and DNSSEC failures. [ Open question: The document currently defines a registry for errors. It has also been suggested that the option also carry human readable (text) messages, to allow the server admin to provide additional debugging information (e.g: "example.com pointed their NS at us. No idea why...", "We don't provide recursive DNS to 192.0.2.0. Please stop asking...", "Have you tried Acme Anvil and DNS? We do DNS right..." (!). Please let us know if you think text is needed, or if a 16bit FCFS registry is expressive enough. ] [ Open question: This document discusses extended *errors*, but it has been suggested that this could be used to also annotate *non- error* messages. The authors do not think that this is a good idea, but could be persuaded otherwise. ] The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-extended-error/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dnsop-extended-error-00 https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-extended-error-00 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/ From nobody Mon Oct 16 15:39:15 2017 Return-Path: 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 ABD6B13457A for ; Mon, 16 Oct 2017 15:39:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.958 X-Spam-Level: X-Spam-Status: No, score=0.958 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RDNS_NONE=0.793, SPF_SOFTFAIL=0.665] autolearn=no 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 I2WZ-MMhD0gg for ; Mon, 16 Oct 2017 15:39:13 -0700 (PDT) Received: from mail.hardakers.net (unknown [168.150.236.43]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED34A133205 for ; Mon, 16 Oct 2017 15:39:12 -0700 (PDT) Received: from localhost (50-1-20-198.dsl.static.fusionbroadband.com [50.1.20.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.hardakers.net (Postfix) with ESMTPSA id 7ADD7226DB for ; Mon, 16 Oct 2017 15:39:12 -0700 (PDT) From: Wes Hardaker To: dnsop@ietf.org Date: Mon, 16 Oct 2017 15:39:11 -0700 Message-ID: User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: [DNSOP] draft-ietf-dnsop-extended-error code options X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Oct 2017 22:39:14 -0000 Folks, We were given feedback during the call for adoption to "use numeric range codes like those in HTTP". Following that, Warren and I sat down and came up with some possibilities and would like your feedback about which of these options you would prefer: 1. Individual codes assigned one at a time, per the existing doc 2. HTTP like: integer ranges where NNYY indicates the NN integer rcode and YY indicates the sub-code. Note that this needs a 32 bit error code field. 3. Use a 16 bit error code field, with the 16 bits differ per rcode. Thus, clients would need to use the combination of rcode and error code to determine the error. 4. 32 bit code field, repeating rcode from elsewhere in the packet Like #2, but copies the rcode directly into the error code header within the extended-error component of the packet. Redundant but clear that the entire 32 bits are needed. Thoughts? -- Wes Hardaker USC/ISI From nobody Wed Oct 18 04:17:00 2017 Return-Path: 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 EF14E1321B6 for ; Wed, 18 Oct 2017 04:16:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.799 X-Spam-Level: X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 u8BAG2btSGxI for ; Wed, 18 Oct 2017 04:16:58 -0700 (PDT) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (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 8752A13305E for ; Wed, 18 Oct 2017 04:16:58 -0700 (PDT) Received: by mail-wm0-x236.google.com with SMTP id b189so9259517wmd.4 for ; Wed, 18 Oct 2017 04:16:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=9tkU3W4mSj7YI16c/Z+K1HzH/ii2nL+7C6fcyVjdkMs=; b=nIUp9km62dmwlfXgkIXu+guW/XkAuaWLq8Fw9ipwbBt7QlCaPfAmXrJCK4keequQIE 7Ctae70KmDC5WkupfcHtyG6fhVMfMEEd9FAQvWZZ3Ub0xez4QAi/ejoVQESMsec3XR9K tumV+luHfW6v96Vx4jDLQfWLR+6ortDAr2tH12RjklCdlX9JAc4V1dTkp/EM/Zc0suxs jloS7Pb+nyABzEk9Z0Iyj45Y3EmnUcVWYewyhkQ900JEkwFJB6kStYLR6POL/MglOpni bRHnz6+Gzct6KsQT4A5V5hcfsww8CkNeLInHC48fOwXR/QYtVPoGuqXZooHCIzi45Ozq r+0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=9tkU3W4mSj7YI16c/Z+K1HzH/ii2nL+7C6fcyVjdkMs=; b=otXOF3O6SMyYVBBU7T6SvZ9VM774sZvyrXe7U94EVXoWXeqG2J5h5fZTNcv/cm2x0N yOlOnGmTg1+5n3JWXFyLkAA4347VhowplRp6hLfWdx5gudvUTuBa5XB48Trjy5zl49yK kEEOkGBJ4srZV6c4trTZ90SxlHimVYCxc1gbmXkMQQ9xZcTjyOK8xnhRQE5TVQ+jQxRB 3+plp8DtNKhOVhUK73zCQwJX5/3IVmjZL4i57LT8Qz1YQPuZCxUBxnJz5WaEQpII10Jj 7QOZdMcJ1l5TVRpHXot6UsQknyge0PzFCdlJn5oIO0m/xy+u/NtPHt5+EXo4efKEKIbB bzcw== X-Gm-Message-State: AMCzsaXzYD4sqePjbJ69pwpA3uW42oL3MedglNexzuHeNx27EXUWXSKb cUQKHb76gh4QP6zpmK+m1BlnBdC+V647h2UxSjfVlg== X-Google-Smtp-Source: ABhQp+TQlWe9leIUN3FTcpWg5hLeuJoo10zdlzR3hsIyc4AUaVxcn4bon7qvDpak/MYSoN/GJ5Is7/uPtQyAP0xgGDU= X-Received: by 10.28.47.69 with SMTP id v66mr6385853wmv.98.1508325416943; Wed, 18 Oct 2017 04:16:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.184.60 with HTTP; Wed, 18 Oct 2017 04:16:56 -0700 (PDT) From: tjw ietf Date: Wed, 18 Oct 2017 07:16:56 -0400 Message-ID: To: dnsop Content-Type: multipart/alternative; boundary="001a11423656aec2ad055bd06012" Archived-At: Subject: [DNSOP] Working Group Last Call - draft-ietf-dnsop-rfc5011-security-considerations X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Oct 2017 11:17:00 -0000 --001a11423656aec2ad055bd06012 Content-Type: text/plain; charset="UTF-8" >From talking with the authors and reading all the comments on the mailing lists, it appears that all outstanding issues have been addressed. This starts a Working Group Last Call for: draft-ietf-dnsop-rfc5011-security-considerations Current versions of the draft is available here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc5011-security-considerations/ Please review the draft and offer relevant comments. Also, if someone feels the document is *not* ready for publication, please speak out with your reasons. This starts a two week Working Group Last Call process, and ends on 1 November 2017 thanks tim --001a11423656aec2ad055bd06012 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

From talking with the authors and read= ing all the comments on the mailing lists, it appears that all outstanding = issues have been addressed.

This starts a Working = Group Last Call for: draft-ietf-dnsop-rfc5011-security-considerations
=

Current versions of the draft is available here:
<= div>

Please review the draft and offer relevant comments. Also, if someone feel= s the document is *not* ready for publication, please speak out with your r= easons.

This starts a two week Working Group Last = Call process, and ends on =C2=A01 November 2017

th= anks
tim
--001a11423656aec2ad055bd06012-- From nobody Wed Oct 18 04:49:51 2017 Return-Path: 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 6282E13305E for ; Wed, 18 Oct 2017 04:49:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.8 X-Spam-Level: X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 UeVGHTQ2LofX for ; Wed, 18 Oct 2017 04:49:49 -0700 (PDT) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (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 AD33A1332CD for ; Wed, 18 Oct 2017 04:49:48 -0700 (PDT) Received: by mail-wm0-x232.google.com with SMTP id i124so9432812wmf.3 for ; Wed, 18 Oct 2017 04:49:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=l2OOKEYowyKhaPiE+ajKRG8yL8msGlTumLjbIEt2bwU=; b=kGeSXBI3IpTOlM6v0ta9yn8kiYX+7Ch1Q4h4aN3kZ+8f81UMI77q4bcACbnLNAD6UB hvZ811lA3CWeqR18p8rqHfZKL5Z8Migvg/qW2vgZwOeK6zY4JF+q0bWR9IbcxgdQAkbg D8j7VIcLOJKgXWVleIjKbd1zZEueeOpStlftBweSjHfNK/inclC+4v2c+fAi5eS4u4mj TVNc5i/McinnuJJ2N8nszkUW9AQvwis3eB3CuwlRqJ0gnEV/BxgTEs4W8kMVmRoMNklz fCYB/cNSAco+nnbTna8H9ICqx+LVKZ6wHwSWPgQ+pbsCkSP33bNTvhf6AdPKq6tDgCPO AVSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=l2OOKEYowyKhaPiE+ajKRG8yL8msGlTumLjbIEt2bwU=; b=QRrMbNR4bjspX98Pxs+lMwqP+TPRH57tTKwkmMoBy6p/BMhM/2XvPV6psrkNuYVPqW mzscVXdMS/gQ6bOGM7LHqUdMpN0RsFGpF8dD49HqHxGvDd0cyDha9Lk5xAfnAgLs9ysJ umgKcJe1Vlbqgm5WtJwaumRBD/Xpl8wf9M8/IvixsU5opexb9obHs4Zzv59s1X7nbIbu dtSNgev5uDxIIpT5thFkSzo2RJ48JlLJiQYAkWwE7DMAFurNX9my3snF7uPc0lVZ2Jf4 jPGnD/HHqfNoAYl3UMKeiEwjP9mWr2U3UHYmiFeK1qaAmyUEADMIWWIrmLMMEzQfzMCJ 0fkA== X-Gm-Message-State: AMCzsaVMJ13sqzNofzNadzxnOD95RgZwjJFyva4bLw8agOHysrWhNpFT 9n2bqTWqZh9O+aTuxFCuRf4oRB7E/SkiH+OZAUk= X-Google-Smtp-Source: ABhQp+R8Kmg6bNo1NC5DLOYjgW0OG0Hd0Ah/KXjR4qj2LrsSurrFfpb5X5fOlZmbLmA3GLH/ekDD6KsUbU0NwGJW1Z0= X-Received: by 10.28.47.69 with SMTP id v66mr6469725wmv.98.1508327387150; Wed, 18 Oct 2017 04:49:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.184.60 with HTTP; Wed, 18 Oct 2017 04:49:46 -0700 (PDT) From: tjw ietf Date: Wed, 18 Oct 2017 07:49:46 -0400 Message-ID: To: dnsop Content-Type: multipart/alternative; boundary="001a114236561dbed4055bd0d61a" Archived-At: Subject: [DNSOP] IETF 100 Meeting slots X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Oct 2017 11:49:50 -0000 --001a114236561dbed4055bd0d61a Content-Type: text/plain; charset="UTF-8" All We've been given two slots for IETF100, and currently more time then we requested. Our slots are: Monday 09:30 - 12:00 Thursday 15:50 - 17:50 We'll want to start thinking of agenda items, keeping in mind we have some curent drafts to get updated. tim --001a114236561dbed4055bd0d61a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

All

We've been given= two slots for IETF100, and currently more time then we requested.=C2=A0 Ou= r slots are:

Monday 09:30 - 12:00
Thursd= ay 15:50 - 17:50

We'll want to start thinking = of agenda items, keeping in mind we have some curent drafts to get updated.=

tim
=C2=A0
--001a114236561dbed4055bd0d61a-- From nobody Wed Oct 18 04:51:26 2017 Return-Path: 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 5D51C13305E for ; Wed, 18 Oct 2017 04:51:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 b92ttwH6_WS1 for ; Wed, 18 Oct 2017 04:51:23 -0700 (PDT) Received: from mail-wr0-x233.google.com (mail-wr0-x233.google.com [IPv6:2a00:1450:400c:c0c::233]) (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 752411342D1 for ; Wed, 18 Oct 2017 04:51:22 -0700 (PDT) Received: by mail-wr0-x233.google.com with SMTP id z99so2252796wrc.12 for ; Wed, 18 Oct 2017 04:51:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GH3B8BcnmoS1fQTCDx+5XCwroyK/b1u2FVTHzorYfV0=; b=k/PTVKWReiqj6RiOd+rYJ/Nb+0YKb228QvefJwdlG5IjzOoc82OtaF6y4j/zu7WNH8 Uogm/9ZHRU8Kjk3/7Aie199v1fHel1zmtFjHbWi+wYEQlJVkNn0UO8MQ5uxRj08VdG8+ hsc8IvxVGPv2k5nm39ohqr8Qcc1X0u3nQ5OdR4vh/N6FxdIX0xezOnT2udgZgb+noExI njL0eKGNog/fkd26r14CJRbl3GswdactaY76ZhLUL3FTXF6z3SCF/dE6+WvhygF/w6Qc DBWsfRU7idUUbCIgl+X7DriVtXLMIhJD70oKFuUNQmG6X4Dw4hVjKpHoUOk6BUQf2xGP 4mWw== 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; bh=GH3B8BcnmoS1fQTCDx+5XCwroyK/b1u2FVTHzorYfV0=; b=YdTt48giEYp1hkTVVsIxTV6aozkuGs3ZsFgwMxoprOBqfAdz+/rtRQUEC/DzQVbsQN 0JPxC1lqq8VGA7rYW0lt9qQUsMej+Bc8gKiseY2iY3tiJG2snneQk4E/eimCZiAazJoz QTsvtawSy2OgtJtOnUwASSDRTaFt75GL5sSSnXSMuxFc/1pGjLGQIT5kUVlUZE+n/srf djDwSB6DRUQUFzT2vJNXaU5Ru/OGJ0DJ/PtY+TebFSFxKTMWkEKWRSz7u9ss48l9bxVC viUR1WbTvuSiHVMjJTKqCfCR8ZoLdl4QJbeypWW+ZXdKGpMcfAXLa7OOBoFuWXXj5uQU hSow== X-Gm-Message-State: AMCzsaWNmbhzT2YhnbJ1HLogYU8HzsVBoBJjMLVgjCoAZdYNro4W3pBZ Y2AbpUhdrk3cyygSUgKkvCMTth0aG/9SlT8JopA= X-Google-Smtp-Source: ABhQp+R47h8ZPkoA8X2g95SGgoamOrIoTqQ1Mu7imeeEQQSH/kr1Rk+s2RpGehDDB/xFDn3ZI4FWsJ57dvxH9gn5MnM= X-Received: by 10.223.133.99 with SMTP id 90mr6545838wrh.101.1508327481016; Wed, 18 Oct 2017 04:51:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.184.60 with HTTP; Wed, 18 Oct 2017 04:51:20 -0700 (PDT) In-Reply-To: References: <20170907154234.3z2zbju2sciiy7wr@nic.fr> <8295055.TIQDDEhZcU@localhost.localdomain> <20170907221241.GA1031@puck.nether.net> <20170908020710.0170284A3195@rock.dv.isc.org> From: tjw ietf Date: Wed, 18 Oct 2017 07:51:20 -0400 Message-ID: To: =?UTF-8?Q?Marek_Vavru=C5=A1a?= Cc: Bob Harold , IETF DNSOP WG Content-Type: multipart/alternative; boundary="94eb2c0d293eb60532055bd0db2a" Archived-At: Subject: Re: [DNSOP] DNSOP Call for Adoption - draft-tale-dnsop-serve-stale X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Oct 2017 11:51:25 -0000 --94eb2c0d293eb60532055bd0db2a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The adoption period finished sone time ago with strong consensus to adopt. Authors will want to upload their latest version. tim On Mon, Sep 11, 2017 at 2:52 PM, Marek Vavru=C5=A1a wrote: > I support the adoption of this document. Was there a discussion of any > actual downsides besides "I'd like to know if it's stale" and > monitoring? > > On Mon, Sep 11, 2017 at 11:11 AM, Bob Harold wrote: > > > > On Thu, Sep 7, 2017 at 10:07 PM, Mark Andrews wrote: > >> > >> > >> Part of the problem is that we have one TTL value for both freshness > >> and don't use beyond. > >> > >> This is fixable. It is possible to specify two timer values. It > >> does require adding signaling between recursive servers and > >> authoritative servers, on zone transfers and update requests. > >> > >> You basically add a additional timer field to every record immediately > >> after the TTL field. This is only returned if the client has > >> signalled support for the extended field, I suggest using the last > >> DNS header bit for this as you can determine how you will parse the > >> response base on whether the bit is set in the response or not. > >> This field is used to expire records from the cache and its value > >> is set to the TTL field if the server has learnt the record from > >> server that doesn't support the extension. > >> > >> The existing TTL field is used for freshness checking. When a query > >> comes in after that value has expired a freshness check is performed > >> similar to the existing prefetches that happen today. A TTL of 1 > >> is returned unless the original TTL was 0 in which case 0 is returned. > >> > >> New client - new recursive server - new authservers > >> > >> example.com. 300 86400 IN A 1.2.3.4 > >> > >> +300 seconds > >> > >> example.com. 1 86100 IN A 1.2.3.4 > >> (background query is in process) > >> > >> Old client - new recursive server - new authservers > >> > >> example.com. 300 IN A 1.2.3.4 > >> > >> +300 seconds > >> > >> example.com. 1 IN A 1.2.3.4 > >> (background query is in process) > >> > >> New client - new recusive server - old auth servers > >> > >> example.com. 300 300 IN A 1.2.3.4 > >> > >> +300 seconds > >> (record has expired from cache, > >> new query is performed) > >> > >> example.com. 300 300 IN A 1.2.3.4 > >> > >> For UPDATE a replacement opcode would be cleanest way to signal the > >> new format is being used. NOTIMP should be returned by servers > >> that don't support the new opcode. > >> > >> There will be a few broken servers that just echo back the new > >> header bit. > >> > >> This way the authoritative servers still control how long records > >> are stored for. Dead servers will get a little bit of traffic until > >> the the refresh completes. If the authorative servers are under > >> attack the clients still see a answer. > >> > >> The alternative is to perform the refresh query and if it fails to > >> complete within X milliseconds return the cached data rather than > >> returning the cached data and doing the refresh in the background. > >> > >> Mark > >> > >> -- > >> Mark Andrews, ISC > >> 1 Seymour St., Dundas Valley, NSW 2117, Australia > >> PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > > > > > > While I like the idea of a "don't use beyond" timer, I think it will b= e > a > > very long time before it is widely deployed (and actually configured by > zone > > owners), and therefore won't solve our immediate need. It would be > great if > > clients could opt-in, but again I don't see that happening anytime > soon. So > > I would start with resolver-operators deciding what seems best for thei= r > > clients (which is hat is happening whether we like it or not). Adding > > client opt-out/opt-in would be good. Signalling to say that a respons= e > is > > stale would be good. Adding the second timer (both per-RR and as a zon= e > > default value, like TTL is handled) would be good. > > > > On a related note - the SOA "expire" timer tells a slave how long to ke= ep > > serving "stale" zone data when the master cannot be reached. Would tha= t > be > > a reasonable default value for how long a resolver should serve "stale" > data > > when the authoritative servers cannot be reached? (Currently I think > most > > people set a very high value compared to the TTL.) > > > > -- > > Bob Harold > > > > > > > > _______________________________________________ > > DNSOP mailing list > > DNSOP@ietf.org > > https://www.ietf.org/mailman/listinfo/dnsop > > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > --94eb2c0d293eb60532055bd0db2a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The adoption period finished sone time ago with strong con= sensus to adopt. =C2=A0 Authors will want to upload their latest version.
tim

=
On Mon, Sep 11, 2017 at 2:52 PM, Marek Vavru= =C5=A1a <mvavrusa@cloudflare.com> wrote:
I support the adoption of this document. Was there a d= iscussion of any
actual downsides besides "I'd like to know if it's stale"= and
monitoring?

On Mon, Sep 11, 2017 at 11:11 AM, Bob Harold <rharolde@umich.edu> wrote:
>
> On Thu, Sep 7, 2017 at 10:07 PM, Mark Andrews <marka@isc.org> wrote:
>>
>>
>> Part of the problem is that we have one TTL value for both freshne= ss
>> and don't use beyond.
>>
>> This is fixable.=C2=A0 It is possible to specify two timer values.= =C2=A0 It
>> does require adding signaling between recursive servers and
>> authoritative servers, on zone transfers and update requests.
>>
>> You basically add a additional timer field to every record immedia= tely
>> after the TTL field.=C2=A0 This is only returned if the client has=
>> signalled support for the extended field, I suggest using the last=
>> DNS header bit for this as you can determine how you will parse th= e
>> response base on whether the bit is set in the response or not. >> This field is used to expire records from the cache and its value<= br> >> is set to the TTL field if the server has learnt the record from >> server that doesn't support the extension.
>>
>> The existing TTL field is used for freshness checking.=C2=A0 When = a query
>> comes in after that value has expired a freshness check is perform= ed
>> similar to the existing prefetches that happen today.=C2=A0 A TTL = of 1
>> is returned unless the original TTL was 0 in which case 0 is retur= ned.
>>
>> New client - new recursive server - new authservers
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0example.com. 300 86400 IN A 1.2.3.4<= br> >>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+300 = seconds
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0example.com. 1 86100 IN A 1.2.3.4 >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (background query is in process)=
>>
>> Old client - new recursive server - new authservers
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0example.com. 300 IN A 1.2.3.4
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+300 = seconds
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0example.com. 1 IN A 1.2.3.4
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (background query is in process)=
>>
>> New client - new recusive server - old auth servers
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0example.com. 300 300 IN A 1.2.3.4 >>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+300 = seconds
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (record has expired from cache,<= br> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0new query is performed) >>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0example.com. 300 300 IN A 1.2.3.4 >>
>> For UPDATE a replacement opcode would be cleanest way to signal th= e
>> new format is being used.=C2=A0 NOTIMP should be returned by serve= rs
>> that don't support the new opcode.
>>
>> There will be a few broken servers that just echo back the new
>> header bit.
>>
>> This way the authoritative servers still control how long records<= br> >> are stored for.=C2=A0 Dead servers will get a little bit of traffi= c until
>> the the refresh completes.=C2=A0 If the authorative servers are un= der
>> attack the clients still see a answer.
>>
>> The alternative is to perform the refresh query and if it fails to=
>> complete within X milliseconds return the cached data rather than<= br> >> returning the cached data and doing the refresh in the background.=
>>
>> Mark
>>
>> --
>> Mark Andrews, ISC
>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
>> PHONE: +61 2 9871 4742=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0INTERNET: marka@isc.or= g
>
>
> While I like the idea of a=C2=A0 "don't use beyond" time= r, I think it will be a
> very long time before it is widely deployed (and actually configured b= y zone
> owners), and therefore won't solve our immediate need.=C2=A0 It wo= uld be great if
> clients could opt-in, but again I don't see that happening anytime= soon.=C2=A0 So
> I would start with resolver-operators deciding what seems best for the= ir
> clients (which is hat is happening whether we like it or not).=C2=A0 A= dding
> client opt-out/opt-in would be good.=C2=A0 =C2=A0Signalling to say tha= t a response is
> stale would be good.=C2=A0 Adding the second timer (both per-RR and as= a zone
> default value, like TTL is handled) would be good.
>
> On a related note - the SOA "expire" timer tells a slave how= long to keep
> serving "stale" zone data when the master cannot be reached.= =C2=A0 Would that be
> a reasonable default value for how long a resolver should serve "= stale" data
> when the authoritative servers cannot be reached?=C2=A0 =C2=A0(Current= ly I think most
> people set a very high value compared to the TTL.)
>
> --
> Bob Harold
>
>
>
> __________________= _____________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop=
>

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

--94eb2c0d293eb60532055bd0db2a-- From nobody Wed Oct 18 06:13:50 2017 Return-Path: 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 0551A1332CA for ; Wed, 18 Oct 2017 06:13:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 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_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.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 555ZYQY95h7Y for ; Wed, 18 Oct 2017 06:13:47 -0700 (PDT) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (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 96296132143 for ; Wed, 18 Oct 2017 06:13:47 -0700 (PDT) Received: by mail-qk0-x22b.google.com with SMTP id x82so6120567qkb.12 for ; Wed, 18 Oct 2017 06:13:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=CoLO0U+QapbX0mnVKt18Dc+hAM7j/pdhQtdv5Ov8uD0=; b=mkffN1WMRpKaIaMuHMQlOLMCJifqMlFuMJKi8fhOdtQFtwWxTzK8G3Cbbpm8Nh5XfP tmB5/TcrlhLKBO8nS0Njc/H2AK9aRTw1gReOU96hZ/UsdkrAsgopfEFVddl1HUzyrZ2A X1ao8pYFRJP3yg4vF9U6lTENp1ZQ7E8xpxV94iwIsDCyC5lAM0CtPnCHYfejoPxyjjmn mPkt3NXsDAcRBU7DOY6Qo/gvJHlT4fQlgJeaEw0C1jLRL93YQfUtedpmGWZmei8kvZru 2lSRLM0o88J7n47UrpoTG1wfuENQGdFg/4wV75VjH2z2UkBkXK0ZMIfGu/foq0rqXIFL ufIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=CoLO0U+QapbX0mnVKt18Dc+hAM7j/pdhQtdv5Ov8uD0=; b=AEER58tZlfRMhLNByCIhT3l6sgy+GmgE825N93ddFnNezKElkKgqTXxnQzYreDKbdp waMk4m++Huv1RUSZHNT6iMMLIMk5DNUDf5K98BLuQli8Ax1BZ+JhsbbuwtXffJwdAZAq Q1KHYel1Fi6AlqDScYQQYpSR8i9L65amj87YpUIgcMIhRR6HoHJ8nvnC3E76FMl0gMZv iYghBLopIYYPdPz6Yfvu4M0JrnJy5OMl81OPh8xRx/AwOZidI9jJo+S0IyAp4+MiCpBO QsrxgZ7cx6Xi4XWBx+Kroe2WHiy4MfBiIIOun4M+UO5xogd53st6JkSd3UVWwvRq0IE8 xNQw== X-Gm-Message-State: AMCzsaX0OSMJbV/K8mQeFQLJ+EAd+4D0cHhv2AqY5cUcw2pTGj8QzMdo iUQg3yrmNKwmxw9gF9ykqkHPhXXY X-Google-Smtp-Source: ABhQp+QSOiKUDYRg5QQs7T6kpHzHSqRv3jAe83eN2fegk0kInNJlGDDvYVS+lROagVRUx2HfX1cclw== X-Received: by 10.55.95.133 with SMTP id t127mr2220434qkb.24.1508332426287; Wed, 18 Oct 2017 06:13:46 -0700 (PDT) Received: from [192.168.1.114] (c-69-140-114-191.hsd1.md.comcast.net. [69.140.114.191]) by smtp.gmail.com with ESMTPSA id z207sm677490qka.52.2017.10.18.06.13.44 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 18 Oct 2017 06:13:44 -0700 (PDT) To: dnsop@ietf.org References: From: Michael StJohns Message-ID: <4571d5a7-8b56-452d-29ef-2e06ceeabeba@nthpermutation.com> Date: Wed, 18 Oct 2017 09:13:42 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------2ECC3D048354DC0B463939FC" Content-Language: en-US Archived-At: Subject: Re: [DNSOP] Working Group Last Call - draft-ietf-dnsop-rfc5011-security-considerations X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Oct 2017 13:13:49 -0000 This is a multi-part message in MIME format. --------------2ECC3D048354DC0B463939FC Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 10/18/2017 7:16 AM, tjw ietf wrote: > > From talking with the authors and reading all the comments on the > mailing lists, it appears that all outstanding issues have been addressed. Nice try - but no.  I got Wes' responses yesterday and haven't yet re-read the document (which was published today with the changes). Given the responses I'm pretty sure we've still got problems.  So... NO. Mike > > This starts a Working Group Last Call for: > draft-ietf-dnsop-rfc5011-security-considerations > > Current versions of the draft is available here: > > https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc5011-security-considerations/ > > Please review the draft and offer relevant comments. Also, if someone > feels the document is *not* ready for publication, please speak out > with your reasons. > > This starts a two week Working Group Last Call process, and ends on  1 > November 2017 > > thanks > tim > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop --------------2ECC3D048354DC0B463939FC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 10/18/2017 7:16 AM, tjw ietf wrote:

From talking with the authors and reading all the comments on the mailing lists, it appears that all outstanding issues have been addressed.

Nice try - but no.  I got Wes' responses yesterday and haven't yet re-read the document (which was published today with the changes).   Given the responses I'm pretty sure we've still got problems.  So... NO. 

Mike


This starts a Working Group Last Call for: draft-ietf-dnsop-rfc5011-security-considerations

Current versions of the draft is available here:


Please review the draft and offer relevant comments. Also, if someone feels the document is *not* ready for publication, please speak out with your reasons.

This starts a two week Working Group Last Call process, and ends on  1 November 2017

thanks
tim


_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


--------------2ECC3D048354DC0B463939FC-- From nobody Wed Oct 18 06:58:27 2017 Return-Path: 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 ABC63133039 for ; Wed, 18 Oct 2017 06:58:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.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 jwmwyGh-GuvD for ; Wed, 18 Oct 2017 06:58:23 -0700 (PDT) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (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 9484D132D44 for ; Wed, 18 Oct 2017 06:58:23 -0700 (PDT) Received: by mail-qt0-x22b.google.com with SMTP id z50so10311052qtj.4 for ; Wed, 18 Oct 2017 06:58:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=ze2Fq3DyYh96SCEOgXZr5PDIWRjEzJvpYhHGXzLmM2k=; b=u06qIiFD7Ye8sJPXwjDs9SkR5O+8Tw3IQl0Maf89FP7+xZmX1xDD0pKtJtfIHNmvnq wIdIMrZ8kngB/Anc+6QwOCfh4H5o3Sjd1gvMJzIFM6Uz8xzb6ogmWsCkNhn7h1pIYAIv pNEDoVJbpQMpdVTQktOc68tHtLq8jYttIyIf6YvDMTSSLNzTHvPjRrnqqQQUbuob1UVE bO4+Bfp1k7pubhNwQeDxDfcF3Lf9qrC17Ze4ncIy68UIERGxZDQQr0ofCaUY25eyAmiG rH6dumeJVGe9YvKAJ5TUxvunsgs4f80N0pPoY+l7OoD795uJxmD6JnV3fit4s/EY4/dT wQqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=ze2Fq3DyYh96SCEOgXZr5PDIWRjEzJvpYhHGXzLmM2k=; b=DGXDHYurFUFzJS6pVQtkGJmbm3jcBWm0ng7dt96UnjID2+xcSrRxPXa4lBs5qaBVHZ QVZXlXIKi6+cVj2tIMkL9UWXqItclZU6CzupD0357o7rs3773VoURVG24AYD/WpPSiX2 ZsgdPOcYdGRm7/lJICognthnwf+2QCoWyjXkXtZQu/UXmUYIhJbzM0GLNrUMbHm+Qynr wkCL4tf/QwSfTE9FwlyNgVH9iDfiTdJP5G0zFDYxWTO8F/yLfFIfYoy1+LMKvccFiRmH g9jCIip6V8NCiO3US94s/kG8azA/S4uPJwcMZlH3cqeljO5+dDecbCcQcd1gxGVU82XV qaog== X-Gm-Message-State: AMCzsaXMNeP0wbdspbkliw+M5BlbbDk/j+OW32YJY0s/AxlIOoGx5bk9 4YIZYaKr+l8fu+f8g0lw6trB1Th3 X-Google-Smtp-Source: ABhQp+Q97WafnGxo8m40gPmgkfYwklVQzhvT+qyF0yIGYw+N4j1eNEeE+QdTEdjGoSTUW9Mg3SE71A== X-Received: by 10.200.4.130 with SMTP id s2mr3092232qtg.338.1508335102044; Wed, 18 Oct 2017 06:58:22 -0700 (PDT) Received: from [192.168.1.114] (c-69-140-114-191.hsd1.md.comcast.net. [69.140.114.191]) by smtp.gmail.com with ESMTPSA id m28sm8070308qtb.55.2017.10.18.06.58.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 18 Oct 2017 06:58:20 -0700 (PDT) To: Wes Hardaker Cc: dnsop@ietf.org References: <840723c3-899a-f57b-caa1-48f14b3686e8@nthpermutation.com> From: Michael StJohns Message-ID: <52a489db-11fe-4142-2135-c363f171dc47@nthpermutation.com> Date: Wed, 18 Oct 2017 09:58:18 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [DNSOP] Responding to MSJ review of the previous rfc5011-security-considerations X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Oct 2017 13:58:26 -0000 Top posting because of the "last call" note. Still not ready. You said in 4.1: which the principle way RFC5011 is currently being used (even though Section 6 of RFC5011 suggests having a stand-by key available) And then in  T-1 you say: Note that for simplicity we assume the signer is not pre-signing and creating "valid in the future" signature sets that may be stolen and replayed even later. But - "the way RFC5011 is currently being used" is with "pre-signing" and "valid in the future" signature sets.   So you want to have your cake and eat it too.     You're now both not dealing with the way 5011 said you should do things nor are you dealing with the way that the root actually does things. All of this can be fixed by going to a wall clock model which is the way the publisher works vs the interval model which is only appropriate for the client. You continue to have a problem with "sigExpirationTime". > The amount of time remaining before any existing > RRSIG's Signature Expiration time is reached. Note that for > organizations pre-creating signatures this time may be fairly > lengthy unless they can be significantly assured their signatures > can not be replayed at a later date. the problem is:  Amount of time measured from when?     (and it should be "latest RRSIG's Signature Expiration time is reached" at least. > sigExpirationTime will > fundamentally be the RRSIG's Signature Expiration time minus the > RRSIG's Signature Inception time when the signature is created. This is no longer fundamentally the difference between one RRSig inception and expiration time.  You can't even describe it as the difference between the earliest inception and latest expiration because that changes as the earlier RRSigs expire.   The only fixed value (and easiest value) is "latest expiration date". You could say "latest expiration date - now" which then gets added to "now" to get back to lastest expiration date..... Please, please please just move to a wall clock value based on the latest expiration date plus appropriate intervals.  All the minor twiddles you've done to try to avoid doing this have made the document less clear. NOT READY FOR LAST CALL. More below. On 10/16/2017 5:34 PM, Wes Hardaker wrote: > > Mike, > > Here's some responses to your comments from last time out. I'm > only including the ones that needed a response or had an actionable > item. > > > 1.12 FIXED Section 4.1: This doesn't actually describe what's in 5011 - > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > specifically bullet 3 was modified to clarify your concerns, but isn't > what was in 5011. You need to have both here. > > + Result: Intro paragraph added to note we're paraphrasing 5011 at a > very high level only. > > + MSJ responds: > > Nope - not fixed.  You have "This document discusses the following > scenario, which is one of many possible combinations of operations > defined in Section 6 of RFC5011:" followed by "3. Begin to > exclusively use recently published DNSKEYs to sign the appropriate > resource records." > > 5011 does not define this as a possible operation. > > Instead: "This document discusses the following scenario which is a > combination of the operations of sections 6.1 and 6.2 but ignores > the guidance of the first paragraph of section 6 which recommends at > least two keys per trust point at all times." > > + Result: changed the sentence in question to: > > This document discusses the following scenario, which the principle > way RFC5011 is currently being used (even though Section 6 of > RFC5011 suggests having a stand-by key available) OK.  Not perfect but works. > > > 1.16 FIXED2 Section 5.1.1 - You're missing a *very* important point here - > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > that DNSKEY RRSets may be signed ahead of their use. You need to > assume that once signed, they are available to be published - even by > an attacker. So wherever you have "signature lifetime" you want > something like "latest signature expiration of any DNSKEY RRSet not > containing the new key" or at least you want to calculate the > date/time value based on that. > > + Result: There are two issues here: > 1. When we discuss the exact requirements for publication, we should > be very very clear about the timing requirements. I agree. > 2. We're trying to pass on the concept of the attack in this > section, not necessarily a description that exactly covers all > possibilities. So, though I'm all for making it as accurate as > we can, I don't think we should make the example text so > confusing to cover all the corner cases that no one can follow > it. No.  You floated this document as being an attack on 5011 updates. Your comments have been that we should concentrate on how 5011 is actually used by the root.  So then you need to have an example that actually meshes with how the root does things.  The root presigns data.  The example should deal with that. > 3. It doesn't benefit an attacker to publish the signatures ahead of > time. So you're right that anyone can publish new signatures, it > really doesn't affect the timing required by the publisher to > wait, which is the point of this draft. > 4. The important take away I take from your text is that any delay > between signing and publication will affect the length of time to > wait, and I'm sure this is what you mean by needing to calculate > via wall-clock (since everything should be based on > sigexpiration). > > With this goal in mind, I've cleaned up the text a bit to make it > a bit more clear. > > + MSJ Responds about point 3: > > The attacker doesn't publish the signatures - the publisher has > signatures it won't be using....    the publisher signs stuff way in > advance of publication because getting people together and getting > the HSM unlocked to sign things is a big huge expensive > production. If the publisher doesn't think to modify its signing > schedule in advance of a 5011 action, then your interval > calculations are less then useless. > > + Fair point, thanks for clarifying. I've added the following text to > 5.1.1: > > Note that for simplicity we assume the signer is not pre-signing and > creating "valid in the future" signature sets that may be stolen and > replayed even later. > > I've also changed the terminology of sigExpirationTime: > > sigExpirationTime: The amount of time remaining before any existing > RRSIG's Signature Expiration time is reached. Note that for > organizations pre-creating signatures this time may be fairly > lengthy unless they can be significantly assured their signatures > can not be replayed at a later date. sigExpirationTime will > fundamentally be the RRSIG's Signature Expiration time minus the > RRSIG's Signature Inception time when the signature is created. See my top posting. > > > 1.17 NOTHINGTODO Section 5.1.1 doesn't actually apply if you use the 5011 rollover > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > approach (section 6.3). E.g. K_old (and any RRSets it signed) will be > revoked the first time K_new is seen and K_standby is the signing key. > At this point this reduces to a normal denial of service attack (where > you prevent new data from being retrieved by the resolver). You'd > need a different section to do that analysis. [And thinking about it, > why is there any practical difference between this attack and a normal > denial of service attack in the first place?] > > + Result: As we've both agreed in the past, the attack described in > our 5.1.1 section only applies when you sign exclusively with a key > that is too new. So, yes when you are using K_standby, the attack > in question doesn't work. We're only describing the case where > there either isn't a K_standby, or when K_standby is also newer than > our 'waitTime' time. > > + And, yes by preventing a new key from being accepted as a trust > anchor, this is a denial of service attack. Though one with > potentially serious ramifications since it may require manual > intervention on all the devices affected by it (unlikely a > network-based DDoS attack, it doesn't stop when the attacker stops > sending packets; this is long lived until the configuration is > manually fixed). > > + MSJ responds: > > Section 5.1.1 does not apply to preventing a resolver from seeing a > revocation.  The calculations are different.   You could add a new > section describing the revocation attack, but I think all you need > to do is note that at the beginning of 5.1.1 and point to section > 6.2 as the mitigation math. > > + Result: 5.1.1 does not now say that it applies to revocation and > specifically discusses "The timing schedule listed below is based on > a Trust Anchor Publisher publishing a new Key Signing Key (KSK), > with the intent that it will later become a trust anchor." OK > > > 1.19 FIXED Section 6 - the formulas are wrong. I also don't understand > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > where you got MAX(originalTTL/2,15 days) - there's no support for this > in the text. > > You're misreading the commas. One of the terms in the outer max > clause is "MAX(original TTL of K_old DNSKEY RRSet) / 2". This is > slightly different than what is in the "1/2*OrigTTL" clause in 5011 > itself. This is because if the publisher changes TTLs over the course > of signing, you have to take the maximum value of any of them, not > just the most recent. (though, to be super-accurate you need to do > some math which we might want to describe about when a given TTL is > published vs when Knew is introduced). > > Anyway, in the end, the formula in ours draft directly derives from > what is in yours. We do take into account the possibility of multiple > TTLs for a given signature set, which 5011 doesn't take into account > (and to some extent, it's less important, but only further shows how > much variance a resolver might have before accepting a new trust > anchor). > > A clear piece of advice for an eventual BCP would be to not change > TTLs at the same time you start any 5011 publication or revocation > process. > > + MSJ responds: > > Note that in 6.1 you have 5 terms, but in the fully expanded equation > in 6.1.6 you have 4.  You're missing the safetyMargin which you didn't > actually define completely in section 6.1.5. > > + Result: I think you mean activeRefreshOffset, as safetyMargin was defined > (though we had to change it again due to the possibility of > extremely short TTLs). But I have added the expansion of > activeRefreshOffset to the equation; thanks for catching that. I > haven't changed the definition since I don't see any missing pieces > to it (or to the safetyMargin definition). > You've got a new term "(addHoldDownTime % activeRefresh)"  that you don't appear to have text to cover the "why".   It's not "safetyMargin" as you expanded the last term to match that definition.  Is that activeRefreshOffset?   Doesn't match the text at the beginning of 6.1.6 so I'm confused. Mike From nobody Wed Oct 18 14:21:22 2017 Return-Path: X-Original-To: dnsop@ietf.org Delivered-To: dnsop@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 902B91321C9; Wed, 18 Oct 2017 14:21:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dnsop@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150836168054.12436.11427606041339518375@ietfa.amsl.com> Date: Wed, 18 Oct 2017 14:21:20 -0700 Archived-At: Subject: [DNSOP] I-D Action: draft-ietf-dnsop-rfc5011-security-considerations-07.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Oct 2017 21:21:20 -0000 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 : Security Considerations for RFC5011 Publishers Authors : Wes Hardaker Warren Kumari Filename : draft-ietf-dnsop-rfc5011-security-considerations-07.txt Pages : 15 Date : 2017-10-18 Abstract: This document extends the RFC5011 rollover strategy with timing advice that must be followed in order to maintain security. Specifically, this document describes the math behind the minimum time-length that a DNS zone publisher must wait before signing exclusively with recently added DNSKEYs. It contains much math and complicated equations, but the summary is that the key rollover / revocation time is much longer than intuition would suggest. If you are not both publishing a DNSSEC trust anchor, and using RFC5011 to update that trust anchor, you probably don't need to read this document. This document also describes the minimum time-length that a DNS zone publisher must wait after publishing a revoked DNSKEY before assuming that all active RFC5011 resolvers should have seen the revocation- marked key and removed it from their list of trust anchors. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc5011-security-considerations/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dnsop-rfc5011-security-considerations-07 https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-rfc5011-security-considerations-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-rfc5011-security-considerations-07 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/ From nobody Wed Oct 18 14:21:46 2017 Return-Path: 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 5B76E13308D for ; Wed, 18 Oct 2017 14:21:45 -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_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 th2ZjwrT93tl for ; Wed, 18 Oct 2017 14:21:44 -0700 (PDT) Received: from mail.hardakers.net (dawn.hardakers.net [IPv6:2001:470:1f00:187::1]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D24CC133090 for ; Wed, 18 Oct 2017 14:21:36 -0700 (PDT) Received: from localhost (50-1-20-198.dsl.static.fusionbroadband.com [50.1.20.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.hardakers.net (Postfix) with ESMTPSA id 3F0F921ADD; Wed, 18 Oct 2017 14:21:35 -0700 (PDT) From: Wes Hardaker To: Michael StJohns Cc: Wes Hardaker , dnsop@ietf.org References: <840723c3-899a-f57b-caa1-48f14b3686e8@nthpermutation.com> <52a489db-11fe-4142-2135-c363f171dc47@nthpermutation.com> Date: Wed, 18 Oct 2017 14:21:34 -0700 In-Reply-To: <52a489db-11fe-4142-2135-c363f171dc47@nthpermutation.com> (Michael StJohns's message of "Wed, 18 Oct 2017 09:58:18 -0400") Message-ID: User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [DNSOP] Responding to MSJ review of the previous rfc5011-security-considerations X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Oct 2017 21:21:45 -0000 > You said in 4.1: > > which the principle > way RFC5011 is currently being used (even though Section 6 of > RFC5011 suggests having a stand-by key available) > > And then in=C2=A0 T-1 you say: > > Note that for simplicity we assume the signer is not pre-signing a= nd > creating "valid in the future" signature sets that may be stolen = and > replayed even later. > > But - "the way RFC5011 is currently being used" is with "pre-signing" > and "valid in the future" signature sets.=C2=A0=C2=A0 So you want to = have your > cake and eat it too.=C2=A0=C2=A0=C2=A0=C2=A0 You're now both not deal= ing with the way 5011 > said you should do things nor are you dealing with the way that the > root actually does things. > > All of this can be fixed by going to a wall clock model which is the > way the publisher works vs the interval model which is only > appropriate for the client. > I understand that's how you'd structure the document. For me, I believe it's easier for people to understand the problem as structured. The example walk-through is designed to be simple for learning about the issue, which is already complex enough. This topic was brought up on the list before and in Chicago and the consent was to leave it as is, though there wasn't a huge number of voiced opinions. We designed the document to come at the topic for human understanding, and I believe most people think about the problem as a delta from the time they sign and publish the zone. I believe that coders will implement it according to how they need to given their software. If you feel strongly about this, please encourage others to chime with requests for change too in order to shift consensus. At this time we don't plan to change the document to reflect your preferred style. > You continue to have a problem with "sigExpirationTime". > > > The amount of time remaining before any existing > > RRSIG's Signature Expiration time is reached. Note that for > > organizations pre-creating signatures this time may be fairly > > lengthy unless they can be significantly assured their signatures > > can not be replayed at a later date. > > the problem is:=C2=A0 Amount of time measured from when?=C2=A0=C2=A0= =C2=A0=C2=A0 (and it should > be "latest RRSIG's Signature Expiration time is reached" at least. > > > sigExpirationTime will > > fundamentally be the RRSIG's Signature Expiration time minus = the > > RRSIG's Signature Inception time when the signature is create= d. > This is no longer fundamentally the difference between one RRSig > inception and expiration time.=C2=A0 You can't even describe it as the > difference between the earliest inception and latest expiration > because that changes as the earlier RRSigs expire.=C2=A0=C2=A0 The onl= y fixed > value (and easiest value) is "latest expiration date". You could say > "latest expiration date - now" which then gets added to "now" to get > back to lastest expiration date..... > > Please, please please just move to a wall clock value based on the > latest expiration date plus appropriate intervals.=C2=A0 All the minor > twiddles you've done to try to avoid doing this have made the document > less clear. I've changed the wording to your "latest...". Thank you for the concrete suggestion. As to "when" it amounts to the current value time(), which is indicated by the "The amount of time remaining...". Again, this is written from the point of view of a human wanting to calculate how long the need to continue waiting.=20 --=20 Wes Hardaker USC/ISI From nobody Wed Oct 18 15:03:31 2017 Return-Path: X-Original-To: dnsop@ietf.org Delivered-To: dnsop@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D63C134459; Wed, 18 Oct 2017 15:03:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dnsop@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150836420939.18959.8417863006279488485@ietfa.amsl.com> Date: Wed, 18 Oct 2017 15:03:29 -0700 Archived-At: Subject: [DNSOP] I-D Action: draft-ietf-dnsop-terminology-bis-07.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Oct 2017 22:03:29 -0000 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 : DNS Terminology Authors : Paul Hoffman Andrew Sullivan Kazunori Fujiwara Filename : draft-ietf-dnsop-terminology-bis-07.txt Pages : 42 Date : 2017-10-18 Abstract: The DNS is defined in literally dozens of different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has sometimes changed in the decades since the DNS was first defined. This document gives current definitions for many of the terms used in the DNS in a single document. This document will be the successor to RFC 7719, and thus will obsolete RFC 7719. It will also update RFC 2308. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-terminology-bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dnsop-terminology-bis-07 https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-terminology-bis-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-terminology-bis-07 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/ From nobody Wed Oct 18 15:10:53 2017 Return-Path: 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 A1134133020 for ; Wed, 18 Oct 2017 15:10:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.302 X-Spam-Level: X-Spam-Status: No, score=-2.302 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_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 B5xFpM86SUgH for ; Wed, 18 Oct 2017 15:10:50 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9423813292A for ; Wed, 18 Oct 2017 15:10:50 -0700 (PDT) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 18 Oct 2017 15:10:48 -0700 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1178.000; Wed, 18 Oct 2017 15:10:48 -0700 From: Paul Hoffman To: dnsop Thread-Topic: Update to terminology-bis: -07 Thread-Index: AQHTSF3z+KZ791h/JUO1jZOKoQ/Btw== Date: Wed, 18 Oct 2017 22:10:47 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.32.234] Content-Type: text/plain; charset="us-ascii" Content-ID: <0D794C2464E4C74089F4E9FF7CAAEB1F@pexch112.icann.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [DNSOP] Update to terminology-bis: -07 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Oct 2017 22:10:52 -0000 Greetings again. This new version closes out a bunch of open issues, and le= aves only three known open issues. We hope you all will read the diffs care= fully, particularly the ones for "Global DNS" and the refined definition fo= r QNAME. Feel free to bring up any problems with the draft here on the list= , or in the issue tracker on GitHub. --Paul Hoffman= From nobody Wed Oct 18 15:27:58 2017 Return-Path: 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 31A751321A1 for ; Wed, 18 Oct 2017 15:27:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 ypDomy0ftAHO for ; Wed, 18 Oct 2017 15:27:55 -0700 (PDT) Received: from mail2.verisign.com (mail2.verisign.com [72.13.63.31]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85CC2132193 for ; Wed, 18 Oct 2017 15:27:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=3366; q=dns/txt; s=VRSN; t=1508365675; h=from:to:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version:subject; bh=AqDhZvgFvErjSU8EocXnBUbxdB1hEO6QzDh8VYFonGw=; b=OI7Vh6og/0pWjp0lsIDjHzw4OOSDznkioiw+o7CVoQzvfEPj0xxM7hhO qfJNzDHMzWrX5n1R1Qcbviza3iXBWbI8+ZPYAB60QKNqnBazmnxQUxw74 RWvRCEENZLRR/KUXo4qQS7OPDCiuSSIqzJYg/rW3raWGsRV11LPuYlpf3 iwBZEs++pFME0AxN4o9teupiEIVF2LC1ZwbB3AA/89x/clF/TGtj3Qiv6 zub8rwJJt4BHJpb6aZHoKeeUWiIKVcIFJHIJDTu3IuBp411AJQk5jbZr+ dqm1EiPuFARXdKdJy/SNNd0f9KbFpx19efn0aCcE6V6NSp4PC6jgpTNPs g==; X-IronPort-AV: E=Sophos;i="5.43,398,1503360000"; d="scan'208";a="2800571" IronPort-PHdr: =?us-ascii?q?9a23=3AAOtsrhUB3S2lFR7LzGtcXA/MkgDV8LGtZVwlr6E/?= =?us-ascii?q?grcLSJyIuqrYbBCOt8tkgFKBZ4jH8fUM07OQ6PGwHzRYqb+681k6OKRWUBEEjc?= =?us-ascii?q?hE1ycBO+WiTXPBEfjxciYhF95DXlI2t1uyMExSBdqsLwaK+i764jEdAAjwOhRo?= =?us-ascii?q?LerpBIHSk9631+ev8JHPfglEnjSwbLdxIRmssQndqtQdjJd/JKo21hbHuGZDdf?= =?us-ascii?q?5MxWNvK1KTnhL86dm18ZV+7SleuO8v+tBZX6nicKs2UbJXDDI9M2Ao/8LrrgXM?= =?us-ascii?q?TRGO5nQHTGoblAdDDhXf4xH7WpfxtTb6tvZ41SKHM8D6Uaw4VDK/5KpwVhTmlD?= =?us-ascii?q?kIOCI48GHPi8x/kqRboA66pxdix4LYeZyZOOZicq/Ye94RWGhPUdtLVyFZAo2y?= =?us-ascii?q?cZYBD/YPM+hboYnypVoOogexCwajH+7v1iZIhnrq0aEmz+gtDwfL1xEgEdIUt3?= =?us-ascii?q?TUqc34OKkSXu+r16nI1ivMb/dN2Tvl9YPGfA0hruuKXb1uf8ba1E4iGB7Lj1qO?= =?us-ascii?q?sozlJC2a1uAWs2WA8epvS/ivi288qwFwrTivwN0ghZXOhoIQ013J8zhyzogyJd?= =?us-ascii?q?29UkF7YNikHYNRty6EK4t2TNkuQ2ZyuCY1zLANpJ21fDASxZg62xLTceGLfoqG?= =?us-ascii?q?7x75SeqcITl1iGh7dL+wiBu+6VWsxvHmWsWp0ltGsjBJnsTDu30OzRDf98uKR/?= =?us-ascii?q?1g9Um7wzmPzRrc6uRcLEAxkqrUNoAuz6YrlpoWrUTDBij2mFjqjKOOdkUr5Oyo?= =?us-ascii?q?6+P/b7r9vJ+cMZJ4igXxM6QrgMO/AOA4Mg8TX2iH5eiwyafv/VPnT7VQj/02ia?= =?us-ascii?q?jZsJ/cJcgBuqG5BApV3p4i6xa5ETimzMwVkWQbIF5fZR6KjYbkN0vTLP34A/qz?= =?us-ascii?q?mUqgnThkyvzeO73uGJTNLnzNkLf7erZ97lZRxxc9zN9B/JJUEa8OIPboWkLqqt?= =?us-ascii?q?zXEAU5Mw2vw+bmB9V90JkSVn6IAq+cKK/Sq0OH5vozI+mQY48YoCvyK/4+5/7p?= =?us-ascii?q?lX80gl4dcre13ZsZcny4Ge5mI0rKKUbr19sHCmAS9jURBLjmjkaFSRZSamq8Ga?= =?us-ascii?q?Um6WdoJpihCNKJeY22m7GFx2PzMoBfYG0MQgSADnrzbIiAQN8SZTiTOc5ulHoP?= =?us-ascii?q?Ur33GNxp7g2nqAKvk+kvFeHT4CBN8Mu7jNU=3D?= X-IPAS-Result: =?us-ascii?q?A2GPAABv1OdZ//SZrQpcGQEBAQEBAQEBAQEBBwEBAQEBFAE?= =?us-ascii?q?BAQEBAQEBAQEBBwEBAQEBhBiBFQeOEpEMJXuVOIINBwoYC4UYAoU4GAEBAQEBA?= =?us-ascii?q?QEBAQEBAoEQgjgkAQ1GLAEBAQEBASYBAQEBAQEjAj4sAQEBAQIBAQE4NBALAgE?= =?us-ascii?q?IDQseECcLJQIEE4oYGK06iyUBAQEBAQUBAQEBAQEBASCDL4NZgWkrC4JENYReE?= =?us-ascii?q?RaDQoIyBYoQhziBa44SBgKHXo8hXYUZiw6VRgIECwIZAYE5H4IUehUfKi0BgjY?= =?us-ascii?q?JhFZ2iCaBM4ERAQEB?= 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 v9IMRpdi021366 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 18 Oct 2017 18:27:51 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0301.000; Wed, 18 Oct 2017 18:27:51 -0400 From: "Wessels, Duane" To: dnsop WG Thread-Topic: [EXTERNAL] [DNSOP] I-D Action: draft-ietf-dnsop-aname-00.txt Thread-Index: AQHTSGBVN06d/np28Eev9GJJu8TEkQ== Date: Wed, 18 Oct 2017 22:27:50 +0000 Message-ID: <609A6D8D-DF63-4000-8928-23968C2518D1@verisign.com> References: <149592096439.3966.11385984990945858242@ietfa.amsl.com> In-Reply-To: <149592096439.3966.11385984990945858242@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: <988F07D1A4FC2840B4F64439A973D9EC@verisign.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-aname-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Oct 2017 22:27:57 -0000 I have a couple of questions about the text in 3.1 around TTLs and caching: > Address records cached locally MUST have a limited TTL. The initial TTL > for locally-cached address records MUST be set to the lesser of the ANAME Reading this reminds me of the way that Unbound works with respect to its cache-max-ttl. Quoting the documentation: cache-max-ttl: Time to live maximum for RRsets and messages in the cache= . Default is 86400 seconds (1 day). If the maximum kicks in= , responses to clients still get decrementing TTLs based on th= e original (larger) values. When the internal TTL expires, th= e cache item has expired. Can be set lower to force the resolve= r to query for data often, and not trust (very large) TTL values. In other words, Unbound uses the original TTL but removes the data after cache-max-ttl, which might be shorter. =20 Might it not also be acceptable (desirable?) to do the same for aname? I t= hink it would mean that the A/AAAA records are cached similarly by both aname-aw= are and aname-unware recursive name servers. > TTL and the TTL of the address records retrieved from the ANAME . Perhaps "...and the TTLs of all the address records..."? > The local TTL MUST count down, just as it would in a conventional resolve= r > cache. Records with an expired TTL MUST NOT be used to answer address > queries until refreshed with a new query to the ANAME . That only says what not to do. How should the server respond if the locally-cached address records cannot be refreshed? SERVFAIL? whatever draft-serve-stale says? DW > On May 27, 2017, at 2:36 PM, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Domain Name System Operations of the IET= F. >=20 > Title : Address-specific DNS Name Redirection (ANAME) > Authors : Evan Hunt > Peter van Dijk > Anthony Eden > Filename : draft-ietf-dnsop-aname-00.txt > Pages : 10 > Date : 2017-05-27 >=20 > Abstract: > This document defines the "ANAME" DNS RR type, to provide similar > functionality to CNAME, but only redirects type A and AAAA queries. > Unlike CNAME, an ANAME can coexist with other record types. The > ANAME RR allows zone owners to redirect queries for apex domain names > in a standards compliant manner. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-aname/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dnsop-aname-00 > https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-aname-00 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop From nobody Thu Oct 19 06:25:53 2017 Return-Path: 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 815C2132C3F for ; Thu, 19 Oct 2017 06:25:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.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 i_CR8h5lPeN7 for ; Thu, 19 Oct 2017 06:25:50 -0700 (PDT) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (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 B2DD11241F3 for ; Thu, 19 Oct 2017 06:25:50 -0700 (PDT) Received: by mail-qt0-x234.google.com with SMTP id k31so14380075qta.6 for ; Thu, 19 Oct 2017 06:25:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=wjgNLrLbYPHeKEDZerzfH4udK/7mit9VEujAH2pDWQg=; b=XaegEZnQQ0Pa4f7U4G+ss6gKkXWh5CvENFZCIHQ6MLRT2G33ZRApg0zSokGE7TxTIU D48xEEUe3sUmvGO1hU2m/qnuqt0r1YtO6BuACq0x7Jjx8ZOULlvy4/Q4iP5f5Fg5MIxV T6JPZ1GDWGxlIr1e8dgviv6s7eSC+q5RzhAuq7m1fqa2MyU/2ckyEeXAXXD4t5ZaW1yM FD2RiIoCPggyyV1sJjfayRomkftDyEkUu379+ikMI35VO+gPSODX8PuU0LlKgb3lMZoj 6t5MBjO7rwmFPFyfrFHHHHcJeRnO9/wbtK5tWsj12TPRcuoSvwoPp7IXe1zMn0v+D5Vn 8Xwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=wjgNLrLbYPHeKEDZerzfH4udK/7mit9VEujAH2pDWQg=; b=SHApsaMwA347VbtJ2UrtF9qp7eEMXv4iYJxqy1da8R5DPHFfM0nJhwKZLfXyansmYr pROY6YMw3lCYIkwBr/KpaSFVHZ9TqCwT5WJUqZeYoso+tBVw4E5089tnM3jbiHZYkh0L jvZVmG8bznh3WmLwIUxP0hs7o7hHRozCpuQf3s+/WhfDsSyx+FOl/mlofMokrA+ohZ1S kv1dN8rFByfeymlS5ANvHiuH0tzq5zo7jt8+lyDUIu6HWeh5x/YNyCIWiDSHMjQ4cY2C kLxYGgUoPLnPOXcL9kFdpJ3hdAbQKKPyQbSEvv5nElgWzb0Z43SLEkPDDjrPB17uY3Cr /24A== X-Gm-Message-State: AMCzsaVYmkwoqW1Stq0GSpHp6YrNsMp7Mophv564L7YWuJ/t0Es0pUsK hw+rZSOizMZ3B0zaYubhIoDky7rv X-Google-Smtp-Source: ABhQp+Tn59816J8BXuY7P7BTJr3mC+gfcmBp3ZkbWVXyQyORRAgH9Qzv7Bou+zZUIiiRmy9kpM8J/Q== X-Received: by 10.200.49.21 with SMTP id g21mr2084761qtb.183.1508419549170; Thu, 19 Oct 2017 06:25:49 -0700 (PDT) Received: from [192.168.1.112] (c-69-140-114-191.hsd1.md.comcast.net. [69.140.114.191]) by smtp.gmail.com with ESMTPSA id p8sm9093698qki.57.2017.10.19.06.25.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Oct 2017 06:25:47 -0700 (PDT) To: Wes Hardaker Cc: dnsop@ietf.org References: <840723c3-899a-f57b-caa1-48f14b3686e8@nthpermutation.com> <52a489db-11fe-4142-2135-c363f171dc47@nthpermutation.com> From: Michael StJohns Message-ID: Date: Thu, 19 Oct 2017 09:25:45 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [DNSOP] Responding to MSJ review of the previous rfc5011-security-considerations X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Oct 2017 13:25:52 -0000 On 10/18/2017 5:21 PM, Wes Hardaker wrote: >> You said in 4.1: >> >> which the principle >> way RFC5011 is currently being used (even though Section 6 of >> RFC5011 suggests having a stand-by key available) >> >> And then in  T-1 you say: >> >> Note that for simplicity we assume the signer is not pre-signing and >> creating "valid in the future" signature sets that may be stolen and >> replayed even later. >> >> But - "the way RFC5011 is currently being used" is with "pre-signing" >> and "valid in the future" signature sets.   So you want to have your >> cake and eat it too.     You're now both not dealing with the way 5011 >> said you should do things nor are you dealing with the way that the >> root actually does things. >> >> All of this can be fixed by going to a wall clock model which is the >> way the publisher works vs the interval model which is only >> appropriate for the client. >> > I understand that's how you'd structure the document. For me, > I believe it's easier for people to understand the problem as > structured. This is unfortunately a deflection.  The document is still being two-faced in that it is claiming to address "the way RFC5011 is currently being used" but ignoring the "pre-signing" and "valid in the future" signature sets in its discussion of the issue AND the solution. With respect to below, I believe that "most people" (who are doing 5011 in the way you've described) would want the answer to the question: "When is it safe for me to revoke all of the older trust anchor keys?".   When they discuss it with "other people" they will use a fixed date not "5 days from when I did the calculation which was 2 days ago so three days from now". This isn't about a structuring preference, it's about having 10 people doing the math at different times and having 100s others get the same understanding of the answer when the first 10 discuss it. Even the Root 5011 folks discuss their timings in terms of actual dates.  Yes they get to the dates by doing interval calculations, but what matters are the dates and I haven't heard anyone say otherwise. > The example walk-through is designed to be simple > for learning about the issue, which is already complex enough. > This topic was brought up on the list before and in Chicago and > the consent was to leave it as is, though there wasn't a huge > number of voiced opinions. We designed the document to come at > the topic for human understanding, and I believe most people > think about the problem as a delta from the time they sign and > publish the zone. I believe that coders will implement it > according to how they need to given their software. > > If you feel strongly about this, please encourage others to > chime with requests for change too in order to shift consensus. > At this time we don't plan to change the document to reflect > your preferred style. > >> You continue to have a problem with "sigExpirationTime". >> >> > The amount of time remaining before any existing >> > RRSIG's Signature Expiration time is reached. Note that for >> > organizations pre-creating signatures this time may be fairly >> > lengthy unless they can be significantly assured their signatures >> > can not be replayed at a later date. >> >> the problem is:  Amount of time measured from when?     (and it should >> be "latest RRSIG's Signature Expiration time is reached" at least. >> >> > sigExpirationTime will >> > fundamentally be the RRSIG's Signature Expiration time minus the >> > RRSIG's Signature Inception time when the signature is created. >> This is no longer fundamentally the difference between one RRSig >> inception and expiration time.  You can't even describe it as the >> difference between the earliest inception and latest expiration >> because that changes as the earlier RRSigs expire.   The only fixed >> value (and easiest value) is "latest expiration date". You could say >> "latest expiration date - now" which then gets added to "now" to get >> back to lastest expiration date..... >> >> Please, please please just move to a wall clock value based on the >> latest expiration date plus appropriate intervals.  All the minor >> twiddles you've done to try to avoid doing this have made the document >> less clear. > I've changed the wording to your "latest...". Thank you for the > concrete suggestion. You're welcome.  However, all the rest of these are also "concrete suggestions".  Or do you mean "actual text that I can incorporate"? I'm happy to edit the entire document to fix the issues if you want to give me the edit token. > As to "when" it amounts to the current > value time(), which is indicated by the "The amount of time > remaining...". So 10 people doing this have to publish both the interval they calculate and the time() value at which they did their calculations?  So the other 10-100 people can figure out "when"? I think not. > Again, this is written from the point of view of > a human wanting to calculate how long the need to continue waiting. > And it should be written from the POV of a human wanting to tell a group of people WHEN something will be done.   Sending out "we're going to do this in 45 days" is problematic especially if I re-read the email 10 days after it was sent or if the email was delayed.    Sending out "we're going to do this on January 1st at 10am" or "we're going to do this in 45 days which is January 1st at 10am" is going to be more useful than a simple interval. I can't figure out why you continue to argue as you do - the output of this calculation is a date and time at which it is safe to revoke the old keys - not an interval.  In fact you have to work hard to make it an interval. Later, Mike From nobody Thu Oct 19 12:46:15 2017 Return-Path: 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 8247913306B; Thu, 19 Oct 2017 12:46:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_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 yb1SaioDylDH; Thu, 19 Oct 2017 12:46:13 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05C0E132D89; Thu, 19 Oct 2017 12:46:13 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id A4209B810C1; Thu, 19 Oct 2017 12:45:49 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, dnsop@ietf.org Message-Id: <20171019194549.A4209B810C1@rfc-editor.org> Date: Thu, 19 Oct 2017 12:45:49 -0700 (PDT) Archived-At: Subject: [DNSOP] RFC 8244 on Special-Use Domain Names Problem Statement X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Oct 2017 19:46:14 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8244 Title: Special-Use Domain Names Problem Statement Author: T. Lemon, R. Droms, W. Kumari Status: Informational Stream: IETF Date: October 2017 Mailbox: ted.lemon@nominum.com, rdroms.ietf@gmail.com, warren@kumari.net Pages: 25 Characters: 59995 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-dnsop-sutld-ps-08.txt URL: https://www.rfc-editor.org/info/rfc8244 DOI: 10.17487/RFC8244 The policy defined in RFC 6761 for IANA registrations in the "Special-Use Domain Names" registry has been shown, through experience, to present challenges that were not anticipated when RFC 6761 was written. This memo presents a list, intended to be comprehensive, of the problems that have since been identified. In addition, it reviews the history of domain names and summarizes current IETF publications and some publications from other organizations relating to Special-Use Domain Names. This document should be considered required reading for IETF participants who wish to express an informed opinion on the topic of Special-Use Domain Names. This document is a product of the Domain Name System Operations Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Fri Oct 20 09:39:59 2017 Return-Path: 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 93937134211 for ; Fri, 20 Oct 2017 09:39:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=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 uWX13nJwsycQ for ; Fri, 20 Oct 2017 09:39:55 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF899132D67 for ; Fri, 20 Oct 2017 09:39:55 -0700 (PDT) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Fri, 20 Oct 2017 09:39:53 -0700 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1178.000; Fri, 20 Oct 2017 09:39:53 -0700 From: Edward Lewis To: tjw ietf CC: dnsop Thread-Topic: [Ext] [DNSOP] Working Group Last Call - draft-ietf-dnsop-rfc5011-security-considerations Thread-Index: AQHTSAKiAPrVc0Gd3keOQWiaZ8psOKLtaW4A Date: Fri, 20 Oct 2017 16:39:52 +0000 Message-ID: <168D0FAC-C972-4A14-B627-DEEB7E030B27@icann.org> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.47.236] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3591337192_1784542923" MIME-Version: 1.0 Archived-At: Subject: Re: [DNSOP] [Ext] Working Group Last Call - draft-ietf-dnsop-rfc5011-security-considerations X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Oct 2017 16:39:57 -0000 --B_3591337192_1784542923 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit On 10/18/17, 04:17, "DNSOP on behalf of tjw ietf" wrote: >This starts a Working Group Last Call for: draft-ietf-dnsop-rfc5011-security-considerations I outright oppose publishing this document. One, the audience of this document (namely the targetted operators) has not participated in the review of the document. I should perhaps add "sufficiently" as I have made comments and my personal observation is that the document isn't all that helpful. No other operator, so far as I know (big caveat), has commented. Two, the document perpetuates the mis-use the term "trust anchor". To point to a specific place in the document: ## 3. Terminology ## ## Trust Anchor Publisher The entity responsible for publishing a ## DNSKEY that can be used as a trust anchor. That is not a term I'd define. Trust is gained, not read. One cannot "push" trust via publishing something. What is published are secure entry point keys: >From "DNSSEC Resource Records", section "The Flags Field": "Bit 15 of the Flags field is the Secure Entry Point flag, described in [RFC3757]" Note that it is not the "Trust Anchor flag." I don't think that the working group should progress documents that lead to terminology confusion. Three, the document beings to co-mingle validation with trust anchor management, which are two different concepts: ## RFC5011 Validating Resolver A DNSSEC Validating Resolver that is ## using the RFC5011 processes to track and update trust anchors. ## Sometimes referred to as a "RFC5011 Resolver" Automated Updates is not part of the validation process, it is a part of the trust anchor management function. Whether the set of trust anchors are managed in accordance to Automated Updates or not, the validation process is the same. Four...well, as I said, it's hard to justify spending time on a document that has a low ROI. The equation for timing, which is the highlight of the document, is too complicated and includes an unsupported "safety margin." The latter element throws out the window any reason to be so precise up to that point. I appreciate the document's desire. But it would be better written if it came from operator experience in implementing a key management scheme that is compatible with what is described in the Automated Updates of DNSSEC Trust Anchors document. And it would be less harmful if the terminology stuck to the language used in developing the protocol, as opposed to the colloquial use that has emerged. (Such as the notion that trust anchors "are published".) The reason I'm opposing going forward without providing new text is that I don't feel that I can give new text until completing a process designed to be compatible with "Automated Updates". I could envision a "Recommended Management of Secure Entry Points for Compatibility with Automated Updates" coming in the future, but not yet. --B_3591337192_1784542923 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIR5gYJKoZIhvcNAQcCoIIR1zCCEdMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC D68wggWeMIIEhqADAgECAhAE64fxtFjS2DdV8JfouoFSMA0GCSqGSIb3DQEBCwUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xNjA4MDkw MDAwMDBaFw0xOTA4MDkxMjAwMDBaMIG9MQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZv cm5pYTEUMBIGA1UEBxMLTG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEeMBwGA1UEAxMVRWR3YXJkIExl d2lzIDkgQXVnIDE2MSUwIwYJKoZIhvcNAQkBFhZlZHdhcmQubGV3aXNAaWNhbm4ub3JnMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxGXAQjOhBCDPz1+sGOERDMvSCFWbOUws GUrXAHLGeEAGYTCpni8f7kYPH7RMalvbep2aVtkMSUn6HR1uY84b437ZZuHCviUn7Aw6itGE wrDyq7Pb7zTlqE/1kLVhKYrHA4sjhsQRHhBHevxWbb3SYU2IMNxJd4QFgRJIp4zDmAR7bzbH 1ZazFGfo/op0QRsfcpFYmBotbj/4SnldtFwZasr7zTK9wJRSXa9sspLXtQhBe9itxTHJRg0H BH66VcPX7iRra9XFzkM5JLXOT2nBDIxeqDsLKoTkRWiNoSWoDZylAqS3BfBppwq7eremR7zD LIaPN4Tbb8TCpORMCZuvswIDAQABo4IB7zCCAeswHwYDVR0jBBgwFoAU5wIjgABP2Ne8lAvZ P3Q5STI8inkwHQYDVR0OBBYEFBiOkLRCGoHjShiTxeM3n94XHm+2MAwGA1UdEwEB/wQCMAAw IQYDVR0RBBowGIEWZWR3YXJkLmxld2lzQGljYW5uLm9yZzAOBgNVHQ8BAf8EBAMCBaAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYKYIZIAYb9bAQBAjAq MCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMIGIBgNVHR8EgYAw fjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJ RENBLWcyLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hB MkFzc3VyZWRJRENBLWcyLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6 Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhY2VydHMuZGlnaWNl cnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG9w0BAQsFAAOCAQEA zhEJp9X6tm36lKKaxCdyjyETxL3oVPDmv2JHBD/T/xbqRH0vQfR34VkRnSO+5d8AqHGdhYTK 7yjB/vW52KjiQUiW9WnQFYdY5Q/Yv3cnVgi4zuuye9BPvyr87HbmJ0uafYjATnYziT71njO7 xKIQP6w0MFv8ugT/fXIZsV4NU2eGQEHhvPkR+WOt0KfFa5jEY1qXoj4iZmE21j+f0OhSTA9K EofM5chR6FCaOyomKPIYU1mcoQwcistCwfcdVhUCpmgazxn6fR89ZOOiKTXxhOHrILdO0pCI dlJ3xO6EBvFKBCOyRBkD2z7jcWm/U3GkkYBLyRMvH1Ki+q4vwKnFZjCCBk4wggU2oAMCAQIC EASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcNAQELBQAwZTELMAkGA1UEBhMCVVMxFTATBgNV BAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMb RGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEzMTEwNTEyMDAwMFoXDTI4MTEwNTEy MDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQ d3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENB MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/AJ3kbLQWHohBDMd8O 1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr+Lp+yTU7VvEffEJ+ JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQelAfJUXo8Ymvzf9e /1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK3OnZ9ZEXjsYhrTg8 E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uCig1xGOSm4IksG/Oy czzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/BAgwBgEB/wIBADAO BgNVHQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2Nz cC5kaWdpY2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9jcmw0LmRpZ2ljZXJ0 LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRp Z2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYDVR0lBBYwFAYIKwYB BQUHAwIGCCsGAQUFBwMEMIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgBhv1sAAIEMIIBkjAo BggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCCAWQGCCsGAQUFBwIC MIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABpAHMAIABDAGUAcgB0AGkAZgBp AGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABhAGMAYwBlAHAAdABhAG4AYwBl ACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABDAFAALwBDAFAAUwAgAGEAbgBk ACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBu AHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBiAGkAbABpAHQAeQAgAGEAbgBk ACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAgAGgAZQByAGUAaQBuACAAYgB5 ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP2Ne8lAvZP3Q5STI8inkw HwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcNAQELBQADggEBAE7U iSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrgYhmZpgeafBMn2+UC ooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg4/mgVgxIEM4zaHvN k6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmwXZG0k4f5lpaBVUCO Zu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1YEhEybr1DDE0023vG QtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIwggO3MIICn6ADAgECAhAM 5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQK EwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0Rp Z2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAwMDAwMDBaFw0zMTExMTAwMDAw MDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3 dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7kQ4BcsYfzt2D5cRKlrtwmlIiq 9M71IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrneVNcMYQq9g+YMjZ2zN7dPKii 72r7IfJSYd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9SwOD7BG8OMM9nYLxj+KA+zp4PW w25EwGE1lhb+WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyChz+VtCshJfDGYM2wi6YfQMlqi uhOCEe05F52ZOnKh5vqk2dUXMXWuhX0irj8BRob2KHnIsdrkVxfEfhwOsLSSplazvbKX7aqn 8LfFqD+VFtD/oZbrCF8Yd08CAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgGGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFEXroq/0ksuCMS1Ri6enIZ3zbcgPMB8GA1UdIwQYMBaAFEXroq/0 ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBBQUAA4IBAQCiDrzf4u3w43JzemSUv/dyZtgy 5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwSTFjk0z2DSUVYlzVpGqhH6lbGeasS2GeBhN9/CTyU 5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJs13rsgkq6ybteL59PyvztyY1bV+JAbZJW58B BZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLxvlBnt2y98/Efaww2BxZ/N3ypW2168RJG YIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76jRslbWyPpbdhAbHSoyahEHGdreLD +cOZUbcrBwjOLuZQsqf6CkUvovDyMYIB/zCCAfsCAQEweTBlMQswCQYDVQQGEwJVUzEVMBMG A1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQD ExtEaWdpQ2VydCBTSEEyIEFzc3VyZWQgSUQgQ0ECEATrh/G0WNLYN1Xwl+i6gVIwCQYFKw4D AhoFAKBdMCMGCSqGSIb3DQEJBDEWBBSFyXqo2ePzseGwi60tENokN1TQfTAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzEwMjAxNjM5NTJaMA0GCSqGSIb3 DQEBAQUABIIBAKIEHKsL2jvxIem8gvDl1PU1CAI4z4Zlv7TJ3OlomN3gUPolnWgfcGD7/P9M CDzUCx7ikUfi9KVUFK3b34/JdwRH3oKC81bpQjrFy8fS/w733T8ZiGU3rmxF/N4QSvgwWIOm 5iu8AvuYtH5VT4aewKY59YRJh0qvt9+EE4RyJjs96y5BD/T03Q8S4utSy8IHGJxiQyOtGYz1 x6AXkMZpkdBLKK8cLSLDsQfvQ4KrlRUie20ZsXsZ8+12l3QE0eiS+nyyKxETFuyLuzkrpJfe p7CMSjDqzod+6+LDjsnl4FNL2LNX9qY7rUt2bgHNOOGYbUhSq8pcE2jXPiZfng3oNaw= --B_3591337192_1784542923-- From nobody Fri Oct 20 17:24:15 2017 Return-Path: X-Original-To: dnsop@ietf.org Delivered-To: dnsop@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CF94134465; Fri, 20 Oct 2017 17:24:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: dnsop@ietf.org, warren@kumari.net X-Test-IDTracker: no X-IETF-IDTracker: 6.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150854545144.20809.7728705221830986245.idtracker@ietfa.amsl.com> Date: Fri, 20 Oct 2017 17:24:11 -0700 Archived-At: Subject: [DNSOP] dnsop - Requested sessions have been scheduled for IETF 100 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Oct 2017 00:24:11 -0000 Dear Tim Wicinski, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. dnsop Session 1 (2:00:00) Monday, Morning Session I 0930-1200 Room Name: Padang size: 300 --------------------------------------------- dnsop Session 2 (1:00:00) Thursday, Afternoon Session II 1550-1750 Room Name: Padang size: 300 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Domain Name System Operations Area Name: Operations and Management Area Session Requester: Tim Wicinski Number of Sessions: 2 Length of Session(s): 2 Hours, 1 Hour Number of Attendees: 160 Conflicts to Avoid: First Priority: dhc homenet dnssd dprive doh Second Priority: v6ops intarea trans ideas Third Priority: 6man grow opsarea opsawg pcp saag sidr People who must be present: Suzanne Woolf Joel Jaeggli Warren Kumari Tim Wicinski Resources Requested: Special Requests: If either session is slotted for Friday, please make it the second 1 hour session. thanks --------------------------------------------------------- From nobody Mon Oct 23 18:52:27 2017 Return-Path: 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 06A49139F67 for ; Mon, 23 Oct 2017 18:52:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 2CJLHjlqmYh9 for ; Mon, 23 Oct 2017 18:52:24 -0700 (PDT) Received: from mail-wr0-x236.google.com (mail-wr0-x236.google.com [IPv6:2a00:1450:400c:c0c::236]) (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 4E6E313942F for ; Mon, 23 Oct 2017 18:52:24 -0700 (PDT) Received: by mail-wr0-x236.google.com with SMTP id o44so19130142wrf.11 for ; Mon, 23 Oct 2017 18:52:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=95kKdyLq/fkk2jyLtnMbK+ktlr+TfxwRPwzNFb9zDFU=; b=Yz326elcnQzq7QGRv515bflWK5CAYgsmGXvTK6NcLm1IiGd6HO7qTWBU2x2sRbXuJF F+VZBWCWh8lCAEi4QRus9lipzgX5s9znSuHq123pTzOuTusWqb0BnTtQHSmYx2JQjs4L qf9aXEGacsr4XEg3+pgg31/iiUD4H6FP77Zfd3qyC4ez//FTUi68od6MZ0gjTAi2T+3r NFwoA4iD7e98vXCeKupqemgraFaH2GRwvIiU5x6tPPsEErA9uXRK4ucw2rjZYcCZUw8q lU3AnTuvgMFKpBxoRsOqBVt/nYy1TmMXhC3ODnap/lwf6iu1HocfyaD2chX7tLUsqBL/ mn2g== 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; bh=95kKdyLq/fkk2jyLtnMbK+ktlr+TfxwRPwzNFb9zDFU=; b=QZluoLMnyu/vfRcRIDdiunEHroOMvHEo51WnHZ/YI5iR5yh2gsgS0ifTSX2TT3eegG YSRrvH2H9rqQpIcztNAYg2bZlnwdwb8A9GdgNXHLV83lQj5r6iNjoLDTykZBWvRUQqq8 qpHqluXiBvOwyDcv0jpymGoGgy6Vt0wRP2Px0YuGGiRDh7sGO8TuRu0CUxBYlwEXW0LH K2a+S/Qz0lD6TcK7o0oRNTgDoUfQTZohkhvllI0gMbKU90ZMfwF0RMOqSn0yg0OH3Rwn 8E6I0c6h/6KkhATDEyVC0OR8GBUCoaq3+QAsMHOsUGNZEfBf5uhB+7CNtmT1NKsLeZ+O Uzkw== X-Gm-Message-State: AMCzsaVnHPGT54sHlLfpJrfHfZH39pY0umXyKQpZFDzUss39xA2Q1vVR eYbKXbZGIAyFqxlQy3M+KXh5FuIwoZQH3TbAHFM= X-Google-Smtp-Source: ABhQp+Tk3yC2G9C+wi98JuPkYpJuk2N1P/tkfmQA+innl/OAqPQsgbFUIuwKEylVxKlSZ9rN/7qjRru+xVRsg7bjEuo= X-Received: by 10.223.181.131 with SMTP id c3mr12763401wre.198.1508809942706; Mon, 23 Oct 2017 18:52:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.184.60 with HTTP; Mon, 23 Oct 2017 18:52:22 -0700 (PDT) In-Reply-To: <89a93742-2917-2125-df8f-b14905218d0f@nic.cz> References: <20170911013510.17202.qmail@ary.lan> <89a93742-2917-2125-df8f-b14905218d0f@nic.cz> From: tjw ietf Date: Mon, 23 Oct 2017 21:52:22 -0400 Message-ID: To: dnsop Content-Type: multipart/alternative; boundary="f40304388b78ab2ef9055c4130e3" Archived-At: Subject: Re: [DNSOP] DNSOP Call for Adoption - draft-west-let-localhost-be-localhost X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 01:52:26 -0000 --f40304388b78ab2ef9055c4130e3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The Call For Adoption ended some time ago, and I spent some time reading the comments. There is consensus to adopt this, *but* there is also a enough of an concern that some of the issues raised be addressed. We'll want to make sure all issues are addressed. tim On Tue, Oct 10, 2017 at 5:12 AM, Petr =C5=A0pa=C4=8Dek = wrote: > > > On 9.10.2017 22:20, Jacob Hoffman-Andrews wrote: > > On 10/09/2017 01:16 PM, Warren Kumari wrote: > >> So, that's my (new) views, and the thread seemed to have stalled. I > >> believe that the security implications of having localhost queries > >> leak into the DNS is bad, and there is significant evidence that this > >> is happening. I get that there is no answer that will make everyone > >> happy, but now that we've had some time to mull over this, where did > >> we end up? > > My feeling of the list is that your view matches the rough consensus: > > stub resolvers are responsible for resolving localhost to 127.0.0.1, an= d > > queries for localhost should not hit the network, as described in the > draft. > > I agree, consider it as one data point in your "rough consensus" > estimation. > > -- > Petr =C5=A0pa=C4=8Dek @ CZ.NIC > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > --f40304388b78ab2ef9055c4130e3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The Call For Adoption ended some time ago, and I spent som= e time reading the comments. =C2=A0

There is consensus t= o adopt this, *but* there is also a enough of an concern that some of the i= ssues raised be addressed. =C2=A0 We'll want to make sure all issues ar= e addressed.=C2=A0

tim

On Tue, Oct 10, 2017 at 5:12 AM, = Petr =C5=A0pa=C4=8Dek <petr.spacek@nic.cz> wrote:


On 9.10.2017 22:20, Jacob Hoffman-Andrews wrote:
> On 10/09/2017 01:16 PM, Warren Kumari wrote:
>> So, that's my (new) views, and the thread seemed to have stall= ed. I
>> believe that the security implications of having=C2=A0 localhost q= ueries
>> leak into the DNS is bad, and there is significant evidence that t= his
>> is happening. I get that there is no answer that will make everyon= e
>> happy, but now that we've had some time to mull over this, whe= re did
>> we end up?
> My feeling of the list is that your view matches the rough consensus:<= br> > stub resolvers are responsible for resolving localhost to 127.0.0.1, a= nd
> queries for localhost should not hit the network, as described in the = draft.

I agree, consider it as one data point in your "rough consensus= " estimation.

--
Petr =C5=A0pa=C4=8Dek=C2=A0 @=C2=A0 CZ.NIC

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

--f40304388b78ab2ef9055c4130e3-- From nobody Tue Oct 24 00:17:45 2017 Return-Path: X-Original-To: dnsop@ietf.org Delivered-To: dnsop@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BD5013C2F9; Tue, 24 Oct 2017 00:17:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dnsop@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150882946350.25306.17929416576913591037@ietfa.amsl.com> Date: Tue, 24 Oct 2017 00:17:43 -0700 Archived-At: Subject: [DNSOP] I-D Action: draft-ietf-dnsop-let-localhost-be-localhost-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 07:17:43 -0000 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 : Let 'localhost' be localhost. Author : Mike West Filename : draft-ietf-dnsop-let-localhost-be-localhost-00.txt Pages : 9 Date : 2017-10-24 Abstract: This document updates RFC6761 with the goal of ensuring that "localhost" can be safely relied upon as a name for the local host's loopback interface. To that end, stub resolvers are required to resolve localhost names to loopback addresses. Recursive DNS servers are required to return "NXDOMAIN" when queried for localhost names, making non-conformant stub resolvers more likely to fail and produce problem reports that result in updates. Together, these requirements would allow applications and specifications to join regular users in drawing the common-sense conclusions that "localhost" means "localhost", and doesn't resolve to somewhere else on the network. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-let-localhost-be-localhost/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dnsop-let-localhost-be-localhost-00 https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-let-localhost-be-localhost-00 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/ From nobody Tue Oct 24 00:38:16 2017 Return-Path: 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 AFB7313D2EB for ; Tue, 24 Oct 2017 00:38:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 kojb8r6Ip907 for ; Tue, 24 Oct 2017 00:38:12 -0700 (PDT) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (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 86C2713DA2F for ; Tue, 24 Oct 2017 00:38:12 -0700 (PDT) Received: by mail-qk0-x22b.google.com with SMTP id d67so25118037qkg.5 for ; Tue, 24 Oct 2017 00:38:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=SlO7gdtSb0Q/A87evDi4Sa4SHgjdkjSc/aKacqtRzN0=; b=Uu+z67LrHh3vSVyYiGp/braFrUtIMCYUbvJE1swiw1tOJD5t+rpfbKdSx+xB14LseD u/qVPCfuXhlPNgFFKpCPvq0s+DYrZSStqwR+Nq0yVdj+FM0L6mT6h+/ynznR6lQ5e6Je 4sBEzpF7V9mTCos1PhuXH192pyMVs2KC67jEShc4ZnXHiYJ5h21I8inYCSA/zZcFseyw k4PKPgsWxHdFh9aAi+QcQx7MoKDWAvlMTfIOIZ6L6A7AcvNECSxGgDUXlIqlWmSGnOcA 6jaGCCPa9+DJCvuu5q6a/QudsZghhQOXeFtk3aOmekx/v4PYxu6stVVOo/BH7AeAtrBw 9gXA== 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; bh=SlO7gdtSb0Q/A87evDi4Sa4SHgjdkjSc/aKacqtRzN0=; b=RFNOmKT+LxDl0T4zbBB+jvxqUpYQdOBkxds7IZK9qGOsqsQX/Bixln89MBpQX9aMt6 4qJaUO8emtRDPXU0v6iGKsLEV+CLdu5baUYT5na9BFsz7zwYOlJr/aEyF4x7MmMkJzOG SXIPa2iLTtAydktkcjBUV2B1GC3hxrE3m+t0JI6/9anQCgjSL/PmhEOESAaFx94nH4oL wdU4u5JZluyFM+WKY90q0/+RXBi1KH0cYZTWPULQiKVEI39nom3bbbJtH+Zk0UPNOUgB dMXABf/4c5+Sr6ljzpudnECa+9dWKdM9INV/yRJBjgr9mltwts835kxT/TjtrBeglPIf nRyA== X-Gm-Message-State: AMCzsaXHXL/t0q0HooJVnx8Iw+CMJkrYEpPWZ2aBLKKLu5lCqPKg3hiM 5dgsD8tgSDJcu7nCatrFU0DUZMB3xyCMslogZx07zOYPgyY= X-Google-Smtp-Source: ABhQp+QZ9kU0BtMXMv2qNFbUZ4XhODgwPj82byFiIgQ8nvJBbaPt+Zk7/uXiBkDSylBE67V/mOgR3gqAJXacnSvU3lg= X-Received: by 10.55.66.84 with SMTP id p81mr23494202qka.182.1508830690951; Tue, 24 Oct 2017 00:38:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.6.210 with HTTP; Tue, 24 Oct 2017 00:37:50 -0700 (PDT) In-Reply-To: <150882946350.25306.17929416576913591037@ietfa.amsl.com> References: <150882946350.25306.17929416576913591037@ietfa.amsl.com> From: Mike West Date: Tue, 24 Oct 2017 09:37:50 +0200 Message-ID: To: dnsop WG Content-Type: multipart/alternative; boundary="001a114abe305cc715055c460547" Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-let-localhost-be-localhost-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 07:38:15 -0000 --001a114abe305cc715055c460547 Content-Type: text/plain; charset="UTF-8" Thanks for the robust discussion on the adoption thread, y'all. This -00 is pretty much a copy of the -06 draft we discussed. I intend to spin out an -01 shortly with the collected feedback from the CfA thread. My impression is that there's a reasonable amount of feedback that seems uncontrovercial, and a larger question of `localhost`'s relationship to DNSSEC. My personal opinion is that Warren's summary in https://www.ietf.org/mail-archive/web/dnsop/current/msg21129.html is a pretty reasonable take on things, and a good basis for moving forward. :) -mike On Tue, Oct 24, 2017 at 9:17 AM, 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 : Let 'localhost' be localhost. > Author : Mike West > Filename : draft-ietf-dnsop-let- > localhost-be-localhost-00.txt > Pages : 9 > Date : 2017-10-24 > > Abstract: > This document updates RFC6761 with the goal of ensuring that > "localhost" can be safely relied upon as a name for the local host's > loopback interface. To that end, stub resolvers are required to > resolve localhost names to loopback addresses. Recursive DNS servers > are required to return "NXDOMAIN" when queried for localhost names, > making non-conformant stub resolvers more likely to fail and produce > problem reports that result in updates. > > Together, these requirements would allow applications and > specifications to join regular users in drawing the common-sense > conclusions that "localhost" means "localhost", and doesn't resolve > to somewhere else on the network. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-let- > localhost-be-localhost/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dnsop-let-localhost-be-localhost-00 > https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-let- > localhost-be-localhost-00 > > > 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 > --001a114abe305cc715055c460547 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the robust discussion on the adoption thre= ad, y'all. This -00 is pretty much a copy of the -06 draft we discussed= .

I intend to spin out an -01 shortly with the collecte= d feedback from the CfA thread. My impression is that there's a reasona= ble amount of feedback that seems uncontrovercial, and a larger question of= `localhost`'s relationship to DNSSEC. My personal opinion is that Warr= en's summary in=C2=A0https://www.ietf.org/mail-archive/web/dnsop/cur= rent/msg21129.html is a pretty reasonable take on things, and a good ba= sis for moving forward. :)

-mike

On Tue, Oct 24, 2017 at 9:17 AM, <= internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Domain Name System Operations WG of the IE= TF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Let 'localhost' be localhost.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Mike= West
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-dnsop-let-localhost-be-localhost-00.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 9
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2017-10-24

Abstract:
=C2=A0 =C2=A0This document updates RFC6761 with the goal of ensuring that =C2=A0 =C2=A0"localhost" can be safely relied upon as a name for = the local host's
=C2=A0 =C2=A0loopback interface.=C2=A0 To that end, stub resolvers are requ= ired to
=C2=A0 =C2=A0resolve localhost names to loopback addresses.=C2=A0 Recursive= DNS servers
=C2=A0 =C2=A0are required to return "NXDOMAIN" when queried for l= ocalhost names,
=C2=A0 =C2=A0making non-conformant stub resolvers more likely to fail and p= roduce
=C2=A0 =C2=A0problem reports that result in updates.

=C2=A0 =C2=A0Together, these requirements would allow applications and
=C2=A0 =C2=A0specifications to join regular users in drawing the common-sen= se
=C2=A0 =C2=A0conclusions that "localhost" means "localhost&q= uot;, and doesn't resolve
=C2=A0 =C2=A0to somewhere else on the network.


The IETF datatracker status page for this draft is:
https://datatracker.iet= f.org/doc/draft-ietf-dnsop-let-localhost-be-localhost/

There are also htmlized versions available at:
https://tools.ietf.org/htm= l/draft-ietf-dnsop-let-localhost-be-localhost-00
https://datatrac= ker.ietf.org/doc/html/draft-ietf-dnsop-let-localhost-be-localhost= -00


Please note that it may take a couple of minutes from the time of submissio= n
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

--001a114abe305cc715055c460547-- From nobody Tue Oct 24 05:17:24 2017 Return-Path: X-Original-To: dnsop@ietf.org Delivered-To: dnsop@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 094FB13F723; Tue, 24 Oct 2017 05:17:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dnsop@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150884743800.25206.2501968545933489353@ietfa.amsl.com> Date: Tue, 24 Oct 2017 05:17:18 -0700 Archived-At: Subject: [DNSOP] I-D Action: draft-ietf-dnsop-let-localhost-be-localhost-01.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 12:17:18 -0000 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 : Let 'localhost' be localhost. Author : Mike West Filename : draft-ietf-dnsop-let-localhost-be-localhost-01.txt Pages : 9 Date : 2017-10-24 Abstract: This document updates RFC6761 with the goal of ensuring that "localhost" can be safely relied upon as a name for the local host's loopback interface. To that end, stub resolvers are required to resolve localhost names to loopback addresses. Recursive DNS servers are required to return "NXDOMAIN" when queried for localhost names, making non-conformant stub resolvers more likely to fail and produce problem reports that result in updates. Together, these requirements would allow applications and specifications to join regular users in drawing the common-sense conclusions that "localhost" means "localhost", and doesn't resolve to somewhere else on the network. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-let-localhost-be-localhost/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dnsop-let-localhost-be-localhost-01 https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-let-localhost-be-localhost-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-let-localhost-be-localhost-01 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/ From nobody Tue Oct 24 05:30:58 2017 Return-Path: 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 59CEA13F3CF for ; Tue, 24 Oct 2017 05:30:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 FVF5LU9SPzK0 for ; Tue, 24 Oct 2017 05:30:54 -0700 (PDT) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (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 0844C13F741 for ; Tue, 24 Oct 2017 05:30:53 -0700 (PDT) Received: by mail-qt0-x231.google.com with SMTP id n61so30099681qte.10 for ; Tue, 24 Oct 2017 05:30:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=EPh7eZbm14V7K0RcFAGOZlNioH627CmswH2dAZRAFck=; b=ejitBOZPJx/MWvA9iZ9VOg/eHArRiDh/pxdKbiiE/6pFZHQAn0C8kXyQbdwPUbudXa DdTUcTGHUglIo0vUr6JuAvwy+ertu9xWRc84eE+IJp+axYY8JRblLzav32bVuWE4u6fV EDGJnq/cZKgcAcA+sVH3H/UZFo4wZXEnuKxSg2+cTWOt8c+GhutWKfYUxWbUxB+ZSwpW qlTXTW+PBY7BbT4t7JinE5MNOaUDPIOt7TYOPfLWE1ODAxz+DnVbrz0OmR5tIiFib6+3 MJ7dk1kE2P0ogvxh1gwchV/6LT4y4jjAECPeclCfhIMAlQU8uATJ3xEMuTEt3okSMyJv ndpQ== 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; bh=EPh7eZbm14V7K0RcFAGOZlNioH627CmswH2dAZRAFck=; b=RKcEUc871YW907cp9snP3EjaozbX2QDYIKXqshtHeh6lsEaUakAohDoNijavaNR74z kmvWVMJg0x5nYJ33KBo0dhJXaYBBI5fT1wXd3W8pyy+0WSr24rF9GJwImW9Kjvn4kiE+ Lqqpa6UZuBhMMIoR5Ontm5kL9XLlCZ7pxeW8Xc1OzVw1oyKJo2tmTVzLQe3n0nNTEvf4 weiglPg2/YdsFze6/a8c5x72BteWopd3I14VPRpdNQ9wweUQsfjexFxfKi13sySjJePI phLSfYHhlpk6ALSFYGlIEd8PBi0Obs2QGUlOIlDEOp5gZkPdwocZUyG+7Od6BZVl8FL3 jiig== X-Gm-Message-State: AMCzsaW9gBMask4l2CCRlJyT4hHwsGJHtczxcRB8FjxQvQK99jc3uI7N 4WhP91JjcgGefHhwvOPfewYrZD6Gd/jBTt8vp1x/p1V6y70= X-Google-Smtp-Source: ABhQp+TGL30r+4oCh6TZ7zj9gz02lWCfWrf8xIqMUJKVUmG6aS28G8d7sKUkWQ/C5KZU23NsNJDjytmlLkkyoUJ6PQQ= X-Received: by 10.200.24.49 with SMTP id q46mr23068964qtj.139.1508848251672; Tue, 24 Oct 2017 05:30:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.6.210 with HTTP; Tue, 24 Oct 2017 05:30:31 -0700 (PDT) In-Reply-To: <150884743800.25206.2501968545933489353@ietfa.amsl.com> References: <150884743800.25206.2501968545933489353@ietfa.amsl.com> From: Mike West Date: Tue, 24 Oct 2017 14:30:31 +0200 Message-ID: To: dnsop WG Content-Type: multipart/alternative; boundary="f403045d6ba2103614055c4a1cee" Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-let-localhost-be-localhost-01.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 12:30:56 -0000 --f403045d6ba2103614055c4a1cee Content-Type: text/plain; charset="UTF-8" As promised, here's an -01 that addresses the concrete feedback in the adoption thread. A brief summary is in the doc https://tools.ietf.org/html/draft-ietf-dnsop-let-localhost-be-localhost-01#appendix-B.1, but an even briefer summary is that it removes the waffling on the secure delegation question by mandating the current behavior of returning NXDOMAIN along with NSEC records constituting a secure denial of existence. That seemed to me to be where the thread's consensus landed. I welcome any and all feedback on the draft. :) -mike On Tue, Oct 24, 2017 at 2:17 PM, 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 : Let 'localhost' be localhost. > Author : Mike West > Filename : draft-ietf-dnsop-let- > localhost-be-localhost-01.txt > Pages : 9 > Date : 2017-10-24 > > Abstract: > This document updates RFC6761 with the goal of ensuring that > "localhost" can be safely relied upon as a name for the local host's > loopback interface. To that end, stub resolvers are required to > resolve localhost names to loopback addresses. Recursive DNS servers > are required to return "NXDOMAIN" when queried for localhost names, > making non-conformant stub resolvers more likely to fail and produce > problem reports that result in updates. > > Together, these requirements would allow applications and > specifications to join regular users in drawing the common-sense > conclusions that "localhost" means "localhost", and doesn't resolve > to somewhere else on the network. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-let- > localhost-be-localhost/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dnsop-let-localhost-be-localhost-01 > https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-let- > localhost-be-localhost-01 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-let- > localhost-be-localhost-01 > > > 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 > --f403045d6ba2103614055c4a1cee Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As promised, here's an -01 that addresses the concrete= feedback in the adoption thread. A brief summary is in the doc=C2=A0https://tools.ietf.org/html/draft-ietf-dnsop-let-localho= st-be-localhost-01#appendix-B.1, but an even briefer summary is that it= removes the waffling on the secure delegation question by mandating the cu= rrent behavior of returning NXDOMAIN along with NSEC records constituting a= secure denial of existence. That seemed to me to be where the thread's= consensus landed.

I welcome any and all feedback on the= draft. :)

-mike

On Tue, Oct 24, 2017 at 2:17 PM, <= internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Domain Name System Operations WG of the IE= TF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Let 'localhost' be localhost.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Mike= West
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-dnsop-let-localhost-be-localhost-01.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 9
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2017-10-24

Abstract:
=C2=A0 =C2=A0This document updates RFC6761 with the goal of ensuring that =C2=A0 =C2=A0"localhost" can be safely relied upon as a name for = the local host's
=C2=A0 =C2=A0loopback interface.=C2=A0 To that end, stub resolvers are requ= ired to
=C2=A0 =C2=A0resolve localhost names to loopback addresses.=C2=A0 Recursive= DNS servers
=C2=A0 =C2=A0are required to return "NXDOMAIN" when queried for l= ocalhost names,
=C2=A0 =C2=A0making non-conformant stub resolvers more likely to fail and p= roduce
=C2=A0 =C2=A0problem reports that result in updates.

=C2=A0 =C2=A0Together, these requirements would allow applications and
=C2=A0 =C2=A0specifications to join regular users in drawing the common-sen= se
=C2=A0 =C2=A0conclusions that "localhost" means "localhost&q= uot;, and doesn't resolve
=C2=A0 =C2=A0to somewhere else on the network.


The IETF datatracker status page for this draft is:
https://datatracker.iet= f.org/doc/draft-ietf-dnsop-let-localhost-be-localhost/

There are also htmlized versions available at:
https://tools.ietf.org/htm= l/draft-ietf-dnsop-let-localhost-be-localhost-01
https://datatrac= ker.ietf.org/doc/html/draft-ietf-dnsop-let-localhost-be-localhost= -01

A diff from the previous version is available at:
https://www.ietf.o= rg/rfcdiff?url2=3Ddraft-ietf-dnsop-let-localhost-be-localhost-01<= /a>


Please note that it may take a couple of minutes from the time of submissio= n
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

--f403045d6ba2103614055c4a1cee-- From nobody Tue Oct 24 12:32:19 2017 Return-Path: X-Original-To: dnsop@ietf.org Delivered-To: dnsop@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1168513F82B for ; Tue, 24 Oct 2017 12:32:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150887353406.25144.9187006029654819543.idtracker@ietfa.amsl.com> Date: Tue, 24 Oct 2017 12:32:14 -0700 From: IETF Secretariat Archived-At: Subject: [DNSOP] Milestones changed for dnsop WG X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 19:32:18 -0000 Deleted milestone "Complete WGLC for dnsop-dnssec-roadblock-avoidance and send to IESG". URL: https://datatracker.ietf.org/wg/dnsop/about/ From nobody Tue Oct 24 13:18:57 2017 Return-Path: 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 C3672139938 for ; Tue, 24 Oct 2017 13:18:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, URIBL_BLOCKED=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 k4jO-MajKqCU for ; Tue, 24 Oct 2017 13:18:54 -0700 (PDT) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 929DD1394F2 for ; Tue, 24 Oct 2017 13:18:54 -0700 (PDT) Received: from [169.254.8.54] (50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id v9OKHWnV084238 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 24 Oct 2017 13:17:33 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141] claimed to be [169.254.8.54] From: "Paul Hoffman" To: "dnsop WG" Date: Tue, 24 Oct 2017 13:18:51 -0700 Message-ID: <7CCE8BB2-3851-42D7-AD01-225553C128B2@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.7r5425) Archived-At: Subject: [DNSOP] Moving towards completing draft-ietf-dnsop-terminology-bis X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 20:18:56 -0000 Greetings again. One of the last major large issues for draft-ietf-dnsop-terminology-bis is to re-look at issues that were brought up in the preparation of RFC 7719 but were deferred to the -bis document. I have recently discovered that us doing that deferral pissed off some folks pretty heavily, and for that I apologize. I hope that people on this list are still willing to engage on the last bits of this document so that we can finish it in the near term. To that end, I have opened up four issues in the GitHub tracker for things that I found we had deferred but not dealt with: https://github.com/DNSOP/draft-ietf-dnsop-terminology-bis/issues/32: superordinate and subordinate https://github.com/DNSOP/draft-ietf-dnsop-terminology-bis/issues/33: Four new terms about queries https://github.com/DNSOP/draft-ietf-dnsop-terminology-bis/issues/34: Split out error names in their own terms https://github.com/DNSOP/draft-ietf-dnsop-terminology-bis/issues/35: Clarifying "referral" Please comment here on the list or in GitHub if you have any opinion about them. Personally, I believe all should be acted on. Also, if you have the stomach for it, please review the entire draft-ietf-dnsop-terminology-bis (yet?) again and see if there are issues you remember from before that weren't brought up, or new issues that should be brought up now. This time, there is clearly no rush like there was before, and it would be good to get it more right this time. --Paul Hoffman From nobody Wed Oct 25 13:16:07 2017 Return-Path: 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 E65031395E9 for ; Wed, 25 Oct 2017 13:16:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-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 m7X6UZIVgslh for ; Wed, 25 Oct 2017 13:16:05 -0700 (PDT) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 EEDC21393A1 for ; Wed, 25 Oct 2017 13:16:04 -0700 (PDT) Received: from [10.32.60.146] (50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id v9PKEgWr088396 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 25 Oct 2017 13:14:43 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141] claimed to be [10.32.60.146] From: "Paul Hoffman" To: dnsop Date: Wed, 25 Oct 2017 13:16:02 -0700 Message-ID: <04C3E53E-985F-49DD-A731-A2DE0911538B@vpnc.org> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.7r5425) Archived-At: Subject: Re: [DNSOP] Working Group Last Call - draft-ietf-dnsop-rfc5011-security-considerations X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Oct 2017 20:16:06 -0000 On 18 Oct 2017, at 4:16, tjw ietf wrote: > This starts a Working Group Last Call for: > draft-ietf-dnsop-rfc5011-security-considerations I support the publication of draft-ietf-dnsop-rfc5011-security-considerations either as-is or with an additional section on looking at timing from a second perspective (as detailed by Mike StJohns). --Paul Hoffman From nobody Thu Oct 26 08:12:25 2017 Return-Path: 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 39B1E13F1EB for ; Thu, 26 Oct 2017 08:12:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=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 pt2AFk-6vjTq for ; Thu, 26 Oct 2017 08:12:22 -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 949D813F0A8 for ; Thu, 26 Oct 2017 08:12:22 -0700 (PDT) Received: by mail-wr0-x22d.google.com with SMTP id r79so3486631wrb.13 for ; Thu, 26 Oct 2017 08:12:22 -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; bh=nEryVILhK8ITDqTRGgXorhplG+1e5LjJAjQrikNmSw4=; b=urKJFcoWOCuRnPEhwmcFX+XpLURcUSjmRhaTf79gkOs+3/+zCenUiIr5soQot1R5bx d+cHdid9+9nTuzOUDdmFQlEkEWywSSt+vfbCREKXJTVsoKSs+GdvB8tNAt3HRSn6+ZoJ k62/qNpCg73lEV0idw7X5ADjNTFL4SU2TDZpUTYpStSTHIOozi4miHHR3PDTOwTlzpLH Rro6E7auLZdh01/5fSPcJRWXuxI1gQNaYXjnvV8ePyfEJrNfCy+Cr+mTFFD+H2og9gIp cwL8pEslT+RstevUYxqGaUu/OcqDHLWa0eGez+C8RddWA78OzY2S3bFMs0c8X0Pm1yhe h1pA== 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; bh=nEryVILhK8ITDqTRGgXorhplG+1e5LjJAjQrikNmSw4=; b=HGZi7RZ1H3IcfL3MxUcXRqdvl6cotX2u33R/2mPTXBeoHyXvT3oBANEWVQJyy/bnqP 5EZGfILDKmvSK/L2mdY+Ywn7fAFFZQ/DdOznyEUFp/HoUUrPFDpgLwMlwy/kp3bwo4bI sEVD7+/52mFG4gyik1dN4K+2Vujx6hmUljYzJAfLFE9tHAr461r1Ul3bIrLr6750x3HZ lmHwKAEgtX/ms2ShwcPccU6xhqQ4h10mUXDP7AnWZ/7rZydFSSGJehOt4BqWk4Q51V4A E+317h/VKf+B/rOCye1pjKHA9Q2zXJb6RqkPxuakkGB2DoIVxCGrT/6gNwuV3xYAG175 rjaw== X-Gm-Message-State: AMCzsaXl0ajCGRNe5KIf90Z8mx616ViiejIAYT/fRF5ewe+KfUgD1HoU 0TJ2RL/sT9IiRuqT4ONVIneSlytuVAnc++AFe/JjxO7P X-Google-Smtp-Source: ABhQp+TBQekppxN5KpQehk/0mcvwXIAJMea1IeypvCBi9udIJI3K7tzXCZPxPxgNG7udJwwI+V9tzz3YyQcmR98bCUQ= X-Received: by 10.223.151.198 with SMTP id t6mr5849705wrb.2.1509030737630; Thu, 26 Oct 2017 08:12:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.187.12 with HTTP; Thu, 26 Oct 2017 08:11:35 -0700 (PDT) In-Reply-To: <04C3E53E-985F-49DD-A731-A2DE0911538B@vpnc.org> References: <04C3E53E-985F-49DD-A731-A2DE0911538B@vpnc.org> From: Warren Kumari Date: Thu, 26 Oct 2017 11:11:35 -0400 Message-ID: To: Paul Hoffman Cc: dnsop Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [DNSOP] Working Group Last Call - draft-ietf-dnsop-rfc5011-security-considerations X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 15:12:24 -0000 On Wed, Oct 25, 2017 at 4:16 PM, Paul Hoffman wrote: > On 18 Oct 2017, at 4:16, tjw ietf wrote: > >> This starts a Working Group Last Call for: >> draft-ietf-dnsop-rfc5011-security-considerations > > > I support the publication of > draft-ietf-dnsop-rfc5011-security-considerations either as-is or with an > additional section on looking at timing from a second perspective (as > detailed by Mike StJohns). Thank you, Paul. Dear WG - I know that this document has a limited audience, is kind of an annoying read, and is filled with maths (gasp!). Wes and I do believe that this is an important document - getting these timers wrong potentially has really bad security implications; there was intended to be a companion document to RFC5011, but seeing as that wasn't created, I think it is really importantt that we address this. So, pretty please, review this document and send feedback. We've tried hard to make it readable, but the topic is unfortunately complex and can only be simplified so far - it is also really hard to talk about sliding windows of time. So, again, please review and comment, W > > --Paul Hoffman > > > _______________________________________________ > 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 From nobody Thu Oct 26 10:42:50 2017 Return-Path: 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 7FE1013F421 for ; Thu, 26 Oct 2017 10:42:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.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 WCqw5F4gsfV1 for ; Thu, 26 Oct 2017 10:42:46 -0700 (PDT) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (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 5F25213F3C7 for ; Thu, 26 Oct 2017 10:42:46 -0700 (PDT) Received: by mail-qt0-x234.google.com with SMTP id n61so5318371qte.10 for ; Thu, 26 Oct 2017 10:42:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=TwaKZXIvj4llNYaXKYzuTTrgXT2j5WfICVKuP2StuhQ=; b=aDYF8OBHcCCnO6SO9cMTaANNcN5tgZMS8ZrcU+xYEOnK1lo4fqnsSwDnD8CwVf/VjM k9HRNJwf0bn8LtnEbYmzEVP2LDytR//idGxB/Xq1EJvv4vfPTbLj1l+bCSIctZErtqv4 8sr4GSrZtNbtqLi+W97pVD0FINtGTxsRPWgV0tUrfjPYTLuTSGw1HunXGJm0qeJjWSJC 6qhsxzYttV1ZyvXGGiAXIxj1rNRx5rTdjaC6NfDVSfxDyuNuT3e4Vw5L0yqKDFjgBrkw +rkExW/4fMj8hVQYWo9gKCpiVnRMHRL8qBT5Gcy1SVXRqL+6sKphQCQKBmVciygDMApe /1KQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=TwaKZXIvj4llNYaXKYzuTTrgXT2j5WfICVKuP2StuhQ=; b=C8dPWID4HoVd0TKikUNAzzQx3uRTfuyCf+OfU0Ttm5CX98nbV9CVl03/OgQ3kE2mCb Oa495QX29MOru0kSBI+dfIudsf5/htEieO9vwyKQsdkfB8AR9SSCu769ReRM7/QPbVBt jvx7H4oYooFY0hj7MsX/WFFeEE/6RXvP1y7othudbKVgOvtcbxqiTthYFnXUiwQaqs9H 1m+YW+pctHIdwER/f3UvQUa5BXwjTfD4ob0oWMRhKI3plb/7mIyEFuyjYPBVV+i9cDUo neO1tQ9u9min/X8uQLrR9UNmvzfJJpxNdl7dm8scHcZOkSTUPJQTUlGTMqAVKCy4L5VF AFPw== X-Gm-Message-State: AMCzsaWQbHxWnSR7bYPl/M1YPIdtFb98dSn672HlbLn9ZSUw4/bJKQkX UfUw921kXmXqRobC7JLwppSyCDeZ X-Google-Smtp-Source: ABhQp+Qgk3WI4NwW23rC50QKWA5dqZ2zxDETCbh+rHlyUVFtOYWNAVJMzipk+1Sfld6vI1jI20KtsA== X-Received: by 10.200.43.26 with SMTP id 26mr39354933qtu.51.1509039764925; Thu, 26 Oct 2017 10:42:44 -0700 (PDT) Received: from [192.168.1.115] (c-69-140-114-191.hsd1.md.comcast.net. [69.140.114.191]) by smtp.gmail.com with ESMTPSA id n131sm3606461qke.48.2017.10.26.10.42.43 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Oct 2017 10:42:43 -0700 (PDT) To: dnsop@ietf.org References: <04C3E53E-985F-49DD-A731-A2DE0911538B@vpnc.org> From: Michael StJohns Message-ID: <61d64c0a-ebd8-528c-5255-ec5205405fdc@nthpermutation.com> Date: Thu, 26 Oct 2017 13:42:42 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------36F17CFEE38C48F92949D868" Content-Language: en-US Archived-At: Subject: Re: [DNSOP] Working Group Last Call - draft-ietf-dnsop-rfc5011-security-considerations X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 17:42:48 -0000 This is a multi-part message in MIME format. --------------36F17CFEE38C48F92949D868 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 10/26/2017 11:11 AM, Warren Kumari wrote: > Wes and I do believe that this is an important document - getting > these timers wrong potentially has really bad security implications; > So, pretty please, review this document and send feedback. We've tried > hard to make it readable, but the topic is unfortunately complex and > can only be simplified so far - it is also really hard to talk about > sliding windows of time. *sigh* It's really not complex and its neither a timer nor an interval nor a window - but a fixed point in time given the input data: earliest date when its safe to revoke ALL old trust anchor keys ::= latest expiration date of any RRSet containing the key(s) to be revoked + queryInterval (from 5011) + holdDownTime (from 5011) + queryInterval (from 5011) earliest date when the zone owner thinks its safe to revoke all the old keys ::= the above + safetyFactor The first query time is the maximum time it takes for all resolvers to make their first query (assuming no retries).  The second query time is the time for all resolvers to make the "next query after the hold down time expires" (again assuming no retries). The safety factor is there primarily to deal with network outages AT THE RESOLVER and is a SWAG that should represent a value that captures the answer to the question "given the retry interval and a 99% network uptime and N resolvers, how long until 99.99% of the resolvers have completed all necessary retries at both the beginning and the end of the process?"  Like most retry questions, this has a bi-modal answer - given a reliable network, the vast majority of resolvers will be successful in small multiples of the retry interval.   A very tiny few will not be successful even after 100s of retries.  The SWAG should pick a number of retries that balances the operational need to complete the process with the possibility of a few resolvers not getting the word. so:  safetyFactor ::= retryInterval (from 5011) * (5 + func(N)) - 5 is a SWAG to set a minimum for even a small group of resolvers. I was thinking Log2(N) - which would give 23 for 10 million resolvers or 28*retryInterval.   Or something suitably non-linear.... Note that "latest expiration date of any RRSet containing the key(s) to be revoked" makes a worst case assumption:  that the pre-signed RRSets are not necessarily protected from disclosure.    If this is not true, then this reduces down to "the latest expiration date of any RRSet containing the keys to be revoked that has been seen publicly".  The document SHOULD assume that any signed RRSet may be available to an attacker whether it's been published in the DNS or not. 5011 was a timer based document because it applied to each resolver in each resolver's time domain.  When a timer fired on resolver A, it had no impact on the behavior of resolver B nor on the DNS server that was being queried. With this document, the 5011 timer intervals are useful only to figure out an earliest possible safe date given the previous live data set.  When that  (those) data set become irrelevant for the purposes of Wes' attack is pretty straight forward: when it expires!   The 5011 intervals can be used to calculate forward from that DATE and TIME to get an idea of when most well-behaving resolvers will have accepted new trust anchors even if they were being attacked.  Note "most".  There is no guarantee that even if you waited 6 years that all resolvers would get the new trust anchors and you just need to accept that the fall back is for the resolver owner to fix the problem when it occurs. This discussion has been helpful because it forced me to consider two things the root does that I never contemplated in 5011:  1) A steady state of a single trust anchor and 2) pre-signing RRSets. Neither of these affects the resolver implementation, but both make the publishing/signing schedules more security sensitive - hence this document. Later, Mike --------------36F17CFEE38C48F92949D868 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 10/26/2017 11:11 AM, Warren Kumari wrote:
Wes and I do believe that this is an important document - getting
these timers wrong potentially has really bad security implications;

So, pretty please, review this document and send feedback. We've tried
hard to make it readable, but the topic is unfortunately complex and
can only be simplified so far - it is also really hard to talk about
sliding windows of time.


*sigh*


It's really not complex and its neither a timer nor an interval nor a window - but a fixed point in time given the input data:

earliest date when its safe to revoke ALL old trust anchor keys ::= latest expiration date of any RRSet containing the key(s) to be revoked + queryInterval (from 5011) + holdDownTime (from 5011) + queryInterval (from 5011)


earliest date when the zone owner thinks its safe to revoke all the old keys ::= the above + safetyFactor

The first query time is the maximum time it takes for all resolvers to make their first query (assuming no retries).  The second query time is the time for all resolvers to make the "next query after the hold down time expires" (again assuming no retries). 

The safety factor is there primarily to deal with network outages AT THE RESOLVER and is a SWAG that should represent a value that captures the answer to the question "given the retry interval and a 99% network uptime and N resolvers, how long until 99.99% of the resolvers have completed all necessary retries at both the beginning and the end of the process?"  Like most retry questions, this has a bi-modal answer - given a reliable network, the vast majority of resolvers will be successful in small multiples of the retry interval.   A very tiny few will not be successful even after 100s of retries.  The SWAG should pick a number of retries that balances the operational need to complete the process with the possibility of a few resolvers not getting the word.

so:  safetyFactor ::= retryInterval (from 5011) * (5 + func(N))  - 5 is a SWAG to set a minimum for even a small group of resolvers.


I was thinking Log2(N) - which would give 23 for 10 million resolvers or 28*retryInterval.   Or something suitably non-linear....


Note that "latest expiration date of any RRSet containing the key(s) to be revoked" makes a worst case assumption:  that the pre-signed RRSets are not necessarily protected from disclosure.    If this is not true, then this reduces down to "the latest expiration date of any RRSet containing the keys to be revoked that has been seen publicly".  The document SHOULD assume that any signed RRSet may be available to an attacker whether it's been published in the DNS or not.

5011 was a timer based document because it applied to each resolver in each resolver's time domain.  When a timer fired on resolver A, it had no impact on the behavior of resolver B nor on the DNS server that was being queried.

With this document, the 5011 timer intervals are useful only to figure out an earliest possible safe date given the previous live data set.  When that  (those) data set become irrelevant for the purposes of Wes' attack is pretty straight forward: when it expires!   The 5011 intervals can be used to calculate forward from that DATE and TIME to get an idea of when most well-behaving resolvers will have accepted new trust anchors even if they were being attacked.  Note "most".  There is no guarantee that even if you waited 6 years that all resolvers would get the new trust anchors and you just need to accept that the fall back is for the resolver owner to fix the problem when it occurs.

This discussion has been helpful because it forced me to consider two things the root does that I never contemplated in 5011:  1) A steady state of a single trust anchor and 2) pre-signing RRSets.  Neither of these affects the resolver implementation, but both make the publishing/signing schedules more security sensitive - hence this document.

Later, Mike





--------------36F17CFEE38C48F92949D868-- From nobody Fri Oct 27 06:10:33 2017 Return-Path: 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 1BD9C13F4CE for ; Fri, 27 Oct 2017 06:10:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] 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 l0FGNcHiKk2r for ; Fri, 27 Oct 2017 06:10:30 -0700 (PDT) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (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 8E6D813955B for ; Fri, 27 Oct 2017 06:10:30 -0700 (PDT) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 1F9E3281DC5 for ; Fri, 27 Oct 2017 15:10:29 +0200 (CEST) Received: by mx4.nic.fr (Postfix, from userid 500) id 16C3A281DC6; Fri, 27 Oct 2017 15:10:29 +0200 (CEST) Received: from relay01.prive.nic.fr (relay01.prive.nic.fr [IPv6:2001:67c:2218:15::11]) by mx4.nic.fr (Postfix) with ESMTP id 10049281DC5 for ; Fri, 27 Oct 2017 15:10:29 +0200 (CEST) Received: from b12.nic.fr (b12.users.prive.nic.fr [10.10.86.133]) by relay01.prive.nic.fr (Postfix) with ESMTP id 0D064642C582 for ; Fri, 27 Oct 2017 15:10:29 +0200 (CEST) Received: by b12.nic.fr (Postfix, from userid 1000) id 01761409F5; Fri, 27 Oct 2017 15:10:28 +0200 (CEST) Date: Fri, 27 Oct 2017 15:10:28 +0200 From: Stephane Bortzmeyer To: dnsop@ietf.org Message-ID: <20171027131028.4is4yob3o5ih55go@nic.fr> References: <150887353406.25144.9187006029654819543.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <150887353406.25144.9187006029654819543.idtracker@ietfa.amsl.com> X-Operating-System: Debian GNU/Linux 9.1 X-Kernel: Linux 4.9.0-3-amd64 x86_64 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: NeoMutt/20170113 (1.7.2) X-Bogosity: No, tests=bogofilter, spamicity=0.000002, version=1.2.2 X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2017.10.27.130016 Archived-At: Subject: Re: [DNSOP] Milestones changed for dnsop WG X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 13:10:32 -0000 On Tue, Oct 24, 2017 at 12:32:14PM -0700, IETF Secretariat wrote a message of 9 lines which said: > Deleted milestone "Complete WGLC for dnsop-dnssec-roadblock-avoidance and > send to IESG". > > URL: https://datatracker.ietf.org/wg/dnsop/about/ Is it a bug or an human error? The only milestone (three years late) is draft-ietf-dnsop-dnssec-key-timing (was actually published as RFC 7583)? What about the stuff in ? From nobody Fri Oct 27 10:08:49 2017 Return-Path: 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 B0BA7138F21 for ; Fri, 27 Oct 2017 10:08:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] 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 rlWKpgYBl7nK for ; Fri, 27 Oct 2017 10:08:44 -0700 (PDT) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (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 75300138A38 for ; Fri, 27 Oct 2017 10:08:44 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id b189so4695976wmd.4 for ; Fri, 27 Oct 2017 10:08:44 -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; bh=yzJZSeriWKCqZwJ6ZlmrrQLbUvC9qq1sxXQrfbg2Pas=; b=SA/DlxwAHRmbD0nfhV5xmsn/+EUawqtsuG+uI/dOVC7mqbyxOWqsZ21tgwTXXEtxai tWvZleCCPDumQwEp12OB5HFPVokPkufwqzQuoJk1Hq+VcAGlpMd0nauLhfCic+lRnoIH j/m7R9dvDt3UD8J39Cw1XgQ9FvvbjjaC2LRbeZjlHH5CyQ3P6cioPckUsRJk5OATDaKp yNYMAcSo9/2MWYvDNctgDoXROoRHlqEnEcVS8UGbP8epRTpeyf6RC5v9tXMNSieK3eQL FZ/OU3A6x6fRxBByrBtogHspkQ6Re/G0OWt8V0O5mfHxWtle/ab3TFzvUm4QwimMIkqz +LOA== 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; bh=yzJZSeriWKCqZwJ6ZlmrrQLbUvC9qq1sxXQrfbg2Pas=; b=JapEbRoApiojOty+06yfwf6Kg+cxH0ZpvLEQ1zn6Nf8FZD1haEMBoIcfJGfhAMWZCa zgobGqMf2x4qs3Kg2a2w1eBb2KLjfajXEFqSxV6ARePjRBeBlTgBYX1bgAusV0LArgpG jIHWJ+8FcZeSN6u36TSwq74lCnlxxiShNnQVEUeXwRLsVPT3z9oNXaLUH0PDmw7pfurv fjM7KGizAeom4Pv0fV6HGsoR5YtfaVtaXTPAsNS+Oyrtb2Z77K4wNCOCvp4AN1MRF+yM dKBayvQryZnWpK8/SzvribmbF0HKw09wLbDuezSWXySgm3HioUgVjQnfVeo+l1ULORAK HQfg== X-Gm-Message-State: AMCzsaUhoxG5VvCLTUCMHXXz4LcDktOv+SzVtclOvbrJX2w0MsBaoqCV 4kxDYL0pXcXYRuld23AzlxgL8HZgdQS6PK7X7M9iJQ== X-Google-Smtp-Source: ABhQp+Qh+/LtneD4LOo7oGhvhqfst6qm1T/i1tQ/czI4Tel+8D1ocMQAlkRyJ/0B+3DdayUyPIfu+V5DbbGIATKtB1w= X-Received: by 10.28.26.138 with SMTP id a132mr1002114wma.124.1509124122598; Fri, 27 Oct 2017 10:08:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.187.12 with HTTP; Fri, 27 Oct 2017 10:08:01 -0700 (PDT) In-Reply-To: <20171027131028.4is4yob3o5ih55go@nic.fr> References: <150887353406.25144.9187006029654819543.idtracker@ietfa.amsl.com> <20171027131028.4is4yob3o5ih55go@nic.fr> From: Warren Kumari Date: Fri, 27 Oct 2017 13:08:01 -0400 Message-ID: To: Stephane Bortzmeyer Cc: dnsop Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [DNSOP] Milestones changed for dnsop WG X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 17:08:48 -0000 On Fri, Oct 27, 2017 at 9:10 AM Stephane Bortzmeyer wrote: > > On Tue, Oct 24, 2017 at 12:32:14PM -0700, > IETF Secretariat wrote > a message of 9 lines which said: > > > Deleted milestone "Complete WGLC for dnsop-dnssec-roadblock-avoidance and > > send to IESG". > > > > URL: https://datatracker.ietf.org/wg/dnsop/about/ > > Is it a bug or an human error? The only milestone (three years late) > is draft-ietf-dnsop-dnssec-key-timing (was actually published as RFC > 7583)? This was my fault -- the chairs had an arrangement with Joel to not do milestones; I knew about this, but forgot... The secretariat sent out a reminder email on how to find milestones which ADs need to approve - I hit the button and it sent the above mail. > > > What about the stuff in > ? Yup - DNSOP is an ops type WG, and so takes on and deals operational issue type documents; we don't really map out our plans for the next N years. There are a significant number of documents in flight, and so constantly adding, approving, closing milestones is more admin faff than needed -- however, we do seem to have lost momentum getting documents over the final hurdles, and so the plan is for the chairs, secretary and myself to sit down in Singapore and figure out how to better track things and stop documents slipping through the cracks. So, sorry for the random closing of an old milestone, the current milestones don't actually reflect what the group is working on (which may or may not be an issue), and we're planning on figuring out how to not lose momentum in the future. W > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop From nobody Fri Oct 27 14:10:49 2017 Return-Path: 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 09C5513B144 for ; Fri, 27 Oct 2017 14:10:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.272 X-Spam-Level: X-Spam-Status: No, score=-0.272 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_HK_NAME_DR=0.01] autolearn=no 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 DKSdATQ6Spxi for ; Fri, 27 Oct 2017 14:10:46 -0700 (PDT) Received: from mail.katezarealty.com (mail.katezarealty.com [104.168.158.213]) by ietfa.amsl.com (Postfix) with ESMTP id 944091386A1 for ; Fri, 27 Oct 2017 14:10:46 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mail.katezarealty.com (Postfix) with ESMTP id C56723741019 for ; Fri, 27 Oct 2017 21:10:45 +0000 (UTC) X-Virus-Scanned: amavisd-new at katezarealty.com Received: from mail.katezarealty.com ([127.0.0.1]) by localhost (mail.katezarealty.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id uAYCbl-rD8nN for ; Fri, 27 Oct 2017 17:10:40 -0400 (EDT) Received: from maxs-mbp.cablelabs.com (unknown [192.160.73.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.katezarealty.com (Postfix) with ESMTPSA id 137B53741015 for ; Fri, 27 Oct 2017 17:10:40 -0400 (EDT) To: DNSOp WG From: "Dr. Pala" Organization: OpenCA Labs Message-ID: Date: Fri, 27 Oct 2017 15:10:39 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030803000802090100020201" Archived-At: Subject: [DNSOP] New I-D for OCSP over DNS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 21:10:48 -0000 This is a cryptographically signed message in MIME format. --------------ms030803000802090100020201 Content-Type: multipart/alternative; boundary="------------D2F817BFDDE53EB777443C1B" Content-Language: en-US This is a multi-part message in MIME format. --------------D2F817BFDDE53EB777443C1B Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hello all, As suggested by some people from other WGs, I just wanted to cross-post=20 this message here since the proposal heavily rely on DNS and can be=20 leveraged in many different environments (e.g., Server and Client=20 (browsers) authentication, document validation, IoT identities, etc.)=20 and we would like to receive feedback from anybody who might be=20 interested in the topic. *Context. *We are currently working on specifying how to use DNS as a=20 transport protocol for revocation information for digital certificates.=20 In particular, we are working on how to leverage the distributed nature=20 of DNS to efficiently (and possibly at a lower operational costs)=20 distribute OCSP (Online Certificate Status Protocol) responses to=20 applications/devices/etc. *Current Status.* We started this work sometime ago but never really had = the time to finish it. Now it seems we can focus more on the topic and=20 would like to discuss this work in a more public venue. We have recently = updated the two competing I-D we submitted sometime ago into the latest=20 reference I-D that is available here: https://datatracker.ietf.org/doc/draft-pala-odin/ Please feel free to contact us for any help (you might require or you=20 might provide), feedback, etc. Thanks, Max --=20 Best Regards, Massimiliano Pala, Ph.D. OpenCA Labs Director OpenCA Logo --------------D2F817BFDDE53EB777443C1B Content-Type: multipart/related; boundary="------------60832DBAEEB62BFFB8F48645" --------------60832DBAEEB62BFFB8F48645 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hello all,

As suggested by some people from other WGs, I just wanted to cross-post this message here since the proposal heavily rely on DNS and can be leveraged in many different environments (e.g., Server and Client (browsers) authentication, document validation, IoT identities, etc.) and we would like to receive feedback from anybody who might be interested in the topic.

Context. We are currently working on specifying how to use DNS as a transport protocol for revocation information for digital certificates. In particular, we are working on how to leverage the distributed nature of DNS to efficiently (and possibly at a lower operational costs) distribute OCSP (Online Certificate Status Protocol) responses to applications/devices/etc.

Current Status. We started this work sometime ago but never really had the time to finish it. Now it seems we can focus more on the topic and would like to discuss this work in a more public venue. We have recently updated the two competing I-D we submitted sometime ago into the latest reference I-D that is available here:<= /p>

=C2=A0=C2=A0=C2=A0 https:= //datatracker.ietf.org/doc/draft-pala-odin/

Please feel free to contact us for any help (you might require or you might provide), feedback, etc.

Thanks,
Max

--
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
3D"OpenCA
--------------60832DBAEEB62BFFB8F48645 Content-Type: image/png; name="nkhgjfmakgmiagai.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="nkhgjfmakgmiagai.png" iVBORw0KGgoAAAANSUhEUgAAAGQAAAA2CAMAAAAGesyaAAADAFBMVEUsJiEAAQAKAwMABwoX BwESCQAqDgEkEQItFQESGykaGh0WGyE1FwE9GwJHHwElJiY4JBQmKDE1KCAfLUQ8KygoMEAq MjpXKgs/MilMMR0pOFEyOUo4OTo1OkRqMgpjOBlpNxUwQV1DPz48QExdOyM4QVV+OQRRQzo1 SGdDR0lDSFJfRDFASVyaPwF+RRpNT1I9UXlwSi8+UnNDUm6hQgCPRhBdUEZTUlBKVGlPVF27 PgCaSANtUT57VBerSQOMUgxHW4KMUiepTwmJVDh6WT6KVjGCWDpRYH21TwFiYF57YgJXYXae VR+lVRZrYld1ZiB7YEuSYQBgZW+8VAlkZWjBVQCfXiqqXwG1WhPLVgedYDazXiDZVgCWZEDV WQJ1blapYjbXWgDRXACMaU6WbgCiZjnIXw9mcIixZC6pZjJ/cUeLbFdycmZ4cGnnWwNwc3Wq aS6BcGeobwndXwzkXwLgYgDaYwyMeCq/bQHJaBi9ajDMagWVegvRZxzVaAvXaQDLainqZAuv cEPrZQDQaSyockrFbSvmZwnabQLvZwDpaQB0fpPkaxGld1d+f3/3aACfeV6RfG2JfnLebSF7 gYy2fQmugQCigxW8d0K3eEr1bQXaciTicRqKgnzNewHuchbUdzKYiDzrdwKah1erjAvOfEXl eSq5g1qYjGikiHO2kADigwC2hmSZjIGGj6aHkJzQiwCximixim/EkAORkZGVkYrOh0rPiVL5 giTvhDKkk4LMjF23mR+zmTrhikrviDzsi0TAlHDCnwvKlGqpnJLdlF2boKy+m324nImkoZ+e o6XKpgrloATwl1WypZPOn3zfqQjYrgLBrVDdo3nGq5mysa/SrI7dq4bqqXTOrpWttL+6s6uw tbe/t4rhvALetpjQuqnuwwe9v8LAv7vauqD3xA68w9XBw83rvJfRwbXFyMvbxbPNyMP8zgTc zMDr0mb91xLM1ODQ1NfS1c7p0sD70bPd19PX4qj83cje4+Xr4tv54NLp7/Hy9PHw9fj6/v3Y ktvJAAAAAXRSTlMAQObYZgAAAAFiS0dEAIgFHUgAAAjrSURBVFjDtVcNWFPXGT6E+l9BZ0EF sTKEIQaUAIrTZdYqxqG0I3UjIuiDM0ipoyO5l0rFh2PE472EoIJKL9hQV2OxqM+USgFL4r9g EaIoQxgqKBZBR+nGGhXYdwNro0Kfkcp3ntzce/7e8/2e70PoJVDl3bMlZyurUSsaKnqESrMp lYrByozCjUOEUZORodMRVsViTjJc8GbLUGCUUstLv1SyLCGch8DGRiDPe/kY5/2HCQQTxZEE y4fb2gDI8KjjLxsjfyyc3lZgM3KixwgeY4TEzk7+kjHODbeb6u0xAhiw8XgFMOxolpP6J75U jLZfp6dzHIcBYCQbIBB4sCxDOLK6eMAVT39it57+e09ysCnDUtnrJ0vS5ZMW0PBFWDbd40G/ 85sH2KeXvj94u/flX8/2J6kYQkhkHbzWbkdH0N0UDN8sURS8uMd9dMzPL7BxIIjOayuWLBIf 70RPUPjxLouBEgVhMaYuWXQlMjwsN+eFTR4cDZ4werRDYOoAIFkrptm/Ni0gthOt9Q4yWQxc AwyWTbacW0sTDGoJen4P002/2S7LjgV6BpY1N6OO5g5eeiZTY/P9b1FzRwfKWuk9p/72ct+N puKpq32qLVaexOCCJB91aezt5y6zt7fXILSdJZjlVr1w0mCR66x6FL3QOXiUQ2a0k/sFlDlq 1LzUMQ4uxxycjl0LWO1bBsY6yXR3wSTJGxqLhdsJHDsS9cwF47XlvcQGQiXhRbih/HkQv4XO cajZb6GDu7PTFEdPkVu0k4vQyd3Jc/SUwNnB+RJ/XsI9ptZDIxMly3dbLNwGnGBJF+Id3cZM 9ui8Gjq5P/TDiRCegbOFgSKRo5e7yNHV2dnPdVb0bHfHQCevNIV/rxqrX48oFQdYcpKMtYRb juxtfqRypNACK28+j3FsqcilAD0ADuIWCt0yRa7zRNEOY2YELhW5CV2dXVKixH8BC+s8GDN9 wWKxf94zpsRiJuWmBYjgndsKFmu5Bc+D3HQXCcu7QTFTMl3HF0SLxruLvGa4zUqdMGFWqqfX 3GSxN0y6NT154i+v75zvH2thXiWgY2YVElhwYl9NYxarlr0grlQn92DQt1vBUk+nUFeHGZme gUIvl1RXr1AnV/fx6zd4v3HptM/YaXbrzmYFePu2WpowYRlJo+2PGLb2d9WE5bw1L4DcnOco 9HIcH3o02HOecMqMJhQqdLPXpArHl2uEo+Na8qZPXxw0+bVx46bFzhw3eZylM2dgwkbWW3Iy Jp9lMDe9H2/raiqPCy5/fHSCu+M7mkffoQuzQhvRhWVlj1FcWTfq6dwdElJmarxedr/u3P6C Nn7Fk95ol8wRjIMsOLGJSwLm/OMGjlFHJ7hqelDuxdMlpbU16JvqlJTamivoBjrfUgNB69zf b6Fr1TWPKmtOw9xCdLayEFWvBlaSfmEBsk6LSdTMNnQaldTe7Qfj20yveddR2toVEevCi9/f fmntR7ErtvompmyICM9qyYpZsG3FhqwNYRH5KUtyW7eGRRxfH1OHDv0ZXH6ihbSyVYzSY3Fu BkVR9LaS2wPxUxyTFpu2eGverr+dezvi0ttpOy/tTKlL2ZkWs6p4VV1Kyq60nevS8iLyi1tW hfNWzMfhYT+ArAQ+5odRBENjlRW5F/vH6O7u7urpXtvR/bQbmX/dPd3w7Ok+2Ij4ry5o0N/d Y1p7qA21FodhFRc1ctjIsXZ2Y18VcwCixNgcWlgVbUiue3b3J33te7497vv/oT1Bj5/7br1R grYlfrReSqmwPDyK0GqOUHKWj/RwP0J0ZlmsK3o2HP+7Qt9HBr3BYH5aNL3FG/+ul8sjKcxH dRJFGJkhfKxgmM2rUoaSg5h4GAwXJsF00dRGq+/21k2EF7o50oNswrNfsYUQKRBIZWIFh3lu aLNe1F++bjXGyWyzZiGoYFYLx5Ys4v0R3GWRdBHNErBiSiqVRhHMyeaYrMQ4SENWCvEcfhCm GIzpqKlm27KTSWUcAX1goBw5oATctDb33aLTYV5SWoaXP5+gyqlFdnZ23nB+plcnREv0RWJC BVkrrBJ1BewMmlVpgRUQF7wpItMJTcsJ34GBRVaFdQZaqoqxFmSb3qDQgu1A2GI4YAnODkQY IOhklDKzo2C1IV2sijzdhjorqwefNdL6ihxzegU7SynexHgBMXy+xWFG8qvdf91D8WpRi41q KFl02YaswYNkULTeLC9CFFK4bDHDMmZbhnuXSOdAsnN1LxgfVu7ZvG8LpSJUlO/gnaWQFwYv JpZeKdUaSC8ApuhIShYQYp5yWQ0oPgVXPtkcHz/fx5rqqzosHSSlBYHIxKSolJcUsIIpnzkh mt4b7Z/tOzBRQWaA6uNCNdet0nxLkL8CgzeQKIlCXaHjXR9MlqQn9Y1fNd5RE0zF/ryKwVR/ JMnsI3S8Umcw6NRYxRuUKqk3lfnKeGcTySAx5hy+7WfgZOv4uLLl0w8wUah71QLBpJeXq/eM VVivV8jz6lB2ofWF6i1dEYRZfMJ4piE+ZweNeb7A2VVyKEx6vjt1z/ghMehVKiUpyt1VYBXC N6j0Q4Mazp7TvvndhIaGhqqvP1bwFk0YRYR5RoLR+PkWmlIpV/oEDQ6jB9Wc3Z6bm6zLTtLl gLC4LVWXz5Q1ffbV5oZ24wmsV/NeKTlirmg+u/q7w7/38PDdeKF8UBgXs2kV4WUC0YR/KOLv Pby3L5O30yvG9vY/6vX8JSbb2je96coXX5QPznqfokKKEPWBAwd20ApaTWsP7LnTfsd42at3 +B+H7+zRUfwZZMutN6baHCX5+Ou9Zy4f3nuiKr7KaHxoNDbsSwhp6htvfyg3Zw901G+ttVlT Ja34/E+fvrXmvY3713xy6tSZfadOJby7X1P/vwn/MeaYr0mF7IMEq690Gu95KwQq5L5K+f59 qGUtaZMSciHMKjdVbY6zFqRC/pv3LgxY5tcW0pjIpGGJ7+89kxBnbXZSmjuz7CeyihyG8fbd XXYdrWlqQg+sZWTdzPqBB68VEdnkzDY0lHSjSD9/GRpaMt3OWqLpQENOTf/PpP8CK9ZVVe2a 8XoAAAAASUVORK5CYII= --------------60832DBAEEB62BFFB8F48645-- --------------D2F817BFDDE53EB777443C1B-- --------------ms030803000802090100020201 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfUwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggU+MIIEJqADAgECAhEA/bu0LJsAKXVhEpPllE0lYzANBgkq hkiG9w0BAQsFADCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3Rl cjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVt YWlsIENBMB4XDTE2MTEzMDAwMDAwMFoXDTE3MTEzMDIzNTk1OVowJDEiMCAGCSqGSIb3DQEJ ARYTZGlyZWN0b3JAb3BlbmNhLm9yZzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AKnGg/GUuTjn0dKCEpRhVd+uiYbCjLQht+dbkvyRLm4aqlL7yHCe+21HQLIcU68ZCHT2ImpF CFFrxQMQh4KijAwkbLc8+xZZSwXeZt58qnPn5c4vcpYU5LFq1q9oDT8MXH33DhVUT/7/IDSi wRWM6FcgM6VrIjBmmvl9dW3gQaEd1bOAhO2X489fChRQYTaB6AEhqb8RSvWW7ZYzfNw8sPxV afMCzWBPpO5RmLqOciZBhAinAM9dXmP5ckg/HjJQYSjvTc7HDcg75mpr5wH8Tk/ChyIYk4CT zqONQV8HKCzZPTVmd2ZuMrliJwMFs3uEg0aBSzHjJTyAmZ89q5Mz3XsCAwEAAaOCAfEwggHt MB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBTGgh9JWBvcrak1 PhAWBLGrECNAjzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYM KwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQv Q1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NI QTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUF BwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9T SEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUF BzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wHgYDVR0RBBcwFYETZGlyZWN0b3JAb3Bl bmNhLm9yZzANBgkqhkiG9w0BAQsFAAOCAQEAdIqtPcvA+g6VTYUpEo0I9Vtnrf9PiZ3OpkRL O7U78EaeUfvOotThqj74XyrIl6eYlg+EdGIIUVB1CI05wPMRlZN3/R/Tj28vWkwckLRIbpL4 A5ZQyKgA9vK15/EEBVFIpCtAI6xJX0zx6TySlIgjcca05L0JgO7nzLGD2MY/dVWEE+QBuNI+ NBci+c+9q6YDPoXOpo0Wwbe0Bq95jNNWmZwhGzc+N5rhOGZmQT4P7TnpzvMik8ugbkqWyyHa DQbLKYzM1RKS/mwcvFqjJCQgORnaCilSbfClwdWGI7vwcTR8eAzduvwG61u46Cgb57K5sMck RicpWRvEYxCCVTwnozGCBEQwggRAAgEBMIGxMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMS R3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8g Q0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0 aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQD9u7QsmwApdWESk+WUTSVjMA0GCWCGSAFlAwQC AQUAoIICYzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzEw MjcyMTEwMzlaMC8GCSqGSIb3DQEJBDEiBCA/zoLc2D+OBIhSTtDyUa2XdqKNEm4JRQ/lj6sp RUhWNDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3 DQMCAgEoMIHCBgkrBgEEAYI3EAQxgbQwgbEwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRp b24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAP27tCybACl1YRKT5ZRNJWMwgcQGCyqGSIb3DQEJ EAILMYG0oIGxMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0ECEQD9u7QsmwApdWESk+WUTSVjMA0GCSqGSIb3DQEBAQUABIIBACgHAxa6BsN9xkFT b1+78W1SfeDn6pHU0dvc+2Cv5lgu3QNtn0IMjCjV7yDKzSUDVmFALBL7Ccn2AGkI7pvn5JV7 yVj7SkcjSge1izj0NH2G3n6+ClEpFfTtW+jAO/SXI3IlzKlKE/L/iGFM/pV1nYS6jyaVk/L3 dgO6HAwyfEzFIKWEEpYOhpS13kZEdHhDTWILJej4fkqmPlx11n4eQkcbO48Gxp26txbcXxFo 8/SIH8g28cZr0hwA0fYRIPxupootYqBdfYaFxbsOd3KbH39pjXxyhMt+qqIE/kQziNLEFApe qpEO+9VEj8axmW44NWOHLF2RTgLQo9uumgKnAQIAAAAAAAA= --------------ms030803000802090100020201-- From nobody Sun Oct 29 05:12:56 2017 Return-Path: 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 DE2E813FDA6 for ; Sun, 29 Oct 2017 05:12:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_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 NNM8cil4yMjY for ; Sun, 29 Oct 2017 05:12:53 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B020B13FE71 for ; Sun, 29 Oct 2017 05:12:53 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 31F02B817AB; Sun, 29 Oct 2017 05:12:47 -0700 (PDT) To: olaf@nlnetlabs.nl, matthijs@nlnetlabs.nl, miek.gieben@sidn.nl, bclaise@cisco.com, warren@kumari.net, suzworldwide@gmail.com, tjw.ietf@gmail.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: andreas.cudok@googlemail.com, dnsop@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20171029121247.31F02B817AB@rfc-editor.org> Date: Sun, 29 Oct 2017 05:12:47 -0700 (PDT) Archived-At: Subject: [DNSOP] [Technical Errata Reported] RFC6781 (5174) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Oct 2017 12:12:55 -0000 The following errata report has been submitted for RFC6781, "DNSSEC Operational Practices, Version 2". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5174 -------------------------------------- Type: Technical Reported by: Andreas Cudok Section: Appendix B. Original Text ------------- is reduced to the following representation: SOA_2005092303 RRSIG_Z_14(SOA_2005092303) DNSKEY_K_14 DNSKEY_Z_15 RRSIG_K_14(DNSKEY) RRSIG_Z_15(DNSKEY) Corrected Text -------------- is reduced to the following representation: SOA_2005092303 RRSIG_Z_14(SOA_2005092303) DNSKEY_Z_14 DNSKEY_K_15 RRSIG_Z_14(DNSKEY) RRSIG_K_15(DNSKEY) Notes ----- Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6781 (draft-ietf-dnsop-rfc4641bis-13) -------------------------------------- Title : DNSSEC Operational Practices, Version 2 Publication Date : December 2012 Author(s) : O. Kolkman, W. Mekking, R. Gieben Category : INFORMATIONAL Source : Domain Name System Operations Area : Operations and Management Stream : IETF Verifying Party : IESG From nobody Sun Oct 29 23:24:40 2017 Return-Path: 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 3B09913F50F for ; Sun, 29 Oct 2017 23:24:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.999 X-Spam-Level: X-Spam-Status: No, score=-6.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-2.8, URIBL_BLOCKED=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 jIxNyuHoygqS for ; Sun, 29 Oct 2017 23:24:37 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (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 2F96F13968C for ; Sun, 29 Oct 2017 23:24:37 -0700 (PDT) Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v9U6OaTV007892 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Mon, 30 Oct 2017 06:24:36 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id v9U6Oawi006051 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Mon, 30 Oct 2017 06:24:36 GMT Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v9U6OZIU015657 for ; Mon, 30 Oct 2017 06:24:36 GMT Received: from [192.168.178.30] (/83.160.139.153) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 29 Oct 2017 23:24:34 -0700 To: dnsop@ietf.org References: <20171029121247.31F02B817AB@rfc-editor.org> From: Matthijs Mekking Message-ID: Date: Mon, 30 Oct 2017 07:24:32 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <20171029121247.31F02B817AB@rfc-editor.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Subject: Re: [DNSOP] [Technical Errata Reported] RFC6781 (5174) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 06:24:39 -0000 Hi, This errata appears to be valid. In addition, the following text must also be corrected, from: The rest of the zone data has the same signature as the SOA record, i.e., an RRSIG created with DNSKEY_K_14. to: The rest of the zone data has the same signature as the SOA record, i.e., an RRSIG created with DNSKEY_K_15. Best regards, Matthijs On 29-10-17 13:12, RFC Errata System wrote: > The following errata report has been submitted for RFC6781, > "DNSSEC Operational Practices, Version 2". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata/eid5174 > > -------------------------------------- > Type: Technical > Reported by: Andreas Cudok > > Section: Appendix B. > > Original Text > ------------- > is reduced to the following representation: > > SOA_2005092303 > RRSIG_Z_14(SOA_2005092303) > DNSKEY_K_14 > DNSKEY_Z_15 > RRSIG_K_14(DNSKEY) > RRSIG_Z_15(DNSKEY) > > Corrected Text > -------------- > is reduced to the following representation: > > SOA_2005092303 > RRSIG_Z_14(SOA_2005092303) > DNSKEY_Z_14 > DNSKEY_K_15 > RRSIG_Z_14(DNSKEY) > RRSIG_K_15(DNSKEY) > > Notes > ----- > > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC6781 (draft-ietf-dnsop-rfc4641bis-13) > -------------------------------------- > Title : DNSSEC Operational Practices, Version 2 > Publication Date : December 2012 > Author(s) : O. Kolkman, W. Mekking, R. Gieben > Category : INFORMATIONAL > Source : Domain Name System Operations > Area : Operations and Management > Stream : IETF > Verifying Party : IESG > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > From nobody Mon Oct 30 02:23:31 2017 Return-Path: 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 2ED2013B10E for ; Mon, 30 Oct 2017 02:23:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=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 ebJkK79t9XpF for ; Mon, 30 Oct 2017 02:23:27 -0700 (PDT) Received: from time-travellers.nl.eu.org (c.time-travellers.nl.eu.org [IPv6:2a02:2770::21a:4aff:fea3:eeaa]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 344CA13AC0E for ; Mon, 30 Oct 2017 02:23:27 -0700 (PDT) Received: from iceeecoldddd.billingeenvo.p3.tiktalik.io ([37.233.99.157] helo=[127.0.0.1]) by time-travellers.nl.eu.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1e96K9-0001hm-Em; Mon, 30 Oct 2017 09:25:37 +0000 To: "Dr. Pala" References: From: Shane Kerr Cc: dnsop@ietf.org Message-ID: Date: Mon, 30 Oct 2017 09:23:00 +0000 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [DNSOP] New I-D for OCSP over DNS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 09:23:29 -0000 Dr. Pala, Dr. Pala: > Hello all, > > As suggested by some people from other WGs, I just wanted to cross-post > this message here since the proposal heavily rely on DNS and can be > leveraged in many different environments (e.g., Server and Client > (browsers) authentication, document validation, IoT identities, etc.) > and we would like to receive feedback from anybody who might be > interested in the topic. > > *Context. *We are currently working on specifying how to use DNS as a > transport protocol for revocation information for digital certificates. > In particular, we are working on how to leverage the distributed nature > of DNS to efficiently (and possibly at a lower operational costs) > distribute OCSP (Online Certificate Status Protocol) responses to > applications/devices/etc. > > *Current Status.* We started this work sometime ago but never really had > the time to finish it. Now it seems we can focus more on the topic and > would like to discuss this work in a more public venue. We have recently > updated the two competing I-D we submitted sometime ago into the latest > reference I-D that is available here: > >     https://datatracker.ietf.org/doc/draft-pala-odin/ > > Please feel free to contact us for any help (you might require or you > might provide), feedback, etc. I had a quick look and have a few comments/suggestions. Some minor points, and then on to major issues.... Section 6.3, "Time Validity" might be tricky. Someone reading the specification may infer that authoritative DNS servers are supposed to look at the OSCP record and clamp TTL to the expiration of the OCSP response. While there is some precedence for this (in RRSIG records), those are limited to cryptography that is for the DNS itself. My recommendation here is that it be made clear that as an operational matter that operators ensure that the records are published in a way that the TTL is low enough that they expire from caches before the OCSP response expiration. Section 7.2, "Use of TXT Records" may hit a problem similar to what happened with the SPF record. In SPF (a mail authentication & authorization technology), early implementations used TXT records. The DNS community encouraged a switch to a "real" RRTYPE for this. However, what ended up happening is that implementations had to support SPF *and* TXT records. This was extra work and even extra packets on the wire, and eventually the next SPF revision deprecated the SPF type. If the OSCPRR is not yet widely deployed, I would suggest at the very least changing "MAY use TXT records" to "SHOULD NOT use TXT records". If it is widely deployed, then... ug. ;) Now on to the big stuff. :) I think that more work needs to be done explaining why DNS is a more efficient delivery mechanism than HTTP or some other technology. If the idea is that resolvers provide "free" caching close to the user then this may be reasonable. If the idea is that DNS is a simple UDP protocol, then this may quite possibly backfire when you stick largish cryptographic blobs into the DNS responses; DNS is probably less efficient than HTTP then because you'll get UDP responses that tell you to switch to TCP... instead of starting with TCP in the first place. Next, I think you may want to consider more security implications in pressing the DNS infrastructure into service as a critical component of a PKI infrastructure. Unlike HTTP, most DNS traffic is not encrypted (there are not even any drafts proposing a solution in the resolver-to-authoritative server space). This means that, for example, an attacker who gains access to DNS logs may not be able to infer clients who have not updated their revocation lists in a way that was not previously possible. None of this means that the proposal is a bad idea, just that more text would make it more convincing. Cheers, -- Shane From nobody Mon Oct 30 03:22:21 2017 Return-Path: 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 172E313F96D for ; Mon, 30 Oct 2017 03:22:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=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 dtsW1ddRaj_J for ; Mon, 30 Oct 2017 03:22:18 -0700 (PDT) Received: from off-send01.osa.jprs.co.jp (off-send01.osa.jprs.co.jp [IPv6:2001:218:3001:17::10]) (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 DEA8D13F97C for ; Mon, 30 Oct 2017 03:22:17 -0700 (PDT) Received: from off-sendsmg01.osa.jprs.co.jp (off-sendsmg01.osa.jprs.co.jp [172.23.8.61]) by off-send01.osa.jprs.co.jp (8.14.4/8.14.4) with ESMTP id v9UAMG7F023205 for ; Mon, 30 Oct 2017 19:22:16 +0900 Received: from off-sendsmg01.osa.jprs.co.jp (localhost [127.0.0.1]) by postfix.imss71 (Postfix) with ESMTP id 66676180064 for ; Mon, 30 Oct 2017 19:22:15 +0900 (JST) Received: from localhost (off-cpu05.osa.jprs.co.jp [172.23.4.15]) by off-sendsmg01.osa.jprs.co.jp (Postfix) with ESMTP id 5AC5E180062 for ; Mon, 30 Oct 2017 19:22:15 +0900 (JST) Date: Mon, 30 Oct 2017 19:22:15 +0900 (JST) Message-Id: <20171030.192215.1452725349912506052.fujiwara@jprs.co.jp> To: dnsop@ietf.org From: fujiwara@jprs.co.jp X-Mailer: Mew version 6.5 on Emacs 24.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1690-8.1.0.1062-23426.005 X-TM-AS-Result: No--5.328-5.0-31-10 X-imss-scan-details: No--5.328-5.0-31-10 X-TMASE-MatchedRID: pLrzZ2yoINVCXIGdsOwlUh5+URxv1WlBQa2sDHLkQ06FbkyVO0E5BzpI hhonTuyPBQSwRMHLbTsDBRGvSvWBgQsTH6q5zeP3kcT+m3MjC/HwZGE/+dMc1lwpnAAvAwaz5vG 1tXHHDX9M7wVZoURWlPx15EY4PiFAHodpx3o6GrvPhdXKEUVkcrj0igGiOeKhFTIyfyTa0AyXqr F0nhL4j3Uv5fXxlzM9H817pl0C9wwfbciQjfRltc5Scd0yVs+bbv16+gil4jfRyxuwHbF4CWd8N Qw82eCfmE6lS+nZSUKTeL8rrhZPBOjlyyR22XVACWiOS0BVokjAQzqh8D4IY2jliw+xvItdWXOj 3NIpqIqynUhD2tnSErBkcxB01tpxTX7PJ/OU3vL+xOhjarOnHiBQn3S4zK7meeFAQHoVNZJvFzy vAB/ijt0H8LFZNFG7bkV4e2xSge41Qrf+CFEEUBwmi/SDNFiek+mnD8kVkT37qdwq43zqclgpWC bva+Mm Archived-At: Subject: [DNSOP] draft-fujiwara-dnsop-additional-answers-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 10:22:20 -0000 Hello, I submitted another multiple response proposal. https://tools.ietf.org/html/draft-fujiwara-dnsop-additional-answers-00 It is similar to draft-wkumari-dnsop-multiple-responses, however, it proposes authoritative DNS server software developers choose additional resource records. # Many implementations (For example, BIND 9 and NSD) add MX mail # exchange A/AAAA or SRV Target A/AAAA in MX or SRV responses. And the draft proposes to append NSEC/NSEC3 RR if additional RR type does not exist. Validating resolvers can generate NODATA response by RFC 8198. It also contains comparison of multiple responses proposals in Appendix. Please read and comment it. Regards, -- Kazunori Fujiwara, JPRS Subject: I-D Action: draft-fujiwara-dnsop-additional-answers-00.txt From: internet-drafts@ietf.org To: Date: Sat, 28 Oct 2017 09:57:24 -0700 Archived-At: A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Returning additional answers in DNS responses Author : Kazunori Fujiwara Filename : draft-fujiwara-dnsop-additional-answers-00.txt Pages : 9 Date : 2017-10-28 Abstract: This document proposes to document the ability to provide multiple answers in single DNS response. For example, authoritative servers may add a NSEC resource record or A/AAAA resource records of the query name. This is especially useful as, in many cases, the entity making the request has no a priori knowledge of what other questions it will need to ask. It is already possible (an authoritative server MAY already sends what it wants in the additional section). This document does not propose any protocol changes, just explanations of an already acceptable practice. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-fujiwara-dnsop-additional-answers/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-fujiwara-dnsop-additional-answers-00 https://datatracker.ietf.org/doc/html/draft-fujiwara-dnsop-additional-answers-00 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/ From nobody Mon Oct 30 08:42:00 2017 Return-Path: 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 EE78B14D198 for ; Mon, 30 Oct 2017 08:41:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 dwBhlsx_P34p for ; Mon, 30 Oct 2017 08:41:57 -0700 (PDT) Received: from hydrogen.portfast.net (hydrogen.portfast.net [188.246.200.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32D7617F5DA for ; Mon, 30 Oct 2017 08:33:02 -0700 (PDT) Received: from [46.227.151.81] (port=49969 helo=rays-mbp.local) by hydrogen.portfast.net ([188.246.200.2]:465) with esmtpsa (fixed_plain:ray@bellis.me.uk) (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) id 1e9C3e-0002Xq-HD (Exim 4.72) for dnsop@ietf.org (return-path ); Mon, 30 Oct 2017 15:32:58 +0000 To: dnsop From: Ray Bellis Message-ID: Date: Mon, 30 Oct 2017 15:33:00 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: [DNSOP] Multiple question drafts? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 15:41:59 -0000 WG chairs Could you please let me / the WG know where we stand with the various drafts describing ways to accommodate multiple questions and/or answers in a single request? Multiple questions: - draft-bellis-dnsext-multi-qtypes - draft-yao-dnsop-accompanying-questions Multiple answers: - draft-vavrusa-dnsop-aaaa-for-free-00 - draft-wkumari-dnsop-multiple-responses thanks, Ray From nobody Mon Oct 30 09:15:00 2017 Return-Path: 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 C280D661D for ; Mon, 30 Oct 2017 09:14:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, URIBL_BLOCKED=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 1OBCAZ2MUaXQ for ; Mon, 30 Oct 2017 09:14:56 -0700 (PDT) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (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 DA5934F5E for ; Mon, 30 Oct 2017 09:04:18 -0700 (PDT) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 667B9280EAC; Mon, 30 Oct 2017 17:04:16 +0100 (CET) Received: by mx4.nic.fr (Postfix, from userid 500) id 60916280F37; Mon, 30 Oct 2017 17:04:16 +0100 (CET) Received: from relay01.prive.nic.fr (relay01.prive.nic.fr [IPv6:2001:67c:2218:15::11]) by mx4.nic.fr (Postfix) with ESMTP id 5A1B9280EAC; Mon, 30 Oct 2017 17:04:16 +0100 (CET) Received: from b12.nic.fr (b12.tech.ipv6.nic.fr [IPv6:2001:67c:1348:7::86:133]) by relay01.prive.nic.fr (Postfix) with ESMTP id 57724642C581; Mon, 30 Oct 2017 17:04:16 +0100 (CET) Received: by b12.nic.fr (Postfix, from userid 1000) id 53A38409E4; Mon, 30 Oct 2017 17:04:16 +0100 (CET) Date: Mon, 30 Oct 2017 17:04:16 +0100 From: Stephane Bortzmeyer To: Ray Bellis Cc: dnsop Message-ID: <20171030160416.n5qstzqx4ivezgbx@nic.fr> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux 9.1 X-Kernel: Linux 4.9.0-3-amd64 x86_64 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: NeoMutt/20170113 (1.7.2) X-Bogosity: No, tests=bogofilter, spamicity=0.000308, version=1.2.2 X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2017.10.30.155717 Archived-At: Subject: Re: [DNSOP] Multiple question drafts? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 16:14:59 -0000 On Mon, Oct 30, 2017 at 03:33:00PM +0000, Ray Bellis wrote a message of 24 lines which said: > Multiple answers: Also draft-fujiwara-dnsop-additional-answers From nobody Mon Oct 30 09:46:46 2017 Return-Path: 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 139A17D76 for ; Mon, 30 Oct 2017 09:46:45 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 t1rIolvBHVm3 for ; Mon, 30 Oct 2017 09:46:43 -0700 (PDT) Received: from hydrogen.portfast.net (hydrogen.portfast.net [188.246.200.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D55E793A for ; Mon, 30 Oct 2017 09:40:42 -0700 (PDT) Received: from [46.227.151.81] (port=51075 helo=rays-mbp.local) by hydrogen.portfast.net ([188.246.200.2]:465) with esmtpsa (fixed_plain:ray@bellis.me.uk) (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) id 1e9D78-0007UI-9E (Exim 4.72) for dnsop@ietf.org (return-path ); Mon, 30 Oct 2017 16:40:38 +0000 To: dnsop From: Ray Bellis Message-ID: <027a469c-5bb6-7940-fd89-55b91dd97275@bellis.me.uk> Date: Mon, 30 Oct 2017 16:40:40 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [DNSOP] draft-huston-kskroll-sentinel - naming format? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 16:46:45 -0000 I see that this draft uses a syntax similar to RFC 8145 Trust Anchor Telemetry RFC (which uses _ta-) albeit without the leading underscore, i.e. .ta-. I'd like to propose instead ._ta. This would allow _ta to be registered as a standalone entry in the underscore label registry, whilst also avoid the risk of collisions with "plain" labels that happen to match ta- FWIW, I think in retrospect that RFC 8145 should have taken a similar approach too. Ray From nobody Mon Oct 30 10:40:56 2017 Return-Path: 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 EE368940A for ; Mon, 30 Oct 2017 10:40:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 gs8tiRYXrB8O for ; Mon, 30 Oct 2017 10:40:53 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (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 DEBE513F592 for ; Mon, 30 Oct 2017 10:40:53 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [149.20.48.19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 3BA2C3B99EC; Mon, 30 Oct 2017 17:40:52 +0000 (UTC) Received: by bikeshed.isc.org (Postfix, from userid 10292) id 2985A216C1E; Mon, 30 Oct 2017 17:40:52 +0000 (UTC) Date: Mon, 30 Oct 2017 17:40:52 +0000 From: Evan Hunt To: Ray Bellis Cc: dnsop Message-ID: <20171030174052.GB87160@isc.org> References: <027a469c-5bb6-7940-fd89-55b91dd97275@bellis.me.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <027a469c-5bb6-7940-fd89-55b91dd97275@bellis.me.uk> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [DNSOP] draft-huston-kskroll-sentinel - naming format? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 17:40:55 -0000 > I see that this draft uses a syntax similar to RFC 8145 Trust Anchor > Telemetry RFC (which uses _ta-) albeit without the leading > underscore, i.e. .ta-. > > I'd like to propose instead ._ta. > > This would allow _ta to be registered as a standalone entry in the > underscore label registry, whilst also avoid the risk of collisions with > "plain" labels that happen to match ta- > > FWIW, I think in retrospect that RFC 8145 should have taken a similar > approach too. IIRC we discussed it, and were concerned that _ta. could be cached as nonexistent by servers implementing QNAME minimization. -- Evan Hunt -- each@isc.org Internet Systems Consortium, Inc. From nobody Mon Oct 30 10:59:16 2017 Return-Path: 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 AC19E9803; Mon, 30 Oct 2017 10:59:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 9CQpGKzOgMw4; Mon, 30 Oct 2017 10:59:14 -0700 (PDT) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (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 5A44913F592; Mon, 30 Oct 2017 10:59:14 -0700 (PDT) Received: by mail-wm0-x234.google.com with SMTP id y83so18074731wmc.4; Mon, 30 Oct 2017 10:59:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=NKb0kucnmnITR37iLZzGisncCFHZV+16cyhZPeWoGuM=; b=PIBqLYdk7swOKHXr0/5kYrJGJ5kgeZ7IqaTx77v0p6SP9tHMyoZ9JlXz7umegqhF2h KYkcv0A3BHmqPAEHoeprJ71uKNzn3oKW/Luaju+abbTixySrngdCUObVtLNhCAqNtl4G zyMPk1+xqjGj1BqolL8DmDBTCdfd5HSsexdsjA/mfF3f46uUmmBoFRukV2R4RTnb7hQE yKnJjwJAtddxoFflSvaM/fitqfuZSngDHi8eAZYwfliAwbeXgn84RUrmU56VmJwL5SWg 5i8o7IBsVG1AknFWJyBQMvPUiLR/6EGD4Er9AbOdGJd2Q3Gk+ivZ99VKjUWsMwiQY+fd FlHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=NKb0kucnmnITR37iLZzGisncCFHZV+16cyhZPeWoGuM=; b=qPY6eM/xqt567MiXcvscd6unkF2xN41iF/L2EtB47XvqRpNz1Hkid+vGWZDYdXYmWx VBLjI4nvEk+zk+KoHvMz58LoBfE0k4pT1v4Qx1E1mOp0t8cZIskuIuqX77NyvYxEaHar JGu4+QZyw34x2BulSLovrX7bM3bzPOqeGt4yZQk8A0TrANryYr17RjJv7ELMtWXe7XGf p+W0DNMwGGIT9LDSiFWeOjf6nWzLOcP658fTzxQxezJL79JBq8Xc+fcMrUw1f+esm53a ewE5uo3+J3OCp0K5mwe5VqsCkpkIQaSHz0Runk7Txj+NjfgFwPafxxROUpvravUFhmzR fBlw== X-Gm-Message-State: AMCzsaW1Fvn9K9fu0+7xePH2YbH8qff1TXpaDJ0jWiHcDDt27TzG0Akm P4oAIpiwfT0oYgeD5fMn42w2XWGwY/OazSoCRyI= X-Google-Smtp-Source: ABhQp+Q7grxoHDaZwH/yYc1J5o945KAHtmIzC6RjySEBKP1728ZAgGk5kBh8YDYNEPGfT0az271RqCToC2a51zSsvkg= X-Received: by 10.28.73.5 with SMTP id w5mr4421541wma.17.1509386352637; Mon, 30 Oct 2017 10:59:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.184.60 with HTTP; Mon, 30 Oct 2017 10:59:12 -0700 (PDT) From: tjw ietf Date: Mon, 30 Oct 2017 13:59:12 -0400 Message-ID: To: dnsop Cc: "dnsop-chairs@ietf.org" Content-Type: multipart/alternative; boundary="001a114b825660e5b1055cc765b6" Archived-At: Subject: [DNSOP] Agenda topics for IETF100 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 17:59:16 -0000 --001a114b825660e5b1055cc765b6 Content-Type: text/plain; charset="UTF-8" All Please submit any request for presenting at IETF100 to the chairs. We'll be working on a draft agenda in the interim. thanks tim --001a114b825660e5b1055cc765b6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

All

Please submit any re= quest for presenting at IETF100 to the chairs.=C2=A0 We'll be working o= n a draft agenda in the interim.=C2=A0

thanks
tim

--001a114b825660e5b1055cc765b6-- From nobody Mon Oct 30 12:45:28 2017 Return-Path: X-Original-To: dnsop@ietf.org Delivered-To: dnsop@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EBAA13F0A8; Mon, 30 Oct 2017 12:45:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dnsop@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150939272660.7850.3117239585167229526@ietfa.amsl.com> Date: Mon, 30 Oct 2017 12:45:26 -0700 Archived-At: Subject: [DNSOP] I-D Action: draft-tale-dnsop-serve-stale-02.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 19:45:26 -0000 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 : Serving Stale Data to Improve DNS Resiliency Authors : David C Lawrence Warren Kumari Filename : draft-tale-dnsop-serve-stale-02.txt Pages : 10 Date : 2017-10-30 Abstract: This draft defines a method for recursive resolvers to use stale DNS data to avoid outages when authoritative nameservers cannot be reached to refresh expired data. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-tale-dnsop-serve-stale/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-tale-dnsop-serve-stale-02 https://datatracker.ietf.org/doc/html/draft-tale-dnsop-serve-stale-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-tale-dnsop-serve-stale-02 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/ From nobody Mon Oct 30 14:08:38 2017 Return-Path: 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 3DA9E13FB88; Mon, 30 Oct 2017 14:08:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=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 QGsu4IzPaKdn; Mon, 30 Oct 2017 14:08:10 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E55FC13FB7C; Mon, 30 Oct 2017 14:08:08 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 552FEB81B4F; Mon, 30 Oct 2017 14:08:01 -0700 (PDT) To: andreas.cudok@googlemail.com, olaf@nlnetlabs.nl, matthijs@nlnetlabs.nl, miek.gieben@sidn.nl X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: warren@kumari.net, iesg@ietf.org, dnsop@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20171030210801.552FEB81B4F@rfc-editor.org> Date: Mon, 30 Oct 2017 14:08:01 -0700 (PDT) Archived-At: Subject: [DNSOP] [Errata Verified] RFC6781 (5174) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 21:08:12 -0000 The following errata report has been verified for RFC6781, "DNSSEC Operational Practices, Version 2". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5174 -------------------------------------- Status: Verified Type: Technical Reported by: Andreas Cudok Date Reported: 2017-10-29 Verified by: Warren Kumari (Ops AD) (IESG) Section: Appendix B. Original Text ------------- is reduced to the following representation: SOA_2005092303 RRSIG_Z_14(SOA_2005092303) DNSKEY_K_14 DNSKEY_Z_15 RRSIG_K_14(DNSKEY) RRSIG_Z_15(DNSKEY) The rest of the zone data has the same signature as the SOA record, i.e., an RRSIG created with DNSKEY_K_14. Corrected Text -------------- is reduced to the following representation: SOA_2005092303 RRSIG_Z_14(SOA_2005092303) DNSKEY_Z_14 DNSKEY_K_15 RRSIG_Z_14(DNSKEY) RRSIG_K_15(DNSKEY) The rest of the zone data has the same signature as the SOA record, i.e., an RRSIG created with DNSKEY_K_15. Notes ----- Note: K and Z were swapped. -------------------------------------- RFC6781 (draft-ietf-dnsop-rfc4641bis-13) -------------------------------------- Title : DNSSEC Operational Practices, Version 2 Publication Date : December 2012 Author(s) : O. Kolkman, W. Mekking, R. Gieben Category : INFORMATIONAL Source : Domain Name System Operations Area : Operations and Management Stream : IETF Verifying Party : IESG From nobody Mon Oct 30 14:09:27 2017 Return-Path: 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 1C3D213FB75 for ; Mon, 30 Oct 2017 14:09:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=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 Y3H-Lk-DutUr for ; Mon, 30 Oct 2017 14:09:24 -0700 (PDT) Received: from mail-wr0-x22a.google.com (mail-wr0-x22a.google.com [IPv6:2a00:1450:400c:c0c::22a]) (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 018FA13FB90 for ; Mon, 30 Oct 2017 14:09:02 -0700 (PDT) Received: by mail-wr0-x22a.google.com with SMTP id y39so14018814wrd.4 for ; Mon, 30 Oct 2017 14:09:02 -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; bh=bXv0EgBrxvnzVYwhMBNbHIw/iu1Z90F1hu6wOEFa2gY=; b=Tsf8yPYIZmrufUWZ1JQOXCxbYqhoqS4bILJH+Ws6xnecZEZTQsueOS4xo+3iidSKoA 9cEy+LDYAy2iQhh8+LfmGzzzdDLWflCre+2dGxSr3GQ/IDNghWRUVp/Fo1yzHRgXdowD EUlQUUK56MuHW76wrg98NcLGB7ZC93EEPzx47v/t7axUDxnlD+/6MDcUsEuYq3IjXozO 5yGGoimciaoH46mXckaRRGjs09DaSYV0GX+Dw/+TYxK7ShzVoGCcRJeqLzKHzmNpmORM neX2Bdq6uo1bqHNELmHAGty82I20WJM3F4qjqi+ObPGm6soymQV7a2LBRGuheyCGfHkv 87CQ== 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; bh=bXv0EgBrxvnzVYwhMBNbHIw/iu1Z90F1hu6wOEFa2gY=; b=HuBd9+mvEII69q5vH5kBnlV1kYgcnhyU7vhE0eP0uaKbamX+x9dvvgqbxRZmoFZey4 5Ce6FOIwI2pMkSdI0wX9N89yo8uXTiQFkQOZhFrwrxQCkmvJ1rxh2X3iw4R58T5cN2+V sKTh/ozaoWQSV1ouXiUnurSccxbaFvTz14mbnQrrwzsgmXtjTMftMo3Y9r7ylcVKbXz1 MGTGGv/ZiSo2iyJtuMgJyNzp3icP9+Gr/cQBpiui7ohqEY4JsJ3kosJWZMhI7kbng1Md J4zqBo6obWhyAJQoR79SnUuK+zhgBSJk9ceVr97o3anxCU9iLnI+WX7FBxaTd0Ay1Qcw ufjw== X-Gm-Message-State: AMCzsaWWYMVUoPLC9a9wVdU/A47nsksbLNPEj6R/N9Ccb/j3S/93cKdL +Qia8IMKhlaUNamGVDUl6JS7Ux4FG/JWqPec5rP3DG6L X-Google-Smtp-Source: ABhQp+SthPHwoJWwtDs2RYE3byD+mz/xdvpvBavff9x0d4xa4epHaH7zkXzURVfUb2x0gT3Lx1KpLeLQtBoNBGqFcuA= X-Received: by 10.223.133.242 with SMTP id 47mr9261685wru.170.1509397741227; Mon, 30 Oct 2017 14:09:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.187.12 with HTTP; Mon, 30 Oct 2017 14:08:20 -0700 (PDT) In-Reply-To: References: <20171029121247.31F02B817AB@rfc-editor.org> From: Warren Kumari Date: Mon, 30 Oct 2017 17:08:20 -0400 Message-ID: To: Matthijs Mekking Cc: dnsop Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [DNSOP] [Technical Errata Reported] RFC6781 (5174) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 21:09:26 -0000 Thanks! Verified. W On Mon, Oct 30, 2017 at 2:24 AM, Matthijs Mekking wrote: > Hi, > > This errata appears to be valid. In addition, the following text must also > be corrected, from: > > The rest of the zone data has the same signature as the SOA record, > i.e., an RRSIG created with DNSKEY_K_14. > > to: > > The rest of the zone data has the same signature as the SOA record, > i.e., an RRSIG created with DNSKEY_K_15. > > Best regards, > Matthijs > > > On 29-10-17 13:12, RFC Errata System wrote: >> >> The following errata report has been submitted for RFC6781, >> "DNSSEC Operational Practices, Version 2". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata/eid5174 >> >> -------------------------------------- >> Type: Technical >> Reported by: Andreas Cudok >> >> Section: Appendix B. >> >> Original Text >> ------------- >> is reduced to the following representation: >> >> SOA_2005092303 >> RRSIG_Z_14(SOA_2005092303) >> DNSKEY_K_14 >> DNSKEY_Z_15 >> RRSIG_K_14(DNSKEY) >> RRSIG_Z_15(DNSKEY) >> >> Corrected Text >> -------------- >> is reduced to the following representation: >> >> SOA_2005092303 >> RRSIG_Z_14(SOA_2005092303) >> DNSKEY_Z_14 >> DNSKEY_K_15 >> RRSIG_Z_14(DNSKEY) >> RRSIG_K_15(DNSKEY) >> >> Notes >> ----- >> >> >> Instructions: >> ------------- >> This erratum is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC6781 (draft-ietf-dnsop-rfc4641bis-13) >> -------------------------------------- >> Title : DNSSEC Operational Practices, Version 2 >> Publication Date : December 2012 >> Author(s) : O. Kolkman, W. Mekking, R. Gieben >> Category : INFORMATIONAL >> Source : Domain Name System Operations >> Area : Operations and Management >> Stream : IETF >> Verifying Party : IESG >> >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop >> > > _______________________________________________ > 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 From nobody Mon Oct 30 14:49:44 2017 Return-Path: X-Original-To: dnsop@ietf.org Delivered-To: dnsop@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A60C1139504; Mon, 30 Oct 2017 14:49:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dnsop@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150940017764.7814.6739838599217498076@ietfa.amsl.com> Date: Mon, 30 Oct 2017 14:49:37 -0700 Archived-At: Subject: [DNSOP] I-D Action: draft-ietf-dnsop-serve-stale-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 21:49:38 -0000 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 : Serving Stale Data to Improve DNS Resiliency Authors : David C Lawrence Warren Kumari Filename : draft-ietf-dnsop-serve-stale-00.txt Pages : 10 Date : 2017-10-30 Abstract: This draft defines a method for recursive resolvers to use stale DNS data to avoid outages when authoritative nameservers cannot be reached to refresh expired data. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-serve-stale/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dnsop-serve-stale-00 https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-serve-stale-00 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/ From nobody Mon Oct 30 15:27:10 2017 Return-Path: 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 2CD6D13F43E for ; Mon, 30 Oct 2017 15:27:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 XfyPGj-sQGjw for ; Mon, 30 Oct 2017 15:27:07 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 601FE13F3F5 for ; Mon, 30 Oct 2017 15:27:07 -0700 (PDT) Received: from givry.fdupont.fr (localhost [IPv6:::1]) by givry.fdupont.fr (8.14.7/8.14.7) with ESMTP id v9UM6Frp029199; Mon, 30 Oct 2017 23:06:15 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201710302206.v9UM6Frp029199@givry.fdupont.fr> From: Francis Dupont To: tjw ietf Cc: dnsop Date: Mon, 30 Oct 2017 23:06:15 +0100 Archived-At: Subject: Re: [DNSOP] Agenda topics for IETF100 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 22:27:09 -0000 Need a short slot (5 mn) about the revision of TSIG specs just submitted as draft-dupont-dnsop-rfc2845bis-00.txt Thanks Francis.Dupont@fdupont.fr PS: there are in fact only a few since IETF99: just the work is in progress and should one day become a WG item. IMHO today the main difference is the draft exists so contributions and comments should be easier... From nobody Mon Oct 30 16:29:57 2017 Return-Path: X-Original-To: dnsop@ietf.org Delivered-To: dnsop@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E1FBFCA4F; Mon, 30 Oct 2017 16:29:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dnsop@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150940619490.28403.7485909732104218964@ietfa.amsl.com> Date: Mon, 30 Oct 2017 16:29:54 -0700 Archived-At: Subject: [DNSOP] I-D Action: draft-woodworth-bulk-rr-07.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 23:29:55 -0000 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 : BULK DNS Resource Records Authors : John Woodworth Dean Ballew Shashwath Bindinganaveli Raghavan David C Lawrence Filename : draft-woodworth-bulk-rr-07.txt Pages : 16 Date : 2017-10-30 Abstract: The BULK DNS resource record type defines a method of pattern-based creation of DNS resource records based on numeric substrings of query names. The intent of BULK is to simplify generic assignments in a memory-efficient way that can be easily shared between the primary and secondary nameservers for a zone. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-woodworth-bulk-rr/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-woodworth-bulk-rr-07 https://datatracker.ietf.org/doc/html/draft-woodworth-bulk-rr-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-woodworth-bulk-rr-07 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/ From nobody Tue Oct 31 02:39:28 2017 Return-Path: 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 1E643138F47 for ; Tue, 31 Oct 2017 02:39:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sidn.nl 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 09BM-fm81Qa3 for ; Tue, 31 Oct 2017 02:39:26 -0700 (PDT) Received: from arn2-kamx.sidn.nl (kamx.sidn.nl [IPv6:2a00:d78:0:147:94:198:152:69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 184E213F5E4 for ; Tue, 31 Oct 2017 02:39:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=sidn.nl; s=sidn-nl; c=relaxed/relaxed; h=from:to:subject:thread-topic:thread-index:date:message-id:accept-language:content-language:x-ms-has-attach:x-ms-tnef-correlator:x-mailer:x-ms-exchange-messagesentrepresentingtype:x-ms-exchange-transport-fromentityheader:x-originating-ip:content-type:mime-version; bh=LGP709nUbA9le9/bJnEA2ucwg37wnNtRrGkLmjmTF1A=; b=LhCocLGpctN9G3i1iW07hov/m4zEwHripb1JM03Y8rZ4n0RGQCaC09ZT6eoVcyuDlesStsGa6gIY6eXVnkgnBVkvgTF2hsrs9Jz8kzoJ6H3gIVRgRBQaKZayBR3QEgQy3kbQkWO32lZvRI9icjoefCEVEHeAsBWyvXdsogWPAq3Aq1xAsgYP05ZQTXJveh6L1ld+O4WlqQBOQTeCFDkOkR6UiwoTrtX2FmZdN2ZoIc9thLO1OqLZX+rEUioqActJFwTqPaZb5TQMe2t3kZ+MByA8m+3bfD1utj+W9Z77x+weKOzL7kvsH+aiI5wS77xWALIfLeQ6E+hTISPCFYkJtA== Received: from ka-mbx02.SIDN.local ([192.168.2.178]) by arn2-kamx.sidn.nl with ESMTP id v9V9dOJD016189-v9V9dOJF016189 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=CAFAIL) for ; Tue, 31 Oct 2017 10:39:24 +0100 Received: from ka-mbx01.SIDN.local (192.168.2.177) by ka-mbx02.SIDN.local (192.168.2.178) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Tue, 31 Oct 2017 10:39:23 +0100 Received: from ka-mbx01.SIDN.local ([fe80::e051:e184:7a9f:b09d]) by ka-mbx01.SIDN.local ([fe80::e051:e184:7a9f:b09d%13]) with mapi id 15.00.1130.005; Tue, 31 Oct 2017 10:39:24 +0100 From: Moritz Muller To: "dnsop@ietf.org" Thread-Topic: Resolver behaviour with multiple trust anchors Thread-Index: AQHTUiwiqVxvIHBV0Uun1GqDhxVA2w== Date: Tue, 31 Oct 2017 09:39:23 +0000 Message-ID: <121CDBC2-D68C-48EE-A56E-46C61FC21538@sidn.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3273) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [94.198.159.138] Content-Type: multipart/signed; boundary="Apple-Mail=_E3B668C3-F4D6-497A-9A63-BDB90D919C31"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 Archived-At: Subject: [DNSOP] Resolver behaviour with multiple trust anchors X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Oct 2017 09:39:28 -0000 --Apple-Mail=_E3B668C3-F4D6-497A-9A63-BDB90D919C31 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Together with my colleagues I have been stumbling upon a, for me, = unclear case when validating trust anchors. Assuming that a resolver has enabled DNSSEC validation and has the root = keys configured. Additionally, it has configured manually a trust anchor for a TLD (that = has also published its DS in the root zone). Now, for example due to a key rollover at the TLD, the manually = configured trust anchor of the TLD does not match the DS in the root = anymore. How should a resolver treat the signatures of this TLD? The resolvers of BIND, Unbound, and PowerDNS seem to treat the = signatures of the TLD as bogus, but we didn't find any specifics in RFC = 4034 and 4035 that describe how resolvers should behave in this case. Knot resolver treats them as NOERROR (according to the developers). If we interpret section 4.3 of RFC 4035 then we would have assumed that = the signature must be treated as secure. Did we miss something, or is there indeed clarification needed? =E2=80=94 Moritz --Apple-Mail=_E3B668C3-F4D6-497A-9A63-BDB90D919C31 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEzP2ZWezgrnEvsIELCviSKxZZtEgFAln4RMsACgkQCviSKxZZ tEgV5Qf+KRn4u1LA2M3RhmQA7xpNjGDUQKMLSEZorFomheiDd2SItZcZWGN5qcXd CZy1RYb0qnMBLpx7yrPkXle5N/cbjncKcYkrlWmFrnzbicWpIE/A8v0Baco+EYDF TQf6SiWPkpagTa/COGW3ZUK/C3fh9W9MdjgtxvCt3yUK1i8K24G1skrSTGU8ksLe Du6ok7z8rytQvO1UiQFYoXFpy/8GTBULQ7h6/tpkgUzQnkMIqerEUL8Vo2IigdxE Ombq6DtHELuBC3TrTzxPO7/ODOXkCg19Q+9k6gGaRu9qFawqFtUuuyMBJVSXdTAD GpXTwrwMkRFyCBRwEtFBwDyW7nwEOA== =F7NM -----END PGP SIGNATURE----- --Apple-Mail=_E3B668C3-F4D6-497A-9A63-BDB90D919C31-- From nobody Tue Oct 31 04:27:36 2017 Return-Path: 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 25A3F13F506 for ; Tue, 31 Oct 2017 04:27: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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 kJsZhSuqZDrS for ; Tue, 31 Oct 2017 04:27:32 -0700 (PDT) Received: from hydrogen.portfast.net (hydrogen.portfast.net [188.246.200.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75C5B13F65E for ; Tue, 31 Oct 2017 04:27:32 -0700 (PDT) Received: from [46.227.151.81] (port=56083 helo=rays-mbp.local) by hydrogen.portfast.net ([188.246.200.2]:465) with esmtpsa (fixed_plain:ray@bellis.me.uk) (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) id 1e9Uhd-0006C2-NI (Exim 4.72) for dnsop@ietf.org (return-path ); Tue, 31 Oct 2017 11:27:29 +0000 To: dnsop@ietf.org References: <027a469c-5bb6-7940-fd89-55b91dd97275@bellis.me.uk> <20171030174052.GB87160@isc.org> From: Ray Bellis Message-ID: Date: Tue, 31 Oct 2017 11:27:30 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <20171030174052.GB87160@isc.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] draft-huston-kskroll-sentinel - naming format? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Oct 2017 11:27:34 -0000 On 30/10/2017 17:40, Evan Hunt wrote: > IIRC we discussed it, and were concerned that _ta. could be cached as > nonexistent by servers implementing QNAME minimization. How would that happen, at least so long as _ta responds like any other empty non-terminal? Ray From nobody Tue Oct 31 06:32:22 2017 Return-Path: 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 2B04813F4F8 for ; Tue, 31 Oct 2017 06:32:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_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 i0imfQwY7jYO for ; Tue, 31 Oct 2017 06:32:15 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org [64.78.40.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CA3C13F48D for ; Tue, 31 Oct 2017 06:32:15 -0700 (PDT) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 31 Oct 2017 06:32:13 -0700 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1178.000; Tue, 31 Oct 2017 06:32:13 -0700 From: Edward Lewis To: Moritz Muller CC: "dnsop@ietf.org" Thread-Topic: [Ext] [DNSOP] Resolver behaviour with multiple trust anchors Thread-Index: AQHTUkyolvHMi3p7Gkyt1Zw4qTyQQg== Date: Tue, 31 Oct 2017 13:32:13 +0000 Message-ID: <80802FE3-3317-4196-9339-1BAB172910B6@icann.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.47.234] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3592287132_682327793" MIME-Version: 1.0 Archived-At: Subject: Re: [DNSOP] [Ext] Resolver behaviour with multiple trust anchors X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Oct 2017 13:32:17 -0000 --B_3592287132_682327793 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit On 10/31/17, 05:39, "DNSOP on behalf of Moritz Muller" wrote: >Now, for example due to a key rollover at the TLD, the manually configured trust anchor of the TLD does not match the DS in the root anymore. > >How should a resolver treat the signatures of this TLD? Short answer: the resolver ought to validate positively (other things being equal) the affected data sets. My opinion/recollection (meaning no citations*): this question has been bounced around before. The general case is "What if it is possible to build a chain of trust from a (any) trust anchor for high.example. but not from any trust anchor for lower.high.example?" Or vice versa? * = Below I have response citing a document...but for now... Starting with, "it is very hard to publish the correct signatures in a chain of trust", so if any can be built, trust the data. Hard meaning you have to have the private keys. If one allows a (or any) broken chain (a signature fails) to cause a validation failure, this allows an attack where someone supplies bad data just to lead to a denial of service. (Not a flooding attack, more like a process kill.) Of course, a strategy of "trusting any chain to any trust anchor" places importance on maintaining only truly trusted trust anchor points. Given that operations might result in a mismatch of established trust anchors and secure entry points, code ought not be too restrictive so as to require/expect the two to be in synch. (Much like NS sets above and below a cut-point. Yes, they should be the same, but if they differ, "life" can go on.) Software implementations can choose to be aggressive or passive. Aggressive means trying all possible means to validate the data within the rules of security. Passive might mean "try one and give up if it fails." For example, under a Kaminsky-described attack, a resolver that only chooses the first response (which would fail, causing SERVFAIL) may not see the later-arriving true response (which would validate). The former approach is what was implemented in at least early code bases (if not still). So, I'd prefer code that seeks any chain before giving up. DNSSEC causes the DNS to be more brittle (securing any existing system does this). For this the philosophy behind DNSSEC is to be as lenient as possible within the boundaries of maintaining a secured environment. (I've always wanted an RCODE of "AWHECKUSEITANYWAY" to represent DNSSEC validation errors that get passed because security is inconvenient - like when a user has one DNSSEC validating server in their stub's list alongside a non-validating server for when those SERVFAILs come back.) OTOH - for a referenced answer: "Protocol Modifications for the DNS Security Extensions" (aka RFC 4035), section "Determining Security Status of Data" (4.3), the definitions for: # Secure: An RRset for which the resolver is able to build a chain of # signed DNSKEY and DS RRs from a trusted security anchor to the # RRset. In this case, the RRset should be signed and is subject to # signature validation, as described above. Note "build a chain" not "build all possible chains" # Bogus: An RRset for which the resolver believes that it ought to be # able to establish a chain of trust but for which it is unable to # do so, either due to signatures that for some reason fail to # validate or due to missing data that the relevant DNSSEC RRs # indicate should be present. This case may indicate an attack but # may also indicate a configuration error or some form of data # corruption. Note again "a chain of trust" and no reference to any failure meaning the data is bogus. --B_3592287132_682327793 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIR5gYJKoZIhvcNAQcCoIIR1zCCEdMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC D68wggWeMIIEhqADAgECAhAE64fxtFjS2DdV8JfouoFSMA0GCSqGSIb3DQEBCwUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xNjA4MDkw MDAwMDBaFw0xOTA4MDkxMjAwMDBaMIG9MQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZv cm5pYTEUMBIGA1UEBxMLTG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEeMBwGA1UEAxMVRWR3YXJkIExl d2lzIDkgQXVnIDE2MSUwIwYJKoZIhvcNAQkBFhZlZHdhcmQubGV3aXNAaWNhbm4ub3JnMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxGXAQjOhBCDPz1+sGOERDMvSCFWbOUws GUrXAHLGeEAGYTCpni8f7kYPH7RMalvbep2aVtkMSUn6HR1uY84b437ZZuHCviUn7Aw6itGE wrDyq7Pb7zTlqE/1kLVhKYrHA4sjhsQRHhBHevxWbb3SYU2IMNxJd4QFgRJIp4zDmAR7bzbH 1ZazFGfo/op0QRsfcpFYmBotbj/4SnldtFwZasr7zTK9wJRSXa9sspLXtQhBe9itxTHJRg0H BH66VcPX7iRra9XFzkM5JLXOT2nBDIxeqDsLKoTkRWiNoSWoDZylAqS3BfBppwq7eremR7zD LIaPN4Tbb8TCpORMCZuvswIDAQABo4IB7zCCAeswHwYDVR0jBBgwFoAU5wIjgABP2Ne8lAvZ P3Q5STI8inkwHQYDVR0OBBYEFBiOkLRCGoHjShiTxeM3n94XHm+2MAwGA1UdEwEB/wQCMAAw IQYDVR0RBBowGIEWZWR3YXJkLmxld2lzQGljYW5uLm9yZzAOBgNVHQ8BAf8EBAMCBaAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYKYIZIAYb9bAQBAjAq MCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMIGIBgNVHR8EgYAw fjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJ RENBLWcyLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hB MkFzc3VyZWRJRENBLWcyLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6 Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhY2VydHMuZGlnaWNl cnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG9w0BAQsFAAOCAQEA zhEJp9X6tm36lKKaxCdyjyETxL3oVPDmv2JHBD/T/xbqRH0vQfR34VkRnSO+5d8AqHGdhYTK 7yjB/vW52KjiQUiW9WnQFYdY5Q/Yv3cnVgi4zuuye9BPvyr87HbmJ0uafYjATnYziT71njO7 xKIQP6w0MFv8ugT/fXIZsV4NU2eGQEHhvPkR+WOt0KfFa5jEY1qXoj4iZmE21j+f0OhSTA9K EofM5chR6FCaOyomKPIYU1mcoQwcistCwfcdVhUCpmgazxn6fR89ZOOiKTXxhOHrILdO0pCI dlJ3xO6EBvFKBCOyRBkD2z7jcWm/U3GkkYBLyRMvH1Ki+q4vwKnFZjCCBk4wggU2oAMCAQIC EASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcNAQELBQAwZTELMAkGA1UEBhMCVVMxFTATBgNV BAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMb RGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEzMTEwNTEyMDAwMFoXDTI4MTEwNTEy MDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQ d3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENB MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/AJ3kbLQWHohBDMd8O 1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr+Lp+yTU7VvEffEJ+ JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQelAfJUXo8Ymvzf9e /1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK3OnZ9ZEXjsYhrTg8 E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uCig1xGOSm4IksG/Oy czzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/BAgwBgEB/wIBADAO BgNVHQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2Nz cC5kaWdpY2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9jcmw0LmRpZ2ljZXJ0 LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRp Z2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYDVR0lBBYwFAYIKwYB BQUHAwIGCCsGAQUFBwMEMIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgBhv1sAAIEMIIBkjAo BggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCCAWQGCCsGAQUFBwIC MIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABpAHMAIABDAGUAcgB0AGkAZgBp AGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABhAGMAYwBlAHAAdABhAG4AYwBl ACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABDAFAALwBDAFAAUwAgAGEAbgBk ACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBu AHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBiAGkAbABpAHQAeQAgAGEAbgBk ACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAgAGgAZQByAGUAaQBuACAAYgB5 ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP2Ne8lAvZP3Q5STI8inkw HwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcNAQELBQADggEBAE7U iSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrgYhmZpgeafBMn2+UC ooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg4/mgVgxIEM4zaHvN k6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmwXZG0k4f5lpaBVUCO Zu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1YEhEybr1DDE0023vG QtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIwggO3MIICn6ADAgECAhAM 5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQK EwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0Rp Z2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAwMDAwMDBaFw0zMTExMTAwMDAw MDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3 dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7kQ4BcsYfzt2D5cRKlrtwmlIiq 9M71IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrneVNcMYQq9g+YMjZ2zN7dPKii 72r7IfJSYd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9SwOD7BG8OMM9nYLxj+KA+zp4PW w25EwGE1lhb+WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyChz+VtCshJfDGYM2wi6YfQMlqi uhOCEe05F52ZOnKh5vqk2dUXMXWuhX0irj8BRob2KHnIsdrkVxfEfhwOsLSSplazvbKX7aqn 8LfFqD+VFtD/oZbrCF8Yd08CAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgGGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFEXroq/0ksuCMS1Ri6enIZ3zbcgPMB8GA1UdIwQYMBaAFEXroq/0 ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBBQUAA4IBAQCiDrzf4u3w43JzemSUv/dyZtgy 5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwSTFjk0z2DSUVYlzVpGqhH6lbGeasS2GeBhN9/CTyU 5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJs13rsgkq6ybteL59PyvztyY1bV+JAbZJW58B BZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLxvlBnt2y98/Efaww2BxZ/N3ypW2168RJG YIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76jRslbWyPpbdhAbHSoyahEHGdreLD +cOZUbcrBwjOLuZQsqf6CkUvovDyMYIB/zCCAfsCAQEweTBlMQswCQYDVQQGEwJVUzEVMBMG A1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQD ExtEaWdpQ2VydCBTSEEyIEFzc3VyZWQgSUQgQ0ECEATrh/G0WNLYN1Xwl+i6gVIwCQYFKw4D AhoFAKBdMCMGCSqGSIb3DQEJBDEWBBQtICenlYMJ3KcwLguR6RUaTh1hGjAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzEwMzExMzMyMTJaMA0GCSqGSIb3 DQEBAQUABIIBABgfd/klViiaO6Kxgfa12ZhC8fOmMxAQ5HUhDHUUCUoU7t4pJjQX3oWWxC1y 3GS0sR7xvfh2HbXW63N4R36Nht/ad/ymupcMtE2R+FV3h9Fn94ajhlrr4zDBcNEZldkSaHf8 IPTXINXFzRMpyLiMEOHXLkAbD1CFpPplNA2CNEtHV3w5iHHKC6Kk87w5PRHI2CNG3i6YdgnO 6LuWwc+r5TpFEtKWSfUCM8BmLM9YwPJBv1s6Lx65YqusHmMBfmiJHnyjNPDWfTcLJVwmIjnv jQJvl51c5Ye4SzO4WH1C/j1ZveAMALYrD56WGxUmVgHSUQcCnosoIGI8FdyWtI4Kgn4= --B_3592287132_682327793-- From nobody Tue Oct 31 07:34:46 2017 Return-Path: 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 97D8413F449 for ; Tue, 31 Oct 2017 07:34:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 IjhQID9E8j9L for ; Tue, 31 Oct 2017 07:34:43 -0700 (PDT) Received: from ppsw-32.csi.cam.ac.uk (ppsw-32.csi.cam.ac.uk [131.111.8.132]) (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 0F8AF13B13B for ; Tue, 31 Oct 2017 07:34:43 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from grey.csi.cam.ac.uk ([131.111.57.57]:49016) by ppsw-32.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1e9Xcm-0011DM-2x (Exim 4.89) (return-path ); Tue, 31 Oct 2017 14:34:40 +0000 Date: Tue, 31 Oct 2017 14:34:40 +0000 From: Tony Finch To: Ray Bellis cc: dnsop@ietf.org In-Reply-To: Message-ID: References: <027a469c-5bb6-7940-fd89-55b91dd97275@bellis.me.uk> <20171030174052.GB87160@isc.org> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: Subject: Re: [DNSOP] draft-huston-kskroll-sentinel - naming format? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Oct 2017 14:34:44 -0000 Ray Bellis wrote: > On 30/10/2017 17:40, Evan Hunt wrote: > > > IIRC we discussed it, and were concerned that _ta. could be cached as > > nonexistent by servers implementing QNAME minimization. > > How would that happen, at least so long as _ta responds like any other > empty non-terminal? It's NXDOMAIN. (It'll also fall foul of RFCs 8020 and 8198.) The problem occurs if you have a validator behind a cache. The cache will prevent downstream id._ta. queries from reaching the root, so any downstream trust anchor variation will be lost. Tony. -- f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode Viking, North Utsire: Southwesterly 5 or 6, veering westerly 5 to 7 later. Moderate or rough, occasionally slight in North Utsire. Rain or showers, fog patches in Viking. Moderate or poor, occasionally very poor in Viking. From nobody Tue Oct 31 07:42:38 2017 Return-Path: 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 0682C13F46A for ; Tue, 31 Oct 2017 07:42:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 sMKb4WdtN9ri for ; Tue, 31 Oct 2017 07:42:36 -0700 (PDT) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 EDE8B13F4FB for ; Tue, 31 Oct 2017 07:42:35 -0700 (PDT) Received: from [10.32.60.231] (50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id v9VEf9BS027428 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 31 Oct 2017 07:41:11 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141] claimed to be [10.32.60.231] From: "Paul Hoffman" To: "Moritz Muller" Cc: "dnsop@ietf.org" Date: Tue, 31 Oct 2017 07:42:32 -0700 Message-ID: <897E0B21-1A78-45F5-95CF-B87FD36524FC@vpnc.org> In-Reply-To: <121CDBC2-D68C-48EE-A56E-46C61FC21538@sidn.nl> References: <121CDBC2-D68C-48EE-A56E-46C61FC21538@sidn.nl> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.7r5425) Archived-At: Subject: Re: [DNSOP] Resolver behaviour with multiple trust anchors X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Oct 2017 14:42:37 -0000 On 31 Oct 2017, at 2:39, Moritz Muller wrote: > Together with my colleagues I have been stumbling upon a, for me, > unclear case when validating trust anchors. > > Assuming that a resolver has enabled DNSSEC validation and has the > root keys configured. > Additionally, it has configured manually a trust anchor for a TLD > (that has also published its DS in the root zone). > Now, for example due to a key rollover at the TLD, the manually > configured trust anchor of the TLD does not match the DS in the root > anymore. > > How should a resolver treat the signatures of this TLD? > The resolvers of BIND, Unbound, and PowerDNS seem to treat the > signatures of the TLD as bogus, but we didn't find any specifics in > RFC 4034 and 4035 that describe how resolvers should behave in this > case. > Knot resolver treats them as NOERROR (according to the developers). > If we interpret section 4.3 of RFC 4035 then we would have assumed > that the signature must be treated as secure. > > Did we miss something, or is there indeed clarification needed? It sounds like clarification is needed if even one (much less three) systems treat such a signature as Bogus. My reading of RFC 4035 is that any chain that successfully leads to a trust anchor should return Secure, even if a different chain returns Bogus. --Paul Hoffman From nobody Tue Oct 31 07:56:47 2017 Return-Path: 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 3956813F617 for ; Tue, 31 Oct 2017 07:56:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopcount.ca 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 G2H10jRlMGjR for ; Tue, 31 Oct 2017 07:56:44 -0700 (PDT) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (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 EF99F13F6D7 for ; Tue, 31 Oct 2017 07:56:43 -0700 (PDT) Received: by mail-io0-x22b.google.com with SMTP id m16so35721450iod.1 for ; Tue, 31 Oct 2017 07:56:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=YYGbosgFG5UkV+Sj0mSTQQHORFD6YiPwDGxV3esHDL0=; b=QQ2UZ99K+1SnPaa2ireFdLa/sae2Lsz51oU2PgueWRh40vhYQB5UxPNt5jzta2zDmu dqpFg/xNzyYAONH8TjJJQxr2SGYTjG8WsQRFGXK2bxV1niAZ4scWVNYu7iWNxRS/cUes SeWpAYM/JEBIbWTeWXONkNb1ZuJUvhyOo35Jc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=YYGbosgFG5UkV+Sj0mSTQQHORFD6YiPwDGxV3esHDL0=; b=CJ796LGmu55noJiDsEalodtgPVI3Xvqj6tmk3mM2GW0v016SvqM6g5CGHpQIiZbvbD lnNQySjVxifoRjbpPtRmuXX2LoUZb0nVPgL3CkbddSjQA54pfbv3dhm4g1CQ99rNvcgS 4Mb1KiAJ869lsai9+X7GsRygniRWUC5VkvIo3Xymr7+0j+sgwNuBAuFEs1Vu/PUIyO2M 0dNF73cseAg6V2Ufr5NDukYf9rRLIKCa12AQR84GtXuBqG6YvJeklmrFzVUU6WQL/im+ dhDizdmYVHKPh2mZ3tP/LRIOOnyP0TVCcHXl2yCFzWAUTE69CTxfYts+uyKJfV5jMIoR S73A== X-Gm-Message-State: AMCzsaUmR4XnIsRuvr1ASSIqggoDTuYhc3MO5tBroMJclUoLN07WLvxp M4uECj/tJlRmhpwlEdpQTtNU71Tk9oA= X-Google-Smtp-Source: ABhQp+R+7ZIZm4dFknO8meR1Dgu5NJUq+mi3nrcZO0XjSDfNvzQxsdb6P3Jc6yv1B2jxPvw7h7wO6w== X-Received: by 10.36.189.196 with SMTP id x187mr3406443ite.85.1509461802757; Tue, 31 Oct 2017 07:56:42 -0700 (PDT) Received: from ?IPv6:2607:f2c0:101:3:105c:5ee2:1ecc:9e40? ([2607:f2c0:101:3:105c:5ee2:1ecc:9e40]) by smtp.gmail.com with ESMTPSA id s81sm935117ita.19.2017.10.31.07.56.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 31 Oct 2017 07:56:41 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Joe Abley X-Mailer: iPad Mail (15A432) In-Reply-To: Date: Tue, 31 Oct 2017 10:56:41 -0400 Cc: dnsop@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <027a469c-5bb6-7940-fd89-55b91dd97275@bellis.me.uk> <20171030174052.GB87160@isc.org> To: Ray Bellis Archived-At: Subject: Re: [DNSOP] draft-huston-kskroll-sentinel - naming format? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Oct 2017 14:56:45 -0000 On Oct 31, 2017, at 07:27, Ray Bellis wrote: >> On 30/10/2017 17:40, Evan Hunt wrote: >>=20 >> IIRC we discussed it, and were concerned that _ta. could be cached as >> nonexistent by servers implementing QNAME minimization. >=20 > How would that happen, at least so long as _ta responds like any other > empty non-terminal? Perhaps I missed something, but how do you ensure that _ta is an empty non-t= erminal? Joe= From nobody Tue Oct 31 07:57:03 2017 Return-Path: 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 B1CF013F72D for ; Tue, 31 Oct 2017 07:57:01 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 QKsdQPQ9oHWi for ; Tue, 31 Oct 2017 07:57:00 -0700 (PDT) Received: from hydrogen.portfast.net (hydrogen.portfast.net [188.246.200.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F1A513F6DB for ; Tue, 31 Oct 2017 07:56:57 -0700 (PDT) Received: from [46.227.151.81] (port=59921 helo=rays-mbp.local) by hydrogen.portfast.net ([188.246.200.2]:465) with esmtpsa (fixed_plain:ray@bellis.me.uk) (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) id 1e9XyI-0002pn-7X (Exim 4.72) (return-path ); Tue, 31 Oct 2017 14:56:54 +0000 To: Tony Finch Cc: dnsop@ietf.org References: <027a469c-5bb6-7940-fd89-55b91dd97275@bellis.me.uk> <20171030174052.GB87160@isc.org> From: Ray Bellis Message-ID: Date: Tue, 31 Oct 2017 14:56:54 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] draft-huston-kskroll-sentinel - naming format? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Oct 2017 14:57:02 -0000 On 31/10/2017 14:34, Tony Finch wrote: > It's NXDOMAIN. (It'll also fall foul of RFCs 8020 and 8198.) > > The problem occurs if you have a validator behind a cache. The cache will > prevent downstream id._ta. queries from reaching the root, so any > downstream trust anchor variation will be lost. Right, but if it's _defined_ to be an ENT instead (with NOERROR) then that problem shouldn't arise? In any event, for the proposed new mechanism the queries don't reach the root, they're handled internally within the resolver. Ray From nobody Tue Oct 31 08:01:25 2017 Return-Path: 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 190C813F737 for ; Tue, 31 Oct 2017 08:01:24 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 K5QKggcsLGcA for ; Tue, 31 Oct 2017 08:01:22 -0700 (PDT) Received: from hydrogen.portfast.net (hydrogen.portfast.net [188.246.200.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 112E613F748 for ; Tue, 31 Oct 2017 08:01:03 -0700 (PDT) Received: from [46.227.151.81] (port=59964 helo=rays-mbp.local) by hydrogen.portfast.net ([188.246.200.2]:465) with esmtpsa (fixed_plain:ray@bellis.me.uk) (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) id 1e9Y2F-0002u4-SN (Exim 4.72) (return-path ); Tue, 31 Oct 2017 15:00:59 +0000 To: Joe Abley Cc: dnsop@ietf.org References: <027a469c-5bb6-7940-fd89-55b91dd97275@bellis.me.uk> <20171030174052.GB87160@isc.org> From: Ray Bellis Message-ID: Date: Tue, 31 Oct 2017 15:01:01 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] draft-huston-kskroll-sentinel - naming format? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Oct 2017 15:01:24 -0000 On 31/10/2017 14:56, Joe Abley wrote: > Perhaps I missed something, but how do you ensure that _ta is an > empty non-terminal? By having that be part of the required server logic to implement the sentinel mechanism? That said, I'm not sure this would be consistent with the draft's proposed use of SERVFAIL. Ray From nobody Tue Oct 31 08:30:04 2017 Return-Path: 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 E756913F831 for ; Tue, 31 Oct 2017 08:30:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 V6KkweCyw-lR for ; Tue, 31 Oct 2017 08:30:01 -0700 (PDT) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (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 6597513F8B7 for ; Tue, 31 Oct 2017 08:23:16 -0700 (PDT) Received: by mail-wm0-x231.google.com with SMTP id b9so24037357wmh.0 for ; Tue, 31 Oct 2017 08:23:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=61mNDokGB9NoVCMqagymHQDB0nYnvd6WPAhsyg7lvN4=; b=ravfmMBmKLYn83HPdTufkthHbbfK9hNMN/ghFl1C6yelJCXqHV5hiYZXtAOakEmNke HB9RktJ28+6/BhDCIfsETAtCtC/jmDpEiRtNzBCdYd9+8CSsFEkmNetGebp+flVV1qJR tvvTR89CrvagDqQST4cykbX4S2vPyLq1o9U1IPM+qL8Ry5KG7nHEPvpzFc7IQ6TJgTws 4DbnkRYmdg3oLjysO0THAc2gVgF0M+zN+hWPIgbgf58dyWnkGOjhYaWt8UVBX4x5PWsK Q9A5ZRzwBMX8S7pevP76rdkNeM4DhlWZ6UOAX0rO2/UDWjEBSkztr3uFSurf0FIiyzGt F4KQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=61mNDokGB9NoVCMqagymHQDB0nYnvd6WPAhsyg7lvN4=; b=tBt4POJjPmlgG0SDCqhY28M17I+jAOLYXKzUTfOQqb1BHU5tL5kpFWCJ3CgyTG4MFB a4k3KR4SDfLXtpIVyN97RcfJMbD1NOg4TKAfurDnQhN9YizTpw8M+OpPx8hPMvcKJtL1 bTy9E4Y3pUlp/1juqc14t4p4gL/5BPAfyFKGVtF+0scpubDm2ukZhPoM7jQR9FBXM1SD 3CYVNU2xZ3T0YWMiT14JI2Oylu729vfVAlwG4FxppDmspSOxmJxfClXLn3k99Vfi6Y1K b8MVXqPZLQTWv5G2WvQGWtbfYzOEFP1Bkx46VLk1wYnSYVd7UMV7ovwvvnbunLCCdjM4 XwYw== X-Gm-Message-State: AMCzsaWe/Ai4ajzDyUmQzAEPPRsCKkwB3VvT/xymUSpZ1YfCDdV3BvHG 1wHnFBxPDQqTDUlvF10Wjcs= X-Google-Smtp-Source: ABhQp+TywvcMDAqOyYK4SJvrAqwKXqXjK2xCtLY32lO9NdGLoQKBlmrb5YT5ifhcel6s12M87eKFbQ== X-Received: by 10.28.156.67 with SMTP id f64mr2082268wme.42.1509463394773; Tue, 31 Oct 2017 08:23:14 -0700 (PDT) Received: from [10.196.222.62] (98-197.icannmeeting.org. [199.91.197.98]) by smtp.gmail.com with ESMTPSA id v35sm4371951wrc.13.2017.10.31.08.23.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 31 Oct 2017 08:23:13 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Geoff Huston In-Reply-To: Date: Tue, 31 Oct 2017 19:23:10 +0400 Cc: Ray Bellis , dnsop@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <027a469c-5bb6-7940-fd89-55b91dd97275@bellis.me.uk> <20171030174052.GB87160@isc.org> To: Tony Finch X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [DNSOP] draft-huston-kskroll-sentinel - naming format? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Oct 2017 15:30:03 -0000 > On 31 Oct 2017, at 6:34 pm, Tony Finch wrote: >=20 > Ray Bellis wrote: >> On 30/10/2017 17:40, Evan Hunt wrote: >>=20 >>> IIRC we discussed it, and were concerned that _ta. could be cached = as >>> nonexistent by servers implementing QNAME minimization. >>=20 >> How would that happen, at least so long as _ta responds like any = other >> empty non-terminal? >=20 > It's NXDOMAIN. (It'll also fall foul of RFCs 8020 and 8198.) >=20 > The problem occurs if you have a validator behind a cache. The cache = will > prevent downstream id._ta. queries from reaching the root, so any > downstream trust anchor variation will be lost. >=20 The mechanism does not rely on these queries reaching the root. The key = aspect is the signal back to the querier. So even caching is quite ok = here. The critical aspect of this mechanism is that it is not intended = to measure resolvers, but detect if an end user has a DNS resolution = environment that will (or will not) be impacted by a roll in the KSK to = a named (via a key tag value) new KSK. Certainly it would remove some of the QNAME minimisation issues if the = test is based on a single label as defined in the draft, and on = reflection I _think_ its probably more robust if its the terminal label, = but frankly I=E2=80=99m not sure about that latter point.=20 Geoff From nobody Tue Oct 31 08:34:16 2017 Return-Path: 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 8BA5913F834 for ; Tue, 31 Oct 2017 08:34:15 -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 (1024-bit key) header.d=apnic.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 vhG5ibkYIHkH for ; Tue, 31 Oct 2017 08:34:08 -0700 (PDT) Received: from APC01-SG2-obe.outbound.protection.outlook.com (mail-eopbgr1290087.outbound.protection.outlook.com [40.107.129.87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E118613F914 for ; Tue, 31 Oct 2017 08:27:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apnic.onmicrosoft.com; s=selector1-apnic-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ntL784ln7UpFOpxmd1hhVjbXHXEUFtF83BDxZ6WqSOY=; b=grru6awMHLM/ZbzjtbkZi1wnqMDH1FEgi7oZZEEAT1fZ0sjsQYNtO13l4B590JeYtxqVBKT3vJ0ymRJ0+xDa+P1VYhxmEsdUGvuOywHaBudxtvkyQ0srWRKCvKY4SCHhg2caPGxHW1HOlmGI8KaApmJ08+zMAhNjRnKqERVkUqE= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=gih@apnic.net; Received: from [10.196.222.62] (199.91.197.98) by HK2PR04MB0691.apcprd04.prod.outlook.com (2a01:111:e400:5892::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.178.6; Tue, 31 Oct 2017 15:27:29 +0000 From: Geoff Huston Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 31 Oct 2017 19:27:06 +0400 References: <027a469c-5bb6-7940-fd89-55b91dd97275@bellis.me.uk> <20171030174052.GB87160@isc.org> To: dnsop@ietf.org In-Reply-To: Message-Id: <12DEDFB4-AA8B-4495-AFA0-CB72AE03B2FE@apnic.net> X-Mailer: Apple Mail (2.3273) X-Originating-IP: [199.91.197.98] X-ClientProxiedBy: HE1PR0402CA0040.eurprd04.prod.outlook.com (2603:10a6:7:7c::29) To HK2PR04MB0691.apcprd04.prod.outlook.com (2a01:111:e400:5892::21) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: bd5e9f01-e94a-4cbb-9192-08d52073e6e7 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(2017052603199); SRVR:HK2PR04MB0691; X-Microsoft-Exchange-Diagnostics: 1; HK2PR04MB0691; 3:QQUeLkQykK9iCMSGzeeavU5CVT7X/muENnhF6tx4SdCenwaIgnQ4Ufy2HAMcb8nYIL8ZziIpw01nMImjk3S5KgghtIsVYNpDSSwP4pSnVtcHxx5tpjgmrj27vhwo9fbIO0Ty/DdhGyfH5OQu1hlmPg7zXlUDXLJYiVYHBnuMt9k5ifkwum8rts37970nX9LSW6mdoJs5gK6axcdLKdi9MB593Snxc/D56EZ/WmCFIhKYOoBUk2x1C+jnDzi8Lsex; 25:T+2T7Pa/RGbhrqgGKwAZeWXJ6pMvxIcAUYs8JUqEw8tEW8YzLHExOd4RGYlnxzNA+hPT0bfBXH6/osVTBV4kq3qrUP4PtIjW7srRJFBa+u4j2FyQzNDYzdCS5S1UGRPNmHs2HSawiib2H5UE8pkP1Vv3JLum5QzVlyB08h1fQOCMvkv1AlKEa8hU1QUENbSQbZq2STCs/FGsRBLnVTw7M688zvdhKeRCnge79Iivzuyd8g//gqQ4aCrsw1rboqjwmFxxw8YIpkRC5wpubyCYr9ijbVYFPWirQNY7AhGB8yrQ1f+cg5inuJYtH3kzXhC0qLPaZ9ujD2Xx111yF++JIQ==; 31:jrty+QLXOtwSbBTEbbT1vFqKqXdCcDeJcYrjJ9uyhMDgoxML7f6dPPXUi6pdqNSYAcsS8I8t0V8O3/3UTUgrsTBqhIypIQhMkHv8A0LoH1EoPwIRfOu/QA1ZRc4kYwKvb72aQpLDVZtMtEuZfOl4NCBXUN253CslfM7ZWKzyYpSQNcrAEZRz+1Mwm9hioU0+m+3O1eUR9H/EladllwHf5MPHOnR+Xy9R7d0I9Re3LE8= X-MS-TrafficTypeDiagnostic: HK2PR04MB0691: X-Exchange-Antispam-Report-Test: UriScan:; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3231020)(3002001)(100000703101)(100105400095)(6041248)(20161123555025)(20161123560025)(20161123564025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:HK2PR04MB0691; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:HK2PR04MB0691; X-Microsoft-Exchange-Diagnostics: 1; HK2PR04MB0691; 4:mb6RtAKryWEZUOZ9+IAE6Z+npkBZg67PkN5yA7cBoGtMWKxeA8HXE/fK7bfKLC82tdwd329HUaTocxlOBd0535IGwlH+ecqWCbbDW0OTqdjiPRL9ihV0KuIuMlSgwgD+2NgBW4XEgyZ5dikhMAqLfS1LyMIN4bcf074no8h9Ckn+0T4vQqQI/Hg0t7ng2h0m9PhhOb0A0OoLopDDroN+asnIxjs8O41CU3CQeYjp7hOSfO/4dG30VBekdevp+DtWHgkofO4+qy/idV35m48cTw== X-Forefront-PRVS: 04772EA191 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6049001)(6009001)(39830400002)(376002)(346002)(24454002)(199003)(189002)(230783001)(93886005)(50466002)(50226002)(2351001)(106356001)(3846002)(6116002)(16576012)(6916009)(2950100002)(23676003)(47776003)(97736004)(83716003)(57306001)(316002)(6666003)(53546010)(189998001)(86362001)(33656002)(6486002)(82746002)(36756003)(25786009)(77096006)(5660300001)(16526018)(229853002)(66066001)(105586002)(81166006)(68736007)(8676002)(53936002)(8936002)(8746002)(81156014)(7736002)(305945005)(478600001)(6246003)(101416001)(2906002)(2361001)(76176999)(50986999)(42262002); DIR:OUT; SFP:1101; SCL:1; SRVR:HK2PR04MB0691; H:[10.196.222.62]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: apnic.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtISzJQUjA0TUIwNjkxOzIzOk8rOUZwTGsvc01DcGQrWEx5aEh5MU5sRXVF?= =?utf-8?B?bXdQN0FZSGF1WC9OT21McGhqaXNvd1BJNi9zVmwrZ0YrbGlGaGRabWZrZkd6?= =?utf-8?B?SWEzb2VoK2JIT3Y2QStENDFEKzBLMDE1RlNjcWo3bjR6UlpmYkJQUVhXNlUx?= =?utf-8?B?bnRDWmdkUVlpQ3dCRm1YbldESzVTeVB2Ym54ODdsM3ZrOGZXb0crTzlqZ05h?= =?utf-8?B?SkJFaGNkeGpIUG1EbDFQdjVWK0ZJUGdZVWpIZjM3dGlDbFV2Zk1nMTlxZkVF?= =?utf-8?B?TE5PN291R0ZPaWdueG90TDM1OHRSck5LbnVRRGkwdmRTNWh1Zy9FNEFhSEtZ?= =?utf-8?B?SFRKZVZPVVRKWVlSajdndk8waXNyRlpMN0tudEViUmxVdlA3WUxUZVI1T0xi?= =?utf-8?B?R1F1dFRsNTZZM3NHL09ZVlVZYk9YQmd2aHA3RVlieEZpTGlWSnlqT1IraTRC?= =?utf-8?B?UmdKU0p3Z3FqVkFvOXdYcUlTMHZ0VXdNd2x6dWFXOFFncDNhNGV6WG1BTXBB?= =?utf-8?B?dnRkWDJjMDdMT3NGNTZXQ2xDV254eUFkSmk0Q2pLZmJqUzJ3Yk14N2Zad3Fy?= =?utf-8?B?V0tnejBNbE9xWFR5OEZIdzREd2ExK2VENDVRRi9QKzIvV1NMbzZGaGt6Ni9h?= =?utf-8?B?c01OeHNkWExodGlleEp0OTF5MW9sclBSYnJzZ2djSWFMWjBrRzZUNzdzd1lB?= =?utf-8?B?TVhQZ1ZTcWhMY1ZnbWVlTlZjeVJxWk5PcTkrOTMyMS9XKzE4My9ZRWYxei83?= =?utf-8?B?aENvalZBd2VkZ2RZN0FhQkxRZHNnSmpobCtxVUZpVzhmOTdBN0I4L0c4RDZY?= =?utf-8?B?VDFwUnJHOXBNQUpMZ0ZWbk56OW9iNmJVZVlmbjFWdUdjRGxRbWZscU15RFNC?= =?utf-8?B?V0JFeU45cHNCSkdWbHIxVnpKYy9VcmQwMHRxc3lBbGZ6WVdxcTZJam9nSXJP?= =?utf-8?B?VURjQlp1bC9xVzlaY0g3eUhoY2MvQUNBdW5kbzQ4MElGWFhLWW41eTBwZHBH?= =?utf-8?B?ZmYvVENCUnZVcHcwQnVpVU4wMkpqRWVhenNOeVhqWXcrZ296aG5EbERja3ZZ?= =?utf-8?B?N2RpMUI1ZS9mck8yRzJGMUp3Uk9SMVdnUWdCTnZKL3AzVGlrdUIxcm9FYkxu?= =?utf-8?B?V0MvLzZ5SlcxN3NZRGVlUFRKZTZzb29SSGUwdi8rZElVOUJjajRtZnU3Z2xk?= =?utf-8?B?N3IxWlVkQzZKeTFkMk42WllvRHc3OEdpRTJ2L2luSTlGVnQ4TnBRNEt4VmYx?= =?utf-8?B?OU9IZEkyTzVjbW5Dd0FTYXQzK0ZvSWlDdkEyUU5RS0pXclVuZElFQnJ2K3FN?= =?utf-8?B?ZUdqTnpEQ3h1T2JmWmlUNnNFb2wybERxcmJKc3JoZzJrREpDTzBmMW5FUUtW?= =?utf-8?B?RzhMdkMxNnhwRTZPanpLUVFZS2tqZWRtZnZQSG5JOWVUT3JiMGYvd0pZSGVL?= =?utf-8?B?S3FicWNOT2VQdFlIQ3A1QzBJM2luMHp1UEs0ZFFhblFlU2sxTnVBK3QzNHM2?= =?utf-8?B?SW55VjN1ZXcvUkFHVC9Kdy9LWXFCRkJSVkNoNzRTVWJyMVNNek1pbzZDbFZi?= =?utf-8?B?UWx4ZStMcm91VnhPY0xKZ2xwaVZNMVFuYzNCMG1VN3NDMFJRSXRXbk4yNlNl?= =?utf-8?B?dU82Zk82eGV0YVhqQlJ3SWxvZ3RGVWg5VzlSUGN0aE5EdGhKUEhWL05uUjdD?= =?utf-8?B?S3A2ZXg3OUJNS2I2aklIR3RreUVoMjZwdCtnbkhTbkZNdUV5cXh5RXY0YTRl?= =?utf-8?Q?W2VPKOfDYuE9jRTeKVn/ZqKMo2PbD0hOuvH0Y=3D?= X-Microsoft-Exchange-Diagnostics: 1; HK2PR04MB0691; 6:mpzKqAZpigqn1Z2BfPM1/msH5mSh2ecPNrxKn5VHxMpAtjVjOYOZJSu6I9eTtpZOKnHschW529UEro47LTLfdM42GiN60hHJ3Iw9rmEc8aXMLWHXQAJo2PkGSy2Qh/SBLv8i6FZSPPgp9tROoGHeSqRIiMPOFhnTsHbOF61uDuZprZFY9BC6N7R3xHgzEfGJh8Nxxd3NoYa1BLQF47aQOznvMP3sSuAg2TDzznJzA21jKnd/pTnS0TExsBvEZ0A+zAAJlmwE5Z0VUeTL/ikJXkftq3s91D8aYJPlEXvI8cm5o/RB04Vnb0nWPnt5QT8BWejOdIqCjSNa7O3bhI7XXEiD73uGjFsmZq16l4UsKPw=; 5:TT83JShS8aV8xtBomxmLIkZvTtDZhoQpKkZcGx/Q3yF+gO8zTUBEnw1Yvi/hSAK0UB182WM5qRLrDEEv6qMcxmScpL+zUnemEv+HzJwY5QZERAm+SRwS6281lMl2Rn5uqD17Yu3CHY9eavdKGOR5b7vtJWsZXF7L7S4Ebx3nRzk=; 24:rMsOtL+Xickoih95wbJbr2JhR8KfJecDG1Mqdyq3x3XiuilmPqmS2UHQDsLtPcxfkWQEch/7G796JndFnpZjhZhg9+iISt2PENhF0OEq7AI=; 7:Yf2dylrzLOslqwRILTChgmCl8aj1chD09zwrO4OxpNxmQsptj0sX5yMvd/BShRwVy+OwoM5EhMow4ouR30RHgeyNteSsfJKurrA/QTwYimfqcvdUyCGbg00xg28b0wNReVmCGoKx8ezWVveZc+ors5ziw+QETVKy5wRyj0vVFNmZq/KVTJzjWm4VPceF0nNLfjr1blTqzx8pIP4FBBqpLp10+X3LZZEK5ETJPqUTH0m8fEf07il3yYRRwSINxWFn SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: apnic.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 Oct 2017 15:27:29.8962 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: bd5e9f01-e94a-4cbb-9192-08d52073e6e7 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 127d8d0d-7ccf-473d-ab09-6e44ad752ded X-MS-Exchange-Transport-CrossTenantHeadersStamped: HK2PR04MB0691 Archived-At: Subject: Re: [DNSOP] draft-huston-kskroll-sentinel - naming format? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Oct 2017 15:34:15 -0000 > On 31 Oct 2017, at 6:34 pm, Tony Finch wrote: >=20 > Ray Bellis wrote: >> On 30/10/2017 17:40, Evan Hunt wrote: >>=20 >>> IIRC we discussed it, and were concerned that _ta. could be cached = as >>> nonexistent by servers implementing QNAME minimization. >>=20 >> How would that happen, at least so long as _ta responds like any = other >> empty non-terminal? >=20 > It's NXDOMAIN. (It'll also fall foul of RFCs 8020 and 8198.) >=20 > The problem occurs if you have a validator behind a cache. The cache = will > prevent downstream id._ta. queries from reaching the root, so any > downstream trust anchor variation will be lost. >=20 The mechanism does not rely on these queries reaching the root. It's the = signal back to the querier that=E2=80=99s important here. So even = caching is quite ok. The critical aspect of this mechanism is that it is = not intended to measure resolvers, but detect if an end user has a DNS = resolution environment that will (or will not) be impacted by a roll in = the KSK to a named (via a key tag value) new KSK. Certainly it would remove some of the QNAME minimisation issues if the = test is based on a single label as defined in the draft, and on = reflection I _think_ its probably more robust if its the terminal label, = but frankly I=E2=80=99m not sure about that latter point.=20 Geoff From nobody Tue Oct 31 08:51:46 2017 Return-Path: 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 AAC1413F79E for ; Tue, 31 Oct 2017 08:51:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopcount.ca 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 nrypuEV2e0p3 for ; Tue, 31 Oct 2017 08:51:38 -0700 (PDT) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::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 BF25913F777 for ; Tue, 31 Oct 2017 08:51:35 -0700 (PDT) Received: by mail-io0-x22d.google.com with SMTP id 97so36132345iok.7 for ; Tue, 31 Oct 2017 08:51:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=9Inhiu8CmBfMfAFRDKZy5tnU7wNVtfytBkYT2KAglMo=; b=AXEiHRmLfK6kpr23LZ6BDMwjVbUSC26h0YXd+o+pDNS729/JgbnQaBl0eOxzyroXxL 5fnA+KysKnsuoA2kbLrPScaz2H+xm7BREqsEF0aeDV7ZzUvmOnDDFOoue2hs8xHU2gk3 Rhfn7um3eb1DFiGPEIe5IxYQW6OAfYqDDk5w0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=9Inhiu8CmBfMfAFRDKZy5tnU7wNVtfytBkYT2KAglMo=; b=DbFLHMOqIVvpoXUmX7WHuNgOK/1FYVho4WgJVcs0Ur7X8vdDGo6K2OLTWSR+16I2yD tlbbbPlMfob3flrWccdmQUCblH1btW1rg99axoCz5nLmjNUumC6InD93Nby8Y3IgrSX9 SMrZD+0FgPzTZGJJpcgb7sFYR4xtcEiggAhxgTv4tb2ECmhI0BjMAyR8JiN/gmRZrce2 zsnXcqPbAXeKMKysJ470gIgPBSY5bvcGZ0g0PvPQZ05CChYnrvbd+jCR4+rZuWNWXIGy SVdg9kJvwu2skiLv4Xz8j7mybJu75nD8lCvcvi8OXAJYl+tuPvvQCBkAfwxD9VIIS8es 96/g== X-Gm-Message-State: AMCzsaVWVorWW23dZoXjh0KecuimJyvL2zr1xESZyCkxUYJqwwB88pfF QuZleGC0YQiGHQgKT6uQSzAgzw== X-Google-Smtp-Source: ABhQp+SaqcBk94BTDOAfLHzOebU5yyHzCWUPt0bgYUsFOSxmTrioyAs0tJqWqPlLQnzl6Lkp5TbpjQ== X-Received: by 10.36.79.10 with SMTP id c10mr3654632itb.146.1509465095023; Tue, 31 Oct 2017 08:51:35 -0700 (PDT) Received: from ?IPv6:2607:f2c0:101:202:6409:9c5b:60c2:7a05? ([2607:f2c0:101:202:6409:9c5b:60c2:7a05]) by smtp.gmail.com with ESMTPSA id g79sm1003238itb.43.2017.10.31.08.51.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 31 Oct 2017 08:51:34 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.7\)) From: Joe Abley In-Reply-To: Date: Tue, 31 Oct 2017 11:51:27 -0400 Cc: dnsop@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <88551C53-593F-4672-9655-4530F4B8068A@hopcount.ca> References: <027a469c-5bb6-7940-fd89-55b91dd97275@bellis.me.uk> <20171030174052.GB87160@isc.org> To: Ray Bellis X-Mailer: Apple Mail (2.3445.1.7) Archived-At: Subject: Re: [DNSOP] draft-huston-kskroll-sentinel - naming format? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Oct 2017 15:51:40 -0000 On 31 Oct 2017, at 11:01, Ray Bellis wrote: > On 31/10/2017 14:56, Joe Abley wrote: >=20 >> Perhaps I missed something, but how do you ensure that _ta is an >> empty non-terminal? >=20 > By having that be part of the required server logic to implement the > sentinel mechanism? If a format is going to be specified that specifically prohibits a zone = cut, doesn't it make more sense to choose one that can't possibly = involve one because there are no potential label boundaries? Joe= From nobody Tue Oct 31 11:10:09 2017 Return-Path: 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 2711613FA1D for ; Tue, 31 Oct 2017 11:10:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.501 X-Spam-Level: X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, SPF_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 bDDspK-8ZWah for ; Tue, 31 Oct 2017 11:10:03 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55EF213FA12 for ; Tue, 31 Oct 2017 11:10:03 -0700 (PDT) Received: from [IPv6:2001:559:8000:c9:4987:fe28:d911:202c] (unknown [IPv6:2001:559:8000:c9:4987:fe28:d911:202c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id BC4BC61FA2; Tue, 31 Oct 2017 18:10:02 +0000 (UTC) Message-ID: <59F8BC79.6040709@redbarn.org> Date: Tue, 31 Oct 2017 11:10:01 -0700 From: Paul Vixie User-Agent: Postbox 5.0.20 (Windows/20171012) MIME-Version: 1.0 To: Joe Abley CC: Ray Bellis , dnsop@ietf.org References: <027a469c-5bb6-7940-fd89-55b91dd97275@bellis.me.uk> <20171030174052.GB87160@isc.org> <88551C53-593F-4672-9655-4530F4B8068A@hopcount.ca> In-Reply-To: <88551C53-593F-4672-9655-4530F4B8068A@hopcount.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] draft-huston-kskroll-sentinel - naming format? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Oct 2017 18:10:09 -0000 Joe Abley wrote: > If a format is going to be specified that specifically prohibits a > zone cut, doesn't it make more sense to choose one that can't > possibly involve one because there are no potential label > boundaries? +1. -- P Vixie From nobody Tue Oct 31 11:24:21 2017 Return-Path: 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 D00B013F5AE for ; Tue, 31 Oct 2017 11:24:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-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 qsqO7F5uEpS4 for ; Tue, 31 Oct 2017 11:24:19 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) (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 C558313F502 for ; Tue, 31 Oct 2017 11:24:18 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384) (Smail #157) id m1e9bCx-0000EpC; Tue, 31 Oct 2017 19:24:15 +0100 Message-Id: To: dnsop@ietf.org Cc: "Paul Hoffman" From: Philip Homburg Sender: pch-bCE2691D2@u-1.phicoh.com References: <121CDBC2-D68C-48EE-A56E-46C61FC21538@sidn.nl> <897E0B21-1A78-45F5-95CF-B87FD36524FC@vpnc.org> In-reply-to: Your message of "Tue, 31 Oct 2017 07:42:32 -0700 ." <897E0B21-1A78-45F5-95CF-B87FD36524FC@vpnc.org> Date: Tue, 31 Oct 2017 19:24:14 +0100 Archived-At: Subject: Re: [DNSOP] Resolver behaviour with multiple trust anchors X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Oct 2017 18:24:21 -0000 >It sounds like clarification is needed if even one (much less three) >systems treat such a signature as Bogus. My reading of RFC 4035 is that >any chain that successfully leads to a trust anchor should return >Secure, even if a different chain returns Bogus. If extra trust anchors are configured for security reasons (as opposed to availability) then I would expect some sort of longest match on the trust anchor that is to be used. For example, if I configure a trust anchor for example.com for security reasons, then that is probably because I don't fully trust the .com zone or even the root zone. If then a record fails to validate using the trust anchor that is configured for example.com, then it would be very bad if the resolver turns around and suddenly trusts the information from the .com zone. From nobody Tue Oct 31 11:25:42 2017 Return-Path: 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 C17CB13FA3C for ; Tue, 31 Oct 2017 11:25:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.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 JSe7W7WxrenJ for ; Tue, 31 Oct 2017 11:25:37 -0700 (PDT) Received: from mail-wr0-x231.google.com (mail-wr0-x231.google.com [IPv6:2a00:1450:400c:c0c::231]) (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 9563713F85B for ; Tue, 31 Oct 2017 11:25:37 -0700 (PDT) Received: by mail-wr0-x231.google.com with SMTP id g90so16796401wrd.6 for ; Tue, 31 Oct 2017 11:25:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=XzN6O8ZvnBmeo5G3vBZABMipBm5h/dKRPm6D0KQHXWQ=; b=TZtcW6kXAMuGuWMHzf7x54yLjjjyjv09CA0pepaZM/cgT+7N9f/PbkPhKH/VvjTykJ HkfJQrLq3j54cgc8HRXDw7hUGHMRGrhmpgUsNHuPpf90OcLnkCFw3g/PQVfbG7De9YIN rDYfp14dOVXlVKUXQ0EKI0DZGYWfRsBa/ORV4= 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; bh=XzN6O8ZvnBmeo5G3vBZABMipBm5h/dKRPm6D0KQHXWQ=; b=L82stE9moX0EjHb2EQEj/wJ+vHm4jXcCxLxw+J9BdxigAXrhLpPyZQCUZpJg/Px8pz b752KHWFr1yYVQidmjPDQRqxKBV9M91CiHYxFK/+/Cq/TNhIyBTbh0hykDoLI9mB4mwW /XmA1EIknwM7fYtTR3EHXH4svjFE/zLcQ7lU2iR4KRGMGeMDHbPlmPglM8DlZpnyBFlu XgpGBvPGq28Ddz2dYazrZpytAZqLohp2oj+A7aoGUC2eDsrjiIpLA6YYyaCYpCoM04RO LiYTauRf3ZGGxoFFPxR9+Ojm6Ynwd3yJL15eycZme9Yuoj2Z2KkVjVQ9tzOg1DPe3Doe sVOw== X-Gm-Message-State: AMCzsaWEf6BRQUR0EJEi8n+7ni0FlrdYKOEI7fmtLOZjdfMywyseEj96 z/VCamDzp9z/O0+262HS2lQgtqANutUjd31TmOc8oQ== X-Google-Smtp-Source: ABhQp+S81ECpvbaAPpSRX+5Xp4rWfdGKy81K1S4i08sX8TdPnOOVAWfg0/RqlwtqhicR3ZBnN0eALKYDujCQq1X6Wuw= X-Received: by 10.223.135.90 with SMTP id 26mr2547258wrz.114.1509474335878; Tue, 31 Oct 2017 11:25:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.201.10 with HTTP; Tue, 31 Oct 2017 11:25:35 -0700 (PDT) In-Reply-To: <121CDBC2-D68C-48EE-A56E-46C61FC21538@sidn.nl> References: <121CDBC2-D68C-48EE-A56E-46C61FC21538@sidn.nl> From: =?UTF-8?B?w5NsYWZ1ciBHdcOwbXVuZHNzb24=?= Date: Tue, 31 Oct 2017 11:25:35 -0700 Message-ID: To: Moritz Muller Cc: "dnsop@ietf.org" Content-Type: multipart/alternative; boundary="001a1146a3ec9682d7055cdbe170" Archived-At: Subject: Re: [DNSOP] Resolver behaviour with multiple trust anchors X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Oct 2017 18:25:40 -0000 --001a1146a3ec9682d7055cdbe170 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable There are three ways to treat this case: Any-TruestedKey-works ConfiguredKey-trumps-DS DS-trumps-configuredKey I think the Last one is the "most" correct from an operational expectation, but the first one is least likely to run into errors, But I suspect the middle one is implemented Olafur On Tue, Oct 31, 2017 at 2:39 AM, Moritz Muller wrote: > Hi, > > Together with my colleagues I have been stumbling upon a, for me, unclear > case when validating trust anchors. > > Assuming that a resolver has enabled DNSSEC validation and has the root > keys configured. > Additionally, it has configured manually a trust anchor for a TLD (that > has also published its DS in the root zone). > Now, for example due to a key rollover at the TLD, the manually configure= d > trust anchor of the TLD does not match the DS in the root anymore. > > How should a resolver treat the signatures of this TLD? > The resolvers of BIND, Unbound, and PowerDNS seem to treat the signatures > of the TLD as bogus, but we didn't find any specifics in RFC 4034 and 403= 5 > that describe how resolvers should behave in this case. > Knot resolver treats them as NOERROR (according to the developers). > If we interpret section 4.3 of RFC 4035 then we would have assumed that > the signature must be treated as secure. > > Did we miss something, or is there indeed clarification needed? > > =E2=80=94 Moritz > > > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > > --001a1146a3ec9682d7055cdbe170 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

There are three ways to treat this case:=C2=A0
Any-TruestedKey-works=C2=A0=C2=A0
ConfiguredKey-trumps-DS= =C2=A0
DS-trumps-configuredKey

I think t= he Last one is the "most" correct from an operational expectation= , but the first one is least likely to run into errors,=C2=A0
But= I suspect the middle one is implemented=C2=A0

Ola= fur


On Tue, Oct 31, 2017 at 2:39 AM, Moritz Muller <moritz.mu= ller@sidn.nl> wrote:
Hi,
Together with my colleagues I have been stumbling upon a, for me, unclear c= ase when validating trust anchors.

Assuming that a resolver has enabled DNSSEC validation and has the root key= s configured.
Additionally, it has configured manually a trust anchor for a TLD (that has= also published its DS in the root zone).
Now, for example due to a key rollover at the TLD, the manually configured = trust anchor of the TLD does not match the DS in the root anymore.

How should a resolver treat the signatures of this TLD?
The resolvers of BIND, Unbound, and PowerDNS seem to treat the signatures o= f the TLD as bogus, but we didn't find any specifics in RFC 4034 and 40= 35 that describe how resolvers should behave in this case.
Knot resolver treats them as NOERROR (according to the developers).
If we interpret section 4.3 of RFC 4035 then we would have assumed that the= signature must be treated as secure.

Did we miss something, or is there indeed clarification needed?

=E2=80=94 Moritz




_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


--001a1146a3ec9682d7055cdbe170-- From nobody Tue Oct 31 11:30:28 2017 Return-Path: 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 3654213FA5B for ; Tue, 31 Oct 2017 11:30:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 ZbU7oICVTv5N for ; Tue, 31 Oct 2017 11:30:24 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 D0DE013FA4F for ; Tue, 31 Oct 2017 11:30:22 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3yRKf46zFFzF7T; Tue, 31 Oct 2017 19:30:20 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1509474621; bh=Twixip/R3hh7gpSPgNiOt8yfHcLk4hf5vRXt0yzSCOI=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=os7zSeg7CA9QgDg8u1s2/iDgpSvv7+YX0IKbuJHo3xUzlwNr1QH20h6jC2Pr/bwZC ZJZGZJPUfmDK0YbBpGfUVobdXffwLTF3pFoLNvncpB4wewP5J/gbUZa7i6ihhpGwDn 50S6DR4mxqlI3yExRnN2i4EIybWNw3VYqG8ru1S4= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id xFo63j8H4EP9; Tue, 31 Oct 2017 19:30:19 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 31 Oct 2017 19:30:19 +0100 (CET) Received: from [10.252.1.42] (unknown [2.50.18.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bofh.nohats.ca (Postfix) with ESMTPSA id A9C6F62D29; Tue, 31 Oct 2017 14:30:18 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca A9C6F62D29 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Paul Wouters X-Mailer: iPhone Mail (15A432) In-Reply-To: Date: Tue, 31 Oct 2017 22:30:13 +0400 Cc: Moritz Muller , "dnsop@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <121CDBC2-D68C-48EE-A56E-46C61FC21538@sidn.nl> To: =?utf-8?Q?=C3=93lafur_Gu=C3=B0mundsson?= Archived-At: Subject: Re: [DNSOP] Resolver behaviour with multiple trust anchors X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Oct 2017 18:30:26 -0000 > On Oct 31, 2017, at 22:25, =C3=93lafur Gu=C3=B0mundsson wrote: >=20 >=20 > There are three ways to treat this case:=20 > Any-TruestedKey-works =20 > ConfiguredKey-trumps-DS=20 > DS-trumps-configuredKey >=20 > I think the Last one is the "most" correct from an operational expectation= , Not really, as that would mean you cannot have internal only zones in split-= dns view, unless you are building in weird assumptions like ConfiguredKeyTrumpsNSECbutNotDS > But I suspect the middle one is implemented=20 It better, it is the only working solution :)= From nobody Tue Oct 31 12:23:35 2017 Return-Path: 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 C2D3313AD2D for ; Tue, 31 Oct 2017 12:23:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.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 ARHOC1sBCNg9 for ; Tue, 31 Oct 2017 12:23:32 -0700 (PDT) Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::232]) (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 5F8EA1389C1 for ; Tue, 31 Oct 2017 12:23:32 -0700 (PDT) Received: by mail-qt0-x232.google.com with SMTP id 8so112011qtv.1 for ; Tue, 31 Oct 2017 12:23:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=7ho0RK9OObcflXRV75bAqoQ4ib034j3QzjKch3Bgir4=; b=TktDopUhm+nJC4s8E+R70SnV2IQ5yHqqs/6HvK+c7gPPppDF+JHwOxFO8zOsT8eYg1 uAzPHao/wkukwPxOLC+ddE12CbEQ7L/xdZXQqugzzqLmNc9MtNrswiLJsPk8Z9EHeZYx 0G9xoovZGasPedgcda0z1QjGtj6edFIBZ7XsJjHCQkm6Vrg2PmSsr/34+bro4eSJxYIb MJNx5IaUGHzT0icLKtqjAd+ce00Y7R/SN8oJhXJWvLSncyvzo0pxHWeVXAN6+qzdOaOW RllfdF0uNjqKare8yZcx5Z0dLA3xevFFI8Ftr/xIcysoqCTxLRYQaREubesjAyKEbV0X KFUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=7ho0RK9OObcflXRV75bAqoQ4ib034j3QzjKch3Bgir4=; b=ogjRjIu+sTinXNCrzjxQLDJBmQIb40+movN+L7rvdXL3YRJKhwChYMDe0U744GDr08 wP88x1m9ynGghD4EbVfixVQrfhC99IoGKabgWB5zWDRtkS2bSiNJEDciRfMQ3TXuN5bl VfXRuKMR1CJs0dRxagv7+rMaoyXxSoO7tHO1h0FzDI8WV8V/rTr5ThENbUUm9bVfU31S R/S9w4jqTjFg7F/Jf+KTRXWZs5OnLvXoMLc27QzJoX6qGgIQhyQql2fi+WV7xvG9gDtg rhjbHbOoZN1HqHxsz18HWqmJM7aZhPZwm/6RrhVpdjjBPASiapIJ8OtJyR1yppAjW67m /3dA== X-Gm-Message-State: AMCzsaVX9u4vaqE+F9cvDhfcwAdVDJRwgsxPgSO00YdPUA81v1Spcff3 fzU4pIbs+lXeUb0e3fTed33AVeec X-Google-Smtp-Source: ABhQp+TG3A8QUQOL6cnPa4fIeYraI+YoW2RojSpE1evvKQBzaeatylh58+x1jaSaQbKyA1aG0POa+Q== X-Received: by 10.200.26.216 with SMTP id h24mr4526037qtk.175.1509477811029; Tue, 31 Oct 2017 12:23:31 -0700 (PDT) Received: from ?IPv6:2601:152:4400:720f::146e? ([2601:152:4400:720f::146e]) by smtp.gmail.com with ESMTPSA id r16sm1415764qtc.4.2017.10.31.12.23.29 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 31 Oct 2017 12:23:29 -0700 (PDT) To: dnsop@ietf.org References: <121CDBC2-D68C-48EE-A56E-46C61FC21538@sidn.nl> From: Michael StJohns Message-ID: Date: Tue, 31 Oct 2017 15:23:26 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <121CDBC2-D68C-48EE-A56E-46C61FC21538@sidn.nl> Content-Type: multipart/alternative; boundary="------------1A6F0361FD716DB8F7755784" Content-Language: en-US Archived-At: Subject: Re: [DNSOP] Resolver behaviour with multiple trust anchors X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Oct 2017 19:23:34 -0000 This is a multi-part message in MIME format. --------------1A6F0361FD716DB8F7755784 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 10/31/2017 5:39 AM, Moritz Muller wrote: > Hi, > > Together with my colleagues I have been stumbling upon a, for me, unclear case when validating trust anchors. > > Assuming that a resolver has enabled DNSSEC validation and has the root keys configured. > Additionally, it has configured manually a trust anchor for a TLD (that has also published its DS in the root zone). > Now, for example due to a key rollover at the TLD, the manually configured trust anchor of the TLD does not match the DS in the root anymore. > > How should a resolver treat the signatures of this TLD? > The resolvers of BIND, Unbound, and PowerDNS seem to treat the signatures of the TLD as bogus, but we didn't find any specifics in RFC 4034 and 4035 that describe how resolvers should behave in this case. > Knot resolver treats them as NOERROR (according to the developers). > If we interpret section 4.3 of RFC 4035 then we would have assumed that the signature must be treated as secure. > > Did we miss something, or is there indeed clarification needed? A couple of things -  Make sure that the subordinate trust anchor is still a trust anchor.   It's possible that  RFC5011, section 5 came into play: > Alternately, a trust point that is subordinate to another configured > trust point MAY be deleted by a resolver after 180 days, where such a > subordinate trust point validly chains to a superior trust point. > The decision to delete the subordinate trust anchor is a local > configuration decision. Once the subordinate trust point is deleted, > validation of the subordinate zone is dependent on validating the > chain of trust to the superior trust point The idea here was to deal with the transition from unsigned root to signed root, but still allow for situations where the subordinate zone wanted to ensure it was able to manage its own trust point. This should have been a bind/unbound/powerdns configuration item but who knows. But sadly - the language in RFC6840 section 5.10 is controlling... basically, any implementation can do whatever it wants. > A DNSSEC validator may be configured such that, for a given response, > more than one trust anchor could be used to validate the chain of > trust to the response zone. For example, imagine a validator > configured with trust anchors for "example." and "zone.example." > When the validator is asked to validate a response to > "www.sub.zone.example.", either trust anchor could apply. > When presented with this situation, DNSSEC validators have a choice > of which trust anchor(s) to use. Which to use is a matter of > implementation choice. Appendix C discusses several possible > algorithms. And once again we see the folly of the words "implementation choice" when trying to come up with a coherent DNS. Later, Mike > > — Moritz > > > > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop --------------1A6F0361FD716DB8F7755784 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 10/31/2017 5:39 AM, Moritz Muller wrote:
Hi,

Together with my colleagues I have been stumbling upon a, for me, unclear case when validating trust anchors.

Assuming that a resolver has enabled DNSSEC validation and has the root keys configured.
Additionally, it has configured manually a trust anchor for a TLD (that has also published its DS in the root zone).
Now, for example due to a key rollover at the TLD, the manually configured trust anchor of the TLD does not match the DS in the root anymore.

How should a resolver treat the signatures of this TLD?
The resolvers of BIND, Unbound, and PowerDNS seem to treat the signatures of the TLD as bogus, but we didn't find any specifics in RFC 4034 and 4035 that describe how resolvers should behave in this case.
Knot resolver treats them as NOERROR (according to the developers).
If we interpret section 4.3 of RFC 4035 then we would have assumed that the signature must be treated as secure.

Did we miss something, or is there indeed clarification needed?

A couple of things -


 Make sure that the subordinate trust anchor is still a trust anchor.   It's possible that  RFC5011, section 5 came into play:

 Alternately, a trust point that is subordinate to another configured
   trust point MAY be deleted by a resolver after 180 days, where such a
 subordinate trust point validly chains to a superior trust point.
   The decision to delete the subordinate trust anchor is a local
   configuration decision.  Once the subordinate trust point is deleted,
   validation of the subordinate zone is dependent on validating the
   chain of trust to the superior trust point

The idea here was to deal with the transition from unsigned root to signed root, but still allow for situations where the subordinate zone wanted to ensure it was able to manage its own trust point.  This should have been a bind/unbound/powerdns configuration item but who knows.

But sadly - the language in RFC6840 section 5.10 is controlling...  basically, any implementation can do whatever it wants.

A DNSSEC validator may be configured such that, for a given response,
more than one trust anchor could be used to validate the chain of
trust to the response zone. For example, imagine a validator
configured with trust anchors for "example." and "zone.example."
When the validator is asked to validate a response to
"www.sub.zone.example.", either trust anchor could apply.

When presented with this situation, DNSSEC validators have a choice
of which trust anchor(s) to use. Which to use is a matter of
implementation choice. Appendix C discusses several possible
algorithms.

And once again we see the folly of the words "implementation choice" when trying to come up with a coherent DNS.

Later, Mike



— Moritz






_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


--------------1A6F0361FD716DB8F7755784-- From nobody Tue Oct 31 12:33:23 2017 Return-Path: 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 AC72913F5B7 for ; Tue, 31 Oct 2017 12:33:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_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 SF84IZm1EYoU for ; Tue, 31 Oct 2017 12:33:21 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org [64.78.40.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6693013F5C6 for ; Tue, 31 Oct 2017 12:33:19 -0700 (PDT) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 31 Oct 2017 12:33:17 -0700 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1178.000; Tue, 31 Oct 2017 12:33:17 -0700 From: Edward Lewis To: Paul Wouters , =?utf-8?B?w5NsYWZ1ciBHdcOwbXVuZHNzb24=?= CC: Moritz Muller , "dnsop@ietf.org" Thread-Topic: [Ext] Re: [DNSOP] Resolver behaviour with multiple trust anchors Thread-Index: AQHTUiwiqVxvIHBV0Uun1GqDhxVA26L+vEmAgAABTICAABGcgA== Date: Tue, 31 Oct 2017 19:33:16 +0000 Message-ID: <4678D8A8-1AA0-4684-BFD1-40C969305C49@icann.org> References: <121CDBC2-D68C-48EE-A56E-46C61FC21538@sidn.nl> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.47.234] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3592308796_152919435" MIME-Version: 1.0 Archived-At: Subject: Re: [DNSOP] [Ext] Re: Resolver behaviour with multiple trust anchors X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Oct 2017 19:33:23 -0000 --B_3592308796_152919435 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable On 10/31/17, 14:30, "DNSOP on behalf of Paul Wouters" wrote: > On Oct 31, 2017, at 22:25, =C3=93lafur Gu=C3=B0mundsson w= rote: >> >> There are three ways to treat this case:=20 >> Any-TrustedKey-works =20 >> ConfiguredKey-trumps-DS=20 >> DS-trumps-configuredKey >> >> But I suspect the middle one is implemented=20 =20 >It better, it is the only working solution :) Can you elaborate...why would it be the "only" "working" solution? I understand that "Any-TrustedKey-Works" would be hard on implementers (I r= ecall a day when one of the original DNSSEC developers didn't like doing som= ething because it made the code ugly), but it's the one that maximizes robus= tness. ("What if:" The trust anchor manager was off-line during the time when an A= utomated Updates [STD 69] revocation was signaled?) Finding the closest trusted encloser ("trusted" meaning there's a trust anc= hor data, as opposed to a simple "closest encloser" determined by existence)= is simple, finding and handling the list of all trusted enclosure points wo= uld make the coding ugly. That's the only rationale I'd see for not follow = a philosophy of "Any-TrustedKey-Works." --B_3592308796_152919435 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIR5gYJKoZIhvcNAQcCoIIR1zCCEdMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC D68wggWeMIIEhqADAgECAhAE64fxtFjS2DdV8JfouoFSMA0GCSqGSIb3DQEBCwUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xNjA4MDkw MDAwMDBaFw0xOTA4MDkxMjAwMDBaMIG9MQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZv cm5pYTEUMBIGA1UEBxMLTG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEeMBwGA1UEAxMVRWR3YXJkIExl d2lzIDkgQXVnIDE2MSUwIwYJKoZIhvcNAQkBFhZlZHdhcmQubGV3aXNAaWNhbm4ub3JnMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxGXAQjOhBCDPz1+sGOERDMvSCFWbOUws GUrXAHLGeEAGYTCpni8f7kYPH7RMalvbep2aVtkMSUn6HR1uY84b437ZZuHCviUn7Aw6itGE wrDyq7Pb7zTlqE/1kLVhKYrHA4sjhsQRHhBHevxWbb3SYU2IMNxJd4QFgRJIp4zDmAR7bzbH 1ZazFGfo/op0QRsfcpFYmBotbj/4SnldtFwZasr7zTK9wJRSXa9sspLXtQhBe9itxTHJRg0H BH66VcPX7iRra9XFzkM5JLXOT2nBDIxeqDsLKoTkRWiNoSWoDZylAqS3BfBppwq7eremR7zD LIaPN4Tbb8TCpORMCZuvswIDAQABo4IB7zCCAeswHwYDVR0jBBgwFoAU5wIjgABP2Ne8lAvZ P3Q5STI8inkwHQYDVR0OBBYEFBiOkLRCGoHjShiTxeM3n94XHm+2MAwGA1UdEwEB/wQCMAAw IQYDVR0RBBowGIEWZWR3YXJkLmxld2lzQGljYW5uLm9yZzAOBgNVHQ8BAf8EBAMCBaAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYKYIZIAYb9bAQBAjAq MCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMIGIBgNVHR8EgYAw fjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJ RENBLWcyLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hB MkFzc3VyZWRJRENBLWcyLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6 Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhY2VydHMuZGlnaWNl cnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG9w0BAQsFAAOCAQEA zhEJp9X6tm36lKKaxCdyjyETxL3oVPDmv2JHBD/T/xbqRH0vQfR34VkRnSO+5d8AqHGdhYTK 7yjB/vW52KjiQUiW9WnQFYdY5Q/Yv3cnVgi4zuuye9BPvyr87HbmJ0uafYjATnYziT71njO7 xKIQP6w0MFv8ugT/fXIZsV4NU2eGQEHhvPkR+WOt0KfFa5jEY1qXoj4iZmE21j+f0OhSTA9K EofM5chR6FCaOyomKPIYU1mcoQwcistCwfcdVhUCpmgazxn6fR89ZOOiKTXxhOHrILdO0pCI dlJ3xO6EBvFKBCOyRBkD2z7jcWm/U3GkkYBLyRMvH1Ki+q4vwKnFZjCCBk4wggU2oAMCAQIC EASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcNAQELBQAwZTELMAkGA1UEBhMCVVMxFTATBgNV BAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMb RGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEzMTEwNTEyMDAwMFoXDTI4MTEwNTEy MDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQ d3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENB MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/AJ3kbLQWHohBDMd8O 1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr+Lp+yTU7VvEffEJ+ JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQelAfJUXo8Ymvzf9e /1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK3OnZ9ZEXjsYhrTg8 E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uCig1xGOSm4IksG/Oy czzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/BAgwBgEB/wIBADAO BgNVHQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2Nz cC5kaWdpY2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9jcmw0LmRpZ2ljZXJ0 LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRp Z2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYDVR0lBBYwFAYIKwYB BQUHAwIGCCsGAQUFBwMEMIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgBhv1sAAIEMIIBkjAo BggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCCAWQGCCsGAQUFBwIC MIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABpAHMAIABDAGUAcgB0AGkAZgBp AGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABhAGMAYwBlAHAAdABhAG4AYwBl ACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABDAFAALwBDAFAAUwAgAGEAbgBk ACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBu AHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBiAGkAbABpAHQAeQAgAGEAbgBk ACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAgAGgAZQByAGUAaQBuACAAYgB5 ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP2Ne8lAvZP3Q5STI8inkw HwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcNAQELBQADggEBAE7U iSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrgYhmZpgeafBMn2+UC ooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg4/mgVgxIEM4zaHvN k6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmwXZG0k4f5lpaBVUCO Zu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1YEhEybr1DDE0023vG QtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIwggO3MIICn6ADAgECAhAM 5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQK EwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0Rp Z2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAwMDAwMDBaFw0zMTExMTAwMDAw MDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3 dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7kQ4BcsYfzt2D5cRKlrtwmlIiq 9M71IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrneVNcMYQq9g+YMjZ2zN7dPKii 72r7IfJSYd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9SwOD7BG8OMM9nYLxj+KA+zp4PW w25EwGE1lhb+WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyChz+VtCshJfDGYM2wi6YfQMlqi uhOCEe05F52ZOnKh5vqk2dUXMXWuhX0irj8BRob2KHnIsdrkVxfEfhwOsLSSplazvbKX7aqn 8LfFqD+VFtD/oZbrCF8Yd08CAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgGGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFEXroq/0ksuCMS1Ri6enIZ3zbcgPMB8GA1UdIwQYMBaAFEXroq/0 ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBBQUAA4IBAQCiDrzf4u3w43JzemSUv/dyZtgy 5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwSTFjk0z2DSUVYlzVpGqhH6lbGeasS2GeBhN9/CTyU 5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJs13rsgkq6ybteL59PyvztyY1bV+JAbZJW58B BZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLxvlBnt2y98/Efaww2BxZ/N3ypW2168RJG YIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76jRslbWyPpbdhAbHSoyahEHGdreLD +cOZUbcrBwjOLuZQsqf6CkUvovDyMYIB/zCCAfsCAQEweTBlMQswCQYDVQQGEwJVUzEVMBMG A1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQD ExtEaWdpQ2VydCBTSEEyIEFzc3VyZWQgSUQgQ0ECEATrh/G0WNLYN1Xwl+i6gVIwCQYFKw4D AhoFAKBdMCMGCSqGSIb3DQEJBDEWBBSAxmBu+NNqF48e5FPtfQf8OOiSAzAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzEwMzExOTMzMTZaMA0GCSqGSIb3 DQEBAQUABIIBAF9fru+dbGSR0cikk++7ZKGp52mChacPCESU7qngErzEQa21leAaOLRiYz1b r9MhrFsuoZls84u5eTZZoC6Pcj0cEfM5o2E/XkZZ5gVz4UlzV7p75gRNbT4t/vhOsGw8sh4A Y4CuO1eB5SRnn5r8W6NwwF9AQLTFqgIDTHxj9pYkRPgac17z71Ft9XdoOzDStm6gS3IABq+n x46xkgHoUTZxGR2oYtTf6dM6FnkeoNUgqvTLOlXb3tpj2R2dyCDkqgETkvl2lWN4mPwDqLqp gp83voENIH8OkFMVI4OqiWkY9y12D22cRHYxSjROPnK3y2x0MeKM1xOdP+1+emuGoVk= --B_3592308796_152919435-- From nobody Tue Oct 31 12:52:29 2017 Return-Path: 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 3A2CE13F61B for ; Tue, 31 Oct 2017 12:52:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 gLdSAoMJAbeJ for ; Tue, 31 Oct 2017 12:52:26 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (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 5ED3013F614 for ; Tue, 31 Oct 2017 12:52:26 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3yRMSk3LGYzFBF; Tue, 31 Oct 2017 20:52:22 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1509479542; bh=wY4UAxjlnw4Yz602R5adkbdSG5mC7vfLneJqIOKmX2A=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=dU9G0FO174T+UcnS+8PafPiTILtLEtIjZGL/ToA5TDD3FHecvPvFFSsw0T9G/WF2z g3Oz5oeGm+ap/+zEP3fpM3MnojS6vg87eno3oTMprJWwrduX4MJPP1HPgiAVY6A93v m4ZmD+waoEhDImQ7Hih56BMtBzSKdt+Wt+U1lmUw= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id 4wm8iO_Fd2LN; Tue, 31 Oct 2017 20:52:20 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 31 Oct 2017 20:52:20 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 8A79762D29; Tue, 31 Oct 2017 15:52:19 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 8A79762D29 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 78E2440D35AF; Tue, 31 Oct 2017 15:52:19 -0400 (EDT) Date: Tue, 31 Oct 2017 15:52:19 -0400 (EDT) From: Paul Wouters To: Edward Lewis cc: =?ISO-8859-15?Q?=D3lafur_Gu=F0mundsson?= , Moritz Muller , "dnsop@ietf.org" In-Reply-To: <4678D8A8-1AA0-4684-BFD1-40C969305C49@icann.org> Message-ID: References: <121CDBC2-D68C-48EE-A56E-46C61FC21538@sidn.nl> <4678D8A8-1AA0-4684-BFD1-40C969305C49@icann.org> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [DNSOP] [Ext] Re: Resolver behaviour with multiple trust anchors X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Oct 2017 19:52:28 -0000 On Tue, 31 Oct 2017, Edward Lewis wrote: >>> Any-TrustedKey-works >>> ConfiguredKey-trumps-DS >>> DS-trumps-configuredKey >>> >>> But I suspect the middle one is implemented > >> It better, it is the only working solution :) > > Can you elaborate...why would it be the "only" "working" solution? The idea of the hierarchical model has always been that if you don't trust the parent, you can configure keys at the level you want. If I don't trust the root, I can put in a trust anchor for .ca. If I don't trust .ca, I can put in a trust anchor for nohats.ca. Allowing "any" key to override that would make me vulnerable to all my parents, even if I don't want to trust them. I don't want .ca to be able to put in a DS for internal.nohats.ca in their TLD and steal my traffic. Now, when I run that zone internally and sign it internally, and put in the trust anchor, this zone can never be stolen from me by a parent. This has always given the parent keys an enigma problem. Get abused once and we will bypass you. Trusting "any" key will no longer allow me to untrust a particular zone cut. Paul From nobody Tue Oct 31 13:00:43 2017 Return-Path: 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 347CF13F659 for ; Tue, 31 Oct 2017 13:00:41 -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_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 z1kQKA1cYsD0 for ; Tue, 31 Oct 2017 13:00:40 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 101A813F648 for ; Tue, 31 Oct 2017 13:00:40 -0700 (PDT) Received: from [IPv6:2001:559:8000:c9:4987:fe28:d911:202c] (unknown [IPv6:2001:559:8000:c9:4987:fe28:d911:202c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id C67AB61FA2; Tue, 31 Oct 2017 20:00:39 +0000 (UTC) Message-ID: <59F8D666.9000808@redbarn.org> Date: Tue, 31 Oct 2017 13:00:38 -0700 From: Paul Vixie User-Agent: Postbox 5.0.20 (Windows/20171012) MIME-Version: 1.0 To: Paul Wouters CC: Edward Lewis , Moritz Muller , =?ISO-8859-1?Q?=D3lafur_Gu=F0mundsson?= , "dnsop@ietf.org" References: <121CDBC2-D68C-48EE-A56E-46C61FC21538@sidn.nl> <4678D8A8-1AA0-4684-BFD1-40C969305C49@icann.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] [Ext] Re: Resolver behaviour with multiple trust anchors X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Oct 2017 20:00:41 -0000 Paul Wouters wrote: > On Tue, 31 Oct 2017, Edward Lewis wrote: > ... >>>> ConfiguredKey-trumps-DS ... >> >>> It better, it is the only working solution :) >> >> Can you elaborate...why would it be the "only" "working" solution? > > The idea of the hierarchical model has always been that if you don't > trust the parent, you can configure keys at the level you want. If > I don't trust the root, I can put in a trust anchor for .ca. If I > don't trust .ca, I can put in a trust anchor for nohats.ca. +1. and this is how DLV worked, for that reason. > Allowing "any" key to override that would make me vulnerable to all > my parents, even if I don't want to trust them. I don't want .ca to > be able to put in a DS for internal.nohats.ca in their TLD and steal > my traffic. Now, when I run that zone internally and sign it internally, > and put in the trust anchor, this zone can never be stolen from me by > a parent. > > This has always given the parent keys an enigma problem. Get abused once > and we will bypass you. Trusting "any" key will no longer allow me to > untrust a particular zone cut. +1. all policy is local. -- P Vixie From nobody Tue Oct 31 13:51:47 2017 Return-Path: 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 5A57B139A2F for ; Tue, 31 Oct 2017 13:51:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 Z86CC7NRGJl5 for ; Tue, 31 Oct 2017 13:51:45 -0700 (PDT) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 55C8913F574 for ; Tue, 31 Oct 2017 13:51:45 -0700 (PDT) Received: from [169.254.101.35] (50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id v9VKoK4u060765 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 31 Oct 2017 13:50:21 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141] claimed to be [169.254.101.35] From: "Paul Hoffman" To: dnsop@ietf.org Date: Tue, 31 Oct 2017 13:51:42 -0700 Message-ID: <148C88F0-FEED-4759-8026-F3FB95B44252@vpnc.org> In-Reply-To: References: <121CDBC2-D68C-48EE-A56E-46C61FC21538@sidn.nl> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.7r5425) Archived-At: Subject: Re: [DNSOP] Resolver behaviour with multiple trust anchors X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Oct 2017 20:51:46 -0000 On 31 Oct 2017, at 12:23, Michael StJohns wrote: > But sadly - the language in RFC6840 section 5.10 is controlling... > basically, any implementation can do whatever it wants. > >> A DNSSEC validator may be configured such that, for a given response, >> more than one trust anchor could be used to validate the chain of >> trust to the response zone. For example, imagine a validator >> configured with trust anchors for "example." and "zone.example." >> When the validator is asked to validate a response to >> "www.sub.zone.example.", either trust anchor could apply. > >> When presented with this situation, DNSSEC validators have a choice >> of which trust anchor(s) to use. Which to use is a matter of >> implementation choice. Appendix C discusses several possible >> algorithms. And the two paragraphs that follow those give more guidance: It is possible and advisable to expose the choice of policy as a configuration option. As a default, it is suggested that validators implement the "Accept Any Success" policy described in Appendix C.2 while exposing other policies as configuration options. The "Accept Any Success" policy is to try all applicable trust anchors until one gives a validation result of Secure, in which case the final validation result is Secure. If and only if all applicable trust anchors give a result of Insecure, the final validation result is Insecure. If one or more trust anchors lead to a Bogus result and there is no Secure result, then the final validation result is Bogus. > And once again we see the folly of the words "implementation choice" > when trying to come up with a coherent DNS. The full quote makes the situation murkier: it is a combination of implementation choice plus configuration options. Some folks on this list strongly prefer that, others strongly don't. --Paul Hoffman From nobody Tue Oct 31 14:01:57 2017 Return-Path: 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 0562413F551 for ; Tue, 31 Oct 2017 14:01:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umich.edu 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 Y0Am2RcQ6zoa for ; Tue, 31 Oct 2017 14:01:52 -0700 (PDT) Received: from mail-pg0-x22b.google.com (mail-pg0-x22b.google.com [IPv6:2607:f8b0:400e:c05::22b]) (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 7FF7A13875A for ; Tue, 31 Oct 2017 14:01:52 -0700 (PDT) Received: by mail-pg0-x22b.google.com with SMTP id m18so239502pgd.13 for ; Tue, 31 Oct 2017 14:01:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umich.edu; s=google-2016-06-03; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=m2NOofcTeZ1g60KhvjFGgAP+lW+6jHSZdAvgFCT3Fdc=; b=b98KUJHkQx4fyLXkYzFif5KRy0lul66Jod/u1K1bF19xOuX5Hg3Zz5OtlFpusH7NQ/ 2CNq6dyhc+fvwA0tM5qruu9bUHW62dnSEN7Ikc4EBNS2QGaQ+GfFhg0ae/DnIEcZwnUT TAiYwMIPMTlgTM6BKjpa7egLwD1dVmgTzNQxhnDlyNj9ghV3F9PflVSQumCYhVfs9At9 RXaxON9TPOThIYziOpiZL0nJS0/vytbXjFZUtftbyuUTdtJsq8PpnQfLS5suUHdl9aTj 90u7r6svX0VQejR9BrzbanUwGZSt7bwlowObEEexkwRSlVUzcUgKOEuZPUjMOczUtdbt NeqA== 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; bh=m2NOofcTeZ1g60KhvjFGgAP+lW+6jHSZdAvgFCT3Fdc=; b=sB6xUvtcbN3d+ArGb6fw5h6qFj3DQ1UQVOTEjea2J4Cbeh1uLWdGy7AEx6ChcWbVe1 5/bG/W2ZQE2rqOdybAjOhDTBMsnU1Qbvz8RPR3PSapG1wtr0nnSQVeu1ffShhJPhGSSW 2TrORFMnTCWlmJ3jJ0LeHX/5M0NmZC+qAN6cOGFR0s6OtmIefdWunob/16ruxlmbaf1g kKmcMq5HSDnMhs4jjxxuaQtQHHxyNGQTCUAep/HAvLJAPT7A+qiqsRRbsANzhehkLxMq S7I92tnNKXNzaGK52zlxBXuSi4PvkAU9ZqYftj3KF1zIJ5EAUGfWI2FpSztoyh4dI86Y Z8FQ== X-Gm-Message-State: AMCzsaXNd9OtRrIUUaA7E5bYG6GmlD3HF83hMwQRQLrG4JYcwlL1BqJ/ TGo1wE2k6gWMrvx4f3e8YFiYtcmHmrHTINf8HWiRNg== X-Google-Smtp-Source: ABhQp+TZxg0ZZS7/hCi2QtsBFCNFjC3wL8JTdI+Q/0EP+5+CHp/WIDVAvK22eHJcDraA5jSr8r27AzJYGNuXJHwn2hA= X-Received: by 10.98.18.18 with SMTP id a18mr3355237pfj.301.1509483711059; Tue, 31 Oct 2017 14:01:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.130.4 with HTTP; Tue, 31 Oct 2017 14:01:50 -0700 (PDT) In-Reply-To: <150940619490.28403.7485909732104218964@ietfa.amsl.com> References: <150940619490.28403.7485909732104218964@ietfa.amsl.com> From: Bob Harold Date: Tue, 31 Oct 2017 17:01:50 -0400 Message-ID: To: internet-drafts@ietf.org Cc: i-d-announce@ietf.org, IETF DNSOP WG Content-Type: multipart/alternative; boundary="001a114596aa646bf2055cde100d" Archived-At: Subject: Re: [DNSOP] I-D Action: draft-woodworth-bulk-rr-07.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Oct 2017 21:01:56 -0000 --001a114596aa646bf2055cde100d Content-Type: text/plain; charset="UTF-8" On Mon, Oct 30, 2017 at 7:29 PM, 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 : BULK DNS Resource Records > Authors : John Woodworth > Dean Ballew > Shashwath Bindinganaveli Raghavan > David C Lawrence > Filename : draft-woodworth-bulk-rr-07.txt > Pages : 16 > Date : 2017-10-30 > > Abstract: > The BULK DNS resource record type defines a method of pattern-based > creation of DNS resource records based on numeric substrings of query > names. The intent of BULK is to simplify generic assignments in a > memory-efficient way that can be easily shared between the primary > and secondary nameservers for a zone. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-woodworth-bulk-rr/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-woodworth-bulk-rr-07 > https://datatracker.ietf.org/doc/html/draft-woodworth-bulk-rr-07 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-woodworth-bulk-rr-07 > > I don't understand this section: 5.1.1. On-the-fly Signatures ... One possibly mitigation for addressing the risk of keeping the zone signing key online would be to continue to keep the key for signing positive answers offline and introduce a second key for online signing of negative answers. Since every positive answer would be different, they would need a different signature, which would need to be generated online. Or do I not understand something? (Is this part of the NPN solution that was deleted?) -- Bob Harold --001a114596aa646bf2055cde100d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

= On Mon, Oct 30, 2017 at 7:29 PM, <internet-drafts@ietf.org>= wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Domain Name System Operations WG of the IE= TF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= BULK DNS Resource Records
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: John= Woodworth
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Dean Ballew
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Shashwath Bindinganaveli Raghavan
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 David C Lawrence
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-woo= dworth-bulk-rr-07.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 16
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2017-10-30

Abstract:
=C2=A0 =C2=A0The BULK DNS resource record type defines a method of pattern-= based
=C2=A0 =C2=A0creation of DNS resource records based on numeric substrings o= f query
=C2=A0 =C2=A0names.=C2=A0 The intent of BULK is to simplify generic assignm= ents in a
=C2=A0 =C2=A0memory-efficient way that can be easily shared between the pri= mary
=C2=A0 =C2=A0and secondary nameservers for a zone.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/dra= ft-woodworth-bulk-rr/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-woodwor= th-bulk-rr-07
https://datatracker.ietf.org/do= c/html/draft-woodworth-bulk-rr-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2= =3Ddraft-woodworth-bulk-rr-07


I don't understand this section:
5.1.1. On-the-fl= y Signatures
=C2=A0...
=C2=A0 =C2=A0One possibly mitigation for addressing the risk of keeping = the zone
= =C2=A0 =C2=A0signing key online would be to continue to keep the key for si= gning
=C2= =A0 =C2=A0positive answers offline and introduce a second key for online
=C2=A0 =C2= =A0signing of negative answers.

Since every positive= answer would be different, they would need a different signature, which wo= uld need to be generated online.=C2=A0=C2=A0
Or do I not understa= nd something?=C2=A0 (Is this part of the NPN solution that was deleted?)

--=C2=A0
Bob Harold

--001a114596aa646bf2055cde100d-- From nobody Tue Oct 31 14:04:14 2017 Return-Path: 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 6FF3013F70B for ; Tue, 31 Oct 2017 14:04:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.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 Kovzuo2gYflD for ; Tue, 31 Oct 2017 14:04:00 -0700 (PDT) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (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 3B1E013F6F0 for ; Tue, 31 Oct 2017 14:03:59 -0700 (PDT) Received: by mail-qt0-x235.google.com with SMTP id p1so453553qtg.2 for ; Tue, 31 Oct 2017 14:03:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=GcdfD0+bHRAm2eJnHr665H+PUN92XmEnW6RK81osEgM=; b=pZqO95KEfxUwMNF+w81QxMMKPtcCQATJ31JwWOj/E0qiBhkQqHScoVyTM2LNhEe/yp 6Yi8nLFe7ftJSX3uDPFjGN/+b1zwnEUzS57bAtP884te/YCz3SJCtaCmkRaaPTBGrqkR dpHRNuVIQLbnkV1WxGTnkvqPOQxoQqLGNDlgtfVJ43nPgB1kXE/X8CgkW6PYvP37FcLu W+Mt+b7px2bsmRcFmQUor+yhLZiAA/MID3c4mFJB+tZkUag1iIzVL3iNwcCaRPTHeDuY 0pSKRvwwz8mCE0ogzjiCeMFKH/s+VPjrEg/exaKm7iVUfsvrUkvV3HKw08B+YahOaYl1 vzig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=GcdfD0+bHRAm2eJnHr665H+PUN92XmEnW6RK81osEgM=; b=dIdXDhaZ1W3HAZjbPvNUZkyiA8L7t9mIu26OmqCGWMH47wsDXpPW+3oVoBHb9ZctlQ XBmJOI6QdWBzzpWr9TlpLcUPftCcEmPCwFRg1yIrcUpf4vLEQtWB6UAtnwXC1RuhaSEG 0k3M7xghr2LOyUeVWGhWh8t23wAhFNxVERQ1wu+NgTFVSdGQhiOzFYAQUHcYqshun2ZX T1lrc6ieBvsGOwn7t6Wo7nzTFakLvrd59TZX3uyStxSdxPyWyQphXpKtb9x5V+y/VJZI lWRzDfxfp5RP9tQHI4lcsHdd2Vvf9sChXXBznkzZ3Hq1/OSYZzwDN/6nBSj9Nr95JDdO Cl0g== X-Gm-Message-State: AMCzsaVmnEndvLNs56vjfTvOruIfgeN3jDgYJgXcNuo0gBcMWTLNnxns l61kbawKwAwtvPtj/M8mKUfNIB4J X-Google-Smtp-Source: ABhQp+QjZfGyR661xKOnjhhdGermvC9MYSefeC1RHcgbX+q7zTVgxl6B5+AZRWKn1lA33Y3/Slgs7Q== X-Received: by 10.200.55.253 with SMTP id e58mr5106221qtc.234.1509483837968; Tue, 31 Oct 2017 14:03:57 -0700 (PDT) Received: from ?IPv6:2601:152:4400:720f::146e? ([2601:152:4400:720f::146e]) by smtp.gmail.com with ESMTPSA id l1sm1559360qtf.5.2017.10.31.14.03.56 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 31 Oct 2017 14:03:57 -0700 (PDT) To: dnsop@ietf.org References: <121CDBC2-D68C-48EE-A56E-46C61FC21538@sidn.nl> <148C88F0-FEED-4759-8026-F3FB95B44252@vpnc.org> From: Michael StJohns Message-ID: Date: Tue, 31 Oct 2017 17:03:54 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <148C88F0-FEED-4759-8026-F3FB95B44252@vpnc.org> Content-Type: multipart/alternative; boundary="------------638A584F5362DFF6DC96BEFB" Content-Language: en-US Archived-At: Subject: Re: [DNSOP] Resolver behaviour with multiple trust anchors X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Oct 2017 21:04:12 -0000 This is a multi-part message in MIME format. --------------638A584F5362DFF6DC96BEFB Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 10/31/2017 4:51 PM, Paul Hoffman wrote: >> And once again we see the folly of the words "implementation choice" >> when trying to come up with a coherent DNS. > > The full quote makes the situation murkier: it is a combination of > implementation choice plus configuration options. Some folks on this > list strongly prefer that, others strongly don't. My main and only desire when querying the DNS is that given the same inputs to the system you should always get the same output. Getting different answers on something that's as important as security because you queried different implementations  continues to seem to be to be a bad idea. Having a standard default (which was not what this was) and having configuration options to change it for good reason is different than "which to use is a matter of implementation choice". Later, Mike --------------638A584F5362DFF6DC96BEFB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 10/31/2017 4:51 PM, Paul Hoffman wrote:
And once again we see the folly of the words "implementation choice" when trying to come up with a coherent DNS.

The full quote makes the situation murkier: it is a combination of implementation choice plus configuration options. Some folks on this list strongly prefer that, others strongly don't.


My main and only desire when querying the DNS is that given the same inputs to the system you should always get the same output.  Getting different answers on something that's as important as security because you queried different implementations  continues to seem to be to be a bad idea.

Having a standard default (which was not what this was) and having configuration options to change it for good reason is different than "which to use is a matter of implementation choice".   

Later, Mike




--------------638A584F5362DFF6DC96BEFB-- From nobody Tue Oct 31 17:50:22 2017 Return-Path: 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 9175113F42E for ; Tue, 31 Oct 2017 17:50:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PP_MIME_FAKE_ASCII_TEXT=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 7Io6ZyZxM3vD for ; Tue, 31 Oct 2017 17:50:19 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (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 CC67D13F42D for ; Tue, 31 Oct 2017 17:50:19 -0700 (PDT) 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)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 995603BC050; Wed, 1 Nov 2017 00:50:17 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 6B0CD160087; Wed, 1 Nov 2017 00:50:17 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 4C9BF160086; Wed, 1 Nov 2017 00:50:17 +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 J1lH2fMeWElv; Wed, 1 Nov 2017 00:50:17 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 02343160064; Wed, 1 Nov 2017 00:50:17 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 0A2E38DCF888; Wed, 1 Nov 2017 11:50:14 +1100 (AEDT) To: Moritz Muller Cc: "dnsop@ietf.org" From: Mark Andrews References: <121CDBC2-D68C-48EE-A56E-46C61FC21538@sidn.nl> In-reply-to: Your message of "Tue, 31 Oct 2017 09:39:23 -0000." <121CDBC2-D68C-48EE-A56E-46C61FC21538@sidn.nl> Date: Wed, 01 Nov 2017 11:50:13 +1100 Message-Id: <20171101005014.0A2E38DCF888@rock.dv.isc.org> Archived-At: Subject: Re: [DNSOP] Resolver behaviour with multiple trust anchors X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Nov 2017 00:50:21 -0000 In message <121CDBC2-D68C-48EE-A56E-46C61FC21538@sidn.nl>, Moritz Muller writes : > > Hi, > > Together with my colleagues I have been stumbling upon a, for me, unclear > case when validating trust anchors. > > Assuming that a resolver has enabled DNSSEC validation and has the root > keys configured. > Additionally, it has configured manually a trust anchor for a TLD (that > has also published its DS in the root zone). > Now, for example due to a key rollover at the TLD, the manually > configured trust anchor of the TLD does not match the DS in the root > anymore. > > How should a resolver treat the signatures of this TLD? > The resolvers of BIND, Unbound, and PowerDNS seem to treat the signatures > of the TLD as bogus, but we didn't find any specifics in RFC 4034 and > 4035 that describe how resolvers should behave in this case. > Knot resolver treats them as NOERROR (according to the developers). > If we interpret section 4.3 of RFC 4035 then we would have assumed that > the signature must be treated as secure. > > Did we miss something, or is there indeed clarification needed? > > — Moritz Firstly the TLD has mismanged the key rollover if this is the case assuming that it was expecting TA to be installed for it. It not the operator of the validator is in error. Secondly doing deepest match on trust anchors is the only secure way to prevent a parent overriding the child zone's security policy. Thirdly if you are doing split DNS and you want to enforce that you only get answers from a particular view you can use DNSSEC to reject leaked answers. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Tue Oct 31 18:32:05 2017 Return-Path: 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 81DD813F5B9 for ; Tue, 31 Oct 2017 18:32:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 NpzCpkByeLRx for ; Tue, 31 Oct 2017 18:32:03 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (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 04DD213F586 for ; Tue, 31 Oct 2017 18:32:03 -0700 (PDT) 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)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id CA8A63AF0D0; Wed, 1 Nov 2017 01:32:00 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 8E1FC16006D; Wed, 1 Nov 2017 01:31:53 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 7A9F9160064; Wed, 1 Nov 2017 01:31:53 +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 y8puofUleXu7; Wed, 1 Nov 2017 01:31:53 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 26CC0160048; Wed, 1 Nov 2017 01:31:53 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id D9F968DD6042; Wed, 1 Nov 2017 12:31:50 +1100 (AEDT) To: Paul Vixie Cc: Paul Wouters , Edward Lewis , Moritz Muller , =?ISO-8859-1?Q?=D3lafur_Gu=F0mundsson?= , "dnsop@ietf.org" From: Mark Andrews References: <121CDBC2-D68C-48EE-A56E-46C61FC21538@sidn.nl> <4678D8A8-1AA0-4684-BFD1-40C969305C49@icann.org> <59F8D666.9000808@redbarn.org> In-reply-to: Your message of "Tue, 31 Oct 2017 13:00:38 -0700." <59F8D666.9000808@redbarn.org> Date: Wed, 01 Nov 2017 12:31:50 +1100 Message-Id: <20171101013150.D9F968DD6042@rock.dv.isc.org> Archived-At: Subject: Re: [DNSOP] [Ext] Re: Resolver behaviour with multiple trust anchors X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Nov 2017 01:32:04 -0000 In message <59F8D666.9000808@redbarn.org>, Paul Vixie writes: > > > Paul Wouters wrote: > > On Tue, 31 Oct 2017, Edward Lewis wrote: > > > ... > >>>> ConfiguredKey-trumps-DS > ... > >> > >>> It better, it is the only working solution :) > >> > >> Can you elaborate...why would it be the "only" "working" solution? > > > > The idea of the hierarchical model has always been that if you don't > > trust the parent, you can configure keys at the level you want. If > > I don't trust the root, I can put in a trust anchor for .ca. If I > > don't trust .ca, I can put in a trust anchor for nohats.ca. > > +1. and this is how DLV worked, for that reason. DLV is deepest match. It also was was only consulted if the answer validated as insecure with configured trust anchors. No trust-anchor above a name means it validated as insecure. The same data could be used to configure trust anchors which are used instead of DS records. Named currently doesn't support this. > > Allowing "any" key to override that would make me vulnerable to all > > my parents, even if I don't want to trust them. I don't want .ca to > > be able to put in a DS for internal.nohats.ca in their TLD and steal > > my traffic. Now, when I run that zone internally and sign it internally, > > and put in the trust anchor, this zone can never be stolen from me by > > a parent. > > > > This has always given the parent keys an enigma problem. Get abused once > > and we will bypass you. Trusting "any" key will no longer allow me to > > untrust a particular zone cut. > > +1. all policy is local. > > -- > P Vixie > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org