From nobody Sat Apr 2 06:49:37 2022 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 7E4B03A1232 for ; Sat, 2 Apr 2022 06:49:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=a4a.de 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 Ukd66GXeDyOx for ; Sat, 2 Apr 2022 06:49:18 -0700 (PDT) Received: from mail.a4a.de (mail.a4a.de [IPv6:2a01:4f8:10a:1d5c:8000::8]) (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 B51C43A1181 for ; Sat, 2 Apr 2022 06:49:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=a4a.de; s=20170825; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From: References:To:Subject:MIME-Version:Date:Message-ID:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=i/Yv29JKX01sf3VhZh/hjTn+QH1DE441L6XUEnNQYGw=; b=bntfahReg2Litpz1Fq+liXXSN9 RNUoN9M3ohcHYsarhIiUGtAWoluz0k4+YlxCeU8ELSQtP78ZZhNwz+DO6E7roR4Bg4uAbwjJDL38R cjeOKNYA/sBPYNrNwfn7I3hsLsI+947/H3c5DE6VZu2ytOkQ3CPE0WQP83q5B6/nh5Vt9CM+FSvj1 Jk9G8Rbs5WkZ/BRbrGRQnq/KVv1t9diupB6JFAh+dBVN/TkguDkfLjYs6dCVjIJJnHYOlMzvL2s++ FORiKpQzrA3lDgeeh2VF5wDqz5Sg7x7JMeN18OQ11sCN9VhMVxFt+QUrJDrEts/7MmrPvEj5/rpay dsXqHgEw==; Received: from [91.65.95.29] (helo=[192.168.178.70]) by mail.a4a.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nae7s-0003no-ND for dnsop@ietf.org; Sat, 02 Apr 2022 15:49:12 +0200 Message-ID: Date: Sat, 2 Apr 2022 15:49:12 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Content-Language: en-US To: dnsop@ietf.org References: <93c34015-f441-20a3-b2b0-54159a70d021@NLnetLabs.nl> From: Peter Thomassen In-Reply-To: <93c34015-f441-20a3-b2b0-54159a70d021@NLnetLabs.nl> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-wisser-dnssec-automation X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2022 13:49:33 -0000 I reviewed the draft and think it is suitable for adoption. I'm willing to contribute text and reviews. ~Peter On 3/25/22 16:35, Benno Overeinder wrote: > As with the previous Call for Adoption today, at this week's DNSOP meeting at IETF 113, we announced that we are initiating a Call for Adoption for the draft-wisser-dnssec-automation.  With the survey we conducted for the last IETF 112, this draft was also a clear candidate. > > With this email we start a period of two weeks for the call for adoption of draft-wisser-dnssec-automation on the mailing list. > > The draft is available here: https://datatracker.ietf.org/doc/draft-wisser-dnssec-automation/. > > Please review this draft to see if you think it is suitable for adoption by DNSOP, and comments to the list, clearly stating your view. > > Please also indicate if you are willing to contribute text, review, etc. > > This call for adoption ends: 8 April 2022 > > Thanks, > > Suzanne, Tim and Benno > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Like our community service? 💛 Please consider donating at https://desec.io/ deSEC e.V. Kyffhäuserstr. 5 10781 Berlin Germany Vorstandsvorsitz: Nils Wisiol Registergericht: AG Berlin (Charlottenburg) VR 37525 From nobody Mon Apr 4 01:38:46 2022 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 A89503A1AEA for ; Mon, 4 Apr 2022 01:38:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.11 X-Spam-Level: X-Spam-Status: No, score=-2.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nlnetlabs.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 z7OJ9NrDt62i for ; Mon, 4 Apr 2022 01:38:29 -0700 (PDT) Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com [IPv6:2a00:1450:4864:20::632]) (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 8DCB13A1AF2 for ; Mon, 4 Apr 2022 01:38:28 -0700 (PDT) Received: by mail-ej1-x632.google.com with SMTP id bh17so18294890ejb.8 for ; Mon, 04 Apr 2022 01:38:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nlnetlabs.nl; s=google; h=message-id:date:mime-version:user-agent:subject:content-language:to :references:from:in-reply-to:content-transfer-encoding; bh=9vUyaWmDi1ZW/OrOfXzCvvA3t7D6iDBVH8Hk4/mpe6Q=; b=byIeErPi5tI8iLG5VGTNQfv3mC62105kUJSXDRGwyZ81qgiGj3G6pus1q5avqyrJ9h L8/kJqMwuoPxuXCdsDRNEdHUheR7houk3MKtn2uaXS+gHbVWsUqdouLpwi1pVqsB2GXY ghePIqpB2DtmRlGLqt6r7JJoInSHkYPS/BNnYdAlFEQrNqPQDD1uSn9weFWMBUhEi6UK YQhE6qQMN20r4bWOCYTVI7mBxgpiDOHNX90M28XXC5jpZIpfZSDe3mlHxeAYBDUT9ZYF +bXutBIZTKXuUP4xu1Dy7yvOh9vVA8HFYKeoMvm+MM7VWtXHR//3CSnHI7ORQ3fW67nA JHYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=9vUyaWmDi1ZW/OrOfXzCvvA3t7D6iDBVH8Hk4/mpe6Q=; b=JTUgb2UBzP0EqPPras5J653C8FJwwhWUrpewuiDis6zhvdfIBCo1E+OVGaprsjBj5Y ced9J9yufxx/o8GX7fMs9SGWr+W5UuIcSzLR4tpx7itS0RXm4vwEUyeDbl2pC/K6NDeX MkCgMiMyI2xWWQMe0XRB0vOFekpd6uNDINRufmVrO+CuQQQe/wKGRt9xx5J51qjVR7vJ U8BZCIYjUSTajlW1xtrqPtMU8XaSzGU/jrNx4Lg6spErO39wVOIglLzWGYi43M3JnPUI U7gFc9263aF832JVX4cL+iureFjUq0EiJYav/62s2GCcqEVVTAyqhcQkG0n5Kj3iOjUk aUSg== X-Gm-Message-State: AOAM5336SFwQOXS3zudbJqZRfz2AshdutrOu1EFYPST7l+PwnRycdFYE BqHyRQLhqQdAqpXly85rLcUeUA== X-Google-Smtp-Source: ABdhPJyb/YBCnK/xNdV/6Q3m5s6eZjx6Q0+3ebdW2wPJ9CpU/Ve4N5B2sHMVcFk4z9wOcGz5XNa9hQ== X-Received: by 2002:a17:907:6d8b:b0:6e7:5610:d355 with SMTP id sb11-20020a1709076d8b00b006e75610d355mr5973806ejc.369.1649061507052; Mon, 04 Apr 2022 01:38:27 -0700 (PDT) Received: from ?IPV6:2a04:b900::760? ([2a04:b900::760]) by smtp.gmail.com with ESMTPSA id w14-20020a509d8e000000b0041cd217726dsm1254020ede.4.2022.04.04.01.38.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 04 Apr 2022 01:38:26 -0700 (PDT) Message-ID: <98980fb8-21e8-6582-8829-b32f104062f2@nlnetlabs.nl> Date: Mon, 4 Apr 2022 10:38:24 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Content-Language: en-US To: "libor.peltan" , dnsop References: From: Willem Toorop In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] draft-yorgos-dnsop-dry-run-dnssec-00 and DS digest field X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2022 08:38:40 -0000 Thanks Libor, I'm planning to create an overview of all the feedback and proposed solutions to our issues we've had since IETF113 (including your proposal), discuss that with the co-authors, and then post that to dnsop together with an announcement that we're working on this. Cheers, -- Willem Op 30-03-2022 om 16:58 schreef libor.peltan: > Hi dnsop, Yorgos, Willem, Roy, > I really like this idea of dry-run DNSSEC. I think it could really help > new DNSSEC adopters. > > The evidently weird thing of the proposal is the displacement of DS > digest field into the first byte of DS hash field, in order to free up > space for dry-run signalling. This will cause difficulties in human > readability of resulting DS. The obvious counter-proposal would be to > simply take the most-significant bit of the DS digest field (set to 1 > for dry-run), which would take 128 of available DS digest numbers > (instead of just one), but wouldn't otherwise introduce any > inconsistencies in DS format. As only four are taken so far, it seems > viable to me. > > Should we (dnsop) discuss this specific matter, or even poll? > > Thanks, > Libor > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop From nobody Tue Apr 5 04:07:08 2022 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 C279E3A204B for ; Tue, 5 Apr 2022 04:06:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FILL_THIS_FORM=0.001, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_FRAUD_PHISH=0.01, T_SCC_BODY_TEXT_LINE=-0.01, 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 65g8oKr63jNi for ; Tue, 5 Apr 2022 04:06:46 -0700 (PDT) Received: from mail-yb1-xb29.google.com (mail-yb1-xb29.google.com [IPv6:2607:f8b0:4864:20::b29]) (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 A03573A20FF for ; Tue, 5 Apr 2022 04:06:46 -0700 (PDT) Received: by mail-yb1-xb29.google.com with SMTP id g9so13039598ybj.9 for ; Tue, 05 Apr 2022 04:06:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=xE2sEiIJ9NKhGExNZoSEMhHzgf68ugmUZcXmeGF8Zxg=; b=Uapo9ep8xKyFiz72Kd/Cwi7J9aU8MsXJoD8682s3IF6VwfTtvVD4bL48czVVscyQup 4iNB3csmoDOLL1rF0bpI5TzRVYslUJ2YVtGv065w1p08PJk7LlPRKkz1uCk8nXLA9Usa CtX8o2DRAyqAULY/GdB2RUl39ME9kH/0kmrCXWkds0qR5SEBdyTRW8Xw9lON6tIq9t+f wyH1zmA6AsNrRjjwFHP89CJ9awjo6am8OnYu4pJVEqvGSUSkNN9ByWgsR9z9mFJMwa7k h9jH9343ntgNNc8ipxmJ0mkZhZHu6xBPOr1rLqFCzSw5+kOlvfF638fW4U83Q7BcrhIc LXcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=xE2sEiIJ9NKhGExNZoSEMhHzgf68ugmUZcXmeGF8Zxg=; b=2XiKdsXNyuST423UHggrs6JfS5dx9MP5OjXFxr2jRRJxgFGq//HWCxn7SXAtuhfCCN y77E1W3v98/HgZydDmnJa5KEBpjbF7r8YrlDWvUaMN6zH+5/TVe0jBqavvHq8P+CCWl+ 8dvCXf6MQuNAM/AzthyDnCtaRH6dKutFGgETEsIGrvRdd3kxaLghxZdExCJV1O7GcZIk sffXV58MJMYzo1mUzq+KViApBVuIptqMCVqOYGvosnuZQTCWd7lUY7Sa/am1xJKoV+l+ 1dHZFr5A/d362kKMgYTUG+7/JM6gx4rfggkSHagquvCS6V1o31PeRKAsO13qk9XB5BUo QRhw== X-Gm-Message-State: AOAM531a/i7Gm54l3jamCkPhxzmViT1wCiYA3/291gHBTbTM2xhlyDra odYRh6JS3ZMZhBcGxNky0sWp6PwZREldElaNXWFb3xRvyP4= X-Google-Smtp-Source: ABdhPJzRD8tEt13QAttRHl0lphHwPrAof6a4cLwv5qrY1yAyR9Qw13knhw/ORDSjPxgDq1+PA25W+Y0CSqGQO45E4QI= X-Received: by 2002:a05:6902:1082:b0:63e:145c:dc55 with SMTP id v2-20020a056902108200b0063e145cdc55mr2075998ybu.283.1649156804796; Tue, 05 Apr 2022 04:06:44 -0700 (PDT) MIME-Version: 1.0 From: =?UTF-8?Q?Eug=C3=A8ne_Adell?= Date: Tue, 5 Apr 2022 12:52:06 +0200 Message-ID: To: dnsop@ietf.org Content-Type: multipart/mixed; boundary="000000000000878e2505dbe63d44" Archived-At: Subject: [DNSOP] introducing a couple of RRTypes (CRC/CRS) for B2B applications X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2022 11:07:05 -0000 --000000000000878e2505dbe63d44 Content-Type: text/plain; charset="UTF-8" Hello, I've been working on two new RRTypes described by a Draft, and as suggested by our magnificent, incredibly brilliant and handsome AD Warren "ACE" Kumari, I am posting here this idea and the material I have written so far (the draft itself, and RFC 6895 components). Briefly, one RRType (CRC : Client Roaming Control) contains a whitelist of networks allowing a company employees to connect to a specific application. The second RRType (CRS : Client Roaming Support) is on the application side and informs what kind of restrictions are applied (by saying if CRC is mandatory, optional or ignored). This is not expected to be deployed broadly and everywhere as it is designed to secure Business-To-Business applications. The material (text XML2RFC draft + RFC 6895 components) written is both incorporated below to this email and attached, for practical reasons. Regards E.A. Internet Engineering Task Force E. Adell Internet-Draft 5 April 2022 Intended status: Informational Expires: 7 October 2022 Client Roaming Control draft-adell-client-roaming-00 Abstract This document specifies the Client Roaming Control (CRC) DNS Resource Record allowing an organization to better control the access to third-party applications over Internet. The applications implementing an authorization mechanism to honor the CRC, publish on their side the Client Roaming Support (CRS) Resource Record to inform of this support. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 7 October 2022. Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Adell Expires 7 October 2022 [Page 1] Internet-Draft Client Roaming Control April 2022 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 3. The CRC Resource Record . . . . . . . . . . . . . . . . . . . 4 3.1. RR name field . . . . . . . . . . . . . . . . . . . . . . 4 3.2. CRC RDATA Wire Format . . . . . . . . . . . . . . . . . . 4 3.3. CRC Presentation Format . . . . . . . . . . . . . . . . . 4 4. The CRS Resource Record . . . . . . . . . . . . . . . . . . . 5 4.1. CRS RDATA Wire Format . . . . . . . . . . . . . . . . . . 5 4.2. CRS Presentation Format . . . . . . . . . . . . . . . . . 5 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.1. Restricted Application . . . . . . . . . . . . . . . . . 6 5.2. Controlled Application . . . . . . . . . . . . . . . . . 7 5.3. Opened Application . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7.1. DNS misconfiguration . . . . . . . . . . . . . . . . . . 9 7.2. DNS Security . . . . . . . . . . . . . . . . . . . . . . 10 7.3. Application Security . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 8.2. Informative References . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction Illegitimate access to professional restricted applications over Internet is a permanent threat for organizations and their staff. Different methods can be used to impersonate a user access, and in some cases an organization also wants to better prevent its own staff to access a third-party application from a network which is not under its control. On the contrary, an organization maybe wants to allow roaming then its users can access from different known places. The Client Roaming Control (CRC) DNS Resource Record (RR) acts as a White-List and informs a compatible application from which networks its users are allowed to connect, be it a limited list of networks or broadly without any restriction. Adell Expires 7 October 2022 [Page 2] Internet-Draft Client Roaming Control April 2022 At the application level, the identification of the user's organization domain can be based on an information carried during the authentication process, or a lookup on an information already known by the application. In both cases this information lets the application relate the user to its organization unequivocally. Finally, the corresponding user's domain DNS will be requested with the application's FQDN and port, and the application will know whether an authorization is expected or not. Some examples will be given in this document. The applications implementing this authorization control let the client organizations know this feature is available by using the Client Roaming Support (CRS) RR. The data associated with this record indicates if the client's organization expected support of the CRC is mandatory, optional, or ignored. This information stored in the CRS can be confirmed at the application level by a redundant data. The way the application handles the authorization mechanism, by consulting the associated CRS record or not, is left to the implementor. Although this mechanism is designed for improving the security between different organizations, there is no objection to use it for a same organization playing both roles of client and application , as an alternative or additional layer to a solution already in place, such as a firewall for example. 2. Conventions Used in This Document This specification uses definitions from Domain Name System [RFC1035], and readers unfamiliar with it can also check DNS Terminology [RFC8499]. The syntax specification uses the Augmented Backus-Naur Form (ABNF) notation as specified in [RFC5234], with some expressions being defined in "Uniform Resource Identifier (URI): Generic Syntax" [RFC3986] and "IP Version 6 Addressing Architecture" [RFC4291]. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Adell Expires 7 October 2022 [Page 3] Internet-Draft Client Roaming Control April 2022 3. The CRC Resource Record The CRC RR purpose is to provide a list of IP ranges authorized to use a particular application. Each RR contains a list of either IPv4 or IPv6 network address ranges. These ranges MUST follow the CIDR notation. A single CRC RR MAY contain ranges for different IP versions, but in the case of many ranges this can be difficult to read or maintain, so dedicating a record to each IP version or not is left to the administrator. Multiple RRs MAY be defined for a given IP version. 3.1. RR name field The CRC RR name field is composed of the third-party application domain, its port, followed by the fully qualified name inherent in this zone. These three components are separated by the underscore character. 3.2. CRC RDATA Wire Format The CRC RDATA wire format is encoded as follows: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / CRC / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ The CRC field contains a list of either IPv4 or IPv6 ranges separated by the comma character. 3.3. CRC Presentation Format The presentation format of the CRC record is: CRC (ip4netlist [,ip6netlist]) / ([ip4netlist,] ip6netlist) ip4netlist = ip4net *(,ip4net) ip4net = IPv4address "/" ip4range ip4range = DIGIT / "1" DIGIT / "2" DIGIT / "3" DIGIT %x30-32 ip6netlist = ip6net *(,ip6net) ip6net = (ipv6-address "/" prefix-length) Adell Expires 7 October 2022 [Page 4] Internet-Draft Client Roaming Control April 2022 4. The CRS Resource Record The CRS RR indicates which control is done on the client organizations, and thus which ones are authorized. A requirement field is used for this purpose, it has one of the following values meaning when the checking is performed : * "N" : Never, all organizations are authorized * "A" : Always, only organizations with a CRC are authorized * "O" : Optional, any organization CRC is honored, other organizations are authorized In addition to this value, an optional list of ports can be given. Indeed, multiple applications can be hosted on different ports under the same domain name, and an equivalent support was described for the CRC RR. In case of different requirement values, it is RECOMMENDED to have one dedicated RR for each although one single RR with all the information is supported. One particular port MUST NOT appear in more than one RR. When no port is mentioned, only one RR MAY be declared and its requirement value covers all applications for this domain name. In the absence of such record, no roaming control is to be expected by the client, any of its CRC RRs will be ignored. It is equivalent to a CRS requirement value indicating no control is performed. 4.1. CRS RDATA Wire Format The CRS RDATA wire format is encoded as follows: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / CRS / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ The CRS field contains a list of requirements followed by their respective optional ports. 4.2. CRS Presentation Format The presentation format of the CRS record is: CRS (single-rule / multiple-rules) single-rule = "R=" ("N" / "A" / "O") *(,port) Adell Expires 7 October 2022 [Page 5] Internet-Draft Client Roaming Control April 2022 multiple-rules = unit-rule 1*2(;unit-rule) unit-rule = "R=" ("N" / "A" / "O") 1*(,port) port = [1-9] *([DIGIT]) 5. Examples The following examples show some typical uses expected from this documentation. Particularly, the intended behaviors for different CRC and CRS values are explained, while the user identification is done directly through carried data or a deduction process. 5.1. Restricted Application In this example, an application is only opened to organizations publishing their respective allowed networks. The requirement value of the CRS record equals "A", and any organization with an empty or missing CRC for this application will be denied access. The ftp.foo.com domain is dedicated to hosting an FTP application, which extracts the client's domain from the username used during the authentication process. This information is then used for requesting the client CRC record and finally comparing its content with the client's IP. The client organization bar.com allows its users from its own network 195.13.35.0/24 and from a cloud service located at 91.220.43.0/24. A second organization baz.com has no CRC record and its users are rejected. Application FQDN : ftp.foo.com Application CRS record : CRS R=A,21 Client FQDN : bar.com Client organization CRC record : CRC ftp.foo.com_21_bar.com,195.13.35.0/24,91.220.43.0/24 Client FQDN : baz.com No client organization CRC record Adell Expires 7 October 2022 [Page 6] Internet-Draft Client Roaming Control April 2022 Client DNS Client FTP Server FTP FTP USER me@bar.com -----------------------------> ... FTP PASS ******** -----------------------------> Query : CRC ftp.foo.com_21_bar.com <------------------------------------ Answer : CRC ftp.foo.com_21_bar.com,195.13.35.0/24,91.220.43.0/24 ------------------------------------> FTP 230 <------------------------------ FTP USER me@baz.com -----------------------------> ... FTP PASS ******** -----------------------------> Query : CRC ftp.foo.com_21_baz.com <------------------------------------ Answer : No such name (3) ------------------------------------> FTP 430 <------------------------------ 5.2. Controlled Application The foo.com domain hosts a Web application on port 443 using client certificates for authenticating its users. The application extracts the client domains from the certificates, which are used to retrieve their CRC records. Users from the bar.com organization are allowed only if they connect from an authorized network listed in the CRC record, while users from baz.com are always granted access since this one has no CRC declared. Application FQDN : foo.com Application CRS record : CRS R=A,443 Client FQDN : bar.com Client organization CRC record : CRC ftp.foo.com_443_bar.com,195.13.35.0/24,91.220.43.0/24 Client FQDN : baz.com No client organization CRC record Adell Expires 7 October 2022 [Page 7] Internet-Draft Client Roaming Control April 2022 Client DNS Client browser Web application ..... Client certificate me@bar.com -----------------------------------> Query : CRC foo.com_443_bar.com <------------------------------------------ Answer : CRC foo.com_443_bar.com,195.13.35.0/24,91.220.43.0/24 ------------------------------------------> ..... 200 OK <----------------------------------- ..... Client certificate me@baz.com -----------------------------------> Query : CRC foo.com_443_baz.com <------------------------------------------ Answer : No such name (3) ------------------------------------------> ..... 200 OK <----------------------------------- 5.3. Opened Application A company is testing the CRC and CRS behaviors before opening a new service to its customers. Its first test described below consists in configuring both sides to be completely opened, likely before hardening the CRS, then the CRC, and testing again. The application.foo.com domain hosts a Web application on port 443 where users are logged in by sending a numerical identifier and a password. The application uses a dictionary data type to identify the user's domain. The client.foo.com domain is temporarily using 2 CRC records indicating a free access from anywhere. Application FQDN : application.foo.com Application CRS record : CRS R=N,443 Client FQDN : client.foo.com Client organization CRC records : CRC application.foo.com_443_foo.com,0.0.0.0/24; CRC application.foo.com_443_foo.com,fe80::/10 Adell Expires 7 October 2022 [Page 8] Internet-Draft Client Roaming Control April 2022 Client DNS Client browser Web application ..... HTTP POST 123456/****** -----------------------------------> 200 OK <----------------------------------- 6. IANA Considerations According to Guidelines for Writing an IANA Considerations Section in RFCs [RFC8126] it is asked to IANA to add into the Resource Record (RR) TYPEs registry located at https://www.iana.org/assignments/dns- parameters/dns-parameters.xhtml#dns-parameters-4 the two entries CRC and CRS. +------+-------+------------------------+-----------+ | TYPE | Value | Description | Reference | +------+-------+------------------------+-----------+ | CRC | TBD1 | Client Roaming Control | this RFC | +------+-------+------------------------+-----------+ | CRS | TBD2 | Client Roaming Support | this RFC | +------+-------+------------------------+-----------+ Table 1 7. Security Considerations This section is meant to inform developers and users of the security implications of the CRC/CRS mechanism described by this document. While the CRS RR mostly plays an informative role, the CRC RR delivers important data which requires attention from the developers and administrators. Some particular points are discussed here. 7.1. DNS misconfiguration Any DNS CRS misconfiguration such as multiple records with different requirement values but with the same port value can get a client confused. In this case the client does not know without testing the actual configuration, if its organization is protected against roaming, and contacting the application administrator to fix the situation is a possibility. While CRC misconfigurations are more or less leading to serious security problems, administrators need to pay attention when dealing with multiple networks or records. Particularly, multiple records for the same network range or overlapping networks should be avoided. Adell Expires 7 October 2022 [Page 9] Internet-Draft Client Roaming Control April 2022 7.2. DNS Security Client and application administrators need to pay as much attention as they usually do when dealing with DNS management. As the CRC records are supposed to be requested during an application authentication process, reflection attacks could be built to target a client organization, even one not hosting any CRC record at all. In a general manner, administrators may consider an adequate TTL setting to not overload client organizations, enable TCP as the preferred transport, or rely on DNSSEC to warrant data authenticity and integrity. 7.3. Application Security The following points are of concern to developers: Encryption: Whenever possible, the application protocol should be encrypted to prevent eavesdropping and man-in-the-middle attacks. It is a critical point for applications maintaining a user session with anything like a token or cookie, as it can lead to session hijacking as discussed below. Timing attack: All authentication systems need to be careful to not deliver any information derived from the computing time to a denied user, even the ones involving multiple factors or steps like the one described in this document. In particular, the order in which these steps are executed and their respective implementations, need to defeat statistical hypotheses. Intermediate systems: Some applications are not directly Internet facing and cannot access to the real client's IP address without involving a mechanism to forward this IP at the application layer. For example with HTTP, the common practice based on the non-standard X-Forwarded-For header, or its alternative standard Forwarded [RFC7239], are playing this role. Such practice requires a correct sanitizing of user data to avoid false injected IPs. Session hijacking: A well-known attack called Session Hijacking is not meant to be defeated by this document alone. Application developers must ensure that any receveid session token, such as an HTTP Cookie, belongs to the same IP address than the one which started this session. 8. References Adell Expires 7 October 2022 [Page 10] Internet-Draft Client Roaming Control April 2022 8.1. Normative References [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, . [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, . [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 8.2. Informative References [RFC7239] Petersson, A. and M. Nilsson, "Forwarded HTTP Extension", RFC 7239, DOI 10.17487/RFC7239, June 2014, . [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, January 2019, . Author's Address Eugene Adell Email: eugene.adell@gmail.com Adell Expires 7 October 2022 [Page 11] RFC 6895 : A. Submission Date:2002/04/05 B.1 Submission Type: [X] New RRTYPE [ ] Modification to RRTYPE B.2 Kind of RR: [X] Data RR [ ] Meta-RR C. Contact Information for submitter : Name: Eugene Adell Email Address: eugene.adell@gmail.com International telephone number: +33699056914 Other contact handles: D. Motivation for the new RRTYPE application. Introduce a couple of RR types working together in order to better secure remote access to partner applications E. Description of the proposed RR type. CRC contains a limited list of authorized networks for a particular application F. What existing RRTYPE or RRTYPEs come closest to filling that need and why are they unsatisfactory? TXT RRTYPE allows the storage of any text data but in practice is usually associated with more or less fixed name or data which is not what is needed here. A dedicated RRTYPE is easier to identify and manage by a security team other than the usual DNS operator team. G. What mnemonic is requested for the new RRTYPE (optional)? CRC H. Does the requested RRTYPE make use of any existing IANA registry or require the creation of a new IANA subregistry in DNS Parameters? It uses the existing Resource Record (RR) TYPEs registry I. Does the proposal require/expect any changes in DNS servers/resolvers that prevent the new type from being processed as an unknown RRTYPE (see [RFC3597])? No J. Comments: None A. Submission Date:2002/04/05 B.1 Submission Type: [X] New RRTYPE [ ] Modification to RRTYPE B.2 Kind of RR: [X] Data RR [ ] Meta-RR C. Contact Information for submitter : Name: Eugene Adell Email Address: eugene.adell@gmail.com International telephone number: +33699056914 Other contact handles: D. Motivation for the new RRTYPE application. Introduce a couple of RR types working together in order to better secure remote access to partner applications E. Description of the proposed RR type. CRS contains a requirement value and a list of ports indicating what kind of authorization check is done during the application authentication process F. What existing RRTYPE or RRTYPEs come closest to filling that need and why are they unsatisfactory? TXT RRTYPE allows the storage of any text data but in practice is usually associated with more or less fixed name or data which is not what is needed here. A dedicated RRTYPE is easier to identify and manage by a security team other than the usual DNS operator team. G. What mnemonic is requested for the new RRTYPE (optional)? CRS H. Does the requested RRTYPE make use of any existing IANA registry or require the creation of a new IANA subregistry in DNS Parameters? It uses the existing Resource Record (RR) TYPEs registry I. Does the proposal require/expect any changes in DNS servers/resolvers that prevent the new type from being processed as an unknown RRTYPE (see [RFC3597])? No J. Comments: None --000000000000878e2505dbe63d44 Content-Type: text/plain; charset="US-ASCII"; name="draft-adell-client-roaming-00.txt" Content-Disposition: attachment; filename="draft-adell-client-roaming-00.txt" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_l1m0r1gx0 CgoKCkludGVybmV0IEVuZ2luZWVyaW5nIFRhc2sgRm9yY2UgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBFLiBBZGVsbApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICA1IEFwcmlsIDIwMjIKSW50ZW5kZWQgc3RhdHVzOiBJbmZv cm1hdGlvbmFsICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCkV4cGly ZXM6IDcgT2N0b2JlciAyMDIyCgoKICAgICAgICAgICAgICAgICAgICAgICAgIENsaWVudCBSb2Ft aW5nIENvbnRyb2wKICAgICAgICAgICAgICAgICAgICAgZHJhZnQtYWRlbGwtY2xpZW50LXJvYW1p bmctMDAKCkFic3RyYWN0CgogICBUaGlzIGRvY3VtZW50IHNwZWNpZmllcyB0aGUgQ2xpZW50IFJv YW1pbmcgQ29udHJvbCAoQ1JDKSBETlMgUmVzb3VyY2UKICAgUmVjb3JkIGFsbG93aW5nIGFuIG9y Z2FuaXphdGlvbiB0byBiZXR0ZXIgY29udHJvbCB0aGUgYWNjZXNzIHRvCiAgIHRoaXJkLXBhcnR5 IGFwcGxpY2F0aW9ucyBvdmVyIEludGVybmV0LiAgVGhlIGFwcGxpY2F0aW9ucwogICBpbXBsZW1l bnRpbmcgYW4gYXV0aG9yaXphdGlvbiBtZWNoYW5pc20gdG8gaG9ub3IgdGhlIENSQywgcHVibGlz aCBvbgogICB0aGVpciBzaWRlIHRoZSBDbGllbnQgUm9hbWluZyBTdXBwb3J0IChDUlMpIFJlc291 cmNlIFJlY29yZCB0byBpbmZvcm0KICAgb2YgdGhpcyBzdXBwb3J0LgoKU3RhdHVzIG9mIFRoaXMg TWVtbwoKICAgVGhpcyBJbnRlcm5ldC1EcmFmdCBpcyBzdWJtaXR0ZWQgaW4gZnVsbCBjb25mb3Jt YW5jZSB3aXRoIHRoZQogICBwcm92aXNpb25zIG9mIEJDUCA3OCBhbmQgQkNQIDc5LgoKICAgSW50 ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5l ZXJpbmcKICAgVGFzayBGb3JjZSAoSUVURikuICBOb3RlIHRoYXQgb3RoZXIgZ3JvdXBzIG1heSBh bHNvIGRpc3RyaWJ1dGUKICAgd29ya2luZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQtRHJhZnRzLiAg VGhlIGxpc3Qgb2YgY3VycmVudCBJbnRlcm5ldC0KICAgRHJhZnRzIGlzIGF0IGh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZHJhZnRzL2N1cnJlbnQvLgoKICAgSW50ZXJuZXQtRHJhZnRzIGFy ZSBkcmFmdCBkb2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhzCiAgIGFu ZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSBvdGhlciBkb2N1bWVu dHMgYXQgYW55CiAgIHRpbWUuICBJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5ldC1E cmFmdHMgYXMgcmVmZXJlbmNlCiAgIG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0aGFu IGFzICJ3b3JrIGluIHByb2dyZXNzLiIKCiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgd2lsbCBleHBp cmUgb24gNyBPY3RvYmVyIDIwMjIuCgpDb3B5cmlnaHQgTm90aWNlCgogICBDb3B5cmlnaHQgKGMp IDIwMjIgSUVURiBUcnVzdCBhbmQgdGhlIHBlcnNvbnMgaWRlbnRpZmllZCBhcyB0aGUKICAgZG9j dW1lbnQgYXV0aG9ycy4gIEFsbCByaWdodHMgcmVzZXJ2ZWQuCgogICBUaGlzIGRvY3VtZW50IGlz IHN1YmplY3QgdG8gQkNQIDc4IGFuZCB0aGUgSUVURiBUcnVzdCdzIExlZ2FsCiAgIFByb3Zpc2lv bnMgUmVsYXRpbmcgdG8gSUVURiBEb2N1bWVudHMgKGh0dHBzOi8vdHJ1c3RlZS5pZXRmLm9yZy8K ICAgbGljZW5zZS1pbmZvKSBpbiBlZmZlY3Qgb24gdGhlIGRhdGUgb2YgcHVibGljYXRpb24gb2Yg dGhpcyBkb2N1bWVudC4KICAgUGxlYXNlIHJldmlldyB0aGVzZSBkb2N1bWVudHMgY2FyZWZ1bGx5 LCBhcyB0aGV5IGRlc2NyaWJlIHlvdXIgcmlnaHRzCiAgIGFuZCByZXN0cmljdGlvbnMgd2l0aCBy ZXNwZWN0IHRvIHRoaXMgZG9jdW1lbnQuICBDb2RlIENvbXBvbmVudHMKICAgZXh0cmFjdGVkIGZy b20gdGhpcyBkb2N1bWVudCBtdXN0IGluY2x1ZGUgUmV2aXNlZCBCU0QgTGljZW5zZSB0ZXh0IGFz CiAgIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDQuZSBvZiB0aGUgVHJ1c3QgTGVnYWwgUHJvdmlzaW9u cyBhbmQgYXJlCiAgIHByb3ZpZGVkIHdpdGhvdXQgd2FycmFudHkgYXMgZGVzY3JpYmVkIGluIHRo ZSBSZXZpc2VkIEJTRCBMaWNlbnNlLgoKCgpBZGVsbCAgICAgICAgICAgICAgICAgICAgRXhwaXJl cyA3IE9jdG9iZXIgMjAyMiAgICAgICAgICAgICAgICAgW1BhZ2UgMV0KDApJbnRlcm5ldC1EcmFm dCAgICAgICAgICAgQ2xpZW50IFJvYW1pbmcgQ29udHJvbCAgICAgICAgICAgICAgIEFwcmlsIDIw MjIKCgpUYWJsZSBvZiBDb250ZW50cwoKICAgMS4gIEludHJvZHVjdGlvbiAgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICAyCiAgIDIuICBDb252ZW50aW9u cyBVc2VkIGluIFRoaXMgRG9jdW1lbnQgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgMwog ICAzLiAgVGhlIENSQyBSZXNvdXJjZSBSZWNvcmQgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAgIDQKICAgICAzLjEuICBSUiBuYW1lIGZpZWxkIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA0CiAgICAgMy4yLiAgQ1JDIFJEQVRBIFdpcmUg Rm9ybWF0IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNAogICAgIDMuMy4g IENSQyBQcmVzZW50YXRpb24gRm9ybWF0IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAgIDQKICAgNC4gIFRoZSBDUlMgUmVzb3VyY2UgUmVjb3JkIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gICA1CiAgICAgNC4xLiAgQ1JTIFJEQVRBIFdpcmUgRm9ybWF0IC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNQogICAgIDQuMi4gIENSUyBQcmVz ZW50YXRpb24gRm9ybWF0IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDUKICAg NS4gIEV4YW1wbGVzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gICA2CiAgICAgNS4xLiAgUmVzdHJpY3RlZCBBcHBsaWNhdGlvbiAgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNgogICAgIDUuMi4gIENvbnRyb2xsZWQgQXBwbGlj YXRpb24gIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDcKICAgICA1LjMuICBP cGVuZWQgQXBwbGljYXRpb24gIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g ICA4CiAgIDYuICBJQU5BIENvbnNpZGVyYXRpb25zIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuICAgOQogICA3LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDkKICAgICA3LjEuICBETlMgbWlzY29u ZmlndXJhdGlvbiAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA5CiAgICAg Ny4yLiAgRE5TIFNlY3VyaXR5ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuICAxMAogICAgIDcuMy4gIEFwcGxpY2F0aW9uIFNlY3VyaXR5ICAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTAKICAgOC4gIFJlZmVyZW5jZXMgIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDEwCiAgICAgOC4xLiAgTm9y bWF0aXZlIFJlZmVyZW5jZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAx MQogICAgIDguMi4gIEluZm9ybWF0aXZlIFJlZmVyZW5jZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAgMTEKICAgQXV0aG9yJ3MgQWRkcmVzcyAgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDExCgoxLiAgSW50cm9kdWN0aW9uCgogICBJ bGxlZ2l0aW1hdGUgYWNjZXNzIHRvIHByb2Zlc3Npb25hbCByZXN0cmljdGVkIGFwcGxpY2F0aW9u cyBvdmVyCiAgIEludGVybmV0IGlzIGEgcGVybWFuZW50IHRocmVhdCBmb3Igb3JnYW5pemF0aW9u cyBhbmQgdGhlaXIgc3RhZmYuCiAgIERpZmZlcmVudCBtZXRob2RzIGNhbiBiZSB1c2VkIHRvIGlt cGVyc29uYXRlIGEgdXNlciBhY2Nlc3MsIGFuZCBpbgogICBzb21lIGNhc2VzIGFuIG9yZ2FuaXph dGlvbiBhbHNvIHdhbnRzIHRvIGJldHRlciBwcmV2ZW50IGl0cyBvd24gc3RhZmYKICAgdG8gYWNj ZXNzIGEgdGhpcmQtcGFydHkgYXBwbGljYXRpb24gZnJvbSBhIG5ldHdvcmsgd2hpY2ggaXMgbm90 IHVuZGVyCiAgIGl0cyBjb250cm9sLiAgT24gdGhlIGNvbnRyYXJ5LCBhbiBvcmdhbml6YXRpb24g bWF5YmUgd2FudHMgdG8gYWxsb3cKICAgcm9hbWluZyB0aGVuIGl0cyB1c2VycyBjYW4gYWNjZXNz IGZyb20gZGlmZmVyZW50IGtub3duIHBsYWNlcy4KCiAgIFRoZSBDbGllbnQgUm9hbWluZyBDb250 cm9sIChDUkMpIEROUyBSZXNvdXJjZSBSZWNvcmQgKFJSKSBhY3RzIGFzIGEKICAgV2hpdGUtTGlz dCBhbmQgaW5mb3JtcyBhIGNvbXBhdGlibGUgYXBwbGljYXRpb24gZnJvbSB3aGljaCBuZXR3b3Jr cwogICBpdHMgdXNlcnMgYXJlIGFsbG93ZWQgdG8gY29ubmVjdCwgYmUgaXQgYSBsaW1pdGVkIGxp c3Qgb2YgbmV0d29ya3Mgb3IKICAgYnJvYWRseSB3aXRob3V0IGFueSByZXN0cmljdGlvbi4KCgoK CgoKCgoKCgoKQWRlbGwgICAgICAgICAgICAgICAgICAgIEV4cGlyZXMgNyBPY3RvYmVyIDIwMjIg ICAgICAgICAgICAgICAgIFtQYWdlIDJdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgIENsaWVu dCBSb2FtaW5nIENvbnRyb2wgICAgICAgICAgICAgICBBcHJpbCAyMDIyCgoKICAgQXQgdGhlIGFw cGxpY2F0aW9uIGxldmVsLCB0aGUgaWRlbnRpZmljYXRpb24gb2YgdGhlIHVzZXIncwogICBvcmdh bml6YXRpb24gZG9tYWluIGNhbiBiZSBiYXNlZCBvbiBhbiBpbmZvcm1hdGlvbiBjYXJyaWVkIGR1 cmluZyB0aGUKICAgYXV0aGVudGljYXRpb24gcHJvY2Vzcywgb3IgYSBsb29rdXAgb24gYW4gaW5m b3JtYXRpb24gYWxyZWFkeSBrbm93bgogICBieSB0aGUgYXBwbGljYXRpb24uICBJbiBib3RoIGNh c2VzIHRoaXMgaW5mb3JtYXRpb24gbGV0cyB0aGUKICAgYXBwbGljYXRpb24gcmVsYXRlIHRoZSB1 c2VyIHRvIGl0cyBvcmdhbml6YXRpb24gdW5lcXVpdm9jYWxseS4KICAgRmluYWxseSwgdGhlIGNv cnJlc3BvbmRpbmcgdXNlcidzIGRvbWFpbiBETlMgd2lsbCBiZSByZXF1ZXN0ZWQgd2l0aAogICB0 aGUgYXBwbGljYXRpb24ncyBGUUROIGFuZCBwb3J0LCBhbmQgdGhlIGFwcGxpY2F0aW9uIHdpbGwg a25vdwogICB3aGV0aGVyIGFuIGF1dGhvcml6YXRpb24gaXMgZXhwZWN0ZWQgb3Igbm90LiAgU29t ZSBleGFtcGxlcyB3aWxsIGJlCiAgIGdpdmVuIGluIHRoaXMgZG9jdW1lbnQuCgogICBUaGUgYXBw bGljYXRpb25zIGltcGxlbWVudGluZyB0aGlzIGF1dGhvcml6YXRpb24gY29udHJvbCBsZXQgdGhl CiAgIGNsaWVudCBvcmdhbml6YXRpb25zIGtub3cgdGhpcyBmZWF0dXJlIGlzIGF2YWlsYWJsZSBi eSB1c2luZyB0aGUKICAgQ2xpZW50IFJvYW1pbmcgU3VwcG9ydCAoQ1JTKSBSUi4gIFRoZSBkYXRh IGFzc29jaWF0ZWQgd2l0aCB0aGlzCiAgIHJlY29yZCBpbmRpY2F0ZXMgaWYgdGhlIGNsaWVudCdz IG9yZ2FuaXphdGlvbiBleHBlY3RlZCBzdXBwb3J0IG9mIHRoZQogICBDUkMgaXMgbWFuZGF0b3J5 LCBvcHRpb25hbCwgb3IgaWdub3JlZC4gIFRoaXMgaW5mb3JtYXRpb24gc3RvcmVkIGluCiAgIHRo ZSBDUlMgY2FuIGJlIGNvbmZpcm1lZCBhdCB0aGUgYXBwbGljYXRpb24gbGV2ZWwgYnkgYSByZWR1 bmRhbnQKICAgZGF0YS4gIFRoZSB3YXkgdGhlIGFwcGxpY2F0aW9uIGhhbmRsZXMgdGhlIGF1dGhv cml6YXRpb24gbWVjaGFuaXNtLAogICBieSBjb25zdWx0aW5nIHRoZSBhc3NvY2lhdGVkIENSUyBy ZWNvcmQgb3Igbm90LCBpcyBsZWZ0IHRvIHRoZQogICBpbXBsZW1lbnRvci4KCiAgIEFsdGhvdWdo IHRoaXMgbWVjaGFuaXNtIGlzIGRlc2lnbmVkIGZvciBpbXByb3ZpbmcgdGhlIHNlY3VyaXR5CiAg IGJldHdlZW4gZGlmZmVyZW50IG9yZ2FuaXphdGlvbnMsIHRoZXJlIGlzIG5vIG9iamVjdGlvbiB0 byB1c2UgaXQgZm9yCiAgIGEgc2FtZSBvcmdhbml6YXRpb24gcGxheWluZyBib3RoIHJvbGVzIG9m IGNsaWVudCBhbmQgYXBwbGljYXRpb24gLCBhcwogICBhbiBhbHRlcm5hdGl2ZSBvciBhZGRpdGlv bmFsIGxheWVyIHRvIGEgc29sdXRpb24gYWxyZWFkeSBpbiBwbGFjZSwKICAgc3VjaCBhcyBhIGZp cmV3YWxsIGZvciBleGFtcGxlLgoKMi4gIENvbnZlbnRpb25zIFVzZWQgaW4gVGhpcyBEb2N1bWVu dAoKICAgVGhpcyBzcGVjaWZpY2F0aW9uIHVzZXMgZGVmaW5pdGlvbnMgZnJvbSBEb21haW4gTmFt ZSBTeXN0ZW0KICAgW1JGQzEwMzVdLCBhbmQgcmVhZGVycyB1bmZhbWlsaWFyIHdpdGggaXQgY2Fu IGFsc28gY2hlY2sgRE5TCiAgIFRlcm1pbm9sb2d5IFtSRkM4NDk5XS4gIFRoZSBzeW50YXggc3Bl Y2lmaWNhdGlvbiB1c2VzIHRoZSBBdWdtZW50ZWQKICAgQmFja3VzLU5hdXIgRm9ybSAoQUJORikg bm90YXRpb24gYXMgc3BlY2lmaWVkIGluIFtSRkM1MjM0XSwgd2l0aCBzb21lCiAgIGV4cHJlc3Np b25zIGJlaW5nIGRlZmluZWQgaW4gIlVuaWZvcm0gUmVzb3VyY2UgSWRlbnRpZmllciAoVVJJKToK ICAgR2VuZXJpYyBTeW50YXgiIFtSRkMzOTg2XSBhbmQgIklQIFZlcnNpb24gNiBBZGRyZXNzaW5n IEFyY2hpdGVjdHVyZSIKICAgW1JGQzQyOTFdLgoKICAgVGhlIGtleSB3b3JkcyAiTVVTVCIsICJN VVNUIE5PVCIsICJSRVFVSVJFRCIsICJTSEFMTCIsICJTSEFMTCBOT1QiLAogICAiU0hPVUxEIiwg IlNIT1VMRCBOT1QiLCAiUkVDT01NRU5ERUQiLCAiTk9UIFJFQ09NTUVOREVEIiwgIk1BWSIsIGFu ZAogICAiT1BUSU9OQUwiIGluIHRoaXMgZG9jdW1lbnQgYXJlIHRvIGJlIGludGVycHJldGVkIGFz IGRlc2NyaWJlZCBpbiBCQ1AKICAgMTQgW1JGQzIxMTldIFtSRkM4MTc0XSB3aGVuLCBhbmQgb25s eSB3aGVuLCB0aGV5IGFwcGVhciBpbiBhbGwKICAgY2FwaXRhbHMsIGFzIHNob3duIGhlcmUuCgoK CgoKCgoKCgpBZGVsbCAgICAgICAgICAgICAgICAgICAgRXhwaXJlcyA3IE9jdG9iZXIgMjAyMiAg ICAgICAgICAgICAgICAgW1BhZ2UgM10KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgQ2xpZW50 IFJvYW1pbmcgQ29udHJvbCAgICAgICAgICAgICAgIEFwcmlsIDIwMjIKCgozLiAgVGhlIENSQyBS ZXNvdXJjZSBSZWNvcmQKCiAgIFRoZSBDUkMgUlIgcHVycG9zZSBpcyB0byBwcm92aWRlIGEgbGlz dCBvZiBJUCByYW5nZXMgYXV0aG9yaXplZCB0bwogICB1c2UgYSBwYXJ0aWN1bGFyIGFwcGxpY2F0 aW9uLiAgRWFjaCBSUiBjb250YWlucyBhIGxpc3Qgb2YgZWl0aGVyIElQdjQKICAgb3IgSVB2NiBu ZXR3b3JrIGFkZHJlc3MgcmFuZ2VzLiAgVGhlc2UgcmFuZ2VzIE1VU1QgZm9sbG93IHRoZSBDSURS CiAgIG5vdGF0aW9uLiAgQSBzaW5nbGUgQ1JDIFJSIE1BWSBjb250YWluIHJhbmdlcyBmb3IgZGlm ZmVyZW50IElQCiAgIHZlcnNpb25zLCBidXQgaW4gdGhlIGNhc2Ugb2YgbWFueSByYW5nZXMgdGhp cyBjYW4gYmUgZGlmZmljdWx0IHRvCiAgIHJlYWQgb3IgbWFpbnRhaW4sIHNvIGRlZGljYXRpbmcg YSByZWNvcmQgdG8gZWFjaCBJUCB2ZXJzaW9uIG9yIG5vdCBpcwogICBsZWZ0IHRvIHRoZSBhZG1p bmlzdHJhdG9yLiAgTXVsdGlwbGUgUlJzIE1BWSBiZSBkZWZpbmVkIGZvciBhIGdpdmVuCiAgIElQ IHZlcnNpb24uCgozLjEuICBSUiBuYW1lIGZpZWxkCgogICBUaGUgQ1JDIFJSIG5hbWUgZmllbGQg aXMgY29tcG9zZWQgb2YgdGhlIHRoaXJkLXBhcnR5IGFwcGxpY2F0aW9uCiAgIGRvbWFpbiwgaXRz IHBvcnQsIGZvbGxvd2VkIGJ5IHRoZSBmdWxseSBxdWFsaWZpZWQgbmFtZSBpbmhlcmVudCBpbgog ICB0aGlzIHpvbmUuICBUaGVzZSB0aHJlZSBjb21wb25lbnRzIGFyZSBzZXBhcmF0ZWQgYnkgdGhl IHVuZGVyc2NvcmUKICAgY2hhcmFjdGVyLgoKMy4yLiAgQ1JDIFJEQVRBIFdpcmUgRm9ybWF0Cgog ICBUaGUgQ1JDIFJEQVRBIHdpcmUgZm9ybWF0IGlzIGVuY29kZWQgYXMgZm9sbG93czoKCiAgICAg ICArLS0rLS0rLS0rLS0rLS0rLS0rLS0rLS0rLS0rLS0rLS0rLS0rLS0rLS0rLS0rLS0rCiAgICAg ICAvICAgICAgICAgICAgICAgICAgICAgQ1JDICAgICAgICAgICAgICAgICAgICAgICAvCiAgICAg ICAvICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAvCiAgICAg ICArLS0rLS0rLS0rLS0rLS0rLS0rLS0rLS0rLS0rLS0rLS0rLS0rLS0rLS0rLS0rLS0rCgogICBU aGUgQ1JDIGZpZWxkIGNvbnRhaW5zIGEgbGlzdCBvZiBlaXRoZXIgSVB2NCBvciBJUHY2IHJhbmdl cyBzZXBhcmF0ZWQKICAgYnkgdGhlIGNvbW1hIGNoYXJhY3Rlci4KCjMuMy4gIENSQyBQcmVzZW50 YXRpb24gRm9ybWF0CgogICBUaGUgcHJlc2VudGF0aW9uIGZvcm1hdCBvZiB0aGUgQ1JDIHJlY29y ZCBpczoKCiAgIENSQyAoaXA0bmV0bGlzdCBbLGlwNm5ldGxpc3RdKSAvIChbaXA0bmV0bGlzdCxd IGlwNm5ldGxpc3QpCgogICBpcDRuZXRsaXN0ID0gaXA0bmV0ICooLGlwNG5ldCkKCiAgIGlwNG5l dCA9IElQdjRhZGRyZXNzICIvIiBpcDRyYW5nZQoKICAgaXA0cmFuZ2UgPSBESUdJVCAvICIxIiBE SUdJVCAvICIyIiBESUdJVCAvICIzIiBESUdJVCAleDMwLTMyCgogICBpcDZuZXRsaXN0ID0gaXA2 bmV0ICooLGlwNm5ldCkKCiAgIGlwNm5ldCA9IChpcHY2LWFkZHJlc3MgIi8iIHByZWZpeC1sZW5n dGgpCgoKCgoKCkFkZWxsICAgICAgICAgICAgICAgICAgICBFeHBpcmVzIDcgT2N0b2JlciAyMDIy ICAgICAgICAgICAgICAgICBbUGFnZSA0XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICBDbGll bnQgUm9hbWluZyBDb250cm9sICAgICAgICAgICAgICAgQXByaWwgMjAyMgoKCjQuICBUaGUgQ1JT IFJlc291cmNlIFJlY29yZAoKICAgVGhlIENSUyBSUiBpbmRpY2F0ZXMgd2hpY2ggY29udHJvbCBp cyBkb25lIG9uIHRoZSBjbGllbnQKICAgb3JnYW5pemF0aW9ucywgYW5kIHRodXMgd2hpY2ggb25l cyBhcmUgYXV0aG9yaXplZC4gIEEgcmVxdWlyZW1lbnQKICAgZmllbGQgaXMgdXNlZCBmb3IgdGhp cyBwdXJwb3NlLCBpdCBoYXMgb25lIG9mIHRoZSBmb2xsb3dpbmcgdmFsdWVzCiAgIG1lYW5pbmcg d2hlbiB0aGUgY2hlY2tpbmcgaXMgcGVyZm9ybWVkIDoKCiAgICogICJOIiA6IE5ldmVyLCBhbGwg b3JnYW5pemF0aW9ucyBhcmUgYXV0aG9yaXplZAoKICAgKiAgIkEiIDogQWx3YXlzLCBvbmx5IG9y Z2FuaXphdGlvbnMgd2l0aCBhIENSQyBhcmUgYXV0aG9yaXplZAoKICAgKiAgIk8iIDogT3B0aW9u YWwsIGFueSBvcmdhbml6YXRpb24gQ1JDIGlzIGhvbm9yZWQsIG90aGVyCiAgICAgIG9yZ2FuaXph dGlvbnMgYXJlIGF1dGhvcml6ZWQKCiAgIEluIGFkZGl0aW9uIHRvIHRoaXMgdmFsdWUsIGFuIG9w dGlvbmFsIGxpc3Qgb2YgcG9ydHMgY2FuIGJlIGdpdmVuLgogICBJbmRlZWQsIG11bHRpcGxlIGFw cGxpY2F0aW9ucyBjYW4gYmUgaG9zdGVkIG9uIGRpZmZlcmVudCBwb3J0cyB1bmRlcgogICB0aGUg c2FtZSBkb21haW4gbmFtZSwgYW5kIGFuIGVxdWl2YWxlbnQgc3VwcG9ydCB3YXMgZGVzY3JpYmVk IGZvciB0aGUKICAgQ1JDIFJSLiAgSW4gY2FzZSBvZiBkaWZmZXJlbnQgcmVxdWlyZW1lbnQgdmFs dWVzLCBpdCBpcyBSRUNPTU1FTkRFRAogICB0byBoYXZlIG9uZSBkZWRpY2F0ZWQgUlIgZm9yIGVh Y2ggYWx0aG91Z2ggb25lIHNpbmdsZSBSUiB3aXRoIGFsbCB0aGUKICAgaW5mb3JtYXRpb24gaXMg c3VwcG9ydGVkLiAgT25lIHBhcnRpY3VsYXIgcG9ydCBNVVNUIE5PVCBhcHBlYXIgaW4KICAgbW9y ZSB0aGFuIG9uZSBSUi4gIFdoZW4gbm8gcG9ydCBpcyBtZW50aW9uZWQsIG9ubHkgb25lIFJSIE1B WSBiZQogICBkZWNsYXJlZCBhbmQgaXRzIHJlcXVpcmVtZW50IHZhbHVlIGNvdmVycyBhbGwgYXBw bGljYXRpb25zIGZvciB0aGlzCiAgIGRvbWFpbiBuYW1lLgoKICAgSW4gdGhlIGFic2VuY2Ugb2Yg c3VjaCByZWNvcmQsIG5vIHJvYW1pbmcgY29udHJvbCBpcyB0byBiZSBleHBlY3RlZAogICBieSB0 aGUgY2xpZW50LCBhbnkgb2YgaXRzIENSQyBSUnMgd2lsbCBiZSBpZ25vcmVkLiAgSXQgaXMgZXF1 aXZhbGVudAogICB0byBhIENSUyByZXF1aXJlbWVudCB2YWx1ZSBpbmRpY2F0aW5nIG5vIGNvbnRy b2wgaXMgcGVyZm9ybWVkLgoKNC4xLiAgQ1JTIFJEQVRBIFdpcmUgRm9ybWF0CgogICBUaGUgQ1JT IFJEQVRBIHdpcmUgZm9ybWF0IGlzIGVuY29kZWQgYXMgZm9sbG93czoKCiAgICAgICArLS0rLS0r LS0rLS0rLS0rLS0rLS0rLS0rLS0rLS0rLS0rLS0rLS0rLS0rLS0rLS0rCiAgICAgICAvICAgICAg ICAgICAgICAgICAgICAgQ1JTICAgICAgICAgICAgICAgICAgICAgICAvCiAgICAgICAvICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAvCiAgICAgICArLS0rLS0r LS0rLS0rLS0rLS0rLS0rLS0rLS0rLS0rLS0rLS0rLS0rLS0rLS0rLS0rCgogICBUaGUgQ1JTIGZp ZWxkIGNvbnRhaW5zIGEgbGlzdCBvZiByZXF1aXJlbWVudHMgZm9sbG93ZWQgYnkgdGhlaXIKICAg cmVzcGVjdGl2ZSBvcHRpb25hbCBwb3J0cy4KCjQuMi4gIENSUyBQcmVzZW50YXRpb24gRm9ybWF0 CgogICBUaGUgcHJlc2VudGF0aW9uIGZvcm1hdCBvZiB0aGUgQ1JTIHJlY29yZCBpczoKCiAgIENS UyAoc2luZ2xlLXJ1bGUgLyBtdWx0aXBsZS1ydWxlcykKCiAgIHNpbmdsZS1ydWxlID0gIlI9IiAo Ik4iIC8gIkEiIC8gIk8iKSAqKCxwb3J0KQoKCgoKQWRlbGwgICAgICAgICAgICAgICAgICAgIEV4 cGlyZXMgNyBPY3RvYmVyIDIwMjIgICAgICAgICAgICAgICAgIFtQYWdlIDVdCgwKSW50ZXJuZXQt RHJhZnQgICAgICAgICAgIENsaWVudCBSb2FtaW5nIENvbnRyb2wgICAgICAgICAgICAgICBBcHJp bCAyMDIyCgoKICAgbXVsdGlwbGUtcnVsZXMgPSB1bml0LXJ1bGUgMSoyKDt1bml0LXJ1bGUpCgog ICB1bml0LXJ1bGUgPSAiUj0iICgiTiIgLyAiQSIgLyAiTyIpIDEqKCxwb3J0KQoKICAgcG9ydCA9 IFsxLTldICooW0RJR0lUXSkKCjUuICBFeGFtcGxlcwoKICAgVGhlIGZvbGxvd2luZyBleGFtcGxl cyBzaG93IHNvbWUgdHlwaWNhbCB1c2VzIGV4cGVjdGVkIGZyb20gdGhpcwogICBkb2N1bWVudGF0 aW9uLiAgUGFydGljdWxhcmx5LCB0aGUgaW50ZW5kZWQgYmVoYXZpb3JzIGZvciBkaWZmZXJlbnQK ICAgQ1JDIGFuZCBDUlMgdmFsdWVzIGFyZSBleHBsYWluZWQsIHdoaWxlIHRoZSB1c2VyIGlkZW50 aWZpY2F0aW9uIGlzCiAgIGRvbmUgZGlyZWN0bHkgdGhyb3VnaCBjYXJyaWVkIGRhdGEgb3IgYSBk ZWR1Y3Rpb24gcHJvY2Vzcy4KCjUuMS4gIFJlc3RyaWN0ZWQgQXBwbGljYXRpb24KCiAgIEluIHRo aXMgZXhhbXBsZSwgYW4gYXBwbGljYXRpb24gaXMgb25seSBvcGVuZWQgdG8gb3JnYW5pemF0aW9u cwogICBwdWJsaXNoaW5nIHRoZWlyIHJlc3BlY3RpdmUgYWxsb3dlZCBuZXR3b3Jrcy4gIFRoZSBy ZXF1aXJlbWVudCB2YWx1ZQogICBvZiB0aGUgQ1JTIHJlY29yZCBlcXVhbHMgIkEiLCBhbmQgYW55 IG9yZ2FuaXphdGlvbiB3aXRoIGFuIGVtcHR5IG9yCiAgIG1pc3NpbmcgQ1JDIGZvciB0aGlzIGFw cGxpY2F0aW9uIHdpbGwgYmUgZGVuaWVkIGFjY2Vzcy4KCiAgIFRoZSBmdHAuZm9vLmNvbSBkb21h aW4gaXMgZGVkaWNhdGVkIHRvIGhvc3RpbmcgYW4gRlRQIGFwcGxpY2F0aW9uLAogICB3aGljaCBl eHRyYWN0cyB0aGUgY2xpZW50J3MgZG9tYWluIGZyb20gdGhlIHVzZXJuYW1lIHVzZWQgZHVyaW5n IHRoZQogICBhdXRoZW50aWNhdGlvbiBwcm9jZXNzLiAgVGhpcyBpbmZvcm1hdGlvbiBpcyB0aGVu IHVzZWQgZm9yIHJlcXVlc3RpbmcKICAgdGhlIGNsaWVudCBDUkMgcmVjb3JkIGFuZCBmaW5hbGx5 IGNvbXBhcmluZyBpdHMgY29udGVudCB3aXRoIHRoZQogICBjbGllbnQncyBJUC4gIFRoZSBjbGll bnQgb3JnYW5pemF0aW9uIGJhci5jb20gYWxsb3dzIGl0cyB1c2VycyBmcm9tCiAgIGl0cyBvd24g bmV0d29yayAxOTUuMTMuMzUuMC8yNCBhbmQgZnJvbSBhIGNsb3VkIHNlcnZpY2UgbG9jYXRlZCBh dAogICA5MS4yMjAuNDMuMC8yNC4gIEEgc2Vjb25kIG9yZ2FuaXphdGlvbiBiYXouY29tIGhhcyBu byBDUkMgcmVjb3JkIGFuZAogICBpdHMgdXNlcnMgYXJlIHJlamVjdGVkLgoKICAgQXBwbGljYXRp b24gRlFETiA6IGZ0cC5mb28uY29tCiAgIEFwcGxpY2F0aW9uIENSUyByZWNvcmQgOiBDUlMgUj1B LDIxCgogICBDbGllbnQgRlFETiA6IGJhci5jb20KICAgQ2xpZW50IG9yZ2FuaXphdGlvbiBDUkMg cmVjb3JkIDogQ1JDCiAgIGZ0cC5mb28uY29tXzIxX2Jhci5jb20sMTk1LjEzLjM1LjAvMjQsOTEu MjIwLjQzLjAvMjQKCiAgIENsaWVudCBGUUROIDogYmF6LmNvbQogICBObyBjbGllbnQgb3JnYW5p emF0aW9uIENSQyByZWNvcmQKCgoKCgoKCgoKCgoKCkFkZWxsICAgICAgICAgICAgICAgICAgICBF eHBpcmVzIDcgT2N0b2JlciAyMDIyICAgICAgICAgICAgICAgICBbUGFnZSA2XQoMCkludGVybmV0 LURyYWZ0ICAgICAgICAgICBDbGllbnQgUm9hbWluZyBDb250cm9sICAgICAgICAgICAgICAgQXBy aWwgMjAyMgoKCiAgIENsaWVudCBETlMgIENsaWVudCBGVFAgICAgICAgICAgICAgICAgU2VydmVy IEZUUAoKICAgICAgICAgICAgICAgICAgICAgRlRQIFVTRVIgbWVAYmFyLmNvbQogICAgICAgICAg ICAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLT4KICAgICAgICAgICAgICAgICAgICAg ICAgICAgIC4uLgogICAgICAgICAgICAgICAgICAgICBGVFAgUEFTUyAqKioqKioqKgogICAgICAg ICAgICAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLT4KICAgICAgICAgIFF1ZXJ5IDog Q1JDIGZ0cC5mb28uY29tXzIxX2Jhci5jb20KICAgICAgICA8LS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tCiAgICAgICAgICBBbnN3ZXIgOiBDUkMgZnRwLmZvby5jb21fMjFfYmFy LmNvbSwxOTUuMTMuMzUuMC8yNCw5MS4yMjAuNDMuMC8yNAogICAgICAgIC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLT4KICAgICAgICAgICAgICAgICAgICAgRlRQIDIzMAogICAg ICAgICAgICAgIDwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KCgogICAgICAgICAgICAg ICAgICAgICBGVFAgVVNFUiBtZUBiYXouY29tCiAgICAgICAgICAgICAgIC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tPgogICAgICAgICAgICAgICAgICAgICAgICAgICAgLi4uCiAgICAgICAg ICAgICAgICAgICAgIEZUUCBQQVNTICoqKioqKioqCiAgICAgICAgICAgICAgIC0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tPgogICAgICAgICAgUXVlcnkgOiBDUkMgZnRwLmZvby5jb21fMjFf YmF6LmNvbQogICAgICAgIDwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KICAg ICAgICAgIEFuc3dlciA6IE5vIHN1Y2ggbmFtZSAoMykKICAgICAgICAtLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0+CiAgICAgICAgICAgICAgICAgICAgIEZUUCA0MzAKICAgICAg ICAgICAgICA8LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCgo1LjIuICBDb250cm9sbGVk IEFwcGxpY2F0aW9uCgogICBUaGUgZm9vLmNvbSBkb21haW4gaG9zdHMgYSBXZWIgYXBwbGljYXRp b24gb24gcG9ydCA0NDMgdXNpbmcgY2xpZW50CiAgIGNlcnRpZmljYXRlcyBmb3IgYXV0aGVudGlj YXRpbmcgaXRzIHVzZXJzLiAgVGhlIGFwcGxpY2F0aW9uIGV4dHJhY3RzCiAgIHRoZSBjbGllbnQg ZG9tYWlucyBmcm9tIHRoZSBjZXJ0aWZpY2F0ZXMsIHdoaWNoIGFyZSB1c2VkIHRvIHJldHJpZXZl CiAgIHRoZWlyIENSQyByZWNvcmRzLiAgVXNlcnMgZnJvbSB0aGUgYmFyLmNvbSBvcmdhbml6YXRp b24gYXJlIGFsbG93ZWQKICAgb25seSBpZiB0aGV5IGNvbm5lY3QgZnJvbSBhbiBhdXRob3JpemVk IG5ldHdvcmsgbGlzdGVkIGluIHRoZSBDUkMKICAgcmVjb3JkLCB3aGlsZSB1c2VycyBmcm9tIGJh ei5jb20gYXJlIGFsd2F5cyBncmFudGVkIGFjY2VzcyBzaW5jZSB0aGlzCiAgIG9uZSBoYXMgbm8g Q1JDIGRlY2xhcmVkLgoKICAgQXBwbGljYXRpb24gRlFETiA6IGZvby5jb20KICAgQXBwbGljYXRp b24gQ1JTIHJlY29yZCA6IENSUyBSPUEsNDQzCgogICBDbGllbnQgRlFETiA6IGJhci5jb20KICAg Q2xpZW50IG9yZ2FuaXphdGlvbiBDUkMgcmVjb3JkIDogQ1JDCiAgIGZ0cC5mb28uY29tXzQ0M19i YXIuY29tLDE5NS4xMy4zNS4wLzI0LDkxLjIyMC40My4wLzI0CgogICBDbGllbnQgRlFETiA6IGJh ei5jb20KICAgTm8gY2xpZW50IG9yZ2FuaXphdGlvbiBDUkMgcmVjb3JkCgoKCgoKQWRlbGwgICAg ICAgICAgICAgICAgICAgIEV4cGlyZXMgNyBPY3RvYmVyIDIwMjIgICAgICAgICAgICAgICAgIFtQ YWdlIDddCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgIENsaWVudCBSb2FtaW5nIENvbnRyb2wg ICAgICAgICAgICAgICBBcHJpbCAyMDIyCgoKICAgQ2xpZW50IEROUyAgQ2xpZW50IGJyb3dzZXIg ICAgICAgICAgICAgICAgV2ViIGFwcGxpY2F0aW9uCgoKICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAuLi4uLgogICAgICAgICAgICAgICAgIENsaWVudCBjZXJ0aWZpY2F0ZSBtZUBiYXIuY29t CiAgICAgICAgICAgICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPgogICAg ICAgICAgUXVlcnkgOiBDUkMgZm9vLmNvbV80NDNfYmFyLmNvbQogICAgICAgIDwtLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KICAgICAgICAgIEFuc3dlciA6IENSQyBm b28uY29tXzQ0M19iYXIuY29tLDE5NS4xMy4zNS4wLzI0LDkxLjIyMC40My4wLzI0CiAgICAgICAg LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPgogICAgICAgICAgICAg ICAgICAgICAgICAgICAgIC4uLi4uCiAgICAgICAgICAgICAgICAgICAgIDIwMCBPSwogICAgICAg ICAgICAgICA8LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KCgogICAgICAgICAg ICAgICAgICAgICAgICAgICAgIC4uLi4uCiAgICAgICAgICAgICAgICAgQ2xpZW50IGNlcnRpZmlj YXRlIG1lQGJhei5jb20KICAgICAgICAgICAgICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0+CiAgICAgICAgICBRdWVyeSA6IENSQyBmb28uY29tXzQ0M19iYXouY29tCiAgICAg ICAgPC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQogICAgICAgICAg QW5zd2VyIDogTm8gc3VjaCBuYW1lICgzKQogICAgICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLT4KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAuLi4uLgog ICAgICAgICAgICAgICAgICAgICAyMDAgT0sKICAgICAgICAgICAgICAgPC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tCgo1LjMuICBPcGVuZWQgQXBwbGljYXRpb24KCiAgIEEgY29t cGFueSBpcyB0ZXN0aW5nIHRoZSBDUkMgYW5kIENSUyBiZWhhdmlvcnMgYmVmb3JlIG9wZW5pbmcg YSBuZXcKICAgc2VydmljZSB0byBpdHMgY3VzdG9tZXJzLiAgSXRzIGZpcnN0IHRlc3QgZGVzY3Jp YmVkIGJlbG93IGNvbnNpc3RzIGluCiAgIGNvbmZpZ3VyaW5nIGJvdGggc2lkZXMgdG8gYmUgY29t cGxldGVseSBvcGVuZWQsIGxpa2VseSBiZWZvcmUKICAgaGFyZGVuaW5nIHRoZSBDUlMsIHRoZW4g dGhlIENSQywgYW5kIHRlc3RpbmcgYWdhaW4uCgogICBUaGUgYXBwbGljYXRpb24uZm9vLmNvbSBk b21haW4gaG9zdHMgYSBXZWIgYXBwbGljYXRpb24gb24gcG9ydCA0NDMKICAgd2hlcmUgdXNlcnMg YXJlIGxvZ2dlZCBpbiBieSBzZW5kaW5nIGEgbnVtZXJpY2FsIGlkZW50aWZpZXIgYW5kIGEKICAg cGFzc3dvcmQuICBUaGUgYXBwbGljYXRpb24gdXNlcyBhIGRpY3Rpb25hcnkgZGF0YSB0eXBlIHRv IGlkZW50aWZ5CiAgIHRoZSB1c2VyJ3MgZG9tYWluLiAgVGhlIGNsaWVudC5mb28uY29tIGRvbWFp biBpcyB0ZW1wb3JhcmlseSB1c2luZyAyCiAgIENSQyByZWNvcmRzIGluZGljYXRpbmcgYSBmcmVl IGFjY2VzcyBmcm9tIGFueXdoZXJlLgoKICAgQXBwbGljYXRpb24gRlFETiA6IGFwcGxpY2F0aW9u LmZvby5jb20KICAgQXBwbGljYXRpb24gQ1JTIHJlY29yZCA6IENSUyBSPU4sNDQzCgogICBDbGll bnQgRlFETiA6IGNsaWVudC5mb28uY29tCiAgIENsaWVudCBvcmdhbml6YXRpb24gQ1JDIHJlY29y ZHMgOiBDUkMKICAgYXBwbGljYXRpb24uZm9vLmNvbV80NDNfZm9vLmNvbSwwLjAuMC4wLzI0OyBD UkMKICAgYXBwbGljYXRpb24uZm9vLmNvbV80NDNfZm9vLmNvbSxmZTgwOjovMTAKCgoKCgpBZGVs bCAgICAgICAgICAgICAgICAgICAgRXhwaXJlcyA3IE9jdG9iZXIgMjAyMiAgICAgICAgICAgICAg ICAgW1BhZ2UgOF0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgQ2xpZW50IFJvYW1pbmcgQ29u dHJvbCAgICAgICAgICAgICAgIEFwcmlsIDIwMjIKCgogICBDbGllbnQgRE5TICBDbGllbnQgYnJv d3NlciAgICAgICAgICAgICAgICBXZWIgYXBwbGljYXRpb24KCgogICAgICAgICAgICAgICAgICAg ICAgICAgICAgIC4uLi4uCiAgICAgICAgICAgICAgICAgSFRUUCBQT1NUIDEyMzQ1Ni8qKioqKioK ICAgICAgICAgICAgICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0+CiAgICAg ICAgICAgICAgICAgICAgIDIwMCBPSwogICAgICAgICAgICAgICA8LS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0KCjYuICBJQU5BIENvbnNpZGVyYXRpb25zCgogICBBY2NvcmRpbmcg dG8gR3VpZGVsaW5lcyBmb3IgV3JpdGluZyBhbiBJQU5BIENvbnNpZGVyYXRpb25zIFNlY3Rpb24g aW4KICAgUkZDcyBbUkZDODEyNl0gaXQgaXMgYXNrZWQgdG8gSUFOQSB0byBhZGQgaW50byB0aGUg UmVzb3VyY2UgUmVjb3JkCiAgIChSUikgVFlQRXMgcmVnaXN0cnkgbG9jYXRlZCBhdCBodHRwczov L3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9kbnMtCiAgIHBhcmFtZXRlcnMvZG5zLXBhcmFtZXRl cnMueGh0bWwjZG5zLXBhcmFtZXRlcnMtNCB0aGUgdHdvIGVudHJpZXMgQ1JDCiAgIGFuZCBDUlMu CgogICAgICAgICAgICstLS0tLS0rLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0t LS0tLS0tLS0rCiAgICAgICAgICAgfCBUWVBFIHwgVmFsdWUgfCBEZXNjcmlwdGlvbiAgICAgICAg ICAgIHwgUmVmZXJlbmNlIHwKICAgICAgICAgICArLS0tLS0tKy0tLS0tLS0rLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tKwogICAgICAgICAgIHwgQ1JDICB8IFRCRDEgIHwgQ2xp ZW50IFJvYW1pbmcgQ29udHJvbCB8IHRoaXMgUkZDICB8CiAgICAgICAgICAgKy0tLS0tLSstLS0t LS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLSsKICAgICAgICAgICB8IENS UyAgfCBUQkQyICB8IENsaWVudCBSb2FtaW5nIFN1cHBvcnQgfCB0aGlzIFJGQyAgfAogICAgICAg ICAgICstLS0tLS0rLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0r CgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVGFibGUgMQoKNy4gIFNlY3VyaXR5 IENvbnNpZGVyYXRpb25zCgogICBUaGlzIHNlY3Rpb24gaXMgbWVhbnQgdG8gaW5mb3JtIGRldmVs b3BlcnMgYW5kIHVzZXJzIG9mIHRoZSBzZWN1cml0eQogICBpbXBsaWNhdGlvbnMgb2YgdGhlIENS Qy9DUlMgbWVjaGFuaXNtIGRlc2NyaWJlZCBieSB0aGlzIGRvY3VtZW50LgogICBXaGlsZSB0aGUg Q1JTIFJSIG1vc3RseSBwbGF5cyBhbiBpbmZvcm1hdGl2ZSByb2xlLCB0aGUgQ1JDIFJSCiAgIGRl bGl2ZXJzIGltcG9ydGFudCBkYXRhIHdoaWNoIHJlcXVpcmVzIGF0dGVudGlvbiBmcm9tIHRoZSBk ZXZlbG9wZXJzCiAgIGFuZCBhZG1pbmlzdHJhdG9ycy4gIFNvbWUgcGFydGljdWxhciBwb2ludHMg YXJlIGRpc2N1c3NlZCBoZXJlLgoKNy4xLiAgRE5TIG1pc2NvbmZpZ3VyYXRpb24KCiAgIEFueSBE TlMgQ1JTIG1pc2NvbmZpZ3VyYXRpb24gc3VjaCBhcyBtdWx0aXBsZSByZWNvcmRzIHdpdGggZGlm ZmVyZW50CiAgIHJlcXVpcmVtZW50IHZhbHVlcyBidXQgd2l0aCB0aGUgc2FtZSBwb3J0IHZhbHVl IGNhbiBnZXQgYSBjbGllbnQKICAgY29uZnVzZWQuICBJbiB0aGlzIGNhc2UgdGhlIGNsaWVudCBk b2VzIG5vdCBrbm93IHdpdGhvdXQgdGVzdGluZyB0aGUKICAgYWN0dWFsIGNvbmZpZ3VyYXRpb24s IGlmIGl0cyBvcmdhbml6YXRpb24gaXMgcHJvdGVjdGVkIGFnYWluc3QKICAgcm9hbWluZywgYW5k IGNvbnRhY3RpbmcgdGhlIGFwcGxpY2F0aW9uIGFkbWluaXN0cmF0b3IgdG8gZml4IHRoZQogICBz aXR1YXRpb24gaXMgYSBwb3NzaWJpbGl0eS4KCiAgIFdoaWxlIENSQyBtaXNjb25maWd1cmF0aW9u cyBhcmUgbW9yZSBvciBsZXNzIGxlYWRpbmcgdG8gc2VyaW91cwogICBzZWN1cml0eSBwcm9ibGVt cywgYWRtaW5pc3RyYXRvcnMgbmVlZCB0byBwYXkgYXR0ZW50aW9uIHdoZW4gZGVhbGluZwogICB3 aXRoIG11bHRpcGxlIG5ldHdvcmtzIG9yIHJlY29yZHMuICBQYXJ0aWN1bGFybHksIG11bHRpcGxl IHJlY29yZHMKICAgZm9yIHRoZSBzYW1lIG5ldHdvcmsgcmFuZ2Ugb3Igb3ZlcmxhcHBpbmcgbmV0 d29ya3Mgc2hvdWxkIGJlIGF2b2lkZWQuCgoKCkFkZWxsICAgICAgICAgICAgICAgICAgICBFeHBp cmVzIDcgT2N0b2JlciAyMDIyICAgICAgICAgICAgICAgICBbUGFnZSA5XQoMCkludGVybmV0LURy YWZ0ICAgICAgICAgICBDbGllbnQgUm9hbWluZyBDb250cm9sICAgICAgICAgICAgICAgQXByaWwg MjAyMgoKCjcuMi4gIEROUyBTZWN1cml0eQoKICAgQ2xpZW50IGFuZCBhcHBsaWNhdGlvbiBhZG1p bmlzdHJhdG9ycyBuZWVkIHRvIHBheSBhcyBtdWNoIGF0dGVudGlvbgogICBhcyB0aGV5IHVzdWFs bHkgZG8gd2hlbiBkZWFsaW5nIHdpdGggRE5TIG1hbmFnZW1lbnQuICBBcyB0aGUgQ1JDCiAgIHJl Y29yZHMgYXJlIHN1cHBvc2VkIHRvIGJlIHJlcXVlc3RlZCBkdXJpbmcgYW4gYXBwbGljYXRpb24K ICAgYXV0aGVudGljYXRpb24gcHJvY2VzcywgcmVmbGVjdGlvbiBhdHRhY2tzIGNvdWxkIGJlIGJ1 aWx0IHRvIHRhcmdldCBhCiAgIGNsaWVudCBvcmdhbml6YXRpb24sIGV2ZW4gb25lIG5vdCBob3N0 aW5nIGFueSBDUkMgcmVjb3JkIGF0IGFsbC4KICAgSW4gYSBnZW5lcmFsIG1hbm5lciwgYWRtaW5p c3RyYXRvcnMgbWF5IGNvbnNpZGVyIGFuIGFkZXF1YXRlIFRUTAogICBzZXR0aW5nIHRvIG5vdCBv dmVybG9hZCBjbGllbnQgb3JnYW5pemF0aW9ucywgZW5hYmxlIFRDUCBhcyB0aGUKICAgcHJlZmVy cmVkIHRyYW5zcG9ydCwgb3IgcmVseSBvbiBETlNTRUMgdG8gd2FycmFudCBkYXRhIGF1dGhlbnRp Y2l0eQogICBhbmQgaW50ZWdyaXR5LgoKNy4zLiAgQXBwbGljYXRpb24gU2VjdXJpdHkKCiAgIFRo ZSBmb2xsb3dpbmcgcG9pbnRzIGFyZSBvZiBjb25jZXJuIHRvIGRldmVsb3BlcnM6CgogICBFbmNy eXB0aW9uOgogICBXaGVuZXZlciBwb3NzaWJsZSwgdGhlIGFwcGxpY2F0aW9uIHByb3RvY29sIHNo b3VsZCBiZSBlbmNyeXB0ZWQgdG8KICAgcHJldmVudCBlYXZlc2Ryb3BwaW5nIGFuZCBtYW4taW4t dGhlLW1pZGRsZSBhdHRhY2tzLiAgSXQgaXMgYQogICBjcml0aWNhbCBwb2ludCBmb3IgYXBwbGlj YXRpb25zIG1haW50YWluaW5nIGEgdXNlciBzZXNzaW9uIHdpdGgKICAgYW55dGhpbmcgbGlrZSBh IHRva2VuIG9yIGNvb2tpZSwgYXMgaXQgY2FuIGxlYWQgdG8gc2Vzc2lvbiBoaWphY2tpbmcKICAg YXMgZGlzY3Vzc2VkIGJlbG93LgoKICAgVGltaW5nIGF0dGFjazoKICAgQWxsIGF1dGhlbnRpY2F0 aW9uIHN5c3RlbXMgbmVlZCB0byBiZSBjYXJlZnVsIHRvIG5vdCBkZWxpdmVyIGFueQogICBpbmZv cm1hdGlvbiBkZXJpdmVkIGZyb20gdGhlIGNvbXB1dGluZyB0aW1lIHRvIGEgZGVuaWVkIHVzZXIs IGV2ZW4KICAgdGhlIG9uZXMgaW52b2x2aW5nIG11bHRpcGxlIGZhY3RvcnMgb3Igc3RlcHMgbGlr ZSB0aGUgb25lIGRlc2NyaWJlZAogICBpbiB0aGlzIGRvY3VtZW50LiAgSW4gcGFydGljdWxhciwg dGhlIG9yZGVyIGluIHdoaWNoIHRoZXNlIHN0ZXBzIGFyZQogICBleGVjdXRlZCBhbmQgdGhlaXIg cmVzcGVjdGl2ZSBpbXBsZW1lbnRhdGlvbnMsIG5lZWQgdG8gZGVmZWF0CiAgIHN0YXRpc3RpY2Fs IGh5cG90aGVzZXMuCgogICBJbnRlcm1lZGlhdGUgc3lzdGVtczoKICAgU29tZSBhcHBsaWNhdGlv bnMgYXJlIG5vdCBkaXJlY3RseSBJbnRlcm5ldCBmYWNpbmcgYW5kIGNhbm5vdCBhY2Nlc3MKICAg dG8gdGhlIHJlYWwgY2xpZW50J3MgSVAgYWRkcmVzcyB3aXRob3V0IGludm9sdmluZyBhIG1lY2hh bmlzbSB0bwogICBmb3J3YXJkIHRoaXMgSVAgYXQgdGhlIGFwcGxpY2F0aW9uIGxheWVyLiAgRm9y IGV4YW1wbGUgd2l0aCBIVFRQLCB0aGUKICAgY29tbW9uIHByYWN0aWNlIGJhc2VkIG9uIHRoZSBu b24tc3RhbmRhcmQgWC1Gb3J3YXJkZWQtRm9yIGhlYWRlciwgb3IKICAgaXRzIGFsdGVybmF0aXZl IHN0YW5kYXJkIEZvcndhcmRlZCBbUkZDNzIzOV0sIGFyZSBwbGF5aW5nIHRoaXMgcm9sZS4KICAg U3VjaCBwcmFjdGljZSByZXF1aXJlcyBhIGNvcnJlY3Qgc2FuaXRpemluZyBvZiB1c2VyIGRhdGEg dG8gYXZvaWQKICAgZmFsc2UgaW5qZWN0ZWQgSVBzLgoKICAgU2Vzc2lvbiBoaWphY2tpbmc6CiAg IEEgd2VsbC1rbm93biBhdHRhY2sgY2FsbGVkIFNlc3Npb24gSGlqYWNraW5nIGlzIG5vdCBtZWFu dCB0byBiZQogICBkZWZlYXRlZCBieSB0aGlzIGRvY3VtZW50IGFsb25lLiAgQXBwbGljYXRpb24g ZGV2ZWxvcGVycyBtdXN0IGVuc3VyZQogICB0aGF0IGFueSByZWNldmVpZCBzZXNzaW9uIHRva2Vu LCBzdWNoIGFzIGFuIEhUVFAgQ29va2llLCBiZWxvbmdzIHRvCiAgIHRoZSBzYW1lIElQIGFkZHJl c3MgdGhhbiB0aGUgb25lIHdoaWNoIHN0YXJ0ZWQgdGhpcyBzZXNzaW9uLgoKOC4gIFJlZmVyZW5j ZXMKCgoKCkFkZWxsICAgICAgICAgICAgICAgICAgICBFeHBpcmVzIDcgT2N0b2JlciAyMDIyICAg ICAgICAgICAgICAgIFtQYWdlIDEwXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICBDbGllbnQg Um9hbWluZyBDb250cm9sICAgICAgICAgICAgICAgQXByaWwgMjAyMgoKCjguMS4gIE5vcm1hdGl2 ZSBSZWZlcmVuY2VzCgogICBbUkZDMTAzNV0gIE1vY2thcGV0cmlzLCBQLiwgIkRvbWFpbiBuYW1l cyAtIGltcGxlbWVudGF0aW9uIGFuZAogICAgICAgICAgICAgIHNwZWNpZmljYXRpb24iLCBTVEQg MTMsIFJGQyAxMDM1LCBET0kgMTAuMTc0ODcvUkZDMTAzNSwKICAgICAgICAgICAgICBOb3ZlbWJl ciAxOTg3LCA8aHR0cHM6Ly93d3cucmZjLWVkaXRvci5vcmcvaW5mby9yZmMxMDM1Pi4KCiAgIFtS RkMyMTE5XSAgQnJhZG5lciwgUy4sICJLZXkgd29yZHMgZm9yIHVzZSBpbiBSRkNzIHRvIEluZGlj YXRlCiAgICAgICAgICAgICAgUmVxdWlyZW1lbnQgTGV2ZWxzIiwgQkNQIDE0LCBSRkMgMjExOSwK ICAgICAgICAgICAgICBET0kgMTAuMTc0ODcvUkZDMjExOSwgTWFyY2ggMTk5NywKICAgICAgICAg ICAgICA8aHR0cHM6Ly93d3cucmZjLWVkaXRvci5vcmcvaW5mby9yZmMyMTE5Pi4KCiAgIFtSRkMz OTg2XSAgQmVybmVycy1MZWUsIFQuLCBGaWVsZGluZywgUi4sIGFuZCBMLiBNYXNpbnRlciwgIlVu aWZvcm0KICAgICAgICAgICAgICBSZXNvdXJjZSBJZGVudGlmaWVyIChVUkkpOiBHZW5lcmljIFN5 bnRheCIsIFNURCA2NiwKICAgICAgICAgICAgICBSRkMgMzk4NiwgRE9JIDEwLjE3NDg3L1JGQzM5 ODYsIEphbnVhcnkgMjAwNSwKICAgICAgICAgICAgICA8aHR0cHM6Ly93d3cucmZjLWVkaXRvci5v cmcvaW5mby9yZmMzOTg2Pi4KCiAgIFtSRkM0MjkxXSAgSGluZGVuLCBSLiBhbmQgUy4gRGVlcmlu ZywgIklQIFZlcnNpb24gNiBBZGRyZXNzaW5nCiAgICAgICAgICAgICAgQXJjaGl0ZWN0dXJlIiwg UkZDIDQyOTEsIERPSSAxMC4xNzQ4Ny9SRkM0MjkxLCBGZWJydWFyeQogICAgICAgICAgICAgIDIw MDYsIDxodHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9pbmZvL3JmYzQyOTE+LgoKICAgW1JGQzUy MzRdICBDcm9ja2VyLCBELiwgRWQuIGFuZCBQLiBPdmVyZWxsLCAiQXVnbWVudGVkIEJORiBmb3Ig U3ludGF4CiAgICAgICAgICAgICAgU3BlY2lmaWNhdGlvbnM6IEFCTkYiLCBTVEQgNjgsIFJGQyA1 MjM0LAogICAgICAgICAgICAgIERPSSAxMC4xNzQ4Ny9SRkM1MjM0LCBKYW51YXJ5IDIwMDgsCiAg ICAgICAgICAgICAgPGh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZjNTIzND4uCgog ICBbUkZDODE3NF0gIExlaWJhLCBCLiwgIkFtYmlndWl0eSBvZiBVcHBlcmNhc2UgdnMgTG93ZXJj YXNlIGluIFJGQwogICAgICAgICAgICAgIDIxMTkgS2V5IFdvcmRzIiwgQkNQIDE0LCBSRkMgODE3 NCwgRE9JIDEwLjE3NDg3L1JGQzgxNzQsCiAgICAgICAgICAgICAgTWF5IDIwMTcsIDxodHRwczov L3d3dy5yZmMtZWRpdG9yLm9yZy9pbmZvL3JmYzgxNzQ+LgoKOC4yLiAgSW5mb3JtYXRpdmUgUmVm ZXJlbmNlcwoKICAgW1JGQzcyMzldICBQZXRlcnNzb24sIEEuIGFuZCBNLiBOaWxzc29uLCAiRm9y d2FyZGVkIEhUVFAgRXh0ZW5zaW9uIiwKICAgICAgICAgICAgICBSRkMgNzIzOSwgRE9JIDEwLjE3 NDg3L1JGQzcyMzksIEp1bmUgMjAxNCwKICAgICAgICAgICAgICA8aHR0cHM6Ly93d3cucmZjLWVk aXRvci5vcmcvaW5mby9yZmM3MjM5Pi4KCiAgIFtSRkM4NDk5XSAgSG9mZm1hbiwgUC4sIFN1bGxp dmFuLCBBLiwgYW5kIEsuIEZ1aml3YXJhLCAiRE5TCiAgICAgICAgICAgICAgVGVybWlub2xvZ3ki LCBCQ1AgMjE5LCBSRkMgODQ5OSwgRE9JIDEwLjE3NDg3L1JGQzg0OTksCiAgICAgICAgICAgICAg SmFudWFyeSAyMDE5LCA8aHR0cHM6Ly93d3cucmZjLWVkaXRvci5vcmcvaW5mby9yZmM4NDk5Pi4K CkF1dGhvcidzIEFkZHJlc3MKCiAgIEV1Z2VuZSBBZGVsbAogICBFbWFpbDogZXVnZW5lLmFkZWxs QGdtYWlsLmNvbQoKCgoKCgoKCkFkZWxsICAgICAgICAgICAgICAgICAgICBFeHBpcmVzIDcgT2N0 b2JlciAyMDIyICAgICAgICAgICAgICAgIFtQYWdlIDExXQo= --000000000000878e2505dbe63d44 Content-Type: text/plain; charset="US-ASCII"; name="RFC 6895 material.txt" Content-Disposition: attachment; filename="RFC 6895 material.txt" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_l1m0sank1 QS4gU3VibWlzc2lvbiBEYXRlOjIwMDIvMDQvMDUNCkIuMSBTdWJtaXNzaW9uIFR5cGU6ICBbWF0g TmV3IFJSVFlQRSAgWyBdIE1vZGlmaWNhdGlvbiB0byBSUlRZUEUNCkIuMiBLaW5kIG9mIFJSOiAg W1hdIERhdGEgUlIgIFsgXSBNZXRhLVJSDQpDLiBDb250YWN0IEluZm9ybWF0aW9uIGZvciBzdWJt aXR0ZXIgOg0KICAgTmFtZTogRXVnZW5lIEFkZWxsICAgICAgICAgICAgICAgRW1haWwgQWRkcmVz czogZXVnZW5lLmFkZWxsQGdtYWlsLmNvbQ0KICAgSW50ZXJuYXRpb25hbCB0ZWxlcGhvbmUgbnVt YmVyOiArMzM2OTkwNTY5MTQNCiAgIE90aGVyIGNvbnRhY3QgaGFuZGxlczoNCkQuIE1vdGl2YXRp b24gZm9yIHRoZSBuZXcgUlJUWVBFIGFwcGxpY2F0aW9uLg0KICAgSW50cm9kdWNlIGEgY291cGxl IG9mIFJSIHR5cGVzIHdvcmtpbmcgdG9nZXRoZXIgaW4gb3JkZXIgdG8gYmV0dGVyIHNlY3VyZSBy ZW1vdGUgYWNjZXNzIHRvIHBhcnRuZXIgYXBwbGljYXRpb25zDQpFLiBEZXNjcmlwdGlvbiBvZiB0 aGUgcHJvcG9zZWQgUlIgdHlwZS4NCiAgIENSQyBjb250YWlucyBhIGxpbWl0ZWQgbGlzdCBvZiBh dXRob3JpemVkIG5ldHdvcmtzIGZvciBhIHBhcnRpY3VsYXIgYXBwbGljYXRpb24NCkYuIFdoYXQg ZXhpc3RpbmcgUlJUWVBFIG9yIFJSVFlQRXMgY29tZSBjbG9zZXN0IHRvIGZpbGxpbmcgdGhhdCBu ZWVkIGFuZCB3aHkgYXJlIHRoZXkgdW5zYXRpc2ZhY3Rvcnk/DQogICBUWFQgUlJUWVBFIGFsbG93 cyB0aGUgc3RvcmFnZSBvZiBhbnkgdGV4dCBkYXRhIGJ1dCBpbiBwcmFjdGljZSBpcyB1c3VhbGx5 IGFzc29jaWF0ZWQgd2l0aCBtb3JlIG9yIGxlc3MgZml4ZWQgbmFtZSBvciBkYXRhIHdoaWNoIGlz IG5vdCB3aGF0IGlzIG5lZWRlZCBoZXJlLiBBIGRlZGljYXRlZCBSUlRZUEUgaXMgZWFzaWVyIHRv IGlkZW50aWZ5IGFuZCBtYW5hZ2UgYnkgYSBzZWN1cml0eSB0ZWFtIG90aGVyIHRoYW4gdGhlIHVz dWFsIEROUyBvcGVyYXRvciB0ZWFtLg0KRy4gV2hhdCBtbmVtb25pYyBpcyByZXF1ZXN0ZWQgZm9y IHRoZSBuZXcgUlJUWVBFIChvcHRpb25hbCk/DQogICBDUkMNCkguIERvZXMgdGhlIHJlcXVlc3Rl ZCBSUlRZUEUgbWFrZSB1c2Ugb2YgYW55IGV4aXN0aW5nIElBTkEgcmVnaXN0cnkgb3IgcmVxdWly ZSB0aGUgY3JlYXRpb24gb2YgYSBuZXcgSUFOQSBzdWJyZWdpc3RyeSBpbiBETlMgUGFyYW1ldGVy cz8NCiAgIEl0IHVzZXMgdGhlIGV4aXN0aW5nIFJlc291cmNlIFJlY29yZCAoUlIpIFRZUEVzIHJl Z2lzdHJ5DQpJLiBEb2VzIHRoZSBwcm9wb3NhbCByZXF1aXJlL2V4cGVjdCBhbnkgY2hhbmdlcyBp biBETlMgc2VydmVycy9yZXNvbHZlcnMgdGhhdCBwcmV2ZW50IHRoZSBuZXcgdHlwZSBmcm9tIGJl aW5nIHByb2Nlc3NlZCBhcyBhbiB1bmtub3duIFJSVFlQRSAoc2VlIFtSRkMzNTk3XSk/DQogICBO bw0KSi4gQ29tbWVudHM6DQogICBOb25lDQoNCg0KQS4gU3VibWlzc2lvbiBEYXRlOjIwMDIvMDQv MDUNCkIuMSBTdWJtaXNzaW9uIFR5cGU6ICBbWF0gTmV3IFJSVFlQRSAgWyBdIE1vZGlmaWNhdGlv biB0byBSUlRZUEUNCkIuMiBLaW5kIG9mIFJSOiAgW1hdIERhdGEgUlIgIFsgXSBNZXRhLVJSDQpD LiBDb250YWN0IEluZm9ybWF0aW9uIGZvciBzdWJtaXR0ZXIgOg0KICAgTmFtZTogRXVnZW5lIEFk ZWxsICAgICAgICAgICAgICAgRW1haWwgQWRkcmVzczogZXVnZW5lLmFkZWxsQGdtYWlsLmNvbQ0K ICAgSW50ZXJuYXRpb25hbCB0ZWxlcGhvbmUgbnVtYmVyOiArMzM2OTkwNTY5MTQNCiAgIE90aGVy IGNvbnRhY3QgaGFuZGxlczoNCkQuIE1vdGl2YXRpb24gZm9yIHRoZSBuZXcgUlJUWVBFIGFwcGxp Y2F0aW9uLg0KICAgSW50cm9kdWNlIGEgY291cGxlIG9mIFJSIHR5cGVzIHdvcmtpbmcgdG9nZXRo ZXIgaW4gb3JkZXIgdG8gYmV0dGVyIHNlY3VyZSByZW1vdGUgYWNjZXNzIHRvIHBhcnRuZXIgYXBw bGljYXRpb25zDQpFLiBEZXNjcmlwdGlvbiBvZiB0aGUgcHJvcG9zZWQgUlIgdHlwZS4NCiAgIENS UyBjb250YWlucyBhIHJlcXVpcmVtZW50IHZhbHVlIGFuZCBhIGxpc3Qgb2YgcG9ydHMgaW5kaWNh dGluZyB3aGF0IGtpbmQgb2YgYXV0aG9yaXphdGlvbiBjaGVjayBpcyBkb25lIGR1cmluZyB0aGUg YXBwbGljYXRpb24gYXV0aGVudGljYXRpb24gcHJvY2Vzcw0KRi4gV2hhdCBleGlzdGluZyBSUlRZ UEUgb3IgUlJUWVBFcyBjb21lIGNsb3Nlc3QgdG8gZmlsbGluZyB0aGF0IG5lZWQgYW5kIHdoeSBh cmUgdGhleSB1bnNhdGlzZmFjdG9yeT8NCiAgIFRYVCBSUlRZUEUgYWxsb3dzIHRoZSBzdG9yYWdl IG9mIGFueSB0ZXh0IGRhdGEgYnV0IGluIHByYWN0aWNlIGlzIHVzdWFsbHkgYXNzb2NpYXRlZCB3 aXRoIG1vcmUgb3IgbGVzcyBmaXhlZCBuYW1lIG9yIGRhdGEgd2hpY2ggaXMgbm90IHdoYXQgaXMg bmVlZGVkIGhlcmUuIEEgZGVkaWNhdGVkIFJSVFlQRSBpcyBlYXNpZXIgdG8gaWRlbnRpZnkgYW5k IG1hbmFnZSBieSBhIHNlY3VyaXR5IHRlYW0gb3RoZXIgdGhhbiB0aGUgdXN1YWwgRE5TIG9wZXJh dG9yIHRlYW0uDQpHLiBXaGF0IG1uZW1vbmljIGlzIHJlcXVlc3RlZCBmb3IgdGhlIG5ldyBSUlRZ UEUgKG9wdGlvbmFsKT8NCiAgIENSUw0KSC4gRG9lcyB0aGUgcmVxdWVzdGVkIFJSVFlQRSBtYWtl IHVzZSBvZiBhbnkgZXhpc3RpbmcgSUFOQSByZWdpc3RyeSBvciByZXF1aXJlIHRoZSBjcmVhdGlv biBvZiBhIG5ldyBJQU5BIHN1YnJlZ2lzdHJ5IGluIEROUyBQYXJhbWV0ZXJzPw0KICAgSXQgdXNl cyB0aGUgZXhpc3RpbmcgUmVzb3VyY2UgUmVjb3JkIChSUikgVFlQRXMgcmVnaXN0cnkNCkkuIERv ZXMgdGhlIHByb3Bvc2FsIHJlcXVpcmUvZXhwZWN0IGFueSBjaGFuZ2VzIGluIEROUyBzZXJ2ZXJz L3Jlc29sdmVycyB0aGF0IHByZXZlbnQgdGhlIG5ldyB0eXBlIGZyb20gYmVpbmcgcHJvY2Vzc2Vk IGFzIGFuIHVua25vd24gUlJUWVBFIChzZWUgW1JGQzM1OTddKT8NCiAgIE5vDQpKLiBDb21tZW50 czoNCiAgIE5vbmU= --000000000000878e2505dbe63d44-- From nobody Tue Apr 5 06:53:47 2022 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 AF9E73A07F1 for ; Tue, 5 Apr 2022 06:53:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.107 X-Spam-Level: X-Spam-Status: No, score=-7.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 zKHAPxwogF6p for ; Tue, 5 Apr 2022 06:53:34 -0700 (PDT) Received: from mail-il1-x12f.google.com (mail-il1-x12f.google.com [IPv6:2607:f8b0:4864:20::12f]) (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 2E7643A07E3 for ; Tue, 5 Apr 2022 06:53:34 -0700 (PDT) Received: by mail-il1-x12f.google.com with SMTP id m17so5224142ilj.13 for ; Tue, 05 Apr 2022 06:53:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JD4H1Iap+DiOd0EKGqNcTJhk8XEv7I2EQBVN80XWFa0=; b=jUqnlNhB4uDn0nq6yP51N8tfuWr3zEo/A56PWV0tFbEsEVFDIen9mDwKDzQwC1hgPI SK3399s/KLZlUjLPG1X92H6VJHDp82oUiuYTpexagMKeAh3hFZ7hZKl6UrlRR62E1T9j r/HKtgrBzRzGcf0DtNuJPjj01Qbg4LJkOX6jtQHH5mzn/6UL3hBtvfw53sisvoxJZ860 YVsg2Z0ro9lCdfEH6kwEEzRy5FSxEidpyGqV7xAcw7m6VtLme1KGRprAAb8b6Pnn5cae kTeTKO4vkI5lyvVbbD+0EdrEijsCpW2F4HFTHa9y8boYIiBGdRsW7uOY5lZdc29d5dXg cVOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JD4H1Iap+DiOd0EKGqNcTJhk8XEv7I2EQBVN80XWFa0=; b=2V7W1ANg9WYGTF8wHI9QDfY1B8tgy6WyfhUBZoZFW6ecz5Hn8cldoILQCioyOcf3Eb 9D/hF22kC6nbHpLdTF64qDYw/OUBecz2KbsyWdclGD80nnr+JIIGsH2k49gVnBxW4kDH 9SWS87TJLvPEm6+naIuhyFZUJzbOtW0NcEyJY9UyxhMwnh8QdtM0L1M/vQRM4Qae+MA6 GtftJj4xUVf0hCAjH9qJAoNEdPPhVKS3D30AyGwNRUtT87ReShVK10RQg3pLa0f41BtT UmqEHUsdxf2pE5ggiZ4wcFRt7/nBqWvuYvjAD4W9ah3jj42vAkS+xPRfvp8Br66kyZ6y Dxng== X-Gm-Message-State: AOAM53068HqVi5Kurj5xwSEsghNEC6Phw+8pS3BGIwD4oT9z10iOnv66 SeTR62Qv2Bn+vb6LUY9w8MKFUtaDRVtW+VLtXWk= X-Google-Smtp-Source: ABdhPJwQ6em3UfvsZ5wy7BTkJEcDL98SMnmVIHnQYr/N0rbVGW1qMcts6X+tfrUK+AXLq7LLTKQ20hYDpMJaiVBJ2B4= X-Received: by 2002:a05:6e02:1885:b0:2ca:3f9e:dc07 with SMTP id o5-20020a056e02188500b002ca3f9edc07mr1809885ilu.28.1649166812945; Tue, 05 Apr 2022 06:53:32 -0700 (PDT) MIME-Version: 1.0 References: <93c34015-f441-20a3-b2b0-54159a70d021@NLnetLabs.nl> In-Reply-To: From: Shumon Huque Date: Tue, 5 Apr 2022 09:53:21 -0400 Message-ID: To: Peter Thomassen Cc: "dnsop@ietf.org WG" Content-Type: multipart/alternative; boundary="0000000000000fa6f205dbe89261" Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-wisser-dnssec-automation X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2022 13:53:46 -0000 --0000000000000fa6f205dbe89261 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I support the adoption of this draft and commit to working on it. I think this is a useful complement to RFC 8901, outlining the precise sequence of steps needed to successfully deploy a multi-signer configuration, and/or transfer a zone across providers using multi-signer as an intermediate state. Shumon On Sat, Apr 2, 2022 at 9:50 AM Peter Thomassen wrote: > I reviewed the draft and think it is suitable for adoption. I'm willing > to contribute text and reviews. > > ~Peter > > > On 3/25/22 16:35, Benno Overeinder wrote: > > As with the previous Call for Adoption today, at this week's DNSOP > meeting at IETF 113, we announced that we are initiating a Call for > Adoption for the draft-wisser-dnssec-automation. With the survey we > conducted for the last IETF 112, this draft was also a clear candidate. > > > > With this email we start a period of two weeks for the call for adoptio= n > of draft-wisser-dnssec-automation on the mailing list. > > > > The draft is available here: > https://datatracker.ietf.org/doc/draft-wisser-dnssec-automation/. > > > > Please review this draft to see if you think it is suitable for adoptio= n > by DNSOP, and comments to the list, clearly stating your view. > > > > Please also indicate if you are willing to contribute text, review, etc= . > > > > This call for adoption ends: 8 April 2022 > > > > Thanks, > > > > Suzanne, Tim and Benno > > > > _______________________________________________ > > DNSOP mailing list > > DNSOP@ietf.org > > https://www.ietf.org/mailman/listinfo/dnsop > > -- > Like our community service? =F0=9F=92=9B > Please consider donating at > > https://desec.io/ > > deSEC e.V. > Kyffh=C3=A4userstr. 5 > 10781 Berlin > Germany > > Vorstandsvorsitz: Nils Wisiol > Registergericht: AG Berlin (Charlottenburg) VR 37525 > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > --0000000000000fa6f205dbe89261 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I support the adoption of this draft and commit to wo= rking on it. I think this is a
useful complement to RFC 8901, out= lining the precise sequence of steps needed
to successfully deplo= y a multi-signer configuration, and/or transfer a zone across
pro= viders using multi-signer as an intermediate state.

Shumon

On Sat, Apr 2, 2022 at 9:50 AM Peter Thomassen <peter@desec.io> wrote:
I reviewed the draft and think it is su= itable for adoption. I'm willing to=C2=A0 contribute text and reviews.<= br>
~Peter


On 3/25/22 16:35, Benno Overeinder wrote:
> As with the previous Call for Adoption today, at this week's DNSOP= meeting at IETF 113, we announced that we are initiating a Call for Adopti= on for the draft-wisser-dnssec-automation.=C2=A0 With the survey we conduct= ed for the last IETF 112, this draft was also a clear candidate.
>
> With this email we start a period of two weeks for the call for adopti= on of draft-wisser-dnssec-automation on the mailing list.
>
> The draft is available here: ht= tps://datatracker.ietf.org/doc/draft-wisser-dnssec-automation/.
>
> Please review this draft to see if you think it is suitable for adopti= on by DNSOP, and comments to the list, clearly stating your view.
>
> Please also indicate if you are willing to contribute text, review, et= c.
>
> This call for adoption ends: 8 April 2022
>
> Thanks,
>
> Suzanne, Tim and Benno
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org=
> https://www.ietf.org/mailman/listinfo/dnsop

--
Like our community service? =F0=9F=92=9B
Please consider donating at

https://= desec.io/

deSEC e.V.
Kyffh=C3=A4userstr. 5
10781 Berlin
Germany

Vorstandsvorsitz: Nils Wisiol
Registergericht: AG Berlin (Charlottenburg) VR 37525

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
--0000000000000fa6f205dbe89261-- From nobody Tue Apr 5 06:57:55 2022 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 B06283A07FB; Tue, 5 Apr 2022 06:57:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.107 X-Spam-Level: X-Spam-Status: No, score=-7.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 Dlno-WvmQGGn; Tue, 5 Apr 2022 06:57:47 -0700 (PDT) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (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 F34DF3A07FD; Tue, 5 Apr 2022 06:57:46 -0700 (PDT) Received: by mail-io1-xd2d.google.com with SMTP id q11so15227385iod.6; Tue, 05 Apr 2022 06:57:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2FurhQqNZFiKar5PhRVELqjvmMNpUyAML1hj+0jzuB4=; b=LK1ZFZpU2wfQYkU1cntBlLQ+4zKu03ufeNV5TEkBmGmEUQPbt/0Q71S0NX3At+P6+u kaJ2HVk1PZwnN0B70Co/08/yZGGEZTf68RQA6j0JPUx87opCzWxt55Jje34UOxuRJTkF uVT4u3ql4UqjjnU+wkbjJoTQCAF3ey4mmKBzLYB07bSamQi1MP1/VnMM+X/vbjzcnDkY GPeulC6kp5SmuXrSgRhOM2ea1EsRkaJF17hIa33W60jRHHDheQbAFxGKWPwmUXcogQOj aXk0zMM4C4nqZSB0+RSIDxd+vk9fpvH+2LQBqG1YSKdrpfXdXGJt6rsYyUlZdOqlLg4C C4pA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2FurhQqNZFiKar5PhRVELqjvmMNpUyAML1hj+0jzuB4=; b=vbNp7siyvqvtaYyg+pphnmbPt/Hxwm1WLVbOmwRkTaNpT15YeF6mAgLkPkQRdWjheq U6ruUOCPDteikaTZBTTgDmktQd4GDYmEuOPm0PhOw1FFko9VH68sI6hArR63TxupiSXq NLE5Gejfq6qRG+Y1ua0wByC/5Y/r/sNcg/YZtb8CtbW9bw6fFZWC5ITtugLyfDsHdgRJ 3muReoGAkh8NASF66j+tvi+u85LQo3QnV4y4fSAa/ckYZjmu+NagJ0Lu0tIanh7ZC2/8 3fWRxcKph5E1mswg1jf08Hy4vGquWQD/2r6BUu4UMVx9fvXS9Kmm86N9gYLjb+QVSBfy hW6A== X-Gm-Message-State: AOAM533ecFWo+e1NBz9TNzifM5C08gYXd+ZZAK8DDveFP2Kr0N3aOH0a nYxPku3f0n2HQGmj0dwwMqm0iTv6CgqYQJZqr4c= X-Google-Smtp-Source: ABdhPJzVM9wfp0nRX92vJQRV2U3WLvthEkhO2cVPNF8NJ7Lh62eomd0QwVbmP3WNkPaeex1TwzhBZBV7k2zFrHa2X8Y= X-Received: by 2002:a5d:9d84:0:b0:649:d9ea:5390 with SMTP id ay4-20020a5d9d84000000b00649d9ea5390mr1706970iob.116.1649167065854; Tue, 05 Apr 2022 06:57:45 -0700 (PDT) MIME-Version: 1.0 References: <8d7e1085-33f3-6a28-3464-3f0105b54182@NLnetLabs.nl> In-Reply-To: From: Shumon Huque Date: Tue, 5 Apr 2022 09:57:34 -0400 Message-ID: To: tjw ietf Cc: Benno Overeinder , DNSOP Working Group , DNSOP WG Chairs Content-Type: multipart/alternative; boundary="00000000000022cc2a05dbe8a173" Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-thomassen-dnsop-dnssec-bootstrapping X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2022 13:57:52 -0000 --00000000000022cc2a05dbe8a173 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I support adoption and am willing to review/contribute etc. Shumon. On Tue, Mar 29, 2022 at 12:14 PM tjw ietf wrote: > (No hats) > > I=E2=80=99ve read this draft and support adoption > > Tim > > Sent from my iPhone > > > On Mar 25, 2022, at 11:28, Benno Overeinder wrote: > > > > =EF=BB=BFAs announced during the DNSOP meeting this week at the IETF 11= 3, we are > starting a Call for Adoption for the > draft-thomassen-dnsop-dnssec-bootstrapping. With the survey we conducted > before the last IETF 112, this draft was a clear candidate. > > > > With this email we start a period of two weeks for the call for adoptio= n > of draft-thomassen-dnsop-dnssec-bootstrapping on the mailing list. > > > > The draft is available here: > https://datatracker.ietf.org/doc/draft-thomassen-dnsop-dnssec-bootstrappi= ng/ > > > > Please review this draft to see if you think it is suitable for adoptio= n > by DNSOP, and comments to the list, clearly stating your view. > > > > Please also indicate if you are willing to contribute text, review, etc= . > > > > This call for adoption ends: 8 April 2022 > > > > Thanks, > > > > Suzanne, Tim and Benno > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > --00000000000022cc2a05dbe8a173 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I support adoption and am willing to review/contribut= e etc.

Shumon.

On Tue, Mar 29, 2022 at 12:14 PM= tjw ietf <tjw.ietf@gmail.com&= gt; wrote:
(No h= ats)

I=E2=80=99ve read this draft and support adoption

Tim

Sent from my iPhone

> On Mar 25, 2022, at 11:28, Benno Overeinder <benno@nlnetlabs.nl> wrote:
>
> =EF=BB=BFAs announced during the DNSOP meeting this week at the IETF 1= 13, we are starting a Call for Adoption for the draft-thomassen-dnsop-dnsse= c-bootstrapping.=C2=A0 With the survey we conducted before the last IETF 11= 2, this draft was a clear candidate.
>
> With this email we start a period of two weeks for the call for adopti= on of draft-thomassen-dnsop-dnssec-bootstrapping on the mailing list.
>
> The draft is available here: https://datatracker.ietf.org/doc/draft-thomassen-dnsop-dnssec-b= ootstrapping/
>
> Please review this draft to see if you think it is suitable for adopti= on by DNSOP, and comments to the list, clearly stating your view.
>
> Please also indicate if you are willing to contribute text, review, et= c.
>
> This call for adoption ends: 8 April 2022
>
> Thanks,
>
> Suzanne, Tim and Benno

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
--00000000000022cc2a05dbe8a173-- From nobody Tue Apr 5 13:35:23 2022 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 948CE3A115A; Tue, 5 Apr 2022 13:35:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.107 X-Spam-Level: X-Spam-Status: No, score=-2.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 GBte7NvjnwQC; Tue, 5 Apr 2022 13:35:14 -0700 (PDT) Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com [IPv6:2a00:1450:4864:20::633]) (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 AFCE63A1153; Tue, 5 Apr 2022 13:35:13 -0700 (PDT) Received: by mail-ej1-x633.google.com with SMTP id qh7so75622ejb.11; Tue, 05 Apr 2022 13:35:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9PufGwMbN39WRrfjom8kMXNl7rtSIygFj+Za8bFiTy4=; b=i1N0ftfsBp9RHajvg1sV9dsiVDeeaw0COXrr/tYirPg2VbduzthVebPGgwI9MYGdsy 87zig/CErXk7L3L7XMA1DxMzIdA8ueeZ7XWITKyrwyaXKo4jvBFpyvGbe2kz24raRJf/ QPJmBwmehT7K58lozRVYDu/NOlJXtPrt24nzfHN5VyH53pMfQxA9c+I687T0x5dCGHio lYrUh393ylaGhU472VEkXa5haxhfNNUBk7hSm6Cfhx9FIMqVwqtBiwVtatVncEpnsc3D mwkfgFzPRwY3tnRdcjgUY3132i50CEvNaXDEPi0jcKsLgzaRwy7o+bawIZXRhgv7QsXO 3AWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9PufGwMbN39WRrfjom8kMXNl7rtSIygFj+Za8bFiTy4=; b=tRFAeVpzrPbjiUkBEs//lpdo/w5g6X0JRTS6WqEQnIgleHhoySzsrPvuA59+6j/GLT URAhbUqIliCfJgXEjRMlK6199gJbgtPWPZRJ5pYfkmpi4du4hWbQpxtgED8cugiaSqjE uaHVzrs015R9rjMHFPFPlMbd3AAL20AvuZSP1RvUGDs1MKLPcoaRy3Y6PB6PTqRkgoa7 2EzYEM3p9mcaOyC+Lp6HYT+E+AQTcBJHws+SnSrM3/suStW7spowzIsIdGkl5oI52nUQ YUM8xrygsEcEItGKQQiPc2gVYftictUq3hjJF6FfDn3LaOlnolBzkrUEpA3+0gOaMIoq OUvg== X-Gm-Message-State: AOAM532xZC/wX06rmK02pXYD9a3wqGquOHgo0ruo1MR9DBzWhsdGj6Oa TLjhOZDCftZtw8OX0QyxVipBIWnSRAkzkW1Duno= X-Google-Smtp-Source: ABdhPJxKVtvdV9LPobPknNVN2RUUe8Rrpryguvp+SMlmSjFUXnruO8IRWxGfsVoWQrjphkKyKXLXrcLAtzLUP/VLJeU= X-Received: by 2002:a17:907:c018:b0:6df:fb9b:e6f8 with SMTP id ss24-20020a170907c01800b006dffb9be6f8mr5060858ejc.495.1649190911383; Tue, 05 Apr 2022 13:35:11 -0700 (PDT) MIME-Version: 1.0 References: <93c34015-f441-20a3-b2b0-54159a70d021@NLnetLabs.nl> In-Reply-To: <93c34015-f441-20a3-b2b0-54159a70d021@NLnetLabs.nl> From: Brian Dickson Date: Tue, 5 Apr 2022 13:35:00 -0700 Message-ID: To: Benno Overeinder Cc: DNSOP Working Group , DNSOP WG Chairs Content-Type: multipart/alternative; boundary="000000000000709d4205dbee2e35" Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-wisser-dnssec-automation X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2022 20:35:19 -0000 --000000000000709d4205dbee2e35 Content-Type: text/plain; charset="UTF-8" On Fri, Mar 25, 2022 at 8:36 AM Benno Overeinder wrote: > As with the previous Call for Adoption today, at this week's DNSOP > meeting at IETF 113, we announced that we are initiating a Call for > Adoption for the draft-wisser-dnssec-automation. With the survey we > conducted for the last IETF 112, this draft was also a clear candidate. > > With this email we start a period of two weeks for the call for adoption > of draft-wisser-dnssec-automation on the mailing list. > > The draft is available here: > https://datatracker.ietf.org/doc/draft-wisser-dnssec-automation/. > > Please review this draft to see if you think it is suitable for adoption > by DNSOP, and comments to the list, clearly stating your view. > > Please also indicate if you are willing to contribute text, review, etc. > > I have read this draft. I support adoption by the WG. I am willing to review, contribute text, etc. Brian > This call for adoption ends: 8 April 2022 > > Thanks, > > Suzanne, Tim and Benno > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > --000000000000709d4205dbee2e35 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Mar 25, 2022 at 8:36 AM Benno= Overeinder <benno@nlnetlabs.nl> wrote:
As = with the previous Call for Adoption today, at this week's DNSOP
meeting at IETF 113, we announced that we are initiating a Call for
Adoption for the draft-wisser-dnssec-automation.=C2=A0 With the survey we <= br> conducted for the last IETF 112, this draft was also a clear candidate.

With this email we start a period of two weeks for the call for adoption of draft-wisser-dnssec-automation on the mailing list.

The draft is available here:
https://datatracker.ietf.org/doc/dra= ft-wisser-dnssec-automation/.

Please review this draft to see if you think it is suitable for adoption by DNSOP, and comments to the list, clearly stating your view.

Please also indicate if you are willing to contribute text, review, etc.

I have read this draft.
I su= pport adoption by the WG.
I am willing to review, contribute text= , etc.

Brian
=C2=A0
This call for adoption ends: 8 April 2022

Thanks,

Suzanne, Tim and Benno

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
--000000000000709d4205dbee2e35-- From nobody Wed Apr 6 07:08:40 2022 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 5E7D33A07AD; Wed, 6 Apr 2022 07:08:21 -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: 7.46.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dnsop@ietf.org Message-ID: <164925410133.8707.7855283268813227906@ietfa.amsl.com> Date: Wed, 06 Apr 2022 07:08:21 -0700 Archived-At: Subject: [DNSOP] I-D Action: draft-ietf-dnsop-rrserial-01.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2022 14:08:22 -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 : The "RRSERIAL" EDNS option for the SOA serial of a RR's zone Authors : Hugo Salgado Mauricio Vergara Ereche Filename : draft-ietf-dnsop-rrserial-01.txt Pages : 6 Date : 2022-04-06 Abstract: The "RRSERIAL" EDNS option allows a DNS querier to request a DNS authoritative server to add an EDNS option in the answer of such query with the SOA serial number field of the origin zone which contains the answered Resource Record. This "RRSERIAL" data allows to debug and diagnose problems by helping to recognize the data source of an answer in an atomic single query, by associating the response with a respective zone version. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-rrserial/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-dnsop-rrserial-01.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-rrserial-01 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts From nobody Wed Apr 6 07:26:55 2022 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 89F653A19FC for ; Wed, 6 Apr 2022 07:26:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 ApLjWivrd6bH for ; Wed, 6 Apr 2022 07:26:21 -0700 (PDT) Received: from mail.nic.cl (mail.nic.cl [IPv6:2001:1398:1::6008]) (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 A8A653A0687 for ; Wed, 6 Apr 2022 07:26:20 -0700 (PDT) Received: from mail.nic.cl (localhost [127.0.0.1]) by mail.nic.cl (Postfix) with ESMTP id 03EFF195D62AA for ; Wed, 6 Apr 2022 10:26:16 -0400 (-04) Received: from pepino (unknown [IPv6:2800:150:126:65:4a3d:968a:4938:f63c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.nic.cl (Postfix) with ESMTPSA id DD72D195D628D for ; Wed, 6 Apr 2022 10:26:15 -0400 (-04) Date: Wed, 6 Apr 2022 10:26:14 -0400 From: Hugo Salgado To: dnsop@ietf.org Message-ID: <20220406142614.GD94415@pepino> References: <164925410133.8707.7855283268813227906@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="g7w8+K/95kPelPD2" Content-Disposition: inline In-Reply-To: <164925410133.8707.7855283268813227906@ietfa.amsl.com> X-Virus-Scanned: ClamAV using ClamSMTP on Wed Apr 6 10:26:16 2022 -0400 (-04) (mail.nic.cl) Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-rrserial-01.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2022 14:26:35 -0000 --g7w8+K/95kPelPD2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Dear DNSOP. The authors have just reactivated the draft after its expiration, with no changes. After some time waiting for other more urgent documents, we believe that we can now reactivate it in the WG and ask for your opinions. The last comments and suggestion were acknowledged, and we think we could be close to Last Call. As this document indicates where I have tried to keep track of work (https://github.com/huguei/rrserial) there's a new implementation in NSD and a couple of clients (dig and perl Net::DNS). Currently we're working in an infrastructure for a public testbed that we'll make available for implementers. Thanks, Hugo On 07:08 06/04, internet-drafts@ietf.org wrote: >=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 WG of the = IETF. >=20 > Title : The "RRSERIAL" EDNS option for the SOA serial o= f a RR's zone > Authors : Hugo Salgado > Mauricio Vergara Ereche > Filename : draft-ietf-dnsop-rrserial-01.txt > Pages : 6 > Date : 2022-04-06 >=20 > Abstract: > The "RRSERIAL" EDNS option allows a DNS querier to request a DNS > authoritative server to add an EDNS option in the answer of such > query with the SOA serial number field of the origin zone which > contains the answered Resource Record. >=20 > This "RRSERIAL" data allows to debug and diagnose problems by helping > to recognize the data source of an answer in an atomic single query, > by associating the response with a respective zone version. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-rrserial/ >=20 > There is also an HTML version available at: > https://www.ietf.org/archive/id/draft-ietf-dnsop-rrserial-01.html >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dnsop-rrserial-01 >=20 >=20 > Internet-Drafts are also available by rsync at rsync.ietf.org::internet-d= rafts >=20 >=20 > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop >=20 --g7w8+K/95kPelPD2 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEV6FHQYxbYRHTM+xJsO5EsOb06a0FAmJNowAACgkQsO5EsOb0 6a3YtA/6AifeE/MYqO3wLRzz54HThffgMDEMCNNA3MMgcKAxs3F3DxGbdQDk0Qmy 2u4QIl5WGcOz+br3HrURIzrEo2s8i17HfIVHppbXGOff8rlfYyxz7Z5Yl2fmo8bR qcJ74dqujw6Gy56oOZPusL2t5IJDRmudrhxL2EVThtJg1oGEmDRAiXFkeaLkyN19 6VRWploLMjoOscQvdcDq7/5yjppz/akl5nt21JnwvzHNMNisM7CP36OS1JawM6Qe Zd53vRpl4Qax1kHIbouCAq5Z5bgry/VsUrsLKz478opYpsUKRTuzzdUC3O5f+6gb wDClhbWPxLfz+gdzKAnbu+jeKL5Smv7855CXIGTefd3WSIi7E0cVTKt33D1Khs+w ANynD3nkYrVJ9djFwPNPXb7d6UnKmk9XQXwS8zC+GDbsjfuboCc7SrCzBTpq0yPt B8XWVCD2yRYhMl3aKeBB/CFrylZZQY8+IFaKIKhwMvHF1oy8ALOpDSKPToWQoAK8 DFWWfvq4ihIYsCoAYVgF3FHutg/nJavduKRvw6MtJl7KYEuJMpwamu6ODPTwGXjn Y81hRfIc3GJ0M5Yz8KGqaSAidWGdzsriPoYb89eSn12jNhxxaE5PAq4EmXTOxE62 fK0ZLkUMJ2N4eUYVo51/Rmlsd4xQclaCrhZNhy70AhWj/rC/UKc= =G0xZ -----END PGP SIGNATURE----- --g7w8+K/95kPelPD2-- From nobody Wed Apr 6 23:54:44 2022 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 9FDDA3A10B2 for ; Wed, 6 Apr 2022 23:54:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.108 X-Spam-Level: X-Spam-Status: No, score=-2.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isc.org header.b=OGhky9Va; dkim=pass (1024-bit key) header.d=isc.org header.b=Jvqp7SaH 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 XoVQ2vRhP9Mw for ; Wed, 6 Apr 2022 23:54:36 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F9393A10E9 for ; Wed, 6 Apr 2022 23:54:35 -0700 (PDT) Received: from zimbrang.isc.org (zimbrang.isc.org [149.20.1.12]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx.pao1.isc.org (Postfix) with ESMTPS id 9E16F3AB006 for ; Thu, 7 Apr 2022 06:54:34 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.10.3 mx.pao1.isc.org 9E16F3AB006 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=isc.org; s=ostpay; t=1649314474; bh=asYd57xVL/tgf0AY4y7pTqmrMLlkjIVpjXHyWrOfGBA=; h=Date:To:References:From:Subject:In-Reply-To; b=OGhky9VaSFfiDwOrmTCLCMEUxkgdfhiuMRbToJXgmVcqNJ0ZZ9pQk7jGOq0i6ueXj 8e6LsIXQx7yFekH6cUbud3AKApn/4lXb7fMJN+6PGES1NS8O2pHYzPlUH8DHsTxZpl XNJ5YhGlkc5b2t/L3AZWrKIPxf7WjENehT2NYD5Y= Received: from zimbrang.isc.org (localhost.localdomain [127.0.0.1]) by zimbrang.isc.org (Postfix) with ESMTPS id 87874982AAE for ; Thu, 7 Apr 2022 06:54:34 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbrang.isc.org (Postfix) with ESMTP id 55D45982AB0 for ; Thu, 7 Apr 2022 06:54:34 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.10.3 zimbrang.isc.org 55D45982AB0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=05DFB016-56A2-11EB-AEC0-15368D323330; t=1649314474; bh=MzHOK2RuqPven/PFO8LY8ZRUhPjLNazYowXSue6CQuE=; h=Message-ID:Date:MIME-Version:To:From; b=Jvqp7SaHGqFhHOTHx25cRrd085eBLhOMgwnrumKuRgaeyrOQ3QvwvQTyy+0vPVTcw sCbjplfo5pADlrxB8E+cKkgThMHlQu2YLJUOiec2eF+hNytD9INkwbdIWBRV71/ngw S5T02hCcgLmaJeMH7xAnq+t9GbGq+zDkJy8fTfyA= Received: from zimbrang.isc.org ([127.0.0.1]) by localhost (zimbrang.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id k5CX3Vp9Wa56 for ; Thu, 7 Apr 2022 06:54:34 +0000 (UTC) Received: from [192.168.0.157] (ip-86-49-254-124.net.upcbroadband.cz [86.49.254.124]) by zimbrang.isc.org (Postfix) with ESMTPSA id D3BD2982AAE for ; Thu, 7 Apr 2022 06:54:33 +0000 (UTC) Message-ID: <2d437493-7f88-5a81-22a9-1bd05081f70a@isc.org> Date: Thu, 7 Apr 2022 08:54:31 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.0 Content-Language: en-US To: dnsop@ietf.org References: <164925410133.8707.7855283268813227906@ietfa.amsl.com> <20220406142614.GD94415@pepino> From: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= In-Reply-To: <20220406142614.GD94415@pepino> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-rrserial-01.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2022 06:54:42 -0000 Hello, I think this is useful in a very limited way. The reason of this=20 limitation is already stated in section 1: > The RRSERIAL EDNS extension doesn't offer much relevance for zones=20 served by an Authoritative server that don't use the SOA serial=20 versioning as a meaning to its content. There are cases where=20 nameservers use different backends for its data sources, like relational=20 databases or by using a different off-DNS synchronicity. In such cases=20 this extension has no benefit or utility to use in debugging or analysis=20 of a response. From my perspective, these systems are not rare, quite the contrary: - PowerDNS with a database backend - Multi-master flavors of BIND - Various "cloud" auths with dynamic backends - Windows DNS with Active Directory (I think) To handle the traditional SERIAL together with more "modern" backends I=20 propose simple modification to extend this draft to handle both. Say that wire format could look like: This allows the auth server to either send (length=3D2,data=3D4) with SOA= =20 serial as usual, or return any other identification suitable for a given=20 backend. If we _really_ wanted we could add also type field to distinguish=20 "traditional" SERIAL vs. backend-specific blob, but I think it is not=20 really needed. To me this is very simple addition which increases value of the proposed=20 protocol. Opinions? Petr =C5=A0pa=C4=8Dek On 06. 04. 22 16:26, Hugo Salgado wrote: > Dear DNSOP. > The authors have just reactivated the draft after its expiration, with > no changes. After some time waiting for other more urgent documents, we > believe that we can now reactivate it in the WG and ask for your > opinions. The last comments and suggestion were acknowledged, and we > think we could be close to Last Call. >=20 > As this document indicates where I have tried to keep track of work > (https://github.com/huguei/rrserial) there's a new implementation in > NSD and a couple of clients (dig and perl Net::DNS). >=20 > Currently we're working in an infrastructure for a public testbed that > we'll make available for implementers. >=20 > Thanks, >=20 > Hugo >=20 >=20 > On 07:08 06/04, internet-drafts@ietf.org wrote: >> >> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories. >> This draft is a work item of the Domain Name System Operations WG of t= he IETF. >> >> Title : The "RRSERIAL" EDNS option for the SOA seri= al of a RR's zone >> Authors : Hugo Salgado >> Mauricio Vergara Ereche >> Filename : draft-ietf-dnsop-rrserial-01.txt >> Pages : 6 >> Date : 2022-04-06 >> >> Abstract: >> The "RRSERIAL" EDNS option allows a DNS querier to request a DNS >> authoritative server to add an EDNS option in the answer of such >> query with the SOA serial number field of the origin zone which >> contains the answered Resource Record. >> >> This "RRSERIAL" data allows to debug and diagnose problems by help= ing >> to recognize the data source of an answer in an atomic single quer= y, >> by associating the response with a respective zone version. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-dnsop-rrserial/ >> >> There is also an HTML version available at: >> https://www.ietf.org/archive/id/draft-ietf-dnsop-rrserial-01.html >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dnsop-rrserial-01 >> >> >> Internet-Drafts are also available by rsync at rsync.ietf.org::interne= t-drafts From nobody Thu Apr 7 05:44:20 2022 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 2CE313A079B for ; Thu, 7 Apr 2022 05:44:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 SoIKUp4etVB0 for ; Thu, 7 Apr 2022 05:44:16 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietfa.amsl.com (Postfix) with SMTP id B0F693A077F for ; Thu, 7 Apr 2022 05:44:13 -0700 (PDT) Received: (qmail 48962 invoked from network); 7 Apr 2022 12:40:04 -0000 Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 7 Apr 2022 12:40:04 -0000 Message-ID: <350d8ab8-0477-b656-8b08-56f7561a7fda@necom830.hpcl.titech.ac.jp> Date: Thu, 7 Apr 2022 21:44:08 +0900 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Content-Language: en-US From: Masataka Ohta To: "dnsop@ietf.org WG" References: <57f1c37b-497c-e1a0-329c-4b9c8b7e197b@necom830.hpcl.titech.ac.jp> <9732682e-78e7-f6bf-84fc-685de22d5e12@necom830.hpcl.titech.ac.jp> In-Reply-To: <9732682e-78e7-f6bf-84fc-685de22d5e12@necom830.hpcl.titech.ac.jp> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [DNSOP] DNSSEC as a Best Current Practice X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2022 12:44:18 -0000 As I wrote: >> Such an individual would have to get access, create the records, give >> them to others, who then have to on-path attack you. At the TLD level >> and higher, this involves HSMs and physical access restrictions using >> a “four eyes minimum” approach. > Not surprisingly, diginotar was equally strongly secure. Are there anyone who still think DNSSEC were cryptographically secure or had protected TLDs more securely than diginotar? Masataka Ohta From nobody Thu Apr 7 06:43:10 2022 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 BC3F93A0BA9 for ; Thu, 7 Apr 2022 06:43:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.11 X-Spam-Level: X-Spam-Status: No, score=-7.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redbarn.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 54L7fx7x2IvL for ; Thu, 7 Apr 2022 06:43:00 -0700 (PDT) Received: from util.redbarn.org (util.redbarn.org [IPv6:2001:559:8000:cd::222]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A72703A0BB0 for ; Thu, 7 Apr 2022 06:42:59 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by util.redbarn.org (Postfix) with ESMTPS id 9DBA91A2423 for ; Thu, 7 Apr 2022 13:42:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=redbarn.org; s=util; t=1649338976; bh=IiYs+ShISKB6Iu1bA95qX7n2/MLK+Vk6XTweQBpFGyI=; h=Subject:To:References:From:Date:In-Reply-To; b=cCfZTgFyYx8UNj/usfItJzXdq6AfEJxlqn4b4VcnJe3njUrja1ton1sx77pAyU/ri jLRaAWaOCpY/sI9Hy2CEoApcKhOi1CvuM/k2eC2lSV3geaHK37yMoPx4ZJcSWbIFqY 0AH9PW3a0WVZAlScpDvOZmkqLJaDwvNGn1UHlri8= Received: from [24.104.150.147] (dhcp-147.access.rits.tisf.net [24.104.150.147]) (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 4FA757597E for ; Thu, 7 Apr 2022 13:42:56 +0000 (UTC) To: dnsop@ietf.org References: <164925410133.8707.7855283268813227906@ietfa.amsl.com> From: Paul Vixie Message-ID: <28d0d9c8-a8a1-0313-0f25-dd8c7dbac087@redbarn.org> Date: Thu, 7 Apr 2022 06:42:57 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 PostboxApp/7.0.54 MIME-Version: 1.0 In-Reply-To: <164925410133.8707.7855283268813227906@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-rrserial-01.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2022 13:43:07 -0000 hugo, mauricio, i hope you will change your nomenclature. a zone serial applies to an rrset not just to an rr. answers contain rrsets not merely rrs. other than this, your proposal looks solid to me. paul re: internet-drafts@ietf.org wrote on 2022-04-06 07:08: > > 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 : The "RRSERIAL" EDNS option for the SOA serial of a RR's zone > Authors : Hugo Salgado > Mauricio Vergara Ereche > Filename : draft-ietf-dnsop-rrserial-01.txt > Pages : 6 > Date : 2022-04-06 > > Abstract: > The "RRSERIAL" EDNS option allows a DNS querier to request a DNS > authoritative server to add an EDNS option in the answer of such > query with the SOA serial number field of the origin zone which > contains the answered Resource Record. > > This "RRSERIAL" data allows to debug and diagnose problems by helping > to recognize the data source of an answer in an atomic single query, > by associating the response with a respective zone version. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-rrserial/ > > There is also an HTML version available at: > https://www.ietf.org/archive/id/draft-ietf-dnsop-rrserial-01.html > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-rrserial-01 > > > Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > -- P Vixie From nobody Thu Apr 7 06:48:01 2022 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 EFEFF3A0BD1 for ; Thu, 7 Apr 2022 06:47:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.11 X-Spam-Level: X-Spam-Status: No, score=-2.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redbarn.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 qyYeBZjyiPRc for ; Thu, 7 Apr 2022 06:47:54 -0700 (PDT) Received: from util.redbarn.org (util.redbarn.org [IPv6:2001:559:8000:cd::222]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B0293A0BB3 for ; Thu, 7 Apr 2022 06:47:53 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by util.redbarn.org (Postfix) with ESMTPS id 80BD91A2423; Thu, 7 Apr 2022 13:47:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=redbarn.org; s=util; t=1649339271; bh=elrSRkiOKRdbOOVciz4/U7jZVzqb4XwUxvqLboLb/ws=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=OXlai4W4Qw2OI48UIXROYgOkmExgg3Qvp/MXbpxBOKZbSD/9g1FkIWzq7pROJiSLS JtzKMEKniNeeSQK1+B00OQlnc2LTpRxst3j+M3BojhWcSKUkNtbtrzgRjNh73Asc4j gA3mbwQmBBd46VNRSeQuKQdnKufSIuPF14GG7fCQ= Received: from [24.104.150.147] (dhcp-147.access.rits.tisf.net [24.104.150.147]) (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 609BF7597E; Thu, 7 Apr 2022 13:47:51 +0000 (UTC) To: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= Cc: dnsop@ietf.org References: <164925410133.8707.7855283268813227906@ietfa.amsl.com> <20220406142614.GD94415@pepino> <2d437493-7f88-5a81-22a9-1bd05081f70a@isc.org> From: Paul Vixie Message-ID: <5fb93410-d751-9c9d-8c25-5a6805f16d68@redbarn.org> Date: Thu, 7 Apr 2022 06:47:52 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 PostboxApp/7.0.54 MIME-Version: 1.0 In-Reply-To: <2d437493-7f88-5a81-22a9-1bd05081f70a@isc.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-rrserial-01.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2022 13:47:59 -0000 Petr Špaček wrote on 2022-04-06 23:54: > Hello, > > ... > > From my perspective, these systems are not rare, quite the contrary: > - PowerDNS with a database backend > - Multi-master flavors of BIND > - Various "cloud" auths with dynamic backends > - Windows DNS with Active Directory (I think) because IXFR and NOTIFY and UPDATE use serial numbers, the DNS protocol itself is aware of serial numbers. i hope that any recognition of non-traditional serial numbers will be an optional addition to the RRSERIAL response, and that if a zone has no actual serial number (so, it cannot participate in IXFR, NOTIFY, and UPDATE) the RRSERIAL value will just be a magic number like zero, or just missing altogether. -- P Vixie From roger.murray@internetstiftelsen.se Thu Apr 7 07:23:55 2022 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 CDA603A0DB5 for ; Thu, 7 Apr 2022 07:23:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.11 X-Spam-Level: X-Spam-Status: No, score=-2.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=internetstiftelsen.se header.b=LcvVESUL; dkim=pass (1024-bit key) header.d=internetstiftelsenisverige.onmicrosoft.com header.b=2Wl2O8mr 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 iYiDf26zp2WG for ; Thu, 7 Apr 2022 07:23:50 -0700 (PDT) Received: from relay2.iis.se (relay2.iis.se [IPv6:2001:67c:124c:7317::16]) (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 4C8843A0105 for ; Thu, 7 Apr 2022 07:23:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=internetstiftelsen.se; s=iis2015; h=mime-version:content-transfer-encoding:content-id:content-type:in-reply-to: references:message-id:date:subject:cc:to:from:from; bh=zoPMn458Gl+Hy8tqUJ8IbW00GwxCUbq4sdkp58FQT7c=; b=LcvVESULRxvZH868l0lWtsHy+p4vMYEgtLdQ9xOOnh15xtQouYwsVnNxFVSeF8bLyA5Arm/b/bPx/ Ci3KaEIQezM6m+vQU45erQ6qOrWZakAH0b3NyxrBk34LF40OazGvQ5OkaE9SNYJAeWiW3HVNEgK2GW 0PMfEXjMNwlW/Hc8= Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-vi1eur04lp0203.outbound.protection.outlook.com [2a01:111:f400:7e0e::203]) by relay2.iis.se (Halon) with ESMTPS id 536ac185-b67e-11ec-a12f-00505682e997; Thu, 07 Apr 2022 14:23:42 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mWIfQs5Cyd/UsCD3ClEulty70yAxFGuVknMMkPwtE6qJI/k3Ek2pRJJuFzYdbkm5/FPmTIQmdjJyk8vnrxR4lsHddNVQbBOWY0PA1sa8EIZYE/uyTc51oq1at2dn/BxdbrSoSBaBRAHqoVlOyiKv5OKBv+CWTegXabZ86jnRn82x7pHC/r/PriEi3A0z9AeXPC6k8WU+3ZrdUVgj6cT00hEc33sBRiQDIWQ4MHMfhzU42hPlofFMvVYYl5J+2hGpM8+l7kCzzcgPc56W2HVozYzz67ShdFbWAHYenDHXZLgxr6uky3Ubn/+aVq5gXo0qyfvT7iA7ILH5qbsaKzAkiw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=zoPMn458Gl+Hy8tqUJ8IbW00GwxCUbq4sdkp58FQT7c=; b=l5WA8K2iuOzASNbGdfQnZFYpEMjb0Smtnve0w2qytjPOTOcdsY6TWt4UrCduoMa7p3p+RsKH9bPGHbN00j/LeRS+kAL/nvMQXNbOt7zvn6DtlFmhic17HPYMtq1GSwueRMn1S8MkV10bXwI/aOksVE/5HrCMHeTtubgRKpRVspqDydQQiZwWilQwDtbVfdjsXkKS70aYe0NLfYfE62Bx1oz0vgK4h3vwsVHw/+5tytpE82JKFloOv15uPohf7YhdSBBQkuRRYLPIs9ZtTIPpVwekoFmskn8JXHeDbXjv0lCm65CxFNLxIHefvc/CmGHvaNmHJ3gfG1yxSVfGWDYnkg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=internetstiftelsen.se; dmarc=pass action=none header.from=internetstiftelsen.se; dkim=pass header.d=internetstiftelsen.se; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=internetstiftelsenisverige.onmicrosoft.com; s=selector1-internetstiftelsenisverige-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zoPMn458Gl+Hy8tqUJ8IbW00GwxCUbq4sdkp58FQT7c=; b=2Wl2O8mrIgQ9GrcQUJnsSolCOK+K7ewfdAziIUtqRvjC8CqSyvcsVNC00Jf2q0xsbyitpqVbujfx65Z7+/YaORGTffnpmox5OX6J8R1q//Tb0qTNQPjJOrk3wERX+XF6TN0a8X26sFuLD/Vv0mQzHJ9MHEvJPvQ24Jv8IbZqQ/0= Received: from AM9P193MB1777.EURP193.PROD.OUTLOOK.COM (2603:10a6:20b:3ee::15) by AS8P193MB1862.EURP193.PROD.OUTLOOK.COM (2603:10a6:20b:3f3::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5144.22; Thu, 7 Apr 2022 14:23:40 +0000 Received: from AM9P193MB1777.EURP193.PROD.OUTLOOK.COM ([fe80::5851:8c87:d4cf:67de]) by AM9P193MB1777.EURP193.PROD.OUTLOOK.COM ([fe80::5851:8c87:d4cf:67de%4]) with mapi id 15.20.5144.022; Thu, 7 Apr 2022 14:23:40 +0000 From: Roger Murray To: Benno Overeinder CC: DNSOP Working Group , DNSOP WG Chairs Thread-Topic: [DNSOP] Call for Adoption: draft-wisser-dnssec-automation Thread-Index: AQHYQF4m1TAZBoZJYEOX6IIPjTxGUKzklWsA Date: Thu, 7 Apr 2022 14:23:40 +0000 Message-ID: <7E50F327-9456-4C08-AD21-DC2622C4466D@internetstiftelsen.se> References: <93c34015-f441-20a3-b2b0-54159a70d021@NLnetLabs.nl> In-Reply-To: <93c34015-f441-20a3-b2b0-54159a70d021@NLnetLabs.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3654.120.0.1.13) authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=internetstiftelsen.se; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e31e96c8-5dc6-483a-cf85-08da18a236be x-ms-traffictypediagnostic: AS8P193MB1862:EE_ x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 20QH4iVY+1pfA1Rri3oh+IE0gdI2/lFQ9C6NcRZMYvyyygF4xhLXbjwINaiyYIXlt5vlW0c7nmsQ3PImA80PZIx/flucNKo6viVJJmO5TpICL41RSYXPySyBVvRNXVy29iRpHMhRQe/toynvqpHA/vfbYVed2BZLvlRMdBZSzNiFdXENV0M6+3vSY9kPXGVUBzUvk/FCNHrl0Nk/59qSuhungivz8EJs5kR63dU6IgPoU+EmZpgbpnHEYATuh80Dlz5OddAHp0AA+US8N1r99MyRmboLt1YpWsRxj4oxdjvjrtejtC/k/+Rf0DcA0htKwR/3FdHc9rIdwef3eJFmzbpXx7kdm57i2Q58WheKwvLPKN3DbMJZUslZOiByMC2uOoWVkfIhr8oU3fZtnN23MynXZFQc9pu5zcDT97ZFvdBLdX8nR++Q1z0YwBtATAgOCdy3/HrmCvGjXqOFEdEkbzE71/74lTwAk5Q697FkOBYWiPnVNcam5MTM+Ex+Y8qgZ5cmou95Y1/kWYYurdVwLA+k2mJnlTNqZX9rBImfwvHJMugjV9ceRlqhFXYfYbqAjJuU7XzO6r/oXI1iiE5mzJ/3gnF9loG0uBwi+HX6BAMgRMILyDnlnPwJZnQKIECe4bZnyYTYn1Wt16GorbMPAlHxHqB+EuuyLNCuX5yXzCkPQdncQXwZeKJCSH8d+jqHhgwm7kATavg8c4KAaHaLX3z/SmPfR9xcOxvyQyQ3qUj20arnpJoujOsPhizu7JxQ+mSnRjTLaeLYAey0bzCmI6Mvlh7awuYJqVP2iklXjbXlvH9dX0ShJHsoIzYMTxHD x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM9P193MB1777.EURP193.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(13230001)(4636009)(376002)(346002)(39840400004)(396003)(366004)(136003)(2616005)(6512007)(6916009)(54906003)(53546011)(6506007)(316002)(186003)(26005)(44832011)(36756003)(91956017)(4326008)(8676002)(38070700005)(38100700002)(5660300002)(508600001)(71200400001)(2906002)(122000001)(86362001)(8936002)(966005)(33656002)(6486002)(76116006)(66946007)(66556008)(64756008)(66446008)(66476007)(45980500001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 2 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?kKEtttg1mShCVZ0RtoDnICRi4LWSsHki9Ssy8GSQZEKPT+XgPMBQ5Eu3CAhg?= =?us-ascii?Q?j9aqUqDbk5mpdQYVXld4H/AxC/t53QiorjcvsovKOeU27O0OAteYv3Z76ilk?= =?us-ascii?Q?m55HfC/iPHVKcxCjFqoVyDbdQPvxO8yhycLriUpGPn3lEKJBy7n6gtkUs48N?= =?us-ascii?Q?2oPuzWUNKFclXYIhW4hyGefniFiZQqfkzZKTCVyrVAxP/blFXPGtL4gF7Prt?= =?us-ascii?Q?TV9PTsLB74k7Gj3FSopWD9oSXEETayuja37amiUSRNvzq/fdhNhmKIvCDIJL?= =?us-ascii?Q?KN9KbP1pUqVVsnKdOKzgE8b78TN8mVep2n4XJy9PRvam3dvNXEj34dGtJyYo?= =?us-ascii?Q?67VaGHkCOGgXGGroMhaVf0LZFHKISZRUxuGIVnD0mYlf3NZW1nYyiNXqjY5L?= =?us-ascii?Q?R4KyEI4OUikAI1WhGV1b2iDF/tHXQ8TwnZJm+8DBf5kPrR0r+MACskNFo372?= =?us-ascii?Q?U/ros+BHIHzC6ZVmUIEdO9vWTHpTc+M7WvLPrdiwmVVI07L5sZgD/B2HKjpJ?= =?us-ascii?Q?Brgh3eswH0I0lSvH/7n/x1mupOOquwqABOx8DYQXKEKxAV8pb8ysBSO3E1bU?= =?us-ascii?Q?IAwJGOirzg3JSg4+H2u8T2eePtPj7vvW/cz9U9dx7/eMEPQv2oBDqmfYPahy?= =?us-ascii?Q?UvVUuSZjIdtno6ndhMWzowYCtL7hSc3TbvPjCptmXCVLLBvueSgRM3vl+45E?= =?us-ascii?Q?UjUpqzfYcG0FJdR6Rx8mdrxztxIKZ8YwPj/oEX3ZTBMqFfCfkA2mJzH4YyUe?= =?us-ascii?Q?H6azfw05qw/wrNP8Ya2QAmHaoGDsWOF3J0NfNuWuWLjoq4dvlxRZ41AAbax6?= =?us-ascii?Q?Wnp8QL+q9Re3rWi2q+yGig3wgqjL7iRiHFHL8mqVzLenp+a2GAAa/dj5EihH?= =?us-ascii?Q?w75mwOhy+QDwA6ha/9iXgT8GQyei/tSqE454VofCo52dhRcEVzOe42VGuLTo?= =?us-ascii?Q?0DGNrF2ImybNK4jQIDb43mcqc7l8GFTtSW3+VbwzPJZa+jUlO5S6s8v67Diu?= =?us-ascii?Q?ivrjmvjsuUxBBf67deRwSUGuuCVTMhsA3N31egWxRnA/D0FxxUY4iODjiEms?= =?us-ascii?Q?HCROLJ/Nm+L1rOlLRw5Qj6uzc/Z3gb2M89k0wIUZu3TgOTOIMvPouY0C6Mbu?= =?us-ascii?Q?NIxbzgeWUkO9Hz6o2kOVpyTCTqRD1m15Jy/JLUXOZJLn8W8PqnqMPTBXd+yG?= =?us-ascii?Q?Zo9Hgcf5GsrReEMQ94TJTSD8HCY1lJEVRrE4+pQNc5Mu8pu+EyJTMYwVBc4I?= =?us-ascii?Q?FrX5Jq3mq8XcVVAPkjsVzr+e1n4dV3/uMsIHBzTAiY3cedl2s+pHD2NB9UOc?= =?us-ascii?Q?+e3WQ15BM8vw9JwkwDmYw/tMIIQnuOronJ19W9YK+jyEg6n2bMuvnrorrASi?= =?us-ascii?Q?lUGvU0rZRU5zX1/pvtUae/TVEGwIHeAxCP53d6p1dwiXamNEsFKoyxrRPZIl?= =?us-ascii?Q?AslNVt0t1rnJOG8tSsSNeFOIKUKMFcDAISezsCxFylhhwVgW2EHQJw2S58Mj?= =?us-ascii?Q?e08ILbYS6ylAMNQTdneiyFPTUjf18//RL0qeCF5jynK5oPhVwQP0ed38R1Dk?= =?us-ascii?Q?usrs+3vumGoD2e2qA71wv6uCskaNTNk3lxjvLTddpcK+BgNOhaODEtnwS6B5?= =?us-ascii?Q?Px4G/0r66qFXX7xGN/xCzzr18Im6Kn7ryivps3p3dXlOszCulXEU0ysvS3tq?= =?us-ascii?Q?DCsXs7174iliyIXDJWt20/0KDAgTP2JoVsnHByS2DRwafHBgR70bvRNcuXYa?= =?us-ascii?Q?T0wX/3QwfnAwtRLf9nayqSdlzYO9qrGQ/4EoCenUtlOkVKBMvOugPgUGRIi2?= x-ms-exchange-antispam-messagedata-1: RfHM1JW3J6RvKA== Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: internetstiftelsen.se X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM9P193MB1777.EURP193.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: e31e96c8-5dc6-483a-cf85-08da18a236be X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Apr 2022 14:23:40.6714 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: c2aa68f8-18f3-48ae-81ba-02301d121d9a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: yf2Qsv1zWdVHAdQ9sgDWLypN08HS7C41/FR/i8BWgtChn1r+72qRt0bATrdI108XBCigtqQLwOltO9pdIyqrhGsCooLfZL+SVWR23t42eRu7rs1SGll1YmFOqxxavZnR X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8P193MB1862 Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-wisser-dnssec-automation X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2022 14:27:42 -0000 I have read this draft and support it for adoption. I am willing to contrib= ute text, review etc. Best Regards, Roger Murray > On 25 Mar 2022, at 16:35, Benno Overeinder wrote: >=20 > As with the previous Call for Adoption today, at this week's DNSOP meetin= g at IETF 113, we announced that we are initiating a Call for Adoption for = the draft-wisser-dnssec-automation. With the survey we conducted for the l= ast IETF 112, this draft was also a clear candidate. >=20 > With this email we start a period of two weeks for the call for adoption = of draft-wisser-dnssec-automation on the mailing list. >=20 > The draft is available here: https://datatracker.ietf.org/doc/draft-wisse= r-dnssec-automation/. >=20 > Please review this draft to see if you think it is suitable for adoption = by DNSOP, and comments to the list, clearly stating your view. >=20 > Please also indicate if you are willing to contribute text, review, etc. >=20 > This call for adoption ends: 8 April 2022 >=20 > Thanks, >=20 > Suzanne, Tim and Benno >=20 > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop From roger.murray@internetstiftelsen.se Thu Apr 7 07:24:42 2022 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 3842B3A0DB4 for ; Thu, 7 Apr 2022 07:24:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.11 X-Spam-Level: X-Spam-Status: No, score=-2.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=internetstiftelsen.se header.b=kuZe6/p8; dkim=pass (1024-bit key) header.d=internetstiftelsenisverige.onmicrosoft.com header.b=XCv8ViOw 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 rIIT1e_UyHUY for ; Thu, 7 Apr 2022 07:24:37 -0700 (PDT) Received: from relay1.iis.se (relay1.iis.se [IPv6:2001:67c:124c:7317::15]) (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 04AA33A0DA6 for ; Thu, 7 Apr 2022 07:24:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=internetstiftelsen.se; s=iis2015; h=mime-version:content-transfer-encoding:content-id:content-type:in-reply-to: references:message-id:date:subject:cc:to:from:from; bh=IQ4cEJmrsusSHHnpv01naxMetg+zeS4xHAXKwwKxhyU=; b=kuZe6/p8UCNtYdMy+hg16RHf+REE0i8wPCQliczJ2W2mCi4xJPvkOGmmL2OgzVhGKwxDYC37udMyJ k4iHIkbD5n+tuK9YkO93SYfdeKSCLyZnuMVWUlNGbQrZhrDWxFYzDeXXgk/6NSOIbrvJMsF/jUhP+9 KrChAmH5CChhcT1o= Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-vi1eur04lp0204.outbound.protection.outlook.com [2a01:111:f400:7e0e::204]) by relay1.iis.se (Halon) with ESMTPS id 71cea9f5-b67e-11ec-a9bd-005056827d92; Thu, 07 Apr 2022 14:24:33 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NhY76YouBXlJXuajsQVk8Wgf5mLCTOQ4ViIQvCFArcZKokwJU54fjNGCgwJJHgrJx0vtqyKgjp2Bmo5KrdWEDgbEiE44pAZfE92lKyTndww0rQhcKTNy1jV5oXQ2RoCXIf8EWh3D5QP1LiEDtldxaZ1pgS7ExJyQ2EVHnlP7huxK0UMyKbxPWBgPZo/0ZnP9O52qCDPlCugFT33IwxH7Tp7r6ufDlWif3X53kmOew89krPp778OJ0wr3lIiYTCkQWe+P5yxFc+w8y0z5EFU94j7AAdsn4YKc8NruEgboE3qN/ePe7MjlGNG/gLJQixFOpCPZUkEKswuSEVfAbiSJmA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=IQ4cEJmrsusSHHnpv01naxMetg+zeS4xHAXKwwKxhyU=; b=RGkdxUXwNVhspfopQO3l9UxDAwyo/jkhNO00UnDIhTflw2FWOloh4M5Ai0DVD4BCaz4bwEgTvBIU933ACe6jfxGk8cLlDQ8pdHyRUz0ivc++Y/YkgCqd5cmXSoQOqBJTv0YP/5WQ6Rj6Whu8Ruv4fGvK/LJLCXtRTLf1Io1TQBLqYRPINo3LnZW2oBitaX0SVlo2V2fgLBy47/xXiC7GNWMB68XkdMNvN0aSLlNiV11dagvRjya/TR6DD7cIFnkO9O5proxWjwLMAyK4N/nDj4vIvuIRikeDa0r9fyZeCLTJuIc8vMo9Na0NVqNzTev4I0HEkN82waAv6cicleG9RA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=internetstiftelsen.se; dmarc=pass action=none header.from=internetstiftelsen.se; dkim=pass header.d=internetstiftelsen.se; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=internetstiftelsenisverige.onmicrosoft.com; s=selector1-internetstiftelsenisverige-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=IQ4cEJmrsusSHHnpv01naxMetg+zeS4xHAXKwwKxhyU=; b=XCv8ViOwFrimDVLPY9rxFzUoSfqEHk8TehfoQ2wJvwPTQ2qphEEJSe3rL97qNHywzTclhPLHE9AlnJ+plHdk5Zp3z3HxB8fUnu6HFNJHlCOvy7b75FNCrL42YNqtwH5L0pdjBLjPrbU1md6Cge4HeBx+insPX9E5zbptbkOFqyQ= Received: from AM9P193MB1777.EURP193.PROD.OUTLOOK.COM (2603:10a6:20b:3ee::15) by AS8P193MB1862.EURP193.PROD.OUTLOOK.COM (2603:10a6:20b:3f3::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5144.22; Thu, 7 Apr 2022 14:24:32 +0000 Received: from AM9P193MB1777.EURP193.PROD.OUTLOOK.COM ([fe80::5851:8c87:d4cf:67de]) by AM9P193MB1777.EURP193.PROD.OUTLOOK.COM ([fe80::5851:8c87:d4cf:67de%4]) with mapi id 15.20.5144.022; Thu, 7 Apr 2022 14:24:32 +0000 From: Roger Murray To: Benno Overeinder CC: DNSOP Working Group , DNSOP WG Chairs Thread-Topic: [DNSOP] Call for Adoption: draft-thomassen-dnsop-dnssec-bootstrapping Thread-Index: AQHYQF0mpK5X4iNzeU2/NESLI50XcKzklaqA Date: Thu, 7 Apr 2022 14:24:32 +0000 Message-ID: References: <8d7e1085-33f3-6a28-3464-3f0105b54182@NLnetLabs.nl> In-Reply-To: <8d7e1085-33f3-6a28-3464-3f0105b54182@NLnetLabs.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3654.120.0.1.13) authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=internetstiftelsen.se; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 272ce59f-7558-404d-cc31-08da18a25549 x-ms-traffictypediagnostic: AS8P193MB1862:EE_ x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: JYrLcmXbrMqiPka/DiyZafbsPiE9xBHdfiZN1GOsOc6WR9Z26+5ZyuerTr7zNfvfs2fhX/3XPUjuOSHPjwR2V/jKhCILE9DcVXkgRs6RcJ3ed/weqk93Dg4Rqa1a6dw/zZDJAlFPl59GLYfxVLTCWadc/IoGygvRXC4N8EgZxCnv0XHIP2syjlEKv/zaRTF1LPY75Vq1A0Lf4eBon9J0n5ITsMU00VrzsdDTmfNpdXiGKLTdpBB2+s7/jjtVBtGCGh8AD3rIFcNQJbORYwUQ2GbV0pO3AzK02xNu9/qtLDBoTujC0Kfq8W/CrZYWsI4J9eN5g6jZl/qRYWSBUKUZQyaYmCohE0wREZCNVVnU6xqdWOYMt7oxvdeJCgumbJAgvmDn7rUojtOLQrX7IYn3ifpNSt1+QLBM/q7cFufz2ilcRK37SQZCG0nCltZKvaGXSQFF2smjYYuxcP4Tx5ZeQLL1JoO69gIRNCgM19bE+MensvS1HHo1+5m8Qo5A6aGhWEiB5VWEU2IdLb9a0QTIpLNp9GeOq4HbuxYge5Mze40PL5DqgNrC5YHlga63dRy89UU8w6sJTRMBT6OKASoVMh7SihwLDv5YT9KHxF5hMFOFhjFs4yLV11OT3i+nojU+dRXXLgRd9TpC07oWO7qLqCozUMMH6Zgb+hcwfG749IxHCgvfcjlVhjAuOe6C0/8Px4HHsMCLZsLF3Rme2GeWPijR/FxGdZsgKTLuCMGNz4gKIEvQBPuL/ulG9bf0eKlNqOyszVTz2qwYXcPem8LTQWbyYpw0+eYl8ut82WfWLDbh5n7dwzWJhA8su2WfNhNk x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM9P193MB1777.EURP193.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(13230001)(4636009)(376002)(346002)(39840400004)(396003)(366004)(136003)(2616005)(6512007)(6916009)(54906003)(53546011)(6506007)(316002)(186003)(26005)(44832011)(36756003)(91956017)(4326008)(8676002)(38070700005)(38100700002)(5660300002)(508600001)(71200400001)(2906002)(122000001)(86362001)(8936002)(966005)(33656002)(6486002)(76116006)(66946007)(66556008)(64756008)(66446008)(66476007)(45980500001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 2 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?58tWHC2Ak+oH1m7KNzXYHtTMb3BXSrSH/XRRpMv3v0akJ56gdWLWUyRBc0U+?= =?us-ascii?Q?FRjjtEoAvj7j1Ngd/9gb0bYSw1YiiZAWqO0695NeAF0L85aeAseW2IOuZkNY?= =?us-ascii?Q?yBCn8bv5qwg3d+bB9pBMwAC9QJ+VQHPTkmixLsRC9h80Leu6A/WsNeeuSrgh?= =?us-ascii?Q?SED5KCGCKsszOmfcxesD2aLg4oeNwj9KnlzB0yC2TO64Vwf1dl7gr4QxtF98?= =?us-ascii?Q?LOmMXSVyXQaQJnYhNn4DOsm6flqQ+bnFmanbwa4Zbb1aplFG330sJGRjIt8l?= =?us-ascii?Q?35WdLRlWviHgjF2a495BNJfWsK5iDhXlshgEYC9ckJVoMysNw/R/mc6+Rwf8?= =?us-ascii?Q?nhCaIen6KK/0qiJ/8FDWjeyZgmjTrrQ7rzN9YebpYBoGSX/CxVNoF8SDK3G/?= =?us-ascii?Q?Vp5Sn5KVFEdAZotLqdk10Tj+hu9Lo0cYZXbFDrs++lgmxd0mLKj/vMSA5uc8?= =?us-ascii?Q?bXFZVnlztM06AIAf7IVqoHTsFk5RW1zmhFBAoiClDfzEGJ+zeMbowOk2qYeg?= =?us-ascii?Q?gcHf5ia7aWCLq5gkwlNJFLxKLbTeS468rW/aNTS8g6BBlMyZ8gA3hEEFre2u?= =?us-ascii?Q?FRgct6LAu3k2d3gbrGdFWpXCUAVtWtTFMd/0jz3D/m/7GzppIPq7wMMIJEUf?= =?us-ascii?Q?pLkAHpOr/9lyGN0HBpVlYMszfIyTp9p97FF4AvfZnuLLxs1mqhxdNKKMOv3M?= =?us-ascii?Q?LFU+5FgkPThvGKXsTGzloq3ryX+8Tf/sL6JjRrMzbx0yPEQHPCs2Xa5tOfaG?= =?us-ascii?Q?74goArRIM3RvFTGDc5vDhmYUM7qIlR+aHAtoG8RnqW6Asq0aStiT0Tf9Tlta?= =?us-ascii?Q?I3xrnJo4fq/3zWWYSHUiqph2127BM8Fit8T3Xo5elyWqs7OQm11LMXJdmdwR?= =?us-ascii?Q?grlyEcMRWHjifPP5/hGBkPMOouPnTWUgTnIdRH9Eccc8+ddgYzTSmIdlInFQ?= =?us-ascii?Q?Y7zLO2bYu2X4eXVVcLl/+DO6DYOH7uxzja3KOf/wwvHcmoZpbMxBxM8TCv2L?= =?us-ascii?Q?HkDYsW4fK81xOXWA/LAhmxU8YXVW53/NzicOXmpfOHhsRIYFz2hvPx4NacGB?= =?us-ascii?Q?lSAt7t9fL01aFjg5c4+QIhl+Eh/dUVUlIy5VLiUL0tdyHMCnJtyI4NByBZsP?= =?us-ascii?Q?MsBAWtNpogqEdhbSDMHmxq+ku1s2h8AdMidVJSHfUFP8ZFrbu1NNGzd5+CYi?= =?us-ascii?Q?Bq6UtRUdV6akEKOuTdSSM/kaxDN2zVA/9mr8sakKDlNKVKYjbyD4lz0rfO7i?= =?us-ascii?Q?4R1EH7WKaHZivK98xa47/Om7oSQADktyrAe2p1FKvzY3UloyUXJxJwMXoXY+?= =?us-ascii?Q?H3Oeds7oL8kIH2huJrcdnKU89udrSCw4BBzmYCgA8EpcQwedgd0+90gOd0Mv?= =?us-ascii?Q?GSGhDbxCHo0kyo/3KbDgTQzNYY4W2KxgNKEAVBBSaTaWN2IQvRcsWFtAXRv/?= =?us-ascii?Q?OBHz5Nxl6BNzro2z2gecg07vU/wSaAXO1ifWy1xkrtMB0AaBQm9Y32+zDepr?= =?us-ascii?Q?qmRLKlu8/FHzR8A/9X602bUN6rjzGqygE1MYgXDRqwglRkIYfrinvSWyTT6q?= =?us-ascii?Q?iPCkQTBHM+WhGYxKUEezpgoMZ5htKi7xcrOrZ7FEEJX6ycFoI+uoe/IEZnY9?= =?us-ascii?Q?nZ/h9okdj62f7cITzQYFDgBjrj9YxRrZo5UNb2pYQcQXJpY3oo0nw6qsntqg?= =?us-ascii?Q?y17j36fOZFG85YsgqBElBFyBZptSZVZRD5V6cY2ZYzjExt8PDNyV6ZvuIwBG?= =?us-ascii?Q?5JuIUIXDqGRfmQoBTmnMfk52O4FDu6KQbx1tWMSAYyxkz/puueELPV37550y?= x-ms-exchange-antispam-messagedata-1: 8FV4Ok2aNEIkyg== Content-Type: text/plain; charset="us-ascii" Content-ID: <6D90886D3EEF8B428698F5CB7015714A@EURP193.PROD.OUTLOOK.COM> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: internetstiftelsen.se X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM9P193MB1777.EURP193.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 272ce59f-7558-404d-cc31-08da18a25549 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Apr 2022 14:24:32.0233 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: c2aa68f8-18f3-48ae-81ba-02301d121d9a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Epds62QMcPDFBIrmbPmwl1Yp031yOr4TtYmiJqg8OFlW85sx3NuDdHRMt6gsHCevrBEDWpdiPh/VWj3jEkn+wF2f17VedG7wzRtGQUUdydgy7F/ZZbAL5B9KOUcCH3VC X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8P193MB1862 Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-thomassen-dnsop-dnssec-bootstrapping X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2022 14:28:20 -0000 I have read this draft and support it for adoption. I am willing to contrib= ute text, review etc. Best Regards, Roger Murray > On 25 Mar 2022, at 16:27, Benno Overeinder wrote: >=20 > As announced during the DNSOP meeting this week at the IETF 113, we are s= tarting a Call for Adoption for the draft-thomassen-dnsop-dnssec-bootstrapp= ing. With the survey we conducted before the last IETF 112, this draft was= a clear candidate. >=20 > With this email we start a period of two weeks for the call for adoption = of draft-thomassen-dnsop-dnssec-bootstrapping on the mailing list. >=20 > The draft is available here: https://datatracker.ietf.org/doc/draft-thoma= ssen-dnsop-dnssec-bootstrapping/ >=20 > Please review this draft to see if you think it is suitable for adoption = by DNSOP, and comments to the list, clearly stating your view. >=20 > Please also indicate if you are willing to contribute text, review, etc. >=20 > This call for adoption ends: 8 April 2022 >=20 > Thanks, >=20 > Suzanne, Tim and Benno >=20 > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop From nobody Thu Apr 7 07:41:03 2022 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 6B5243A00E9 for ; Thu, 7 Apr 2022 07:41:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.107 X-Spam-Level: X-Spam-Status: No, score=-2.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] 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 0vBe31Sq_jq6 for ; Thu, 7 Apr 2022 07:40:56 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.85]) (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 7A0103A00E0 for ; Thu, 7 Apr 2022 07:40:56 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4KZ3w61Xv4zrV; Thu, 7 Apr 2022 16:40:54 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1649342454; bh=Bw5Lf0yWd/vvWWFe7In7SI4CytLCSmrmNwxKuWyJhOQ=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=UxBh3FUVb3+8eLExSDObrZh6RSGJ42xUjd0SDzG95115Q3PBr9qaru5+XsqBti/4T FnjV1TbSHqUMSbYp1511RaB/Ezm6RjXrJ0Q0sPQHma3hZhf8iBDx6azCYjpaosX4Zo z7E8At3/HKJ4KGOzoMo1M12gT7kkVLGNNE0qKyv0= 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 aJXmKweiEcur; Thu, 7 Apr 2022 16:40:53 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Thu, 7 Apr 2022 16:40:53 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 241132DB125; Thu, 7 Apr 2022 10:40:52 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 22D022DB124; Thu, 7 Apr 2022 10:40:52 -0400 (EDT) Date: Thu, 7 Apr 2022 10:40:52 -0400 (EDT) From: Paul Wouters To: Masataka Ohta cc: "dnsop@ietf.org WG" In-Reply-To: <350d8ab8-0477-b656-8b08-56f7561a7fda@necom830.hpcl.titech.ac.jp> Message-ID: <860d0d0-281e-b8c9-4169-5998a95a581f@nohats.ca> References: <57f1c37b-497c-e1a0-329c-4b9c8b7e197b@necom830.hpcl.titech.ac.jp> <9732682e-78e7-f6bf-84fc-685de22d5e12@necom830.hpcl.titech.ac.jp> <350d8ab8-0477-b656-8b08-56f7561a7fda@necom830.hpcl.titech.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Subject: Re: [DNSOP] DNSSEC as a Best Current Practice X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2022 14:41:02 -0000 On Thu, 7 Apr 2022, Masataka Ohta wrote: > As I wrote: > >>> Such an individual would have to get access, create the records, give >>> them to others, who then have to on-path attack you. At the TLD level >>> and higher, this involves HSMs and physical access restrictions using >>> a “four eyes minimum” approach. > >> Not surprisingly, diginotar was equally strongly secure. > > Are there anyone who still think DNSSEC were cryptographically secure > or had protected TLDs more securely than diginotar? Yes, everyone but you who participated in this thread. Paul From nobody Thu Apr 7 08:01:24 2022 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 4D4313A0859 for ; Thu, 7 Apr 2022 08:01:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 oJBAf-lB2U9m for ; Thu, 7 Apr 2022 08:01:11 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietfa.amsl.com (Postfix) with SMTP id 514103A094C for ; Thu, 7 Apr 2022 08:01:09 -0700 (PDT) Received: (qmail 52046 invoked from network); 7 Apr 2022 14:56:58 -0000 Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 7 Apr 2022 14:56:58 -0000 Message-ID: <00501a4b-0e47-e25e-2791-d0b80a416793@necom830.hpcl.titech.ac.jp> Date: Fri, 8 Apr 2022 00:01:02 +0900 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Content-Language: en-US To: "dnsop@ietf.org WG" References: <57f1c37b-497c-e1a0-329c-4b9c8b7e197b@necom830.hpcl.titech.ac.jp> <9732682e-78e7-f6bf-84fc-685de22d5e12@necom830.hpcl.titech.ac.jp> <350d8ab8-0477-b656-8b08-56f7561a7fda@necom830.hpcl.titech.ac.jp> <860d0d0-281e-b8c9-4169-5998a95a581f@nohats.ca> From: Masataka Ohta In-Reply-To: <860d0d0-281e-b8c9-4169-5998a95a581f@nohats.ca> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] DNSSEC as a Best Current Practice X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2022 15:01:21 -0000 Paul Wouters wrote: >> Are there anyone who still think DNSSEC were cryptographically secure >> or had protected TLDs more securely than diginotar? > > Yes, everyone but you who participated in this thread. That's simply wrong. Are there anyone who still think, with reasons, DNSSEC were cryptographically secure or had protected TLDs more securely than diginotar? Masataka Ohta From nobody Thu Apr 7 08:30:23 2022 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 BE7343A0C0B for ; Thu, 7 Apr 2022 08:30:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.109 X-Spam-Level: X-Spam-Status: No, score=-2.109 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isc.org header.b=WoRzz5XE; dkim=pass (1024-bit key) header.d=isc.org header.b=LNHIMCSi 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 gZ3CAYNObsdS for ; Thu, 7 Apr 2022 08:30:16 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15FB53A0BD8 for ; Thu, 7 Apr 2022 08:30:15 -0700 (PDT) Received: from zimbrang.isc.org (zimbrang.isc.org [149.20.1.12]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx.pao1.isc.org (Postfix) with ESMTPS id 7A1B43AB026; Thu, 7 Apr 2022 15:30:14 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.10.3 mx.pao1.isc.org 7A1B43AB026 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=isc.org; s=ostpay; t=1649345414; bh=P0y2UI385lCI5ioWYVeCA5WyP8KMd5L3e6ynhouQ/pQ=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=WoRzz5XEVhLzN9/tdnBsm+c0jC4IE3wi/g72qUWrgivAFRw/CBhKPly9p2xFzswLL FmAbsmMm/BoVOhBl0U92/IAk2A5DQDXn+mX9zrba8f6wKOC5CiPX9aIIzFkFQ/JUg1 zmyrYsHpUDk+5rbqLxRXiC9k53pa5fvjYJv2ON8c= Received: from zimbrang.isc.org (localhost.localdomain [127.0.0.1]) by zimbrang.isc.org (Postfix) with ESMTPS id 6E60898309F; Thu, 7 Apr 2022 15:30:14 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbrang.isc.org (Postfix) with ESMTP id 4654D9830A0; Thu, 7 Apr 2022 15:30:14 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.10.3 zimbrang.isc.org 4654D9830A0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=05DFB016-56A2-11EB-AEC0-15368D323330; t=1649345414; bh=P0y2UI385lCI5ioWYVeCA5WyP8KMd5L3e6ynhouQ/pQ=; h=Message-ID:Date:MIME-Version:To:From; b=LNHIMCSiQqGJMVlIHi11n5rcMMoP9p0VfQZRQZ1LnnJerusNDjdhnUwce4fgH9Zsi 7jEG/UIxYzQFcVpXZnnDkiiduZyFciBH8DuX+Dko7NfQKWFI7gqrF1Cb3rL1B1ZnfF ik5tqik7T26nToUsuZ2tmN5uoKo6betN/rd2jVO0= Received: from zimbrang.isc.org ([127.0.0.1]) by localhost (zimbrang.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 2rPbxZrcJvKc; Thu, 7 Apr 2022 15:30:14 +0000 (UTC) Received: from [192.168.0.157] (ip-86-49-254-124.net.upcbroadband.cz [86.49.254.124]) by zimbrang.isc.org (Postfix) with ESMTPSA id A712C98309F; Thu, 7 Apr 2022 15:30:13 +0000 (UTC) Message-ID: Date: Thu, 7 Apr 2022 17:30:11 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.0 Content-Language: en-US To: Paul Vixie Cc: dnsop@ietf.org References: <164925410133.8707.7855283268813227906@ietfa.amsl.com> <20220406142614.GD94415@pepino> <2d437493-7f88-5a81-22a9-1bd05081f70a@isc.org> <5fb93410-d751-9c9d-8c25-5a6805f16d68@redbarn.org> From: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= In-Reply-To: <5fb93410-d751-9c9d-8c25-5a6805f16d68@redbarn.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-rrserial-01.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2022 15:30:21 -0000 On 07. 04. 22 15:47, Paul Vixie wrote: > Petr =C5=A0pa=C4=8Dek wrote on 2022-04-06 23:54: >> Hello, >> >> ... >> >> =C2=A0From my perspective, these systems are not rare, quite the contr= ary: >> - PowerDNS with a database backend >> - Multi-master flavors of BIND >> - Various "cloud" auths with dynamic backends >> - Windows DNS with Active Directory (I think) >=20 > because IXFR and NOTIFY and UPDATE use serial numbers, the DNS protocol= =20 > itself is aware of serial numbers. i hope that any recognition of=20 > non-traditional serial numbers will be an optional addition to the=20 > RRSERIAL response, and that if a zone has no actual serial number (so,=20 > it cannot participate in IXFR, NOTIFY, and UPDATE) the RRSERIAL value=20 > will just be a magic number like zero, or just missing altogether. I fail to understand what you mean, can you elaborate? I will try to rephrase myself for clarity: "Let's make this draft _also_ usable for debugging e.g. PowerDNS and=20 multi-master BIND." I cannot see any technical reason not to support it. Moreover this draft=20 does not touch notify or transfer protocol in any way - which is why=20 your e-mail confuses me. --=20 Petr =C5=A0pa=C4=8Dek From nobody Thu Apr 7 08:49:33 2022 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 E74CA3A0DAE for ; Thu, 7 Apr 2022 08:49:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.108 X-Spam-Level: X-Spam-Status: No, score=-7.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable 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 jmkZkAZNZJSE for ; Thu, 7 Apr 2022 08:49:29 -0700 (PDT) Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) (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 2C7ED3A0B02 for ; Thu, 7 Apr 2022 08:49:29 -0700 (PDT) Received: by mail-wr1-x432.google.com with SMTP id c7so8557305wrd.0 for ; Thu, 07 Apr 2022 08:49:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7Agduw29q9pkFBQfE1A6oqSWR9pwrbWe2yaOnSvLigk=; b=qhA0idTAinRHeNBcDFGjhR/BtDN5NMqZm5Moqfv7QNCHba4R8Jf52u3ysIUcPvQdQi H2aieV2goOXrxjaz4Vm2XklvlUNO7eCNIUTdZTL9eXpNly0jUlKqT8EUAfA3qqGaaYFE BJmEK+Ym4R9fq3VJQP/AzXjuwDabeM4VF2+fnoDkY8I48iu07tL9Gf2dXIAQlIRYnZn2 n5qQj1pw1XX8C2lrE+om8Uz6N+wMyQcvvSDbI1macgtSQVrSwpuNhGZUSZRZiNWvCdYK ELThfBfkYf83Sve93X83DnkNXjVc+YQnw2GAT+PnHsmwLwhyAjUag03KM7XHL0GA5h7X zmYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7Agduw29q9pkFBQfE1A6oqSWR9pwrbWe2yaOnSvLigk=; b=d/d2tPUzg8+eBDtDZ2w916BI8kv39u0WhuU46hYliDE/f94jbgWSIs5LiCF0O3AR2x 92KEZcUvtabeXpm/cUvMAfZC4BqnjXt2Ki2G9xNwU+RwhAk3a4IJiCwMFiV8/Drz8mhv fcRWJec4n4tFo9CNbgjaD3zRlwop2Ah51G6LVoQPzFJWbwcGU04J2eyKIWARgStFwgQi hG6WNCLIgsta6qd26VFCFCACwh3/f07vmOlQ9p/Dkzbqbt6GoRTGQ3LFH4zyXxOPK1IK dc1e7yW/nSxPKsNkI1ZSpnQKCno7QPlXNrVWBneWJGU3dBy6N8Y1BTlImHEjej2FJ0tT b5+A== X-Gm-Message-State: AOAM532AUr5fTJoDWd4gsAxwy8HxNpZgRejQglYHcAXaqrZkQ1Q0tC4U FYet79KFUVsmPyxk+c9NxkLRD3wJ1y7PeA0IEZHNfgC3 X-Google-Smtp-Source: ABdhPJy0Kb5GRXHBtB1OS4Dda3TII9bN+jZGSoc8CAo9rZgMrNUEd73H9FMAOskPfly/DuW6Kytaa6aGI4Kkqk0HwBQ= X-Received: by 2002:a5d:6e0c:0:b0:1ef:7cbb:a5aa with SMTP id h12-20020a5d6e0c000000b001ef7cbba5aamr11363174wrz.5.1649346566761; Thu, 07 Apr 2022 08:49:26 -0700 (PDT) MIME-Version: 1.0 References: <164925410133.8707.7855283268813227906@ietfa.amsl.com> <20220406142614.GD94415@pepino> <2d437493-7f88-5a81-22a9-1bd05081f70a@isc.org> <5fb93410-d751-9c9d-8c25-5a6805f16d68@redbarn.org> In-Reply-To: <5fb93410-d751-9c9d-8c25-5a6805f16d68@redbarn.org> From: Dick Franks Date: Thu, 7 Apr 2022 16:48:50 +0100 Message-ID: To: Paul Vixie Cc: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= , IETF DNSOP WG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-rrserial-01.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2022 15:49:31 -0000 On Thu, 7 Apr 2022 at 14:48, Paul Vixie wrote: > > because IXFR and NOTIFY and UPDATE use serial numbers, the DNS protocol > itself is aware of serial numbers. i hope that any recognition of > non-traditional serial numbers will be an optional addition to the > RRSERIAL response, and that if a zone has no actual serial number (so, > it cannot participate in IXFR, NOTIFY, and UPDATE) the RRSERIAL value > will just be a magic number like zero, or just missing altogether. > Magic numbers are messy. Zero-length option preferred, same as the outbound request. Need explicit statement somewhere that zero-length response means that IXFR, NOTIFY, and UPDATE are not supported. Not keen on the implementation-specific blob idea, which is of little use to the general user. Implementers and power users will already have more appropriate debugging tools. --Dick From nobody Thu Apr 7 08:56:42 2022 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 E21183A0BE0 for ; Thu, 7 Apr 2022 08:56:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.108 X-Spam-Level: X-Spam-Status: No, score=-2.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mork.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 bsDmIwcI3PIM for ; Thu, 7 Apr 2022 08:56:20 -0700 (PDT) Received: from louie.mork.no (louie.mork.no [IPv6:2001:41c8:51:8a:feff:ff:fe00:e5]) (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 823483A0D98 for ; Thu, 7 Apr 2022 08:56:19 -0700 (PDT) Received: from canardo.dyn.mork.no ([IPv6:2a01:799:c9f:8600:0:0:0:1]) (authenticated bits=0) by louie.mork.no (8.15.2/8.15.2) with ESMTPSA id 237Fu76x505475 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=OK); Thu, 7 Apr 2022 16:56:10 +0100 Received: from miraculix.mork.no ([IPv6:2a01:799:c9f:8602:8cd5:a7b0:d07:d516]) (authenticated bits=0) by canardo.dyn.mork.no (8.15.2/8.15.2) with ESMTPSA id 237Fu4I72073489 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=OK); Thu, 7 Apr 2022 17:56:07 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mork.no; s=b; t=1649346967; bh=zqGGiXm2Tjie07vflrH5rID5Hr42x4qSpwSk1BVs/xI=; h=From:To:Cc:Subject:References:Date:Message-ID:From; b=C7Cj3d+spMy4A1NTeEZSdA/TThzn71SI9JRfbxPee8Dqd9klaZB+ssZkQTE76Ikxe 4NFNcV4oQykxxnl4ajdv7BImENlgQqXuwEsejFJGv+yLLvUByDgKqkEas5ek01TzcZ JeRsehkD88o10kOspYnY3NhHLfcjUYzihhzvqnSs= Received: (nullmailer pid 717982 invoked by uid 1000); Thu, 07 Apr 2022 15:56:04 -0000 From: =?utf-8?Q?Bj=C3=B8rn_Mork?= To: Masataka Ohta Cc: "dnsop@ietf.org WG" Organization: m References: <57f1c37b-497c-e1a0-329c-4b9c8b7e197b@necom830.hpcl.titech.ac.jp> <9732682e-78e7-f6bf-84fc-685de22d5e12@necom830.hpcl.titech.ac.jp> <350d8ab8-0477-b656-8b08-56f7561a7fda@necom830.hpcl.titech.ac.jp> <860d0d0-281e-b8c9-4169-5998a95a581f@nohats.ca> <00501a4b-0e47-e25e-2791-d0b80a416793@necom830.hpcl.titech.ac.jp> Date: Thu, 07 Apr 2022 17:56:04 +0200 In-Reply-To: <00501a4b-0e47-e25e-2791-d0b80a416793@necom830.hpcl.titech.ac.jp> (Masataka Ohta's message of "Fri, 8 Apr 2022 00:01:02 +0900") Message-ID: <877d80zy3v.fsf@miraculix.mork.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: clamav-milter 0.103.5 at canardo X-Virus-Status: Clean Archived-At: Subject: Re: [DNSOP] DNSSEC as a Best Current Practice X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2022 15:56:26 -0000 Masataka Ohta writes: > Are there anyone who still think, with reasons, DNSSEC were > cryptographically secure or had protected TLDs more securely > than diginotar? Does DNSSEC make the TLD operators less trustworthy in your eyes? Bj=C3=B8rn From nobody Thu Apr 7 09:50:40 2022 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 E0C733A107C for ; Thu, 7 Apr 2022 09:50:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.109 X-Spam-Level: X-Spam-Status: No, score=-2.109 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.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 jDEN1NBNN32Y for ; Thu, 7 Apr 2022 09:50:33 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 DA78F3A1054 for ; Thu, 7 Apr 2022 09:50:32 -0700 (PDT) Received: (qmail 28054 invoked from network); 7 Apr 2022 16:50:30 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:mime-version:content-type; s=6d93.624f1656.k2204; bh=L+yLzklAsnDUsF4mEzBC90X0eTfv4Ye5wNQLQeXr91w=; b=WsDX+hJDqCaa3NTedWauZsx4UFZLl1Kog+4F247mGzKEt2q1MHkybH4m0GYXM2CJVH133PSK6eBLAkBB1huMTL19VEHP20zGLj6ODVcLoTSYT+uhlSyWUjC0uJ036FQCeu6PrduIJq7mHbVDU8otPK8O4jKR6hNE3DkthEyBzpdkUaVh1VVsCv7jH0KGG2pmg9erTpP7imf3hkL2Rq0mSNFdMjLyWyz/CK9VPFn2DPqmpYORsg2MlSWGq6MeBSrc1OW9s5CXSa2/KS1p5SEo8kjAljucatv6Tm6SfP0A+iggQ2uhCGMV4beL3v/AMfTTcza98FXhiWoJAC9BWhVZ5A== Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.3 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 07 Apr 2022 16:50:30 -0000 Received: by ary.qy (Postfix, from userid 501) id AF2633B52BEC; Thu, 7 Apr 2022 12:50:29 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by ary.qy (Postfix) with ESMTP id 137C63B52BCE for ; Thu, 7 Apr 2022 12:50:29 -0400 (EDT) Date: 7 Apr 2022 12:50:28 -0400 Message-ID: <9355318d-a779-400f-9e3b-27b53fa3e9bf@iecc.com> From: "John R. Levine" To: "dnsop@ietf.org WG" X-X-Sender: johnl@ary.qy MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: [DNSOP] Wildcard junk vs NXDOMAIN junk X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2022 16:50:38 -0000 A friend of mine asserts that wildcard DNS records are a problem because hostile clients can use them to fill up DNS caches with junk answers to random queries that match a wildcard. But it seems to me that you can do it just as well with random queries that match nothing and fill up the cache with NXDOMAIN junk answers. Am I missing something here? If you add DNSSEC, with or without RFC 8198 response synthesis, the details change but I don't think answer does, it's about the same either way. I can see attacks where you might use URLs with wildcard names to fill web caches with junk pages (see https://www.web.sp.am/) but that's different. Regards, John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly From nobody Thu Apr 7 10:35:48 2022 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 8D1A63A1109 for ; Thu, 7 Apr 2022 10:35:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.11 X-Spam-Level: X-Spam-Status: No, score=-7.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redbarn.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 jdu-3XMxPPYe for ; Thu, 7 Apr 2022 10:35:40 -0700 (PDT) Received: from util.redbarn.org (util.redbarn.org [IPv6:2001:559:8000:cd::222]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C71643A10E8 for ; Thu, 7 Apr 2022 10:35:36 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by util.redbarn.org (Postfix) with ESMTPS id 5886D1A2423; Thu, 7 Apr 2022 17:35:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=redbarn.org; s=util; t=1649352934; bh=bFIvC70tEwue0A/2ez+nLjog9Xyb7h5JiPhAtCXhA2M=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=iEAOcRI8tecKkNDW5zCn6gQ84IqfFjGfstP3HiJNScffM14YWgZUJUHw3xsIqui5y RCsQS8UJlw1KhvrugS344zxXDxsS39BPQmZtW1tUXKJpBFMDKFdZXk/oWAdnv80ezu KU2TatbINeOQFeGBYMShgNteKQjxUhPEbGLhKorI= Received: from [24.104.150.147] (dhcp-147.access.rits.tisf.net [24.104.150.147]) (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 3E28F7597E; Thu, 7 Apr 2022 17:35:34 +0000 (UTC) To: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= Cc: dnsop@ietf.org References: <164925410133.8707.7855283268813227906@ietfa.amsl.com> <20220406142614.GD94415@pepino> <2d437493-7f88-5a81-22a9-1bd05081f70a@isc.org> <5fb93410-d751-9c9d-8c25-5a6805f16d68@redbarn.org> From: Paul Vixie Message-ID: <8e6e7047-1695-9a1c-e4f6-51308e8e0b36@redbarn.org> Date: Thu, 7 Apr 2022 10:35:35 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 PostboxApp/7.0.54 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-rrserial-01.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2022 17:35:47 -0000 Petr Špaček wrote on 2022-04-07 08:30: > On 07. 04. 22 15:47, Paul Vixie wrote: >> Petr Špaček wrote on 2022-04-06 23:54: >>> ... >> >> because IXFR and NOTIFY and UPDATE use serial numbers, the DNS >> protocol itself is aware of serial numbers. i hope that any >> recognition of non-traditional serial numbers will be an optional >> addition to the RRSERIAL response, and that if a zone has no actual >> serial number (so, it cannot participate in IXFR, NOTIFY, and UPDATE) >> the RRSERIAL value will just be a magic number like zero, or just >> missing altogether. > > I fail to understand what you mean, can you elaborate? > > I will try to rephrase myself for clarity: > > "Let's make this draft _also_ usable for debugging e.g. PowerDNS and > multi-master BIND." > > I cannot see any technical reason not to support it. Moreover this draft > does not touch notify or transfer protocol in any way - which is why > your e-mail confuses me. if a debugging method is needed let's add one but let's decide in advance not to use that debugging method in production or to overload a production method with non-production data. you probably want a text record at example.com.zone.server (chaos class) or similar. it's a good idea and will help, but should not be stuffed into any in-band response such as the rrserial option. -- P Vixie From nobody Thu Apr 7 11:02:57 2022 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 AA2A43A11CD for ; Thu, 7 Apr 2022 11:02:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 7yH1P6POjgl2 for ; Thu, 7 Apr 2022 11:02:54 -0700 (PDT) Received: from mail.nic.cl (mail.nic.cl [200.1.123.8]) (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 3A5113A11CE for ; Thu, 7 Apr 2022 11:02:53 -0700 (PDT) Received: from mail.nic.cl (localhost [127.0.0.1]) by mail.nic.cl (Postfix) with ESMTP id 02E2B195D62EE; Thu, 7 Apr 2022 14:02:51 -0400 (-04) Received: from pepino (unknown [IPv6:2800:150:126:65:4a3d:968a:4938:f63c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.nic.cl (Postfix) with ESMTPSA id DEB61195D6287; Thu, 7 Apr 2022 14:02:50 -0400 (-04) Date: Thu, 7 Apr 2022 14:02:49 -0400 From: Hugo Salgado To: Paul Vixie Cc: dnsop@ietf.org Message-ID: <20220407180249.GA164061@pepino> References: <164925410133.8707.7855283268813227906@ietfa.amsl.com> <28d0d9c8-a8a1-0313-0f25-dd8c7dbac087@redbarn.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="5vNYLRcllDrimb99" Content-Disposition: inline In-Reply-To: <28d0d9c8-a8a1-0313-0f25-dd8c7dbac087@redbarn.org> X-Virus-Scanned: ClamAV using ClamSMTP on Thu Apr 7 14:02:51 2022 -0400 (-04) (mail.nic.cl) Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-rrserial-01.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2022 18:02:56 -0000 --5vNYLRcllDrimb99 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 06:42 07/04, Paul Vixie wrote: > hugo, mauricio, >=20 > i hope you will change your nomenclature. a zone serial applies to an rrs= et > not just to an rr. answers contain rrsets not merely rrs. other than this, > your proposal looks solid to me. >=20 Thank you very much Paul, agree with specifying that it is a set. However it's not clear to me what you mean by *nomenclature*. Is it about changing the name of RRSERIAL to RRSETSERIAL? (Or RRS-SERIAL?) Or will it be enough to clarify it in the introduction and change the references from "resource record" to "resource record set"? Hugo --5vNYLRcllDrimb99 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEV6FHQYxbYRHTM+xJsO5EsOb06a0FAmJPJ0UACgkQsO5EsOb0 6a1c7w//SWq4O2QhJqCjpCU0UlZYZRRB8INytLCSrD1va/ufq3TEipFttRzFyoHI 58q71pkhRTLpNF3HhqaWXZhq6hsq4g94qdij1txCy8Aqod2QgLddFZCHZMMocUQQ JOLezpJGaw0UqVPXCwAmUrsUtIJjbulxdz7ImaCJvIC/gKHLI928+blPj+g7di2q zBffUbZ+L5a+5h9O1Nqy3NL07XHsLWlUFDx5JN1ACsXbE5p4sxfAP9oQL2WVTr/e lfNWB7MQlscjyC2YJoQICUSgym7o21jCjcCkKHKhbzFf7OiBtYrpeQWCI7SkU35q QV2aXyA9odnndFrxmiiHV0avW93KpxKCUvmoxdv22nqjqhY5oF66MI/WotpcTwuT PJqEDdEh0MLtT+SSvl1gIj5I7q2ZoOi2n8gQjp0gS2djndt5JUped8f5ZB1UtKM2 y+CAxQPGrtnC1aWoqYqxXb62tempS7ZNhFE2K1p0W8k8xbRcwgHDaefZzg2OkTnb MzsvPWbdUJTgFEoxCpRCiqJG+xWN+uSrDeU8BZj9WEMpi5jGbEMBQjZVbKoISVJ3 XbhMdbp3ccR0wIJQ5ra33emd4s4djtlAcTewJt1w1Rj0+c4ygkER0Eok/kUhIAXF aagTFfOSP5zsC6ZnOvPUMECVHxNpxpoK1UDBYot2EjjM2HcEhVw= =gS1B -----END PGP SIGNATURE----- --5vNYLRcllDrimb99-- From nobody Thu Apr 7 11:10:26 2022 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 7E6F83A11C4 for ; Thu, 7 Apr 2022 11:10:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.109 X-Spam-Level: X-Spam-Status: No, score=-2.109 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redbarn.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 SAI7chKn5PaI for ; Thu, 7 Apr 2022 11:10:18 -0700 (PDT) Received: from util.redbarn.org (util.redbarn.org [24.104.150.222]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AEFA3A1215 for ; Thu, 7 Apr 2022 11:10:15 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by util.redbarn.org (Postfix) with ESMTPS id A1E4A1A2423; Thu, 7 Apr 2022 18:10:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=redbarn.org; s=util; t=1649355014; bh=S3BF1pAmGup8jVYpOncPL0OFE21+7y5q9cOSTDWCQLY=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=jGFBT6I4+gP66RtESm+1CRv/nM4cKBAI+ULxaCXGKA8xjdPmqy064D9igeEOs69R+ 1VMkKtq/vuYbCilG2jXLBV+IMJGKsd5gvoBj7vmXir4Ejzo7lryL5U16mBfseZGx/1 KcLBHTP4HD64n3tGD7q5YqOy0CSPxKMX0EXAU7OE= Received: from [24.104.150.147] (dhcp-147.access.rits.tisf.net [24.104.150.147]) (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 8704C7597E; Thu, 7 Apr 2022 18:10:14 +0000 (UTC) To: Hugo Salgado Cc: Paul Vixie , dnsop@ietf.org References: <164925410133.8707.7855283268813227906@ietfa.amsl.com> <28d0d9c8-a8a1-0313-0f25-dd8c7dbac087@redbarn.org> <20220407180249.GA164061@pepino> From: Paul Vixie Message-ID: <1f62c1db-b9d4-f7d5-fdfa-c298541875d4@redbarn.org> Date: Thu, 7 Apr 2022 11:10:15 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 PostboxApp/7.0.54 MIME-Version: 1.0 In-Reply-To: <20220407180249.GA164061@pepino> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-rrserial-01.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2022 18:10:25 -0000 Hugo Salgado wrote on 2022-04-07 11:02: > > On 06:42 07/04, Paul Vixie wrote: >> hugo, mauricio, >> >> i hope you will change your nomenclature. a zone serial applies to an rrset >> not just to an rr. answers contain rrsets not merely rrs. other than this, >> your proposal looks solid to me. >> > > Thank you very much Paul, agree with specifying that it is a set. > > However it's not clear to me what you mean by *nomenclature*. Is it > about changing the name of RRSERIAL to RRSETSERIAL? (Or RRS-SERIAL?) > Or will it be enough to clarify it in the introduction and change the > references from "resource record" to "resource record set"? the semantics of an answer are pretty well understood -- the rrset which is in the zone containing the qname is easily found. therefore you could rename the option code to ZONESERIAL or even SERIAL and it would have an unambiguous meaning. but it seems to me you'd be better off with a zero-length option called SERIAL which if set in the query causes the SOA of the answer's zone to be added to the authority section (similar to an RFC 2308 negative proof) and which option would only be echoed in the answer's OPT if the option was supported. you'd want to specify that the SOA in this case is not optional and that its truncation would cause the TC bit to be set. -- P Vixie From nobody Thu Apr 7 11:22:02 2022 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 CFF293A123E; Thu, 7 Apr 2022 11:22:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.106 X-Spam-Level: X-Spam-Status: No, score=-2.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 gVuJI4LAei9F; Thu, 7 Apr 2022 11:21:59 -0700 (PDT) Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::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 EF0703A1244; Thu, 7 Apr 2022 11:21:58 -0700 (PDT) Received: by mail-lj1-x233.google.com with SMTP id g24so8531454lja.7; Thu, 07 Apr 2022 11:21:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XPYctNakvjIWhWWfidkR7CHKFsQaNYdIuMOZHH4GoHQ=; b=JlzsbI8YW01inKQ9K53rsDXn/ezI6ZE2qE64IceHwMuz+U4ruQrwvUJ+dhXKZl2daq EvqlWEYSF7zB/I7aP1c+Rk65LF699b9ihTbvbWqmXHKJf0GBHekmKXipcMEy20aWnrMS cgUdyIOnLdzWnzyjrL+XikoLKCUjJV/n42GC31m6+wGb3xkRvPspFS/e93s3tbIreKZw yNDvrQNoIyo5FLuOw/jsRQmWT3yoslW1rh/phoB/b27DiBHMpjIpAyqANmjkZL1+Iv5G MGY3baU15s9bhRV3lk3+ga49seCu59/8wnsr/NsT3D9ynpXZigvd8JMImFLgPncrxgBM 3ngQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=XPYctNakvjIWhWWfidkR7CHKFsQaNYdIuMOZHH4GoHQ=; b=g6iBXp3GmsSr82pGdaV2AM9/5DM2F31NU+1ZitpCyfLQ5+53ubP8SguvnFDNgB+28G ZUKpwXUNXhDOtGGc55BCJ0aQHMSTZ4C9xXvFbgOEUlllhx28k/XRD0jJmznWszEyKMH+ Y3ZWFu4MgIC2hKYUIZvL9bPdY4NzrW0SZYa8m6F7Ik0l8EhxSwQ28ohh2i3FWWRPQqmj EaUoY4HCy9iBWmNkxNYx1m4skEGf0hkamzv7sjAj2yhN+DfqrOy5yVweopfJ+9SHxaEs gWQAo27OFr/ImggTlix7lcVhu7iCep1IhYhi/mfcAm4iF73GXpyqhcwhHgQMp629GoHG Ot4g== X-Gm-Message-State: AOAM532a9Cqq/3v4hWKHHNrbovHyxtXephYOXGUZkx04qkoxTXIbM6q5 PARfpO+cjpvkpNdJeHQAHlXojEnL5zNJZKIUULiCKBc/ X-Google-Smtp-Source: ABdhPJxwHaZaPKiwvWQq2v1msvO0guekYHzzA+yf3eFTs8j7dhxMF6yzVBxTh0nkrUBv3UnArdMvIAN7Fwr0iEgNN7U= X-Received: by 2002:a2e:8906:0:b0:24a:f907:71b2 with SMTP id d6-20020a2e8906000000b0024af90771b2mr9359637lji.201.1649355716528; Thu, 07 Apr 2022 11:21:56 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Tim Wicinski Date: Thu, 7 Apr 2022 14:21:45 -0400 Message-ID: To: dnsop Cc: dnsop-chairs Content-Type: multipart/alternative; boundary="000000000000978fd005dc148ddb" Archived-At: Subject: Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-nsec3-guidance X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2022 18:22:01 -0000 --000000000000978fd005dc148ddb Content-Type: text/plain; charset="UTF-8" All The WGLC last call has ended, and we feel the document is ready to move forward. The authors have addressed the issues raised, and they should update the document in the Datatracker. We'll then pass it on to the next stage. thanks tim On Wed, Mar 23, 2022 at 7:45 PM Tim Wicinski wrote: > All, > > With the authors feeling there are no outstanding changes and most people > are happy with the current version. So this means it's time: > > This starts a Working Group Last Call for draft-ietf-dnsop-nsec3-guidance- > > Current versions of the draft is available here: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-nsec3-guidance/ > > The Current Intended Status of this document is: Best Current Practice > > Please review the draft and offer relevant comments. > If this does not seem appropriate please speak out. > 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: 7 > April 2022 > > thanks > tim > --000000000000978fd005dc148ddb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

A= ll=C2=A0
=
The = WGLC last call has ended, and we feel the document is ready to move forward= .=C2=A0
<= br>The authors have addressed the issues raised, and they should update the= document in the Datatracker.
We'll then pass it on to the next stage.

thanks
tim


On Wed, Mar 23, 202= 2 at 7:45 PM Tim Wicinski <tjw.iet= f@gmail.com> wrote:
All,=C2=A0

With the authors feeling there are no outstanding changes and m= ost people are happy with the current version.=C2=A0 So this means it's= time:

This starts a Working Group Last Call for draft-ietf-dnsop-ns= ec3-guidance-

Current versions of the draft is available here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-nsec3-= guidance/

The Current Intended Status of this document is: Best = Current Practice

Please review the draft and offer relevant comments= .
If this does not seem appropriate please speak out.
If someone fee= ls 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: 7 April 2022

thanks
tim
--000000000000978fd005dc148ddb-- From nobody Thu Apr 7 11:31:54 2022 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 29D3D3A1270 for ; Thu, 7 Apr 2022 11:31:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 w4M5QzO3sbLO for ; Thu, 7 Apr 2022 11:31:50 -0700 (PDT) Received: from mail.nic.cl (mail.nic.cl [IPv6:2001:1398:1::6008]) (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 AB2303A1260 for ; Thu, 7 Apr 2022 11:31:49 -0700 (PDT) Received: from mail.nic.cl (localhost [127.0.0.1]) by mail.nic.cl (Postfix) with ESMTP id 3A69E195D6304; Thu, 7 Apr 2022 14:31:45 -0400 (-04) Received: from pepino (unknown [IPv6:2800:150:126:65:4a3d:968a:4938:f63c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.nic.cl (Postfix) with ESMTPSA id 1FF1B195D6303; Thu, 7 Apr 2022 14:31:45 -0400 (-04) Date: Thu, 7 Apr 2022 14:31:43 -0400 From: Hugo Salgado To: Petr =?utf-8?B?xaBwYcSNZWs=?= Cc: Paul Vixie , dnsop@ietf.org Message-ID: <20220407183143.GB164061@pepino> References: <164925410133.8707.7855283268813227906@ietfa.amsl.com> <20220406142614.GD94415@pepino> <2d437493-7f88-5a81-22a9-1bd05081f70a@isc.org> <5fb93410-d751-9c9d-8c25-5a6805f16d68@redbarn.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="OwLcNYc0lM97+oe1" Content-Disposition: inline In-Reply-To: X-Virus-Scanned: ClamAV using ClamSMTP on Thu Apr 7 14:31:45 2022 -0400 (-04) (mail.nic.cl) Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-rrserial-01.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2022 18:31:52 -0000 --OwLcNYc0lM97+oe1 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 17:30 07/04, Petr =C5=A0pa=C4=8Dek wrote: > On 07. 04. 22 15:47, Paul Vixie wrote: > > Petr =C5=A0pa=C4=8Dek wrote on 2022-04-06 23:54: > > > Hello, > > >=20 > > > ... > > >=20 > > > =C2=A0From my perspective, these systems are not rare, quite the cont= rary: > > > - PowerDNS with a database backend > > > - Multi-master flavors of BIND > > > - Various "cloud" auths with dynamic backends > > > - Windows DNS with Active Directory (I think) > >=20 > > because IXFR and NOTIFY and UPDATE use serial numbers, the DNS protocol > > itself is aware of serial numbers. i hope that any recognition of > > non-traditional serial numbers will be an optional addition to the > > RRSERIAL response, and that if a zone has no actual serial number (so, > > it cannot participate in IXFR, NOTIFY, and UPDATE) the RRSERIAL value > > will just be a magic number like zero, or just missing altogether. >=20 > I fail to understand what you mean, can you elaborate? >=20 > I will try to rephrase myself for clarity: >=20 > "Let's make this draft _also_ usable for debugging e.g. PowerDNS and > multi-master BIND." >=20 Hi Petr, thank you for your suggestions. The way we see RRSERIAL extension is just as a copy of the SOA serial value. I think what you=E2=80=99re trying to describe on PowerDNS and multi-master BIND, is that the value contained there doesn=E2=80=99t offer any meaning; I assume it could be either 0 or 1 or any custom other value (and here, we can all agree there is a value). In such cases I would still expect an RRSERIAL answer with that specific value, irrespective if it has a meaning, and also, those implementations can just avoid to answer RRSERIAL queries (which BTW it is allowed). Did we understand that correctly, right? So, maybe there's another way of accomplish this need: we can drop entirely this RRSERIAL option, and create a new "ZONEVERSION" EDNS option, that has a new meaning of... well... zone versioning :) So, this ZONEVERSION value would be the SOA serial number in classic zones (like this RRSERIAL proposal) but it would also add a new opaque meaning for the other server implementations. If this new value has another structure, then maybe we need a new field inside ZONEVERSION to differentiate it. If it's just a 32 bits unsigned number just like RRSERIAL, then it's a number, just not the same as the SOA serial value. Hugo --OwLcNYc0lM97+oe1 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEV6FHQYxbYRHTM+xJsO5EsOb06a0FAmJPLgsACgkQsO5EsOb0 6a1nTA//VdyxIIh2Fkul+4qEHYLDm1rATvBRdJv4Tt8OE4rxiisUdQirTF5/zSre ctNiUDFvO0QbeYHGp1c+jKLtZVqKbVtasVbGjQfi44cmNeCzYPLve1R4xWq5EEPq BbNJXGdCjN/+QFSLFFt/kTqI/fHqWTDukQcpiwKWGDq7xg/Ozo2+7wSlytZ8u1Gc 1XyCDhGmNkWoCKQDz3oQ1K37+5ahAYNGGfNcj6boUZ8YzfXL2fshPOIiTz6R3sC6 R7eoSK9kpyOvmMC3P+46zJths4qUyGOaWwt6oHQPkBqBKGQV5nC7F7yyLXgZRDxo 63ZHPi4B6gEZ6+Fstg0r3HdnmRRBdh5HybVF+DDgHWYs47YLWiul2BwEWWn4GXVq xmWuk1QS42kVPi9HH9gRnVqLxnUFnIqZ7eg22VML5rCvNp8iwIu1ti8gfZHXEs15 TCnjKmT0d7hZ8TsTN/0kSOWsdBX9gjd1HXQ0wEh2246TjHATEEqlzE/n9H6yDO3+ SJR+3iiiTl2yLiO69n+sEx3z5IDV6F/t1ODB29RTBF0WCGFZEqEGTKI8oc5WuYq8 Eykdou8T8ivtUTu4df62tLlKhtLV6Anb+zwORjDb/HDQhYqGQb1GByOGVE996B22 UOY6QWMkk944O16QZ4zFGz1QCCNqipldEpJTDzuJuKp8gMbbcYE= =iy6v -----END PGP SIGNATURE----- --OwLcNYc0lM97+oe1-- From nobody Thu Apr 7 11:37:12 2022 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 120A73A1264; Thu, 7 Apr 2022 11:37:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.107 X-Spam-Level: X-Spam-Status: No, score=-2.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 EMckB5ZUChHm; Thu, 7 Apr 2022 11:37:08 -0700 (PDT) Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (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 08B433A0CB3; Thu, 7 Apr 2022 11:37:08 -0700 (PDT) Received: by mail-lf1-x131.google.com with SMTP id e16so11108644lfc.13; Thu, 07 Apr 2022 11:37:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FSyJF/vpmhJi4EXUlOX/xFxeiQQJtLLKdyxR5L41G8Y=; b=e8PHEmXkq/iRr6yC1B4YZZLVQhToy+QfI3Xd7woDEbHay5DddJmfHYQTy82FgcT4FN xsmeXPHYF+QRlVi2mjO6hPlmzV6id2HSK8BWoI9un4xfcidow2vxsQfHhOPsweM5/ZVy QMgOAZwae6BlmEZyOvLeBbhGREmduXHMnvizyXpqn6KnhAtzprLdcZNmxtKa/LBrtoJT t888gllFMv44RpLcpeZtQkO9bIQyxyfuG+nqvmO9ZCci7O5PSkW3TvNihOtNOQ+QyAjQ WQVzYKHW4brdaXE51CQj4reb4LWM4qc1DyabTozi/LTLqekTj40zGciRKUK3RWbvlwqX GY9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FSyJF/vpmhJi4EXUlOX/xFxeiQQJtLLKdyxR5L41G8Y=; b=m2oFgLkAayVrjmoZWCjMn4IwJflkTCEgwlnkGzEqXagxqAaxn/zRPvVAUP0zCeYcfk RNkO6+4Gov60gEEyloNbOpEZN89G4Gixddo02VO1XohL+x0dbTxbZV15RZnOHl9uZOeb OWArwaIlJgz8/wsgcBXj/Qw+eYE2Ty/F2hi7yrNPyWFbcvne8iRruNDMJNOOIKB1wfpt aQVvB2t5VC/gil1lHyAeIZTWoXWdOnPiHqE9iN70xbIXRySgo7/g381reyTS7PvqBZrv tlfIqYQ8ITvaWDpo5/3gxnP7/A0H9M7owprMTXfZuNecJgxBbbMd1uupJqefAYZjruzI 0wxw== X-Gm-Message-State: AOAM5329DdvNubvN7Q+xJqRv/21/4SoNRl7E0HV4XBPnkvVY043MfTfY jwzdFVLZVSKtjyQO8cQYg+a8Lt4Go53Mb4CAXBGTjRcf X-Google-Smtp-Source: ABdhPJz+lBzardjmDzD/8H448CCOvutPoX2xvlqrpdN6J8aqnmIzJ9wsKgohaInsC9NeVqaytmgyJns64qyEWQON/II= X-Received: by 2002:a05:6512:1383:b0:44a:69a9:d336 with SMTP id p3-20020a056512138300b0044a69a9d336mr10174618lfa.493.1649356625233; Thu, 07 Apr 2022 11:37:05 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Tim Wicinski Date: Thu, 7 Apr 2022 14:36:53 -0400 Message-ID: To: dnsop Cc: dnsop-chairs Content-Type: multipart/alternative; boundary="000000000000c14b4105dc14c30d" Archived-At: Subject: Re: [DNSOP] Call for Adoption: DNSSEC as BCP: draft-hoffman-dnssec X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2022 18:37:10 -0000 --000000000000c14b4105dc14c30d Content-Type: text/plain; charset="UTF-8" All The Call for Adoption people has ended and DNSOP has adopted the document. Paul should upload a version of the document with an updated name. He has already captured the issues raised here: https://github.com/paulehoffman/draft-hoffman-dnssec/issues However, please raise any additional issues. As we discussed, the chairs are attempting to fast track this document, with the idea of a Working Group Last Call by June (assuming all open issues have been resolved). thanks tim On Thu, Mar 24, 2022 at 7:07 PM Tim Wicinski wrote: > > All > > If you attended the most recent DNSOP session, you've heard Warren speak > about creating a BCP for DNSSEC, including all of the DNSSEC related RFCs, > in order to make life easier for implementers and DNS operators. > > We want to ask the working group if this is something DNSOP wants to work > on. If so, we can work with Warren to prioritize getting through the > approval process as efficiently as possible. > > > This starts a Call for Adoption for: draft-hoffman-dnssec > > The draft is available here: > https://datatracker.ietf.org/doc/draft-hoffman-dnssec/ > > Please review this draft to see if you think it is suitable for adoption > by DNSOP, and send any comments to the list, clearly stating your view. > > Please also indicate if you are willing to contribute text, review, etc. > > This call for adoption ends: 7 April 2022 > > Thanks, > tim wicinski > For DNSOP co-chairs > > --000000000000c14b4105dc14c30d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
All
The Call for Adoption people has ended and DNSOP has adopted the document= .=C2=A0 Paul should upload a version
of the document with an updated name.=C2=A0 =C2= =A0He has already=C2=A0captured the issues raised here:=C2=A0

https://g= ithub.com/paulehoffman/draft-hoffman-dnssec/issues

However, please raise any ad= ditional issues.=C2=A0=C2=A0

As we discussed, the chairs are attempting to fast track th= is document, with the idea of a Working Group Last Call
by June (assuming all open i= ssues have been resolved).

thanks

tim

On Thu, Mar 24, 2022 at 7:07 PM Tim Wicinski <tjw.ietf@gmail.com>= wrote:
=C2= =A0
All

If you attended the most recent DNSOP session, you've= heard Warren speak about creating a BCP for DNSSEC, including =C2=A0all of= the DNSSEC related RFCs, in order to make life easier for implementers and= DNS operators.

We want to ask the working group if this is somethi= ng DNSOP wants to work on. If so, we can work with Warren to prioritize get= ting through the approval process as efficiently as possible.


Th= is starts a Call for Adoption for: draft-hoffman-dnssec

The draft is= available here: https://datatracker.ietf.org/doc/draft-hoffman-d= nssec/

Please review this draft to see if you think it is suitab= le for adoption
by DNSOP, and send any comments to the list, clearly sta= ting your view.

Please also indicate if you are willing to contribut= e text, review, etc.

This call for adoption ends: 7 April 2022
Thanks,
tim wicinski
For DNSOP co-chairs

--000000000000c14b4105dc14c30d-- From nobody Thu Apr 7 11:44:29 2022 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 AA8AC3A0D30 for ; Thu, 7 Apr 2022 11:44:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.107 X-Spam-Level: X-Spam-Status: No, score=-2.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable 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 YBzAf3kn88mB for ; Thu, 7 Apr 2022 11:44:22 -0700 (PDT) Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) (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 2C17D3A011B for ; Thu, 7 Apr 2022 11:44:22 -0700 (PDT) Received: by mail-wm1-x32c.google.com with SMTP id m67-20020a1ca346000000b0038e6a1b218aso4253407wme.2 for ; Thu, 07 Apr 2022 11:44:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=pTVk+L5tM1tCuisnMVlaHf1FOGgEiFWQwEpfItF//Ig=; b=DKRVSjGJ2cgitycshvYtyQfe5JuaorqfFrogKHqvTohz935LHHXrtNkejNdCiSjV9O 2aWqJSUW6z+c0ydTvh0pkoCdUL9+oRFRAmjxrlWHjZwqcmqJySwFhGkjVG0HEqH5k0sZ oIQ8bhfsiJgSRDF84dtW9cyCWAO3R9bQH9TEw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=pTVk+L5tM1tCuisnMVlaHf1FOGgEiFWQwEpfItF//Ig=; b=Dldsr4ZMRa4AFqnLXCaj6niVdlqbibmXaw8CzDGzsXAUNreg0oovJr0uLqQNTofw5K bguohMd9YWPO6aeg278mWzxfXAlv3ZNogWl7Lj7UUFwRs0RtilidFCjLW55ugq5XOrFr Bd2zFzoYMhwski2JuCJzXLHtiYvP2ZF++Vc8dZeCz+ev+d6kgR+z12WJj+EH3n8/KwZf mNvK9hGG3lUVdOXpsuL7k3euF4e6nRIVWC4EERweagF5ONhkEGZZdYEhsRvIohNcLoNV 5O3bQeuCxAubXaca8K20L9wLArsz8qhhqd/qyCIesFNqgZRwO8HhEq1X7isjgTqTTE7I onBQ== X-Gm-Message-State: AOAM532c35kghZD7KqBdMP8zFh/La5PFZ0vXgOhKg14k+MjNJMBU5sYH ERdms/LLzdij1KYaA2REr7LPyEW4GiIwmXBB X-Google-Smtp-Source: ABdhPJwxUAMkp73N3VNByh/6S50Z9EbNT3mgAFKaGsoW+lovWeHOLLIabDUyHEoFYZj/x0MXg60TaA== X-Received: by 2002:a7b:c7c3:0:b0:389:cbf1:fadf with SMTP id z3-20020a7bc7c3000000b00389cbf1fadfmr13830903wmk.147.1649357059580; Thu, 07 Apr 2022 11:44:19 -0700 (PDT) Received: from smtpclient.apple ([31.223.44.209]) by smtp.gmail.com with ESMTPSA id o8-20020a5d6488000000b002051f1028f6sm21030386wri.111.2022.04.07.11.44.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 07 Apr 2022 11:44:19 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable From: Joe Abley Mime-Version: 1.0 (1.0) Date: Thu, 7 Apr 2022 21:44:18 +0300 Message-Id: <7155233A-DB48-4CFF-95A2-F48E32088EDB@hopcount.ca> References: <1f62c1db-b9d4-f7d5-fdfa-c298541875d4@redbarn.org> Cc: Hugo Salgado , dnsop@ietf.org In-Reply-To: <1f62c1db-b9d4-f7d5-fdfa-c298541875d4@redbarn.org> To: Paul Vixie X-Mailer: iPhone Mail (19E258) Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-rrserial-01.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2022 18:44:28 -0000 On Apr 7, 2022, at 21:10, Paul Vixie w= rote: > but it seems to me you'd be better off with a zero-length option called SE= RIAL which if set in the query causes the SOA of the answer's zone to be add= ed to the authority section (similar to an RFC 2308 negative proof) and whic= h option would only be echoed in the answer's OPT if the option was supporte= d. you'd want to specify that the SOA in this case is not optional and that i= ts truncation would cause the TC bit to be set. That sounds like a lovely and clean way to do this. I like it.=20 Joe= From nobody Thu Apr 7 12:37:01 2022 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 553293A12FF for ; Thu, 7 Apr 2022 12:36:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.106 X-Spam-Level: X-Spam-Status: No, score=-2.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 H8PXUOb-ZrLJ for ; Thu, 7 Apr 2022 12:36:54 -0700 (PDT) Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [IPv6:2a00:1450:4864:20::631]) (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 6E55E3A15B4 for ; Thu, 7 Apr 2022 12:36:54 -0700 (PDT) Received: by mail-ej1-x631.google.com with SMTP id l7so7576411ejn.2 for ; Thu, 07 Apr 2022 12:36:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yFEn0mGI4waGZ+hf3ezJryfXiZlZ5FIavDw3B2Vq0mI=; b=Usq/JYeI5t9O1p2Pq8tpX5O4c6b7qpKxeSeW46h1ybc4eZui7D3JtJEG50ucBnAmeA NI0/M4WeX2N7UlBL88arYrenDV5DSwnCV78HtIjz5QLoyZTddx0aGTl0SGD+gJESYRt8 +qQIjzDc041FWpcOeVX3OoLktR+0T4P+M0bftPzmkYMhMPMYc3TIzPz0KfkICh6+uTh2 HglX6zFiGK+jOmQlP3MdzRcpJuOfuSQaAiyDHR7REJd/kzOQ9MQ2oaIuATnKNaBGECCa euUYYrODyFiT6ABGSqavCDcEKIqUhxNkqP1jhWDdIayvRWUyfXrNsH7TF78YRD+DxVls iDDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=yFEn0mGI4waGZ+hf3ezJryfXiZlZ5FIavDw3B2Vq0mI=; b=ebcMde+lzyCdcgMR5yMDN+Z2g8SspzR8AgIGScS6QnLB35ZX8H42VEn413oDtWNUuS JQY5EwmxygHBjh6A/IAMAZfj9+fZs1BbH6wNBnDkAy4liKgMFaW+oah3+jGAxrHyhsla ort3M+u8Aj/mdnLjrTs+ohcW5LBjKe1iA87UvXfqB+2dNM0+MzqZ047TGDunSYlhQ63P g2ohYE7XB7X4igHtjigLiu8ka1zveLmmDTSxSUgAOWtlGb298MvkJwbNZRO9V6AGvcKP R8F23gDe7HDUz4BjI6BjMtOnIHjq7f7cb1aEma4Dms/C1aMBR2jKLwwvDjXNvuFaL2yA Zi5A== X-Gm-Message-State: AOAM530xCyyjWiAABEgk5hiciNJ1mhzvNb872ipkSj+yhGp2GLvJE5+o CjzNkYjUUObamiVms0AT83mlAs1deDQAaZC4/qADzxJCG7Y= X-Google-Smtp-Source: ABdhPJxFQHK4l+2f5idJDduFArmjcJ/LZakbUE+Z4onzd72lm/xFEs2cjXXutip/igKtrmSJdxHAQuAi/VzEeuX/vTo= X-Received: by 2002:a17:906:7742:b0:6e8:3f85:4da1 with SMTP id o2-20020a170906774200b006e83f854da1mr3267995ejn.495.1649360212444; Thu, 07 Apr 2022 12:36:52 -0700 (PDT) MIME-Version: 1.0 References: <57f1c37b-497c-e1a0-329c-4b9c8b7e197b@necom830.hpcl.titech.ac.jp> <9732682e-78e7-f6bf-84fc-685de22d5e12@necom830.hpcl.titech.ac.jp> <350d8ab8-0477-b656-8b08-56f7561a7fda@necom830.hpcl.titech.ac.jp> In-Reply-To: <350d8ab8-0477-b656-8b08-56f7561a7fda@necom830.hpcl.titech.ac.jp> From: Brian Dickson Date: Thu, 7 Apr 2022 12:36:40 -0700 Message-ID: To: Masataka Ohta Cc: "dnsop@ietf.org WG" Content-Type: multipart/alternative; boundary="00000000000091c85205dc159902" Archived-At: Subject: Re: [DNSOP] DNSSEC as a Best Current Practice X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2022 19:37:00 -0000 --00000000000091c85205dc159902 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Apr 7, 2022 at 5:45 AM Masataka Ohta < mohta@necom830.hpcl.titech.ac.jp> wrote: > As I wrote: > > >> Such an individual would have to get access, create the records, give > >> them to others, who then have to on-path attack you. At the TLD level > >> and higher, this involves HSMs and physical access restrictions using > >> a =E2=80=9Cfour eyes minimum=E2=80=9D approach. > > > Not surprisingly, diginotar was equally strongly secure. > > Are there anyone who still think DNSSEC were cryptographically secure > or had protected TLDs more securely than diginotar? > I'm not sure why "thinks" enters into the conversation. Nobody is entitled to their own facts, only their own opinions. The facts are what matters here: - Each TLD has its own specific infrastructure, practices, etc. - Not all TLDs are equivalent for purposes of comparison of relative security (to each other or when compared to corresponding CA infrastructure and practices) - Each TLD is a monopoly for the purposes of DNSSEC. The TLD operator has exclusive control over the delegations (including DNSSEC components)= to registrants. - Registrants choose the TLD to use when they register a domain - Modulo the restrictions applicable to specific TLDs, the available choices of TLD are substantial - Each CA (including diginotar) is not a monopoly. Any CA can issue a certificate for any domain name. - Each CA has its own specific infrastructure, practices, etc. - Not all CAs are equivalent for purposes of comparison of relative security (to each other or when compared to corresponding TLD infrastructure and practices) Taking these facts into consideration, the following assertions are clear consequences: - Some CAs MAY have stronger infrastructure and practices than some TLDs - Some TLDs MAY have stronger infrastructure and practices than some CAs - It MAY be the case that some TLDs have infrastructure and practices that are not exceeded by those of any CA - Rephrased: some TLDs >=3D all CAs (which includes the boundary condition of "some TLDS =3D=3D some CAs" without explicitly claiming = that set is non-empty) - An attacker who wishes to compromise a domain via a WebPKI certificate, can choose which CA to use for this purpose - An attacker who wishes to compromise a domain via DNSSEC delegation, cannot choose which TLD to use for this purpose Taken together, this means that as long as there exists any CA which is weaker than some TLD, that automatically means that as a global system, DNSSEC is more cryptographically secure than WebPKI. And, given the facts regarding diginotar, this means that as a system, DNSSEC is more cryptographically secure than diginotar. QED Registrants get to choose the TLD. Once that decision has been made, the attacker has no alternatives to that TLD in terms of what would need to be compromised to affect that specific domain. The same is not true of CAs. Any CA being compromised places every domain (regardless of TLD) in jeopardy, if the only protections on certificates are those currently employed (e.g. CT, CRLs, OCSP). If/when DANE (TLSA records) are used to improve certificate validation, the choice of CA for the attacker to compromise is removed from the equation. Brian --00000000000091c85205dc159902 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Apr 7, 2022 at 5:45 AM Masata= ka Ohta <mohta@necom= 830.hpcl.titech.ac.jp> wrote:
As I wrote:

>> Such an individual would have to get access, create the records, g= ive
>> them to others, who then have to on-path attack you. At the TLD le= vel
>> and higher, this involves HSMs and physical access restrictions us= ing
>> a =E2=80=9Cfour eyes minimum=E2=80=9D approach.

> Not surprisingly, diginotar was equally strongly secure.

Are there anyone who still think DNSSEC were cryptographically secure
or had protected TLDs more securely than diginotar?
I'm not sure why "thinks" enters into the conver= sation.

Nobody is entitled to their own facts, onl= y their own opinions.

The facts are what matters h= ere:
  • Each TLD has its own specific infrastructure, practi= ces, etc.
    • Not all TLDs are equivalent for purposes of compariso= n of relative security (to each=C2=A0other or when compared to correspondin= g CA infrastructure and practices)
  • Each TLD is a monopoly for = the purposes of DNSSEC. The TLD operator has exclusive control over the del= egations (including DNSSEC components) to registrants.
  • Registrants = choose the TLD to use when they register a domain
  • Modulo the restri= ctions applicable to specific TLDs, the available choices of TLD are substa= ntial
  • Each CA (including diginotar) is not a monopoly. Any CA can i= ssue a certificate for any domain name.
  • Each CA has its own specifi= c infrastructure, practices, etc.
    • Not all CAs are equivalent fo= r purposes of comparison of relative security (to each=C2=A0other or when c= ompared to corresponding TLD infrastructure and practices)
Ta= king these facts into consideration, the following assertions are clear con= sequences:
  • Some CAs MAY have stronger infrastructure and = practices than some TLDs
  • Some TLDs MAY have stronger infrastructure= and practices than some CAs
  • It MAY be the case that some TLDs have= infrastructure and practices that are not exceeded by those of any CA
    • =
    • Rephrased: some TLDs >=3D all CAs (which includes the boundary c= ondition of "some TLDS =3D=3D some CAs" without explicitly claimi= ng that set is non-empty)
  • An attacker who wishes to compromise= a domain via a WebPKI certificate, can choose which CA to use for this pur= pose
  • An attacker who wishes to compromise a domain via DNSSEC deleg= ation, cannot choose which TLD to use for this purpose
Taken = together, this means that as long as there exists any CA which is weaker th= an some TLD, that automatically means that as a global system, DNSSEC is mo= re cryptographically secure than WebPKI.
And, given the fac= ts regarding diginotar, this means that as a system, DNSSEC is more cryptog= raphically secure than diginotar.

QED
Registrants get to choose the TLD. Once that decision has= been made, the attacker has no alternatives to that TLD in terms of what w= ould need to be compromised to affect that specific domain.
The s= ame is not true of CAs. Any CA being compromised places every domain (regar= dless of TLD) in jeopardy, if the only protections on certificates are thos= e currently employed (e.g. CT, CRLs, OCSP).
If/when DANE (TLSA re= cords) are used to improve certificate validation, the choice of CA for the= attacker to compromise is removed from the equation.

<= /div>
Brian
--00000000000091c85205dc159902-- From nobody Thu Apr 7 12:42:25 2022 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 27C393A15B4; Thu, 7 Apr 2022 12:42:22 -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: 7.46.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dnsop@ietf.org Message-ID: <164936054209.8122.17637562583503846564@ietfa.amsl.com> Date: Thu, 07 Apr 2022 12:42:22 -0700 Archived-At: Subject: [DNSOP] I-D Action: draft-ietf-dnsop-nsec3-guidance-07.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2022 19:42:22 -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 : Guidance for NSEC3 parameter settings Authors : Wes Hardaker Viktor Dukhovni Filename : draft-ietf-dnsop-nsec3-guidance-07.txt Pages : 11 Date : 2022-04-07 Abstract: NSEC3 is a DNSSEC mechanism providing proof of non-existence by promising there are no names that exist between two domainnames within a zone. Unlike its counterpart NSEC, NSEC3 avoids directly disclosing the bounding domainname pairs. This document provides guidance on setting NSEC3 parameters based on recent operational deployment experience. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-nsec3-guidance/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-nsec3-guidance-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-nsec3-guidance-07 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts From nobody Thu Apr 7 12:49:28 2022 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 430953A15D1; Thu, 7 Apr 2022 12:49:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tim Wicinski via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 7.46.0 Auto-Submitted: auto-generated Precedence: bulk Cc: dnsop-chairs@ietf.org, dnsop@ietf.org, iesg-secretary@ietf.org, tjw.ietf@gmail.com Message-ID: <164936096525.25734.763323299718964448@ietfa.amsl.com> Date: Thu, 07 Apr 2022 12:49:25 -0700 Archived-At: Subject: [DNSOP] Publication has been requested for draft-ietf-dnsop-nsec3-guidance-07 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2022 19:49:26 -0000 Tim Wicinski has requested publication of draft-ietf-dnsop-nsec3-guidance-07 as Best Current Practice on behalf of the DNSOP working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-dnsop-nsec3-guidance/ From nobody Thu Apr 7 13:24:54 2022 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 D3E1A3A1720 for ; Thu, 7 Apr 2022 13:24:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.107 X-Spam-Level: X-Spam-Status: No, score=-2.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable 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 mEXMGMx8kLbz for ; Thu, 7 Apr 2022 13:24:48 -0700 (PDT) Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (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 24AC53A1724 for ; Thu, 7 Apr 2022 13:24:48 -0700 (PDT) Received: by mail-wr1-x42d.google.com with SMTP id u3so9534862wrg.3 for ; Thu, 07 Apr 2022 13:24:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=gnZeuYWJhJNNc77/MmG7ch/xw4j5QHlZPokMQIgQ3EI=; b=RMtqZRwWZoRq0DMNZamHOihk3FquqZqJuVaKekSHDNZ8EuBAKX3OS/fVrXYxG3ZniQ sZ2ha67Ba3CF0fgjp85VWOjXOeyoyL2kecSAV/nTIIaH2xToihfjw2fM8l0oEjkPf2iq 5rg2fqjfFci3Bybas7fWsXOp3FkyvwUB52nnWI3s27Fuee0TQtXbm6+kNObTse92zdJX inwOeJYSYOASTO6saXcE7lQwgV+tm2n9+1DBnZeXdIH5gsHB5pvreHZa4Z4eaoWbonb/ bVii+yks+HFb/Tkwh6i0onU0jVih9lykETptpF2fqK8++zIXcJl9vt50o6hdjXc69UpO e1Ig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=gnZeuYWJhJNNc77/MmG7ch/xw4j5QHlZPokMQIgQ3EI=; b=M9G7NbUHT9uL280yuxSizmTLPMxFOu8uvohmf7cbsGVQtaukCkEoR1V38dFPzWq5+J Y9yfkI/tG6QHduw0zWQzymBoVeHb7WPifEA/hqv1Plr3/samVaMw/1qtwUxUxgaXQchF f8/OCo6ZoNIFwt+2e/AfmNkx2OPzD+8QzFMuslm/fKmhel5eHhS4CLZDMD9Q1pZzrZ+5 Irw0xZE9mbRLNAycZyEV9jUP4tLQUP4MReJmuwdKhNcuWxHNfuG7/pMgwU9KtGBLKCsR ZGpyZLUF0a7FeAsBRF0ejqwddMk3fjqDEr1ddAYNPPDmYzRyxV8zRiZomfygtdzB2BrV EhJQ== X-Gm-Message-State: AOAM533khiyQ4JhBwAzM+NumUfSge/L22nH1VLrbH+lo3B7jlMWF1i5i /6INOVJBatw6IxXeFqF9hgKjWDpkLrdGpJVDt1A= X-Google-Smtp-Source: ABdhPJw4KvXy6mssOGxCwHLxQNaO+0ivGeG2/EsuDI0U7JnVSKTSZBfR4YfMuyBIsRT+d1TYviLi0ZhHkrT7973tGrM= X-Received: by 2002:a5d:6e0c:0:b0:1ef:7cbb:a5aa with SMTP id h12-20020a5d6e0c000000b001ef7cbba5aamr12129722wrz.5.1649363086018; Thu, 07 Apr 2022 13:24:46 -0700 (PDT) MIME-Version: 1.0 References: <1f62c1db-b9d4-f7d5-fdfa-c298541875d4@redbarn.org> <7155233A-DB48-4CFF-95A2-F48E32088EDB@hopcount.ca> In-Reply-To: <7155233A-DB48-4CFF-95A2-F48E32088EDB@hopcount.ca> From: Dick Franks Date: Thu, 7 Apr 2022 21:24:09 +0100 Message-ID: To: Joe Abley Cc: Paul Vixie , IETF DNSOP WG , Hugo Salgado Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-rrserial-01.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2022 20:24:53 -0000 On Thu, 7 Apr 2022 at 19:44, Joe Abley wrote: > > On Apr 7, 2022, at 21:10, Paul Vixie wrote: > > > but it seems to me you'd be better off with a zero-length option called= SERIAL which if set in the query causes the SOA of the answer's zone to be= added to the authority section (similar to an RFC 2308 negative proof) and= which option would only be echoed in the answer's OPT if the option was su= pported. you'd want to specify that the SOA in this case is not optional an= d that its truncation would cause the TC bit to be set. > > That sounds like a lovely and clean way to do this. I like it. > This is an excellent idea, requiring trivial client-side support. PV did not say so, but I would expect the SOA's RRSIG to be included in the response. --Dick > Joe > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop From nobody Thu Apr 7 13:39:45 2022 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 D94283A1743; Thu, 7 Apr 2022 13:39: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: 7.46.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dnsop@ietf.org Message-ID: <164936398373.781.3159437192207399883@ietfa.amsl.com> Date: Thu, 07 Apr 2022 13:39:43 -0700 Archived-At: Subject: [DNSOP] I-D Action: draft-ietf-dnsop-dnssec-bcp-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2022 20:39:44 -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 Security Extensions (DNSSEC) Author : Paul Hoffman Filename : draft-ietf-dnsop-dnssec-bcp-00.txt Pages : 8 Date : 2022-04-07 Abstract: This document describes the DNS security extensions (commonly called "DNSSEC") that are specified RFCs 4033, 4034, 4035, and a handful of others. One purpose is to introduce all of the RFCs in one place so that the reader can understand the many aspects of DNSSEC. This document does not update any of those RFCs. Another purpose is to move DNSSEC to Best Current Practice status. This document is currently maintained at https://github.com/paulehoffman/draft-hoffman-dnssec. Issues and pull requests are welcomed. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-bcp/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-dnssec-bcp-00 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts From nobody Thu Apr 7 13:49:20 2022 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 0ADDC3A1755 for ; Thu, 7 Apr 2022 13:49:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.108 X-Spam-Level: X-Spam-Status: No, score=-2.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=frobbit.se 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 Knigx93_--UC for ; Thu, 7 Apr 2022 13:49:11 -0700 (PDT) Received: from mail.frobbit.se (mail.frobbit.se [85.30.129.176]) (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 A13F83A1757 for ; Thu, 7 Apr 2022 13:49:11 -0700 (PDT) Received: from [192.168.10.128] (c-c5dd524e.028-114-73746f27.bbcust.telenor.se [78.82.221.197]) by mail.frobbit.se (Postfix) with ESMTPSA id 95EB02058A; Thu, 7 Apr 2022 22:49:07 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=frobbit.se; s=mail; t=1649364547; bh=584SsHHv2SpJDbc6ppoOwCDJsQFMbpHajJY3avKwg28=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=lMh/lNaYDdmTcW46TCcCQl7acvq6HGFx5JIQwWVmEgij3VAWhMXFh7NeqEd5phHq3 TRAFyUKa3G13R40jGQxBGCgi2atG/2OFMUQ35+zv/AIvle0vNJcSmjNfMcUSfs8ooR roBCLP4VVdoZ2DBewVIW7bUPsCCoiiJ/I5wV2J5E= From: Patrik =?utf-8?b?RsOkbHRzdHLDtm0=?= To: "John R. Levine" Cc: WG Date: Thu, 07 Apr 2022 22:49:05 +0200 X-Mailer: MailMate (1.14r5864) Message-ID: In-Reply-To: <9355318d-a779-400f-9e3b-27b53fa3e9bf@iecc.com> References: <9355318d-a779-400f-9e3b-27b53fa3e9bf@iecc.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_MailMate_40B27E9D-52AD-4BD5-91AE-57383EB6FC64_="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [DNSOP] Wildcard junk vs NXDOMAIN junk X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2022 20:49:18 -0000 This is an OpenPGP/MIME signed message (RFC 3156 and 4880). --=_MailMate_40B27E9D-52AD-4BD5-91AE-57383EB6FC64_= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On 7 Apr 2022, at 18:50, John R. Levine wrote: > A friend of mine asserts that wildcard DNS records are a problem becaus= e hostile clients can use them to fill up DNS caches with junk answers to= random queries that match a wildcard. But it seems to me that you can d= o it just as well with random queries that match nothing and fill up the = cache with NXDOMAIN junk answers. Am I missing something here? I don't think so, part from of course that the TTL of the cached data mig= ht be different depending on whether the query matches something or not. Patrik > If you add DNSSEC, with or without RFC 8198 response synthesis, the det= ails change but I don't think answer does, it's about the same either way= =2E > > I can see attacks where you might use URLs with wildcard names to fill = web caches with junk pages (see https://www.web.sp.am/) but that's differ= ent. > > Regards, > John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for = Dummies", > Please consider the environment before reading this e-mail. https://jl.= ly > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop --=_MailMate_40B27E9D-52AD-4BD5-91AE-57383EB6FC64_= Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iG0EAREKAC0WIQRUH/cJI8i4DDUU3qWsxpsaC4jXzQUCYk9OQg8ccGFmQGZyb2Ji aXQuc2UACgkQrMabGguI181bMgCfQoej4we/ymH/17vsYzWAZLAn314An1bTvQwQ PAVMM3hTtpjyPwP5jdxC =MYdh -----END PGP SIGNATURE----- --=_MailMate_40B27E9D-52AD-4BD5-91AE-57383EB6FC64_=-- From nobody Thu Apr 7 14:26:39 2022 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 979563A17B3 for ; Thu, 7 Apr 2022 14:26:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.107 X-Spam-Level: X-Spam-Status: No, score=-7.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 bRIwk6UovWGZ for ; Thu, 7 Apr 2022 14:26:14 -0700 (PDT) Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) (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 8A0F23A17A9 for ; Thu, 7 Apr 2022 14:26:14 -0700 (PDT) Received: by mail-ed1-x52c.google.com with SMTP id w18so7870139edi.13 for ; Thu, 07 Apr 2022 14:26:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VlFDBlEynVEdgyg5beAuc7br0lXJ3VZcBFZMtgISZII=; b=FfU+01NQV7r/vjQ7tqXVXqIKnq5GPdiKcMseCyw6tjiXj+aCQ6W2Z929oMWEkHBPpm 5pKORGZA/vNRahxuRmAb29cV4mTwmktAX6rKLONcJuTXFYXMctq/J1IHoPOauEVRlTtq cY/qsReYawKVgAxOb60YV2nfFltyXKQHjd2CdKrQeAVrhxZAg27VFcTSr+7n8mY8EqXu cc8VN/ai1Tpos0qvyGTG+6aTs6MfTT8PmbJCQP1XxFCYKgDHnZLe1HS5tb2yFjCVG5qC VqXf5x26AmkD1xzlInl/ehiG3Nx36pD3VjSzqIQd2ppO3FPjS8mYNJ3912ZDpaV01wtk zsGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=VlFDBlEynVEdgyg5beAuc7br0lXJ3VZcBFZMtgISZII=; b=xkgLBreJqazU+PdpdEhlMNqc0NOlNSwcSr9EIAngOIkJX7pphX34k6EH4TxQKVYg6U oZ2OJerbyjx/XPGt2bvs2nQcto+AqKHxzMfLJue3vljLwqdqE6n/5gT7luGeknUQ5al1 3fAmU4rvC6k8FZqtPRNbmF6JllqB9XG1bTbsrZYTnYTRDy3OUU/okZWfYtvkeSSx6rdw FPU4lVzMPrhggC/NLI2pXdCinHWUaVoWEzwobt6i+6YRGLqc/fjDumXXglB/d1OyMP5K jU9KuEZtuPSXpfBMtDvBHDCjUUCpFGhrNLuFhmTROw2V3iN3ZtkiYGr443ulxpBaYLRi TO4Q== X-Gm-Message-State: AOAM531xKJg1h2YY4XE5ryelXWkC1RsbKtVD4cw+h3v7VDeIKE1xQmmy 4AUpRIGS0wa9pmugrvIx91Uxrcbld4xOlqFyKQZGzSU1 X-Google-Smtp-Source: ABdhPJxXSCjtjLQmhZjQ5KCZh/U/285MMrRAhP0os8DwXhkPGxUwkvWWdbZw/XQTf0+57JIZQ09njW9q6QKAnlMrPYI= X-Received: by 2002:a50:baa8:0:b0:415:b0bc:6353 with SMTP id x37-20020a50baa8000000b00415b0bc6353mr16490403ede.220.1649366772371; Thu, 07 Apr 2022 14:26:12 -0700 (PDT) MIME-Version: 1.0 References: <9355318d-a779-400f-9e3b-27b53fa3e9bf@iecc.com> In-Reply-To: <9355318d-a779-400f-9e3b-27b53fa3e9bf@iecc.com> From: Brian Dickson Date: Thu, 7 Apr 2022 14:26:01 -0700 Message-ID: To: "John R. Levine" Cc: "dnsop@ietf.org WG" Content-Type: multipart/alternative; boundary="00000000000092559e05dc172020" Archived-At: Subject: Re: [DNSOP] Wildcard junk vs NXDOMAIN junk X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2022 21:26:21 -0000 --00000000000092559e05dc172020 Content-Type: text/plain; charset="UTF-8" On Thu, Apr 7, 2022 at 9:51 AM John R. Levine wrote: > A friend of mine asserts that wildcard DNS records are a problem because > hostile clients can use them to fill up DNS caches with junk answers to > random queries that match a wildcard. But it seems to me that you can do > it just as well with random queries that match nothing and fill up the > cache with NXDOMAIN junk answers. Am I missing something here? > > If you add DNSSEC, with or without RFC 8198 response synthesis, the > details change but I don't think answer does, it's about the same either > way. > Yep, I agree. However, that does provide motivation for (a) signing zones, and (b) resolvers doing validation with synthesis. Together, those reduce (a) load on auth servers, and (b) cache pollution. Win/win. Brian --00000000000092559e05dc172020 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Apr 7, 2022 at 9:51 AM John R= . Levine <johnl@iecc.com> wrote= :
A friend of mi= ne asserts that wildcard DNS records are a problem because
hostile clients can use them to fill up DNS caches with junk answers to random queries that match a wildcard.=C2=A0 But it seems to me that you can= do
it just as well with random queries that match nothing and fill up the
cache with NXDOMAIN junk answers.=C2=A0 Am I missing something here?

If you add DNSSEC, with or without RFC 8198 response synthesis, the
details change but I don't think answer does, it's about the same e= ither
way.

Yep, I agree.

=
However, that does provide motivation=C2=A0for (a) signing zones, and = (b) resolvers doing validation=C2=A0with synthesis.

Together, those reduce (a) load on auth servers, and (b) cache pollution.= Win/win.

Brian
=C2=A0
--00000000000092559e05dc172020-- From nobody Thu Apr 7 16:12:36 2022 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 5FB843A0E84 for ; Thu, 7 Apr 2022 16:12:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.109 X-Spam-Level: X-Spam-Status: No, score=-2.109 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redbarn.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 nLDq6Uv-sGJh for ; Thu, 7 Apr 2022 16:12:29 -0700 (PDT) Received: from util.redbarn.org (util.redbarn.org [IPv6:2001:559:8000:cd::222]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A3EB3A1908 for ; Thu, 7 Apr 2022 16:12:25 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by util.redbarn.org (Postfix) with ESMTPS id C0B1E1A2423 for ; Thu, 7 Apr 2022 23:12:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=redbarn.org; s=util; t=1649373141; bh=gAvdm1ScbHneUPC+5C3wQsAjhZDE2DEyE7emppLGvYs=; h=Subject:To:References:From:Date:In-Reply-To; b=R+RuPuOHnL3stAf+HV/LFTwFAVkS3rBkS65H+x+NowzG9fu54VpqEvkMp8BezhgwG PU9MmTL3tP2I6sks17S7SCNWoOgF1NkYxNXCFO3KE82UOnhIdBzRDjLvcy2AxZ+Asb /o4GxlI6qEO0qod1TsFBzINZKovJYVUi77113NgY= Received: from [24.104.150.147] (dhcp-147.access.rits.tisf.net [24.104.150.147]) (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 7A3747597E for ; Thu, 7 Apr 2022 23:12:21 +0000 (UTC) To: "dnsop@ietf.org WG" References: <9355318d-a779-400f-9e3b-27b53fa3e9bf@iecc.com> From: Paul Vixie Message-ID: <0a5f3ac5-1901-28f5-c977-806d684710de@redbarn.org> Date: Thu, 7 Apr 2022 16:12:20 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 PostboxApp/7.0.54 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [DNSOP] Wildcard junk vs NXDOMAIN junk X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2022 23:12:35 -0000 Brian Dickson wrote on 2022-04-07 14:26: > ... > > However, that does provide motivation for (a) signing zones, and (b) > resolvers doing validation with synthesis. > > Together, those reduce (a) load on auth servers, and (b) cache > pollution. Win/win. if those pigs had wings, they could indeed fly. (the motivation is assymetric to the benefit, so this is like all other things dnssec related, and most things ipv6 related, and so on.) wildcard synthesis should always have been resolver-side. now we live like this. a zero-length EDNS option with a name like REALWILD that asked the authority server to include *.example.com as an answer's owner name (rather than www.example.com by synthesis) is probably the way out of this hell. -- P Vixie From nobody Thu Apr 7 17:22:02 2022 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 20D663A1AFA for ; Thu, 7 Apr 2022 17:21:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.108 X-Spam-Level: X-Spam-Status: No, score=-7.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isc.org header.b=SgjCmrmD; dkim=pass (1024-bit key) header.d=isc.org header.b=Ui63r+rC 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 slD2dPjIVChl for ; Thu, 7 Apr 2022 17:21:55 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 263613A1AFB for ; Thu, 7 Apr 2022 17:21:54 -0700 (PDT) Received: from zimbrang.isc.org (zimbrang.isc.org [149.20.1.12]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx.pao1.isc.org (Postfix) with ESMTPS id 0E8D73AB008; Fri, 8 Apr 2022 00:21:53 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.10.3 mx.pao1.isc.org 0E8D73AB008 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=isc.org; s=ostpay; t=1649377313; bh=aIn5fCtDno4wX+4fqgmQnjEMMyfLuRcxpGZ96nTn+UA=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=SgjCmrmDmtCWMEPaTlW/x2cQY+Ej33UZuWMd12nUZ9NyYvY8kvuLxtAzFH2pIz6tl vnY/JRoLX/IKCABXOrz0oEoOE9QCeX0QgZSm5/+OcGeIz+5V0S4UQLk9/D3qeo9fL2 rYIZjVy3CKlbOCNSgb+J8Kd+Wjx7J8BhsX0x49/s= Received: from zimbrang.isc.org (localhost.localdomain [127.0.0.1]) by zimbrang.isc.org (Postfix) with ESMTPS id EFAEF98334A; Fri, 8 Apr 2022 00:21:52 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbrang.isc.org (Postfix) with ESMTP id C62DA9833A9; Fri, 8 Apr 2022 00:21:52 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.10.3 zimbrang.isc.org C62DA9833A9 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=05DFB016-56A2-11EB-AEC0-15368D323330; t=1649377312; bh=q3ABTyfSd67jzQuDrzkdQHWaLT6ngtOXPfgBSzbTdR4=; h=Mime-Version:From:Date:Message-Id:To; b=Ui63r+rCkoG9cpW8z/RtQJ1XdBitCxD7eZj4SMpAKSAHBFzYz5Wv7LXyRFyQ7656W q72yO86/zChi1jOi+S/JtAJ4sU1AjSg1DImeM2wx7r5uYi5NL5xo7hxlB18NuCmaY7 9TtWt3yop4+RD9ICYsxjEZRoaVffYEayKxfMVRMg= Received: from zimbrang.isc.org ([127.0.0.1]) by localhost (zimbrang.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id IANqVDtOKwBe; Fri, 8 Apr 2022 00:21:52 +0000 (UTC) Received: from smtpclient.apple (n114-74-26-107.bla4.nsw.optusnet.com.au [114.74.26.107]) by zimbrang.isc.org (Postfix) with ESMTPSA id 2137D98334A; Fri, 8 Apr 2022 00:21:51 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Mark Andrews In-Reply-To: <0a5f3ac5-1901-28f5-c977-806d684710de@redbarn.org> Date: Fri, 8 Apr 2022 10:21:48 +1000 Cc: "dnsop@ietf.org WG" Content-Transfer-Encoding: quoted-printable Message-Id: References: <9355318d-a779-400f-9e3b-27b53fa3e9bf@iecc.com> <0a5f3ac5-1901-28f5-c977-806d684710de@redbarn.org> To: Paul Vixie X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: Subject: Re: [DNSOP] Wildcard junk vs NXDOMAIN junk X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2022 00:22:00 -0000 > On 8 Apr 2022, at 09:12, Paul Vixie = wrote: > Brian Dickson wrote on 2022-04-07 14:26: >> ... >> However, that does provide motivation for (a) signing zones, and (b) = resolvers doing validation with synthesis. >> Together, those reduce (a) load on auth servers, and (b) cache = pollution. Win/win. > if those pigs had wings, they could indeed fly. (the motivation is = assymetric to the benefit, so this is like all other things dnssec = related, and most things ipv6 related, and so on.) >=20 > wildcard synthesis should always have been resolver-side. now we live = like this. a zero-length EDNS option with a name like REALWILD that = asked the authority server to include *.example.com as an answer's owner = name (rather than www.example.com by synthesis) is probably the way out = of this hell. Wildcard synthesis in the resolver only works if you have NSEC/NSEC3 = records (or the equivalent) that shows the non-existence of the QNAME otherwise the resolver would replace explicit = data with synthesised data. Real wildcard + covering NSEC/NSEC3 range would work. Getting rid of OPTOUT would = also help as you can=E2=80=99t synthesise using an OPTOUT NSEC3 record. Zone operators can turn off OPTOUT today. --=20 Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Thu Apr 7 19:40:50 2022 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 286953A18B2 for ; Thu, 7 Apr 2022 19:40:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.109 X-Spam-Level: X-Spam-Status: No, score=-2.109 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redbarn.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 ADLfdbB-qnmD for ; Thu, 7 Apr 2022 19:40:42 -0700 (PDT) Received: from util.redbarn.org (util.redbarn.org [IPv6:2001:559:8000:cd::222]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A9FC3A18B7 for ; Thu, 7 Apr 2022 19:40:40 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by util.redbarn.org (Postfix) with ESMTPS id 5D53E1A2423; Fri, 8 Apr 2022 02:40:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=redbarn.org; s=util; t=1649385637; bh=EVkX/hoeu9k3ZcPDyC4EpZqSgI/5lZ+j5BfvgcwsmsE=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=NN+ll3SSxl2vzyPjRundWD3jF4kOk0Z1isZGfbM4KDFHTGpZLzx4kfP4TaER7XVgU Nb5d7BJMw2xKAxK4ZfcZff8nex9/zX51QgHVpffKU3NFl5GLQ0VRC4E8UrSX5GAejR 2QHjNnhzn/g26IyqPjp0ECxfC3LHin2/zYj87lQ8= Received: from [24.104.150.147] (dhcp-147.access.rits.tisf.net [24.104.150.147]) (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 2A5897597E; Fri, 8 Apr 2022 02:40:37 +0000 (UTC) To: Mark Andrews Cc: Paul Vixie , "dnsop@ietf.org WG" References: <9355318d-a779-400f-9e3b-27b53fa3e9bf@iecc.com> <0a5f3ac5-1901-28f5-c977-806d684710de@redbarn.org> From: Paul Vixie Message-ID: <3cb254ae-f6d9-e8aa-0c50-825be6254e9e@redbarn.org> Date: Thu, 7 Apr 2022 19:40:36 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 PostboxApp/7.0.54 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [DNSOP] Wildcard junk vs NXDOMAIN junk X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2022 02:40:48 -0000 Mark Andrews wrote on 2022-04-07 17:21: > > >> On 8 Apr 2022, at 09:12, Paul Vixie >> wrote: ... >> >> wildcard synthesis should always have been resolver-side. now we >> live like this. a zero-length EDNS option with a name like REALWILD >> that asked the authority server to include *.example.com as an >> answer's owner name (rather than www.example.com by synthesis) is >> probably the way out of this hell. > > Wildcard synthesis in the resolver only works if you have NSEC/NSEC3 > records (or the equivalent) that shows the non-existence of the QNAME > otherwise the resolver would replace explicit data with synthesised > data. Real wildcard + covering NSEC/NSEC3 range would work. Getting > rid of OPTOUT would also help as you can’t synthesise using an > OPTOUT NSEC3 record. Zone operators can turn off OPTOUT today. a feature that only works with dnssec sounds good to me. -- P Vixie From nobody Thu Apr 7 22:05:08 2022 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 461813A1DC6 for ; Thu, 7 Apr 2022 22:05:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 a8SliSC7FzU6 for ; Thu, 7 Apr 2022 22:05:01 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietfa.amsl.com (Postfix) with SMTP id 8C1D03A1DC3 for ; Thu, 7 Apr 2022 22:05:00 -0700 (PDT) Received: (qmail 62150 invoked from network); 8 Apr 2022 05:00:52 -0000 Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 8 Apr 2022 05:00:52 -0000 Message-ID: <0c7478e8-d522-a174-4af4-aa0abffc93f4@necom830.hpcl.titech.ac.jp> Date: Fri, 8 Apr 2022 14:04:57 +0900 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Content-Language: en-US To: =?UTF-8?Q?Bj=c3=b8rn_Mork?= , "dnsop@ietf.org WG" References: <57f1c37b-497c-e1a0-329c-4b9c8b7e197b@necom830.hpcl.titech.ac.jp> <9732682e-78e7-f6bf-84fc-685de22d5e12@necom830.hpcl.titech.ac.jp> <350d8ab8-0477-b656-8b08-56f7561a7fda@necom830.hpcl.titech.ac.jp> <860d0d0-281e-b8c9-4169-5998a95a581f@nohats.ca> <00501a4b-0e47-e25e-2791-d0b80a416793@necom830.hpcl.titech.ac.jp> <877d80zy3v.fsf@miraculix.mork.no> From: Masataka Ohta In-Reply-To: <877d80zy3v.fsf@miraculix.mork.no> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] DNSSEC as a Best Current Practice X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2022 05:05:06 -0000 Bjorn Mork wrote: >> Are there anyone who still think, with reasons, DNSSEC were >> cryptographically secure or had protected TLDs more securely >> than diginotar? > > Does DNSSEC make the TLD operators less trustworthy in your eyes? Good point. A false sense of security that DNSSEC were cryptographically secure motivates the operators ignore DNSSEC operation rules, which are very complicated and hard to follow, for relatively strong physical security, which might be what happened in diginotar. With proper recognition that DNSSEC is not cryptographically secure, operators won't violate rules for physical security of DNSSEC and, instead, stop operating DNSSEC. Masataka Ohta From nobody Thu Apr 7 22:27:38 2022 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 43BC33A1E73 for ; Thu, 7 Apr 2022 22:27:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 K38p5oKwPR65 for ; Thu, 7 Apr 2022 22:27:34 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietfa.amsl.com (Postfix) with SMTP id E8D493A0D2D for ; Thu, 7 Apr 2022 22:27:33 -0700 (PDT) Received: (qmail 62783 invoked from network); 8 Apr 2022 05:23:27 -0000 Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 8 Apr 2022 05:23:27 -0000 Message-ID: <0e2dffab-6afc-b1b6-9028-175f89f0d29e@necom830.hpcl.titech.ac.jp> Date: Fri, 8 Apr 2022 14:27:31 +0900 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Content-Language: en-US To: Brian Dickson , "dnsop@ietf.org WG" References: <57f1c37b-497c-e1a0-329c-4b9c8b7e197b@necom830.hpcl.titech.ac.jp> <9732682e-78e7-f6bf-84fc-685de22d5e12@necom830.hpcl.titech.ac.jp> <350d8ab8-0477-b656-8b08-56f7561a7fda@necom830.hpcl.titech.ac.jp> From: Masataka Ohta In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] DNSSEC as a Best Current Practice X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2022 05:27:37 -0000 Brian Dickson wrote: >> Are there anyone who still think DNSSEC were cryptographically secure >> or had protected TLDs more securely than diginotar? > I'm not sure why "thinks" enters into the conversation. You may replace it with "dreams". > The facts are what matters here: The important facts are that: DNSSEC is not cryptographically secure. DNSSEC "at the TLD level and higher", which include root zone, is only as trustworthy as diginotar. > Taken together, this means that as long as there exists any CA which > is weaker than some TLD, that automatically means that as a global > system, DNSSEC is more cryptographically secure than WebPKI. First, "CA" is terminology not specific to WebPKI, whatever it means, but PKI in general including DNS. That is, a DNSSEC TLD is a CA. Second "any CA which is weaker than some TLD" means not "cryptographically weaker" but "operationally/physically weaker". As such, your conclusion can only be "DNSSEC is more operationally/physically secure than WebPKI" Third, all the CAs, including TLDs, pursuing commercial success have very good appearance using such words as "HSMs" or "four eyes minimum". That is, you can't compare actual operational/physical strength from their formal documents. Remember: >> At the TLD level and higher, this involves HSMs and physical >> access restrictions using a "four eyes minimum" approach. > Not surprisingly, diginotar was equally strongly secure. Masataka Ohta From nobody Thu Apr 7 23:24:38 2022 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 52E283A2013 for ; Thu, 7 Apr 2022 23:24:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.108 X-Spam-Level: X-Spam-Status: No, score=-2.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=switch.ch 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 FsWTjryCmH-c for ; Thu, 7 Apr 2022 23:24:30 -0700 (PDT) Received: from mx3.switch.ch (mx3.switch.ch [85.235.88.34]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FAF13A200F for ; Thu, 7 Apr 2022 23:24:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=switch.ch; l=6141; s=selector1; t=1649399070; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=eDlcgcUJuEcGbQ0Fivw+k4405CmNT7XCf9+Zfk/gJcY=; b=Jnd6hwBbcizQX5bre2jEiePSw9cy4Yw5SoBTEIIrX8pxrZazcuoHWpIb JO8fy1ewIOAEYxlF7Eq+CTEYGbP3k+xoELOMb4yu8X/N3xfAlrJdiNtVh IIALKRzVuDHdq0OveZBh4blT9quvefSWz4W2RhIRxdKLyJkmeqsHflgaO o7jqG2YlhOxxVDqsX0ieibVlaIvk7Sd0/p32b7LT0Xj4QlQoDeCQbzLME Vp4a9T+Ckbc7y738gN62SJQ0DBtK8df7iLyvixhZS+QfjFbkh8gjn27ZU H7JO9wEMgj+RCtcD86alHXPiIUtlVJXR5MjiJnWeQ01oFP59bJRSzsmwh Q==; X-IronPort-MAIL-FROM: michael.hausding@switch.ch X-IronPort-RCPT-TO: dnsop@ietf.org X-IronPort-AV: E=Sophos;i="5.90,244,1643670000"; d="asc'?scan'208,217";a="257783" Received: from unknown (HELO SWH-S04-EXC2.swd.switch.ch) ([172.16.60.12]) by mx3int.switch.ch with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Apr 2022 08:24:25 +0200 Received: from SWH-S02-EXC1.swd.switch.ch (172.16.60.11) by SWH-S04-EXC2.swd.switch.ch (172.16.60.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.22; Fri, 8 Apr 2022 08:24:24 +0200 Received: from SWH-S02-EXC1.swd.switch.ch ([fe80::b507:6b:5e39:3ff3]) by SWH-S02-EXC1.swd.switch.ch ([fe80::b507:6b:5e39:3ff3%9]) with mapi id 15.02.0986.022; Fri, 8 Apr 2022 08:24:24 +0200 From: Michael Hausding To: DNSOP Working Group Thread-Topic: [DNSOP] Call for Adoption: draft-thomassen-dnsop-dnssec-bootstrapping Thread-Index: AQHYQF0sPvJyOrV4fk6vszadO2Qucazlf76A Date: Fri, 8 Apr 2022 06:24:24 +0000 Message-ID: <3C08BACA-C41C-4A16-9740-46CDE9CB1D50@switch.ch> References: <8d7e1085-33f3-6a28-3464-3f0105b54182@NLnetLabs.nl> In-Reply-To: <8d7e1085-33f3-6a28-3464-3f0105b54182@NLnetLabs.nl> Accept-Language: en-CH, en-US, de-CH Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3654.120.0.1.13) x-originating-ip: [172.16.60.33] Content-Type: multipart/signed; boundary="Apple-Mail=_64FB36AC-9377-498B-A238-C21A4BE643D4"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-thomassen-dnsop-dnssec-bootstrapping X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2022 06:24:36 -0000 --Apple-Mail=_64FB36AC-9377-498B-A238-C21A4BE643D4 Content-Type: multipart/alternative; boundary="Apple-Mail=_6E5CE983-8D8A-4A36-920B-FB536710303A" --Apple-Mail=_6E5CE983-8D8A-4A36-920B-FB536710303A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I=E2=80=99ve read this draft and support adoption Michael > On 25 Mar 2022, at 16:27, Benno Overeinder wrote: >=20 > As announced during the DNSOP meeting this week at the IETF 113, we = are starting a Call for Adoption for the = draft-thomassen-dnsop-dnssec-bootstrapping. With the survey we = conducted before the last IETF 112, this draft was a clear candidate. >=20 > With this email we start a period of two weeks for the call for = adoption of draft-thomassen-dnsop-dnssec-bootstrapping on the mailing = list. >=20 > The draft is available here: = https://datatracker.ietf.org/doc/draft-thomassen-dnsop-dnssec-bootstrappin= g/ >=20 > Please review this draft to see if you think it is suitable for = adoption by DNSOP, and comments to the list, clearly stating your view. >=20 > Please also indicate if you are willing to contribute text, review, = etc. >=20 > This call for adoption ends: 8 April 2022 >=20 > Thanks, >=20 > Suzanne, Tim and Benno >=20 > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop --Apple-Mail=_6E5CE983-8D8A-4A36-920B-FB536710303A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
I=E2=80=99ve read this draft and support adoption 


Michael



On 25 Mar 2022, at 16:27, Benno Overeinder <benno@NLnetLabs.nl> = wrote:

As announced during the DNSOP meeting this week at the IETF = 113, we are starting a Call for Adoption for the = draft-thomassen-dnsop-dnssec-bootstrapping.  With the survey we = conducted before the last IETF 112, this draft was a clear candidate.

With this email we start a period of two weeks = for the call for adoption of draft-thomassen-dnsop-dnssec-bootstrapping = on the mailing list.

The draft is available = here: https://datatracker.ietf.org/doc/draft-thomassen-dnsop-dnssec-b= ootstrapping/

Please review this draft = to see if you think it is suitable for adoption by DNSOP, and comments = to the list, clearly stating your view.

Please also indicate if you are willing to contribute text, = review, etc.

This call for adoption ends: 8 = April 2022

Thanks,

Suzanne, Tim and Benno

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

= --Apple-Mail=_6E5CE983-8D8A-4A36-920B-FB536710303A-- --Apple-Mail=_64FB36AC-9377-498B-A238-C21A4BE643D4 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----- Comment: GPGTools - http://gpgtools.org iQIzBAEBCAAdFiEE9zl6U2K2MCzKrqcp4tTfwqks5IQFAmJP1JsACgkQ4tTfwqks 5IQa3RAA3Sg77BCecZnADyXlBRnnonorlW/wf8kP4B3oLuinchei+RyZ2n3fauLo ndGcBw6c3RGn9tTR/fEYHYx2mGdgV204e+T4YzYpe4/eM9Dll9CGHAJPsxawFLvv m/Hkd4RRtsCIpFiJN+3kCNeyFaZDv63jnCVT2DxvmXBRx85N0h+RVrxnAARr3zox 0AT/7iCDV/te9aBQxMuqbcdGG8bxGs6NtIwc2EmsMe4a5BzmPgQIuAD78XSr6Y4+ 8pStC2IcGZ7RgxVA1QOFquWXba+hAxhN+D8O5qt5kovS1BVLTUsFJ4G0xjus0jk3 BfgunaUNpkX+TqKTnOJOYdwQqJvfmKGiLfoortHI8BqNlu6n0QUTF1Hocp0RP6MI BqKTlKbbbGgihpTLGhI6XhvgizrazGNq3L0ei3Te0GZiVhGDEnMNrxJkLPE6/js7 YiJ38zP5gbgLU70xLicrWLWK+38BNzMDWqHOxqptx2RjDo73DdCwe1zyI7oZ+JeD G2FMgwyWjLFAhcriJm4WCb/pK2AG0l/tDzk2fflftZd9YSQNddVxZlU9/8XziYFU rpyDTDJhzYPtFxmQZlsQzGQHtyo5vWg6b/REylJ28yxHjyyo3ugCLrTjSa1FLgT8 cYO+ermFzc/Tf/c95m6+Li4yNCAIpm0lEPMzD0xnq4fG7bE/soY= =SfXU -----END PGP SIGNATURE----- --Apple-Mail=_64FB36AC-9377-498B-A238-C21A4BE643D4-- From nobody Fri Apr 8 02:25:48 2022 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 C945B3A1992 for ; Fri, 8 Apr 2022 02:25:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.107 X-Spam-Level: X-Spam-Status: No, score=-2.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] 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 WiErbKJkOcbV for ; Fri, 8 Apr 2022 02:25:41 -0700 (PDT) Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) (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 DC82D3A198E for ; Fri, 8 Apr 2022 02:25:40 -0700 (PDT) Received: by mail-wm1-x334.google.com with SMTP id 6-20020a1c0206000000b0038ccb70e239so450388wmc.3 for ; Fri, 08 Apr 2022 02:25:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=4GfEpcPKcmkKJU/LdjzjawLqDc2Z3wNE00oEXARbgs8=; b=NL8Bq9GDj+tREae3k2eaCE4u1jrQDw7suSiCfFOdm041dT3uap6NAaUJ1aeSnq9ybc osI5aR49vvEL6JQi9nrKfkqarvxiXJgA/kKjT8eyuyBLrELuWJDpVZNNfLqqWwCxu3PU +ZI6iZyf5QvXQc2XxoamV6ujtREDazRGATmTI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=4GfEpcPKcmkKJU/LdjzjawLqDc2Z3wNE00oEXARbgs8=; b=XvGPakBSfu7pfsIkRfllmC/17h7w5CZNK6VipQo3GqDAfZLmgSCINbg57fCKAGmzco 7f+fgKv/esR3/EhOMVlJAKuuXtRrUxnyw+4Y7yZR1RPaq9eRTntVZFshee9OMvf0GIfX PHxEUmTCJJAdswbrFCnxPvKdxcvUDY+DEhRni2f3/PlID6MHqsgvvJyiJBRprYmZ2EBm 7kFZbMHjA2YNKxHATsXf3D0lzZYgu08IJha/ltOJyppN8YQm7xeqK0Ls3gZlMzL2oVoZ pn5iS+qxGPAhhlRaV0xPGLomGzuo6zqEGouqkChJIuTMH9Ys6fD4PnYVtol/CpckUoDV WDeg== X-Gm-Message-State: AOAM533N4Cu3DusbGzGMl9cRWvxhAiAo245V9zU89//jqx1MGQXdZhUi y5syTABHzVYxCPyfQmwugcVpY0MlFcCsMK+8 X-Google-Smtp-Source: ABdhPJzbmyJWwcuo4/41sBPj1ENDyAGl6xcIWsIs+79q8cs+fR82bPS/JSnGSxtnttU8gvVMaZQNzw== X-Received: by 2002:a05:600c:4256:b0:38e:9caf:8ace with SMTP id r22-20020a05600c425600b0038e9caf8acemr3942782wmm.44.1649409938763; Fri, 08 Apr 2022 02:25:38 -0700 (PDT) Received: from smtpclient.apple ([31.223.44.209]) by smtp.gmail.com with ESMTPSA id l13-20020a05600012cd00b0020617fd5dc6sm10231244wrx.95.2022.04.08.02.25.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 08 Apr 2022 02:25:37 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable From: Joe Abley Mime-Version: 1.0 (1.0) Date: Fri, 8 Apr 2022 12:25:35 +0300 Message-Id: References: <93c34015-f441-20a3-b2b0-54159a70d021@NLnetLabs.nl> Cc: DNSOP Working Group , DNSOP WG Chairs In-Reply-To: <93c34015-f441-20a3-b2b0-54159a70d021@NLnetLabs.nl> To: Benno Overeinder X-Mailer: iPad Mail (19E258) Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-wisser-dnssec-automation X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2022 09:25:46 -0000 On Mar 25, 2022, at 18:36, Benno Overeinder wrote: > Please review this draft to see if you think it is suitable for adoption b= y DNSOP, and comments to the list, clearly stating your view. I think it's clear that there are people who want to do this, I think a stan= dard approach is important to write down, and I think this draft is a perfec= tly reasonable starting point for that. So I think this draft is suitable fo= r adoption by dnsop. > Please also indicate if you are willing to contribute text, review, etc. I am willing to do either or both. Joe= From nobody Fri Apr 8 02:56:28 2022 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 074573A1A77 for ; Fri, 8 Apr 2022 02:56:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.109 X-Spam-Level: X-Spam-Status: No, score=-2.109 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=internetstiftelsen.se header.b=e/BnewAa; dkim=pass (1024-bit key) header.d=internetstiftelsenisverige.onmicrosoft.com header.b=PuFjTcyF 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 02tBaWxKwo18 for ; Fri, 8 Apr 2022 02:56:22 -0700 (PDT) Received: from relay1.iis.se (relay1.iis.se [IPv6:2001:67c:124c:7317::15]) (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 7A50E3A1A74 for ; Fri, 8 Apr 2022 02:56:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=internetstiftelsen.se; s=iis2015; h=mime-version:content-type:in-reply-to:references:message-id:date:subject:cc: to:from:from; bh=T51dW5vbOXnAX/QA4gv8wa+/ZmNYOUIXNo59/Muka04=; b=e/BnewAa5/ccTs2TQyGLN9osM9jF6qNkQQR0U/Gumzr7a8dliye0mx6OGM1HUCjIL4sbvjuSgidfd HqHzK5u2caoyyrCKkB+8NpLF5tOKi23/Yd3JtlgGSTRvoX1WwDXM1OLVp7bEl5hVbOOBMtUWJL90Ce +hlxOlnVSfdwhv3E= Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05lp20205.outbound.protection.outlook.com [2a01:111:f400:7e1a::205]) by relay1.iis.se (Halon) with ESMTPS id 213cf7d9-b722-11ec-a9bd-005056827d92; Fri, 08 Apr 2022 09:56:15 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=P7ugVorWBkq4anytN3AR6OgiIHap7O5A7z/AHba3lmdjLS/wECZHQHOAGL2+r5huvCq8arTgozcZM+EcXV9ZaokCD0EBqSYhyP084lzq9LAKNHM2k7nD9+UXRF9GBV/XztL/Ev9mNIj/1Cm1vQHId9S40I/hAasOK5duVaBsValVI0ZIFtre08wdV4ZfN9d9r14Jqa7zaT28i3LQ9htXjGkxtmdae5dof6gCvfZSqPenvlihF1h8mGi/IQKGe0Q8YbvYJxnhgzlSZSZlMh7vzl2OeJRd6qCYA7IT54xwQCxm4gcjSnD0Jccpl6+YfbQ/kSlyC9Z0M0at4/Ee6T1gGw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=T51dW5vbOXnAX/QA4gv8wa+/ZmNYOUIXNo59/Muka04=; b=TplH6EUuz6bZowca0gsRfK3UxK5GOjH7BiKrFpui5rmQpwmeiAvhKS3vvnAOpOp4EFlRpXJAiB0nu7sa0JSVTsY1VqBEtYILFvZO4aLEovCxG11Me5qu9tmPANcxZyrLXKqYRahs/zvCIr3LsEyBT2HvADmYn5lSIkZDhDhtG87jinT4kij93NeofBKYPw7DYbGZe9Js/2+FfZh8KsXp8GhZ5ksJ9PKfWDiyEqxQ8lJk/dL0lBfZ+76G53pd6TYOXai2CckL1IabT4BHHwS70yENvl5E2uPMfABp/6+cDBQaZ3edTdI4koIVfvLxflDs+tH9TQBrdSknGxGNRr2aQQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=internetstiftelsen.se; dmarc=pass action=none header.from=internetstiftelsen.se; dkim=pass header.d=internetstiftelsen.se; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=internetstiftelsenisverige.onmicrosoft.com; s=selector1-internetstiftelsenisverige-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=T51dW5vbOXnAX/QA4gv8wa+/ZmNYOUIXNo59/Muka04=; b=PuFjTcyFa6eJ0ov8avseYkoMfyvr9zYaCeR2qCQbKVeXakvA2hcVaxb0lkkMet1IIWPjWxQ1fSf7Wh7MS1MaWKcdEHeXW+1tTOh/PPKvhYNsbYbOIWknJxSb5/5ZWwG+gsVuBPcio7suB3Y+3y5B1ERUjQ0FXzdBJES0KzVoWFo= Received: from DU2P193MB2402.EURP193.PROD.OUTLOOK.COM (2603:10a6:10:2f6::8) by AM8P193MB0977.EURP193.PROD.OUTLOOK.COM (2603:10a6:20b:1e9::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5144.25; Fri, 8 Apr 2022 09:56:14 +0000 Received: from DU2P193MB2402.EURP193.PROD.OUTLOOK.COM ([fe80::d1dc:ce37:b582:134f]) by DU2P193MB2402.EURP193.PROD.OUTLOOK.COM ([fe80::d1dc:ce37:b582:134f%4]) with mapi id 15.20.5144.026; Fri, 8 Apr 2022 09:56:14 +0000 From: Nicklas Pousette To: Benno Overeinder , DNSOP Working Group CC: DNSOP WG Chairs Thread-Topic: [DNSOP] Call for Adoption: draft-wisser-dnssec-automation Thread-Index: AQHYQF4mkRWAaYYPSU232IVo7cdalqzl3Hu6 Date: Fri, 8 Apr 2022 09:56:14 +0000 Message-ID: References: <93c34015-f441-20a3-b2b0-54159a70d021@NLnetLabs.nl> In-Reply-To: <93c34015-f441-20a3-b2b0-54159a70d021@NLnetLabs.nl> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=internetstiftelsen.se; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 89b63c03-1570-4025-cc34-08da194604e4 x-ms-traffictypediagnostic: AM8P193MB0977:EE_ x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: HdxUHnEFh8o5TJ+Ex4ffTHCsFy5WtkS34FcOl0rz6GgXHwM5AmS4+o7G2o/t7aNFP8Lb5SWxil8tnH5AG0DNlg1VWxgCdcm9YdU1ZDBTB8xsBkSk4/Qp8QL2mCW9DcX5v/unozpkxVYQRzgLXi7MCWPpIFOA4Eu1gzWw4TQbj4uK4ErfpJoCagjxSon/r2Z2aDgRcA0H4uFc35smjWB13zZcFTZNruTJwX3J0zgTCQSl9metuC8glbdeW+6g7wFRIlyhWwF+aeKcrME69dIkKR9ebeNcZn7KY0JnIZEtRpQn+D3AEoDHvL9+S2z4agFAVV5WnRPxADaNqSzAR/dZWiz1122Y5/VV2oF9inY3S6IpKrC1CIkZd50Y+W5mBLupHaJFzD12Vtyj3DBM8XOjcCkjLRQCNp4sTpnDCYm+8e7uZGN5UdLtB5owUblWPbCEQilxJLhlG51eEXCRBNULfXd8FQ449tDCUE7S1uT969PuJxdX66HHWgBpF5bHpczfNkRWPnnD6gyTe1MGwz50IibkW9juDPQcTNU7I4nAx1JJ6U+E+hsUnzT1YgsO7tDrOQD4+VMM847o0kmQAjTAlaEKo5VyRmdQ4Yxm7ZRDzYh5jP2KO3V3deYLsCDLQMi89no2plrexlBNWk1nonrb68tYaT4gGNA6l4tb8FRf4tEPFRofTPnfIqDSuZSRyYHjoOrLtbJXsFtXFGwwJ5p32SLOnguCyfEKSfr3Ft74RdThaXI+6ZbMojU6tga9yiMtJVSv+MJtXoMDYX/cKMBSusoYGdq7H1pLSlvmoaGknb0= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DU2P193MB2402.EURP193.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(13230001)(4636009)(346002)(39840400004)(396003)(376002)(136003)(366004)(5660300002)(4326008)(53546011)(66446008)(55016003)(110136005)(66574015)(8676002)(66946007)(66556008)(166002)(52536014)(86362001)(64756008)(2906002)(76116006)(66476007)(91956017)(44832011)(7696005)(26005)(6506007)(186003)(38100700002)(316002)(38070700005)(508600001)(33656002)(71200400001)(8936002)(9686003)(966005)(122000001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 2 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?p8Q8oPC0al8Xz6stwLSTRWycYVl4dFmtC71wjXFg8viiRRjLZ4u3pP4D/QKs?= =?us-ascii?Q?P85HrqOtcDD5Ipk1DDygooiL+kiESV05728u4TcYs8vUpX+t4Epwfz6oCcwd?= =?us-ascii?Q?8XOO1887APYeHoxLJVkzd0V+tk+jnH14xL5qPrHkUkbcDFId+/IphwDYh+Iy?= =?us-ascii?Q?pYAVJYtcJsqw6VC6XDcXOgtH1UFNn2M+GPl5jq2wzH0dnefj1P4y/8ClwDDP?= =?us-ascii?Q?J0t2l4oSR/hrTRvLqAW99bAM47tgV8oJRJa07MGLFoDBNgLf+tdIYzER3kTG?= =?us-ascii?Q?1MO427sPdgS2V0ncNWmxwJFx+TNjoX4C0oFaUkLxcJRJM3AEM0MkJQnUuyuS?= =?us-ascii?Q?gCKPZwIwCmeLFciY+NuBoTgDdD1YWJ9NkKZt99tsgkWVDht6XKufcSVvmk0c?= =?us-ascii?Q?5liCUhyE25G5rOZu+p3oD0o51f6U8ANh8DnJrGb7LBgyNY7RP2OyhverL6HA?= =?us-ascii?Q?8duhP1A3dfh4Y759vGnPnexGRDP6TOBCTlLGaRZCz4dNkMhgxUAyM7LklX/j?= =?us-ascii?Q?4pA55GHM+mN2MZUmL+p7KWlgVl7y3IHC+WPP1edtv1vId3ZAhk4KXvHkLFf/?= =?us-ascii?Q?6K/z8X/j1lDZX4Qp1SFei8S+6NLOGET9OcNBJXyc6fmiIZXjrd2Hq/p4DeLw?= =?us-ascii?Q?V9WOEfmW6DU7UPCDLkxN9NcaxbQADyrE7Fiep6FfuWCf0VMir3EoI+GjZjrl?= =?us-ascii?Q?svfNsBEstD+oYT42PeYuUctUJR2RdGg4TChMjNz8KcsKrhaFV5zTO6JIuAFM?= =?us-ascii?Q?Ugreh5r5oOQW1ifIj4aQtfNAMa0dTMI70cj0BKH0S4lNgIfI6P91DwYReock?= =?us-ascii?Q?o4BdVn6XbGxj9rpNv4qOjyGTAP/eeFPmSbtnBfjI5hWjdizYiCpgNB8b67fu?= =?us-ascii?Q?Db2FW6j+SiYzPYE1tDgJYCXJaGZPxVjnlLdoZY/XGcEr0MXvKSWb3CoCLtwn?= =?us-ascii?Q?WGIztd5X2zaDH35n4gZ4QO8xqugkHk7NX3Z71fgqpqxRrPYC4FI9dIS6MF2/?= =?us-ascii?Q?6yQH4u1kaEqaRuamMZDAtTbYRLl2N5oIK+MGbGB0GmX4lmUkzBgOqZZZKimz?= =?us-ascii?Q?N675bCaEXWqw44uTRTpH9YI/QPUiqR+0RJll8eXAT/aymrpTLhNBj1gJ0CAs?= =?us-ascii?Q?bDKXPfsiEZaYDXjlrmrpceXxiJ3eosr1vaM4ri9O+STpr0byZlnogy4qZMto?= =?us-ascii?Q?dldm01mACFXh1fwn7m3IUISfa8V0+LRZoSzRb9Aq32d7qUbRnUgNMxd1FzfJ?= =?us-ascii?Q?TAAwmv+Nekda4N8jMAQcxy4oVxb12mEiIpWsGzyVceID2xETO+NA80vKdwGZ?= =?us-ascii?Q?VR8fMpVVcZTuPM/UbS0CDpnpRpXZI2BGGEIG9uy84n8fJm9bV5HZ4QGGVJsK?= =?us-ascii?Q?P1WM5QJUhQ5j2/fUNNS2K/vuyOH3U3s509Y+YmCG9oNamTmdAWlIWoDY9MaH?= =?us-ascii?Q?viCISXR1N7HnL+ZWH6RPHFqAjyHUYASnZsKX0fR/CR0gpOdr0IzuzisOiovA?= =?us-ascii?Q?bIpNJSdRel84OtgOsCvg2YeS3S/krJVykrBpCx+B2YDzAkapj6ufQ89kvqrO?= =?us-ascii?Q?zwMAOV9mMBlWIpUVSd+f/gkGAIHuDTiMe3aXf2fRCdkPaV3Xmti0UO6+d/nS?= =?us-ascii?Q?QR6xTxi9UfOAIxD/nfaaqdvC5jMxaptXZUzUO1xVhQj3NPfgrTnAqqYsJenE?= =?us-ascii?Q?YLJ0NtODybMOzvU5bU+JHzYdbDTfeMyaYIo0SkVeGIupDw/vtMXCiN8WEleB?= =?us-ascii?Q?q+OiqEoCqoUpDNXuzutFGloEIVtzTQ37wATAHfwOADAEVvLS067bKv5DntMd?= x-ms-exchange-antispam-messagedata-1: RrxwN9s9E6Yqssp8TW1EuC4lrvjE852lDms= Content-Type: multipart/alternative; boundary="_000_DU2P193MB2402957D24FC0F9992F749C792E99DU2P193MB2402EURP_" MIME-Version: 1.0 X-OriginatorOrg: internetstiftelsen.se X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DU2P193MB2402.EURP193.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 89b63c03-1570-4025-cc34-08da194604e4 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Apr 2022 09:56:14.6230 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: c2aa68f8-18f3-48ae-81ba-02301d121d9a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: DTz46qnnnuGrS6fw/NWj/iTIfZr+qYSpz8GTqrYnAgsYOgMDbatwH/V8WUPSiWSQx7wP3T5zcYMxLM+3Nj8DU/+HXALCoteUrTx7kdiEqdPVksrQrcrlh6rF+YHNLeyX X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM8P193MB0977 Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-wisser-dnssec-automation X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2022 09:56:28 -0000 --_000_DU2P193MB2402957D24FC0F9992F749C792E99DU2P193MB2402EURP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I support this draft and am willing to contribute Nicklas Rg, Nicklas Nicklas Pousette Head of DNS Labs The Swedish Internet Foundation +46 73 655 86 11 https://internetstiftelsen.se/en/ Visiting address: Hammarby Kaj 10D, Stockholm, Sweden Mailing address: Box 92073, 120 07 Stockholm, Sweden From: DNSOP on behalf of Benno Overeinder Date: Friday, 25 March 2022 at 16:36 To: DNSOP Working Group Cc: DNSOP WG Chairs Subject: [DNSOP] Call for Adoption: draft-wisser-dnssec-automation As with the previous Call for Adoption today, at this week's DNSOP meeting at IETF 113, we announced that we are initiating a Call for Adoption for the draft-wisser-dnssec-automation. With the survey we conducted for the last IETF 112, this draft was also a clear candidate. With this email we start a period of two weeks for the call for adoption of draft-wisser-dnssec-automation on the mailing list. The draft is available here: https://datatracker.ietf.org/doc/draft-wisser-dnssec-automation/. Please review this draft to see if you think it is suitable for adoption by DNSOP, and comments to the list, clearly stating your view. Please also indicate if you are willing to contribute text, review, etc. This call for adoption ends: 8 April 2022 Thanks, Suzanne, Tim and Benno _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop --_000_DU2P193MB2402957D24FC0F9992F749C792E99DU2P193MB2402EURP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I support this draft and am willing to contribute

 

 

Nicklas

 

 

 

 

 

 

Rg, Nicklas

 

Nicklas Pousette
Head of DNS Labs
The Swedish Internet Foundation

+46 73 655 86 11
https://internetstiftelsen.se/= en/

Visiting address: Hammarby Kaj 10D, Stockholm, Sweden
Mailing address: Box 92073, 120 07 Stockholm, Sweden

 

 

From: DNSOP <dnsop-bou= nces@ietf.org> on behalf of Benno Overeinder <benno@NLnetLabs.nl><= br> Date: Friday, 25 March 2022 at 16:36
To: DNSOP Working Group <dnsop@ietf.org>
Cc: DNSOP WG Chairs <dnsop-chairs@ietf.org>
Subject: [DNSOP] Call for Adoption: draft-wisser-dnssec-automation

As with the previou= s Call for Adoption today, at this week's DNSOP
meeting at IETF 113, we announced that we are initiating a Call for
Adoption for the draft-wisser-dnssec-automation.  With the survey we <= br> conducted for the last IETF 112, this draft was also a clear candidate.

With this email we start a period of two weeks for the call for adoption of draft-wisser-dnssec-automation on the mailing list.

The draft is available here:
https://datatracker.ietf.org/doc/draft-wisser-dnssec-automation/.

Please review this draft to see if you think it is suitable for adoption by DNSOP, and comments to the list, clearly stating your view.

Please also indicate if you are willing to contribute text, review, etc.
This call for adoption ends: 8 April 2022

Thanks,

Suzanne, Tim and Benno

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

--_000_DU2P193MB2402957D24FC0F9992F749C792E99DU2P193MB2402EURP_-- From nobody Fri Apr 8 05:39:27 2022 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 3B36F3A1835 for ; Fri, 8 Apr 2022 05:39:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.109 X-Spam-Level: X-Spam-Status: No, score=-2.109 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isc.org header.b=VxBjB3tZ; dkim=pass (1024-bit key) header.d=isc.org header.b=LI8vjJ/y 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 7ubAmlQUGvYW for ; Fri, 8 Apr 2022 05:39:20 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13F1A3A1833 for ; Fri, 8 Apr 2022 05:39:19 -0700 (PDT) Received: from zimbrang.isc.org (zimbrang.isc.org [149.20.1.12]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx.pao1.isc.org (Postfix) with ESMTPS id 3C9C83AB007; Fri, 8 Apr 2022 12:39:18 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.10.3 mx.pao1.isc.org 3C9C83AB007 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=isc.org; s=ostpay; t=1649421558; bh=HLj69epLTn7GnXSnQ/wsJtx72kiVM1cO7fhgRg0g2gc=; h=Date:To:Cc:References:From:Subject:In-Reply-To; b=VxBjB3tZv1e/NuajRmVGCJdtjg5n5mKqYeOiK36b44HDHVq7synjF/9w+uBBF32or 3wDErgoGE1XD+2dXTqRGQPdKq+WXfqCufHjXY3ls0KUFbvkqy8MEcUZT4O1Se/PZ/p YCZwopBK2ymK2hcwFD+MV7OlLk+fS+X8SWc0MMoM= Received: from zimbrang.isc.org (localhost.localdomain [127.0.0.1]) by zimbrang.isc.org (Postfix) with ESMTPS id 2CA219839C3; Fri, 8 Apr 2022 12:39:18 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbrang.isc.org (Postfix) with ESMTP id F34E39839CD; Fri, 8 Apr 2022 12:39:17 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.10.3 zimbrang.isc.org F34E39839CD DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=05DFB016-56A2-11EB-AEC0-15368D323330; t=1649421558; bh=NKz4vbqkhbRANXrHube6Lnax424Fk1gtSxtEWCSLpgs=; h=Message-ID:Date:MIME-Version:To:From; b=LI8vjJ/yAeyQHXmOK9IW9xsnxEbeD46W77Ndcey7qXL1FeTQh9Tui3aVYNp+kSFEV Rv9fPDsVwZkTgLh4wJdSmHiTSRkusROVqwEYB2HivNabREHSGyapAcG/MUOTTSWdww 07Kz9i+p7BRkvuYDZp+m42k2qYN4IiCeukliC5QQ= Received: from zimbrang.isc.org ([127.0.0.1]) by localhost (zimbrang.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id fy48d-D0ftnN; Fri, 8 Apr 2022 12:39:17 +0000 (UTC) Received: from [192.168.0.157] (ip-86-49-254-124.net.upcbroadband.cz [86.49.254.124]) by zimbrang.isc.org (Postfix) with ESMTPSA id 2A6399839C3; Fri, 8 Apr 2022 12:39:16 +0000 (UTC) Message-ID: Date: Fri, 8 Apr 2022 14:39:14 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.0 Content-Language: en-US To: Hugo Salgado Cc: Paul Vixie , dnsop@ietf.org References: <164925410133.8707.7855283268813227906@ietfa.amsl.com> <20220406142614.GD94415@pepino> <2d437493-7f88-5a81-22a9-1bd05081f70a@isc.org> <5fb93410-d751-9c9d-8c25-5a6805f16d68@redbarn.org> <20220407183143.GB164061@pepino> From: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= In-Reply-To: <20220407183143.GB164061@pepino> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-rrserial-01.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2022 12:39:26 -0000 On 07. 04. 22 20:31, Hugo Salgado wrote: > On 17:30 07/04, Petr =C5=A0pa=C4=8Dek wrote: >> On 07. 04. 22 15:47, Paul Vixie wrote: >>> Petr =C5=A0pa=C4=8Dek wrote on 2022-04-06 23:54: >>>> Hello, >>>> >>>> ... >>>> >>>> =C2=A0From my perspective, these systems are not rare, quite the co= ntrary: >>>> - PowerDNS with a database backend >>>> - Multi-master flavors of BIND >>>> - Various "cloud" auths with dynamic backends >>>> - Windows DNS with Active Directory (I think) >>> >>> because IXFR and NOTIFY and UPDATE use serial numbers, the DNS protoc= ol >>> itself is aware of serial numbers. i hope that any recognition of >>> non-traditional serial numbers will be an optional addition to the >>> RRSERIAL response, and that if a zone has no actual serial number (so= , >>> it cannot participate in IXFR, NOTIFY, and UPDATE) the RRSERIAL value >>> will just be a magic number like zero, or just missing altogether. >> >> I fail to understand what you mean, can you elaborate? >> >> I will try to rephrase myself for clarity: >> >> "Let's make this draft _also_ usable for debugging e.g. PowerDNS and >> multi-master BIND." >> >=20 > Hi Petr, thank you for your suggestions. >=20 > The way we see RRSERIAL extension is just as a copy of the SOA serial > value. >=20 > I think what you=E2=80=99re trying to describe on PowerDNS and multi-ma= ster > BIND, is that the value contained there doesn=E2=80=99t offer any meani= ng; > I assume it could be either 0 or 1 or any custom other value (and here, > we can all agree there is a value). In such cases I would still expect > an RRSERIAL answer with that specific value, irrespective if it has a > meaning, and also, those implementations can just avoid to answer > RRSERIAL queries (which BTW it is allowed). Did we understand that > correctly, right? Yes, that's exactly what I meant. > So, maybe there's another way of accomplish this need: we can drop > entirely this RRSERIAL option, and create a new "ZONEVERSION" EDNS > option, that has a new meaning of... well... zone versioning :) So, > this ZONEVERSION value would be the SOA serial number in classic zones > (like this RRSERIAL proposal) but it would also add a new opaque > meaning for the other server implementations. If this new value has > another structure, then maybe we need a new field inside ZONEVERSION > to differentiate it. If it's just a 32 bits unsigned number just like > RRSERIAL, then it's a number, just not the same as the SOA serial value= . Yes, that's basically what I meant. Let's sketch a wire format for ZONEVERSION option: - 1 byte - flags - 2 bytes - length L - L bytes Flags: - bit 0 - is the value in fact SOA serial? What do you think? --=20 Petr =C5=A0pa=C4=8Dek P.S. I'm going to be AFK for a week or so. Silence from my side does not=20 mean I intentionally ignore responses. From nobody Fri Apr 8 06:19:07 2022 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 1BB923A199D; Fri, 8 Apr 2022 06:18:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, MIME_HTML_ONLY=0.1, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 PzHWOTnhjq67; Fri, 8 Apr 2022 06:18:28 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on060f.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe02::60f]) (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 DB6953A1999; Fri, 8 Apr 2022 06:18:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QnS7luz3skOwNAoaOWar9SIcrCpjNKPhb+7EVdcV+TnYvpwzeI8sKDvHehSHy1a0rtQLweejHd6OKgDUCZQsV/nU8G/ZGP3Si2DQlmIvNg+BFn7u2qZP/lDggwYif9Wa34uYaWyPBcizm+3f9albUstpXrZcrvtu0FNNAJvw/ejghJiDZ8YooLly1LJFd8ildRp+Sk2fjOsiOSoMKWwRigz8S//u9qm8CG+tTh0d91HI5evN/bdI6eS/Z9PlJf1t6vRHgqWruXuftedqXp3oKQyvhcUQ32JDYR4WRuy4a5IPO3kHwucCKfevn9teYwxkHdAN4hkXmH6V6oxs1hr9/Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=rOBnvcmURKssOQRMW2Bu23mlImQbBgiVD88vB2sQqLk=; b=BDZZwHqZJjzfigPbepfwhvRP9HHS3r/Xa3LpwPMVp0Q3Du11KqCYAkAZLtAJu/BX9YfuZ7/057KWH1QGegOOJcAx9/DJOxPLrMywJhWVGb5aFwnDdrzCyBrt/GyPZ7kPElfe+cBH+387Azmx6ORHlS5TGqKIwT/6QeKxOzU9Pf739a2r/QPdCtF+uljShZ1do0hxO47uLobeLx1GGGuk4lWUvqm9PJKKCA2l9VmlQ09CVkpx2UqvkTtkB1oJf5ZjzpWH1IbqR+uECTYoxMoJ2jRC3M+uUPG97h3xk/Tq5Gp+iIEo6kwTP0WzTxz7Hn45zhab9tXssA5uo6FCJFeAQw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=rOBnvcmURKssOQRMW2Bu23mlImQbBgiVD88vB2sQqLk=; b=ip+w+3LZ6BrGfiqNLesI0Fc3i7VxpqPyBbdi5cPc8wo65jSbG9y+hD/GCNkXv4O+W1nTPl2UgZS2fYvDojIujilMma/2Bk1UDfm8L6wxpoXL7HjqOHSLcCJjBQuvy5NCE/sJioXW1BNbwwx3YCLRxfiCQLE2wmkvEQedOiHUeg8= Received: from HE1PR07MB4217.eurprd07.prod.outlook.com (2603:10a6:7:96::33) by AM0PR0702MB3603.eurprd07.prod.outlook.com (2603:10a6:208:22::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5164.8; Fri, 8 Apr 2022 13:18:23 +0000 Received: from HE1PR07MB4217.eurprd07.prod.outlook.com ([fe80::5c96:9284:fd99:5332]) by HE1PR07MB4217.eurprd07.prod.outlook.com ([fe80::5c96:9284:fd99:5332%3]) with mapi id 15.20.5144.019; Fri, 8 Apr 2022 13:18:23 +0000 From: Francesca Palombini To: Ben Schwartz CC: Tim Wicinski , dnsop , dnsop-chairs , The IESG , "draft-ietf-dnsop-svcb-https@ietf.org" Thread-Topic: Francesca Palombini's Discuss on draft-ietf-dnsop-svcb-https-08: (with DISCUSS and COMMENT) Thread-Index: AQHYLoLRt0oe9wF030CMKYktnqnnUayt+1UAgDg8BnY= Date: Fri, 8 Apr 2022 13:18:22 +0000 Message-ID: References: <164625921309.28301.3763925347495901808@ietfa.amsl.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=ericsson.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3297334e-d813-4a6d-c0f0-08da19624221 x-ms-traffictypediagnostic: AM0PR0702MB3603:EE_ x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: WHUxrZpnJaFWqmZ+pnABxmXJq8E1bGP/bzJuaaMrrPcbNUWRNE/NPyk8APMslGYpN9mnM85waeC0fjc1ojZUv8aw47NmRgyxeROATwHf35wiJaimwQ+W8zfhfUlnjsSZkVGziFqDBtjfg9TCZH+vdW81MJGZHJ0PetZLwv28AK5WVza7vzxLSdW1jnK5QyHCISqHclXyG1/Zavssb67khszK6tCM2RZqm8J1sn75LNmM4Mr8ToZ1ZedBjp71Ev9vZ/eg0nrpjX3HqCaPeQdGm2WlCsIyLbCT94L5Y9vFXfMFyhZ9/XpKdMDTfUgCeAFR13DV9s0O/Hg5tta6tdV3/9PtZAWctksvSElBrsXVY0Nh9pTh12bVUz2M9XZD746uWnu9D0PNhdQgmdU9VaSRDhlNqUy4WKjU8SwY5YSVi/a4oJvnauQj/4lUIbjxMd6fi8IPEsx5MU8bmW+QBPdH6EqPPeNnNc1uPKqMQB0ZYl76avKkgf2AKATBeSHTrDakd5IylDyJNUb0yaiDSNV03T/y3Ov2ZOdWkM4cc45FTYRRJHXSOMC77Zq22n3ggzKY+N/QnNNaMEkjoKrQUSiZFPZRcJXbYqVC7abkow/EQjbi867zzYTnNR04mVQrY2NAVkoj5UrUo1FZzCG1pHVh9mvGB2peIyORdD0MaNtnRnLHv168Co5KbNS8gI2DppSzUY1bpHKMeiV2iI+Wf4bjVG1icGw66Eq/boMKMQVV+cBp16T8PtK/TPk08phUTawsR3nILu5nKVX339faMGXOig== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR07MB4217.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(91956017)(54906003)(186003)(76116006)(66946007)(64756008)(9326002)(71200400001)(66446008)(38100700002)(122000001)(9686003)(66476007)(8676002)(86362001)(316002)(6506007)(166002)(53546011)(7696005)(82960400001)(38070700005)(99936003)(52536014)(83380400001)(66556008)(966005)(4326008)(5660300002)(8936002)(33656002)(2906002)(44832011)(55016003)(508600001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 2 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?DKqTtrmu0226CtX0pgwcZkAiFo66md4+D+J6tgT6p5I/Q0PV9Dv03bqG?= =?Windows-1252?Q?YhfzS+Jst5Ajd71woyzhBBkNKasWkzBZfNCTBHupeIVWhDEuDL4O43XS?= =?Windows-1252?Q?c8Xn0FjOKLvESwwzVut1s8LivPLAEnPqTFF+JObR0lBYURYR9vegTRGo?= =?Windows-1252?Q?qi+a4fhRGa+QuVgb+83KTg7IpHp++8uzYYxo/Ds/ce8KMPX2N7UA65ZP?= =?Windows-1252?Q?qPyiGjZ4BtcjpYAScm8x/vxCkXG/0PVTm68/LJ02Lilg6wPEgJh5SNjN?= =?Windows-1252?Q?nTSqiUbnH1TeqwQm+Fdlm3rbDjKPXDT8tafqtWUZCAbnBUCBZiXkTeTd?= =?Windows-1252?Q?qfIA0AlDORPQ4YQS/5nrvE0G/0fzIp5pVrmgMmKN987kQtrhWuln16Vv?= =?Windows-1252?Q?wYjWU392G763OPDRDc9x8bLgy/4kAgVS5l6OYghwNKeFDQsMBlxpdV5k?= =?Windows-1252?Q?DyNx+wrXsWXet/w+lIuk53LBP+0w6zzPtf6ZoeSaYHmJShVBl01XZ/QE?= =?Windows-1252?Q?+JuzoUt1msfqVugb/03YdgIDG2NH01oXe+kVl61IrXcywWHmUgOfpIn6?= =?Windows-1252?Q?xTScLnwdHEq4Dw9x/v5KnXbcMFe3+BdKZ5z6z9T2fY86658I+jb8wjep?= =?Windows-1252?Q?pAU9mFa7W4UYbT1tilIZxZRkzYgsAe29ANqnB+0KJUlAPxUG9pNm1wQD?= =?Windows-1252?Q?cKA7RdPSKqEaey3FijOF2PMj7ZY34xwW//FpEH2+n5CRn5WxsXZwwgLG?= =?Windows-1252?Q?MZ8Ib2aOqer3Wti3RQI7qF8f6V9hrXHSN1m/iSOn89zWDwatnLav3Y6Y?= =?Windows-1252?Q?AB9/uVEytnlvF6XwQGFyy7idykbV/Yku0jgdV7b6G1v4Eyz5/6wCSQ/T?= =?Windows-1252?Q?ws9aQnHTpyxvQ2LXRd5G9VodMyqziVrGTwMOrB0vGWPzyNroPTYuG27F?= =?Windows-1252?Q?hZ0yTlKW3leH5Td+6TOCCyTYe8s0FSrp3YaDxiPA1WYfQE0hu1s8aFdY?= =?Windows-1252?Q?ohQbEUFrlaJCZqg2d2XqAMo3Ie7143lviKnlkAuQCbXUgtHZnRXjlwZq?= =?Windows-1252?Q?voEhfdz0cetxUypyX8FU//IBG6WoIEuazbNh+vdXM6js+TbQYn2ph3Zt?= =?Windows-1252?Q?uvlGPx2OOGt36Vqwdau9vNKj0uX3JtcU9ELXOmy4fhIhgW6oqhAMG9vp?= =?Windows-1252?Q?NwFx1HYOf96Re68wrhESHVoj9r4QwX9JI4MFc3qZu7qyRSaLtIFVX7U1?= =?Windows-1252?Q?Y/ALKJvllp0LhUpn3SFh+aQjsw027rB7xZYjhW7Oa9iQltf7BLOB3pFm?= =?Windows-1252?Q?QVwuy626p4MWwcfum/DgyF3eHp6BRvvnvbrC05UlzTNVCIvBEDr387N/?= =?Windows-1252?Q?ZcNjZZYbK6q1tbumlKps5YNGuccIy5SsiZGShlbRmdAYQo1uAMEPViGt?= =?Windows-1252?Q?eereDGahuvJhn0yRPfss6TOS3p0m5MshcmylZ/Jal/UBQO8cxHxIhHNS?= =?Windows-1252?Q?6laDne5aTjasjw8XGmGc/cJccrTjg18mR9J6MHxI2NvcqPvPwo8AuM0U?= =?Windows-1252?Q?95AIn5MbVFclxurxETb2NsU0jCRyNzKF3IrTDW747atld2YZkUTvoJ4q?= =?Windows-1252?Q?ic3mZXR++MxwvLlIr7oUPwh2vkX8MQ958ecvs2Txlyu4NWC2iwGNa9gu?= =?Windows-1252?Q?bzSoMK0Qjz/xigTZjW8xEjd23BNGkgTposiQMtMoRI6biktdRcunLtLz?= =?Windows-1252?Q?HxeB9NGM98uQCCQPBC7UEcQc5FJs1riMl2QMeSuyYwLq7rYjs9gSFZxu?= =?Windows-1252?Q?DlRZAnngVMWmMFfr4cyZ+dEQ+2XsTPYpTblKYOYVWAdnJm07TkeqCTmd?= =?Windows-1252?Q?FgotiPSbMF29V+08cRLWfZ7PlJIIeEC2CcrWw90sZRlF8BYQJFcCdvnn?= =?Windows-1252?Q?QvvCTEYK?= x-ms-exchange-antispam-messagedata-1: iK0wwyEyjivag2WCbQiVwFfQF6VKSNasjj03cdp4b4OaNnZTRTEQVUCSUj/zm2zDXRYQEQmpPYY1YQ== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="sha256"; boundary="_59B91CD4-2BB4-2B44-A5AE-1BE8F61152B1_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR07MB4217.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3297334e-d813-4a6d-c0f0-08da19624221 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Apr 2022 13:18:23.0063 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: mDJaioQe4Twhj2tWlsdi42qQUXqmWah8IolSDpPa8/PXNFeKTes9Q2xik8RVJVKsEnwsGMSgnwPDn9TohjYSJEyfdMq5otOe2R7WJ2PUcBhJW2nMvhZrqnZ1vBiJZsr2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR0702MB3603 Archived-At: Subject: Re: [DNSOP] Francesca Palombini's Discuss on draft-ietf-dnsop-svcb-https-08: (with DISCUSS and COMMENT) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2022 13:18:33 -0000 --_59B91CD4-2BB4-2B44-A5AE-1BE8F61152B1_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"

Hi Ben,

 

Thank= s for your reply. Some additional thoughts inline.

 

Francesca

 

From: = iesg <iesg-bounc= es@ietf.org> on behalf of Ben Schwartz <bemasc=3D40google.com@dmarc.i= etf.org>
Date: Thursday, 3 March 2022 at 19:27
To: F= rancesca Palombini <francesca.palombini@ericsson.com>
Cc: T= im Wicinski <tjw.ietf@gmail.com>, dnsop <dnsop@ietf.org>, dnsop= -chairs <dnsop-chairs@ietf.org>, The IESG <iesg@ietf.org>, draf= t-ietf-dnsop-svcb-https@ietf.org <draft-ietf-dnsop-svcb-https@ietf.org&g= t;
Subject: Re: Francesca Palombini's Discuss on draft-ietf-dnsop= -svcb-https-08: (with DISCUSS and COMMENT)

=

On Wed, Mar 2, 2022 = at 5:13 PM Francesca Palombini via Datatracker <noreply@ietf.org> wrote:


--------------------------------------------------= --------------------
DISCUSS:
---------------------------------------= -------------------------------

Thank you for the work on this docum= ent

Many thanks to Cullen Jennings for his ART ART review:
https://mailarchive.ietf.org/arch/msg/art/CfAGYlDfw5kPjlhbujmikX43J6Q/.

I am concerned by the use of SHOULD in this document. In several = places (see 1.
below for what I identified as problematic SHOULDs) the d= ocument lacks text
about why these are SHOULD and not MUST or MAY.<= /o:p>

 

FP: Thank you.

...

I also have a number of non blocking comments and q= uestions. I will appreciate
answers to my questions, to improve my under= standing. If any clarification
comes out of it, I hope it will help impr= ove the document.

 

I've attempted to answer questions inline, = and tracked the other comments at https://github.com/Mik= eBishop/dns-alt-svc/issues/372.

 

... 

--------------------------------------------------= --------------------
COMMENT:
---------------------------------------= -------------------------------


2. -----

   Thi= s subsection briefly describes the SVCB RR in a non-normative
  &nb= sp;manner.  (As mentioned above, this all applies equally to the HTTPS=
   RR which shares the same encoding, format, and high-level = semantics.)

FP: I am not sure about why this section is described as= non-normative but does
define requirements etc. Maybe it is normatively= described somewhere else?

 

Yes, this section highlights some= requirements but does not include any normative language.  Any normat= ive requirements mentioned in this section are defined normatively elsewher= e in the document.

 

Th= en
a pointer to that makes sense.

 

OK, we can add more forw= ard references to this section.  (Tracked at http= s://github.com/MikeBishop/dns-alt-svc/issues/371.)

=

 

Also why does this mention encoding and f= ormat
but there is no encoding specified.

 

This section of = the introduction is just an overview, for a reader who is not familiar with= SVCB.  The detailed specification of encodings, formats, and other re= quirements is later in the document.

 

FP: Thanks, I added a note in the gi= thub with a suggestion on text =E2=80=93 basically removing =E2=80=9Cnon-no= rmative manner=E2=80=9D.

 

5. -----

   SvcParams in presentation format MAY appea= r in any order, but keys
   MUST NOT be repeated.

FP: S= eems to contradict

   SvcParamKeys SHALL appear in increas= ing numeric order.

 

Ordering is unspecified in presentation fo= rmat, but must be sorted in wire format.

 

6. -----

   If the client has an in-p= rogress TCP connection to
   [2001:db8::2]:1234, it MAY procee= d with TLS on that connection using
   ech=3D"222..."= ;, even though the other record in the RRSet has higher
   pri= ority.

FP: I believe this is descriptive of the example and should n= ot use BCP 14 MAY.

 

This "MAY" is intended as an exc= eption to "Clients SHOULD try higher-priority alternatives first"= in Section 3.

 

FP: You don=E2=80=99t need to add this as a BCP 14 =E2=80= =9CMAY=E2=80=9D, as =E2=80=9CSHOULD=E2=80=9D already allows for exceptions,= and again this text is only describing an example, so in my opinion should= not be adding requirements but just describe behavior.

 

7. -----

   For example= , the following is a valid list of SvcParams:

   ech=3D...= key65333=3Dex1 key65444=3Dex2 mandatory=3Dkey65444,ech

FP: I expect= ed this to be a comma separated list.

 

Section 2.1 notes that = "SvcParams are a whitespace-separated list".  The SvcParamVa= lue for "mandatory" is a comma-separated list ("key65444,ech= ").

 

FP: Thanks, I missed it.

 

12. -----

   All protocols employing &quo= t;http://" or "https://" URLs SHOULD respect
   = ;HTTPS RRs.  For example, clients that support HTTPS RRs and implement=

FP: I am not sure how the first sentence is supposed to be implemen= ted, hence
why BCP 14 SHOULD is used here. I also think "respect HT= TPS RRs" might not be
the clearest wording.

 

There are= many protocols that are "layered on top" of HTTP in some fashion= , e.g. generating an HTTP URL and performing an HTTP connection as part of = some process.  This text was originally written for WebSocket (wss://)= , but it could also potentially apply to something like MTA-STS, which gene= rates an HTTP URL to fetch information about a mail server.

<= /div>

 

The SHOU= LD applies primarily to implementers of such protocols, who may need to con= figure their HTTP implementations appropriately.

<= p class=3DMsoNormal style=3D'margin-left:36.0pt'> 

I think the word &q= uot;respected" was used because HTTPS-record support is optional for H= TTP in general.  The point here is that HTTPS records are applicable t= o such "embedded" instances of HTTP, and should not be ignored me= rely because HTTP is not the "top layer" protocol.

=

 

FP: I see, t= hank you for the clarification =E2=80=93 it makes sense. I=E2=80=99ll leave= it up to you if you think some wording (such as the one you just wrote abo= ve) might help the reader, or leave it as is.

= --_59B91CD4-2BB4-2B44-A5AE-1BE8F61152B1_ Content-type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCHfww ggU4MIIDIKADAgECAhEAlb4WoPcuRvF7OYJy+ovNljANBgkqhkiG9w0BAQUFADA3MRQwEgYDVQQK DAtUZWxpYVNvbmVyYTEfMB0GA1UEAwwWVGVsaWFTb25lcmEgUm9vdCBDQSB2MTAeFw0wNzEwMTgx MjAwNTBaFw0zMjEwMTgxMjAwNTBaMDcxFDASBgNVBAoMC1RlbGlhU29uZXJhMR8wHQYDVQQDDBZU ZWxpYVNvbmVyYSBSb290IENBIHYxMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAwr7r J/Aho/NpJlV+ncVVFpFc/e8hv1OAei3SkYxjMfDsJPDDpdJyfBBt9De35eZ8eeqMtYKLrki2rADc ZXXsKk1fwYf1IGUrgahHPokjlTAWkH/oVwdI5xmuv0VnsTcbBir+3vmsfYP7Xrrkj5dnvkuOjWQH VzhVaTQ2PRNI70/i02YepM8at142M9S0Br0YAf13hFAARfWMXegjvH7+NeHtUHupMI0Z0wmOaGdd vzyXGFO7KWLFyl5ywceW1NstoLQfaQPs6uJQ8Qw88KzzUy3wHPXtbDk5c4AWyFKwI83gPtzdPEeg uzWK4phoi77lv3Lu0vql7RLt/JgYqSZ23ChLECAc038Wdy3tb4D3SbtTBbtdaMfUyHUWP4lai/cX R9RM8dKJeT5NPZioYd46HtL4XgPgwckcjNONTdOVNrM3X2NjmzMU8C0ma1N8iYwywm7sPSEAOcmh aOJQgy6wOivzNqCsL+RvYcJRCTk+i1O5u2fa3FO5dlk2nUPlIOA9MmCFIlG3xzO73RUvpHimB3uB RjYEht15NceVLDuwoxc15XMftFxZ79rqEGV7etB/n7O0Kjc7cIubW7krt+yyURKXUyla1PASENxP ArsSki9i1D9pQ3wN1vxYdQGInVgWS966kP9HAYkGavZfspBqswKmAoi/s0d+KtnV+mh4NU0CAwEA AaM/MD0wDwYDVR0TAQH/BAUwAwEB/zALBgNVHQ8EBAMCAQYwHQYDVR0OBBYEFPCPWTgAs/WPmpYM 1ev6e6oX6BMSMA0GCSqGSIb3DQEBBQUAA4ICAQC+5FxiTiT0DAj/8NMMaOSTSSI/RCdvu23eg2bO qMwN/PWaBuV3FJHrnUF7mSqE5f/8IcFd8OQfV7d1qaFfAib/18f3Tt5P+PccRsB6T0AsIjXwGbHQ a2cssKjgwEA3NfaEXFzjr0J4/qfJDVDqDYR29lHvg1PGev8OVkkuj3rWDOYnVONNCmByYs2RB9al v8iZa+3EGearTBE4xW8x4m5JyD92gCYDJingNvb2IFPjF3A0F51jaB5r7MNNhrgTMC9dRg1HQ9Ub qlkOuVyNBkitdIdfx/wxVEET4schDp7gHg3hwHtDhZDFiljGZQp4V/LGIw8B2SBL3g/7koV1Klxz jW17JZHK7kWuBksAzNOxWVDaOog7KUNGXpcrVM5Tb41K55b6v3EOQot8/Sig0EjK2sSBTLuic5Mm yOsM1iaItsAkz7u9W+t1fekIjoYzLHl3CWmlifyzcJCHdo/TIrtCzr1zCyAmKtCbPXAeJGzNh3ap F5a3zw2S+44YqZhJ0Z7+YERyIbkZ7cL1MfE5SIiQJHVUFq3O9PhpFGQ5+6O4unBAxyccv8RWU/pj ZdDzHA4W9WuGWE0Y1OQNjqWdW5HcdiRQP8Yq+9m3nLXW5tDZ6BmLFXFIrbfq2FmI1JC/FrPZ6axZ YVTIHLrKwcrhuSBMjzqTiaWgzL/T9nWkdZZtVjCCBfowggPioAMCAQICDwF731DhUf59QOA9prhz QzANBgkqhkiG9w0BAQsFADBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNV BAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMwHhcNMjEwOTEzMTMyMDI0WhcNMjQwOTEz MTMyMDI0WjBiMREwDwYDVQQKDAhFcmljc3NvbjEcMBoGA1UEAwwTRnJhbmNlc2NhIFBhbG9tYmlu aTEvMC0GCSqGSIb3DQEJARYgZnJhbmNlc2NhLnBhbG9tYmluaUBlcmljc3Nvbi5jb20wggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQD1O3e1WObcyyKwjBh4oaxjZv8duhiSjE3Psz4lZPyl AzdMStq+Ybn7L4tFDTxUCqKxLk4oj4e+pU4Zffi5oxUiXkIolQXohBdF/OJmFzzYYCWavXqHFxH6 1bKh9BWJN4amfmoHqlS/EDY8Ib0su5ht0HVloi0zwF6sjVwxP8ytsQ0l6y+I7K432OtjOBz33F+b AEP8svQs7NzNG/5TlxGxuc1TGEA6M7EZ2yIdHv/x0LkVxRH3PGemswFmjTd+BH1S5eySfVNCfxFO WCxgvuFZnFRnzdQDJJ2HZR4Z9DOP7fAM8iJoH/XTYRlELxXWd/TERayEDQoVlPDY3/c+Ush9AgMB AAGjggHGMIIBwjAfBgNVHSMEGDAWgBQcexmel5x2rCA92NzjkWrj2y2mUzAdBgNVHQ4EFgQUV5cE pvQePLiJ/9eJuJnGGDAiZ2EwDgYDVR0PAQH/BAQDAgWgMFUGA1UdIAROMEwwSgYMKwYBBAGCDwID AQESMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5j b20vQ1BTMCsGA1UdEQQkMCKBIGZyYW5jZXNjYS5wYWxvbWJpbmlAZXJpY3Nzb24uY29tMEgGA1Ud HwRBMD8wPaA7oDmGN2h0dHA6Ly9jcmwudHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlk dWFsY2F2My5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMIGCBggrBgEFBQcBAQR2 MHQwKAYIKwYBBQUHMAGGHGh0dHA6Ly9vY3NwMi50cnVzdC50ZWxpYS5jb20wSAYIKwYBBQUHMAKG PGh0dHA6Ly9jYS50cnVzdC50ZWxpYXNvbmVyYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYz LmNlcjANBgkqhkiG9w0BAQsFAAOCAgEAET9WXEAgQzjwaBr0QSAIXlAj0vFNHWYac8TBKo/J0DmC yJaAIFOra3VGwaB5Rh7Zg2HAkeZjUccwsMlcLBHNcTirLpKvzwC6jYJfM9IJSDQKVdOdywpmHXnE 6EExFFjNXVgZ/ifJl/v/P0ldwPEHf7HON3YiulP26ufvIbFHA73oRBi8VVyLvqPCwaOh9NsAs64T Cw0bYBmjlvzwq7LLhs5oeP1spxLW0ycJw/KXH1GnUa4jMBe0sWk8CnIKLr7s3nhULcjOL35AcRc4 sLm77MgcEYXvYevYTmLutIsMKHeXZ1kdR4RPaH3uPjd9xDYHsINUJ6eEKoAiCm5OX9aTPZpU1f2Y Fe/6h4SBpqK4St+c9tWSAR4hI6XuFzdSrNAk44/WzaGmMIntvsY9rmg6I8+OVqE05p4S0fA9MpKl UZ9vVvx12EaEe1R291l71Qr7qoMWMZvI3quC47+KbFvnV7Y3b7E0nbdkrypdQ9MoQ1Rut0CENo4C /sVJJOJLUf8YgE6zG471NQUfl1G6L8gDYhaub2QubIiv+Tc1vFDQBQ1UMSTndl3VPyfX4iA9er2C 0elpLWw5bEUKWdtcbuM60TpzMFodhkACQVll02I/PxAUBR2fn3GUEdhU4k4BTDelCp26PkYo3ecW UAhQHvfXo+iwWo30SEMBUKpvkZFN/TAwggX6MIID4qADAgECAg8Be99Q4VH+fUDgPaa4c0MwDQYJ KoZIhvcNAQELBQAwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxF cmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzMB4XDTIxMDkxMzEzMjAyNFoXDTI0MDkxMzEzMjAy NFowYjERMA8GA1UECgwIRXJpY3Nzb24xHDAaBgNVBAMME0ZyYW5jZXNjYSBQYWxvbWJpbmkxLzAt BgkqhkiG9w0BCQEWIGZyYW5jZXNjYS5wYWxvbWJpbmlAZXJpY3Nzb24uY29tMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA9Tt3tVjm3MsisIwYeKGsY2b/HboYkoxNz7M+JWT8pQM3TEra vmG5+y+LRQ08VAqisS5OKI+HvqVOGX34uaMVIl5CKJUF6IQXRfziZhc82GAlmr16hxcR+tWyofQV iTeGpn5qB6pUvxA2PCG9LLuYbdB1ZaItM8BerI1cMT/MrbENJesviOyuN9jrYzgc99xfmwBD/LL0 LOzczRv+U5cRsbnNUxhAOjOxGdsiHR7/8dC5FcUR9zxnprMBZo03fgR9UuXskn1TQn8RTlgsYL7h WZxUZ83UAySdh2UeGfQzj+3wDPIiaB/102EZRC8V1nf0xEWshA0KFZTw2N/3PlLIfQIDAQABo4IB xjCCAcIwHwYDVR0jBBgwFoAUHHsZnpecdqwgPdjc45Fq49stplMwHQYDVR0OBBYEFFeXBKb0Hjy4 if/XibiZxhgwImdhMA4GA1UdDwEB/wQEAwIFoDBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBEjA6 MDgGCCsGAQUFBwIBFixodHRwczovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQ UzArBgNVHREEJDAigSBmcmFuY2VzY2EucGFsb21iaW5pQGVyaWNzc29uLmNvbTBIBgNVHR8EQTA/ MD2gO6A5hjdodHRwOi8vY3JsLnRydXN0LnRlbGlhLmNvbS9lcmljc3Nvbm5saW5kaXZpZHVhbGNh djMuY3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjCBggYIKwYBBQUHAQEEdjB0MCgG CCsGAQUFBzABhhxodHRwOi8vb2NzcDIudHJ1c3QudGVsaWEuY29tMEgGCCsGAQUFBzAChjxodHRw Oi8vY2EudHJ1c3QudGVsaWFzb25lcmEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jZXIw DQYJKoZIhvcNAQELBQADggIBABE/VlxAIEM48Gga9EEgCF5QI9LxTR1mGnPEwSqPydA5gsiWgCBT q2t1RsGgeUYe2YNhwJHmY1HHMLDJXCwRzXE4qy6Sr88Auo2CXzPSCUg0ClXTncsKZh15xOhBMRRY zV1YGf4nyZf7/z9JXcDxB3+xzjd2IrpT9urn7yGxRwO96EQYvFVci76jwsGjofTbALOuEwsNG2AZ o5b88Kuyy4bOaHj9bKcS1tMnCcPylx9Rp1GuIzAXtLFpPApyCi6+7N54VC3Izi9+QHEXOLC5u+zI HBGF72Hr2E5i7rSLDCh3l2dZHUeET2h97j43fcQ2B7CDVCenhCqAIgpuTl/Wkz2aVNX9mBXv+oeE gaaiuErfnPbVkgEeISOl7hc3UqzQJOOP1s2hpjCJ7b7GPa5oOiPPjlahNOaeEtHwPTKSpVGfb1b8 ddhGhHtUdvdZe9UK+6qDFjGbyN6rguO/imxb51e2N2+xNJ23ZK8qXUPTKENUbrdAhDaOAv7FSSTi S1H/GIBOsxuO9TUFH5dRui/IA2IWrm9kLmyIr/k3NbxQ0AUNVDEk53Zd1T8n1+IgPXq9gtHpaS1s OWxFClnbXG7jOtE6czBaHYZAAkFZZdNiPz8QFAUdn59xlBHYVOJOAUw3pQqduj5GKN3nFlAIUB73 16PosFqN9EhDAVCqb5GRTf0wMIIF+jCCA+KgAwIBAgIPAXvfUOFR/n1A4D2muHNDMA0GCSqGSIb3 DQEBCwUAMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nz b24gTkwgSW5kaXZpZHVhbCBDQSB2MzAeFw0yMTA5MTMxMzIwMjRaFw0yNDA5MTMxMzIwMjRaMGIx ETAPBgNVBAoMCEVyaWNzc29uMRwwGgYDVQQDDBNGcmFuY2VzY2EgUGFsb21iaW5pMS8wLQYJKoZI hvcNAQkBFiBmcmFuY2VzY2EucGFsb21iaW5pQGVyaWNzc29uLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAPU7d7VY5tzLIrCMGHihrGNm/x26GJKMTc+zPiVk/KUDN0xK2r5hufsv i0UNPFQKorEuTiiPh76lThl9+LmjFSJeQiiVBeiEF0X84mYXPNhgJZq9eocXEfrVsqH0FYk3hqZ+ ageqVL8QNjwhvSy7mG3QdWWiLTPAXqyNXDE/zK2xDSXrL4jsrjfY62M4HPfcX5sAQ/yy9Czs3M0b /lOXEbG5zVMYQDozsRnbIh0e//HQuRXFEfc8Z6azAWaNN34EfVLl7JJ9U0J/EU5YLGC+4VmcVGfN 1AMknYdlHhn0M4/t8AzyImgf9dNhGUQvFdZ39MRFrIQNChWU8Njf9z5SyH0CAwEAAaOCAcYwggHC MB8GA1UdIwQYMBaAFBx7GZ6XnHasID3Y3OORauPbLaZTMB0GA1UdDgQWBBRXlwSm9B48uIn/14m4 mcYYMCJnYTAOBgNVHQ8BAf8EBAMCBaAwVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4Bggr BgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwKwYD VR0RBCQwIoEgZnJhbmNlc2NhLnBhbG9tYmluaUBlcmljc3Nvbi5jb20wSAYDVR0fBEEwPzA9oDug OYY3aHR0cDovL2NybC50cnVzdC50ZWxpYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYzLmNy bDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwgYIGCCsGAQUFBwEBBHYwdDAoBggrBgEF BQcwAYYcaHR0cDovL29jc3AyLnRydXN0LnRlbGlhLmNvbTBIBggrBgEFBQcwAoY8aHR0cDovL2Nh LnRydXN0LnRlbGlhc29uZXJhLmNvbS9lcmljc3Nvbm5saW5kaXZpZHVhbGNhdjMuY2VyMA0GCSqG SIb3DQEBCwUAA4ICAQARP1ZcQCBDOPBoGvRBIAheUCPS8U0dZhpzxMEqj8nQOYLIloAgU6trdUbB oHlGHtmDYcCR5mNRxzCwyVwsEc1xOKsukq/PALqNgl8z0glINApV053LCmYdecToQTEUWM1dWBn+ J8mX+/8/SV3A8Qd/sc43diK6U/bq5+8hsUcDvehEGLxVXIu+o8LBo6H02wCzrhMLDRtgGaOW/PCr ssuGzmh4/WynEtbTJwnD8pcfUadRriMwF7SxaTwKcgouvuzeeFQtyM4vfkBxFziwubvsyBwRhe9h 69hOYu60iwwod5dnWR1HhE9ofe4+N33ENgewg1Qnp4QqgCIKbk5f1pM9mlTV/ZgV7/qHhIGmorhK 35z21ZIBHiEjpe4XN1Ks0CTjj9bNoaYwie2+xj2uaDojz45WoTTmnhLR8D0ykqVRn29W/HXYRoR7 VHb3WXvVCvuqgxYxm8jeq4Ljv4psW+dXtjdvsTSdt2SvKl1D0yhDVG63QIQ2jgL+xUkk4ktR/xiA TrMbjvU1BR+XUbovyANiFq5vZC5siK/5NzW8UNAFDVQxJOd2XdU/J9fiID16vYLR6WktbDlsRQpZ 21xu4zrROnMwWh2GQAJBWWXTYj8/EBQFHZ+fcZQR2FTiTgFMN6UKnbo+Rijd5xZQCFAe99ej6LBa jfRIQwFQqm+RkU39MDCCBsIwggSqoAMCAQICEFO4foPhnJkok7CbSRzsuOswDQYJKoZIhvcNAQEL BQAwNzEUMBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0Eg djEwHhcNMTUxMDI3MTIxNjQ2WhcNMjUxMDI3MTIxNjQ2WjBHMQswCQYDVQQGEwJTRTERMA8GA1UE CgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMwggIiMA0G CSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDs8t8AALhQ8qe72FS3xpP348GqO9TDRjS0s85eQ7Y0 LTLZdmSz2cl+lYqs0zfSTm+7meisbhkqUXkL7fFzoe4iIZCh/VuYUaW407CZlDCXes4n4TqTSuok lN6uOPhY7EC9ZVbXILlLhRummTdDdxhVW4Leo0awEhfLf98MvWxzwCHzMj8m6YOmNjx+f9TcJE3q aA0piuvSxlfpVdiCulPTlmsmV2RSBSAwqBshZYRcQBIDfqmdvkaoP9EzNKAh7yjthC0hpgHZyZMI s0eNo4v2PUmE0rhu+Zs0nujnwhljPA2/8b8v9tGixD1zbtT7zoM2Ot1menJpFp4zJVSfdKVgtoWq g5t2H/E0XY1LwJez89W07nscEocyBmpC+zJAmKxKhzEWqIyP1UrZaEIFu+hO+s0Nm8sOUMa4TlG4 rAUikc5U5TmUIGBRQGxulYhfAzqSYf8oLUMLky1DOa9eRu3sp0FdQDEzQlnF/h1L4AK1MOkX1vS+ fLgOvBo5LRU1fLPUZQ7FKrDXC6nl2ldvEtljHWstGBmqv25aEvAA+yrrplCh/kYvSBjvZibz9Obb wx4yqS77/NHN1iyZyVP2s52B2BLdvo4yhzk6nRk8S/8zHaUUkBUrrvijPDaGK5FNVSaioGvkC7IK ioITKffYLtT9XuirKrHlh3VzkazG46pAVwIDAQABo4IBuDCCAbQwgYoGCCsGAQUFBwEBBH4wfDAt BggrBgEFBQcwAYYhaHR0cDovL29jc3AudHJ1c3QudGVsaWFzb25lcmEuY29tMEsGCCsGAQUFBzAC hj9odHRwOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290 Y2F2MS5jZXIwEgYDVR0TAQH/BAgwBgEB/wIBADBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBAjA6 MDgGCCsGAQUFBwIBFixodHRwczovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQ UzBLBgNVHR8ERDBCMECgPqA8hjpodHRwOi8vY3JsLTMudHJ1c3QudGVsaWFzb25lcmEuY29tL3Rl bGlhc29uZXJhcm9vdGNhdjEuY3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAOBgNV HQ8BAf8EBAMCAQYwHQYDVR0OBBYEFBx7GZ6XnHasID3Y3OORauPbLaZTMB8GA1UdIwQYMBaAFPCP WTgAs/WPmpYM1ev6e6oX6BMSMA0GCSqGSIb3DQEBCwUAA4ICAQBQWGvx1Yw7tC6rV0PIjKfDyxaa nIX+NZLEGOkdQLKGW2gVLtDUJQEPRs5QtaZiObNHCZ7mmSNMVek4lkt/0dqfVIFutVw/QkyFGwC9 9ZmNwXSX9z+OoMyoEBHGvw5RY6vRlZrj0uKvdASzYL4KMaB7m3NwurNDmmNbG52suRIZ76wBOEOd dRZcZiTy50ZkBqYnnl2t3D3oBX2NZCQysshUcqRdUbkS13HTCIChMuTV9W0tzPXUOJoJlJlU9nd9 1IikhGEOrPwfixWms+C8sF0r9qN1uJGx6ELPOiFrLfNtcMNMMbAqRHwpSLxe3wcNkJGxv9T8LswL i1UrRIQ85AKjqzBnLSsjRGgbMgJ+xKtngmvEA155JmoKfUD7DRbP6Kp14/Y9XFbR/WuDj84bYNKX e4HdDc1P+UMYm16m2L6LkIIoRlx0A5mi+K7jewuGqzFKkaPNmJ0RLCi+4d4/47Zs3DC3PUNOxdOE EHf4kkdWOaSIuj3TQYhNv+LsgF0uijiBmaz2zUFDa2bcIkKakDZfAFM4HoHz8K2BZRaHKWhd3dZu a/tlSiqokUFX2DxmHmZ1n5HM9OiaAIXP/Zo2x10j/Yb1mM3i0bqGahxlHYzl/QyEG/dujp3lewuV jCI0mPDkZGphvxyqp4Jo8qS94EnOqBvxOgftYug7OY9EKY+WkDGCAl4wggJaAgEBMFowRzELMAkG A1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlk dWFsIENBIHYzAg8Be99Q4VH+fUDgPaa4c0MwDQYJYIZIAWUDBAIBBQCggdYwGAYJKoZIhvcNAQkD MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjIwNDA4MTMxODIwWjAvBgkqhkiG9w0BCQQx IgQg4CiJtC4OYIoGetiTtyy3y42kV+kZc5I/vv1K8+lp7scwawYLKoZIhvcNAQkQAgsxXKBaMEcx CzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5k aXZpZHVhbCBDQSB2MwIPAXvfUOFR/n1A4D2muHNDMA0GCSqGSIb3DQEBAQUABIIBAO2XKjXCdjzj qMXVa5tMh7xUhDvXMHxd7T8qKBEZhKddgCbjEpiB5Z4XpvCeEt6LzSs0okVdTGo3u4u2VG8wIvu8 HDhrTMg9hahQWFkUtGT0DJAJUXHmgqTHJy/VgUZA6krsWFcc4YigxE0f2Ywb6XVbAkc0FS2Ey0HL TijdGlRxKeKNdW181KTx+QZw/LzJUeJNxwmXCwH4hHoOmaAlhk2/H1rdtRSinkBrQ5wxjTU4yMzC 8g03Pzi1Egu0lj12OM98XgUz5rH7FHzd/3yWGW+P0AmgAVi2ZZNiED9Sg7kuU73UocPGewidGNHy MlH+g531vfl/GQKYDPzUwKo7u98AAAAAAAA= --_59B91CD4-2BB4-2B44-A5AE-1BE8F61152B1_-- From nobody Fri Apr 8 07:31:44 2022 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 637F03A0BB0 for ; Fri, 8 Apr 2022 07:31:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 aUYaiAd9w46C for ; Fri, 8 Apr 2022 07:31:39 -0700 (PDT) Received: from ppa3.lax.icann.org (ppa3.lax.icann.org [192.0.33.78]) (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 12EEF3A0B77 for ; Fri, 8 Apr 2022 07:31:39 -0700 (PDT) Received: from MBX112-E2-CO-1.pexch112.icann.org (out.mail.icann.org [64.78.33.7]) by ppa3.lax.icann.org (8.16.0.43/8.16.0.43) with ESMTPS id 238EVc81007005 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 8 Apr 2022 14:31:38 GMT Received: from MBX112-W2-CO-1.pexch112.icann.org (10.226.41.128) by MBX112-W2-CO-1.pexch112.icann.org (10.226.41.128) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.22; Fri, 8 Apr 2022 07:31:37 -0700 Received: from MBX112-W2-CO-1.pexch112.icann.org ([10.226.41.128]) by MBX112-W2-CO-1.pexch112.icann.org ([10.226.41.128]) with mapi id 15.02.0986.022; Fri, 8 Apr 2022 07:31:37 -0700 From: Paul Hoffman To: "dnsop@ietf.org WG" Thread-Topic: [Ext] [DNSOP] DNSSEC as a Best Current Practice Thread-Index: AQHYS1VaUhzSq43MzE22r3La4AdQIQ== Date: Fri, 8 Apr 2022 14:31:37 +0000 Message-ID: <88F7F567-F605-4F0D-9292-C083465E6678@icann.org> References: <57f1c37b-497c-e1a0-329c-4b9c8b7e197b@necom830.hpcl.titech.ac.jp> <9732682e-78e7-f6bf-84fc-685de22d5e12@necom830.hpcl.titech.ac.jp> <350d8ab8-0477-b656-8b08-56f7561a7fda@necom830.hpcl.titech.ac.jp> <0e2dffab-6afc-b1b6-9028-175f89f0d29e@necom830.hpcl.titech.ac.jp> In-Reply-To: <0e2dffab-6afc-b1b6-9028-175f89f0d29e@necom830.hpcl.titech.ac.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [192.0.32.234] x-source-routing-agent: Processed Content-Type: multipart/signed; boundary="Apple-Mail=_5FB33619-DBFC-468B-BAD0-CD70DDB29D83"; protocol="application/pkcs7-signature"; micalg=sha-256 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425, 18.0.858 definitions=2022-04-08_05:2022-04-08, 2022-04-08 signatures=0 Archived-At: Subject: Re: [DNSOP] [Ext] DNSSEC as a Best Current Practice X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2022 14:31:43 -0000 --Apple-Mail=_5FB33619-DBFC-468B-BAD0-CD70DDB29D83 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Now that the document in question has been published as a WG document, = it follows the standard IETF rules about consensus. As document author, = I will follow those rules to the best of my ability. I see a very strong consensus in this thread against the proposals from = Ohta-san, so I think the thread can close. If Ohta-san wants to re-open = the thread, he can do so with specific wording changes for = draft-ietf-dnsop-dnssec-bcp and then we can see if there is consensus = for those. Until then, though, maybe we can move to other topics. --Paul Hoffman --Apple-Mail=_5FB33619-DBFC-468B-BAD0-CD70DDB29D83 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCBrYw ggayMIIFmqADAgECAhMwAAAX4ZqelQKZcEdTAAMAABfhMA0GCSqGSIb3DQEBCwUAMF8xEzARBgoJ kiaJk/IsZAEZFgNvcmcxFTATBgoJkiaJk/IsZAEZFgVpY2FubjESMBAGCgmSJomT8ixkARkWAmRz MR0wGwYDVQQDExRhZDEtbGF4LmRzLmljYW5uLm9yZzAeFw0yMTA1MjAxNTAxMzNaFw0yMzA1MjAx NTAxMzNaMIGUMRMwEQYKCZImiZPyLGQBGRYDb3JnMRUwEwYKCZImiZPyLGQBGRYFaWNhbm4xEjAQ BgoJkiaJk/IsZAEZFgJkczEUMBIGA1UECxMLSUNBTk4tVXNlcnMxFTATBgNVBAMTDFBhdWwgSG9m Zm1hbjElMCMGCSqGSIb3DQEJARYWcGF1bC5ob2ZmbWFuQGljYW5uLm9yZzCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBALtvlgd1mCsDZcUXiDdEtqqeklaJa3MfG8v1RMIKaVSaK3dsq2gA JujPfGwUdRIne4Tz6HJqPXBYEzVkgUdxdFXu/xPzfZei+fRb7zeVA9sMTrKl9gQ31Q0cw5VbmJzG P41Lxq2ruCyX/cGiru1PG4VVN72f9w1lpBt4rhRYpi5f2DDRmNm01teEoNOdvQ6PavUJVWrLVDI0 Z+uF4oe51yriMBQntRw9XenckW2yDa9ob3DlmOYKdZp1mNv2f+XB1Uc4xZSpJMFly/nxd0hIvkmi GrG0+puC0+OyDV4z1JIURBIx2RnXEJxYvaFPID5g/IT7MtFqQnLKIZTJc2DXySECAwEAAaOCAy8w ggMrMB0GA1UdDgQWBBRXoW6yUY7G6nMFSxU+2lZm7KqcvDAfBgNVHSMEGDAWgBTpKerCBbuXyks/ cnl6+luCS7lqhDCB2QYDVR0fBIHRMIHOMIHLoIHIoIHFhoHCbGRhcDovLy9DTj1hZDEtbGF4LmRz LmljYW5uLm9yZygxKSxDTj1hZDEtbGF4LENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNl cyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPWRzLERDPWljYW5uLERDPW9yZz9jZXJ0 aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9p bnQwgcoGCCsGAQUFBwEBBIG9MIG6MIG3BggrBgEFBQcwAoaBqmxkYXA6Ly8vQ049YWQxLWxheC5k cy5pY2Fubi5vcmcsQ049QUlBLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2Vz LENOPUNvbmZpZ3VyYXRpb24sREM9ZHMsREM9aWNhbm4sREM9b3JnP2NBQ2VydGlmaWNhdGU/YmFz ZT9vYmplY3RDbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MA4GA1UdDwEB/wQEAwIFoDA9Bgkr BgEEAYI3FQcEMDAuBiYrBgEEAYI3FQiBurJNhMjIaoOtkz+HlPRag/mIbk6H68s/hoOYWgIBZAIB BzApBgNVHSUEIjAgBgorBgEEAYI3CgMEBggrBgEFBQcDBAYIKwYBBQUHAwIwNQYJKwYBBAGCNxUK BCgwJjAMBgorBgEEAYI3CgMEMAoGCCsGAQUFBwMEMAoGCCsGAQUFBwMCMEkGA1UdEQRCMECgJgYK KwYBBAGCNxQCA6AYDBZwYXVsLmhvZmZtYW5AaWNhbm4ub3JngRZwYXVsLmhvZmZtYW5AaWNhbm4u b3JnMEQGCSqGSIb3DQEJDwQ3MDUwDgYIKoZIhvcNAwICAgCAMA4GCCqGSIb3DQMEAgIAgDAHBgUr DgMCBzAKBggqhkiG9w0DBzANBgkqhkiG9w0BAQsFAAOCAQEAetxZFQDQ4/o0w3yjeD1PEIf4QJU3 vLp3QHq5I0I3ogj7UTGxAUudkuz7ttpb7K9HtBWRcbhyFY9blGQ2FLScWMBQkg1GO5pIwGSAkFGj iLPcyihxOASMrI1TBGaPuHUeMfOhqYl1tYgLWnabrd2mjjSLJHvJHJQ7ZSAexjGLhoFoj8/sVPk1 JIOvOOtIWZ3lky3eYI4Q7NYI4p9sHE6CAeOX52gpdvpVphaktfKZhGbIbeQiQTmdkcvOklHr6xHE CKXbhVZqEzOQtSxbsoGUOascj3k7PwFZPmWH/aQbnINDyqo97A++tKkSyVbmKbCeOORbH5hIGpYg CshNrXTOsTGCAyAwggMcAgEBMHYwXzETMBEGCgmSJomT8ixkARkWA29yZzEVMBMGCgmSJomT8ixk ARkWBWljYW5uMRIwEAYKCZImiZPyLGQBGRYCZHMxHTAbBgNVBAMTFGFkMS1sYXguZHMuaWNhbm4u b3JnAhMwAAAX4ZqelQKZcEdTAAMAABfhMA0GCWCGSAFlAwQCAQUAoIIBezAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMjA0MDgxNDMxMzZaMC8GCSqGSIb3DQEJBDEi BCDxmfxiPqkZbU5p/84gXVtn1WDyzeT2huM79fKNvJO3+DCBhQYJKwYBBAGCNxAEMXgwdjBfMRMw EQYKCZImiZPyLGQBGRYDb3JnMRUwEwYKCZImiZPyLGQBGRYFaWNhbm4xEjAQBgoJkiaJk/IsZAEZ FgJkczEdMBsGA1UEAxMUYWQxLWxheC5kcy5pY2Fubi5vcmcCEzAAABfhmp6VAplwR1MAAwAAF+Ew gYcGCyqGSIb3DQEJEAILMXigdjBfMRMwEQYKCZImiZPyLGQBGRYDb3JnMRUwEwYKCZImiZPyLGQB GRYFaWNhbm4xEjAQBgoJkiaJk/IsZAEZFgJkczEdMBsGA1UEAxMUYWQxLWxheC5kcy5pY2Fubi5v cmcCEzAAABfhmp6VAplwR1MAAwAAF+EwDQYJKoZIhvcNAQELBQAEggEAqU5A0v5wOPHaTQDZgKFV E5TTczf50NcVNoM7CmVYtMfekMbmy3Yjm4JiULuj+guzLQEArpxdva6jxcjWPLiI6wrTSEua92RH IKFQSAnu43cvMmt06F2ClFqpBoJ+HbHpYBAcJxnehoxmqzxkyDf7X8Bob5ZrgtnXRysh2svKbyO7 WGECxCgwmA2K9YfGE4QZireB4hlqpSCLDgcbB+cj+xNWWIddI2is+M3x7t9MwBJfwYNA3GtKz7dF pxBRiNSCoQMMKmjJgSrv4V2wflNmNiw7WZVX++R7eZpoBKJkVfXj4xTelai4holdlOFx1Z/nr76u /y3TN4eDE52VeRkzEAAAAAAAAA== --Apple-Mail=_5FB33619-DBFC-468B-BAD0-CD70DDB29D83-- From nobody Fri Apr 8 07:40:37 2022 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 061FA3A0D35 for ; Fri, 8 Apr 2022 07:40:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.107 X-Spam-Level: X-Spam-Status: No, score=-2.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] 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 n7m9dQF0dsvS for ; Fri, 8 Apr 2022 07:40:31 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.85]) (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 70EC13A0D2A for ; Fri, 8 Apr 2022 07:40:31 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4KZgs92YYQzDh9; Fri, 8 Apr 2022 16:40:29 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1649428829; bh=k+H578pp8XVzShfOqwl3Cq8VHLfMMDRh1AQOU/sWrwI=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=oVzuVM3pKrp6/JeDZ08faj5U0P3pr1p+7k/eQDE0pADgg0awmrPsuAh9W78pNjGMd iJ1DrQiHcCc7DwB6wkCJy1PpT32NrvAOe7Ojk6R/DKsCLB98M0KO72yGhTbIYz+vdo u2qm0uhWvzDHrmipGI3Zz7IBGQQkXHR/WiIoahcA= 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 xbfqttBotZoF; Fri, 8 Apr 2022 16:40:28 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Fri, 8 Apr 2022 16:40:28 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 536182DC05E; Fri, 8 Apr 2022 10:40:27 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 4FF692DC05D; Fri, 8 Apr 2022 10:40:27 -0400 (EDT) Date: Fri, 8 Apr 2022 10:40:27 -0400 (EDT) From: Paul Wouters To: Masataka Ohta cc: "dnsop@ietf.org WG" In-Reply-To: <0e2dffab-6afc-b1b6-9028-175f89f0d29e@necom830.hpcl.titech.ac.jp> Message-ID: References: <57f1c37b-497c-e1a0-329c-4b9c8b7e197b@necom830.hpcl.titech.ac.jp> <9732682e-78e7-f6bf-84fc-685de22d5e12@necom830.hpcl.titech.ac.jp> <350d8ab8-0477-b656-8b08-56f7561a7fda@necom830.hpcl.titech.ac.jp> <0e2dffab-6afc-b1b6-9028-175f89f0d29e@necom830.hpcl.titech.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [DNSOP] DNSSEC as a Best Current Practice X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2022 14:40:36 -0000 On Fri, 8 Apr 2022, Masataka Ohta wrote: > First, "CA" is terminology not specific to WebPKI, whatever > it means, but PKI in general including DNS. That is, a DNSSEC > TLD is a CA. This is incorrect. Or rather, it is equivalent to a CA with a very strict path constraint of being within the TLD. In your favourite terms, diginotar as DNSSEC entity would have only been able to mess up .nl and not any other TLD, if it had been a "DNSSEC CA" instead of a "webpki CA". The hierarchical space offers better security than the flat webpki. > Second "any CA which is weaker than some TLD" means not > "cryptographically weaker" but "operationally/physically > weaker". As such, your conclusion can only be "DNSSEC is > more operationally/physically secure than WebPKI" You keep conflating operational security with protocol security, and insisting protocol security is not needed because operational security is always the weaker link. But you are not offering any alternative ("larger plaintext cookies" is not a security protocol) and therefor imply we should abandon every cryptographic protocol in the name of "false security". So please tell me why you use TLS at all? Why not force your browser into only using port 80? You can also use extra long HTTP header cookies. Paul From nobody Fri Apr 8 13:17:56 2022 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 B71133A119A for ; Fri, 8 Apr 2022 13:17:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.109 X-Spam-Level: X-Spam-Status: No, score=-7.109 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 0hrDWRgFP4De for ; Fri, 8 Apr 2022 13:17:47 -0700 (PDT) Received: from mail2.verisign.com (mail2.verisign.com [72.13.63.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A0603A1198 for ; Fri, 8 Apr 2022 13:17:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=45782; q=dns/txt; s=VRSN; t=1649449068; h=from:to:cc:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version:subject; bh=Ng+/QdwcxBZXVZtV7qEMFhVvzQkvnt7rp9hQxgL/hOQ=; b=IT1dbRbaqPhbkCn0m+3LUTJycgp7Ndk5zejwCqo5AWOXPVqPmehPdSnz Ve9z4NxvCp/ET2FKUyaFL9+0WYNOIkJrcGZ1Fao3ee0bYv3ADIvCkTMHI 8HpYkU0Y5iBOILYV3u+NxfMHhK8vr4H2KGN+id0B/ZdglbrZ9lzMwUQ5V dQFFRVmBUgrCEtwgGuOwttwqhcYflW3Lzp+fjSHM+1VoW0hoQe7t7vL0U Rf3Van6dNmbyEw7dXHypHeolaPuWmv8t582X2cjfsAH4oaLYgUQfeONLQ izyrdDawMVhxEyT0+DWU79beTeuz0R8p8jEvZ1omg1DlAEyDnKSr2/mkK g==; IronPort-Data: A9a23:0iFA563OGn1Pg8wJsfbD5WBzkn2cJEfYwER7XKvMYLTBsI5bp2AEy WUYUWiDbvmJamCmf4tybdjk8h9U7JDVxt9lGgNsqSg9HnlHl5HIVI+TRqvS04N+DSFioGZPt Zh2hgzodZhsJpPkS5PE3oHJ9RGQ74nRLlbHILOCa3gZqTNMEn9700o/w75h2OaEvPDia++zk YKqyyHgEAL9s9JEGjp8B3Wr8U4HUFza4Vv0j3RmDRx5lAa2e0o9VfrzEZqMw07QGeG4KAIaq 9Hrl9lV9kuBl/skIo39zuajKiXmSJaKVeSFoiI+t6RPHnGuD8H9u0o2HKN0VKtZt9mGt9Yu5 /Zw8r+KcwQwL5GUxPYGdFpaSz4raMWq+JefSZS+meap6RT5VVbcm6woEkoxJ5Ve8+oxH3tV8 7oTLzVlghKr3rrwme3gDLAx3YJ/fKEHP6tG0p1k5T3GAO09TJTYa7vH/95D3Tg2wMtJGJ4yY uJAMmE+PUyYPnWjPH9OE8gUxM2KpkWvdgN/737Fio0GpEncmVkZPL/FdYC9lsaxbchIkUueq yTP82n9BjkVMdWezXyO9XfEruPJhiTjcIMfCLP+8eRl6GB/3UQZEhtPSl22saHgz1WgQZRaK ldR8C1op7I0rQq1VML7GRa/pRZooyIhZjaZKMVigCnl90Yey1/x6rQsJtKZVOEbiQ== IronPort-HdrOrdr: A9a23:dpBb9q/ruGad/zrcibpuk+AFI+orL9Y04lQ7vn2ZLiYlF/Bw9v re/sjzuiWVtN98Yh8dcLO7V5VoKEm0naKdirNhXotKMjOGhEKYaK9v6of4yyDtFmnU5odmuZ tIQuxbBMfrBVZ3yeT38GCDeeoI8Z2i/LqzjenTi01xSxpnApsM0y5iBh2FHlZNSA5KOJo8GP OnjfZ6mw== X-IronPort-AV: E=Sophos;i="5.90,245,1643673600"; d="scan'208";a="13399005" Received: from BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) by BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2375.24; Fri, 8 Apr 2022 16:17:45 -0400 Received: from BRN1WNEX01.vcorp.ad.vrsn.com ([10.173.153.48]) by BRN1WNEX01.vcorp.ad.vrsn.com ([10.173.153.48]) with mapi id 15.01.2375.024; Fri, 8 Apr 2022 16:17:45 -0400 From: "Wessels, Duane" To: =?utf-8?B?RXVnw6huZSBBZGVsbA==?= CC: "dnsop@ietf.org" Thread-Topic: [EXTERNAL] [DNSOP] introducing a couple of RRTypes (CRC/CRS) for B2B applications Thread-Index: AQHYSN176UHk9Uw9UEmutrAwEJWhKqzmvLwA Date: Fri, 8 Apr 2022 20:17:45 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3654.120.0.1.13) x-originating-ip: [10.170.148.18] Content-Type: text/plain; charset="utf-8" Content-ID: <3D22F56CF3DB104DAF4020B78454309B@verisign.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [DNSOP] introducing a couple of RRTypes (CRC/CRS) for B2B applications X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2022 20:17:54 -0000 SGkgRXVnw6huZSwgSSByZWFkIHRocm91Z2ggdGhlIGRyYWZ0IGFuZCBoYXZlIGEgZmV3IHN1Z2dl c3Rpb25zIGZvciB5b3UgdG8gY29uc2lkZXI6DQoNCjEpIFRoZSBDUlMgYW5kIENSQyBSREFUQSBm aWVsZHMgaGF2ZSBhIGxvdCBpbiBjb21tb24gd2l0aCBUWFQgcmVjb3Jkcy4gIE9uIG9uZSBoYW5k IHlvdSBtaWdodCBmaW5kIHNvbWUgYmVuZWZpdHMgZnJvbSBtYWtpbmcgdGhlc2UgbmV3IFJSIHR5 cGVzIGhhdmUgdGhlIHNhbWUgcGFyc2luZywgd2lyZSBmb3JtYXQsIGFuZCBwcmVzZW50YXRpb24g Zm9ybWF0IGFzIFRYVCByZWNvcmRzLiAgQnV0IG9uIHRoZSBvdGhlciBoYW5kLCB0aGF0IHByb2Jh Ymx5IGxpbWl0cyB0aGUgYWJpbGl0eSB0byBwZXJmb3JtIHN5bnRheCBjaGVja2luZyBieSBhbiBh dXRob3JpdGF0aXZlIG5hbWUgc2VydmVyLiAgTWF5YmUgZ2V0IHNvbWUgYWR2aWNlIGZyb20gRE5T IGltcGxlbWVudG9ycyBvbiB0aGlzIHRvcGljLg0KDQoyKSBZb3Ugc2hvdWxkIHVzZSBkb2N1bWVu dGF0aW9uIGRvbWFpbnMgKGFuZCBhZGRyZXNzZXMpLiAgaS5lLiwgZXhhbXBsZS5jb20gaW5zdGVh ZCBvZiBmb28uY29tLg0KDQozKSBZb3VyIGV4YW1wbGUgcmVjb3JkcyBzaG91bGQgYXBwZWFyIGp1 c3QgbGlrZSB0aGV5IHdvdWxkIGluIGEgem9uZSBmaWxlLiAgTWF5YmUgc29tZXRoaW5nIGxpa2UN Cg0KICAgZnRwLmV4YW1wbGUuY29tLiBJTiBDUlMgUj1BLDIxDQoNCjQpIFNlcGFyYXRpb24gb2Yg Y29tcG9uZW50cyB3aXRoIHVuZGVyc2NvcmUgZG9lc27igJl0IHNlZW0gcmlnaHQgdG8gbWUuICBZ b3UgZ2l2ZSBhbiBleGFtcGxlIGFzIOKAnGZ0cC5mb28uY29tXzIxX2Jhci5jb23igJ0uICBUaGlz IGNyZWF0ZXMgYW4gKGludmFsaWQpIHNlY29uZC1sZXZlbCBkb21haW4gY29tXzIxX2Jhci5jb20s IHVubGVzcyBJIG1pc3VuZGVyc3RhbmQ/DQoNCjUpIENhbiB5b3UgaW5jbHVkZSBhbiBleGFtcGxl IG9mIGhvdyB0aGUgQ1JTIHJlY29yZCB3b3VsZCBiZSB1c2VkPw0KDQpEVw0KDQoNCg0KDQoNCj4g T24gQXByIDUsIDIwMjIsIGF0IDM6NTIgQU0sIEV1Z8OobmUgQWRlbGwgPGV1Z2VuZS5hZGVsbEBn bWFpbC5jb20+IHdyb3RlOg0KPiANCj4gSGVsbG8sDQo+IA0KPiBJJ3ZlIGJlZW4gd29ya2luZyBv biB0d28gbmV3IFJSVHlwZXMgZGVzY3JpYmVkIGJ5IGEgRHJhZnQsIGFuZCBhcw0KPiBzdWdnZXN0 ZWQgYnkgb3VyIG1hZ25pZmljZW50LCBpbmNyZWRpYmx5IGJyaWxsaWFudCBhbmQgaGFuZHNvbWUg QUQNCj4gV2FycmVuICJBQ0UiIEt1bWFyaSwgSSBhbSBwb3N0aW5nIGhlcmUgdGhpcyBpZGVhIGFu ZCB0aGUgbWF0ZXJpYWwgSQ0KPiBoYXZlIHdyaXR0ZW4gc28gZmFyICh0aGUgZHJhZnQgaXRzZWxm LCBhbmQgUkZDIDY4OTUgY29tcG9uZW50cykuDQo+IA0KPiBCcmllZmx5LCBvbmUgUlJUeXBlIChD UkMgOiBDbGllbnQgUm9hbWluZyBDb250cm9sKSBjb250YWlucyBhDQo+IHdoaXRlbGlzdCBvZiBu ZXR3b3JrcyBhbGxvd2luZyBhIGNvbXBhbnkgZW1wbG95ZWVzIHRvIGNvbm5lY3QgdG8gYQ0KPiBz cGVjaWZpYyBhcHBsaWNhdGlvbi4gVGhlIHNlY29uZCBSUlR5cGUgKENSUyA6IENsaWVudCBSb2Ft aW5nIFN1cHBvcnQpDQo+IGlzIG9uIHRoZSBhcHBsaWNhdGlvbiBzaWRlIGFuZCBpbmZvcm1zIHdo YXQga2luZCBvZiByZXN0cmljdGlvbnMgYXJlDQo+IGFwcGxpZWQgKGJ5IHNheWluZyBpZiBDUkMg aXMgbWFuZGF0b3J5LCBvcHRpb25hbCBvciBpZ25vcmVkKS4NCj4gVGhpcyBpcyBub3QgZXhwZWN0 ZWQgdG8gYmUgZGVwbG95ZWQgYnJvYWRseSBhbmQgZXZlcnl3aGVyZSBhcyBpdCBpcw0KPiBkZXNp Z25lZCB0byBzZWN1cmUgQnVzaW5lc3MtVG8tQnVzaW5lc3MgYXBwbGljYXRpb25zLg0KPiANCj4g VGhlIG1hdGVyaWFsICh0ZXh0IFhNTDJSRkMgZHJhZnQgKyBSRkMgNjg5NSBjb21wb25lbnRzKSB3 cml0dGVuIGlzDQo+IGJvdGggaW5jb3Jwb3JhdGVkIGJlbG93IHRvIHRoaXMgZW1haWwgYW5kIGF0 dGFjaGVkLCBmb3IgcHJhY3RpY2FsDQo+IHJlYXNvbnMuDQo+IA0KPiANCj4gUmVnYXJkcw0KPiBF LkEuDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gSW50ZXJuZXQgRW5naW5lZXJpbmcgVGFzayBGb3Jj ZSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEUuIEFkZWxsDQo+IEludGVybmV0LURy YWZ0ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDUgQXByaWwg MjAyMg0KPiBJbnRlbmRlZCBzdGF0dXM6IEluZm9ybWF0aW9uYWwNCj4gRXhwaXJlczogNyBPY3Rv YmVyIDIwMjINCj4gDQo+IA0KPiAgICAgICAgICAgICAgICAgICAgICAgICBDbGllbnQgUm9hbWlu ZyBDb250cm9sDQo+ICAgICAgICAgICAgICAgICAgICAgZHJhZnQtYWRlbGwtY2xpZW50LXJvYW1p bmctMDANCj4gDQo+IEFic3RyYWN0DQo+IA0KPiAgIFRoaXMgZG9jdW1lbnQgc3BlY2lmaWVzIHRo ZSBDbGllbnQgUm9hbWluZyBDb250cm9sIChDUkMpIEROUyBSZXNvdXJjZQ0KPiAgIFJlY29yZCBh bGxvd2luZyBhbiBvcmdhbml6YXRpb24gdG8gYmV0dGVyIGNvbnRyb2wgdGhlIGFjY2VzcyB0bw0K PiAgIHRoaXJkLXBhcnR5IGFwcGxpY2F0aW9ucyBvdmVyIEludGVybmV0LiAgVGhlIGFwcGxpY2F0 aW9ucw0KPiAgIGltcGxlbWVudGluZyBhbiBhdXRob3JpemF0aW9uIG1lY2hhbmlzbSB0byBob25v ciB0aGUgQ1JDLCBwdWJsaXNoIG9uDQo+ICAgdGhlaXIgc2lkZSB0aGUgQ2xpZW50IFJvYW1pbmcg U3VwcG9ydCAoQ1JTKSBSZXNvdXJjZSBSZWNvcmQgdG8gaW5mb3JtDQo+ICAgb2YgdGhpcyBzdXBw b3J0Lg0KPiANCj4gU3RhdHVzIG9mIFRoaXMgTWVtbw0KPiANCj4gICBUaGlzIEludGVybmV0LURy YWZ0IGlzIHN1Ym1pdHRlZCBpbiBmdWxsIGNvbmZvcm1hbmNlIHdpdGggdGhlDQo+ICAgcHJvdmlz aW9ucyBvZiBCQ1AgNzggYW5kIEJDUCA3OS4NCj4gDQo+ICAgSW50ZXJuZXQtRHJhZnRzIGFyZSB3 b3JraW5nIGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmcNCj4gICBUYXNrIEZv cmNlIChJRVRGKS4gIE5vdGUgdGhhdCBvdGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZQ0K PiAgIHdvcmtpbmcgZG9jdW1lbnRzIGFzIEludGVybmV0LURyYWZ0cy4gIFRoZSBsaXN0IG9mIGN1 cnJlbnQgSW50ZXJuZXQtDQo+ICAgRHJhZnRzIGlzIGF0IGh0dHBzOi8vc2VjdXJlLXdlYi5jaXNj by5jb20vMVVCcU5xT0QwX2F2anRyLVlZLXEtZU9nZmNhYWRmR2VyRzltVzJKS0tDc2VRNmFRYU5t OVFJLW44U3Vaa1l3NXQzSk5odC1ROUo3Um0tZ25QbHJYemlyZW15Rm1fVjhEOFlKRlRURlhnYnd1 SUJrTTMxWkRrVlowanUzREI2amFTcDlHdmwtemFzSTh5TU01LXlfTDZ6Y2QzcFpwbDEyeXgtQ2Uz Y3ZPYTc4dU10ZnNIWEhmcXdpMTRJRlhGZ000ZXdrS1ZtVEVoLWZSS29ZTnRRZ2pGNG1ZcE9lV2E2 ZjNfR2pFR2s4ZEZoSkY4UXA1bDZrcnBhWGlsckk1LXhiYUsvaHR0cHMlM0ElMkYlMkZkYXRhdHJh Y2tlci5pZXRmLm9yZyUyRmRyYWZ0cyUyRmN1cnJlbnQlMkYNCj4gDQo+ICAgSW50ZXJuZXQtRHJh ZnRzIGFyZSBkcmFmdCBkb2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhz DQo+ICAgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVy IGRvY3VtZW50cyBhdCBhbnkNCj4gICB0aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2Ug SW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZQ0KPiAgIG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhl bSBvdGhlciB0aGFuIGFzICJ3b3JrIGluIHByb2dyZXNzLiINCj4gDQo+ICAgVGhpcyBJbnRlcm5l dC1EcmFmdCB3aWxsIGV4cGlyZSBvbiA3IE9jdG9iZXIgMjAyMi4NCj4gDQo+IENvcHlyaWdodCBO b3RpY2UNCj4gDQo+ICAgQ29weXJpZ2h0IChjKSAyMDIyIElFVEYgVHJ1c3QgYW5kIHRoZSBwZXJz b25zIGlkZW50aWZpZWQgYXMgdGhlDQo+ICAgZG9jdW1lbnQgYXV0aG9ycy4gIEFsbCByaWdodHMg cmVzZXJ2ZWQuDQo+IA0KPiAgIFRoaXMgZG9jdW1lbnQgaXMgc3ViamVjdCB0byBCQ1AgNzggYW5k IHRoZSBJRVRGIFRydXN0J3MgTGVnYWwNCj4gICBQcm92aXNpb25zIFJlbGF0aW5nIHRvIElFVEYg RG9jdW1lbnRzIChodHRwczovL3NlY3VyZS13ZWIuY2lzY28uY29tLzFwZzYtd0VoWGZOLU13aGxK OGg3ZW8tZEFsOFFkUG1sZHJkTUN1TjNtRWlhQ25Gc2g5SEc1V2hYWnctV0VVbVlQVUdfRjh2R3Zr SU1Xbm5NODB4ZGtJd2QtQWR0Vk82VENtU2h1N0JvX095bFA0TWdNVDBVdDRCU2RJcVViNVhsb2ww SElSS0I3Qm1PczVxdGc5SkpHdWpFcWt6bHR1OU5sUk1LU0kxT2JKVXJFUEJjU1BUZ3lnbzJ1cHQy aFVpQ1dmaGpuVDMyN3JiaGRnNEQzazRDNEw2Si1pMGM3S0pta2V5VzB0T093M2Rqc3o2UmlGWXFx TGNtdGlPcWhQQkgxL2h0dHBzJTNBJTJGJTJGdHJ1c3RlZS5pZXRmLm9yZyUyRg0KPiAgIGxpY2Vu c2UtaW5mbykgaW4gZWZmZWN0IG9uIHRoZSBkYXRlIG9mIHB1YmxpY2F0aW9uIG9mIHRoaXMgZG9j dW1lbnQuDQo+ICAgUGxlYXNlIHJldmlldyB0aGVzZSBkb2N1bWVudHMgY2FyZWZ1bGx5LCBhcyB0 aGV5IGRlc2NyaWJlIHlvdXIgcmlnaHRzDQo+ICAgYW5kIHJlc3RyaWN0aW9ucyB3aXRoIHJlc3Bl Y3QgdG8gdGhpcyBkb2N1bWVudC4gIENvZGUgQ29tcG9uZW50cw0KPiAgIGV4dHJhY3RlZCBmcm9t IHRoaXMgZG9jdW1lbnQgbXVzdCBpbmNsdWRlIFJldmlzZWQgQlNEIExpY2Vuc2UgdGV4dCBhcw0K PiAgIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDQuZSBvZiB0aGUgVHJ1c3QgTGVnYWwgUHJvdmlzaW9u cyBhbmQgYXJlDQo+ICAgcHJvdmlkZWQgd2l0aG91dCB3YXJyYW50eSBhcyBkZXNjcmliZWQgaW4g dGhlIFJldmlzZWQgQlNEIExpY2Vuc2UuDQo+IA0KPiANCj4gDQo+IEFkZWxsICAgICAgICAgICAg ICAgICAgICBFeHBpcmVzIDcgT2N0b2JlciAyMDIyICAgICAgICAgICAgICAgICBbUGFnZSAxXQ0K PiANCj4gSW50ZXJuZXQtRHJhZnQgICAgICAgICAgIENsaWVudCBSb2FtaW5nIENvbnRyb2wgICAg ICAgICAgICAgICBBcHJpbCAyMDIyDQo+IA0KPiANCj4gVGFibGUgb2YgQ29udGVudHMNCj4gDQo+ ICAgMS4gIEludHJvZHVjdGlvbiAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gICAyDQo+ICAgMi4gIENvbnZlbnRpb25zIFVzZWQgaW4gVGhpcyBEb2N1bWVu dCAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICAzDQo+ICAgMy4gIFRoZSBDUkMgUmVzb3Vy Y2UgUmVjb3JkIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA0DQo+ICAg ICAzLjEuICBSUiBuYW1lIGZpZWxkIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gICA0DQo+ICAgICAzLjIuICBDUkMgUkRBVEEgV2lyZSBGb3JtYXQgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA0DQo+ICAgICAzLjMuICBDUkMgUHJlc2VudGF0 aW9uIEZvcm1hdCAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA0DQo+ICAgNC4g IFRoZSBDUlMgUmVzb3VyY2UgUmVjb3JkIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gICA1DQo+ICAgICA0LjEuICBDUlMgUkRBVEEgV2lyZSBGb3JtYXQgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA1DQo+ICAgICA0LjIuICBDUlMgUHJlc2VudGF0aW9u IEZvcm1hdCAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA1DQo+ICAgNS4gIEV4 YW1wbGVzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gICA2DQo+ICAgICA1LjEuICBSZXN0cmljdGVkIEFwcGxpY2F0aW9uICAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gICA2DQo+ICAgICA1LjIuICBDb250cm9sbGVkIEFwcGxpY2F0 aW9uICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA3DQo+ICAgICA1LjMuICBP cGVuZWQgQXBwbGljYXRpb24gIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g ICA4DQo+ICAgNi4gIElBTkEgQ29uc2lkZXJhdGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gICA5DQo+ICAgNy4gIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA5DQo+ICAgICA3LjEuICBETlMg bWlzY29uZmlndXJhdGlvbiAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA5 DQo+ICAgICA3LjIuICBETlMgU2VjdXJpdHkgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gIDEwDQo+ICAgICA3LjMuICBBcHBsaWNhdGlvbiBTZWN1cml0eSAgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDEwDQo+ICAgOC4gIFJlZmVyZW5jZXMg IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDEwDQo+ ICAgICA4LjEuICBOb3JtYXRpdmUgUmVmZXJlbmNlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gIDExDQo+ICAgICA4LjIuICBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzICAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDExDQo+ICAgQXV0aG9yJ3MgQWRkcmVzcyAg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDExDQo+IA0K PiAxLiAgSW50cm9kdWN0aW9uDQo+IA0KPiAgIElsbGVnaXRpbWF0ZSBhY2Nlc3MgdG8gcHJvZmVz c2lvbmFsIHJlc3RyaWN0ZWQgYXBwbGljYXRpb25zIG92ZXINCj4gICBJbnRlcm5ldCBpcyBhIHBl cm1hbmVudCB0aHJlYXQgZm9yIG9yZ2FuaXphdGlvbnMgYW5kIHRoZWlyIHN0YWZmLg0KPiAgIERp ZmZlcmVudCBtZXRob2RzIGNhbiBiZSB1c2VkIHRvIGltcGVyc29uYXRlIGEgdXNlciBhY2Nlc3Ms IGFuZCBpbg0KPiAgIHNvbWUgY2FzZXMgYW4gb3JnYW5pemF0aW9uIGFsc28gd2FudHMgdG8gYmV0 dGVyIHByZXZlbnQgaXRzIG93biBzdGFmZg0KPiAgIHRvIGFjY2VzcyBhIHRoaXJkLXBhcnR5IGFw cGxpY2F0aW9uIGZyb20gYSBuZXR3b3JrIHdoaWNoIGlzIG5vdCB1bmRlcg0KPiAgIGl0cyBjb250 cm9sLiAgT24gdGhlIGNvbnRyYXJ5LCBhbiBvcmdhbml6YXRpb24gbWF5YmUgd2FudHMgdG8gYWxs b3cNCj4gICByb2FtaW5nIHRoZW4gaXRzIHVzZXJzIGNhbiBhY2Nlc3MgZnJvbSBkaWZmZXJlbnQg a25vd24gcGxhY2VzLg0KPiANCj4gICBUaGUgQ2xpZW50IFJvYW1pbmcgQ29udHJvbCAoQ1JDKSBE TlMgUmVzb3VyY2UgUmVjb3JkIChSUikgYWN0cyBhcyBhDQo+ICAgV2hpdGUtTGlzdCBhbmQgaW5m b3JtcyBhIGNvbXBhdGlibGUgYXBwbGljYXRpb24gZnJvbSB3aGljaCBuZXR3b3Jrcw0KPiAgIGl0 cyB1c2VycyBhcmUgYWxsb3dlZCB0byBjb25uZWN0LCBiZSBpdCBhIGxpbWl0ZWQgbGlzdCBvZiBu ZXR3b3JrcyBvcg0KPiAgIGJyb2FkbHkgd2l0aG91dCBhbnkgcmVzdHJpY3Rpb24uDQo+IA0KPiAN Cj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IEFkZWxsICAgICAgICAg ICAgICAgICAgICBFeHBpcmVzIDcgT2N0b2JlciAyMDIyICAgICAgICAgICAgICAgICBbUGFnZSAy XQ0KPiANCj4gSW50ZXJuZXQtRHJhZnQgICAgICAgICAgIENsaWVudCBSb2FtaW5nIENvbnRyb2wg ICAgICAgICAgICAgICBBcHJpbCAyMDIyDQo+IA0KPiANCj4gICBBdCB0aGUgYXBwbGljYXRpb24g bGV2ZWwsIHRoZSBpZGVudGlmaWNhdGlvbiBvZiB0aGUgdXNlcidzDQo+ICAgb3JnYW5pemF0aW9u IGRvbWFpbiBjYW4gYmUgYmFzZWQgb24gYW4gaW5mb3JtYXRpb24gY2FycmllZCBkdXJpbmcgdGhl DQo+ICAgYXV0aGVudGljYXRpb24gcHJvY2Vzcywgb3IgYSBsb29rdXAgb24gYW4gaW5mb3JtYXRp b24gYWxyZWFkeSBrbm93bg0KPiAgIGJ5IHRoZSBhcHBsaWNhdGlvbi4gIEluIGJvdGggY2FzZXMg dGhpcyBpbmZvcm1hdGlvbiBsZXRzIHRoZQ0KPiAgIGFwcGxpY2F0aW9uIHJlbGF0ZSB0aGUgdXNl ciB0byBpdHMgb3JnYW5pemF0aW9uIHVuZXF1aXZvY2FsbHkuDQo+ICAgRmluYWxseSwgdGhlIGNv cnJlc3BvbmRpbmcgdXNlcidzIGRvbWFpbiBETlMgd2lsbCBiZSByZXF1ZXN0ZWQgd2l0aA0KPiAg IHRoZSBhcHBsaWNhdGlvbidzIEZRRE4gYW5kIHBvcnQsIGFuZCB0aGUgYXBwbGljYXRpb24gd2ls bCBrbm93DQo+ICAgd2hldGhlciBhbiBhdXRob3JpemF0aW9uIGlzIGV4cGVjdGVkIG9yIG5vdC4g IFNvbWUgZXhhbXBsZXMgd2lsbCBiZQ0KPiAgIGdpdmVuIGluIHRoaXMgZG9jdW1lbnQuDQo+IA0K PiAgIFRoZSBhcHBsaWNhdGlvbnMgaW1wbGVtZW50aW5nIHRoaXMgYXV0aG9yaXphdGlvbiBjb250 cm9sIGxldCB0aGUNCj4gICBjbGllbnQgb3JnYW5pemF0aW9ucyBrbm93IHRoaXMgZmVhdHVyZSBp cyBhdmFpbGFibGUgYnkgdXNpbmcgdGhlDQo+ICAgQ2xpZW50IFJvYW1pbmcgU3VwcG9ydCAoQ1JT KSBSUi4gIFRoZSBkYXRhIGFzc29jaWF0ZWQgd2l0aCB0aGlzDQo+ICAgcmVjb3JkIGluZGljYXRl cyBpZiB0aGUgY2xpZW50J3Mgb3JnYW5pemF0aW9uIGV4cGVjdGVkIHN1cHBvcnQgb2YgdGhlDQo+ ICAgQ1JDIGlzIG1hbmRhdG9yeSwgb3B0aW9uYWwsIG9yIGlnbm9yZWQuICBUaGlzIGluZm9ybWF0 aW9uIHN0b3JlZCBpbg0KPiAgIHRoZSBDUlMgY2FuIGJlIGNvbmZpcm1lZCBhdCB0aGUgYXBwbGlj YXRpb24gbGV2ZWwgYnkgYSByZWR1bmRhbnQNCj4gICBkYXRhLiAgVGhlIHdheSB0aGUgYXBwbGlj YXRpb24gaGFuZGxlcyB0aGUgYXV0aG9yaXphdGlvbiBtZWNoYW5pc20sDQo+ICAgYnkgY29uc3Vs dGluZyB0aGUgYXNzb2NpYXRlZCBDUlMgcmVjb3JkIG9yIG5vdCwgaXMgbGVmdCB0byB0aGUNCj4g ICBpbXBsZW1lbnRvci4NCj4gDQo+ICAgQWx0aG91Z2ggdGhpcyBtZWNoYW5pc20gaXMgZGVzaWdu ZWQgZm9yIGltcHJvdmluZyB0aGUgc2VjdXJpdHkNCj4gICBiZXR3ZWVuIGRpZmZlcmVudCBvcmdh bml6YXRpb25zLCB0aGVyZSBpcyBubyBvYmplY3Rpb24gdG8gdXNlIGl0IGZvcg0KPiAgIGEgc2Ft ZSBvcmdhbml6YXRpb24gcGxheWluZyBib3RoIHJvbGVzIG9mIGNsaWVudCBhbmQgYXBwbGljYXRp b24gLCBhcw0KPiAgIGFuIGFsdGVybmF0aXZlIG9yIGFkZGl0aW9uYWwgbGF5ZXIgdG8gYSBzb2x1 dGlvbiBhbHJlYWR5IGluIHBsYWNlLA0KPiAgIHN1Y2ggYXMgYSBmaXJld2FsbCBmb3IgZXhhbXBs ZS4NCj4gDQo+IDIuICBDb252ZW50aW9ucyBVc2VkIGluIFRoaXMgRG9jdW1lbnQNCj4gDQo+ICAg VGhpcyBzcGVjaWZpY2F0aW9uIHVzZXMgZGVmaW5pdGlvbnMgZnJvbSBEb21haW4gTmFtZSBTeXN0 ZW0NCj4gICBbUkZDMTAzNV0sIGFuZCByZWFkZXJzIHVuZmFtaWxpYXIgd2l0aCBpdCBjYW4gYWxz byBjaGVjayBETlMNCj4gICBUZXJtaW5vbG9neSBbUkZDODQ5OV0uICBUaGUgc3ludGF4IHNwZWNp ZmljYXRpb24gdXNlcyB0aGUgQXVnbWVudGVkDQo+ICAgQmFja3VzLU5hdXIgRm9ybSAoQUJORikg bm90YXRpb24gYXMgc3BlY2lmaWVkIGluIFtSRkM1MjM0XSwgd2l0aCBzb21lDQo+ICAgZXhwcmVz c2lvbnMgYmVpbmcgZGVmaW5lZCBpbiAiVW5pZm9ybSBSZXNvdXJjZSBJZGVudGlmaWVyIChVUkkp Og0KPiAgIEdlbmVyaWMgU3ludGF4IiBbUkZDMzk4Nl0gYW5kICJJUCBWZXJzaW9uIDYgQWRkcmVz c2luZyBBcmNoaXRlY3R1cmUiDQo+ICAgW1JGQzQyOTFdLg0KPiANCj4gICBUaGUga2V5IHdvcmRz ICJNVVNUIiwgIk1VU1QgTk9UIiwgIlJFUVVJUkVEIiwgIlNIQUxMIiwgIlNIQUxMIE5PVCIsDQo+ ICAgIlNIT1VMRCIsICJTSE9VTEQgTk9UIiwgIlJFQ09NTUVOREVEIiwgIk5PVCBSRUNPTU1FTkRF RCIsICJNQVkiLCBhbmQNCj4gICAiT1BUSU9OQUwiIGluIHRoaXMgZG9jdW1lbnQgYXJlIHRvIGJl IGludGVycHJldGVkIGFzIGRlc2NyaWJlZCBpbiBCQ1ANCj4gICAxNCBbUkZDMjExOV0gW1JGQzgx NzRdIHdoZW4sIGFuZCBvbmx5IHdoZW4sIHRoZXkgYXBwZWFyIGluIGFsbA0KPiAgIGNhcGl0YWxz LCBhcyBzaG93biBoZXJlLg0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiAN Cj4gQWRlbGwgICAgICAgICAgICAgICAgICAgIEV4cGlyZXMgNyBPY3RvYmVyIDIwMjIgICAgICAg ICAgICAgICAgIFtQYWdlIDNdDQo+IA0KPiBJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgQ2xpZW50 IFJvYW1pbmcgQ29udHJvbCAgICAgICAgICAgICAgIEFwcmlsIDIwMjINCj4gDQo+IA0KPiAzLiAg VGhlIENSQyBSZXNvdXJjZSBSZWNvcmQNCj4gDQo+ICAgVGhlIENSQyBSUiBwdXJwb3NlIGlzIHRv IHByb3ZpZGUgYSBsaXN0IG9mIElQIHJhbmdlcyBhdXRob3JpemVkIHRvDQo+ICAgdXNlIGEgcGFy dGljdWxhciBhcHBsaWNhdGlvbi4gIEVhY2ggUlIgY29udGFpbnMgYSBsaXN0IG9mIGVpdGhlciBJ UHY0DQo+ICAgb3IgSVB2NiBuZXR3b3JrIGFkZHJlc3MgcmFuZ2VzLiAgVGhlc2UgcmFuZ2VzIE1V U1QgZm9sbG93IHRoZSBDSURSDQo+ICAgbm90YXRpb24uICBBIHNpbmdsZSBDUkMgUlIgTUFZIGNv bnRhaW4gcmFuZ2VzIGZvciBkaWZmZXJlbnQgSVANCj4gICB2ZXJzaW9ucywgYnV0IGluIHRoZSBj YXNlIG9mIG1hbnkgcmFuZ2VzIHRoaXMgY2FuIGJlIGRpZmZpY3VsdCB0bw0KPiAgIHJlYWQgb3Ig bWFpbnRhaW4sIHNvIGRlZGljYXRpbmcgYSByZWNvcmQgdG8gZWFjaCBJUCB2ZXJzaW9uIG9yIG5v dCBpcw0KPiAgIGxlZnQgdG8gdGhlIGFkbWluaXN0cmF0b3IuICBNdWx0aXBsZSBSUnMgTUFZIGJl IGRlZmluZWQgZm9yIGEgZ2l2ZW4NCj4gICBJUCB2ZXJzaW9uLg0KPiANCj4gMy4xLiAgUlIgbmFt ZSBmaWVsZA0KPiANCj4gICBUaGUgQ1JDIFJSIG5hbWUgZmllbGQgaXMgY29tcG9zZWQgb2YgdGhl IHRoaXJkLXBhcnR5IGFwcGxpY2F0aW9uDQo+ICAgZG9tYWluLCBpdHMgcG9ydCwgZm9sbG93ZWQg YnkgdGhlIGZ1bGx5IHF1YWxpZmllZCBuYW1lIGluaGVyZW50IGluDQo+ICAgdGhpcyB6b25lLiAg VGhlc2UgdGhyZWUgY29tcG9uZW50cyBhcmUgc2VwYXJhdGVkIGJ5IHRoZSB1bmRlcnNjb3JlDQo+ ICAgY2hhcmFjdGVyLg0KPiANCj4gMy4yLiAgQ1JDIFJEQVRBIFdpcmUgRm9ybWF0DQo+IA0KPiAg IFRoZSBDUkMgUkRBVEEgd2lyZSBmb3JtYXQgaXMgZW5jb2RlZCBhcyBmb2xsb3dzOg0KPiANCj4g ICAgICAgKy0tKy0tKy0tKy0tKy0tKy0tKy0tKy0tKy0tKy0tKy0tKy0tKy0tKy0tKy0tKy0tKw0K PiAgICAgICAvICAgICAgICAgICAgICAgICAgICAgQ1JDICAgICAgICAgICAgICAgICAgICAgICAv DQo+ICAgICAgIC8gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IC8NCj4gICAgICAgKy0tKy0tKy0tKy0tKy0tKy0tKy0tKy0tKy0tKy0tKy0tKy0tKy0tKy0tKy0t Ky0tKw0KPiANCj4gICBUaGUgQ1JDIGZpZWxkIGNvbnRhaW5zIGEgbGlzdCBvZiBlaXRoZXIgSVB2 NCBvciBJUHY2IHJhbmdlcyBzZXBhcmF0ZWQNCj4gICBieSB0aGUgY29tbWEgY2hhcmFjdGVyLg0K PiANCj4gMy4zLiAgQ1JDIFByZXNlbnRhdGlvbiBGb3JtYXQNCj4gDQo+ICAgVGhlIHByZXNlbnRh dGlvbiBmb3JtYXQgb2YgdGhlIENSQyByZWNvcmQgaXM6DQo+IA0KPiAgIENSQyAoaXA0bmV0bGlz dCBbLGlwNm5ldGxpc3RdKSAvIChbaXA0bmV0bGlzdCxdIGlwNm5ldGxpc3QpDQo+IA0KPiAgIGlw NG5ldGxpc3QgPSBpcDRuZXQgKigsaXA0bmV0KQ0KPiANCj4gICBpcDRuZXQgPSBJUHY0YWRkcmVz cyAiLyIgaXA0cmFuZ2UNCj4gDQo+ICAgaXA0cmFuZ2UgPSBESUdJVCAvICIxIiBESUdJVCAvICIy IiBESUdJVCAvICIzIiBESUdJVCAleDMwLTMyDQo+IA0KPiAgIGlwNm5ldGxpc3QgPSBpcDZuZXQg KigsaXA2bmV0KQ0KPiANCj4gICBpcDZuZXQgPSAoaXB2Ni1hZGRyZXNzICIvIiBwcmVmaXgtbGVu Z3RoKQ0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiBBZGVsbCAgICAgICAgICAgICAgICAgICAg RXhwaXJlcyA3IE9jdG9iZXIgMjAyMiAgICAgICAgICAgICAgICAgW1BhZ2UgNF0NCj4gDQo+IElu dGVybmV0LURyYWZ0ICAgICAgICAgICBDbGllbnQgUm9hbWluZyBDb250cm9sICAgICAgICAgICAg ICAgQXByaWwgMjAyMg0KPiANCj4gDQo+IDQuICBUaGUgQ1JTIFJlc291cmNlIFJlY29yZA0KPiAN Cj4gICBUaGUgQ1JTIFJSIGluZGljYXRlcyB3aGljaCBjb250cm9sIGlzIGRvbmUgb24gdGhlIGNs aWVudA0KPiAgIG9yZ2FuaXphdGlvbnMsIGFuZCB0aHVzIHdoaWNoIG9uZXMgYXJlIGF1dGhvcml6 ZWQuICBBIHJlcXVpcmVtZW50DQo+ICAgZmllbGQgaXMgdXNlZCBmb3IgdGhpcyBwdXJwb3NlLCBp dCBoYXMgb25lIG9mIHRoZSBmb2xsb3dpbmcgdmFsdWVzDQo+ICAgbWVhbmluZyB3aGVuIHRoZSBj aGVja2luZyBpcyBwZXJmb3JtZWQgOg0KPiANCj4gICAqICAiTiIgOiBOZXZlciwgYWxsIG9yZ2Fu aXphdGlvbnMgYXJlIGF1dGhvcml6ZWQNCj4gDQo+ICAgKiAgIkEiIDogQWx3YXlzLCBvbmx5IG9y Z2FuaXphdGlvbnMgd2l0aCBhIENSQyBhcmUgYXV0aG9yaXplZA0KPiANCj4gICAqICAiTyIgOiBP cHRpb25hbCwgYW55IG9yZ2FuaXphdGlvbiBDUkMgaXMgaG9ub3JlZCwgb3RoZXINCj4gICAgICBv cmdhbml6YXRpb25zIGFyZSBhdXRob3JpemVkDQo+IA0KPiAgIEluIGFkZGl0aW9uIHRvIHRoaXMg dmFsdWUsIGFuIG9wdGlvbmFsIGxpc3Qgb2YgcG9ydHMgY2FuIGJlIGdpdmVuLg0KPiAgIEluZGVl ZCwgbXVsdGlwbGUgYXBwbGljYXRpb25zIGNhbiBiZSBob3N0ZWQgb24gZGlmZmVyZW50IHBvcnRz IHVuZGVyDQo+ICAgdGhlIHNhbWUgZG9tYWluIG5hbWUsIGFuZCBhbiBlcXVpdmFsZW50IHN1cHBv cnQgd2FzIGRlc2NyaWJlZCBmb3IgdGhlDQo+ICAgQ1JDIFJSLiAgSW4gY2FzZSBvZiBkaWZmZXJl bnQgcmVxdWlyZW1lbnQgdmFsdWVzLCBpdCBpcyBSRUNPTU1FTkRFRA0KPiAgIHRvIGhhdmUgb25l IGRlZGljYXRlZCBSUiBmb3IgZWFjaCBhbHRob3VnaCBvbmUgc2luZ2xlIFJSIHdpdGggYWxsIHRo ZQ0KPiAgIGluZm9ybWF0aW9uIGlzIHN1cHBvcnRlZC4gIE9uZSBwYXJ0aWN1bGFyIHBvcnQgTVVT VCBOT1QgYXBwZWFyIGluDQo+ICAgbW9yZSB0aGFuIG9uZSBSUi4gIFdoZW4gbm8gcG9ydCBpcyBt ZW50aW9uZWQsIG9ubHkgb25lIFJSIE1BWSBiZQ0KPiAgIGRlY2xhcmVkIGFuZCBpdHMgcmVxdWly ZW1lbnQgdmFsdWUgY292ZXJzIGFsbCBhcHBsaWNhdGlvbnMgZm9yIHRoaXMNCj4gICBkb21haW4g bmFtZS4NCj4gDQo+ICAgSW4gdGhlIGFic2VuY2Ugb2Ygc3VjaCByZWNvcmQsIG5vIHJvYW1pbmcg Y29udHJvbCBpcyB0byBiZSBleHBlY3RlZA0KPiAgIGJ5IHRoZSBjbGllbnQsIGFueSBvZiBpdHMg Q1JDIFJScyB3aWxsIGJlIGlnbm9yZWQuICBJdCBpcyBlcXVpdmFsZW50DQo+ICAgdG8gYSBDUlMg cmVxdWlyZW1lbnQgdmFsdWUgaW5kaWNhdGluZyBubyBjb250cm9sIGlzIHBlcmZvcm1lZC4NCj4g DQo+IDQuMS4gIENSUyBSREFUQSBXaXJlIEZvcm1hdA0KPiANCj4gICBUaGUgQ1JTIFJEQVRBIHdp cmUgZm9ybWF0IGlzIGVuY29kZWQgYXMgZm9sbG93czoNCj4gDQo+ICAgICAgICstLSstLSstLSst LSstLSstLSstLSstLSstLSstLSstLSstLSstLSstLSstLSstLSsNCj4gICAgICAgLyAgICAgICAg ICAgICAgICAgICAgIENSUyAgICAgICAgICAgICAgICAgICAgICAgLw0KPiAgICAgICAvICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAvDQo+ICAgICAgICstLSst LSstLSstLSstLSstLSstLSstLSstLSstLSstLSstLSstLSstLSstLSstLSsNCj4gDQo+ICAgVGhl IENSUyBmaWVsZCBjb250YWlucyBhIGxpc3Qgb2YgcmVxdWlyZW1lbnRzIGZvbGxvd2VkIGJ5IHRo ZWlyDQo+ICAgcmVzcGVjdGl2ZSBvcHRpb25hbCBwb3J0cy4NCj4gDQo+IDQuMi4gIENSUyBQcmVz ZW50YXRpb24gRm9ybWF0DQo+IA0KPiAgIFRoZSBwcmVzZW50YXRpb24gZm9ybWF0IG9mIHRoZSBD UlMgcmVjb3JkIGlzOg0KPiANCj4gICBDUlMgKHNpbmdsZS1ydWxlIC8gbXVsdGlwbGUtcnVsZXMp DQo+IA0KPiAgIHNpbmdsZS1ydWxlID0gIlI9IiAoIk4iIC8gIkEiIC8gIk8iKSAqKCxwb3J0KQ0K PiANCj4gDQo+IA0KPiANCj4gQWRlbGwgICAgICAgICAgICAgICAgICAgIEV4cGlyZXMgNyBPY3Rv YmVyIDIwMjIgICAgICAgICAgICAgICAgIFtQYWdlIDVdDQo+IA0KPiBJbnRlcm5ldC1EcmFmdCAg ICAgICAgICAgQ2xpZW50IFJvYW1pbmcgQ29udHJvbCAgICAgICAgICAgICAgIEFwcmlsIDIwMjIN Cj4gDQo+IA0KPiAgIG11bHRpcGxlLXJ1bGVzID0gdW5pdC1ydWxlIDEqMig7dW5pdC1ydWxlKQ0K PiANCj4gICB1bml0LXJ1bGUgPSAiUj0iICgiTiIgLyAiQSIgLyAiTyIpIDEqKCxwb3J0KQ0KPiAN Cj4gICBwb3J0ID0gWzEtOV0gKihbRElHSVRdKQ0KPiANCj4gNS4gIEV4YW1wbGVzDQo+IA0KPiAg IFRoZSBmb2xsb3dpbmcgZXhhbXBsZXMgc2hvdyBzb21lIHR5cGljYWwgdXNlcyBleHBlY3RlZCBm cm9tIHRoaXMNCj4gICBkb2N1bWVudGF0aW9uLiAgUGFydGljdWxhcmx5LCB0aGUgaW50ZW5kZWQg YmVoYXZpb3JzIGZvciBkaWZmZXJlbnQNCj4gICBDUkMgYW5kIENSUyB2YWx1ZXMgYXJlIGV4cGxh aW5lZCwgd2hpbGUgdGhlIHVzZXIgaWRlbnRpZmljYXRpb24gaXMNCj4gICBkb25lIGRpcmVjdGx5 IHRocm91Z2ggY2FycmllZCBkYXRhIG9yIGEgZGVkdWN0aW9uIHByb2Nlc3MuDQo+IA0KPiA1LjEu ICBSZXN0cmljdGVkIEFwcGxpY2F0aW9uDQo+IA0KPiAgIEluIHRoaXMgZXhhbXBsZSwgYW4gYXBw bGljYXRpb24gaXMgb25seSBvcGVuZWQgdG8gb3JnYW5pemF0aW9ucw0KPiAgIHB1Ymxpc2hpbmcg dGhlaXIgcmVzcGVjdGl2ZSBhbGxvd2VkIG5ldHdvcmtzLiAgVGhlIHJlcXVpcmVtZW50IHZhbHVl DQo+ICAgb2YgdGhlIENSUyByZWNvcmQgZXF1YWxzICJBIiwgYW5kIGFueSBvcmdhbml6YXRpb24g d2l0aCBhbiBlbXB0eSBvcg0KPiAgIG1pc3NpbmcgQ1JDIGZvciB0aGlzIGFwcGxpY2F0aW9uIHdp bGwgYmUgZGVuaWVkIGFjY2Vzcy4NCj4gDQo+ICAgVGhlIGZ0cC5mb28uY29tIGRvbWFpbiBpcyBk ZWRpY2F0ZWQgdG8gaG9zdGluZyBhbiBGVFAgYXBwbGljYXRpb24sDQo+ICAgd2hpY2ggZXh0cmFj dHMgdGhlIGNsaWVudCdzIGRvbWFpbiBmcm9tIHRoZSB1c2VybmFtZSB1c2VkIGR1cmluZyB0aGUN Cj4gICBhdXRoZW50aWNhdGlvbiBwcm9jZXNzLiAgVGhpcyBpbmZvcm1hdGlvbiBpcyB0aGVuIHVz ZWQgZm9yIHJlcXVlc3RpbmcNCj4gICB0aGUgY2xpZW50IENSQyByZWNvcmQgYW5kIGZpbmFsbHkg Y29tcGFyaW5nIGl0cyBjb250ZW50IHdpdGggdGhlDQo+ICAgY2xpZW50J3MgSVAuICBUaGUgY2xp ZW50IG9yZ2FuaXphdGlvbiBiYXIuY29tIGFsbG93cyBpdHMgdXNlcnMgZnJvbQ0KPiAgIGl0cyBv d24gbmV0d29yayAxOTUuMTMuMzUuMC8yNCBhbmQgZnJvbSBhIGNsb3VkIHNlcnZpY2UgbG9jYXRl ZCBhdA0KPiAgIDkxLjIyMC40My4wLzI0LiAgQSBzZWNvbmQgb3JnYW5pemF0aW9uIGJhei5jb20g aGFzIG5vIENSQyByZWNvcmQgYW5kDQo+ICAgaXRzIHVzZXJzIGFyZSByZWplY3RlZC4NCj4gDQo+ ICAgQXBwbGljYXRpb24gRlFETiA6IGZ0cC5mb28uY29tDQo+ICAgQXBwbGljYXRpb24gQ1JTIHJl Y29yZCA6IENSUyBSPUEsMjENCj4gDQo+ICAgQ2xpZW50IEZRRE4gOiBiYXIuY29tDQo+ICAgQ2xp ZW50IG9yZ2FuaXphdGlvbiBDUkMgcmVjb3JkIDogQ1JDDQo+ICAgZnRwLmZvby5jb21fMjFfYmFy LmNvbSwxOTUuMTMuMzUuMC8yNCw5MS4yMjAuNDMuMC8yNA0KPiANCj4gICBDbGllbnQgRlFETiA6 IGJhei5jb20NCj4gICBObyBjbGllbnQgb3JnYW5pemF0aW9uIENSQyByZWNvcmQNCj4gDQo+IA0K PiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IEFkZWxsICAgICAg ICAgICAgICAgICAgICBFeHBpcmVzIDcgT2N0b2JlciAyMDIyICAgICAgICAgICAgICAgICBbUGFn ZSA2XQ0KPiANCj4gSW50ZXJuZXQtRHJhZnQgICAgICAgICAgIENsaWVudCBSb2FtaW5nIENvbnRy b2wgICAgICAgICAgICAgICBBcHJpbCAyMDIyDQo+IA0KPiANCj4gICBDbGllbnQgRE5TICBDbGll bnQgRlRQICAgICAgICAgICAgICAgIFNlcnZlciBGVFANCj4gDQo+ICAgICAgICAgICAgICAgICAg ICAgRlRQIFVTRVIgbWVAYmFyLmNvbQ0KPiAgICAgICAgICAgICAgIC0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tPg0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAuLi4NCj4gICAgICAg ICAgICAgICAgICAgICBGVFAgUEFTUyAqKioqKioqKg0KPiAgICAgICAgICAgICAgIC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tPg0KPiAgICAgICAgICBRdWVyeSA6IENSQyBmdHAuZm9vLmNv bV8yMV9iYXIuY29tDQo+ICAgICAgICA8LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQo+ICAgICAgICAgIEFuc3dlciA6IENSQyBmdHAuZm9vLmNvbV8yMV9iYXIuY29tLDE5NS4x My4zNS4wLzI0LDkxLjIyMC40My4wLzI0DQo+ICAgICAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0+DQo+ICAgICAgICAgICAgICAgICAgICAgRlRQIDIzMA0KPiAgICAgICAg ICAgICAgPC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiANCj4gDQo+ICAgICAgICAg ICAgICAgICAgICAgRlRQIFVTRVIgbWVAYmF6LmNvbQ0KPiAgICAgICAgICAgICAgIC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tPg0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAuLi4N Cj4gICAgICAgICAgICAgICAgICAgICBGVFAgUEFTUyAqKioqKioqKg0KPiAgICAgICAgICAgICAg IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPg0KPiAgICAgICAgICBRdWVyeSA6IENSQyBm dHAuZm9vLmNvbV8yMV9iYXouY29tDQo+ICAgICAgICA8LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQo+ICAgICAgICAgIEFuc3dlciA6IE5vIHN1Y2ggbmFtZSAoMykNCj4gICAg ICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLT4NCj4gICAgICAgICAgICAg ICAgICAgICBGVFAgNDMwDQo+ICAgICAgICAgICAgICA8LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQo+IA0KPiA1LjIuICBDb250cm9sbGVkIEFwcGxpY2F0aW9uDQo+IA0KPiAgIFRoZSBm b28uY29tIGRvbWFpbiBob3N0cyBhIFdlYiBhcHBsaWNhdGlvbiBvbiBwb3J0IDQ0MyB1c2luZyBj bGllbnQNCj4gICBjZXJ0aWZpY2F0ZXMgZm9yIGF1dGhlbnRpY2F0aW5nIGl0cyB1c2Vycy4gIFRo ZSBhcHBsaWNhdGlvbiBleHRyYWN0cw0KPiAgIHRoZSBjbGllbnQgZG9tYWlucyBmcm9tIHRoZSBj ZXJ0aWZpY2F0ZXMsIHdoaWNoIGFyZSB1c2VkIHRvIHJldHJpZXZlDQo+ICAgdGhlaXIgQ1JDIHJl Y29yZHMuICBVc2VycyBmcm9tIHRoZSBiYXIuY29tIG9yZ2FuaXphdGlvbiBhcmUgYWxsb3dlZA0K PiAgIG9ubHkgaWYgdGhleSBjb25uZWN0IGZyb20gYW4gYXV0aG9yaXplZCBuZXR3b3JrIGxpc3Rl ZCBpbiB0aGUgQ1JDDQo+ICAgcmVjb3JkLCB3aGlsZSB1c2VycyBmcm9tIGJhei5jb20gYXJlIGFs d2F5cyBncmFudGVkIGFjY2VzcyBzaW5jZSB0aGlzDQo+ICAgb25lIGhhcyBubyBDUkMgZGVjbGFy ZWQuDQo+IA0KPiAgIEFwcGxpY2F0aW9uIEZRRE4gOiBmb28uY29tDQo+ICAgQXBwbGljYXRpb24g Q1JTIHJlY29yZCA6IENSUyBSPUEsNDQzDQo+IA0KPiAgIENsaWVudCBGUUROIDogYmFyLmNvbQ0K PiAgIENsaWVudCBvcmdhbml6YXRpb24gQ1JDIHJlY29yZCA6IENSQw0KPiAgIGZ0cC5mb28uY29t XzQ0M19iYXIuY29tLDE5NS4xMy4zNS4wLzI0LDkxLjIyMC40My4wLzI0DQo+IA0KPiAgIENsaWVu dCBGUUROIDogYmF6LmNvbQ0KPiAgIE5vIGNsaWVudCBvcmdhbml6YXRpb24gQ1JDIHJlY29yZA0K PiANCj4gDQo+IA0KPiANCj4gDQo+IEFkZWxsICAgICAgICAgICAgICAgICAgICBFeHBpcmVzIDcg T2N0b2JlciAyMDIyICAgICAgICAgICAgICAgICBbUGFnZSA3XQ0KPiANCj4gSW50ZXJuZXQtRHJh ZnQgICAgICAgICAgIENsaWVudCBSb2FtaW5nIENvbnRyb2wgICAgICAgICAgICAgICBBcHJpbCAy MDIyDQo+IA0KPiANCj4gICBDbGllbnQgRE5TICBDbGllbnQgYnJvd3NlciAgICAgICAgICAgICAg ICBXZWIgYXBwbGljYXRpb24NCj4gDQo+IA0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg Li4uLi4NCj4gICAgICAgICAgICAgICAgIENsaWVudCBjZXJ0aWZpY2F0ZSBtZUBiYXIuY29tDQo+ ICAgICAgICAgICAgICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0+DQo+ICAg ICAgICAgIFF1ZXJ5IDogQ1JDIGZvby5jb21fNDQzX2Jhci5jb20NCj4gICAgICAgIDwtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gICAgICAgICAgQW5zd2VyIDog Q1JDIGZvby5jb21fNDQzX2Jhci5jb20sMTk1LjEzLjM1LjAvMjQsOTEuMjIwLjQzLjAvMjQNCj4g ICAgICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLT4NCj4gICAg ICAgICAgICAgICAgICAgICAgICAgICAgIC4uLi4uDQo+ICAgICAgICAgICAgICAgICAgICAgMjAw IE9LDQo+ICAgICAgICAgICAgICAgPC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQo+IA0KPiANCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgIC4uLi4uDQo+ICAgICAgICAg ICAgICAgICBDbGllbnQgY2VydGlmaWNhdGUgbWVAYmF6LmNvbQ0KPiAgICAgICAgICAgICAgIC0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPg0KPiAgICAgICAgICBRdWVyeSA6IENS QyBmb28uY29tXzQ0M19iYXouY29tDQo+ICAgICAgICA8LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQo+ICAgICAgICAgIEFuc3dlciA6IE5vIHN1Y2ggbmFtZSAoMykN Cj4gICAgICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLT4NCj4g ICAgICAgICAgICAgICAgICAgICAgICAgICAgIC4uLi4uDQo+ICAgICAgICAgICAgICAgICAgICAg MjAwIE9LDQo+ICAgICAgICAgICAgICAgPC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQo+IA0KPiA1LjMuICBPcGVuZWQgQXBwbGljYXRpb24NCj4gDQo+ICAgQSBjb21wYW55IGlz IHRlc3RpbmcgdGhlIENSQyBhbmQgQ1JTIGJlaGF2aW9ycyBiZWZvcmUgb3BlbmluZyBhIG5ldw0K PiAgIHNlcnZpY2UgdG8gaXRzIGN1c3RvbWVycy4gIEl0cyBmaXJzdCB0ZXN0IGRlc2NyaWJlZCBi ZWxvdyBjb25zaXN0cyBpbg0KPiAgIGNvbmZpZ3VyaW5nIGJvdGggc2lkZXMgdG8gYmUgY29tcGxl dGVseSBvcGVuZWQsIGxpa2VseSBiZWZvcmUNCj4gICBoYXJkZW5pbmcgdGhlIENSUywgdGhlbiB0 aGUgQ1JDLCBhbmQgdGVzdGluZyBhZ2Fpbi4NCj4gDQo+ICAgVGhlIGFwcGxpY2F0aW9uLmZvby5j b20gZG9tYWluIGhvc3RzIGEgV2ViIGFwcGxpY2F0aW9uIG9uIHBvcnQgNDQzDQo+ICAgd2hlcmUg dXNlcnMgYXJlIGxvZ2dlZCBpbiBieSBzZW5kaW5nIGEgbnVtZXJpY2FsIGlkZW50aWZpZXIgYW5k IGENCj4gICBwYXNzd29yZC4gIFRoZSBhcHBsaWNhdGlvbiB1c2VzIGEgZGljdGlvbmFyeSBkYXRh IHR5cGUgdG8gaWRlbnRpZnkNCj4gICB0aGUgdXNlcidzIGRvbWFpbi4gIFRoZSBjbGllbnQuZm9v LmNvbSBkb21haW4gaXMgdGVtcG9yYXJpbHkgdXNpbmcgMg0KPiAgIENSQyByZWNvcmRzIGluZGlj YXRpbmcgYSBmcmVlIGFjY2VzcyBmcm9tIGFueXdoZXJlLg0KPiANCj4gICBBcHBsaWNhdGlvbiBG UUROIDogYXBwbGljYXRpb24uZm9vLmNvbQ0KPiAgIEFwcGxpY2F0aW9uIENSUyByZWNvcmQgOiBD UlMgUj1OLDQ0Mw0KPiANCj4gICBDbGllbnQgRlFETiA6IGNsaWVudC5mb28uY29tDQo+ICAgQ2xp ZW50IG9yZ2FuaXphdGlvbiBDUkMgcmVjb3JkcyA6IENSQw0KPiAgIGFwcGxpY2F0aW9uLmZvby5j b21fNDQzX2Zvby5jb20sMC4wLjAuMC8yNDsgQ1JDDQo+ICAgYXBwbGljYXRpb24uZm9vLmNvbV80 NDNfZm9vLmNvbSxmZTgwOjovMTANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiBBZGVsbCAgICAgICAg ICAgICAgICAgICAgRXhwaXJlcyA3IE9jdG9iZXIgMjAyMiAgICAgICAgICAgICAgICAgW1BhZ2Ug OF0NCj4gDQo+IEludGVybmV0LURyYWZ0ICAgICAgICAgICBDbGllbnQgUm9hbWluZyBDb250cm9s ICAgICAgICAgICAgICAgQXByaWwgMjAyMg0KPiANCj4gDQo+ICAgQ2xpZW50IEROUyAgQ2xpZW50 IGJyb3dzZXIgICAgICAgICAgICAgICAgV2ViIGFwcGxpY2F0aW9uDQo+IA0KPiANCj4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgIC4uLi4uDQo+ICAgICAgICAgICAgICAgICBIVFRQIFBPU1Qg MTIzNDU2LyoqKioqKg0KPiAgICAgICAgICAgICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tPg0KPiAgICAgICAgICAgICAgICAgICAgIDIwMCBPSw0KPiAgICAgICAgICAgICAg IDwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiANCj4gNi4gIElBTkEgQ29u c2lkZXJhdGlvbnMNCj4gDQo+ICAgQWNjb3JkaW5nIHRvIEd1aWRlbGluZXMgZm9yIFdyaXRpbmcg YW4gSUFOQSBDb25zaWRlcmF0aW9ucyBTZWN0aW9uIGluDQo+ICAgUkZDcyBbUkZDODEyNl0gaXQg aXMgYXNrZWQgdG8gSUFOQSB0byBhZGQgaW50byB0aGUgUmVzb3VyY2UgUmVjb3JkDQo+ICAgKFJS KSBUWVBFcyByZWdpc3RyeSBsb2NhdGVkIGF0IGh0dHBzOi8vc2VjdXJlLXdlYi5jaXNjby5jb20v MUpqNTJ4UkJ3N2M4NGE0aUZkNDZPYVVRYnhEcEFuYllDX0dSMEs3aVVnRnFLX0V0em42TVhrT2Rr U2s4T1c0dWQwemItZEdROENrcFhUZ2w3YmV4R2U0WkdreU43eS1zZG1VRlJma1hiWV9wQ3ZQc29x NTY0RHJpaVN5aFNjUG5CdDRkRmN0SHJiX0xmdnExY08yREVvOGVFODR1clJMT2FneDNSaFlDVHVs UmF1UldGcUdDdTdOT1hqSjJSUVp2UG1GYkVKQ0Z6OTF0RDFVRHR3NUFQWkFYNUNKTXliOFd4TEt0 ZDlzenlIZFA2WXJ5V2VJbVJKMGpvRXViUFkzWDcvaHR0cHMlM0ElMkYlMkZ3d3cuaWFuYS5vcmcl MkZhc3NpZ25tZW50cyUyRmRucy0NCj4gICBwYXJhbWV0ZXJzL2Rucy1wYXJhbWV0ZXJzLnhodG1s I2Rucy1wYXJhbWV0ZXJzLTQgdGhlIHR3byBlbnRyaWVzIENSQw0KPiAgIGFuZCBDUlMuDQo+IA0K PiAgICAgICAgICAgKy0tLS0tLSstLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0t LS0tLS0tLSsNCj4gICAgICAgICAgIHwgVFlQRSB8IFZhbHVlIHwgRGVzY3JpcHRpb24gICAgICAg ICAgICB8IFJlZmVyZW5jZSB8DQo+ICAgICAgICAgICArLS0tLS0tKy0tLS0tLS0rLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tKw0KPiAgICAgICAgICAgfCBDUkMgIHwgVEJEMSAg fCBDbGllbnQgUm9hbWluZyBDb250cm9sIHwgdGhpcyBSRkMgIHwNCj4gICAgICAgICAgICstLS0t LS0rLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0rDQo+ICAgICAg ICAgICB8IENSUyAgfCBUQkQyICB8IENsaWVudCBSb2FtaW5nIFN1cHBvcnQgfCB0aGlzIFJGQyAg fA0KPiAgICAgICAgICAgKy0tLS0tLSstLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSst LS0tLS0tLS0tLSsNCj4gDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFRhYmxl IDENCj4gDQo+IDcuICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucw0KPiANCj4gICBUaGlzIHNlY3Rp b24gaXMgbWVhbnQgdG8gaW5mb3JtIGRldmVsb3BlcnMgYW5kIHVzZXJzIG9mIHRoZSBzZWN1cml0 eQ0KPiAgIGltcGxpY2F0aW9ucyBvZiB0aGUgQ1JDL0NSUyBtZWNoYW5pc20gZGVzY3JpYmVkIGJ5 IHRoaXMgZG9jdW1lbnQuDQo+ICAgV2hpbGUgdGhlIENSUyBSUiBtb3N0bHkgcGxheXMgYW4gaW5m b3JtYXRpdmUgcm9sZSwgdGhlIENSQyBSUg0KPiAgIGRlbGl2ZXJzIGltcG9ydGFudCBkYXRhIHdo aWNoIHJlcXVpcmVzIGF0dGVudGlvbiBmcm9tIHRoZSBkZXZlbG9wZXJzDQo+ICAgYW5kIGFkbWlu aXN0cmF0b3JzLiAgU29tZSBwYXJ0aWN1bGFyIHBvaW50cyBhcmUgZGlzY3Vzc2VkIGhlcmUuDQo+ IA0KPiA3LjEuICBETlMgbWlzY29uZmlndXJhdGlvbg0KPiANCj4gICBBbnkgRE5TIENSUyBtaXNj b25maWd1cmF0aW9uIHN1Y2ggYXMgbXVsdGlwbGUgcmVjb3JkcyB3aXRoIGRpZmZlcmVudA0KPiAg IHJlcXVpcmVtZW50IHZhbHVlcyBidXQgd2l0aCB0aGUgc2FtZSBwb3J0IHZhbHVlIGNhbiBnZXQg YSBjbGllbnQNCj4gICBjb25mdXNlZC4gIEluIHRoaXMgY2FzZSB0aGUgY2xpZW50IGRvZXMgbm90 IGtub3cgd2l0aG91dCB0ZXN0aW5nIHRoZQ0KPiAgIGFjdHVhbCBjb25maWd1cmF0aW9uLCBpZiBp dHMgb3JnYW5pemF0aW9uIGlzIHByb3RlY3RlZCBhZ2FpbnN0DQo+ICAgcm9hbWluZywgYW5kIGNv bnRhY3RpbmcgdGhlIGFwcGxpY2F0aW9uIGFkbWluaXN0cmF0b3IgdG8gZml4IHRoZQ0KPiAgIHNp dHVhdGlvbiBpcyBhIHBvc3NpYmlsaXR5Lg0KPiANCj4gICBXaGlsZSBDUkMgbWlzY29uZmlndXJh dGlvbnMgYXJlIG1vcmUgb3IgbGVzcyBsZWFkaW5nIHRvIHNlcmlvdXMNCj4gICBzZWN1cml0eSBw cm9ibGVtcywgYWRtaW5pc3RyYXRvcnMgbmVlZCB0byBwYXkgYXR0ZW50aW9uIHdoZW4gZGVhbGlu Zw0KPiAgIHdpdGggbXVsdGlwbGUgbmV0d29ya3Mgb3IgcmVjb3Jkcy4gIFBhcnRpY3VsYXJseSwg bXVsdGlwbGUgcmVjb3Jkcw0KPiAgIGZvciB0aGUgc2FtZSBuZXR3b3JrIHJhbmdlIG9yIG92ZXJs YXBwaW5nIG5ldHdvcmtzIHNob3VsZCBiZSBhdm9pZGVkLg0KPiANCj4gDQo+IA0KPiBBZGVsbCAg ICAgICAgICAgICAgICAgICAgRXhwaXJlcyA3IE9jdG9iZXIgMjAyMiAgICAgICAgICAgICAgICAg W1BhZ2UgOV0NCj4gDQo+IEludGVybmV0LURyYWZ0ICAgICAgICAgICBDbGllbnQgUm9hbWluZyBD b250cm9sICAgICAgICAgICAgICAgQXByaWwgMjAyMg0KPiANCj4gDQo+IDcuMi4gIEROUyBTZWN1 cml0eQ0KPiANCj4gICBDbGllbnQgYW5kIGFwcGxpY2F0aW9uIGFkbWluaXN0cmF0b3JzIG5lZWQg dG8gcGF5IGFzIG11Y2ggYXR0ZW50aW9uDQo+ICAgYXMgdGhleSB1c3VhbGx5IGRvIHdoZW4gZGVh bGluZyB3aXRoIEROUyBtYW5hZ2VtZW50LiAgQXMgdGhlIENSQw0KPiAgIHJlY29yZHMgYXJlIHN1 cHBvc2VkIHRvIGJlIHJlcXVlc3RlZCBkdXJpbmcgYW4gYXBwbGljYXRpb24NCj4gICBhdXRoZW50 aWNhdGlvbiBwcm9jZXNzLCByZWZsZWN0aW9uIGF0dGFja3MgY291bGQgYmUgYnVpbHQgdG8gdGFy Z2V0IGENCj4gICBjbGllbnQgb3JnYW5pemF0aW9uLCBldmVuIG9uZSBub3QgaG9zdGluZyBhbnkg Q1JDIHJlY29yZCBhdCBhbGwuDQo+ICAgSW4gYSBnZW5lcmFsIG1hbm5lciwgYWRtaW5pc3RyYXRv cnMgbWF5IGNvbnNpZGVyIGFuIGFkZXF1YXRlIFRUTA0KPiAgIHNldHRpbmcgdG8gbm90IG92ZXJs b2FkIGNsaWVudCBvcmdhbml6YXRpb25zLCBlbmFibGUgVENQIGFzIHRoZQ0KPiAgIHByZWZlcnJl ZCB0cmFuc3BvcnQsIG9yIHJlbHkgb24gRE5TU0VDIHRvIHdhcnJhbnQgZGF0YSBhdXRoZW50aWNp dHkNCj4gICBhbmQgaW50ZWdyaXR5Lg0KPiANCj4gNy4zLiAgQXBwbGljYXRpb24gU2VjdXJpdHkN Cj4gDQo+ICAgVGhlIGZvbGxvd2luZyBwb2ludHMgYXJlIG9mIGNvbmNlcm4gdG8gZGV2ZWxvcGVy czoNCj4gDQo+ICAgRW5jcnlwdGlvbjoNCj4gICBXaGVuZXZlciBwb3NzaWJsZSwgdGhlIGFwcGxp Y2F0aW9uIHByb3RvY29sIHNob3VsZCBiZSBlbmNyeXB0ZWQgdG8NCj4gICBwcmV2ZW50IGVhdmVz ZHJvcHBpbmcgYW5kIG1hbi1pbi10aGUtbWlkZGxlIGF0dGFja3MuICBJdCBpcyBhDQo+ICAgY3Jp dGljYWwgcG9pbnQgZm9yIGFwcGxpY2F0aW9ucyBtYWludGFpbmluZyBhIHVzZXIgc2Vzc2lvbiB3 aXRoDQo+ICAgYW55dGhpbmcgbGlrZSBhIHRva2VuIG9yIGNvb2tpZSwgYXMgaXQgY2FuIGxlYWQg dG8gc2Vzc2lvbiBoaWphY2tpbmcNCj4gICBhcyBkaXNjdXNzZWQgYmVsb3cuDQo+IA0KPiAgIFRp bWluZyBhdHRhY2s6DQo+ICAgQWxsIGF1dGhlbnRpY2F0aW9uIHN5c3RlbXMgbmVlZCB0byBiZSBj YXJlZnVsIHRvIG5vdCBkZWxpdmVyIGFueQ0KPiAgIGluZm9ybWF0aW9uIGRlcml2ZWQgZnJvbSB0 aGUgY29tcHV0aW5nIHRpbWUgdG8gYSBkZW5pZWQgdXNlciwgZXZlbg0KPiAgIHRoZSBvbmVzIGlu dm9sdmluZyBtdWx0aXBsZSBmYWN0b3JzIG9yIHN0ZXBzIGxpa2UgdGhlIG9uZSBkZXNjcmliZWQN Cj4gICBpbiB0aGlzIGRvY3VtZW50LiAgSW4gcGFydGljdWxhciwgdGhlIG9yZGVyIGluIHdoaWNo IHRoZXNlIHN0ZXBzIGFyZQ0KPiAgIGV4ZWN1dGVkIGFuZCB0aGVpciByZXNwZWN0aXZlIGltcGxl bWVudGF0aW9ucywgbmVlZCB0byBkZWZlYXQNCj4gICBzdGF0aXN0aWNhbCBoeXBvdGhlc2VzLg0K PiANCj4gICBJbnRlcm1lZGlhdGUgc3lzdGVtczoNCj4gICBTb21lIGFwcGxpY2F0aW9ucyBhcmUg bm90IGRpcmVjdGx5IEludGVybmV0IGZhY2luZyBhbmQgY2Fubm90IGFjY2Vzcw0KPiAgIHRvIHRo ZSByZWFsIGNsaWVudCdzIElQIGFkZHJlc3Mgd2l0aG91dCBpbnZvbHZpbmcgYSBtZWNoYW5pc20g dG8NCj4gICBmb3J3YXJkIHRoaXMgSVAgYXQgdGhlIGFwcGxpY2F0aW9uIGxheWVyLiAgRm9yIGV4 YW1wbGUgd2l0aCBIVFRQLCB0aGUNCj4gICBjb21tb24gcHJhY3RpY2UgYmFzZWQgb24gdGhlIG5v bi1zdGFuZGFyZCBYLUZvcndhcmRlZC1Gb3IgaGVhZGVyLCBvcg0KPiAgIGl0cyBhbHRlcm5hdGl2 ZSBzdGFuZGFyZCBGb3J3YXJkZWQgW1JGQzcyMzldLCBhcmUgcGxheWluZyB0aGlzIHJvbGUuDQo+ ICAgU3VjaCBwcmFjdGljZSByZXF1aXJlcyBhIGNvcnJlY3Qgc2FuaXRpemluZyBvZiB1c2VyIGRh dGEgdG8gYXZvaWQNCj4gICBmYWxzZSBpbmplY3RlZCBJUHMuDQo+IA0KPiAgIFNlc3Npb24gaGlq YWNraW5nOg0KPiAgIEEgd2VsbC1rbm93biBhdHRhY2sgY2FsbGVkIFNlc3Npb24gSGlqYWNraW5n IGlzIG5vdCBtZWFudCB0byBiZQ0KPiAgIGRlZmVhdGVkIGJ5IHRoaXMgZG9jdW1lbnQgYWxvbmUu ICBBcHBsaWNhdGlvbiBkZXZlbG9wZXJzIG11c3QgZW5zdXJlDQo+ICAgdGhhdCBhbnkgcmVjZXZl aWQgc2Vzc2lvbiB0b2tlbiwgc3VjaCBhcyBhbiBIVFRQIENvb2tpZSwgYmVsb25ncyB0bw0KPiAg IHRoZSBzYW1lIElQIGFkZHJlc3MgdGhhbiB0aGUgb25lIHdoaWNoIHN0YXJ0ZWQgdGhpcyBzZXNz aW9uLg0KPiANCj4gOC4gIFJlZmVyZW5jZXMNCj4gDQo+IA0KPiANCj4gDQo+IEFkZWxsICAgICAg ICAgICAgICAgICAgICBFeHBpcmVzIDcgT2N0b2JlciAyMDIyICAgICAgICAgICAgICAgIFtQYWdl IDEwXQ0KPiANCj4gSW50ZXJuZXQtRHJhZnQgICAgICAgICAgIENsaWVudCBSb2FtaW5nIENvbnRy b2wgICAgICAgICAgICAgICBBcHJpbCAyMDIyDQo+IA0KPiANCj4gOC4xLiAgTm9ybWF0aXZlIFJl ZmVyZW5jZXMNCj4gDQo+ICAgW1JGQzEwMzVdICBNb2NrYXBldHJpcywgUC4sICJEb21haW4gbmFt ZXMgLSBpbXBsZW1lbnRhdGlvbiBhbmQNCj4gICAgICAgICAgICAgIHNwZWNpZmljYXRpb24iLCBT VEQgMTMsIFJGQyAxMDM1LCBET0kgMTAuMTc0ODcvUkZDMTAzNSwNCj4gICAgICAgICAgICAgIE5v dmVtYmVyIDE5ODcsIDxodHRwczovL3NlY3VyZS13ZWIuY2lzY28uY29tLzFuZnM1Uk8yWXRRdnF0 SkRvZVRKay1RbnFCUEZRM0hHejZxX0hnZmFKX3ZjckF0MVdtS3lKTjBLQjFsNzRiWnlSRUN6R2xQ UUxXNzFZdUtzNU5CT3lTOU1lbVF4VGlWSDVJbkwzNjMwOTdQSEZSNGU3T3pGMy1razVHdTRkT0Jq WkhhczBaOVpDY2loUHRaRUxraDkwbDFIVjFMYmNyaUlvd2RlZ1B3TmFfckZaa0xEenZ2bnh4cGUz aWRrTW5RWEtDQ05odnhtS3k1cWlQMlcyVU1pVU5rOVNudndLdGxLazdrWi1WTk9qT0k0QmZjbjFf LXRwMV83Sm44UDZsWEM3L2h0dHBzJTNBJTJGJTJGd3d3LnJmYy1lZGl0b3Iub3JnJTJGaW5mbyUy RnJmYzEwMzU+Lg0KPiANCj4gICBbUkZDMjExOV0gIEJyYWRuZXIsIFMuLCAiS2V5IHdvcmRzIGZv ciB1c2UgaW4gUkZDcyB0byBJbmRpY2F0ZQ0KPiAgICAgICAgICAgICAgUmVxdWlyZW1lbnQgTGV2 ZWxzIiwgQkNQIDE0LCBSRkMgMjExOSwNCj4gICAgICAgICAgICAgIERPSSAxMC4xNzQ4Ny9SRkMy MTE5LCBNYXJjaCAxOTk3LA0KPiAgICAgICAgICAgICAgPGh0dHBzOi8vc2VjdXJlLXdlYi5jaXNj by5jb20vMVpRN2hMQllvQ3RsSjRRdXlQMG5BQU9XNmwySUhNeFdXbkhzd2pkaWpEU2o0VEdBQ0Z0 aE9hQm41dUo1azUza05PWFUySkNoNWlCbkl6VEJRZjJmMjBtZXNoMmtwZ0lPMXFvTy1ZUlNWY2k3 NFZIWUE4OFl2R21sQTlHNW8wamlmdHRzOTRic2pqNFZRZVkzMkozVGhpSWNIaWJQMFdWOFBab21a OXYyTFh5YldreW1VV3A3OGg2aEY4WGpUb2RXU1VmMXlmSEZTZU5QdDRMYTNPRTJWNjBmR2U1ampX V1ZMa3hRV3BGQnU1NEY1LUJJUjhyVUNWREphbGpRNFRGaEEvaHR0cHMlM0ElMkYlMkZ3d3cucmZj LWVkaXRvci5vcmclMkZpbmZvJTJGcmZjMjExOT4uDQo+IA0KPiAgIFtSRkMzOTg2XSAgQmVybmVy cy1MZWUsIFQuLCBGaWVsZGluZywgUi4sIGFuZCBMLiBNYXNpbnRlciwgIlVuaWZvcm0NCj4gICAg ICAgICAgICAgIFJlc291cmNlIElkZW50aWZpZXIgKFVSSSk6IEdlbmVyaWMgU3ludGF4IiwgU1RE IDY2LA0KPiAgICAgICAgICAgICAgUkZDIDM5ODYsIERPSSAxMC4xNzQ4Ny9SRkMzOTg2LCBKYW51 YXJ5IDIwMDUsDQo+ICAgICAgICAgICAgICA8aHR0cHM6Ly9zZWN1cmUtd2ViLmNpc2NvLmNvbS8x cmdMWnE1Yk41NGpEcjM0VEdqZnBNdEd5djk3Zy1mMEYyS0FRZ1k4TkpUOE90M2NxekF5cW5DR1JH dEtMdGNhRFphcm4xQzJzWi1QOTIxUjFTQ29UR0JqZGx5aFM2TzExN2djZThnNWlyNmFtMGZueTZn RC1yZGk2QWNmTXpqemFnXzR5bm11Zm5HQUVUQXdKM2lpcGNVbzFDZGM5dUFpRDBTTm5QUnc1SjZf eHM1VENwTkFvdEdtQXNzbXRsZlRJRzZhTVd3T1QyNWdXSk83V1FQaUk2VEk2VEtlZE1UdS1zQUpM dHk2Ym9va0VITDR5VFlnLVc4cEhhT05aeWVaRC9odHRwcyUzQSUyRiUyRnd3dy5yZmMtZWRpdG9y Lm9yZyUyRmluZm8lMkZyZmMzOTg2Pi4NCj4gDQo+ICAgW1JGQzQyOTFdICBIaW5kZW4sIFIuIGFu ZCBTLiBEZWVyaW5nLCAiSVAgVmVyc2lvbiA2IEFkZHJlc3NpbmcNCj4gICAgICAgICAgICAgIEFy Y2hpdGVjdHVyZSIsIFJGQyA0MjkxLCBET0kgMTAuMTc0ODcvUkZDNDI5MSwgRmVicnVhcnkNCj4g ICAgICAgICAgICAgIDIwMDYsIDxodHRwczovL3NlY3VyZS13ZWIuY2lzY28uY29tLzF2X3ZpQ1Fi Wlh1clNuS0Z5TXpYTkxDODUxVHpKTTlDQm5kNVEyUUZ5MWVZRlBwT2xtQmpSeUtPekFrN3JBcmRJ a0poMmhYOXRZT1pCbXBsejJGZGdDX1g5UERvV1hvamljUnNqM2stQ29QclRWRWJCWWdLY0pxTlAt ZWVFVjNGQlBkajIxa1BldWVLaTZ1VFR5U1NPRDkwVy1qSWtJeXQ1S29ERlhUcnlOVzV0b1IzaGZT UEpLSFpTM1FJSmt1bFh1aHdRaEV2N1RQakx2SGZGSDNDRHJjWFE1SjNQSHlZWDA2OFlYaEFJc2hE NkVVdXhSYjEtX0pwZGdwU2lyeGk5L2h0dHBzJTNBJTJGJTJGd3d3LnJmYy1lZGl0b3Iub3JnJTJG aW5mbyUyRnJmYzQyOTE+Lg0KPiANCj4gICBbUkZDNTIzNF0gIENyb2NrZXIsIEQuLCBFZC4gYW5k IFAuIE92ZXJlbGwsICJBdWdtZW50ZWQgQk5GIGZvciBTeW50YXgNCj4gICAgICAgICAgICAgIFNw ZWNpZmljYXRpb25zOiBBQk5GIiwgU1REIDY4LCBSRkMgNTIzNCwNCj4gICAgICAgICAgICAgIERP SSAxMC4xNzQ4Ny9SRkM1MjM0LCBKYW51YXJ5IDIwMDgsDQo+ICAgICAgICAgICAgICA8aHR0cHM6 Ly9zZWN1cmUtd2ViLmNpc2NvLmNvbS8xLVhCeE5KbVJPd0dvclNkOVpBWVN6cnN5UVZZMFpxb21L WDhtdGFDQndOakxCNTNsX2FhS01MNFE3UFNZTFdXakZwSG8wVlhkWjZWd2YwUzBnTmozOE9QYzJq UHBPUFFpQUJFQ2ltUFg0OXJxT09oUnFMNTVDZzRBV3VxSmQzcUpIRGluNVFhVXQyazNYa2twcWNi bkh3eU1WQ3NiS0R6ajZtQk1OMmk5QmRwVHNQcmF6UF9ZNUZtWHJvaWhocGktN1kybzV3dDdJVDRB V0lfd1RYYng1T0FIZGpPWUh2ZGgyZ2Y2MUR5alNZLUZMR0ItSlE1SVNTMjJMaTlPNFZsTS9odHRw cyUzQSUyRiUyRnd3dy5yZmMtZWRpdG9yLm9yZyUyRmluZm8lMkZyZmM1MjM0Pi4NCj4gDQo+ICAg W1JGQzgxNzRdICBMZWliYSwgQi4sICJBbWJpZ3VpdHkgb2YgVXBwZXJjYXNlIHZzIExvd2VyY2Fz ZSBpbiBSRkMNCj4gICAgICAgICAgICAgIDIxMTkgS2V5IFdvcmRzIiwgQkNQIDE0LCBSRkMgODE3 NCwgRE9JIDEwLjE3NDg3L1JGQzgxNzQsDQo+ICAgICAgICAgICAgICBNYXkgMjAxNywgPGh0dHBz Oi8vc2VjdXJlLXdlYi5jaXNjby5jb20vMVBIYXVNbnhMbkgwdU96ampjd2pVOVdIWVRfM0dVQ0F5 aDk0MExlOU1LM0hwLVY4MHYxek1RZjZrSTZHRDBDZzRHdHJXVVU4al9yVDdTdklycGhMZHpDeXk4 WFVnaTNwazNQUVJZdXFLaUpBZzBwTUxBc25hOEkyN1dUa2RHRmtEaXZKQVVZZ3FnalhBZTA3VlQy NlNnc2JlYTRDS2RZbTdRTjVaS2UyTWppdDh3VGxsUDdqOG9YR1FRTm1HTHVKRFNiX3pqMnotUWZW aVhvZ2xVZ2FJdVdoWnU2MWt5VjF2OWkwUEhLaU9KTUZCaThWRkNzOERENEVCclpqMFh3U1gvaHR0 cHMlM0ElMkYlMkZ3d3cucmZjLWVkaXRvci5vcmclMkZpbmZvJTJGcmZjODE3ND4uDQo+IA0KPiA4 LjIuICBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzDQo+IA0KPiAgIFtSRkM3MjM5XSAgUGV0ZXJzc29u LCBBLiBhbmQgTS4gTmlsc3NvbiwgIkZvcndhcmRlZCBIVFRQIEV4dGVuc2lvbiIsDQo+ICAgICAg ICAgICAgICBSRkMgNzIzOSwgRE9JIDEwLjE3NDg3L1JGQzcyMzksIEp1bmUgMjAxNCwNCj4gICAg ICAgICAgICAgIDxodHRwczovL3NlY3VyZS13ZWIuY2lzY28uY29tLzFmWERmTVFsckFKVW9mSHBT YnNlaEdXaF9uZ205eGxMNllVQkQ5aVFRN2xUVnZ4aGsxRmkxTk5DRnVfOEhfZ1ZnQ2RkSFdVcW1J MUQ5d2ZjakEwQXg4U0IxNktfa2REVkhGTGpLQXJnbWFQVXY2Unc5ZXE1bmpFTllkRWFnLUFnQVdE bHpxb0Z2RDdFTWtxLVpJZFZIT2ljMzM0TVZuUzlrd05sb2hPT1R2NTl4OTQxLTM0c3VEczZTY0Z3 NzZhNi1GRzZZZlZsYVAxRFJBN0szSUpCenlMUHRzQlpPX2JWRzZod0p4NTNfNjRGODUxQkxqTkZI bi1va0d3Zng4dGU5L2h0dHBzJTNBJTJGJTJGd3d3LnJmYy1lZGl0b3Iub3JnJTJGaW5mbyUyRnJm YzcyMzk+Lg0KPiANCj4gICBbUkZDODQ5OV0gIEhvZmZtYW4sIFAuLCBTdWxsaXZhbiwgQS4sIGFu ZCBLLiBGdWppd2FyYSwgIkROUw0KPiAgICAgICAgICAgICAgVGVybWlub2xvZ3kiLCBCQ1AgMjE5 LCBSRkMgODQ5OSwgRE9JIDEwLjE3NDg3L1JGQzg0OTksDQo+ICAgICAgICAgICAgICBKYW51YXJ5 IDIwMTksIDxodHRwczovL3NlY3VyZS13ZWIuY2lzY28uY29tLzE4N0J1UlBjQkxyOXNTUk1neHY1 LURyeWdxb21ORy1LMGpEZnBGNkZMLURTYnNQOENFOTNnemN6emR0WjlUc2NVMzdhbXF1cnJsVWY4 cTktVWJ6bU95Qk16bXNjNTJyY3dwSU1FWkRQcE1BYUpBQ3VOUGJWaEJ3ejlxYXNfN2ZORjdKU0E0 QjRwalRNamstc2VWZDRSOEtHRHZFYVB4ZzBLbktBaGM2U09PdkNGY3pFMVhyN1h2bkYtalNSLUNf NFVzazZGU25YNEtUWGplbzdZV0lhMVJ2X292bDN5UUhmai10bkpoMEQyS2tKRDVKcHQxUUdkLUh1 NHY2eUVoc3I2L2h0dHBzJTNBJTJGJTJGd3d3LnJmYy1lZGl0b3Iub3JnJTJGaW5mbyUyRnJmYzg0 OTk+Lg0KPiANCj4gQXV0aG9yJ3MgQWRkcmVzcw0KPiANCj4gICBFdWdlbmUgQWRlbGwNCj4gICBF bWFpbDogZXVnZW5lLmFkZWxsQGdtYWlsLmNvbQ0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiAN Cj4gDQo+IEFkZWxsICAgICAgICAgICAgICAgICAgICBFeHBpcmVzIDcgT2N0b2JlciAyMDIyICAg ICAgICAgICAgICAgIFtQYWdlIDExXQ0KPiANCj4gDQo+IFJGQyA2ODk1IDoNCj4gQS4gU3VibWlz c2lvbiBEYXRlOjIwMDIvMDQvMDUNCj4gQi4xIFN1Ym1pc3Npb24gVHlwZTogIFtYXSBOZXcgUlJU WVBFICBbIF0gTW9kaWZpY2F0aW9uIHRvIFJSVFlQRQ0KPiBCLjIgS2luZCBvZiBSUjogIFtYXSBE YXRhIFJSICBbIF0gTWV0YS1SUg0KPiBDLiBDb250YWN0IEluZm9ybWF0aW9uIGZvciBzdWJtaXR0 ZXIgOg0KPiAgIE5hbWU6IEV1Z2VuZSBBZGVsbCAgICAgICAgICAgICAgIEVtYWlsIEFkZHJlc3M6 IGV1Z2VuZS5hZGVsbEBnbWFpbC5jb20NCj4gICBJbnRlcm5hdGlvbmFsIHRlbGVwaG9uZSBudW1i ZXI6ICszMzY5OTA1NjkxNA0KPiAgIE90aGVyIGNvbnRhY3QgaGFuZGxlczoNCj4gRC4gTW90aXZh dGlvbiBmb3IgdGhlIG5ldyBSUlRZUEUgYXBwbGljYXRpb24uDQo+ICAgSW50cm9kdWNlIGEgY291 cGxlIG9mIFJSIHR5cGVzIHdvcmtpbmcgdG9nZXRoZXIgaW4gb3JkZXIgdG8gYmV0dGVyDQo+IHNl Y3VyZSByZW1vdGUgYWNjZXNzIHRvIHBhcnRuZXIgYXBwbGljYXRpb25zDQo+IEUuIERlc2NyaXB0 aW9uIG9mIHRoZSBwcm9wb3NlZCBSUiB0eXBlLg0KPiAgIENSQyBjb250YWlucyBhIGxpbWl0ZWQg bGlzdCBvZiBhdXRob3JpemVkIG5ldHdvcmtzIGZvciBhIHBhcnRpY3VsYXINCj4gYXBwbGljYXRp b24NCj4gRi4gV2hhdCBleGlzdGluZyBSUlRZUEUgb3IgUlJUWVBFcyBjb21lIGNsb3Nlc3QgdG8g ZmlsbGluZyB0aGF0IG5lZWQNCj4gYW5kIHdoeSBhcmUgdGhleSB1bnNhdGlzZmFjdG9yeT8NCj4g ICBUWFQgUlJUWVBFIGFsbG93cyB0aGUgc3RvcmFnZSBvZiBhbnkgdGV4dCBkYXRhIGJ1dCBpbiBw cmFjdGljZSBpcw0KPiB1c3VhbGx5IGFzc29jaWF0ZWQgd2l0aCBtb3JlIG9yIGxlc3MgZml4ZWQg bmFtZSBvciBkYXRhIHdoaWNoIGlzIG5vdA0KPiB3aGF0IGlzIG5lZWRlZCBoZXJlLiBBIGRlZGlj YXRlZCBSUlRZUEUgaXMgZWFzaWVyIHRvIGlkZW50aWZ5IGFuZA0KPiBtYW5hZ2UgYnkgYSBzZWN1 cml0eSB0ZWFtIG90aGVyIHRoYW4gdGhlIHVzdWFsIEROUyBvcGVyYXRvciB0ZWFtLg0KPiBHLiBX aGF0IG1uZW1vbmljIGlzIHJlcXVlc3RlZCBmb3IgdGhlIG5ldyBSUlRZUEUgKG9wdGlvbmFsKT8N Cj4gICBDUkMNCj4gSC4gRG9lcyB0aGUgcmVxdWVzdGVkIFJSVFlQRSBtYWtlIHVzZSBvZiBhbnkg ZXhpc3RpbmcgSUFOQSByZWdpc3RyeSBvcg0KPiByZXF1aXJlIHRoZSBjcmVhdGlvbiBvZiBhIG5l dyBJQU5BIHN1YnJlZ2lzdHJ5IGluIEROUyBQYXJhbWV0ZXJzPw0KPiAgIEl0IHVzZXMgdGhlIGV4 aXN0aW5nIFJlc291cmNlIFJlY29yZCAoUlIpIFRZUEVzIHJlZ2lzdHJ5DQo+IEkuIERvZXMgdGhl IHByb3Bvc2FsIHJlcXVpcmUvZXhwZWN0IGFueSBjaGFuZ2VzIGluIEROUw0KPiBzZXJ2ZXJzL3Jl c29sdmVycyB0aGF0IHByZXZlbnQgdGhlIG5ldyB0eXBlIGZyb20gYmVpbmcgcHJvY2Vzc2VkIGFz IGFuDQo+IHVua25vd24gUlJUWVBFIChzZWUgW1JGQzM1OTddKT8NCj4gICBObw0KPiBKLiBDb21t ZW50czoNCj4gICBOb25lDQo+IA0KPiANCj4gQS4gU3VibWlzc2lvbiBEYXRlOjIwMDIvMDQvMDUN Cj4gQi4xIFN1Ym1pc3Npb24gVHlwZTogIFtYXSBOZXcgUlJUWVBFICBbIF0gTW9kaWZpY2F0aW9u IHRvIFJSVFlQRQ0KPiBCLjIgS2luZCBvZiBSUjogIFtYXSBEYXRhIFJSICBbIF0gTWV0YS1SUg0K PiBDLiBDb250YWN0IEluZm9ybWF0aW9uIGZvciBzdWJtaXR0ZXIgOg0KPiAgIE5hbWU6IEV1Z2Vu ZSBBZGVsbCAgICAgICAgICAgICAgIEVtYWlsIEFkZHJlc3M6IGV1Z2VuZS5hZGVsbEBnbWFpbC5j b20NCj4gICBJbnRlcm5hdGlvbmFsIHRlbGVwaG9uZSBudW1iZXI6ICszMzY5OTA1NjkxNA0KPiAg IE90aGVyIGNvbnRhY3QgaGFuZGxlczoNCj4gRC4gTW90aXZhdGlvbiBmb3IgdGhlIG5ldyBSUlRZ UEUgYXBwbGljYXRpb24uDQo+ICAgSW50cm9kdWNlIGEgY291cGxlIG9mIFJSIHR5cGVzIHdvcmtp bmcgdG9nZXRoZXIgaW4gb3JkZXIgdG8gYmV0dGVyDQo+IHNlY3VyZSByZW1vdGUgYWNjZXNzIHRv IHBhcnRuZXIgYXBwbGljYXRpb25zDQo+IEUuIERlc2NyaXB0aW9uIG9mIHRoZSBwcm9wb3NlZCBS UiB0eXBlLg0KPiAgIENSUyBjb250YWlucyBhIHJlcXVpcmVtZW50IHZhbHVlIGFuZCBhIGxpc3Qg b2YgcG9ydHMgaW5kaWNhdGluZw0KPiB3aGF0IGtpbmQgb2YgYXV0aG9yaXphdGlvbiBjaGVjayBp cyBkb25lIGR1cmluZyB0aGUgYXBwbGljYXRpb24NCj4gYXV0aGVudGljYXRpb24gcHJvY2Vzcw0K PiBGLiBXaGF0IGV4aXN0aW5nIFJSVFlQRSBvciBSUlRZUEVzIGNvbWUgY2xvc2VzdCB0byBmaWxs aW5nIHRoYXQgbmVlZA0KPiBhbmQgd2h5IGFyZSB0aGV5IHVuc2F0aXNmYWN0b3J5Pw0KPiAgIFRY VCBSUlRZUEUgYWxsb3dzIHRoZSBzdG9yYWdlIG9mIGFueSB0ZXh0IGRhdGEgYnV0IGluIHByYWN0 aWNlIGlzDQo+IHVzdWFsbHkgYXNzb2NpYXRlZCB3aXRoIG1vcmUgb3IgbGVzcyBmaXhlZCBuYW1l IG9yIGRhdGEgd2hpY2ggaXMgbm90DQo+IHdoYXQgaXMgbmVlZGVkIGhlcmUuIEEgZGVkaWNhdGVk IFJSVFlQRSBpcyBlYXNpZXIgdG8gaWRlbnRpZnkgYW5kDQo+IG1hbmFnZSBieSBhIHNlY3VyaXR5 IHRlYW0gb3RoZXIgdGhhbiB0aGUgdXN1YWwgRE5TIG9wZXJhdG9yIHRlYW0uDQo+IEcuIFdoYXQg bW5lbW9uaWMgaXMgcmVxdWVzdGVkIGZvciB0aGUgbmV3IFJSVFlQRSAob3B0aW9uYWwpPw0KPiAg IENSUw0KPiBILiBEb2VzIHRoZSByZXF1ZXN0ZWQgUlJUWVBFIG1ha2UgdXNlIG9mIGFueSBleGlz dGluZyBJQU5BIHJlZ2lzdHJ5IG9yDQo+IHJlcXVpcmUgdGhlIGNyZWF0aW9uIG9mIGEgbmV3IElB TkEgc3VicmVnaXN0cnkgaW4gRE5TIFBhcmFtZXRlcnM/DQo+ICAgSXQgdXNlcyB0aGUgZXhpc3Rp bmcgUmVzb3VyY2UgUmVjb3JkIChSUikgVFlQRXMgcmVnaXN0cnkNCj4gSS4gRG9lcyB0aGUgcHJv cG9zYWwgcmVxdWlyZS9leHBlY3QgYW55IGNoYW5nZXMgaW4gRE5TDQo+IHNlcnZlcnMvcmVzb2x2 ZXJzIHRoYXQgcHJldmVudCB0aGUgbmV3IHR5cGUgZnJvbSBiZWluZyBwcm9jZXNzZWQgYXMgYW4N Cj4gdW5rbm93biBSUlRZUEUgKHNlZSBbUkZDMzU5N10pPw0KPiAgIE5vDQo+IEouIENvbW1lbnRz Og0KPiAgIE5vbmUNCj4gPGRyYWZ0LWFkZWxsLWNsaWVudC1yb2FtaW5nLTAwLnR4dD48UkZDIDY4 OTUgbWF0ZXJpYWwudHh0Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+IEROU09QIG1haWxpbmcgbGlzdA0KPiBETlNPUEBpZXRmLm9yZw0KPiBodHRwczov L3NlY3VyZS13ZWIuY2lzY28uY29tLzE5by1PTzM2Wm4tR2VMWE9QWHVTTE15b09hWUJmMWNrSFB2 UUl0Zk1VNDFHc1dlNUw1T3NUWlR4NENRb0xIYTV2MTlOVDlXYl9xVDhWTmx0UC1xdEhMTUlRTG1K emc4T2dNWkRjYS1naHp0NXRtNWtuWEI4ZE4wNXFxUGpGWWI3SFJZUmJTTGh0QklEU2l3LWNsUXox by1ZZ3hTS2x4SEYxNGt4SnQxWVlKcjRNR3dDbG5xTElDQ25hcE5LVGl1UWFPMEs2ZGIzNG13aHpl TkZiczRYckJWNkFXWFl1ZUVyUE45dW9qVExwN1RCQ1NNNWFCeDNDczdKUk14QmR0Vzd6L2h0dHBz JTNBJTJGJTJGd3d3LmlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGZG5zb3ANCg0K From nobody Sun Apr 10 20:13:17 2022 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 97DF03A19D1 for ; Sun, 10 Apr 2022 20:13:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, T_SCC_BODY_TEXT_LINE=-0.01, 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 Uw4ssN40CJUP for ; Sun, 10 Apr 2022 20:13:10 -0700 (PDT) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id 033133A11D9 for ; Sun, 10 Apr 2022 20:13:05 -0700 (PDT) Received: from CNNIC-PC (unknown [218.241.111.115]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0CpsXm6nFNixTlYAA--.2561S2; Mon, 11 Apr 2022 11:12:58 +0800 (CST) Date: Mon, 11 Apr 2022 11:12:58 +0800 From: zhangcuiling To: dnsop X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.2.18.95[cn] Mime-Version: 1.0 Message-ID: <202204111111585901567@cnnic.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart004300256512_=----" X-CM-TRANSID: AQAAf0CpsXm6nFNixTlYAA--.2561S2 X-Coremail-Antispam: 1UD129KBjvJXoWruw15KrWrWFyktF48JF1rtFb_yoW8Jr1rpa 1xtrn8Aas5KasxGanYq3W8AFWrtryYkayDGwn8Jryjya98AFn3Aw1Ikay5J34aqw1kG3Zr Jr4xAr1qvr4rZa7anT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUQIb7Iv0xC_Cr1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Xr0_Ar1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Gr0_Cr1l84ACjcxK6I8E87Iv67AKxVWxJr0_GcWl84ACjcxK6I 8E87Iv6xkF7I0E14v26rxl6s0DM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVAYj202 j2C_Gr0_Xr1l5I8CrVAKz4kIr2xC04v26r1j6r4UMc02F40Ex7xS67I2xxkvbII20VAFz4 8EcVAYj21lYx0E2Ix0cI8IcVAFwI0_Jr0_Jr4lYx0Ex4A2jsIE14v26r1j6r4UMcvjeVCF s4IE7xkEbVWUJVW8JwACjcxG0xvY0x0EwIxGrwACY4xI67k04243AVAKzVAKj4xxM4xvF2 IEb7IF0Fy26I8I3I1lc2xSY4AK67AK6r48MxAIw28IcxkI7VAKI48JMxC20s026xCaFVCj c4AY6r1j6r4UMI8I3I0E5I8CrVAFwI0_JrI_JrWlx2IqxVCjr7xvwVAFwI0_JrI_JrWlx4 CE17CEb7AF67AKxVWUJVWUXwCIc40Y0x0EwIxGrwCI42IY6xIIjxv20xvE14v26r1j6r1x MIIF0xvE2Ix0cI8IcVCY1x0267AKxVWUJVW8JwCI42IY6xAIw20EY4v20xvaj40_WFyUJV Cq3wCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E14v26r1j6r4UMVCE FcxC0VAYjxAxZFUvcSsGvfC2KfnxnUUI43ZEXa7IU8Wv37UUUUU== X-CM-SenderInfo: x2kd0wxfxlzxlqj6u0xqlfhubq/ Archived-At: Subject: [DNSOP] A new draft on SM2 digital signature algorithm for DNSSEC X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2022 03:13:15 -0000 This is a multi-part message in MIME format. ------=_001_NextPart004300256512_=---- Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGkgZG5zb3AsDQogDQpNeSBjb3dvcmtlcnMgYW5kIEkgaGF2ZSB3cml0dGVuIGEgZHJhZnQgb24g U00yIGRpZ2l0YWwgc2lnbmF0dXJlIGFsZ29yaXRobSBmb3IgRE5TU0VDLg0KIA0KVGhlIG1haW4g Y29udGVudCBpcyB0byBpbnRyb2R1Y2UgdGhlIGZvcm1hdCBvZiBETlNLRVkvUlJTSUcgUlJzIHVz aW5nIFNNMiBkaWdpdGFsIHNpZ25hdHVyZSBhbGdvcml0aG0gd2l0aCBTTTMgZGlnZXN0IGFsZ29y aXRobSwgYW5kIHRoZSBmb3JtYXQgb2YgRFMvTlNFQzMgUlJzIHVzaW5nIFNNMyBkaWdlc3QgYWxn b3JpdGhtLg0KIA0KQW5kIHRoZSBtYWluIHB1cnBvc2UgaXMgdG8gaW1wcm92ZSB0aGUgZGl2ZXJz aXR5IG9mIEROU1NFQyBhbGdvcml0aG1zLCBhbmQgdG8gbWFrZSBpdCBjb252ZW5pZW50IGZvciBw ZW9wbGUgd2hvIHdhbnQgdG8gdXNlIFNNMiBkaWdpdGFsIHNpZ25hdHVyZSBhbGdvcml0aG0gYXMg YW4gYWx0ZXJuYXRpdmUgZm9yIEROU1NFQy4NCiANCkkgd291bGQgbG92ZSB0byBoZWFyIGNvbW1l bnRzIGFuZCBzdWdnZXN0aW9ucyBmcm9tIHlvdS4NCg0KVGhhbmtzIGluIGFkdmFuY2UuDQoNCk5h bWU6IGRyYWZ0LWN1aWxpbmctZG5zb3Atc20yLWFsZw0KUmV2aXNpb246IDAwDQpUaXRsZTogU00y IERpZ2l0YWwgU2lnbmF0dXJlIEFsZ29yaXRobSBmb3IgRE5TU0VDDQpEb2N1bWVudCBkYXRlOiAy MDIyLTA0LTA3DQpHcm91cDogSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpQYWdlczogNQ0KVVJMOiAg ICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2FyY2hpdmUvaWQvZHJhZnQtY3VpbGluZy1k bnNvcC1zbTItYWxnLTAwLnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LWN1aWxpbmctZG5zb3Atc20yLWFsZy8NCkh0bWxpemVkOiAgICAg ICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWN1aWxpbmctZG5z b3Atc20yLWFsZw0KIA0KQWJzdHJhY3Q6DQogIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGhvdyB0 byBzcGVjaWZ5IFNNMiBEaWdpdGFsIFNpZ25hdHVyZQ0KICBBbGdvcml0aG0ga2V5cyBhbmQgc2ln bmF0dXJlcyBpbiBETlMgU2VjdXJpdHkgKEROU1NFQykuIEl0IGxpc3RzDQogIHRoZSBjdXJ2ZSBh bmQgdXNlcyBTTTMgYXMgaGFzaCBhbGdvcml0aG0gZm9yIHNpZ25hdHVyZXMuDQogDQpCZXN0IHJl Z2FyZHMsDQogDQpDYXRoeSBaaGFuZw0KDQoyMDIyLTA0LTExDQoNCg== ------=_001_NextPart004300256512_=---- Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi dnsop,

 

My coworkers and I have written a draft on SM2 digital signature algo= rithm for DNSSEC.

<= o:p> 

The main content is to i= ntroduce the format of DNSKEY/RRSIG RRs using SM2 digital signature algori= thm with SM3 digest algorithm, and the format of DS/NSEC3 RRs using SM3 di= gest algorithm.

<= o:p> 

And the main purpose is = to improve the diversity of DNSSEC algorithms, and to make it convenient f= or people who want to use SM2 digital signature algorithm as an alternativ= e for DNSSEC.

=  

I would love to hear comments= and suggestions from you.


Thanks in advance.


<= /p>

Name: draft-cuiling-dnsop-sm2-alg
Revision: 00
Title: SM2 Digital Signature Algorithm for DNSSE= C
Document date: 2022-04-0= 7
Group: Individual Submis= sion
Pages: 5
=
URL:     &nbs= p;      https://www.ietf.org/archive/id/draft-cui= ling-dnsop-sm2-alg-00.txt
= Status:         https://datatracke= r.ietf.org/doc/draft-cuiling-dnsop-sm2-alg/
Htmlized:       https://da= tatracker.ietf.org/doc/html/draft-cuiling-dnsop-sm2-alg
<= span style=3D"font-family: 'Times New Roman'; line-height: 1.5; background= -color: transparent;"> 
Abstract:
  This d= ocument describes how to specify SM2 Digital Signature
  Algorithm keys and signatures in DNS S= ecurity (DNSSEC). It lists

  the curve and use= s SM3 as hash algorithm for signatures.
 

Best regards,

&nbs= p;

Cathy Zhang


2022-04-11


------=_001_NextPart004300256512_=------ From nobody Mon Apr 11 00:58:05 2022 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 878A73A0C66 for ; Mon, 11 Apr 2022 00:58:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.107 X-Spam-Level: X-Spam-Status: No, score=-2.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isc.org header.b=KwK3tPyX; dkim=pass (1024-bit key) header.d=isc.org header.b=XNWjET4S 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 uV2_Tb4ADxuP for ; Mon, 11 Apr 2022 00:57:57 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B93D43A07FB for ; Mon, 11 Apr 2022 00:57:57 -0700 (PDT) Received: from zimbrang.isc.org (zimbrang.isc.org [149.20.1.12]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx.pao1.isc.org (Postfix) with ESMTPS id 1ECF33AB008; Mon, 11 Apr 2022 07:57:57 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.10.3 mx.pao1.isc.org 1ECF33AB008 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=isc.org; s=ostpay; t=1649663877; bh=PHnT74KoPbpjFD7w5+gO0aWFooADvKZa8NQpG5AFaEU=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=KwK3tPyXiaOVh7JiCI6eb0TcoKRKETPGJXomlqCJZ2esUDraPU2zbUjkMf9HrtKPl VfED4rawk9i+m76cZW2Rb9VVaRPNuZfUkrFgP+H724zPxrkOQXaY1n2CMIU2JJdj8V aFzaFfsMjP+Sy8RNcQTcsyjv72p3uIARme9kWFkA= Received: from zimbrang.isc.org (localhost.localdomain [127.0.0.1]) by zimbrang.isc.org (Postfix) with ESMTPS id 04D16A20CE1; Mon, 11 Apr 2022 07:57:57 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbrang.isc.org (Postfix) with ESMTP id B9C6AA20CE3; Mon, 11 Apr 2022 07:57:56 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.10.3 zimbrang.isc.org B9C6AA20CE3 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=05DFB016-56A2-11EB-AEC0-15368D323330; t=1649663876; bh=iT6i/19U4iILu4GdViISDTHSWRnzz3dt/hX54wkQEI0=; h=Mime-Version:From:Date:Message-Id:To; b=XNWjET4SKZBwLVynRnINVZLsBC0as8Jl9pcPTYKIRGtCGwA5YydDjEKlA84miMCbD nZzc47B5ufBikdyowctXoJV+EfzRtbU1MfQAktkGgB0FhjPn1dZ/ssDnQQdL3ULrkt CuNl80kaxv/PbLQlNlTdcUUMiUDMfGk9X11izwDw= Received: from zimbrang.isc.org ([127.0.0.1]) by localhost (zimbrang.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id va-TUVtO6x6W; Mon, 11 Apr 2022 07:57:56 +0000 (UTC) Received: from smtpclient.apple (n114-74-26-107.bla4.nsw.optusnet.com.au [114.74.26.107]) by zimbrang.isc.org (Postfix) with ESMTPSA id E27B6A20CE1; Mon, 11 Apr 2022 07:57:55 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Mark Andrews In-Reply-To: Date: Mon, 11 Apr 2022 17:57:53 +1000 Cc: dnsop@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: To: =?utf-8?Q?Eug=C3=A8ne_Adell?= X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: Subject: Re: [DNSOP] introducing a couple of RRTypes (CRC/CRS) for B2B applications X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2022 07:58:04 -0000 I don=E2=80=99t see why APL (RFC 3123) can=E2=80=99t be used for CRC = give you need to construct an owner name anyway and have well known label to seperate the components = of the name. I see no reason to re-invent the wheel here. ftp.foo.com_21_bar.com,195.13.35.0/24,91.220.43.0/24 would be ftp.foo.com._21._crc.bar.com APL 1:195.13.35.0/24 1:91.220.43.0/24 > On 5 Apr 2022, at 20:52, Eug=C3=A8ne Adell = wrote: >=20 > Hello, >=20 > I've been working on two new RRTypes described by a Draft, and as > suggested by our magnificent, incredibly brilliant and handsome AD > Warren "ACE" Kumari, I am posting here this idea and the material I > have written so far (the draft itself, and RFC 6895 components). >=20 > Briefly, one RRType (CRC : Client Roaming Control) contains a > whitelist of networks allowing a company employees to connect to a > specific application. The second RRType (CRS : Client Roaming Support) > is on the application side and informs what kind of restrictions are > applied (by saying if CRC is mandatory, optional or ignored). > This is not expected to be deployed broadly and everywhere as it is > designed to secure Business-To-Business applications. >=20 > The material (text XML2RFC draft + RFC 6895 components) written is > both incorporated below to this email and attached, for practical > reasons. >=20 >=20 > Regards > E.A. >=20 >=20 >=20 >=20 >=20 > Internet Engineering Task Force E. = Adell > Internet-Draft 5 April = 2022 > Intended status: Informational > Expires: 7 October 2022 >=20 >=20 > Client Roaming Control > draft-adell-client-roaming-00 >=20 > Abstract >=20 > This document specifies the Client Roaming Control (CRC) DNS = Resource > Record allowing an organization to better control the access to > third-party applications over Internet. The applications > implementing an authorization mechanism to honor the CRC, publish on > their side the Client Roaming Support (CRS) Resource Record to = inform > of this support. >=20 > Status of This Memo >=20 > This Internet-Draft is submitted in full conformance with the > provisions of BCP 78 and BCP 79. >=20 > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF). Note that other groups may also distribute > working documents as Internet-Drafts. The list of current Internet- > Drafts is at https://datatracker.ietf.org/drafts/current/. >=20 > Internet-Drafts are draft documents valid for a maximum of six = months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." >=20 > This Internet-Draft will expire on 7 October 2022. >=20 > Copyright Notice >=20 > Copyright (c) 2022 IETF Trust and the persons identified as the > document authors. All rights reserved. >=20 > This document is subject to BCP 78 and the IETF Trust's Legal > Provisions Relating to IETF Documents (https://trustee.ietf.org/ > license-info) in effect on the date of publication of this document. > Please review these documents carefully, as they describe your = rights > and restrictions with respect to this document. Code Components > extracted from this document must include Revised BSD License text = as > described in Section 4.e of the Trust Legal Provisions and are > provided without warranty as described in the Revised BSD License. >=20 >=20 >=20 > Adell Expires 7 October 2022 [Page = 1] >=20 > Internet-Draft Client Roaming Control April = 2022 >=20 >=20 > Table of Contents >=20 > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . = 2 > 2. Conventions Used in This Document . . . . . . . . . . . . . . = 3 > 3. The CRC Resource Record . . . . . . . . . . . . . . . . . . . = 4 > 3.1. RR name field . . . . . . . . . . . . . . . . . . . . . . = 4 > 3.2. CRC RDATA Wire Format . . . . . . . . . . . . . . . . . . = 4 > 3.3. CRC Presentation Format . . . . . . . . . . . . . . . . . = 4 > 4. The CRS Resource Record . . . . . . . . . . . . . . . . . . . = 5 > 4.1. CRS RDATA Wire Format . . . . . . . . . . . . . . . . . . = 5 > 4.2. CRS Presentation Format . . . . . . . . . . . . . . . . . = 5 > 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . = 6 > 5.1. Restricted Application . . . . . . . . . . . . . . . . . = 6 > 5.2. Controlled Application . . . . . . . . . . . . . . . . . = 7 > 5.3. Opened Application . . . . . . . . . . . . . . . . . . . = 8 > 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . = 9 > 7. Security Considerations . . . . . . . . . . . . . . . . . . . = 9 > 7.1. DNS misconfiguration . . . . . . . . . . . . . . . . . . = 9 > 7.2. DNS Security . . . . . . . . . . . . . . . . . . . . . . = 10 > 7.3. Application Security . . . . . . . . . . . . . . . . . . = 10 > 8. References . . . . . . . . . . . . . . . . . . . . . . . . . = 10 > 8.1. Normative References . . . . . . . . . . . . . . . . . . = 11 > 8.2. Informative References . . . . . . . . . . . . . . . . . = 11 > Author's Address . . . . . . . . . . . . . . . . . . . . . . . . = 11 >=20 > 1. Introduction >=20 > Illegitimate access to professional restricted applications over > Internet is a permanent threat for organizations and their staff. > Different methods can be used to impersonate a user access, and in > some cases an organization also wants to better prevent its own = staff > to access a third-party application from a network which is not = under > its control. On the contrary, an organization maybe wants to allow > roaming then its users can access from different known places. >=20 > The Client Roaming Control (CRC) DNS Resource Record (RR) acts as a > White-List and informs a compatible application from which networks > its users are allowed to connect, be it a limited list of networks = or > broadly without any restriction. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Adell Expires 7 October 2022 [Page = 2] >=20 > Internet-Draft Client Roaming Control April = 2022 >=20 >=20 > At the application level, the identification of the user's > organization domain can be based on an information carried during = the > authentication process, or a lookup on an information already known > by the application. In both cases this information lets the > application relate the user to its organization unequivocally. > Finally, the corresponding user's domain DNS will be requested with > the application's FQDN and port, and the application will know > whether an authorization is expected or not. Some examples will be > given in this document. >=20 > The applications implementing this authorization control let the > client organizations know this feature is available by using the > Client Roaming Support (CRS) RR. The data associated with this > record indicates if the client's organization expected support of = the > CRC is mandatory, optional, or ignored. This information stored in > the CRS can be confirmed at the application level by a redundant > data. The way the application handles the authorization mechanism, > by consulting the associated CRS record or not, is left to the > implementor. >=20 > Although this mechanism is designed for improving the security > between different organizations, there is no objection to use it for > a same organization playing both roles of client and application , = as > an alternative or additional layer to a solution already in place, > such as a firewall for example. >=20 > 2. Conventions Used in This Document >=20 > This specification uses definitions from Domain Name System > [RFC1035], and readers unfamiliar with it can also check DNS > Terminology [RFC8499]. The syntax specification uses the Augmented > Backus-Naur Form (ABNF) notation as specified in [RFC5234], with = some > expressions being defined in "Uniform Resource Identifier (URI): > Generic Syntax" [RFC3986] and "IP Version 6 Addressing Architecture" > [RFC4291]. >=20 > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and > "OPTIONAL" in this document are to be interpreted as described in = BCP > 14 [RFC2119] [RFC8174] when, and only when, they appear in all > capitals, as shown here. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Adell Expires 7 October 2022 [Page = 3] >=20 > Internet-Draft Client Roaming Control April = 2022 >=20 >=20 > 3. The CRC Resource Record >=20 > The CRC RR purpose is to provide a list of IP ranges authorized to > use a particular application. Each RR contains a list of either = IPv4 > or IPv6 network address ranges. These ranges MUST follow the CIDR > notation. A single CRC RR MAY contain ranges for different IP > versions, but in the case of many ranges this can be difficult to > read or maintain, so dedicating a record to each IP version or not = is > left to the administrator. Multiple RRs MAY be defined for a given > IP version. >=20 > 3.1. RR name field >=20 > The CRC RR name field is composed of the third-party application > domain, its port, followed by the fully qualified name inherent in > this zone. These three components are separated by the underscore > character. >=20 > 3.2. CRC RDATA Wire Format >=20 > The CRC RDATA wire format is encoded as follows: >=20 > +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ > / CRC / > / / > +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ >=20 > The CRC field contains a list of either IPv4 or IPv6 ranges = separated > by the comma character. >=20 > 3.3. CRC Presentation Format >=20 > The presentation format of the CRC record is: >=20 > CRC (ip4netlist [,ip6netlist]) / ([ip4netlist,] ip6netlist) >=20 > ip4netlist =3D ip4net *(,ip4net) >=20 > ip4net =3D IPv4address "/" ip4range >=20 > ip4range =3D DIGIT / "1" DIGIT / "2" DIGIT / "3" DIGIT %x30-32 >=20 > ip6netlist =3D ip6net *(,ip6net) >=20 > ip6net =3D (ipv6-address "/" prefix-length) >=20 >=20 >=20 >=20 >=20 >=20 > Adell Expires 7 October 2022 [Page = 4] >=20 > Internet-Draft Client Roaming Control April = 2022 >=20 >=20 > 4. The CRS Resource Record >=20 > The CRS RR indicates which control is done on the client > organizations, and thus which ones are authorized. A requirement > field is used for this purpose, it has one of the following values > meaning when the checking is performed : >=20 > * "N" : Never, all organizations are authorized >=20 > * "A" : Always, only organizations with a CRC are authorized >=20 > * "O" : Optional, any organization CRC is honored, other > organizations are authorized >=20 > In addition to this value, an optional list of ports can be given. > Indeed, multiple applications can be hosted on different ports under > the same domain name, and an equivalent support was described for = the > CRC RR. In case of different requirement values, it is RECOMMENDED > to have one dedicated RR for each although one single RR with all = the > information is supported. One particular port MUST NOT appear in > more than one RR. When no port is mentioned, only one RR MAY be > declared and its requirement value covers all applications for this > domain name. >=20 > In the absence of such record, no roaming control is to be expected > by the client, any of its CRC RRs will be ignored. It is equivalent > to a CRS requirement value indicating no control is performed. >=20 > 4.1. CRS RDATA Wire Format >=20 > The CRS RDATA wire format is encoded as follows: >=20 > +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ > / CRS / > / / > +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ >=20 > The CRS field contains a list of requirements followed by their > respective optional ports. >=20 > 4.2. CRS Presentation Format >=20 > The presentation format of the CRS record is: >=20 > CRS (single-rule / multiple-rules) >=20 > single-rule =3D "R=3D" ("N" / "A" / "O") *(,port) >=20 >=20 >=20 >=20 > Adell Expires 7 October 2022 [Page = 5] >=20 > Internet-Draft Client Roaming Control April = 2022 >=20 >=20 > multiple-rules =3D unit-rule 1*2(;unit-rule) >=20 > unit-rule =3D "R=3D" ("N" / "A" / "O") 1*(,port) >=20 > port =3D [1-9] *([DIGIT]) >=20 > 5. Examples >=20 > The following examples show some typical uses expected from this > documentation. Particularly, the intended behaviors for different > CRC and CRS values are explained, while the user identification is > done directly through carried data or a deduction process. >=20 > 5.1. Restricted Application >=20 > In this example, an application is only opened to organizations > publishing their respective allowed networks. The requirement value > of the CRS record equals "A", and any organization with an empty or > missing CRC for this application will be denied access. >=20 > The ftp.foo.com domain is dedicated to hosting an FTP application, > which extracts the client's domain from the username used during the > authentication process. This information is then used for = requesting > the client CRC record and finally comparing its content with the > client's IP. The client organization bar.com allows its users from > its own network 195.13.35.0/24 and from a cloud service located at > 91.220.43.0/24. A second organization baz.com has no CRC record and > its users are rejected. >=20 > Application FQDN : ftp.foo.com > Application CRS record : CRS R=3DA,21 >=20 > Client FQDN : bar.com > Client organization CRC record : CRC > ftp.foo.com_21_bar.com,195.13.35.0/24,91.220.43.0/24 >=20 > Client FQDN : baz.com > No client organization CRC record >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Adell Expires 7 October 2022 [Page = 6] >=20 > Internet-Draft Client Roaming Control April = 2022 >=20 >=20 > Client DNS Client FTP Server FTP >=20 > FTP USER me@bar.com > -----------------------------> > ... > FTP PASS ******** > -----------------------------> > Query : CRC ftp.foo.com_21_bar.com > <------------------------------------ > Answer : CRC = ftp.foo.com_21_bar.com,195.13.35.0/24,91.220.43.0/24 > ------------------------------------> > FTP 230 > <------------------------------ >=20 >=20 > FTP USER me@baz.com > -----------------------------> > ... > FTP PASS ******** > -----------------------------> > Query : CRC ftp.foo.com_21_baz.com > <------------------------------------ > Answer : No such name (3) > ------------------------------------> > FTP 430 > <------------------------------ >=20 > 5.2. Controlled Application >=20 > The foo.com domain hosts a Web application on port 443 using client > certificates for authenticating its users. The application extracts > the client domains from the certificates, which are used to retrieve > their CRC records. Users from the bar.com organization are allowed > only if they connect from an authorized network listed in the CRC > record, while users from baz.com are always granted access since = this > one has no CRC declared. >=20 > Application FQDN : foo.com > Application CRS record : CRS R=3DA,443 >=20 > Client FQDN : bar.com > Client organization CRC record : CRC > ftp.foo.com_443_bar.com,195.13.35.0/24,91.220.43.0/24 >=20 > Client FQDN : baz.com > No client organization CRC record >=20 >=20 >=20 >=20 >=20 > Adell Expires 7 October 2022 [Page = 7] >=20 > Internet-Draft Client Roaming Control April = 2022 >=20 >=20 > Client DNS Client browser Web application >=20 >=20 > ..... > Client certificate me@bar.com > -----------------------------------> > Query : CRC foo.com_443_bar.com > <------------------------------------------ > Answer : CRC = foo.com_443_bar.com,195.13.35.0/24,91.220.43.0/24 > ------------------------------------------> > ..... > 200 OK > <----------------------------------- >=20 >=20 > ..... > Client certificate me@baz.com > -----------------------------------> > Query : CRC foo.com_443_baz.com > <------------------------------------------ > Answer : No such name (3) > ------------------------------------------> > ..... > 200 OK > <----------------------------------- >=20 > 5.3. Opened Application >=20 > A company is testing the CRC and CRS behaviors before opening a new > service to its customers. Its first test described below consists = in > configuring both sides to be completely opened, likely before > hardening the CRS, then the CRC, and testing again. >=20 > The application.foo.com domain hosts a Web application on port 443 > where users are logged in by sending a numerical identifier and a > password. The application uses a dictionary data type to identify > the user's domain. The client.foo.com domain is temporarily using 2 > CRC records indicating a free access from anywhere. >=20 > Application FQDN : application.foo.com > Application CRS record : CRS R=3DN,443 >=20 > Client FQDN : client.foo.com > Client organization CRC records : CRC > application.foo.com_443_foo.com,0.0.0.0/24; CRC > application.foo.com_443_foo.com,fe80::/10 >=20 >=20 >=20 >=20 >=20 > Adell Expires 7 October 2022 [Page = 8] >=20 > Internet-Draft Client Roaming Control April = 2022 >=20 >=20 > Client DNS Client browser Web application >=20 >=20 > ..... > HTTP POST 123456/****** > -----------------------------------> > 200 OK > <----------------------------------- >=20 > 6. IANA Considerations >=20 > According to Guidelines for Writing an IANA Considerations Section = in > RFCs [RFC8126] it is asked to IANA to add into the Resource Record > (RR) TYPEs registry located at https://www.iana.org/assignments/dns- > parameters/dns-parameters.xhtml#dns-parameters-4 the two entries CRC > and CRS. >=20 > +------+-------+------------------------+-----------+ > | TYPE | Value | Description | Reference | > +------+-------+------------------------+-----------+ > | CRC | TBD1 | Client Roaming Control | this RFC | > +------+-------+------------------------+-----------+ > | CRS | TBD2 | Client Roaming Support | this RFC | > +------+-------+------------------------+-----------+ >=20 > Table 1 >=20 > 7. Security Considerations >=20 > This section is meant to inform developers and users of the security > implications of the CRC/CRS mechanism described by this document. > While the CRS RR mostly plays an informative role, the CRC RR > delivers important data which requires attention from the developers > and administrators. Some particular points are discussed here. >=20 > 7.1. DNS misconfiguration >=20 > Any DNS CRS misconfiguration such as multiple records with different > requirement values but with the same port value can get a client > confused. In this case the client does not know without testing the > actual configuration, if its organization is protected against > roaming, and contacting the application administrator to fix the > situation is a possibility. >=20 > While CRC misconfigurations are more or less leading to serious > security problems, administrators need to pay attention when dealing > with multiple networks or records. Particularly, multiple records > for the same network range or overlapping networks should be = avoided. >=20 >=20 >=20 > Adell Expires 7 October 2022 [Page = 9] >=20 > Internet-Draft Client Roaming Control April = 2022 >=20 >=20 > 7.2. DNS Security >=20 > Client and application administrators need to pay as much attention > as they usually do when dealing with DNS management. As the CRC > records are supposed to be requested during an application > authentication process, reflection attacks could be built to target = a > client organization, even one not hosting any CRC record at all. > In a general manner, administrators may consider an adequate TTL > setting to not overload client organizations, enable TCP as the > preferred transport, or rely on DNSSEC to warrant data authenticity > and integrity. >=20 > 7.3. Application Security >=20 > The following points are of concern to developers: >=20 > Encryption: > Whenever possible, the application protocol should be encrypted to > prevent eavesdropping and man-in-the-middle attacks. It is a > critical point for applications maintaining a user session with > anything like a token or cookie, as it can lead to session hijacking > as discussed below. >=20 > Timing attack: > All authentication systems need to be careful to not deliver any > information derived from the computing time to a denied user, even > the ones involving multiple factors or steps like the one described > in this document. In particular, the order in which these steps are > executed and their respective implementations, need to defeat > statistical hypotheses. >=20 > Intermediate systems: > Some applications are not directly Internet facing and cannot access > to the real client's IP address without involving a mechanism to > forward this IP at the application layer. For example with HTTP, = the > common practice based on the non-standard X-Forwarded-For header, or > its alternative standard Forwarded [RFC7239], are playing this role. > Such practice requires a correct sanitizing of user data to avoid > false injected IPs. >=20 > Session hijacking: > A well-known attack called Session Hijacking is not meant to be > defeated by this document alone. Application developers must ensure > that any receveid session token, such as an HTTP Cookie, belongs to > the same IP address than the one which started this session. >=20 > 8. References >=20 >=20 >=20 >=20 > Adell Expires 7 October 2022 [Page = 10] >=20 > Internet-Draft Client Roaming Control April = 2022 >=20 >=20 > 8.1. Normative References >=20 > [RFC1035] Mockapetris, P., "Domain names - implementation and > specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, > November 1987, . >=20 > [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate > Requirement Levels", BCP 14, RFC 2119, > DOI 10.17487/RFC2119, March 1997, > . >=20 > [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform > Resource Identifier (URI): Generic Syntax", STD 66, > RFC 3986, DOI 10.17487/RFC3986, January 2005, > . >=20 > [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing > Architecture", RFC 4291, DOI 10.17487/RFC4291, February > 2006, . >=20 > [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for = Syntax > Specifications: ABNF", STD 68, RFC 5234, > DOI 10.17487/RFC5234, January 2008, > . >=20 > [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC > 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, > May 2017, . >=20 > 8.2. Informative References >=20 > [RFC7239] Petersson, A. and M. Nilsson, "Forwarded HTTP Extension", > RFC 7239, DOI 10.17487/RFC7239, June 2014, > . >=20 > [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS > Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, > January 2019, . >=20 > Author's Address >=20 > Eugene Adell > Email: eugene.adell@gmail.com >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Adell Expires 7 October 2022 [Page = 11] >=20 >=20 > RFC 6895 : > A. Submission Date:2002/04/05 > B.1 Submission Type: [X] New RRTYPE [ ] Modification to RRTYPE > B.2 Kind of RR: [X] Data RR [ ] Meta-RR > C. Contact Information for submitter : > Name: Eugene Adell Email Address: = eugene.adell@gmail.com > International telephone number: +33699056914 > Other contact handles: > D. Motivation for the new RRTYPE application. > Introduce a couple of RR types working together in order to better > secure remote access to partner applications > E. Description of the proposed RR type. > CRC contains a limited list of authorized networks for a particular > application > F. What existing RRTYPE or RRTYPEs come closest to filling that need > and why are they unsatisfactory? > TXT RRTYPE allows the storage of any text data but in practice is > usually associated with more or less fixed name or data which is not > what is needed here. A dedicated RRTYPE is easier to identify and > manage by a security team other than the usual DNS operator team. > G. What mnemonic is requested for the new RRTYPE (optional)? > CRC > H. Does the requested RRTYPE make use of any existing IANA registry or > require the creation of a new IANA subregistry in DNS Parameters? > It uses the existing Resource Record (RR) TYPEs registry > I. Does the proposal require/expect any changes in DNS > servers/resolvers that prevent the new type from being processed as an > unknown RRTYPE (see [RFC3597])? > No > J. Comments: > None >=20 >=20 > A. Submission Date:2002/04/05 > B.1 Submission Type: [X] New RRTYPE [ ] Modification to RRTYPE > B.2 Kind of RR: [X] Data RR [ ] Meta-RR > C. Contact Information for submitter : > Name: Eugene Adell Email Address: = eugene.adell@gmail.com > International telephone number: +33699056914 > Other contact handles: > D. Motivation for the new RRTYPE application. > Introduce a couple of RR types working together in order to better > secure remote access to partner applications > E. Description of the proposed RR type. > CRS contains a requirement value and a list of ports indicating > what kind of authorization check is done during the application > authentication process > F. What existing RRTYPE or RRTYPEs come closest to filling that need > and why are they unsatisfactory? > TXT RRTYPE allows the storage of any text data but in practice is > usually associated with more or less fixed name or data which is not > what is needed here. A dedicated RRTYPE is easier to identify and > manage by a security team other than the usual DNS operator team. > G. What mnemonic is requested for the new RRTYPE (optional)? > CRS > H. Does the requested RRTYPE make use of any existing IANA registry or > require the creation of a new IANA subregistry in DNS Parameters? > It uses the existing Resource Record (RR) TYPEs registry > I. Does the proposal require/expect any changes in DNS > servers/resolvers that prevent the new type from being processed as an > unknown RRTYPE (see [RFC3597])? > No > J. Comments: > None > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop --=20 Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Mon Apr 11 06:01:09 2022 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 CA2193A0E7A for ; Mon, 11 Apr 2022 06:00:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.107 X-Spam-Level: X-Spam-Status: No, score=-2.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] 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 9SDf-3MlQeSU for ; Mon, 11 Apr 2022 06:00:53 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::85]) (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 460083A0E17 for ; Mon, 11 Apr 2022 06:00:53 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4KcTVp0Tk5z38F; Mon, 11 Apr 2022 15:00:50 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1649682050; bh=e1JzFhO45eXuwi0qh9Vh0eo9Y3FhEjhkipUUL+XXyNc=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=mAnbfG0cC3SvGMBzdJnjq/Uofw/oPRlE145YnfjGsP/+QkAjVtClXKcNU7vIvoetS pxx1ZFVl6m8CMjiC2bmxlbWxmHfgj8aPAtOYL63Pn4ZUBggX4e8Tt/XPKvs5SUtUz/ /SyCgu1X69HMmgqZ5gcV1K6dRbA8QwVP1j47t8+Q= 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 MEYFV11Lkt73; Mon, 11 Apr 2022 15:00:48 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 11 Apr 2022 15:00:48 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 8941D2DF2A3; Mon, 11 Apr 2022 09:00:47 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 85A772DF2A2; Mon, 11 Apr 2022 09:00:47 -0400 (EDT) Date: Mon, 11 Apr 2022 09:00:47 -0400 (EDT) From: Paul Wouters To: zhangcuiling cc: dnsop In-Reply-To: <202204111111585901567@cnnic.cn> Message-ID: <4af2f29f-b2ac-b2e7-e977-793461adfda5@nohats.ca> References: <202204111111585901567@cnnic.cn> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [DNSOP] A new draft on SM2 digital signature algorithm for DNSSEC X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2022 13:01:06 -0000 On Mon, 11 Apr 2022, zhangcuiling wrote: > And the main purpose is to improve the diversity of DNSSEC algorithms, and to make it convenient for people who want to use SM2 > digital signature algorithm as an alternative for DNSSEC. We actually want to prevent as much diversity as we can, to avoid creating more new long tails of deployment of algorithms. So a new algorithm should really offer something the others do not. Also having a number of ECC based algorithms would likely mean if one ends up broken, all of them end up broken. So based on: Due to the similarity between SM2 and ECDSA with curve P-256, some of the material in this document is copied liberally from RFC 6605 [RFC6605]. I don't see a strong reason to adopt another ECC type of algorithm. Additionally, in this case SM2/SM3 seems to be ISO standards that are not freely available, so these are additionally problematic. Paul From nobody Mon Apr 11 06:01:45 2022 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 86A7C3A1109 for ; Mon, 11 Apr 2022 06:01:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 oumRm5QIyGKR for ; Mon, 11 Apr 2022 06:01:30 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietfa.amsl.com (Postfix) with SMTP id 765163A1047 for ; Mon, 11 Apr 2022 06:01:20 -0700 (PDT) Received: (qmail 32311 invoked from network); 11 Apr 2022 12:57:08 -0000 Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 11 Apr 2022 12:57:08 -0000 Message-ID: <872eeab2-636d-05c9-8138-c5a29ae495f8@necom830.hpcl.titech.ac.jp> Date: Mon, 11 Apr 2022 22:01:16 +0900 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Content-Language: en-US To: dnsop@ietf.org References: <57f1c37b-497c-e1a0-329c-4b9c8b7e197b@necom830.hpcl.titech.ac.jp> <9732682e-78e7-f6bf-84fc-685de22d5e12@necom830.hpcl.titech.ac.jp> <350d8ab8-0477-b656-8b08-56f7561a7fda@necom830.hpcl.titech.ac.jp> <0e2dffab-6afc-b1b6-9028-175f89f0d29e@necom830.hpcl.titech.ac.jp> <88F7F567-F605-4F0D-9292-C083465E6678@icann.org> From: Masataka Ohta In-Reply-To: <88F7F567-F605-4F0D-9292-C083465E6678@icann.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] [Ext] DNSSEC as a Best Current Practice X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2022 13:01:42 -0000 Paul Hoffman wrote: > I see a very strong consensus in this thread against the proposals > from Ohta-san, I can't see any as discussion is still ongoing. Masataka Ohta From nobody Mon Apr 11 06:11:19 2022 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 8AC823A0FB0 for ; Mon, 11 Apr 2022 06:11:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 Yan4GEghPFpf for ; Mon, 11 Apr 2022 06:11:15 -0700 (PDT) Received: from ix1.dns-oarc.net (ix1.dns-oarc.net [IPv6:2620:ff:c000::198]) (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 DE07D3A0F0E for ; Mon, 11 Apr 2022 06:11:15 -0700 (PDT) Received: from [172.17.0.4] (78-69-122-246-no54.tbcn.telia.com [78.69.122.246]) (authenticated bits=0) by ix1.dns-oarc.net (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id 23BDBA5q026925 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Mon, 11 Apr 2022 13:11:14 GMT Message-ID: <81cca2d9-cdc8-fe00-6ea6-07787d6fb57f@dns-oarc.net> Date: Mon, 11 Apr 2022 15:11:09 +0200 MIME-Version: 1.0 User-Agent: Mutt Content-Language: en-US To: dnsop@ietf.org References: <57f1c37b-497c-e1a0-329c-4b9c8b7e197b@necom830.hpcl.titech.ac.jp> <9732682e-78e7-f6bf-84fc-685de22d5e12@necom830.hpcl.titech.ac.jp> <350d8ab8-0477-b656-8b08-56f7561a7fda@necom830.hpcl.titech.ac.jp> <0e2dffab-6afc-b1b6-9028-175f89f0d29e@necom830.hpcl.titech.ac.jp> <88F7F567-F605-4F0D-9292-C083465E6678@icann.org> <872eeab2-636d-05c9-8138-c5a29ae495f8@necom830.hpcl.titech.ac.jp> From: =?UTF-8?Q?Jerry_Lundstr=c3=b6m?= In-Reply-To: <872eeab2-636d-05c9-8138-c5a29ae495f8@necom830.hpcl.titech.ac.jp> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [DNSOP] [Ext] DNSSEC as a Best Current Practice X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2022 13:11:18 -0000 I'm against the proposals from Ohta-san. /Jerry On 4/11/22 15:01, Masataka Ohta wrote: > Paul Hoffman wrote: > >> I see a very strong consensus in this thread against the proposals >> from Ohta-san, > > I can't see any as discussion is still ongoing. > >                             Masataka Ohta > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop From nobody Mon Apr 11 06:19:49 2022 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 EEA413A10F7 for ; Mon, 11 Apr 2022 06:19:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 sWOSXhUNDlwJ for ; Mon, 11 Apr 2022 06:19:43 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietfa.amsl.com (Postfix) with SMTP id BC0AE3A10DC for ; Mon, 11 Apr 2022 06:19:42 -0700 (PDT) Received: (qmail 32440 invoked from network); 11 Apr 2022 13:15:30 -0000 Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 11 Apr 2022 13:15:30 -0000 Message-ID: Date: Mon, 11 Apr 2022 22:19:38 +0900 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Content-Language: en-US To: Paul Wouters , "dnsop@ietf.org WG" References: <57f1c37b-497c-e1a0-329c-4b9c8b7e197b@necom830.hpcl.titech.ac.jp> <9732682e-78e7-f6bf-84fc-685de22d5e12@necom830.hpcl.titech.ac.jp> <350d8ab8-0477-b656-8b08-56f7561a7fda@necom830.hpcl.titech.ac.jp> <0e2dffab-6afc-b1b6-9028-175f89f0d29e@necom830.hpcl.titech.ac.jp> From: Masataka Ohta In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] DNSSEC as a Best Current Practice X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2022 13:19:48 -0000 Paul Wouters wrote: >> First, "CA" is terminology not specific to WebPKI, whatever it >> means, but PKI in general including DNS. That is, a DNSSEC TLD is a >> CA. > This is incorrect. First, thank you very much for an evidence that discussion is still continuing. Anyway, https://en.wikipedia.org/wiki/Public_key_infrastructure In cryptography, a PKI is an arrangement that binds public keys with respective identities of entities (like people and organizations). The binding is established through a process of registration and issuance of certificates at and by a certificate authority (CA). Do you still insist that CA is terminology specific to WebPKI not PKI in general? > In your favourite > terms, diginotar as DNSSEC entity would have only been able to mess > up .nl and not any other TLD, The fact is that diginotar actually supported government PKI of NL, which is why the problem is so serious. As for DNSSEC, we can be sure that national TLDs are not so secure. > You keep conflating operational security with protocol security, and > insisting protocol security is not needed because operational > security is always the weaker link. Your previous statement: : At the TLD level : and higher, this involves HSMs and physical access restrictions : using a "four eyes minimum" approach. is an evidence that operational security is required because DNSSEC is not secure merely by protocol security. I don't deny DNSSEC has some protocol security, but the problem is that it is not complete and useless without operational security. > But you are not offering any alternative ("larger plaintext cookies" > is not a security protocol) Cookies and DNSSEC, subject to active MitM attacks, are equally secure. > So please tell me why you use TLS at all? Why not force your browser > into only using port 80? You can also use extra long HTTP header > cookies. With compromised intermediate CAs and ISPs, TLS and plain http with long enough cookies are equally secure against active MitM attacks. The difference is that, unlike cookies, TLS is safe against passive MitM attacks of packet snooping. So? Masataka Ohta From nobody Mon Apr 11 07:09:29 2022 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 AEC4F3A1777 for ; Mon, 11 Apr 2022 07:09:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 813oCEgNXEc8 for ; Mon, 11 Apr 2022 07:09:24 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietfa.amsl.com (Postfix) with SMTP id BF7513A176E for ; Mon, 11 Apr 2022 07:09:22 -0700 (PDT) Received: (qmail 32799 invoked from network); 11 Apr 2022 14:05:10 -0000 Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 11 Apr 2022 14:05:10 -0000 Message-ID: Date: Mon, 11 Apr 2022 23:09:18 +0900 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Content-Language: en-US To: Paul Wouters , "dnsop@ietf.org WG" References: <57f1c37b-497c-e1a0-329c-4b9c8b7e197b@necom830.hpcl.titech.ac.jp> <9732682e-78e7-f6bf-84fc-685de22d5e12@necom830.hpcl.titech.ac.jp> <350d8ab8-0477-b656-8b08-56f7561a7fda@necom830.hpcl.titech.ac.jp> <0e2dffab-6afc-b1b6-9028-175f89f0d29e@necom830.hpcl.titech.ac.jp> From: Masataka Ohta In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] DNSSEC as a Best Current Practice X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2022 14:09:27 -0000 Paul Wouters wrote: > In your > favourite terms, diginotar as DNSSEC entity would have only > been able to mess up .nl and not any other TLD, if it had been > a "DNSSEC CA" instead of a "webpki CA". The hierarchical space > offers better security than the flat webpki. I can't see any reason why you think the root zone is more secure than TLDs, especially because, as I wrote: : Third, all the CAs, including TLDs, pursuing commercial : success have very good appearance using such words as : "HSMs" or "four eyes minimum". That is, you can't : compare actual operational/physical strength from : their formal documents. and : A false sense of security that DNSSEC were : cryptographically secure motivates the operators : ignore DNSSEC operation rules, which are very : complicated and hard to follow, for relatively : strong physical security, which might be what : happened in diginotar. Masataka Ohta From nobody Mon Apr 11 07:33:20 2022 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 A98C33A184B for ; Mon, 11 Apr 2022 07:33:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.107 X-Spam-Level: X-Spam-Status: No, score=-7.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] 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 zeisg_sYT9Ho for ; Mon, 11 Apr 2022 07:33:12 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::85]) (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 9D0993A1855 for ; Mon, 11 Apr 2022 07:33:12 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4KcWYK2YcZzCWK; Mon, 11 Apr 2022 16:33:09 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1649687589; bh=mvtwyEX2wd0n0iXbDMymvCGtxRPycTDemMRJ7eHLwxM=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=aJHlnIHiOCSLXPEam1nFetdit4n+krnPF5zu3nRyKNJZiWUxLCWjKm2TAD+fTBHUC Ff4k2LJMwdviChgkOSWXFiu7gtU8KCxHA418x3xHZbXv9zijNZuS817z2E5r1ewDXb oIcdttqamnYS0TDk8AztnlK7DVdtXqKjSetBApLQ= 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 Vsce6txkIHcN; Mon, 11 Apr 2022 16:33:08 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 11 Apr 2022 16:33:08 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 84B742DF309; Mon, 11 Apr 2022 10:33:07 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 81FDB2DF308; Mon, 11 Apr 2022 10:33:07 -0400 (EDT) Date: Mon, 11 Apr 2022 10:33:07 -0400 (EDT) From: Paul Wouters To: Masataka Ohta cc: "dnsop@ietf.org WG" In-Reply-To: Message-ID: References: <57f1c37b-497c-e1a0-329c-4b9c8b7e197b@necom830.hpcl.titech.ac.jp> <9732682e-78e7-f6bf-84fc-685de22d5e12@necom830.hpcl.titech.ac.jp> <350d8ab8-0477-b656-8b08-56f7561a7fda@necom830.hpcl.titech.ac.jp> <0e2dffab-6afc-b1b6-9028-175f89f0d29e@necom830.hpcl.titech.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [DNSOP] DNSSEC as a Best Current Practice X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2022 14:33:19 -0000 On Mon, 11 Apr 2022, Masataka Ohta wrote: > I can't see any reason why you think the root zone is > more secure than TLDs, especially because, as I wrote: Because I am informed about their operational procedures and I contributed to the technical design as one of the for the DNS Root Zone Key-Signing-Key of the Root Zone Rollover advisory group. I was also responsible for the design and implementation of a large TLD fully implementation redundant DNSSEC signer solution. I talked to a lot of TLD operators at ICANN during my term as the IETF Liason to the ICANN Technical Expert Group. > : Third, all the CAs, including TLDs, pursuing commercial > : success have very good appearance using such words as > : "HSMs" or "four eyes minimum". That is, you can't > : compare actual operational/physical strength from > : their formal documents. This is an anecdote, that a logical reasoned argument. > : A false sense of security that DNSSEC were > : cryptographically secure This remains factually incorrect, no matter how many times you quote yourself. > : motivates the operators > : ignore DNSSEC operation rules, which are very > : complicated and hard to follow, for relatively > : strong physical security, which might be what > : happened in diginotar. This is hearsay combined with personal opinion that is unsubstantiated by facts. As for your other mail to list, it seems we do not in fact have an ongoing discussion. You keep repeating and quoting yourself as evidence while people keep telling you they disagree with your quotes. But to make it abundantly clear this is not a discussion, I shall refrain from further messages so you cannot miscatageorize my correspondence as a "discussion of peers". Paul From nobody Mon Apr 11 07:36:46 2022 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 7E8403A0112 for ; Mon, 11 Apr 2022 07:36:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.721 X-Spam-Level: X-Spam-Status: No, score=-1.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.186, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] 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 9N6rf-KSJhgD for ; Mon, 11 Apr 2022 07:36:40 -0700 (PDT) Received: from shaun.rfc1035.com (smtp.v6.rfc1035.com [IPv6:2001:4b10:100:7::25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED46E3A00E5 for ; Mon, 11 Apr 2022 07:36:39 -0700 (PDT) Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shaun.rfc1035.com (Postfix) with ESMTPSA id CE79F2421481; Mon, 11 Apr 2022 14:36:34 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.7\)) From: Jim Reid In-Reply-To: <872eeab2-636d-05c9-8138-c5a29ae495f8@necom830.hpcl.titech.ac.jp> Date: Mon, 11 Apr 2022 15:36:34 +0100 Cc: dnsop@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <78F63C60-9762-4FF6-A933-09FFD9195F7B@rfc1035.com> References: <57f1c37b-497c-e1a0-329c-4b9c8b7e197b@necom830.hpcl.titech.ac.jp> <9732682e-78e7-f6bf-84fc-685de22d5e12@necom830.hpcl.titech.ac.jp> <350d8ab8-0477-b656-8b08-56f7561a7fda@necom830.hpcl.titech.ac.jp> <0e2dffab-6afc-b1b6-9028-175f89f0d29e@necom830.hpcl.titech.ac.jp> <88F7F567-F605-4F0D-9292-C083465E6678@icann.org> <872eeab2-636d-05c9-8138-c5a29ae495f8@necom830.hpcl.titech.ac.jp> To: Masataka Ohta X-Mailer: Apple Mail (2.3445.9.7) Archived-At: Subject: Re: [DNSOP] [Ext] DNSSEC as a Best Current Practice X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2022 14:36:45 -0000 > On 11 Apr 2022, at 14:01, Masataka Ohta = wrote: >=20 > I can't see any as discussion is still ongoing. There is no discussion, just you arguing with yourself. Please stop. From nobody Mon Apr 11 08:38:03 2022 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 8C27D3A09B7; Mon, 11 Apr 2022 08:38:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.109 X-Spam-Level: X-Spam-Status: No, score=-2.109 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sandelman.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 dudD-RgWMD5l; Mon, 11 Apr 2022 08:37:56 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4828D3A0FE2; Mon, 11 Apr 2022 08:37:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 83D4038C3C; Mon, 11 Apr 2022 11:49:21 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Sw8hvGqwY5yR; Mon, 11 Apr 2022 11:49:20 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 1F1CE38C27; Mon, 11 Apr 2022 11:49:20 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sandelman.ca; s=mail; t=1649692160; bh=C6JYezNT1qyyXdl/X+70PXPdxEUeP42AY+HRTQIzIII=; h=From:To:Subject:Date:From; b=8F0TMyivGtY5izxXixK+ZgsMrGp/FXtRf+W1x/zAAV+SIk5orSiNcgJ4FPIEYag8C teIlsDjI6q035vFYqwbdAexh1jkogWpEurSQy/H8c8uXnVlG67aisnTUHPUI9AFM4p 6Lbud1rykblstkyqm+9epnyNRdVRotS4qHov+aY/TucwKpIr5LMJ/nZeJs6wzLH0il g2znib1okeSb0lnQZmMON5nvryCqV/GoxK57WSV/5DvIaT8kgIc/93vPFcJSjMgJaZ 50NrBYm6f8hyi7TmvJEfVKWRGonqW8PId3Q7Qhgfn7WuylwBNp6x/U+0vvPRBTlCEg q1KANyTXE0vZA== Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 60D29A7; Mon, 11 Apr 2022 11:37:49 -0400 (EDT) From: Michael Richardson To: dnsop@ietf.org, mud@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 27.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [DNSOP] looking for reference for reverse maps do not work X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2022 15:38:01 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, in reviews of https://www.ietf.org/archive/id/draft-ietf-opsawg-mud-iot-dns-considerati= ons-04.html I was asked to expand upon why the reverse map can not be intelligently use= d=20=20 for MUD ACLs. (section 3, XXX stuff) (MUD controllers, upon being presented with ACLs made up of names need to do forward lookups of the names and build ACLs based upon the IP addresses.) There are two aspects of this: 1) even in an ideal situation, it takes too long on the first packet to extract a name from an IP address. Yes, that could be aggresively cac= hed. 2) forward:reverse maps are N:M mappings, often with unidirectional parts= , and often broken or not delegated. =20=20=20=20=20 Further, there is no authorization of the mappings, so an attacker who wants to be able to reach IP address 2001:db8::abcd, can insert a reverse name of their choice, including updates.example.com, which is permitted by the MUD ACL. While I can write the above paragraph, I don't feel that it's detailed enou= gh for what is needed, and I feel that we (the IETF) must have documented the security issues with reverse/forward mismatched at least twice over the past 40 years. I'm looking for a good well reviewed reference to use rather than repeating this again. =2D-=20 Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQFKBAEBCgA0FiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmJUS00WHG1jcitpZXRm QHNhbmRlbG1hbi5jYQAKCRCAi3D73dDdZds5B/4mtGf3HeCwsNYMjd77ieEwJZR+ lffP/2xEfyj1VA9ou/a5hGssBKQQSob4zjOfLbW3iiTt9jexq0Qg/I/VsIpORUud o/fFOcKxdPjnMLSwuPyEJ47XY5XERovDYmiu9OUjyLeyfFdtzJcSqt649VUUrtnL rqQ6a0xXQlCx4sPfDtgygL1kwMGNBPWkRRlhUNFojB2HMpotrZuuzcOf839daaxV EED2m33gRxkfQx8KxDjytyTl+ZtmeXjX5rx7+IsHbw3bfF7KghY2kqtAwiD1RLvW nz0Ds+jtCD/D5EghwESYh3ZyijHsZY3edPJ0tFEQHkar9KBnVYhr7tJ8TMcc =I9iN -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Apr 11 08:45:53 2022 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 721FC3A112A; Mon, 11 Apr 2022 08:45:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=Oqveamdw; dkim=pass (1024-bit key) header.d=yitter.info header.b=ci2nyVW1 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 DhOnGaKn_Bzu; Mon, 11 Apr 2022 08:45:47 -0700 (PDT) Received: from mx5.yitter.info (mx5.yitter.info [159.203.31.152]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D372E3A1122; Mon, 11 Apr 2022 08:45:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx5.yitter.info (Postfix) with ESMTP id 92958BD5C5; Mon, 11 Apr 2022 15:45:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1649691943; bh=Nh43tYT1UxS2UWkzutCDJJRkJ6h0P2/en/DUkunrLuM=; h=From:Subject:Date:References:Cc:In-Reply-To:To:From; b=Oqveamdw7YqK0rpwlZWh7uZKQNGq+/DMZq41UANRw/1j8jnyxVugvSzPOucssuTSK 86rcxVL/Cew2dLX/gCszBe3Dqgo1/mKNes9lD9bu4OwgTCo9Sgq9Ua4l04luV2wzFx yl2qowdAiS0c2j0YlQt9dw7q89T/voesUAX4rxww= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx5.yitter.info ([127.0.0.1]) by localhost (mx5.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V4uScjukLMiG; Mon, 11 Apr 2022 15:45:41 +0000 (UTC) Content-Type: multipart/alternative; boundary=Apple-Mail-9F2151B5-34BA-4095-8D13-CFB6B0331CA6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1649691941; bh=Nh43tYT1UxS2UWkzutCDJJRkJ6h0P2/en/DUkunrLuM=; h=From:Subject:Date:References:Cc:In-Reply-To:To:From; b=ci2nyVW1Q9H79yuZV1pDNZotPInsXt9L3SpOOICFz0PDgaNcax8erlSH5nSgPmEsA N0ZMn69OdrFvaUCQgaLHSzhYaKa1K3UD3m5dsV+Lbg41iYKOMlPrvMuUixE37cX0gX MMU+5wukJPkHqiv4S2UNq/L92QgE9v8U/zhwgbYg= Content-Transfer-Encoding: 7bit From: Andrew Sullivan Mime-Version: 1.0 (1.0) Date: Mon, 11 Apr 2022 11:45:39 -0400 Message-Id: <92E310C3-B9FA-4C8D-AB9A-06E069086BE2@anvilwalrusden.com> References: <24231.1649691469@localhost> Cc: dnsop@ietf.org, mud@ietf.org In-Reply-To: <24231.1649691469@localhost> To: Michael Richardson Archived-At: Subject: Re: [DNSOP] looking for reference for reverse maps do not work X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2022 15:45:52 -0000 --Apple-Mail-9F2151B5-34BA-4095-8D13-CFB6B0331CA6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I tried to document this ages ago in https://datatracker.ietf.org/doc/draft-= ietf-dnsop-reverse-mapping-considerations/, and got so many contradictory ed= its (see the history) that the final version ended up saying =E2=80=9CA or m= aybe not-A, or maybe both, your choice,=E2=80=9D so the then-chairs decided t= he document wasn=E2=80=99t worth sending through publication.=20 A =E2=80=94=20 Andrew Sullivan=20 Please excuse my clumbsy thums > On Apr 11, 2022, at 11:38, Michael Richardson wrot= e: >=20 > =EF=BB=BF > Hi, in reviews of > https://www.ietf.org/archive/id/draft-ietf-opsawg-mud-iot-dns-considerati= ons-04.html >=20 > I was asked to expand upon why the reverse map can not be intelligently us= ed =20 > for MUD ACLs. (section 3, XXX stuff) > (MUD controllers, upon being presented with ACLs made up of > names need to do forward lookups of the names and build ACLs based upon th= e > IP addresses.) >=20 > There are two aspects of this: > 1) even in an ideal situation, it takes too long on the first packet to > extract a name from an IP address. Yes, that could be aggresively cac= hed. >=20 > 2) forward:reverse maps are N:M mappings, often with unidirectional parts= , and often > broken or not delegated. >=20 > Further, there is no authorization of the mappings, so an attacker who= > wants to be able to reach IP address 2001:db8::abcd, can insert a > reverse name of their choice, including updates.example.com, which is > permitted by the MUD ACL. >=20 > While I can write the above paragraph, I don't feel that it's detailed eno= ugh > for what is needed, and I feel that we (the IETF) must have documented the= > security issues with reverse/forward mismatched at least twice over the pa= st > 40 years. >=20 > I'm looking for a good well reviewed reference to use rather than repeatin= g > this again. >=20 > --=20 > Michael Richardson . o O ( IPv6 I=C3=B8T consult= ing ) > Sandelman Software Works Inc, Ottawa and Worldwide > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop --Apple-Mail-9F2151B5-34BA-4095-8D13-CFB6B0331CA6 Content-Type: multipart/related; type="text/html"; boundary=Apple-Mail-38BA4F31-A61D-4D87-98B4-5F097734D587 Content-Transfer-Encoding: 7bit --Apple-Mail-38BA4F31-A61D-4D87-98B4-5F097734D587 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable I tried to document this ages ago in <= a href=3D"https://datatracker.ietf.org/doc/draft-ietf-dnsop-reverse-mapping-= considerations/">https://datatracker.ietf.org/doc/draft-ietf-dnsop-reverse-m= apping-considerations/, and got so many contradictory edits (see the his= tory) that the final version ended up saying =E2=80=9CA or maybe not-A, or m= aybe both, your choice,=E2=80=9D so the then-chairs decided the document was= n=E2=80=99t worth sending through publication. 

A
=E2=80=94 
Andrew Sullivan 
Pl= ease excuse my clumbsy thums

On Apr 11, 2022, at 11:38, Michael Richardson <mcr+ietf@sandel= man.ca> wrote:

=EF=BB=BF
Hi, in reviews of
 https://www.ietf.org/archive/id/draft-ietf-opsawg-mud-iot-dns-consid= erations-04.html

I was asked to expand upon= why the reverse map can not be intelligently used  
fo= r MUD ACLs. (section 3, XXX stuff)
(MUD controllers, upon be= ing presented with ACLs made up of
names need to do forward l= ookups of the names and build ACLs based upon the
IP address= es.)

There are two aspects of this:<= br>  1) even in an ideal situation, it takes too long on the firs= t packet to
    extract a name from an I= P address.  Yes, that could be aggresively cached.

 2) forward:reverse maps are N:M mappings, often with uni= directional parts, and often
    broken= or not delegated.

    = ;Further, there is no authorization of the mappings, so an attacker who
    wants to be able to reach IP address 20= 01:db8::abcd, can insert a
    reverse n= ame of their choice, including updates.example.com, which is
    permitted by the MUD ACL.
<= br>While I can write the above paragraph, I don't feel that it's detai= led enough
for what is needed, and I feel that we (the IETF)= must have documented the
security issues with reverse/forwa= rd mismatched at least twice over the past
40 years.<= br>
I'm looking for a good well reviewed reference to u= se rather than repeating
this again.
=
--
Michael Richardson <mcr+IETF@sandelman.ca&g= t;   . o O ( IPv6 I=C3=B8T consulting )
 &nb= sp;        Sandelman Software Works I= nc, Ottawa and Worldwide
___________________________________= ____________
DNSOP mailing list
DNSOP@ietf.o= rg
https://www.ietf.org/mailman/listinfo/dnsop
= --Apple-Mail-38BA4F31-A61D-4D87-98B4-5F097734D587 Content-Type: application/octet-stream; name=signature.asc; x-apple-part-url=1D73C416-64BA-4E16-A239-6ACCB655700F Content-Disposition: attachment; filename=signature.asc Content-Transfer-Encoding: 7bit Content-Id: <1D73C416-64BA-4E16-A239-6ACCB655700F> -----BEGIN PGP SIGNATURE----- iQFKBAEBCgA0FiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmJUS00WHG1jcitpZXRm QHNhbmRlbG1hbi5jYQAKCRCAi3D73dDdZds5B/4mtGf3HeCwsNYMjd77ieEwJZR+ lffP/2xEfyj1VA9ou/a5hGssBKQQSob4zjOfLbW3iiTt9jexq0Qg/I/VsIpORUud o/fFOcKxdPjnMLSwuPyEJ47XY5XERovDYmiu9OUjyLeyfFdtzJcSqt649VUUrtnL rqQ6a0xXQlCx4sPfDtgygL1kwMGNBPWkRRlhUNFojB2HMpotrZuuzcOf839daaxV EED2m33gRxkfQx8KxDjytyTl+ZtmeXjX5rx7+IsHbw3bfF7KghY2kqtAwiD1RLvW nz0Ds+jtCD/D5EghwESYh3ZyijHsZY3edPJ0tFEQHkar9KBnVYhr7tJ8TMcc =I9iN -----END PGP SIGNATURE----- --Apple-Mail-38BA4F31-A61D-4D87-98B4-5F097734D587-- --Apple-Mail-9F2151B5-34BA-4095-8D13-CFB6B0331CA6-- From nobody Mon Apr 11 09:49:48 2022 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 001923A1606 for ; Mon, 11 Apr 2022 09:49:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 v3pf3qA5eHF6 for ; Mon, 11 Apr 2022 09:49:42 -0700 (PDT) Received: from mail.nic.cl (mail.nic.cl [200.1.123.8]) (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 795583A15F1 for ; Mon, 11 Apr 2022 09:49:42 -0700 (PDT) Received: from mail.nic.cl (localhost [127.0.0.1]) by mail.nic.cl (Postfix) with ESMTP id 7201F195D6346; Mon, 11 Apr 2022 12:49:39 -0400 (-04) Received: from pepino (unknown [IPv6:2800:150:126:65:4a3d:968a:4938:f63c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.nic.cl (Postfix) with ESMTPSA id 4C12D195D6328; Mon, 11 Apr 2022 12:49:39 -0400 (-04) Date: Mon, 11 Apr 2022 12:49:38 -0400 From: Hugo Salgado To: Dick Franks Cc: Joe Abley , IETF DNSOP WG , Paul Vixie Message-ID: <20220411164938.GA3640@pepino> References: <1f62c1db-b9d4-f7d5-fdfa-c298541875d4@redbarn.org> <7155233A-DB48-4CFF-95A2-F48E32088EDB@hopcount.ca> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="oyUTqETQ0mS9luUI" Content-Disposition: inline In-Reply-To: X-Virus-Scanned: ClamAV using ClamSMTP on Mon Apr 11 12:49:39 2022 -0400 (-04) (mail.nic.cl) Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-rrserial-01.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2022 16:49:47 -0000 --oyUTqETQ0mS9luUI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 21:24 07/04, Dick Franks wrote: > On Thu, 7 Apr 2022 at 19:44, Joe Abley wrote: > > > > On Apr 7, 2022, at 21:10, Paul Vixie wrote: > > > > > but it seems to me you'd be better off with a zero-length option call= ed SERIAL which if set in the query causes the SOA of the answer's zone to = be added to the authority section (similar to an RFC 2308 negative proof) a= nd which option would only be echoed in the answer's OPT if the option was = supported. you'd want to specify that the SOA in this case is not optional = and that its truncation would cause the TC bit to be set. > > > > That sounds like a lovely and clean way to do this. I like it. > > >=20 > This is an excellent idea, requiring trivial client-side support. >=20 > PV did not say so, but I would expect the SOA's RRSIG to be included > in the response. >=20 The idea of having the complete SOA + RRSIG was proposed before[1] and were discussed its disadvantages regarding size increase[2], query amplification[3], authority/additional epistemological grief[4][5] with changes in processing[6]. I personally believe that the path of including the full SOA is dangerously close to multi-qtype[7][8], which has historically failed for various reasons. Finally, the full SOA prevents us from going down the path of using a zone versioning other than SOA serial, which allows other implementations to indicate useful data, as we discussed last week[9]. It is our understanding that the complete SOA path was rejected by the group, and that the path through the EDNS extension that also allows other types of versioning data would have greater consensus. Thanks, Hugo [1]: https://mailarchive.ietf.org/arch/msg/dnsop/JMMKO7Q6WfFq25pqMQ5Yjsklywc [2]: https://mailarchive.ietf.org/arch/msg/dnsop/Oy6DeGp9xiGenV8IsYy3faQbn1A [3]: https://mailarchive.ietf.org/arch/msg/dnsop/kGTyENBGDnNwR1YOALurQFMNB8g [4]: https://mailarchive.ietf.org/arch/msg/dnsop/D5ZYnZf-E_TOhZmTLjkaFWxO_P0 [5]: https://mailarchive.ietf.org/arch/msg/dnsop/1F24G6vtreg3q5c5PxEOndXCI68 [6]: https://mailarchive.ietf.org/arch/msg/dnsop/0kynqLc8Ksicv4JDX3opB3nYyfI [7]: https://mailarchive.ietf.org/arch/msg/dnsop/07ISssrct9IXXyMpOgwGBXUczlw [8]: https://mailarchive.ietf.org/arch/msg/dnsop/0kynqLc8Ksicv4JDX3opB3nYyfI [9]: https://mailarchive.ietf.org/arch/msg/dnsop/VGTgsYAPXF_KsHCi2ruNa57QWYU --oyUTqETQ0mS9luUI Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEV6FHQYxbYRHTM+xJsO5EsOb06a0FAmJUXB4ACgkQsO5EsOb0 6a25PxAAp8+y2ON0+AhT7fVCa3FrdFFxpF3mXStFiYBWOJoV7aoVHGZ1t8aTZshf Bq51cos5sWmAcnywFogWlR10Em5FbeynBRP5Ofb6VFzjfBgx84EiUASeC0h/GUr3 7Ea4s6nkmCbruGVFL8l2EgicLANm8swhxsy7ldnb56rgJGXHU11QtJHEYudSetm0 3JcMmpIqdgJZcE65I2kwoWe+KF7pqHbbmWch/THiVvIGDRaYjnSZg9ERc4ZFluDH q1fk2kVIdXAwjUvNHMSr4pB9G3w1Iodkf6rqdDmGy9ZWGC6PhaDfMWkZ8odF9b3Y Sk/sElheq3n8svp9lcm26SIvAFX8XQqQQyW0wyT6VGe9CUgPz/GXRYVjd06f5+9Q B8G0HSdO5TNa1OnKAHTzac4ojcPJ9lvhgRhcw/1jMmQjr6/2UNKGl6dqOGinWYpo lg7cLFNpGo2RaYCeNCQwM6Y+c83GNDoRgd9bFS8MP57Qu+/oN5TDm4AS2VRwAGAw Z8Fo9R7b4LJ+bqT1mAbmvmE73pHXhSYbYywJASf0Lqq9Bnf6LvHdOcybYw/cHPSM IFaOfTkTcYuEd9t86u0OgN997CT7FcKP8LDnlRHyErLIlpa2brtKzihXM0K8SOFt BDOBbk1PZLL1l9k58bsMrQKgRDzvALmsTgCwLoZYtuFGXGvshNs= =ES/C -----END PGP SIGNATURE----- --oyUTqETQ0mS9luUI-- From nobody Mon Apr 11 10:37:32 2022 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 069083A09EB; Mon, 11 Apr 2022 10:37:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.109 X-Spam-Level: X-Spam-Status: No, score=-2.109 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sandelman.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 3vkfnYLmbLLD; Mon, 11 Apr 2022 10:37:23 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 431A33A099D; Mon, 11 Apr 2022 10:37:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 0AB9D38C03; Mon, 11 Apr 2022 13:48:51 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 3xOTkk4AzsE4; Mon, 11 Apr 2022 13:48:49 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 9AA0538BDC; Mon, 11 Apr 2022 13:48:49 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sandelman.ca; s=mail; t=1649699329; bh=riXWPdkWrG8cp0AcvFbzHrImVVOLEo674lIlzGUnLg4=; h=From:To:cc:Subject:In-Reply-To:References:Date:From; b=OLQJB64OR0iXVgo7A9Yr+nqIcgYk9gAkFcZHCoCDHOewcZ3rwKhOwEYZOQ5PTQjO5 ocCJ4+YEHZeTKIMr9UPFIr021AeeMzuhpt48j033FVRBLSBSmi+5XxEMMMAmxIVBEf BQTPrbCoaRn6h8Aw3TaNV2NppPrE0X6EW67CxiMRD3ozKm/XhVPU7BKibTnB0pnWzw 731flXvPXPGs6DEpMZP9QdM5eUGD8IA0ymUKscIMWxuc5Oky6FE31oBVKe6zqTrnZ6 eKUEX3AsDnSlvreZaX8+ELdVHYSO1P/V57/jnIRBj4a4G8qZrOC7lksIKommlFivwu yLbhIO9T1aayQ== Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 8D2553F; Mon, 11 Apr 2022 13:37:18 -0400 (EDT) From: Michael Richardson To: Andrew Sullivan cc: dnsop@ietf.org, mud@ietf.org In-Reply-To: <92E310C3-B9FA-4C8D-AB9A-06E069086BE2@anvilwalrusden.com> References: <24231.1649691469@localhost> <92E310C3-B9FA-4C8D-AB9A-06E069086BE2@anvilwalrusden.com> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 27.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [DNSOP] [Mud] looking for reference for reverse maps do not work X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2022 17:37:28 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Andrew Sullivan wrote: > I tried to document this ages ago in > https://datatracker.ietf.org/doc/draft-ietf-dnsop-reverse-mapping-con= siderations/, > and got so many contradictory edits (see the history) that the final > version ended up saying =E2=80=9CA or maybe not-A, or maybe both, you= r choice,=E2=80=9D > so the then-chairs decided the document wasn=E2=80=99t worth sending = through > publication. Oh. That's why I don't want to attempt writing this myself. So, that's not encouraging. =2D-=20 Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQFKBAEBCgA0FiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmJUZ04WHG1jcitpZXRm QHNhbmRlbG1hbi5jYQAKCRCAi3D73dDdZTtvB/98FdfSaxP5k6Dt1RJnjnEn9V// 9KnV1xiQIlXPvIRN0Y4gvXP0yzzhYc/QIsHn+1XDAvfI3rDPR7PZktKeinL5/D0m 8CmvOosx7J4TY9QNeOE6Z6RpSX+EVmiydoqVl7s8m3Ip1S4X1FJZFpSBAxfFBV3T xfqbZ/EZT01NlF8G21VVPjEWT+htj3iZDSds6l+kKwd546UJQU5RjXCv4JsLRHYW YCeRj2jwGTSer6BHKYtaH+yc+2cuzUlTYNgx5h1/d3+16JQFtENzWwsYYsPHX2c+ UDwYkd/rQOAIIt2y4uuZmRf07zppmpt9bp4S320V2ijqO1WKdapPivPf5Xyz =t4BT -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Apr 11 17:44:09 2022 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 A22853A0541 for ; Mon, 11 Apr 2022 17:44:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.108 X-Spam-Level: X-Spam-Status: No, score=-2.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isc.org header.b=DdpPcGL6; dkim=pass (1024-bit key) header.d=isc.org header.b=N4wsErJC 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 J80tfr8w6abb for ; Mon, 11 Apr 2022 17:43:59 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B74743A0490 for ; Mon, 11 Apr 2022 17:43:59 -0700 (PDT) Received: from zimbrang.isc.org (zimbrang.isc.org [149.20.1.12]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx.pao1.isc.org (Postfix) with ESMTPS id E8A103AB008; Tue, 12 Apr 2022 00:43:57 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.10.3 mx.pao1.isc.org E8A103AB008 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=isc.org; s=ostpay; t=1649724237; bh=vW/m5YTREWUCuvqY/579rU99z69lVDARbT8EJC3G1A8=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=DdpPcGL6760dVqxw3Aw0mL4u0a594NT3KFx1/gQ6NjDcTr5mTrkw4t5XFM0XG+oNI 0Rtno8tF+TraTNEWXmJZ/Y+HO/7BTWpjWJdEHGmD9GCyib6ze0ILriN8fSfZPvZhcf UobJEiU7PMUI6e0JwlBQYsibKXIHNM9mLpVIEFZw= Received: from zimbrang.isc.org (localhost.localdomain [127.0.0.1]) by zimbrang.isc.org (Postfix) with ESMTPS id D28A7A2133D; Tue, 12 Apr 2022 00:43:57 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbrang.isc.org (Postfix) with ESMTP id A2302A2133E; Tue, 12 Apr 2022 00:43:57 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.10.3 zimbrang.isc.org A2302A2133E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=05DFB016-56A2-11EB-AEC0-15368D323330; t=1649724237; bh=qDXRcCxDxxTIVVLQ+vfSrQU9tXP8GP2SniEX0F5b1K8=; h=Mime-Version:From:Date:Message-Id:To; b=N4wsErJC/y/7uYrqLhrrbbebMqxWVExDXqvhBcXZ9u/R/P4HYNIg3rnUt0YW/Hunh oIRtScqbFbkqKb1wkFrObNwB4j/R5LByzE0ubZXC+sZ+KS11ZI+3AIn4aIp+St8ICF Ospx93K/6RPKTy54WnCgOd3MZwoAbfEnowqNeFSM= Received: from zimbrang.isc.org ([127.0.0.1]) by localhost (zimbrang.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 4vL7dlbmNB82; Tue, 12 Apr 2022 00:43:57 +0000 (UTC) Received: from smtpclient.apple (n114-74-26-107.bla4.nsw.optusnet.com.au [114.74.26.107]) by zimbrang.isc.org (Postfix) with ESMTPSA id C75C4A2133D; Tue, 12 Apr 2022 00:43:56 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Mark Andrews In-Reply-To: Date: Tue, 12 Apr 2022 10:43:54 +1000 Cc: dnsop@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <355263CA-10A6-4AED-8622-8336A94F069A@isc.org> References: To: =?utf-8?Q?Eug=C3=A8ne_Adell?= X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: Subject: Re: [DNSOP] introducing a couple of RRTypes (CRC/CRS) for B2B applications X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2022 00:44:06 -0000 > On 11 Apr 2022, at 17:57, Mark Andrews wrote: >=20 > I don=E2=80=99t see why APL (RFC 3123) can=E2=80=99t be used for CRC = give you need to construct an > owner name anyway and have well known label to seperate the components = of the name. > I see no reason to re-invent the wheel here. >=20 > ftp.foo.com_21_bar.com,195.13.35.0/24,91.220.43.0/24 >=20 > would be >=20 > ftp.foo.com._21._crc.bar.com APL 1:195.13.35.0/24 1:91.220.43.0/24 Additionally text is a really bad way to transmit IP address and = prefixes in the DNS. DNS RRsets are resource constrained (maximum < 64k). DNS = caches are resource constrained. 10-16 octets of text for an IPv4/24 vs 7 = octets for APL. An IPv4/8 is 9-11 vs 5 octets. The :: improves this a little bit for = IPv6 but in general you will be dealing with /48=E2=80=99s or longer = xxxx:xxxx:xxxx::/48 (19 octets) vs 10 for APL. >> On 5 Apr 2022, at 20:52, Eug=C3=A8ne Adell = wrote: >>=20 >> Hello, >>=20 >> I've been working on two new RRTypes described by a Draft, and as >> suggested by our magnificent, incredibly brilliant and handsome AD >> Warren "ACE" Kumari, I am posting here this idea and the material I >> have written so far (the draft itself, and RFC 6895 components). >>=20 >> Briefly, one RRType (CRC : Client Roaming Control) contains a >> whitelist of networks allowing a company employees to connect to a >> specific application. The second RRType (CRS : Client Roaming = Support) >> is on the application side and informs what kind of restrictions are >> applied (by saying if CRC is mandatory, optional or ignored). >> This is not expected to be deployed broadly and everywhere as it is >> designed to secure Business-To-Business applications. >>=20 >> The material (text XML2RFC draft + RFC 6895 components) written is >> both incorporated below to this email and attached, for practical >> reasons. >>=20 >>=20 >> Regards >> E.A. >>=20 >>=20 >>=20 >>=20 >>=20 >> Internet Engineering Task Force E. = Adell >> Internet-Draft 5 April = 2022 >> Intended status: Informational >> Expires: 7 October 2022 >>=20 >>=20 >> Client Roaming Control >> draft-adell-client-roaming-00 >>=20 >> Abstract >>=20 >> This document specifies the Client Roaming Control (CRC) DNS = Resource >> Record allowing an organization to better control the access to >> third-party applications over Internet. The applications >> implementing an authorization mechanism to honor the CRC, publish on >> their side the Client Roaming Support (CRS) Resource Record to = inform >> of this support. >>=20 >> Status of This Memo >>=20 >> This Internet-Draft is submitted in full conformance with the >> provisions of BCP 78 and BCP 79. >>=20 >> Internet-Drafts are working documents of the Internet Engineering >> Task Force (IETF). Note that other groups may also distribute >> working documents as Internet-Drafts. The list of current Internet- >> Drafts is at https://datatracker.ietf.org/drafts/current/. >>=20 >> Internet-Drafts are draft documents valid for a maximum of six = months >> and may be updated, replaced, or obsoleted by other documents at any >> time. It is inappropriate to use Internet-Drafts as reference >> material or to cite them other than as "work in progress." >>=20 >> This Internet-Draft will expire on 7 October 2022. >>=20 >> Copyright Notice >>=20 >> Copyright (c) 2022 IETF Trust and the persons identified as the >> document authors. All rights reserved. >>=20 >> This document is subject to BCP 78 and the IETF Trust's Legal >> Provisions Relating to IETF Documents (https://trustee.ietf.org/ >> license-info) in effect on the date of publication of this document. >> Please review these documents carefully, as they describe your = rights >> and restrictions with respect to this document. Code Components >> extracted from this document must include Revised BSD License text = as >> described in Section 4.e of the Trust Legal Provisions and are >> provided without warranty as described in the Revised BSD License. >>=20 >>=20 >>=20 >> Adell Expires 7 October 2022 [Page = 1] >>=20 >> Internet-Draft Client Roaming Control April = 2022 >>=20 >>=20 >> Table of Contents >>=20 >> 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . = 2 >> 2. Conventions Used in This Document . . . . . . . . . . . . . . = 3 >> 3. The CRC Resource Record . . . . . . . . . . . . . . . . . . . = 4 >> 3.1. RR name field . . . . . . . . . . . . . . . . . . . . . . = 4 >> 3.2. CRC RDATA Wire Format . . . . . . . . . . . . . . . . . . = 4 >> 3.3. CRC Presentation Format . . . . . . . . . . . . . . . . . = 4 >> 4. The CRS Resource Record . . . . . . . . . . . . . . . . . . . = 5 >> 4.1. CRS RDATA Wire Format . . . . . . . . . . . . . . . . . . = 5 >> 4.2. CRS Presentation Format . . . . . . . . . . . . . . . . . = 5 >> 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . = 6 >> 5.1. Restricted Application . . . . . . . . . . . . . . . . . = 6 >> 5.2. Controlled Application . . . . . . . . . . . . . . . . . = 7 >> 5.3. Opened Application . . . . . . . . . . . . . . . . . . . = 8 >> 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . = 9 >> 7. Security Considerations . . . . . . . . . . . . . . . . . . . = 9 >> 7.1. DNS misconfiguration . . . . . . . . . . . . . . . . . . = 9 >> 7.2. DNS Security . . . . . . . . . . . . . . . . . . . . . . = 10 >> 7.3. Application Security . . . . . . . . . . . . . . . . . . = 10 >> 8. References . . . . . . . . . . . . . . . . . . . . . . . . . = 10 >> 8.1. Normative References . . . . . . . . . . . . . . . . . . = 11 >> 8.2. Informative References . . . . . . . . . . . . . . . . . = 11 >> Author's Address . . . . . . . . . . . . . . . . . . . . . . . . = 11 >>=20 >> 1. Introduction >>=20 >> Illegitimate access to professional restricted applications over >> Internet is a permanent threat for organizations and their staff. >> Different methods can be used to impersonate a user access, and in >> some cases an organization also wants to better prevent its own = staff >> to access a third-party application from a network which is not = under >> its control. On the contrary, an organization maybe wants to allow >> roaming then its users can access from different known places. >>=20 >> The Client Roaming Control (CRC) DNS Resource Record (RR) acts as a >> White-List and informs a compatible application from which networks >> its users are allowed to connect, be it a limited list of networks = or >> broadly without any restriction. >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> Adell Expires 7 October 2022 [Page = 2] >>=20 >> Internet-Draft Client Roaming Control April = 2022 >>=20 >>=20 >> At the application level, the identification of the user's >> organization domain can be based on an information carried during = the >> authentication process, or a lookup on an information already known >> by the application. In both cases this information lets the >> application relate the user to its organization unequivocally. >> Finally, the corresponding user's domain DNS will be requested with >> the application's FQDN and port, and the application will know >> whether an authorization is expected or not. Some examples will be >> given in this document. >>=20 >> The applications implementing this authorization control let the >> client organizations know this feature is available by using the >> Client Roaming Support (CRS) RR. The data associated with this >> record indicates if the client's organization expected support of = the >> CRC is mandatory, optional, or ignored. This information stored in >> the CRS can be confirmed at the application level by a redundant >> data. The way the application handles the authorization mechanism, >> by consulting the associated CRS record or not, is left to the >> implementor. >>=20 >> Although this mechanism is designed for improving the security >> between different organizations, there is no objection to use it for >> a same organization playing both roles of client and application , = as >> an alternative or additional layer to a solution already in place, >> such as a firewall for example. >>=20 >> 2. Conventions Used in This Document >>=20 >> This specification uses definitions from Domain Name System >> [RFC1035], and readers unfamiliar with it can also check DNS >> Terminology [RFC8499]. The syntax specification uses the Augmented >> Backus-Naur Form (ABNF) notation as specified in [RFC5234], with = some >> expressions being defined in "Uniform Resource Identifier (URI): >> Generic Syntax" [RFC3986] and "IP Version 6 Addressing Architecture" >> [RFC4291]. >>=20 >> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", >> "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and >> "OPTIONAL" in this document are to be interpreted as described in = BCP >> 14 [RFC2119] [RFC8174] when, and only when, they appear in all >> capitals, as shown here. >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> Adell Expires 7 October 2022 [Page = 3] >>=20 >> Internet-Draft Client Roaming Control April = 2022 >>=20 >>=20 >> 3. The CRC Resource Record >>=20 >> The CRC RR purpose is to provide a list of IP ranges authorized to >> use a particular application. Each RR contains a list of either = IPv4 >> or IPv6 network address ranges. These ranges MUST follow the CIDR >> notation. A single CRC RR MAY contain ranges for different IP >> versions, but in the case of many ranges this can be difficult to >> read or maintain, so dedicating a record to each IP version or not = is >> left to the administrator. Multiple RRs MAY be defined for a given >> IP version. >>=20 >> 3.1. RR name field >>=20 >> The CRC RR name field is composed of the third-party application >> domain, its port, followed by the fully qualified name inherent in >> this zone. These three components are separated by the underscore >> character. >>=20 >> 3.2. CRC RDATA Wire Format >>=20 >> The CRC RDATA wire format is encoded as follows: >>=20 >> +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ >> / CRC / >> / / >> +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ >>=20 >> The CRC field contains a list of either IPv4 or IPv6 ranges = separated >> by the comma character. >>=20 >> 3.3. CRC Presentation Format >>=20 >> The presentation format of the CRC record is: >>=20 >> CRC (ip4netlist [,ip6netlist]) / ([ip4netlist,] ip6netlist) >>=20 >> ip4netlist =3D ip4net *(,ip4net) >>=20 >> ip4net =3D IPv4address "/" ip4range >>=20 >> ip4range =3D DIGIT / "1" DIGIT / "2" DIGIT / "3" DIGIT %x30-32 >>=20 >> ip6netlist =3D ip6net *(,ip6net) >>=20 >> ip6net =3D (ipv6-address "/" prefix-length) >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> Adell Expires 7 October 2022 [Page = 4] >>=20 >> Internet-Draft Client Roaming Control April = 2022 >>=20 >>=20 >> 4. The CRS Resource Record >>=20 >> The CRS RR indicates which control is done on the client >> organizations, and thus which ones are authorized. A requirement >> field is used for this purpose, it has one of the following values >> meaning when the checking is performed : >>=20 >> * "N" : Never, all organizations are authorized >>=20 >> * "A" : Always, only organizations with a CRC are authorized >>=20 >> * "O" : Optional, any organization CRC is honored, other >> organizations are authorized >>=20 >> In addition to this value, an optional list of ports can be given. >> Indeed, multiple applications can be hosted on different ports under >> the same domain name, and an equivalent support was described for = the >> CRC RR. In case of different requirement values, it is RECOMMENDED >> to have one dedicated RR for each although one single RR with all = the >> information is supported. One particular port MUST NOT appear in >> more than one RR. When no port is mentioned, only one RR MAY be >> declared and its requirement value covers all applications for this >> domain name. >>=20 >> In the absence of such record, no roaming control is to be expected >> by the client, any of its CRC RRs will be ignored. It is equivalent >> to a CRS requirement value indicating no control is performed. >>=20 >> 4.1. CRS RDATA Wire Format >>=20 >> The CRS RDATA wire format is encoded as follows: >>=20 >> +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ >> / CRS / >> / / >> +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ >>=20 >> The CRS field contains a list of requirements followed by their >> respective optional ports. >>=20 >> 4.2. CRS Presentation Format >>=20 >> The presentation format of the CRS record is: >>=20 >> CRS (single-rule / multiple-rules) >>=20 >> single-rule =3D "R=3D" ("N" / "A" / "O") *(,port) >>=20 >>=20 >>=20 >>=20 >> Adell Expires 7 October 2022 [Page = 5] >>=20 >> Internet-Draft Client Roaming Control April = 2022 >>=20 >>=20 >> multiple-rules =3D unit-rule 1*2(;unit-rule) >>=20 >> unit-rule =3D "R=3D" ("N" / "A" / "O") 1*(,port) >>=20 >> port =3D [1-9] *([DIGIT]) >>=20 >> 5. Examples >>=20 >> The following examples show some typical uses expected from this >> documentation. Particularly, the intended behaviors for different >> CRC and CRS values are explained, while the user identification is >> done directly through carried data or a deduction process. >>=20 >> 5.1. Restricted Application >>=20 >> In this example, an application is only opened to organizations >> publishing their respective allowed networks. The requirement value >> of the CRS record equals "A", and any organization with an empty or >> missing CRC for this application will be denied access. >>=20 >> The ftp.foo.com domain is dedicated to hosting an FTP application, >> which extracts the client's domain from the username used during the >> authentication process. This information is then used for = requesting >> the client CRC record and finally comparing its content with the >> client's IP. The client organization bar.com allows its users from >> its own network 195.13.35.0/24 and from a cloud service located at >> 91.220.43.0/24. A second organization baz.com has no CRC record and >> its users are rejected. >>=20 >> Application FQDN : ftp.foo.com >> Application CRS record : CRS R=3DA,21 >>=20 >> Client FQDN : bar.com >> Client organization CRC record : CRC >> ftp.foo.com_21_bar.com,195.13.35.0/24,91.220.43.0/24 >>=20 >> Client FQDN : baz.com >> No client organization CRC record >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> Adell Expires 7 October 2022 [Page = 6] >>=20 >> Internet-Draft Client Roaming Control April = 2022 >>=20 >>=20 >> Client DNS Client FTP Server FTP >>=20 >> FTP USER me@bar.com >> -----------------------------> >> ... >> FTP PASS ******** >> -----------------------------> >> Query : CRC ftp.foo.com_21_bar.com >> <------------------------------------ >> Answer : CRC = ftp.foo.com_21_bar.com,195.13.35.0/24,91.220.43.0/24 >> ------------------------------------> >> FTP 230 >> <------------------------------ >>=20 >>=20 >> FTP USER me@baz.com >> -----------------------------> >> ... >> FTP PASS ******** >> -----------------------------> >> Query : CRC ftp.foo.com_21_baz.com >> <------------------------------------ >> Answer : No such name (3) >> ------------------------------------> >> FTP 430 >> <------------------------------ >>=20 >> 5.2. Controlled Application >>=20 >> The foo.com domain hosts a Web application on port 443 using client >> certificates for authenticating its users. The application extracts >> the client domains from the certificates, which are used to retrieve >> their CRC records. Users from the bar.com organization are allowed >> only if they connect from an authorized network listed in the CRC >> record, while users from baz.com are always granted access since = this >> one has no CRC declared. >>=20 >> Application FQDN : foo.com >> Application CRS record : CRS R=3DA,443 >>=20 >> Client FQDN : bar.com >> Client organization CRC record : CRC >> ftp.foo.com_443_bar.com,195.13.35.0/24,91.220.43.0/24 >>=20 >> Client FQDN : baz.com >> No client organization CRC record >>=20 >>=20 >>=20 >>=20 >>=20 >> Adell Expires 7 October 2022 [Page = 7] >>=20 >> Internet-Draft Client Roaming Control April = 2022 >>=20 >>=20 >> Client DNS Client browser Web application >>=20 >>=20 >> ..... >> Client certificate me@bar.com >> -----------------------------------> >> Query : CRC foo.com_443_bar.com >> <------------------------------------------ >> Answer : CRC = foo.com_443_bar.com,195.13.35.0/24,91.220.43.0/24 >> ------------------------------------------> >> ..... >> 200 OK >> <----------------------------------- >>=20 >>=20 >> ..... >> Client certificate me@baz.com >> -----------------------------------> >> Query : CRC foo.com_443_baz.com >> <------------------------------------------ >> Answer : No such name (3) >> ------------------------------------------> >> ..... >> 200 OK >> <----------------------------------- >>=20 >> 5.3. Opened Application >>=20 >> A company is testing the CRC and CRS behaviors before opening a new >> service to its customers. Its first test described below consists = in >> configuring both sides to be completely opened, likely before >> hardening the CRS, then the CRC, and testing again. >>=20 >> The application.foo.com domain hosts a Web application on port 443 >> where users are logged in by sending a numerical identifier and a >> password. The application uses a dictionary data type to identify >> the user's domain. The client.foo.com domain is temporarily using 2 >> CRC records indicating a free access from anywhere. >>=20 >> Application FQDN : application.foo.com >> Application CRS record : CRS R=3DN,443 >>=20 >> Client FQDN : client.foo.com >> Client organization CRC records : CRC >> application.foo.com_443_foo.com,0.0.0.0/24; CRC >> application.foo.com_443_foo.com,fe80::/10 >>=20 >>=20 >>=20 >>=20 >>=20 >> Adell Expires 7 October 2022 [Page = 8] >>=20 >> Internet-Draft Client Roaming Control April = 2022 >>=20 >>=20 >> Client DNS Client browser Web application >>=20 >>=20 >> ..... >> HTTP POST 123456/****** >> -----------------------------------> >> 200 OK >> <----------------------------------- >>=20 >> 6. IANA Considerations >>=20 >> According to Guidelines for Writing an IANA Considerations Section = in >> RFCs [RFC8126] it is asked to IANA to add into the Resource Record >> (RR) TYPEs registry located at https://www.iana.org/assignments/dns- >> parameters/dns-parameters.xhtml#dns-parameters-4 the two entries CRC >> and CRS. >>=20 >> +------+-------+------------------------+-----------+ >> | TYPE | Value | Description | Reference | >> +------+-------+------------------------+-----------+ >> | CRC | TBD1 | Client Roaming Control | this RFC | >> +------+-------+------------------------+-----------+ >> | CRS | TBD2 | Client Roaming Support | this RFC | >> +------+-------+------------------------+-----------+ >>=20 >> Table 1 >>=20 >> 7. Security Considerations >>=20 >> This section is meant to inform developers and users of the security >> implications of the CRC/CRS mechanism described by this document. >> While the CRS RR mostly plays an informative role, the CRC RR >> delivers important data which requires attention from the developers >> and administrators. Some particular points are discussed here. >>=20 >> 7.1. DNS misconfiguration >>=20 >> Any DNS CRS misconfiguration such as multiple records with different >> requirement values but with the same port value can get a client >> confused. In this case the client does not know without testing the >> actual configuration, if its organization is protected against >> roaming, and contacting the application administrator to fix the >> situation is a possibility. >>=20 >> While CRC misconfigurations are more or less leading to serious >> security problems, administrators need to pay attention when dealing >> with multiple networks or records. Particularly, multiple records >> for the same network range or overlapping networks should be = avoided. >>=20 >>=20 >>=20 >> Adell Expires 7 October 2022 [Page = 9] >>=20 >> Internet-Draft Client Roaming Control April = 2022 >>=20 >>=20 >> 7.2. DNS Security >>=20 >> Client and application administrators need to pay as much attention >> as they usually do when dealing with DNS management. As the CRC >> records are supposed to be requested during an application >> authentication process, reflection attacks could be built to target = a >> client organization, even one not hosting any CRC record at all. >> In a general manner, administrators may consider an adequate TTL >> setting to not overload client organizations, enable TCP as the >> preferred transport, or rely on DNSSEC to warrant data authenticity >> and integrity. >>=20 >> 7.3. Application Security >>=20 >> The following points are of concern to developers: >>=20 >> Encryption: >> Whenever possible, the application protocol should be encrypted to >> prevent eavesdropping and man-in-the-middle attacks. It is a >> critical point for applications maintaining a user session with >> anything like a token or cookie, as it can lead to session hijacking >> as discussed below. >>=20 >> Timing attack: >> All authentication systems need to be careful to not deliver any >> information derived from the computing time to a denied user, even >> the ones involving multiple factors or steps like the one described >> in this document. In particular, the order in which these steps are >> executed and their respective implementations, need to defeat >> statistical hypotheses. >>=20 >> Intermediate systems: >> Some applications are not directly Internet facing and cannot access >> to the real client's IP address without involving a mechanism to >> forward this IP at the application layer. For example with HTTP, = the >> common practice based on the non-standard X-Forwarded-For header, or >> its alternative standard Forwarded [RFC7239], are playing this role. >> Such practice requires a correct sanitizing of user data to avoid >> false injected IPs. >>=20 >> Session hijacking: >> A well-known attack called Session Hijacking is not meant to be >> defeated by this document alone. Application developers must ensure >> that any receveid session token, such as an HTTP Cookie, belongs to >> the same IP address than the one which started this session. >>=20 >> 8. References >>=20 >>=20 >>=20 >>=20 >> Adell Expires 7 October 2022 [Page = 10] >>=20 >> Internet-Draft Client Roaming Control April = 2022 >>=20 >>=20 >> 8.1. Normative References >>=20 >> [RFC1035] Mockapetris, P., "Domain names - implementation and >> specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, >> November 1987, . >>=20 >> [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate >> Requirement Levels", BCP 14, RFC 2119, >> DOI 10.17487/RFC2119, March 1997, >> . >>=20 >> [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform >> Resource Identifier (URI): Generic Syntax", STD 66, >> RFC 3986, DOI 10.17487/RFC3986, January 2005, >> . >>=20 >> [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing >> Architecture", RFC 4291, DOI 10.17487/RFC4291, February >> 2006, . >>=20 >> [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for = Syntax >> Specifications: ABNF", STD 68, RFC 5234, >> DOI 10.17487/RFC5234, January 2008, >> . >>=20 >> [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC >> 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, >> May 2017, . >>=20 >> 8.2. Informative References >>=20 >> [RFC7239] Petersson, A. and M. Nilsson, "Forwarded HTTP Extension", >> RFC 7239, DOI 10.17487/RFC7239, June 2014, >> . >>=20 >> [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS >> Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, >> January 2019, . >>=20 >> Author's Address >>=20 >> Eugene Adell >> Email: eugene.adell@gmail.com >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> Adell Expires 7 October 2022 [Page = 11] >>=20 >>=20 >> RFC 6895 : >> A. Submission Date:2002/04/05 >> B.1 Submission Type: [X] New RRTYPE [ ] Modification to RRTYPE >> B.2 Kind of RR: [X] Data RR [ ] Meta-RR >> C. Contact Information for submitter : >> Name: Eugene Adell Email Address: = eugene.adell@gmail.com >> International telephone number: +33699056914 >> Other contact handles: >> D. Motivation for the new RRTYPE application. >> Introduce a couple of RR types working together in order to better >> secure remote access to partner applications >> E. Description of the proposed RR type. >> CRC contains a limited list of authorized networks for a particular >> application >> F. What existing RRTYPE or RRTYPEs come closest to filling that need >> and why are they unsatisfactory? >> TXT RRTYPE allows the storage of any text data but in practice is >> usually associated with more or less fixed name or data which is not >> what is needed here. A dedicated RRTYPE is easier to identify and >> manage by a security team other than the usual DNS operator team. >> G. What mnemonic is requested for the new RRTYPE (optional)? >> CRC >> H. Does the requested RRTYPE make use of any existing IANA registry = or >> require the creation of a new IANA subregistry in DNS Parameters? >> It uses the existing Resource Record (RR) TYPEs registry >> I. Does the proposal require/expect any changes in DNS >> servers/resolvers that prevent the new type from being processed as = an >> unknown RRTYPE (see [RFC3597])? >> No >> J. Comments: >> None >>=20 >>=20 >> A. Submission Date:2002/04/05 >> B.1 Submission Type: [X] New RRTYPE [ ] Modification to RRTYPE >> B.2 Kind of RR: [X] Data RR [ ] Meta-RR >> C. Contact Information for submitter : >> Name: Eugene Adell Email Address: = eugene.adell@gmail.com >> International telephone number: +33699056914 >> Other contact handles: >> D. Motivation for the new RRTYPE application. >> Introduce a couple of RR types working together in order to better >> secure remote access to partner applications >> E. Description of the proposed RR type. >> CRS contains a requirement value and a list of ports indicating >> what kind of authorization check is done during the application >> authentication process >> F. What existing RRTYPE or RRTYPEs come closest to filling that need >> and why are they unsatisfactory? >> TXT RRTYPE allows the storage of any text data but in practice is >> usually associated with more or less fixed name or data which is not >> what is needed here. A dedicated RRTYPE is easier to identify and >> manage by a security team other than the usual DNS operator team. >> G. What mnemonic is requested for the new RRTYPE (optional)? >> CRS >> H. Does the requested RRTYPE make use of any existing IANA registry = or >> require the creation of a new IANA subregistry in DNS Parameters? >> It uses the existing Resource Record (RR) TYPEs registry >> I. Does the proposal require/expect any changes in DNS >> servers/resolvers that prevent the new type from being processed as = an >> unknown RRTYPE (see [RFC3597])? >> No >> J. Comments: >> None >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop >=20 > --=20 > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org >=20 > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop --=20 Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Tue Apr 12 01:38:29 2022 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 AA5BD3A06E7 for ; Tue, 12 Apr 2022 01:38:27 -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, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, T_SCC_BODY_TEXT_LINE=-0.01, 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 MhBWjk0PbLPe for ; Tue, 12 Apr 2022 01:38:23 -0700 (PDT) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id D12C43A077C for ; Tue, 12 Apr 2022 01:38:20 -0700 (PDT) Received: from CNNIC-PC (unknown [218.241.111.115]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0BZYXl4OlVi7hxZAA--.4635S2; Tue, 12 Apr 2022 16:38:16 +0800 (CST) Date: Tue, 12 Apr 2022 16:38:17 +0800 From: zhangcuiling To: "Paul Wouters" Cc: dnsop References: <202204111111585901567@cnnic.cn>, <4af2f29f-b2ac-b2e7-e977-793461adfda5@nohats.ca> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.2.18.95[cn] Mime-Version: 1.0 Message-ID: <202204121637168708993@cnnic.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart321488411677_=----" X-CM-TRANSID: AQAAf0BZYXl4OlVi7hxZAA--.4635S2 X-Coremail-Antispam: 1UD129KBjvJXoWxAFy8KFW7GrW7WFy5uw1UGFg_yoW5Aw18pF Wxtw1ktaykJFnxGas2gw4xWayFvrZ5Gw4UGFn8JrWvywn8ZFnavryIkay5Way3Wrn3ZF1j qr4IvFyDAan8CaDanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUU9Gb7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Ar0_tr1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Cr0_Gr1UM28EF7xvwVC2z280aVAFwI0_GcCE3s1l84ACjcxK6I 8E87Iv6xkF7I0E14v26rxl6s0DM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVC2j2CE jI02ccxYII8I67AEr4CY67k08wAv7VC0I7IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI 0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4UM4x0Y48IcxkI7VAKI48JM4xvF2IEb7IF0Fy2 64kE64k0F24lc2xSY4AK67AK6r43MxAIw28IcxkI7VAKI48JMxC20s026xCaFVCjc4AY6r 1j6r4UMI8I3I0E5I8CrVAFwI0_JrI_JrWlx2IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE17CE b7AF67AKxVWUXVWUAwCIc40Y0x0EwIxGrwCI42IY6xIIjxv20xvE14v26r1j6r1xMIIF0x vE2Ix0cI8IcVCY1x0267AKxVWUJVW8JwCI42IY6xAIw20EY4v20xvaj40_WFyUJVCq3wCI 42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E14v26r1j6r4UMVCEFcxC0V AYjxAxZFUvcSsGvfC2KfnxnUUI43ZEXa7IU5drcDUUUUU== X-CM-SenderInfo: x2kd0wxfxlzxlqj6u0xqlfhubq/ Archived-At: Subject: Re: [DNSOP] A new draft on SM2 digital signature algorithm for DNSSEC X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2022 08:38:28 -0000 This is a multi-part message in MIME format. ------=_001_NextPart321488411677_=---- Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpNYW55IHRoYW5rcyBmb3IgcmVhZGluZyB0aGUgZHJhZnQuDQoNCj4gZnJvbTogIlBhdWwgV291 dGVycyIgPHBhdWxAbm9oYXRzLmNhPiBvbiBNb24sIDIwMjItMDQtMTENCj4gdG86IHpoYW5nY3Vp bGluZyA8emhhbmdjdWlsaW5nQGNubmljLmNuPg0KPiBjYzogZG5zb3AgPGRuc29wQGlldGYub3Jn Pg0KPiBzdWJqZWN0OiBSZTogW0ROU09QXSBBIG5ldyBkcmFmdCBvbiBTTTIgZGlnaXRhbCBzaWdu YXR1cmUgYWxnb3JpdGhtIGZvciBETlNTRUMNCj4gDQo+IE9uIE1vbiwgMTEgQXByIDIwMjIsIHpo YW5nY3VpbGluZyB3cm90ZToNCj4gDQo+ID4gQW5kIHRoZSBtYWluIHB1cnBvc2UgaXMgdG8gaW1w cm92ZSB0aGUgZGl2ZXJzaXR5IG9mIEROU1NFQyBhbGdvcml0aG1zLCBhbmQgdG8gbWFrZSBpdCBj b252ZW5pZW50IGZvciBwZW9wbGUgd2hvIHdhbnQgdG8gdXNlIFNNMg0KPiA+IGRpZ2l0YWwgc2ln bmF0dXJlIGFsZ29yaXRobSBhcyBhbiBhbHRlcm5hdGl2ZSBmb3IgRE5TU0VDLg0KPiANCj4gV2Ug YWN0dWFsbHkgd2FudCB0byBwcmV2ZW50IGFzIG11Y2ggZGl2ZXJzaXR5IGFzIHdlIGNhbiwgdG8g YXZvaWQNCj4gY3JlYXRpbmcgbW9yZSBuZXcgbG9uZyB0YWlscyBvZiBkZXBsb3ltZW50IG9mIGFs Z29yaXRobXMuIFNvIGEgbmV3DQoNClRoYXQgc291bmRzIHJlYXNvbmFibGUuIEl0IGRvZXMgbmVl ZCBhZGRpdGlvbmFsIHdvcmsgdG8gc3VwcG9ydCANClNNMiBEaWdpdGFsIFNpZ25hdHVyZSBBbGdv cml0aG0gZm9yIEROUyBzb2Z0d2FyZSBpbXBsZW1lbnRhdGlvbi4gDQpUaGUgZ29vZCBuZXdzIGlz IHRoYXQgT3BlbnNzbCBoYXMgc3VwcG9ydGVkIGl0IHNpbmNlIHZlcnNpb24gMS4xLjEuIA0KQW5k IEkgdGhpbmsgT3BlbnNzbCBpcyB3aWRlbHkgdXNlZCBhbW9uZyBETlMgc29mdHdhcmUuDQoNCj4g YWxnb3JpdGhtIHNob3VsZCByZWFsbHkgb2ZmZXIgc29tZXRoaW5nIHRoZSBvdGhlcnMgZG8gbm90 LiBBbHNvIGhhdmluZw0KPiBhIG51bWJlciBvZiBFQ0MgYmFzZWQgYWxnb3JpdGhtcyB3b3VsZCBs aWtlbHkgbWVhbiBpZiBvbmUgZW5kcyB1cA0KPiBicm9rZW4sIGFsbCBvZiB0aGVtIGVuZCB1cCBi cm9rZW4uDQo+IA0KPiBTbyBiYXNlZCBvbjoNCj4gDQo+ICAgRHVlIHRvIHRoZSBzaW1pbGFyaXR5 IGJldHdlZW4gU00yIGFuZCBFQ0RTQSB3aXRoIGN1cnZlIFAtMjU2LCBzb21lDQo+ICAgb2YgdGhl IG1hdGVyaWFsIGluIHRoaXMgZG9jdW1lbnQgaXMgY29waWVkIGxpYmVyYWxseSBmcm9tIFJGQyA2 NjA1DQo+ICAgW1JGQzY2MDVdLg0KPiANCj4gSSBkb24ndCBzZWUgYSBzdHJvbmcgcmVhc29uIHRv IGFkb3B0IGFub3RoZXIgRUNDIHR5cGUgb2YgYWxnb3JpdGhtLg0KDQpTb3JyeSB0aGF0IG1heWJl IEkgZGlkbid0IG1ha2UgaXQgY2xlYXIuIA0KDQpBYm91dCBTTTIgYW5kIEVDRFNBOg0KU00yIGFu ZCBFQ0RTQSBhcmUgc2ltaWxhciBpbiB0aGUgZm9sbG93aW5nIGFzcGVjdHM6IHRoZSBsZW5ndGgg b2YgdGhlIA0KcHJpdmF0ZSBrZXkgKDMyIG9jdGV0cyksIHB1YmxpYyBrZXkgKDY0IG9jdGV0cykg YW5kIHRoZSBzaWduYXR1cmUgDQooNjQgb2N0ZXRzKSBhcmUgdGhlIHNhbWUuIA0KQnV0IHRoZXJl IGlzIGFuIGltcG9ydGFudCBkaWZmZXJlbmNlIGJldHdlZW4gdGhlc2UgdHdvIGFsZ29yaXRobXMs IA0Kd2hpY2ggaXMgdGhlIHByb2Nlc3Mgb2Ygc2lnbmF0dXJlIGNhbGN1bGF0aW9uLiBTbyBTTTIg aXMgYSBkaWZmZXJlbnQgDQphbGdvcml0aG0gZnJvbSBFQ0RTQS4NCkJ5IHRoZSB3YXksIGNvbXBh cmVkIHRvIGEgdG90YWxseSBkaWZmZXJlbnQgYWxnb3JpdGhtLCANCnRoZSBzaW1pbGFyaXR5IGJl dHdlZW4gU00yIGFuZCBFQ0RTQSBjYW4gcmVkdWNlIHRoZSBjb21wbGljYXRpb24gb2YgDQpzdXBw b3J0aW5nIFNNMiB0byBzb21lIGV4dGVudC4NCg0KQWJvdXQgdGhlIHNlY3VyaXR5IG9mIEVDQy1i YXNlZCBhbGdvcml0aG1zOg0KQXMgZmFyIGFzIEkga25vdywgdGhlIHNlY3VyaXR5IG9mIEVDQy1i YXNlZCBhbGdvcml0aG1zIGlzIHN0cm9uZ2x5IA0KaW5mbHVlbmNlZCBieSB0aGUgY3VydmUgaXQg dXNlcy4gU29tZXRpbWVzIGl0J3MgaGFyZCB0byBzYXkgd2hpY2ggDQpjdXJ2ZSBpcyBtdWNoIHNh ZmVyLiBFbGxpcHRpYyBjdXJ2ZSBzZWNwMjU2cjEgKGZvciBETlNTRUMpIGFuZCANCnNlY3AyNTZr MSAoZm9yIGJsb2NrY2hhaW4pIGFyZSByZWxhdGl2ZWx5IHBvcHVsYXIgZm9yIEVDRFNBLiANCg0K U00yIHVzZXMgYSBkaWZmZXJlbnQgY3VydmUgYW5kIGhhcyBkaWZmZXJlbnQgcHJvY2VzcyB3aXRo IHRoZSBzaWduYXR1cmUNCmdlbmVyYXRpb24gYW5kIHZhbGlkYXRpb24sIHNvIEknZCBsaWtlIHRv IGNvbnNpZGVyIGl0IGFzIGFuIGFsdGVybmF0aXZlDQp0byBFQ0RTQS4NCg0KPiANCj4gQWRkaXRp b25hbGx5LCBpbiB0aGlzIGNhc2UgU00yL1NNMyBzZWVtcyB0byBiZSBJU08gc3RhbmRhcmRzIHRo YXQgYXJlDQo+IG5vdCBmcmVlbHkgYXZhaWxhYmxlLCBzbyB0aGVzZSBhcmUgYWRkaXRpb25hbGx5 IHByb2JsZW1hdGljLg0KPiANCg0KSSBhZ3JlZSB3aXRoIHlvdS4gSSBzaG91bGQgc3BlY2lmeSBh IGRvY3VtZW50IHRoYXQgY291bGQgYmUgZG93bmxvYWRlZCBmcmVlbHkuDQpIZXJlIGlzIGFub3Ro ZXIgb25lIGludHJvZHVjaW5nIFNNMi9TTTMgaW4gZGV0YWlsOg0KIkluZm9ybWF0aW9uIHNlY3Vy aXR5IHRlY2hub2xvZ3kgLS0tIFB1YmxpYyBrZXkgY3J5cHRvZ3JhcGhpYyBhbGdvcml0aG0gDQpT TTIgYmFzZWQgb24gZWxsaXB0aWMgY3VydmVzIC0tLSBQYXJ0IDI6IERpZ2l0YWwgc2lnbmF0dXJl IGFsZ29yaXRobSINCmh0dHA6Ly93d3cuZ21iei5vcmcuY24vdXBsb2FkLzIwMTgtMDctMjQvMTUz MjQwMTY3MzEzODA1NjMxMS5wZGYNCkl0J3Mgd3JpdHRlbiBpbiBFbmdsaXNoLCBidXQgdW5mb3J0 dW5hdGVseSBpdCdzIG5vdCBhbiBpbnRlcm5hdGlvbmFsIHN0YW5kYXJkLg0KSSB3aWxsIGtlZXAg b24gdHJ5aW5nIHRvIGZpbmQgYSBtb3JlIHByb3BlciBkb2N1bWVudC4NCg0KVGhhbmsgeW91IGFn YWluIGZvciB5b3VyIHRpbWUgYW5kIHlvdXIgaGVscGZ1bCBjb21tZW50Lg0KDQpCZXN0IHJlZ2Fy ZHMsDQoNCkNhdGh5IFpoYW5nDQo= ------=_001_NextPart321488411677_=---- Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
Many thanks= for reading the draft.

> from: "Paul Wouters" <paul@nohats.ca> on Mon, = 2022-04-11
> to: zhangcuiling &= lt;zhangcuiling@cnnic.cn>
> cc: dn= sop <dnsop@ietf.org>
> subject: = Re: [DNSOP] A new draft on SM2 digital signature algorithm for DNSSEC
> 
> On Mon, 11 Apr 2022, zhangcuiling wrote:
> 
> > And the main = purpose is to improve the diversity of DNSSEC algorithms, and to make it c= onvenient for people who want to use SM2
> > digital signature algorithm as an alternative for DNSSEC.
=
> 
&g= t; We actually want to prevent as much diversity as we can, to avoid
=
> creating more new long tails of deploymen= t of algorithms. So a new

That sounds reasonable. It does need additional wo= rk to support 
SM2 Digital Signatur= e Algorithm for DNS software implementation. 
The good news is that Openssl has supported it since version 1.1= .1. 
And I think Openssl is widely= used among DNS software.

> algorithm should really offer something the o= thers do not. Also having
> a number = of ECC based algorithms would likely mean if one ends up
> broken, all of them end up broken.
> 
> So bas= ed on:
> 
>   Due to the similarity between SM2 and ECDSA with curve P-2= 56, some
>   of the material in this docu= ment is copied liberally from RFC 6605
&g= t;   [RFC6605].
> 
> I don't see a strong reason to adopt another ECC ty= pe of algorithm.

Sorry that maybe I didn't make it clear. 

About SM2 and = ECDSA:
SM2 and ECDSA are similar in the= following aspects: the length of the 
private key (32 octets), public key (64 octets) and the signature =
(64 octets) are the same. 
But there is an important difference between thes= e two algorithms, 
which is the proc= ess of signature calculation. So SM2 is a different 
algorithm from ECDSA.
By the way, compared to a totally different algorithm, 
the similarity between SM2 and ECDSA can reduce the c= omplication of 
supporting SM2 to so= me extent.

About the security of ECC-based algorithms:
As far as I know, the security of ECC-based algorithms is stro= ngly 
influenced by the curve it us= es. Sometimes it's hard to say which 
secp256k1 (for blockchain) are relatively po= pular for ECDSA. 

SM2 uses a different curve and has different process = with the signature
generation and valid= ation, so I'd like to consider it as an alternative
to ECDSA.

> 
> Additi= onally, in this case SM2/SM3 seems to be ISO standards that are
> not freely available, so these are additionall= y problematic.
> 

I agree with you.= I should specify a document that could be downloaded freely.
Here is another one introducing SM2/SM3 in detail:
"Information security technology --- Public= key cryptographic algorithm 
SM2 b= ased on elliptic curves --- Part 2: Digital signature algorithm"
http://www.gmbz.org.cn/upload/2018-07-24/153240167= 3138056311.pdf
It's written in English, b= ut unfortunately it's not an international standard.
I will keep on trying to find a more proper document.

Thank you a= gain for your time and your helpful comment.

Best regards,

Cathy Zhang
------=_001_NextPart321488411677_=------ From nobody Tue Apr 12 03:42:46 2022 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 BD7513A1A36 for ; Tue, 12 Apr 2022 03:42:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.108 X-Spam-Level: X-Spam-Status: No, score=-2.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 14n9cPeOX6ct for ; Tue, 12 Apr 2022 03:42:36 -0700 (PDT) Received: from mail-yb1-xb34.google.com (mail-yb1-xb34.google.com [IPv6:2607:f8b0:4864:20::b34]) (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 79EF33A1A30 for ; Tue, 12 Apr 2022 03:42:36 -0700 (PDT) Received: by mail-yb1-xb34.google.com with SMTP id q19so1344993ybd.6 for ; Tue, 12 Apr 2022 03:42:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=an46Q/+ZHs0zAa/hBNulOlbN3KDxT4TVmv8L9a07gTM=; b=k005bbizkKw5lb0i2kdrcnXgMrqd1ll1L/uRt6LVQadsExNPcgLySU59mUz1o8aASZ c1gr8n+Nr3knpdMHV07f/An1I4YM3jYzbLoFt0SyrWTr+zjFUxcm2OhX8CSuYtGgbEBn VJxEDLcs1KqHza8iLzTWGDSj0Hn5u8rSGsKmcNXwXX4REIbalfyQU4jQPtIbUP5N81QU qGioXWy676nm6osZHqqhde/2hllx68mlOUNVrTaSP7T5gmysraLFBqGwO3FzudE4yjDG cvjihfJp/fom2vL48BpDnfz3Ipk9HFhJhwQxsMbzgCJwc4k+G3RyL8kCcsvrfIHjjsyT aYHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=an46Q/+ZHs0zAa/hBNulOlbN3KDxT4TVmv8L9a07gTM=; b=Z9SOPWCN4n9zdN3/x7scX/gK47ryFZsy83eReyg7MG06jNRkS7iO67nEUJFiAfKb7U Fn8+CoITFQEIttSC7waF8kpwN9RgsUlcX/Ch92XM+pv3h1YK/0n23VqWvIjN8SVkeYVo z6j3MF2Ve2hsOA1vPwWwFV/AoM+Mhiidyk+nQK7UGL78gAf7eZKfKhYGQMS7txk20W2D IG4N9qFYifXGB3UZCjp/TZ1OzkfgaWI+Bq18HF2ycZVi21KWKuXU7FsxOl1CjGAZI1X5 T5SIYAz98ltl5XPlEXZFElMD30lRvklf84/RHWAHrHKg/fIcioTunpQe3NtgOCqy0KUg IKhw== X-Gm-Message-State: AOAM532kCWMnSeIUrUXRVrVA5hiXl3Ootx2D7gfDcNCpdU+i19/cGis2 g9mojbayxrcWmNePi1OdUUmfH4E8FbhcnYSM9ds= X-Google-Smtp-Source: ABdhPJzMmuK9oqxA4j7BMyz9znvL0h+dm5W1gnt7O/1WFqwzHCksOdPRNeQ3U2zRONIFi91f2wBUnXkjIFi/fEv05Ms= X-Received: by 2002:a25:ccd7:0:b0:641:7c61:de91 with SMTP id l206-20020a25ccd7000000b006417c61de91mr4800865ybf.288.1649760154281; Tue, 12 Apr 2022 03:42:34 -0700 (PDT) MIME-Version: 1.0 References: <355263CA-10A6-4AED-8622-8336A94F069A@isc.org> In-Reply-To: <355263CA-10A6-4AED-8622-8336A94F069A@isc.org> From: =?UTF-8?Q?Eug=C3=A8ne_Adell?= Date: Tue, 12 Apr 2022 12:27:48 +0200 Message-ID: To: Mark Andrews , dwessels@verisign.com Cc: dnsop@ietf.org Content-Type: multipart/mixed; boundary="000000000000f6159205dc72b762" Archived-At: Subject: Re: [DNSOP] introducing a couple of RRTypes (CRC/CRS) for B2B applications X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2022 10:42:44 -0000 --000000000000f6159205dc72b762 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello, thanks for your constructive comments. My answers are just below, with an updated document (from Duane's remarks, Mark's ones will follow later). 1. Beyond the technical aspects, there are several different persons to think about in our case : the DNS administrator obviously, the decision maker buying (or not) a secured online service, and the CISO. It looks more simple to have dedicated RR types to let them communicate together, without any information distortion. It's necessary to explain that the CRS record can play two roles : of course being involved during the authorization mechanism, and as an information for existing or potential customers checking this mechanism support before subscribing to a new service. In that case, any decision maker or CISO can check by himself without sorting all the TXT records found. @Mark : I am just discovering the APL RR now as I didn't notice it when checking what could be reused. It fits the needs of the CRC, with a different syntax, and likely it's still potentially easier to identify when building an inventory of what CRC-CRS contracts an organization has. 2. I updated for compliance with RFC2606 & RFC5737 3. Updated so 4. After your comments and correcting a typo, it gives ftp.example.com_21.example.net Such domain name for sure doesn't exist and uses the underscore character as separator. It has to be considered as storing data establishing a kind of contract between the two organizations involved. 5. I give some explanation in the answer 1 but I will rephrase. The CRS record can be used before subscribing to a service (typically any storage/log system/SIEM) as an indicator that this service provides the kind of authorization process described in the document. More importantly, it can be checked by the application during the authentication to know if the client CRC must be checked or not. However, if an application doesn't want to rely on the CRS RR, it also can use a parameter in its configuration file. Maybe adding a schema would help ? At least, I tested all that prior to sending my first email, with NSD and a modified Apache Tomcat, and I got the results I wanted. Internet Engineering Task Force E. Adell Internet-Draft 12 April 2022 Intended status: Informational Expires: 14 October 2022 Client Roaming Control draft-adell-client-roaming-00 Abstract This document specifies the Client Roaming Control (CRC) DNS Resource Record allowing an organization to better control the access to third-party applications over Internet. The applications implementing an authorization mechanism to honor the CRC, publish on their side the Client Roaming Support (CRS) Resource Record to inform of this support. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 14 October 2022. Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Adell Expires 14 October 2022 [Page 1] Internet-Draft Client Roaming Control April 2022 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 3. The CRC Resource Record . . . . . . . . . . . . . . . . . . . 4 3.1. RR name field . . . . . . . . . . . . . . . . . . . . . . 4 3.2. CRC RDATA Wire Format . . . . . . . . . . . . . . . . . . 4 3.3. CRC Presentation Format . . . . . . . . . . . . . . . . . 4 4. The CRS Resource Record . . . . . . . . . . . . . . . . . . . 5 4.1. CRS RDATA Wire Format . . . . . . . . . . . . . . . . . . 5 4.2. CRS Presentation Format . . . . . . . . . . . . . . . . . 5 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.1. Restricted Application . . . . . . . . . . . . . . . . . 6 5.2. Controlled Application . . . . . . . . . . . . . . . . . 7 5.3. Opened Application . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7.1. DNS misconfiguration . . . . . . . . . . . . . . . . . . 9 7.2. DNS Security . . . . . . . . . . . . . . . . . . . . . . 10 7.3. Application Security . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 8.2. Informative References . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction Illegitimate access to professional restricted applications over Internet is a permanent threat for organizations and their staff. Different methods can be used to impersonate a user access, and in some cases an organization also wants to better prevent its own staff to access a third-party application from a network which is not under its control. On the contrary, an organization maybe wants to allow roaming then its users can access from different known places. The Client Roaming Control (CRC) DNS Resource Record (RR) acts as a White-List and informs a compatible application from which networks its users are allowed to connect, be it a limited list of networks or broadly without any restriction. Adell Expires 14 October 2022 [Page 2] Internet-Draft Client Roaming Control April 2022 At the application level, the identification of the user's organization domain can be based on an information carried during the authentication process, or a lookup on an information already known by the application. In both cases this information lets the application relate the user to its organization unequivocally. Finally, the corresponding user's domain DNS will be requested with the application's FQDN and port, and the application will know whether an authorization is expected or not. Some examples will be given in this document. The applications implementing this authorization control let the client organizations know this feature is available by using the Client Roaming Support (CRS) RR. The data associated with this record indicates if the client's organization expected support of the CRC is mandatory, optional, or ignored. This information stored in the CRS can be confirmed at the application level by a redundant data. The way the application handles the authorization mechanism, by consulting the associated CRS record or not, is left to the implementor. Although this mechanism is designed for improving the security between different organizations, there is no objection to use it for a same organization playing both roles of client and application , as an alternative or additional layer to a solution already in place, such as a firewall for example. 2. Conventions Used in This Document This specification uses definitions from Domain Name System [RFC1035], and readers unfamiliar with it can also check DNS Terminology [RFC8499]. The syntax specification uses the Augmented Backus-Naur Form (ABNF) notation as specified in [RFC5234], with some expressions being defined in "Uniform Resource Identifier (URI): Generic Syntax" [RFC3986] and "IP Version 6 Addressing Architecture" [RFC4291]. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Adell Expires 14 October 2022 [Page 3] Internet-Draft Client Roaming Control April 2022 3. The CRC Resource Record The CRC RR purpose is to provide a list of IP ranges authorized to use a particular application. Each RR contains a list of either IPv4 or IPv6 network address ranges. These ranges MUST follow the CIDR notation. A single CRC RR MAY contain ranges for different IP versions, but in the case of many ranges this can be difficult to read or maintain, so dedicating a record to each IP version or not is left to the administrator. Multiple RRs MAY be defined for a given IP version. 3.1. RR name field The CRC RR name field is composed of the third-party application domain, its port, followed by the fully qualified name inherent in this zone. These three components are separated by the underscore character. 3.2. CRC RDATA Wire Format The CRC RDATA wire format is encoded as follows: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / CRC / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ The CRC field contains a list of either IPv4 or IPv6 ranges separated by the comma character. 3.3. CRC Presentation Format The presentation format of the CRC record is: CRC (ip4netlist [,ip6netlist]) / ([ip4netlist,] ip6netlist) ip4netlist =3D ip4net *(,ip4net) ip4net =3D IPv4address "/" ip4range ip4range =3D DIGIT / "1" DIGIT / "2" DIGIT / "3" DIGIT %x30-32 ip6netlist =3D ip6net *(,ip6net) ip6net =3D (ipv6-address "/" prefix-length) Adell Expires 14 October 2022 [Page 4] Internet-Draft Client Roaming Control April 2022 4. The CRS Resource Record The CRS RR indicates which control is done on the client organizations, and thus which ones are authorized. A requirement field is used for this purpose, it has one of the following values meaning when the checking is performed : * "N" : Never, all organizations are authorized * "A" : Always, only organizations with a CRC are authorized * "O" : Optional, any organization CRC is honored, other organizations are authorized In addition to this value, an optional list of ports can be given. Indeed, multiple applications can be hosted on different ports under the same domain name, and an equivalent support was described for the CRC RR. In case of different requirement values, it is RECOMMENDED to have one dedicated RR for each although one single RR with all the information is supported. One particular port MUST NOT appear in more than one RR. When no port is mentioned, only one RR MAY be declared and its requirement value covers all applications for this domain name. In the absence of such record, no roaming control is to be expected by the client, any of its CRC RRs will be ignored. It is equivalent to a CRS requirement value indicating no control is performed. 4.1. CRS RDATA Wire Format The CRS RDATA wire format is encoded as follows: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / CRS / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ The CRS field contains a list of requirements followed by their respective optional ports. 4.2. CRS Presentation Format The presentation format of the CRS record is: CRS (single-rule / multiple-rules) single-rule =3D "R=3D" ("N" / "A" / "O") *(,port) Adell Expires 14 October 2022 [Page 5] Internet-Draft Client Roaming Control April 2022 multiple-rules =3D unit-rule 1*2(;unit-rule) unit-rule =3D "R=3D" ("N" / "A" / "O") 1*(,port) port =3D [1-9] *([DIGIT]) 5. Examples The following examples show some typical uses expected from this documentation. Particularly, the intended behaviors for different CRC and CRS values are explained, while the user identification is done directly through carried data or a deduction process. 5.1. Restricted Application In this example, an application is only opened to organizations publishing their respective allowed networks. The requirement value of the CRS record equals "A", and any organization with an empty or missing CRC for this application will be denied access. The ftp.example.com domain is dedicated to hosting an FTP application, which extracts the client's domain from the username used during the authentication process. This information is then used for requesting the client CRC record and finally comparing its content with the client's IP. The client organization example.net allows its users from its own network 192.0.2.0/24 and from a cloud service located at 198.51.100.0/24. A second organization example.org has no CRC record and its users are rejected. Application FQDN : ftp.example.com Application CRS record : ftp.example.com. IN CRS R=3DA,21 Client FQDN : example.net Client organization CRC record : ftp.example.com_21.example.net. IN CRC 192.0.2.0/24,198.51.100.0/24 Client FQDN : example.org No client organization CRC record Adell Expires 14 October 2022 [Page 6] Internet-Draft Client Roaming Control April 2022 Client DNS Client FTP Server FTP FTP USER me@example.net -----------------------------> ... FTP PASS ******** -----------------------------> Query : CRC ftp.example.com_21.example.net <------------------------------------ Answer : CRC ftp.example.com_21.example.net 192.0.2.0/24,198.51.100.0/24 ------------------------------------> FTP 230 <------------------------------ FTP USER me@example.org -----------------------------> ... FTP PASS ******** -----------------------------> Query : CRC ftp.example.com_21.example.org <------------------------------------ Answer : No such name (3) ------------------------------------> FTP 430 <------------------------------ 5.2. Controlled Application The www.example.com domain hosts a Web application on port 443 using client certificates for authenticating its users. The application extracts the client domains from the certificates, which are used to retrieve their CRC records. Users from the example.net organization are allowed only if they connect from an authorized network listed in the CRC record, while users from example.org are always granted access since this one has no CRC declared. Application FQDN : www.example.com Application CRS record : www.example.com. IN CRS R=3DO,443 Client FQDN : example.net Client organization CRC record : www.example.com_443.example.net. IN CRC 192.0.2.0/24,198.51.100.0/24 Client FQDN : example.org No client organization CRC record Adell Expires 14 October 2022 [Page 7] Internet-Draft Client Roaming Control April 2022 Client DNS Client browser Web application ..... Client certificate me@example.net -----------------------------------> Query : CRC www.example.com_443.example.net <------------------------------------------ Answer : CRC www.example.com_443.example.net 192.0.2.0/24,198.51.100.0/24 ------------------------------------------> ..... 200 OK <----------------------------------- ..... Client certificate me@example.org -----------------------------------> Query : CRC www.example.com_443.example.org <------------------------------------------ Answer : No such name (3) ------------------------------------------> ..... 200 OK <----------------------------------- 5.3. Opened Application A company is testing the CRC and CRS behaviors before opening a new service to its customers. Its first test described below consists in configuring both sides to be completely opened, likely before hardening the CRS, then the CRC, and testing again. The application.example.com domain hosts a Web application on port 443 where users are logged in by sending a numerical identifier and a password. The application uses a dictionary data type to identify the user's domain. The client.example.net domain is temporarily using 2 CRC records indicating a free access from anywhere. Application FQDN : application.example.com Application CRS record : application.example.com. IN CRS R=3DN,443 Client FQDN : client.example.net Client organization CRC records : application.example.com_443.example.net. IN CRC 0.0.0.0/24 application.example.com_443.example.net. IN CRC fe80::/10 Adell Expires 14 October 2022 [Page 8] Internet-Draft Client Roaming Control April 2022 Client DNS Client browser Web application ..... HTTP POST 123456/****** -----------------------------------> 200 OK <----------------------------------- 6. IANA Considerations According to Guidelines for Writing an IANA Considerations Section in RFCs [RFC8126] it is asked to IANA to add into the Resource Record (RR) TYPEs registry located at https://www.iana.org/assignments/dns- parameters/dns-parameters.xhtml#dns-parameters-4 the two entries CRC and CRS. +------+-------+------------------------+-----------+ | TYPE | Value | Description | Reference | +------+-------+------------------------+-----------+ | CRC | TBD1 | Client Roaming Control | this RFC | +------+-------+------------------------+-----------+ | CRS | TBD2 | Client Roaming Support | this RFC | +------+-------+------------------------+-----------+ Table 1 7. Security Considerations This section is meant to inform developers and users of the security implications of the CRC/CRS mechanism described by this document. While the CRS RR mostly plays an informative role, the CRC RR delivers important data which requires attention from the developers and administrators. Some particular points are discussed here. 7.1. DNS misconfiguration Any DNS CRS misconfiguration such as multiple records with different requirement values but with the same port value can get a client confused. In this case the client does not know without testing the actual configuration, if its organization is protected against roaming, and contacting the application administrator to fix the situation is a possibility. While CRC misconfigurations are more or less leading to serious security problems, administrators need to pay attention when dealing with multiple networks or records. Particularly, multiple records for the same network range or overlapping networks should be avoided. Adell Expires 14 October 2022 [Page 9] Internet-Draft Client Roaming Control April 2022 7.2. DNS Security Client and application administrators need to pay as much attention as they usually do when dealing with DNS management. As the CRC records are supposed to be requested during an application authentication process, reflection attacks could be built to target a client organization, even one not hosting any CRC record at all. In a general manner, administrators may consider an adequate TTL setting to not overload client organizations, enable TCP as the preferred transport, or rely on DNSSEC to warrant data authenticity and integrity. 7.3. Application Security The following points are of concern to developers: Encryption: Whenever possible, the application protocol should be encrypted to prevent eavesdropping and man-in-the-middle attacks. It is a critical point for applications maintaining a user session with anything like a token or cookie, as it can lead to session hijacking as discussed below. Timing attack: All authentication systems need to be careful to not deliver any information derived from the computing time to a denied user, even the ones involving multiple factors or steps like the one described in this document. In particular, the order in which these steps are executed and their respective implementations, need to defeat statistical hypotheses. Intermediate systems: Some applications are not directly Internet facing and cannot access to the real client's IP address without involving a mechanism to forward this IP at the application layer. For example with HTTP, the common practice based on the non-standard X-Forwarded-For header, or its alternative standard Forwarded [RFC7239], are playing this role. Such practice requires a correct sanitizing of user data to avoid false injected IPs. Session hijacking: A well-known attack called Session Hijacking is not meant to be defeated by this document alone. Application developers must ensure that any receveid session token, such as an HTTP Cookie, belongs to the same IP address than the one which started this session. 8. References Adell Expires 14 October 2022 [Page 10] Internet-Draft Client Roaming Control April 2022 8.1. Normative References [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, . [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, . [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 8.2. Informative References [RFC7239] Petersson, A. and M. Nilsson, "Forwarded HTTP Extension", RFC 7239, DOI 10.17487/RFC7239, June 2014, . [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, January 2019, . Author's Address Eugene Adell Email: eugene.adell@gmail.com Adell Expires 14 October 2022 [Page 11] Le mar. 12 avr. 2022 =C3=A0 02:44, Mark Andrews a =C3=A9cri= t : > > > > > On 11 Apr 2022, at 17:57, Mark Andrews wrote: > > > > I don=E2=80=99t see why APL (RFC 3123) can=E2=80=99t be used for CRC gi= ve you need to construct an > > owner name anyway and have well known label to seperate the components = of the name. > > I see no reason to re-invent the wheel here. > > > > ftp.foo.com_21_bar.com,195.13.35.0/24,91.220.43.0/24 > > > > would be > > > > ftp.foo.com._21._crc.bar.com APL 1:195.13.35.0/24 1:91.220.43.0/24 > > > Additionally text is a really bad way to transmit IP address and prefixes > in the DNS. DNS RRsets are resource constrained (maximum < 64k). DNS ca= ches > are resource constrained. 10-16 octets of text for an IPv4/24 vs 7 octet= s for APL. > An IPv4/8 is 9-11 vs 5 octets. The :: improves this a little bit for IPv= 6 but in > general you will be dealing with /48=E2=80=99s or longer xxxx:xxxx:xxxx::= /48 (19 octets) > vs 10 for APL. > > >> On 5 Apr 2022, at 20:52, Eug=C3=A8ne Adell wr= ote: > >> > >> Hello, > >> > >> I've been working on two new RRTypes described by a Draft, and as > >> suggested by our magnificent, incredibly brilliant and handsome AD > >> Warren "ACE" Kumari, I am posting here this idea and the material I > >> have written so far (the draft itself, and RFC 6895 components). > >> > >> Briefly, one RRType (CRC : Client Roaming Control) contains a > >> whitelist of networks allowing a company employees to connect to a > >> specific application. The second RRType (CRS : Client Roaming Support) > >> is on the application side and informs what kind of restrictions are > >> applied (by saying if CRC is mandatory, optional or ignored). > >> This is not expected to be deployed broadly and everywhere as it is > >> designed to secure Business-To-Business applications. > >> > >> The material (text XML2RFC draft + RFC 6895 components) written is > >> both incorporated below to this email and attached, for practical > >> reasons. > >> > >> > >> Regards > >> E.A. > >> > >> > >> > >> > >> > >> Internet Engineering Task Force E. Ade= ll > >> Internet-Draft 5 April 20= 22 > >> Intended status: Informational > >> Expires: 7 October 2022 > >> > >> > >> Client Roaming Control > >> draft-adell-client-roaming-00 > >> > >> Abstract > >> > >> This document specifies the Client Roaming Control (CRC) DNS Resource > >> Record allowing an organization to better control the access to > >> third-party applications over Internet. The applications > >> implementing an authorization mechanism to honor the CRC, publish on > >> their side the Client Roaming Support (CRS) Resource Record to inform > >> of this support. > >> > >> Status of This Memo > >> > >> This Internet-Draft is submitted in full conformance with the > >> provisions of BCP 78 and BCP 79. > >> > >> Internet-Drafts are working documents of the Internet Engineering > >> Task Force (IETF). Note that other groups may also distribute > >> working documents as Internet-Drafts. The list of current Internet- > >> Drafts is at https://datatracker.ietf.org/drafts/current/. > >> > >> Internet-Drafts are draft documents valid for a maximum of six months > >> and may be updated, replaced, or obsoleted by other documents at any > >> time. It is inappropriate to use Internet-Drafts as reference > >> material or to cite them other than as "work in progress." > >> > >> This Internet-Draft will expire on 7 October 2022. > >> > >> Copyright Notice > >> > >> Copyright (c) 2022 IETF Trust and the persons identified as the > >> document authors. All rights reserved. > >> > >> This document is subject to BCP 78 and the IETF Trust's Legal > >> Provisions Relating to IETF Documents (https://trustee.ietf.org/ > >> license-info) in effect on the date of publication of this document. > >> Please review these documents carefully, as they describe your rights > >> and restrictions with respect to this document. Code Components > >> extracted from this document must include Revised BSD License text as > >> described in Section 4.e of the Trust Legal Provisions and are > >> provided without warranty as described in the Revised BSD License. > >> > >> > >> > >> Adell Expires 7 October 2022 [Page = 1] > >> > >> Internet-Draft Client Roaming Control April 20= 22 > >> > >> > >> Table of Contents > >> > >> 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 > >> 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 > >> 3. The CRC Resource Record . . . . . . . . . . . . . . . . . . . 4 > >> 3.1. RR name field . . . . . . . . . . . . . . . . . . . . . . 4 > >> 3.2. CRC RDATA Wire Format . . . . . . . . . . . . . . . . . . 4 > >> 3.3. CRC Presentation Format . . . . . . . . . . . . . . . . . 4 > >> 4. The CRS Resource Record . . . . . . . . . . . . . . . . . . . 5 > >> 4.1. CRS RDATA Wire Format . . . . . . . . . . . . . . . . . . 5 > >> 4.2. CRS Presentation Format . . . . . . . . . . . . . . . . . 5 > >> 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 6 > >> 5.1. Restricted Application . . . . . . . . . . . . . . . . . 6 > >> 5.2. Controlled Application . . . . . . . . . . . . . . . . . 7 > >> 5.3. Opened Application . . . . . . . . . . . . . . . . . . . 8 > >> 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 > >> 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 > >> 7.1. DNS misconfiguration . . . . . . . . . . . . . . . . . . 9 > >> 7.2. DNS Security . . . . . . . . . . . . . . . . . . . . . . 10 > >> 7.3. Application Security . . . . . . . . . . . . . . . . . . 10 > >> 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 > >> 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 > >> 8.2. Informative References . . . . . . . . . . . . . . . . . 11 > >> Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 > >> > >> 1. Introduction > >> > >> Illegitimate access to professional restricted applications over > >> Internet is a permanent threat for organizations and their staff. > >> Different methods can be used to impersonate a user access, and in > >> some cases an organization also wants to better prevent its own staff > >> to access a third-party application from a network which is not under > >> its control. On the contrary, an organization maybe wants to allow > >> roaming then its users can access from different known places. > >> > >> The Client Roaming Control (CRC) DNS Resource Record (RR) acts as a > >> White-List and informs a compatible application from which networks > >> its users are allowed to connect, be it a limited list of networks or > >> broadly without any restriction. > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> Adell Expires 7 October 2022 [Page = 2] > >> > >> Internet-Draft Client Roaming Control April 20= 22 > >> > >> > >> At the application level, the identification of the user's > >> organization domain can be based on an information carried during the > >> authentication process, or a lookup on an information already known > >> by the application. In both cases this information lets the > >> application relate the user to its organization unequivocally. > >> Finally, the corresponding user's domain DNS will be requested with > >> the application's FQDN and port, and the application will know > >> whether an authorization is expected or not. Some examples will be > >> given in this document. > >> > >> The applications implementing this authorization control let the > >> client organizations know this feature is available by using the > >> Client Roaming Support (CRS) RR. The data associated with this > >> record indicates if the client's organization expected support of the > >> CRC is mandatory, optional, or ignored. This information stored in > >> the CRS can be confirmed at the application level by a redundant > >> data. The way the application handles the authorization mechanism, > >> by consulting the associated CRS record or not, is left to the > >> implementor. > >> > >> Although this mechanism is designed for improving the security > >> between different organizations, there is no objection to use it for > >> a same organization playing both roles of client and application , as > >> an alternative or additional layer to a solution already in place, > >> such as a firewall for example. > >> > >> 2. Conventions Used in This Document > >> > >> This specification uses definitions from Domain Name System > >> [RFC1035], and readers unfamiliar with it can also check DNS > >> Terminology [RFC8499]. The syntax specification uses the Augmented > >> Backus-Naur Form (ABNF) notation as specified in [RFC5234], with some > >> expressions being defined in "Uniform Resource Identifier (URI): > >> Generic Syntax" [RFC3986] and "IP Version 6 Addressing Architecture" > >> [RFC4291]. > >> > >> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > >> "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and > >> "OPTIONAL" in this document are to be interpreted as described in BCP > >> 14 [RFC2119] [RFC8174] when, and only when, they appear in all > >> capitals, as shown here. > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> Adell Expires 7 October 2022 [Page = 3] > >> > >> Internet-Draft Client Roaming Control April 20= 22 > >> > >> > >> 3. The CRC Resource Record > >> > >> The CRC RR purpose is to provide a list of IP ranges authorized to > >> use a particular application. Each RR contains a list of either IPv4 > >> or IPv6 network address ranges. These ranges MUST follow the CIDR > >> notation. A single CRC RR MAY contain ranges for different IP > >> versions, but in the case of many ranges this can be difficult to > >> read or maintain, so dedicating a record to each IP version or not is > >> left to the administrator. Multiple RRs MAY be defined for a given > >> IP version. > >> > >> 3.1. RR name field > >> > >> The CRC RR name field is composed of the third-party application > >> domain, its port, followed by the fully qualified name inherent in > >> this zone. These three components are separated by the underscore > >> character. > >> > >> 3.2. CRC RDATA Wire Format > >> > >> The CRC RDATA wire format is encoded as follows: > >> > >> +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ > >> / CRC / > >> / / > >> +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ > >> > >> The CRC field contains a list of either IPv4 or IPv6 ranges separated > >> by the comma character. > >> > >> 3.3. CRC Presentation Format > >> > >> The presentation format of the CRC record is: > >> > >> CRC (ip4netlist [,ip6netlist]) / ([ip4netlist,] ip6netlist) > >> > >> ip4netlist =3D ip4net *(,ip4net) > >> > >> ip4net =3D IPv4address "/" ip4range > >> > >> ip4range =3D DIGIT / "1" DIGIT / "2" DIGIT / "3" DIGIT %x30-32 > >> > >> ip6netlist =3D ip6net *(,ip6net) > >> > >> ip6net =3D (ipv6-address "/" prefix-length) > >> > >> > >> > >> > >> > >> > >> Adell Expires 7 October 2022 [Page = 4] > >> > >> Internet-Draft Client Roaming Control April 20= 22 > >> > >> > >> 4. The CRS Resource Record > >> > >> The CRS RR indicates which control is done on the client > >> organizations, and thus which ones are authorized. A requirement > >> field is used for this purpose, it has one of the following values > >> meaning when the checking is performed : > >> > >> * "N" : Never, all organizations are authorized > >> > >> * "A" : Always, only organizations with a CRC are authorized > >> > >> * "O" : Optional, any organization CRC is honored, other > >> organizations are authorized > >> > >> In addition to this value, an optional list of ports can be given. > >> Indeed, multiple applications can be hosted on different ports under > >> the same domain name, and an equivalent support was described for the > >> CRC RR. In case of different requirement values, it is RECOMMENDED > >> to have one dedicated RR for each although one single RR with all the > >> information is supported. One particular port MUST NOT appear in > >> more than one RR. When no port is mentioned, only one RR MAY be > >> declared and its requirement value covers all applications for this > >> domain name. > >> > >> In the absence of such record, no roaming control is to be expected > >> by the client, any of its CRC RRs will be ignored. It is equivalent > >> to a CRS requirement value indicating no control is performed. > >> > >> 4.1. CRS RDATA Wire Format > >> > >> The CRS RDATA wire format is encoded as follows: > >> > >> +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ > >> / CRS / > >> / / > >> +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ > >> > >> The CRS field contains a list of requirements followed by their > >> respective optional ports. > >> > >> 4.2. CRS Presentation Format > >> > >> The presentation format of the CRS record is: > >> > >> CRS (single-rule / multiple-rules) > >> > >> single-rule =3D "R=3D" ("N" / "A" / "O") *(,port) > >> > >> > >> > >> > >> Adell Expires 7 October 2022 [Page = 5] > >> > >> Internet-Draft Client Roaming Control April 20= 22 > >> > >> > >> multiple-rules =3D unit-rule 1*2(;unit-rule) > >> > >> unit-rule =3D "R=3D" ("N" / "A" / "O") 1*(,port) > >> > >> port =3D [1-9] *([DIGIT]) > >> > >> 5. Examples > >> > >> The following examples show some typical uses expected from this > >> documentation. Particularly, the intended behaviors for different > >> CRC and CRS values are explained, while the user identification is > >> done directly through carried data or a deduction process. > >> > >> 5.1. Restricted Application > >> > >> In this example, an application is only opened to organizations > >> publishing their respective allowed networks. The requirement value > >> of the CRS record equals "A", and any organization with an empty or > >> missing CRC for this application will be denied access. > >> > >> The ftp.foo.com domain is dedicated to hosting an FTP application, > >> which extracts the client's domain from the username used during the > >> authentication process. This information is then used for requesting > >> the client CRC record and finally comparing its content with the > >> client's IP. The client organization bar.com allows its users from > >> its own network 195.13.35.0/24 and from a cloud service located at > >> 91.220.43.0/24. A second organization baz.com has no CRC record and > >> its users are rejected. > >> > >> Application FQDN : ftp.foo.com > >> Application CRS record : CRS R=3DA,21 > >> > >> Client FQDN : bar.com > >> Client organization CRC record : CRC > >> ftp.foo.com_21_bar.com,195.13.35.0/24,91.220.43.0/24 > >> > >> Client FQDN : baz.com > >> No client organization CRC record > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> Adell Expires 7 October 2022 [Page = 6] > >> > >> Internet-Draft Client Roaming Control April 20= 22 > >> > >> > >> Client DNS Client FTP Server FTP > >> > >> FTP USER me@bar.com > >> -----------------------------> > >> ... > >> FTP PASS ******** > >> -----------------------------> > >> Query : CRC ftp.foo.com_21_bar.com > >> <------------------------------------ > >> Answer : CRC ftp.foo.com_21_bar.com,195.13.35.0/24,91.220.43.0= /24 > >> ------------------------------------> > >> FTP 230 > >> <------------------------------ > >> > >> > >> FTP USER me@baz.com > >> -----------------------------> > >> ... > >> FTP PASS ******** > >> -----------------------------> > >> Query : CRC ftp.foo.com_21_baz.com > >> <------------------------------------ > >> Answer : No such name (3) > >> ------------------------------------> > >> FTP 430 > >> <------------------------------ > >> > >> 5.2. Controlled Application > >> > >> The foo.com domain hosts a Web application on port 443 using client > >> certificates for authenticating its users. The application extracts > >> the client domains from the certificates, which are used to retrieve > >> their CRC records. Users from the bar.com organization are allowed > >> only if they connect from an authorized network listed in the CRC > >> record, while users from baz.com are always granted access since this > >> one has no CRC declared. > >> > >> Application FQDN : foo.com > >> Application CRS record : CRS R=3DA,443 > >> > >> Client FQDN : bar.com > >> Client organization CRC record : CRC > >> ftp.foo.com_443_bar.com,195.13.35.0/24,91.220.43.0/24 > >> > >> Client FQDN : baz.com > >> No client organization CRC record > >> > >> > >> > >> > >> > >> Adell Expires 7 October 2022 [Page = 7] > >> > >> Internet-Draft Client Roaming Control April 20= 22 > >> > >> > >> Client DNS Client browser Web application > >> > >> > >> ..... > >> Client certificate me@bar.com > >> -----------------------------------> > >> Query : CRC foo.com_443_bar.com > >> <------------------------------------------ > >> Answer : CRC foo.com_443_bar.com,195.13.35.0/24,91.220.43.0/24 > >> ------------------------------------------> > >> ..... > >> 200 OK > >> <----------------------------------- > >> > >> > >> ..... > >> Client certificate me@baz.com > >> -----------------------------------> > >> Query : CRC foo.com_443_baz.com > >> <------------------------------------------ > >> Answer : No such name (3) > >> ------------------------------------------> > >> ..... > >> 200 OK > >> <----------------------------------- > >> > >> 5.3. Opened Application > >> > >> A company is testing the CRC and CRS behaviors before opening a new > >> service to its customers. Its first test described below consists in > >> configuring both sides to be completely opened, likely before > >> hardening the CRS, then the CRC, and testing again. > >> > >> The application.foo.com domain hosts a Web application on port 443 > >> where users are logged in by sending a numerical identifier and a > >> password. The application uses a dictionary data type to identify > >> the user's domain. The client.foo.com domain is temporarily using 2 > >> CRC records indicating a free access from anywhere. > >> > >> Application FQDN : application.foo.com > >> Application CRS record : CRS R=3DN,443 > >> > >> Client FQDN : client.foo.com > >> Client organization CRC records : CRC > >> application.foo.com_443_foo.com,0.0.0.0/24; CRC > >> application.foo.com_443_foo.com,fe80::/10 > >> > >> > >> > >> > >> > >> Adell Expires 7 October 2022 [Page = 8] > >> > >> Internet-Draft Client Roaming Control April 20= 22 > >> > >> > >> Client DNS Client browser Web application > >> > >> > >> ..... > >> HTTP POST 123456/****** > >> -----------------------------------> > >> 200 OK > >> <----------------------------------- > >> > >> 6. IANA Considerations > >> > >> According to Guidelines for Writing an IANA Considerations Section in > >> RFCs [RFC8126] it is asked to IANA to add into the Resource Record > >> (RR) TYPEs registry located at https://www.iana.org/assignments/dns- > >> parameters/dns-parameters.xhtml#dns-parameters-4 the two entries CRC > >> and CRS. > >> > >> +------+-------+------------------------+-----------+ > >> | TYPE | Value | Description | Reference | > >> +------+-------+------------------------+-----------+ > >> | CRC | TBD1 | Client Roaming Control | this RFC | > >> +------+-------+------------------------+-----------+ > >> | CRS | TBD2 | Client Roaming Support | this RFC | > >> +------+-------+------------------------+-----------+ > >> > >> Table 1 > >> > >> 7. Security Considerations > >> > >> This section is meant to inform developers and users of the security > >> implications of the CRC/CRS mechanism described by this document. > >> While the CRS RR mostly plays an informative role, the CRC RR > >> delivers important data which requires attention from the developers > >> and administrators. Some particular points are discussed here. > >> > >> 7.1. DNS misconfiguration > >> > >> Any DNS CRS misconfiguration such as multiple records with different > >> requirement values but with the same port value can get a client > >> confused. In this case the client does not know without testing the > >> actual configuration, if its organization is protected against > >> roaming, and contacting the application administrator to fix the > >> situation is a possibility. > >> > >> While CRC misconfigurations are more or less leading to serious > >> security problems, administrators need to pay attention when dealing > >> with multiple networks or records. Particularly, multiple records > >> for the same network range or overlapping networks should be avoided. > >> > >> > >> > >> Adell Expires 7 October 2022 [Page = 9] > >> > >> Internet-Draft Client Roaming Control April 20= 22 > >> > >> > >> 7.2. DNS Security > >> > >> Client and application administrators need to pay as much attention > >> as they usually do when dealing with DNS management. As the CRC > >> records are supposed to be requested during an application > >> authentication process, reflection attacks could be built to target a > >> client organization, even one not hosting any CRC record at all. > >> In a general manner, administrators may consider an adequate TTL > >> setting to not overload client organizations, enable TCP as the > >> preferred transport, or rely on DNSSEC to warrant data authenticity > >> and integrity. > >> > >> 7.3. Application Security > >> > >> The following points are of concern to developers: > >> > >> Encryption: > >> Whenever possible, the application protocol should be encrypted to > >> prevent eavesdropping and man-in-the-middle attacks. It is a > >> critical point for applications maintaining a user session with > >> anything like a token or cookie, as it can lead to session hijacking > >> as discussed below. > >> > >> Timing attack: > >> All authentication systems need to be careful to not deliver any > >> information derived from the computing time to a denied user, even > >> the ones involving multiple factors or steps like the one described > >> in this document. In particular, the order in which these steps are > >> executed and their respective implementations, need to defeat > >> statistical hypotheses. > >> > >> Intermediate systems: > >> Some applications are not directly Internet facing and cannot access > >> to the real client's IP address without involving a mechanism to > >> forward this IP at the application layer. For example with HTTP, the > >> common practice based on the non-standard X-Forwarded-For header, or > >> its alternative standard Forwarded [RFC7239], are playing this role. > >> Such practice requires a correct sanitizing of user data to avoid > >> false injected IPs. > >> > >> Session hijacking: > >> A well-known attack called Session Hijacking is not meant to be > >> defeated by this document alone. Application developers must ensure > >> that any receveid session token, such as an HTTP Cookie, belongs to > >> the same IP address than the one which started this session. > >> > >> 8. References > >> > >> > >> > >> > >> Adell Expires 7 October 2022 [Page 1= 0] > >> > >> Internet-Draft Client Roaming Control April 20= 22 > >> > >> > >> 8.1. Normative References > >> > >> [RFC1035] Mockapetris, P., "Domain names - implementation and > >> specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, > >> November 1987, . > >> > >> [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate > >> Requirement Levels", BCP 14, RFC 2119, > >> DOI 10.17487/RFC2119, March 1997, > >> . > >> > >> [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform > >> Resource Identifier (URI): Generic Syntax", STD 66, > >> RFC 3986, DOI 10.17487/RFC3986, January 2005, > >> . > >> > >> [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing > >> Architecture", RFC 4291, DOI 10.17487/RFC4291, February > >> 2006, . > >> > >> [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax > >> Specifications: ABNF", STD 68, RFC 5234, > >> DOI 10.17487/RFC5234, January 2008, > >> . > >> > >> [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC > >> 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, > >> May 2017, . > >> > >> 8.2. Informative References > >> > >> [RFC7239] Petersson, A. and M. Nilsson, "Forwarded HTTP Extension", > >> RFC 7239, DOI 10.17487/RFC7239, June 2014, > >> . > >> > >> [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS > >> Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, > >> January 2019, . > >> > >> Author's Address > >> > >> Eugene Adell > >> Email: eugene.adell@gmail.com > >> > >> > >> > >> > >> > >> > >> > >> > >> Adell Expires 7 October 2022 [Page 1= 1] > >> > >> > >> RFC 6895 : > >> A. Submission Date:2002/04/05 > >> B.1 Submission Type: [X] New RRTYPE [ ] Modification to RRTYPE > >> B.2 Kind of RR: [X] Data RR [ ] Meta-RR > >> C. Contact Information for submitter : > >> Name: Eugene Adell Email Address: eugene.adell@gmail.co= m > >> International telephone number: +33699056914 > >> Other contact handles: > >> D. Motivation for the new RRTYPE application. > >> Introduce a couple of RR types working together in order to better > >> secure remote access to partner applications > >> E. Description of the proposed RR type. > >> CRC contains a limited list of authorized networks for a particular > >> application > >> F. What existing RRTYPE or RRTYPEs come closest to filling that need > >> and why are they unsatisfactory? > >> TXT RRTYPE allows the storage of any text data but in practice is > >> usually associated with more or less fixed name or data which is not > >> what is needed here. A dedicated RRTYPE is easier to identify and > >> manage by a security team other than the usual DNS operator team. > >> G. What mnemonic is requested for the new RRTYPE (optional)? > >> CRC > >> H. Does the requested RRTYPE make use of any existing IANA registry or > >> require the creation of a new IANA subregistry in DNS Parameters? > >> It uses the existing Resource Record (RR) TYPEs registry > >> I. Does the proposal require/expect any changes in DNS > >> servers/resolvers that prevent the new type from being processed as an > >> unknown RRTYPE (see [RFC3597])? > >> No > >> J. Comments: > >> None > >> > >> > >> A. Submission Date:2002/04/05 > >> B.1 Submission Type: [X] New RRTYPE [ ] Modification to RRTYPE > >> B.2 Kind of RR: [X] Data RR [ ] Meta-RR > >> C. Contact Information for submitter : > >> Name: Eugene Adell Email Address: eugene.adell@gmail.co= m > >> International telephone number: +33699056914 > >> Other contact handles: > >> D. Motivation for the new RRTYPE application. > >> Introduce a couple of RR types working together in order to better > >> secure remote access to partner applications > >> E. Description of the proposed RR type. > >> CRS contains a requirement value and a list of ports indicating > >> what kind of authorization check is done during the application > >> authentication process > >> F. What existing RRTYPE or RRTYPEs come closest to filling that need > >> and why are they unsatisfactory? > >> TXT RRTYPE allows the storage of any text data but in practice is > >> usually associated with more or less fixed name or data which is not > >> what is needed here. A dedicated RRTYPE is easier to identify and > >> manage by a security team other than the usual DNS operator team. > >> G. What mnemonic is requested for the new RRTYPE (optional)? > >> CRS > >> H. Does the requested RRTYPE make use of any existing IANA registry or > >> require the creation of a new IANA subregistry in DNS Parameters? > >> It uses the existing Resource Record (RR) TYPEs registry > >> I. Does the proposal require/expect any changes in DNS > >> servers/resolvers that prevent the new type from being processed as an > >> unknown RRTYPE (see [RFC3597])? > >> No > >> J. Comments: > >> None > >> ____________= ___________________________________ > >> 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 > > > > _______________________________________________ > > 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 > --000000000000f6159205dc72b762 Content-Type: text/plain; charset="US-ASCII"; name="draft-adell-client-roaming-01.txt" Content-Disposition: attachment; filename="draft-adell-client-roaming-01.txt" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_l1w01mic0 CgoKCkludGVybmV0IEVuZ2luZWVyaW5nIFRhc2sgRm9yY2UgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBFLiBBZGVsbApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIDEyIEFwcmlsIDIwMjIKSW50ZW5kZWQgc3RhdHVzOiBJbmZv cm1hdGlvbmFsICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCkV4cGly ZXM6IDE0IE9jdG9iZXIgMjAyMgoKCiAgICAgICAgICAgICAgICAgICAgICAgICBDbGllbnQgUm9h bWluZyBDb250cm9sCiAgICAgICAgICAgICAgICAgICAgIGRyYWZ0LWFkZWxsLWNsaWVudC1yb2Ft aW5nLTAwCgpBYnN0cmFjdAoKICAgVGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgdGhlIENsaWVudCBS b2FtaW5nIENvbnRyb2wgKENSQykgRE5TIFJlc291cmNlCiAgIFJlY29yZCBhbGxvd2luZyBhbiBv cmdhbml6YXRpb24gdG8gYmV0dGVyIGNvbnRyb2wgdGhlIGFjY2VzcyB0bwogICB0aGlyZC1wYXJ0 eSBhcHBsaWNhdGlvbnMgb3ZlciBJbnRlcm5ldC4gIFRoZSBhcHBsaWNhdGlvbnMKICAgaW1wbGVt ZW50aW5nIGFuIGF1dGhvcml6YXRpb24gbWVjaGFuaXNtIHRvIGhvbm9yIHRoZSBDUkMsIHB1Ymxp c2ggb24KICAgdGhlaXIgc2lkZSB0aGUgQ2xpZW50IFJvYW1pbmcgU3VwcG9ydCAoQ1JTKSBSZXNv dXJjZSBSZWNvcmQgdG8gaW5mb3JtCiAgIG9mIHRoaXMgc3VwcG9ydC4KClN0YXR1cyBvZiBUaGlz IE1lbW8KCiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgaXMgc3VibWl0dGVkIGluIGZ1bGwgY29uZm9y bWFuY2Ugd2l0aCB0aGUKICAgcHJvdmlzaW9ucyBvZiBCQ1AgNzggYW5kIEJDUCA3OS4KCiAgIElu dGVybmV0LURyYWZ0cyBhcmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2lu ZWVyaW5nCiAgIFRhc2sgRm9yY2UgKElFVEYpLiAgTm90ZSB0aGF0IG90aGVyIGdyb3VwcyBtYXkg YWxzbyBkaXN0cmlidXRlCiAgIHdvcmtpbmcgZG9jdW1lbnRzIGFzIEludGVybmV0LURyYWZ0cy4g IFRoZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJuZXQtCiAgIERyYWZ0cyBpcyBhdCBodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RyYWZ0cy9jdXJyZW50Ly4KCiAgIEludGVybmV0LURyYWZ0cyBh cmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4IG1vbnRocwogICBh bmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1l bnRzIGF0IGFueQogICB0aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQt RHJhZnRzIGFzIHJlZmVyZW5jZQogICBtYXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhh biBhcyAid29yayBpbiBwcm9ncmVzcy4iCgogICBUaGlzIEludGVybmV0LURyYWZ0IHdpbGwgZXhw aXJlIG9uIDE0IE9jdG9iZXIgMjAyMi4KCkNvcHlyaWdodCBOb3RpY2UKCiAgIENvcHlyaWdodCAo YykgMjAyMiBJRVRGIFRydXN0IGFuZCB0aGUgcGVyc29ucyBpZGVudGlmaWVkIGFzIHRoZQogICBk b2N1bWVudCBhdXRob3JzLiAgQWxsIHJpZ2h0cyByZXNlcnZlZC4KCiAgIFRoaXMgZG9jdW1lbnQg aXMgc3ViamVjdCB0byBCQ1AgNzggYW5kIHRoZSBJRVRGIFRydXN0J3MgTGVnYWwKICAgUHJvdmlz aW9ucyBSZWxhdGluZyB0byBJRVRGIERvY3VtZW50cyAoaHR0cHM6Ly90cnVzdGVlLmlldGYub3Jn LwogICBsaWNlbnNlLWluZm8pIGluIGVmZmVjdCBvbiB0aGUgZGF0ZSBvZiBwdWJsaWNhdGlvbiBv ZiB0aGlzIGRvY3VtZW50LgogICBQbGVhc2UgcmV2aWV3IHRoZXNlIGRvY3VtZW50cyBjYXJlZnVs bHksIGFzIHRoZXkgZGVzY3JpYmUgeW91ciByaWdodHMKICAgYW5kIHJlc3RyaWN0aW9ucyB3aXRo IHJlc3BlY3QgdG8gdGhpcyBkb2N1bWVudC4gIENvZGUgQ29tcG9uZW50cwogICBleHRyYWN0ZWQg ZnJvbSB0aGlzIGRvY3VtZW50IG11c3QgaW5jbHVkZSBSZXZpc2VkIEJTRCBMaWNlbnNlIHRleHQg YXMKICAgZGVzY3JpYmVkIGluIFNlY3Rpb24gNC5lIG9mIHRoZSBUcnVzdCBMZWdhbCBQcm92aXNp b25zIGFuZCBhcmUKICAgcHJvdmlkZWQgd2l0aG91dCB3YXJyYW50eSBhcyBkZXNjcmliZWQgaW4g dGhlIFJldmlzZWQgQlNEIExpY2Vuc2UuCgoKCkFkZWxsICAgICAgICAgICAgICAgICAgICBFeHBp cmVzIDE0IE9jdG9iZXIgMjAyMiAgICAgICAgICAgICAgICBbUGFnZSAxXQoMCkludGVybmV0LURy YWZ0ICAgICAgICAgICBDbGllbnQgUm9hbWluZyBDb250cm9sICAgICAgICAgICAgICAgQXByaWwg MjAyMgoKClRhYmxlIG9mIENvbnRlbnRzCgogICAxLiAgSW50cm9kdWN0aW9uICAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDIKICAgMi4gIENvbnZlbnRp b25zIFVzZWQgaW4gVGhpcyBEb2N1bWVudCAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICAz CiAgIDMuICBUaGUgQ1JDIFJlc291cmNlIFJlY29yZCAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuICAgNAogICAgIDMuMS4gIFJSIG5hbWUgZmllbGQgLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDQKICAgICAzLjIuICBDUkMgUkRBVEEgV2ly ZSBGb3JtYXQgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA0CiAgICAgMy4z LiAgQ1JDIFByZXNlbnRhdGlvbiBGb3JtYXQgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuICAgNAogICA0LiAgVGhlIENSUyBSZXNvdXJjZSBSZWNvcmQgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAgIDUKICAgICA0LjEuICBDUlMgUkRBVEEgV2lyZSBGb3JtYXQg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA1CiAgICAgNC4yLiAgQ1JTIFBy ZXNlbnRhdGlvbiBGb3JtYXQgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNQog ICA1LiAgRXhhbXBsZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAgIDYKICAgICA1LjEuICBSZXN0cmljdGVkIEFwcGxpY2F0aW9uICAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA2CiAgICAgNS4yLiAgQ29udHJvbGxlZCBBcHBs aWNhdGlvbiAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNwogICAgIDUuMy4g IE9wZW5lZCBBcHBsaWNhdGlvbiAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAgIDgKICAgNi4gIElBTkEgQ29uc2lkZXJhdGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gICA5CiAgIDcuICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgOQogICAgIDcuMS4gIEROUyBtaXNj b25maWd1cmF0aW9uICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDkKICAg ICA3LjIuICBETlMgU2VjdXJpdHkgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gIDEwCiAgICAgNy4zLiAgQXBwbGljYXRpb24gU2VjdXJpdHkgIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxMAogICA4LiAgUmVmZXJlbmNlcyAgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTAKICAgICA4LjEuICBO b3JtYXRpdmUgUmVmZXJlbmNlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g IDExCiAgICAgOC4yLiAgSW5mb3JtYXRpdmUgUmVmZXJlbmNlcyAgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuICAxMQogICBBdXRob3IncyBBZGRyZXNzICAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTEKCjEuICBJbnRyb2R1Y3Rpb24KCiAg IElsbGVnaXRpbWF0ZSBhY2Nlc3MgdG8gcHJvZmVzc2lvbmFsIHJlc3RyaWN0ZWQgYXBwbGljYXRp b25zIG92ZXIKICAgSW50ZXJuZXQgaXMgYSBwZXJtYW5lbnQgdGhyZWF0IGZvciBvcmdhbml6YXRp b25zIGFuZCB0aGVpciBzdGFmZi4KICAgRGlmZmVyZW50IG1ldGhvZHMgY2FuIGJlIHVzZWQgdG8g aW1wZXJzb25hdGUgYSB1c2VyIGFjY2VzcywgYW5kIGluCiAgIHNvbWUgY2FzZXMgYW4gb3JnYW5p emF0aW9uIGFsc28gd2FudHMgdG8gYmV0dGVyIHByZXZlbnQgaXRzIG93biBzdGFmZgogICB0byBh Y2Nlc3MgYSB0aGlyZC1wYXJ0eSBhcHBsaWNhdGlvbiBmcm9tIGEgbmV0d29yayB3aGljaCBpcyBu b3QgdW5kZXIKICAgaXRzIGNvbnRyb2wuICBPbiB0aGUgY29udHJhcnksIGFuIG9yZ2FuaXphdGlv biBtYXliZSB3YW50cyB0byBhbGxvdwogICByb2FtaW5nIHRoZW4gaXRzIHVzZXJzIGNhbiBhY2Nl c3MgZnJvbSBkaWZmZXJlbnQga25vd24gcGxhY2VzLgoKICAgVGhlIENsaWVudCBSb2FtaW5nIENv bnRyb2wgKENSQykgRE5TIFJlc291cmNlIFJlY29yZCAoUlIpIGFjdHMgYXMgYQogICBXaGl0ZS1M aXN0IGFuZCBpbmZvcm1zIGEgY29tcGF0aWJsZSBhcHBsaWNhdGlvbiBmcm9tIHdoaWNoIG5ldHdv cmtzCiAgIGl0cyB1c2VycyBhcmUgYWxsb3dlZCB0byBjb25uZWN0LCBiZSBpdCBhIGxpbWl0ZWQg bGlzdCBvZiBuZXR3b3JrcyBvcgogICBicm9hZGx5IHdpdGhvdXQgYW55IHJlc3RyaWN0aW9uLgoK CgoKCgoKCgoKCgpBZGVsbCAgICAgICAgICAgICAgICAgICAgRXhwaXJlcyAxNCBPY3RvYmVyIDIw MjIgICAgICAgICAgICAgICAgW1BhZ2UgMl0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgQ2xp ZW50IFJvYW1pbmcgQ29udHJvbCAgICAgICAgICAgICAgIEFwcmlsIDIwMjIKCgogICBBdCB0aGUg YXBwbGljYXRpb24gbGV2ZWwsIHRoZSBpZGVudGlmaWNhdGlvbiBvZiB0aGUgdXNlcidzCiAgIG9y Z2FuaXphdGlvbiBkb21haW4gY2FuIGJlIGJhc2VkIG9uIGFuIGluZm9ybWF0aW9uIGNhcnJpZWQg ZHVyaW5nIHRoZQogICBhdXRoZW50aWNhdGlvbiBwcm9jZXNzLCBvciBhIGxvb2t1cCBvbiBhbiBp bmZvcm1hdGlvbiBhbHJlYWR5IGtub3duCiAgIGJ5IHRoZSBhcHBsaWNhdGlvbi4gIEluIGJvdGgg Y2FzZXMgdGhpcyBpbmZvcm1hdGlvbiBsZXRzIHRoZQogICBhcHBsaWNhdGlvbiByZWxhdGUgdGhl IHVzZXIgdG8gaXRzIG9yZ2FuaXphdGlvbiB1bmVxdWl2b2NhbGx5LgogICBGaW5hbGx5LCB0aGUg Y29ycmVzcG9uZGluZyB1c2VyJ3MgZG9tYWluIEROUyB3aWxsIGJlIHJlcXVlc3RlZCB3aXRoCiAg IHRoZSBhcHBsaWNhdGlvbidzIEZRRE4gYW5kIHBvcnQsIGFuZCB0aGUgYXBwbGljYXRpb24gd2ls bCBrbm93CiAgIHdoZXRoZXIgYW4gYXV0aG9yaXphdGlvbiBpcyBleHBlY3RlZCBvciBub3QuICBT b21lIGV4YW1wbGVzIHdpbGwgYmUKICAgZ2l2ZW4gaW4gdGhpcyBkb2N1bWVudC4KCiAgIFRoZSBh cHBsaWNhdGlvbnMgaW1wbGVtZW50aW5nIHRoaXMgYXV0aG9yaXphdGlvbiBjb250cm9sIGxldCB0 aGUKICAgY2xpZW50IG9yZ2FuaXphdGlvbnMga25vdyB0aGlzIGZlYXR1cmUgaXMgYXZhaWxhYmxl IGJ5IHVzaW5nIHRoZQogICBDbGllbnQgUm9hbWluZyBTdXBwb3J0IChDUlMpIFJSLiAgVGhlIGRh dGEgYXNzb2NpYXRlZCB3aXRoIHRoaXMKICAgcmVjb3JkIGluZGljYXRlcyBpZiB0aGUgY2xpZW50 J3Mgb3JnYW5pemF0aW9uIGV4cGVjdGVkIHN1cHBvcnQgb2YgdGhlCiAgIENSQyBpcyBtYW5kYXRv cnksIG9wdGlvbmFsLCBvciBpZ25vcmVkLiAgVGhpcyBpbmZvcm1hdGlvbiBzdG9yZWQgaW4KICAg dGhlIENSUyBjYW4gYmUgY29uZmlybWVkIGF0IHRoZSBhcHBsaWNhdGlvbiBsZXZlbCBieSBhIHJl ZHVuZGFudAogICBkYXRhLiAgVGhlIHdheSB0aGUgYXBwbGljYXRpb24gaGFuZGxlcyB0aGUgYXV0 aG9yaXphdGlvbiBtZWNoYW5pc20sCiAgIGJ5IGNvbnN1bHRpbmcgdGhlIGFzc29jaWF0ZWQgQ1JT IHJlY29yZCBvciBub3QsIGlzIGxlZnQgdG8gdGhlCiAgIGltcGxlbWVudG9yLgoKICAgQWx0aG91 Z2ggdGhpcyBtZWNoYW5pc20gaXMgZGVzaWduZWQgZm9yIGltcHJvdmluZyB0aGUgc2VjdXJpdHkK ICAgYmV0d2VlbiBkaWZmZXJlbnQgb3JnYW5pemF0aW9ucywgdGhlcmUgaXMgbm8gb2JqZWN0aW9u IHRvIHVzZSBpdCBmb3IKICAgYSBzYW1lIG9yZ2FuaXphdGlvbiBwbGF5aW5nIGJvdGggcm9sZXMg b2YgY2xpZW50IGFuZCBhcHBsaWNhdGlvbiAsIGFzCiAgIGFuIGFsdGVybmF0aXZlIG9yIGFkZGl0 aW9uYWwgbGF5ZXIgdG8gYSBzb2x1dGlvbiBhbHJlYWR5IGluIHBsYWNlLAogICBzdWNoIGFzIGEg ZmlyZXdhbGwgZm9yIGV4YW1wbGUuCgoyLiAgQ29udmVudGlvbnMgVXNlZCBpbiBUaGlzIERvY3Vt ZW50CgogICBUaGlzIHNwZWNpZmljYXRpb24gdXNlcyBkZWZpbml0aW9ucyBmcm9tIERvbWFpbiBO YW1lIFN5c3RlbQogICBbUkZDMTAzNV0sIGFuZCByZWFkZXJzIHVuZmFtaWxpYXIgd2l0aCBpdCBj YW4gYWxzbyBjaGVjayBETlMKICAgVGVybWlub2xvZ3kgW1JGQzg0OTldLiAgVGhlIHN5bnRheCBz cGVjaWZpY2F0aW9uIHVzZXMgdGhlIEF1Z21lbnRlZAogICBCYWNrdXMtTmF1ciBGb3JtIChBQk5G KSBub3RhdGlvbiBhcyBzcGVjaWZpZWQgaW4gW1JGQzUyMzRdLCB3aXRoIHNvbWUKICAgZXhwcmVz c2lvbnMgYmVpbmcgZGVmaW5lZCBpbiAiVW5pZm9ybSBSZXNvdXJjZSBJZGVudGlmaWVyIChVUkkp OgogICBHZW5lcmljIFN5bnRheCIgW1JGQzM5ODZdIGFuZCAiSVAgVmVyc2lvbiA2IEFkZHJlc3Np bmcgQXJjaGl0ZWN0dXJlIgogICBbUkZDNDI5MV0uCgogICBUaGUga2V5IHdvcmRzICJNVVNUIiwg Ik1VU1QgTk9UIiwgIlJFUVVJUkVEIiwgIlNIQUxMIiwgIlNIQUxMIE5PVCIsCiAgICJTSE9VTEQi LCAiU0hPVUxEIE5PVCIsICJSRUNPTU1FTkRFRCIsICJOT1QgUkVDT01NRU5ERUQiLCAiTUFZIiwg YW5kCiAgICJPUFRJT05BTCIgaW4gdGhpcyBkb2N1bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQg YXMgZGVzY3JpYmVkIGluIEJDUAogICAxNCBbUkZDMjExOV0gW1JGQzgxNzRdIHdoZW4sIGFuZCBv bmx5IHdoZW4sIHRoZXkgYXBwZWFyIGluIGFsbAogICBjYXBpdGFscywgYXMgc2hvd24gaGVyZS4K CgoKCgoKCgoKCkFkZWxsICAgICAgICAgICAgICAgICAgICBFeHBpcmVzIDE0IE9jdG9iZXIgMjAy MiAgICAgICAgICAgICAgICBbUGFnZSAzXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICBDbGll bnQgUm9hbWluZyBDb250cm9sICAgICAgICAgICAgICAgQXByaWwgMjAyMgoKCjMuICBUaGUgQ1JD IFJlc291cmNlIFJlY29yZAoKICAgVGhlIENSQyBSUiBwdXJwb3NlIGlzIHRvIHByb3ZpZGUgYSBs aXN0IG9mIElQIHJhbmdlcyBhdXRob3JpemVkIHRvCiAgIHVzZSBhIHBhcnRpY3VsYXIgYXBwbGlj YXRpb24uICBFYWNoIFJSIGNvbnRhaW5zIGEgbGlzdCBvZiBlaXRoZXIgSVB2NAogICBvciBJUHY2 IG5ldHdvcmsgYWRkcmVzcyByYW5nZXMuICBUaGVzZSByYW5nZXMgTVVTVCBmb2xsb3cgdGhlIENJ RFIKICAgbm90YXRpb24uICBBIHNpbmdsZSBDUkMgUlIgTUFZIGNvbnRhaW4gcmFuZ2VzIGZvciBk aWZmZXJlbnQgSVAKICAgdmVyc2lvbnMsIGJ1dCBpbiB0aGUgY2FzZSBvZiBtYW55IHJhbmdlcyB0 aGlzIGNhbiBiZSBkaWZmaWN1bHQgdG8KICAgcmVhZCBvciBtYWludGFpbiwgc28gZGVkaWNhdGlu ZyBhIHJlY29yZCB0byBlYWNoIElQIHZlcnNpb24gb3Igbm90IGlzCiAgIGxlZnQgdG8gdGhlIGFk bWluaXN0cmF0b3IuICBNdWx0aXBsZSBSUnMgTUFZIGJlIGRlZmluZWQgZm9yIGEgZ2l2ZW4KICAg SVAgdmVyc2lvbi4KCjMuMS4gIFJSIG5hbWUgZmllbGQKCiAgIFRoZSBDUkMgUlIgbmFtZSBmaWVs ZCBpcyBjb21wb3NlZCBvZiB0aGUgdGhpcmQtcGFydHkgYXBwbGljYXRpb24KICAgZG9tYWluLCBp dHMgcG9ydCwgZm9sbG93ZWQgYnkgdGhlIGZ1bGx5IHF1YWxpZmllZCBuYW1lIGluaGVyZW50IGlu CiAgIHRoaXMgem9uZS4gIFRoZXNlIHRocmVlIGNvbXBvbmVudHMgYXJlIHNlcGFyYXRlZCBieSB0 aGUgdW5kZXJzY29yZQogICBjaGFyYWN0ZXIuCgozLjIuICBDUkMgUkRBVEEgV2lyZSBGb3JtYXQK CiAgIFRoZSBDUkMgUkRBVEEgd2lyZSBmb3JtYXQgaXMgZW5jb2RlZCBhcyBmb2xsb3dzOgoKICAg ICAgICstLSstLSstLSstLSstLSstLSstLSstLSstLSstLSstLSstLSstLSstLSstLSstLSsKICAg ICAgIC8gICAgICAgICAgICAgICAgICAgICBDUkMgICAgICAgICAgICAgICAgICAgICAgIC8KICAg ICAgIC8gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC8KICAg ICAgICstLSstLSstLSstLSstLSstLSstLSstLSstLSstLSstLSstLSstLSstLSstLSstLSsKCiAg IFRoZSBDUkMgZmllbGQgY29udGFpbnMgYSBsaXN0IG9mIGVpdGhlciBJUHY0IG9yIElQdjYgcmFu Z2VzIHNlcGFyYXRlZAogICBieSB0aGUgY29tbWEgY2hhcmFjdGVyLgoKMy4zLiAgQ1JDIFByZXNl bnRhdGlvbiBGb3JtYXQKCiAgIFRoZSBwcmVzZW50YXRpb24gZm9ybWF0IG9mIHRoZSBDUkMgcmVj b3JkIGlzOgoKICAgQ1JDIChpcDRuZXRsaXN0IFssaXA2bmV0bGlzdF0pIC8gKFtpcDRuZXRsaXN0 LF0gaXA2bmV0bGlzdCkKCiAgIGlwNG5ldGxpc3QgPSBpcDRuZXQgKigsaXA0bmV0KQoKICAgaXA0 bmV0ID0gSVB2NGFkZHJlc3MgIi8iIGlwNHJhbmdlCgogICBpcDRyYW5nZSA9IERJR0lUIC8gIjEi IERJR0lUIC8gIjIiIERJR0lUIC8gIjMiIERJR0lUICV4MzAtMzIKCiAgIGlwNm5ldGxpc3QgPSBp cDZuZXQgKigsaXA2bmV0KQoKICAgaXA2bmV0ID0gKGlwdjYtYWRkcmVzcyAiLyIgcHJlZml4LWxl bmd0aCkKCgoKCgoKQWRlbGwgICAgICAgICAgICAgICAgICAgIEV4cGlyZXMgMTQgT2N0b2JlciAy MDIyICAgICAgICAgICAgICAgIFtQYWdlIDRdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgIENs aWVudCBSb2FtaW5nIENvbnRyb2wgICAgICAgICAgICAgICBBcHJpbCAyMDIyCgoKNC4gIFRoZSBD UlMgUmVzb3VyY2UgUmVjb3JkCgogICBUaGUgQ1JTIFJSIGluZGljYXRlcyB3aGljaCBjb250cm9s IGlzIGRvbmUgb24gdGhlIGNsaWVudAogICBvcmdhbml6YXRpb25zLCBhbmQgdGh1cyB3aGljaCBv bmVzIGFyZSBhdXRob3JpemVkLiAgQSByZXF1aXJlbWVudAogICBmaWVsZCBpcyB1c2VkIGZvciB0 aGlzIHB1cnBvc2UsIGl0IGhhcyBvbmUgb2YgdGhlIGZvbGxvd2luZyB2YWx1ZXMKICAgbWVhbmlu ZyB3aGVuIHRoZSBjaGVja2luZyBpcyBwZXJmb3JtZWQgOgoKICAgKiAgIk4iIDogTmV2ZXIsIGFs bCBvcmdhbml6YXRpb25zIGFyZSBhdXRob3JpemVkCgogICAqICAiQSIgOiBBbHdheXMsIG9ubHkg b3JnYW5pemF0aW9ucyB3aXRoIGEgQ1JDIGFyZSBhdXRob3JpemVkCgogICAqICAiTyIgOiBPcHRp b25hbCwgYW55IG9yZ2FuaXphdGlvbiBDUkMgaXMgaG9ub3JlZCwgb3RoZXIKICAgICAgb3JnYW5p emF0aW9ucyBhcmUgYXV0aG9yaXplZAoKICAgSW4gYWRkaXRpb24gdG8gdGhpcyB2YWx1ZSwgYW4g b3B0aW9uYWwgbGlzdCBvZiBwb3J0cyBjYW4gYmUgZ2l2ZW4uCiAgIEluZGVlZCwgbXVsdGlwbGUg YXBwbGljYXRpb25zIGNhbiBiZSBob3N0ZWQgb24gZGlmZmVyZW50IHBvcnRzIHVuZGVyCiAgIHRo ZSBzYW1lIGRvbWFpbiBuYW1lLCBhbmQgYW4gZXF1aXZhbGVudCBzdXBwb3J0IHdhcyBkZXNjcmli ZWQgZm9yIHRoZQogICBDUkMgUlIuICBJbiBjYXNlIG9mIGRpZmZlcmVudCByZXF1aXJlbWVudCB2 YWx1ZXMsIGl0IGlzIFJFQ09NTUVOREVECiAgIHRvIGhhdmUgb25lIGRlZGljYXRlZCBSUiBmb3Ig ZWFjaCBhbHRob3VnaCBvbmUgc2luZ2xlIFJSIHdpdGggYWxsIHRoZQogICBpbmZvcm1hdGlvbiBp cyBzdXBwb3J0ZWQuICBPbmUgcGFydGljdWxhciBwb3J0IE1VU1QgTk9UIGFwcGVhciBpbgogICBt b3JlIHRoYW4gb25lIFJSLiAgV2hlbiBubyBwb3J0IGlzIG1lbnRpb25lZCwgb25seSBvbmUgUlIg TUFZIGJlCiAgIGRlY2xhcmVkIGFuZCBpdHMgcmVxdWlyZW1lbnQgdmFsdWUgY292ZXJzIGFsbCBh cHBsaWNhdGlvbnMgZm9yIHRoaXMKICAgZG9tYWluIG5hbWUuCgogICBJbiB0aGUgYWJzZW5jZSBv ZiBzdWNoIHJlY29yZCwgbm8gcm9hbWluZyBjb250cm9sIGlzIHRvIGJlIGV4cGVjdGVkCiAgIGJ5 IHRoZSBjbGllbnQsIGFueSBvZiBpdHMgQ1JDIFJScyB3aWxsIGJlIGlnbm9yZWQuICBJdCBpcyBl cXVpdmFsZW50CiAgIHRvIGEgQ1JTIHJlcXVpcmVtZW50IHZhbHVlIGluZGljYXRpbmcgbm8gY29u dHJvbCBpcyBwZXJmb3JtZWQuCgo0LjEuICBDUlMgUkRBVEEgV2lyZSBGb3JtYXQKCiAgIFRoZSBD UlMgUkRBVEEgd2lyZSBmb3JtYXQgaXMgZW5jb2RlZCBhcyBmb2xsb3dzOgoKICAgICAgICstLSst LSstLSstLSstLSstLSstLSstLSstLSstLSstLSstLSstLSstLSstLSstLSsKICAgICAgIC8gICAg ICAgICAgICAgICAgICAgICBDUlMgICAgICAgICAgICAgICAgICAgICAgIC8KICAgICAgIC8gICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC8KICAgICAgICstLSst LSstLSstLSstLSstLSstLSstLSstLSstLSstLSstLSstLSstLSstLSstLSsKCiAgIFRoZSBDUlMg ZmllbGQgY29udGFpbnMgYSBsaXN0IG9mIHJlcXVpcmVtZW50cyBmb2xsb3dlZCBieSB0aGVpcgog ICByZXNwZWN0aXZlIG9wdGlvbmFsIHBvcnRzLgoKNC4yLiAgQ1JTIFByZXNlbnRhdGlvbiBGb3Jt YXQKCiAgIFRoZSBwcmVzZW50YXRpb24gZm9ybWF0IG9mIHRoZSBDUlMgcmVjb3JkIGlzOgoKICAg Q1JTIChzaW5nbGUtcnVsZSAvIG11bHRpcGxlLXJ1bGVzKQoKICAgc2luZ2xlLXJ1bGUgPSAiUj0i ICgiTiIgLyAiQSIgLyAiTyIpICooLHBvcnQpCgoKCgpBZGVsbCAgICAgICAgICAgICAgICAgICAg RXhwaXJlcyAxNCBPY3RvYmVyIDIwMjIgICAgICAgICAgICAgICAgW1BhZ2UgNV0KDApJbnRlcm5l dC1EcmFmdCAgICAgICAgICAgQ2xpZW50IFJvYW1pbmcgQ29udHJvbCAgICAgICAgICAgICAgIEFw cmlsIDIwMjIKCgogICBtdWx0aXBsZS1ydWxlcyA9IHVuaXQtcnVsZSAxKjIoO3VuaXQtcnVsZSkK CiAgIHVuaXQtcnVsZSA9ICJSPSIgKCJOIiAvICJBIiAvICJPIikgMSooLHBvcnQpCgogICBwb3J0 ID0gWzEtOV0gKihbRElHSVRdKQoKNS4gIEV4YW1wbGVzCgogICBUaGUgZm9sbG93aW5nIGV4YW1w bGVzIHNob3cgc29tZSB0eXBpY2FsIHVzZXMgZXhwZWN0ZWQgZnJvbSB0aGlzCiAgIGRvY3VtZW50 YXRpb24uICBQYXJ0aWN1bGFybHksIHRoZSBpbnRlbmRlZCBiZWhhdmlvcnMgZm9yIGRpZmZlcmVu dAogICBDUkMgYW5kIENSUyB2YWx1ZXMgYXJlIGV4cGxhaW5lZCwgd2hpbGUgdGhlIHVzZXIgaWRl bnRpZmljYXRpb24gaXMKICAgZG9uZSBkaXJlY3RseSB0aHJvdWdoIGNhcnJpZWQgZGF0YSBvciBh IGRlZHVjdGlvbiBwcm9jZXNzLgoKNS4xLiAgUmVzdHJpY3RlZCBBcHBsaWNhdGlvbgoKICAgSW4g dGhpcyBleGFtcGxlLCBhbiBhcHBsaWNhdGlvbiBpcyBvbmx5IG9wZW5lZCB0byBvcmdhbml6YXRp b25zCiAgIHB1Ymxpc2hpbmcgdGhlaXIgcmVzcGVjdGl2ZSBhbGxvd2VkIG5ldHdvcmtzLiAgVGhl IHJlcXVpcmVtZW50IHZhbHVlCiAgIG9mIHRoZSBDUlMgcmVjb3JkIGVxdWFscyAiQSIsIGFuZCBh bnkgb3JnYW5pemF0aW9uIHdpdGggYW4gZW1wdHkgb3IKICAgbWlzc2luZyBDUkMgZm9yIHRoaXMg YXBwbGljYXRpb24gd2lsbCBiZSBkZW5pZWQgYWNjZXNzLgoKICAgVGhlIGZ0cC5leGFtcGxlLmNv bSBkb21haW4gaXMgZGVkaWNhdGVkIHRvIGhvc3RpbmcgYW4gRlRQCiAgIGFwcGxpY2F0aW9uLCB3 aGljaCBleHRyYWN0cyB0aGUgY2xpZW50J3MgZG9tYWluIGZyb20gdGhlIHVzZXJuYW1lCiAgIHVz ZWQgZHVyaW5nIHRoZSBhdXRoZW50aWNhdGlvbiBwcm9jZXNzLiAgVGhpcyBpbmZvcm1hdGlvbiBp cyB0aGVuCiAgIHVzZWQgZm9yIHJlcXVlc3RpbmcgdGhlIGNsaWVudCBDUkMgcmVjb3JkIGFuZCBm aW5hbGx5IGNvbXBhcmluZyBpdHMKICAgY29udGVudCB3aXRoIHRoZSBjbGllbnQncyBJUC4gIFRo ZSBjbGllbnQgb3JnYW5pemF0aW9uIGV4YW1wbGUubmV0CiAgIGFsbG93cyBpdHMgdXNlcnMgZnJv bSBpdHMgb3duIG5ldHdvcmsgMTkyLjAuMi4wLzI0IGFuZCBmcm9tIGEgY2xvdWQKICAgc2Vydmlj ZSBsb2NhdGVkIGF0IDE5OC41MS4xMDAuMC8yNC4gIEEgc2Vjb25kIG9yZ2FuaXphdGlvbgogICBl eGFtcGxlLm9yZyBoYXMgbm8gQ1JDIHJlY29yZCBhbmQgaXRzIHVzZXJzIGFyZSByZWplY3RlZC4K CiAgIEFwcGxpY2F0aW9uIEZRRE4gOiBmdHAuZXhhbXBsZS5jb20KICAgQXBwbGljYXRpb24gQ1JT IHJlY29yZCA6IGZ0cC5leGFtcGxlLmNvbS4gIElOIENSUyBSPUEsMjEKCiAgIENsaWVudCBGUURO IDogZXhhbXBsZS5uZXQKICAgQ2xpZW50IG9yZ2FuaXphdGlvbiBDUkMgcmVjb3JkIDogZnRwLmV4 YW1wbGUuY29tXzIxLmV4YW1wbGUubmV0LiAgSU4KICAgQ1JDIDE5Mi4wLjIuMC8yNCwxOTguNTEu MTAwLjAvMjQKCiAgIENsaWVudCBGUUROIDogZXhhbXBsZS5vcmcKICAgTm8gY2xpZW50IG9yZ2Fu aXphdGlvbiBDUkMgcmVjb3JkCgoKCgoKCgoKCgoKCgpBZGVsbCAgICAgICAgICAgICAgICAgICAg RXhwaXJlcyAxNCBPY3RvYmVyIDIwMjIgICAgICAgICAgICAgICAgW1BhZ2UgNl0KDApJbnRlcm5l dC1EcmFmdCAgICAgICAgICAgQ2xpZW50IFJvYW1pbmcgQ29udHJvbCAgICAgICAgICAgICAgIEFw cmlsIDIwMjIKCgogICBDbGllbnQgRE5TICBDbGllbnQgRlRQICAgICAgICAgICAgICAgIFNlcnZl ciBGVFAKCiAgICAgICAgICAgICAgICAgICAgIEZUUCBVU0VSIG1lQGV4YW1wbGUubmV0CiAgICAg ICAgICAgICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPgogICAgICAgICAgICAgICAg ICAgICAgICAgICAgLi4uCiAgICAgICAgICAgICAgICAgICAgIEZUUCBQQVNTICoqKioqKioqCiAg ICAgICAgICAgICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPgogICAgICAgICAgUXVl cnkgOiBDUkMgZnRwLmV4YW1wbGUuY29tXzIxLmV4YW1wbGUubmV0CiAgICAgICAgPC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQogICAgICAgICAgQW5zd2VyIDogQ1JDIGZ0cC5l eGFtcGxlLmNvbV8yMS5leGFtcGxlLm5ldCAxOTIuMC4yLjAvMjQsMTk4LjUxLjEwMC4wLzI0CiAg ICAgICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPgogICAgICAgICAgICAg ICAgICAgICBGVFAgMjMwCiAgICAgICAgICAgICAgPC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQoKCiAgICAgICAgICAgICAgICAgICAgIEZUUCBVU0VSIG1lQGV4YW1wbGUub3JnCiAgICAg ICAgICAgICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPgogICAgICAgICAgICAgICAg ICAgICAgICAgICAgLi4uCiAgICAgICAgICAgICAgICAgICAgIEZUUCBQQVNTICoqKioqKioqCiAg ICAgICAgICAgICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPgogICAgICAgICAgUXVl cnkgOiBDUkMgZnRwLmV4YW1wbGUuY29tXzIxLmV4YW1wbGUub3JnCiAgICAgICAgPC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQogICAgICAgICAgQW5zd2VyIDogTm8gc3VjaCBu YW1lICgzKQogICAgICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLT4KICAg ICAgICAgICAgICAgICAgICAgRlRQIDQzMAogICAgICAgICAgICAgIDwtLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0KCjUuMi4gIENvbnRyb2xsZWQgQXBwbGljYXRpb24KCiAgIFRoZSB3d3cu ZXhhbXBsZS5jb20gZG9tYWluIGhvc3RzIGEgV2ViIGFwcGxpY2F0aW9uIG9uIHBvcnQgNDQzIHVz aW5nCiAgIGNsaWVudCBjZXJ0aWZpY2F0ZXMgZm9yIGF1dGhlbnRpY2F0aW5nIGl0cyB1c2Vycy4g IFRoZSBhcHBsaWNhdGlvbgogICBleHRyYWN0cyB0aGUgY2xpZW50IGRvbWFpbnMgZnJvbSB0aGUg Y2VydGlmaWNhdGVzLCB3aGljaCBhcmUgdXNlZCB0bwogICByZXRyaWV2ZSB0aGVpciBDUkMgcmVj b3Jkcy4gIFVzZXJzIGZyb20gdGhlIGV4YW1wbGUubmV0IG9yZ2FuaXphdGlvbgogICBhcmUgYWxs b3dlZCBvbmx5IGlmIHRoZXkgY29ubmVjdCBmcm9tIGFuIGF1dGhvcml6ZWQgbmV0d29yayBsaXN0 ZWQgaW4KICAgdGhlIENSQyByZWNvcmQsIHdoaWxlIHVzZXJzIGZyb20gZXhhbXBsZS5vcmcgYXJl IGFsd2F5cyBncmFudGVkCiAgIGFjY2VzcyBzaW5jZSB0aGlzIG9uZSBoYXMgbm8gQ1JDIGRlY2xh cmVkLgoKICAgQXBwbGljYXRpb24gRlFETiA6IHd3dy5leGFtcGxlLmNvbQogICBBcHBsaWNhdGlv biBDUlMgcmVjb3JkIDogd3d3LmV4YW1wbGUuY29tLiAgSU4gQ1JTIFI9Tyw0NDMKCiAgIENsaWVu dCBGUUROIDogZXhhbXBsZS5uZXQKICAgQ2xpZW50IG9yZ2FuaXphdGlvbiBDUkMgcmVjb3JkIDog d3d3LmV4YW1wbGUuY29tXzQ0My5leGFtcGxlLm5ldC4gIElOCiAgIENSQyAxOTIuMC4yLjAvMjQs MTk4LjUxLjEwMC4wLzI0CgogICBDbGllbnQgRlFETiA6IGV4YW1wbGUub3JnCiAgIE5vIGNsaWVu dCBvcmdhbml6YXRpb24gQ1JDIHJlY29yZAoKCgoKCkFkZWxsICAgICAgICAgICAgICAgICAgICBF eHBpcmVzIDE0IE9jdG9iZXIgMjAyMiAgICAgICAgICAgICAgICBbUGFnZSA3XQoMCkludGVybmV0 LURyYWZ0ICAgICAgICAgICBDbGllbnQgUm9hbWluZyBDb250cm9sICAgICAgICAgICAgICAgQXBy aWwgMjAyMgoKCiAgIENsaWVudCBETlMgIENsaWVudCBicm93c2VyICAgICAgICAgICAgICAgIFdl YiBhcHBsaWNhdGlvbgoKCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLi4uLi4KICAgICAg ICAgICAgICAgICBDbGllbnQgY2VydGlmaWNhdGUgbWVAZXhhbXBsZS5uZXQKICAgICAgICAgICAg ICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0+CiAgICAgICAgICBRdWVyeSA6 IENSQyB3d3cuZXhhbXBsZS5jb21fNDQzLmV4YW1wbGUubmV0CiAgICAgICAgPC0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQogICAgICAgICAgQW5zd2VyIDogQ1JDIHd3 dy5leGFtcGxlLmNvbV80NDMuZXhhbXBsZS5uZXQgMTkyLjAuMi4wLzI0LDE5OC41MS4xMDAuMC8y NAogICAgICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLT4KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAuLi4uLgogICAgICAgICAgICAgICAgICAgICAyMDAg T0sKICAgICAgICAgICAgICAgPC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCgoK ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAuLi4uLgogICAgICAgICAgICAgICAgIENsaWVu dCBjZXJ0aWZpY2F0ZSBtZUBleGFtcGxlLm9yZwogICAgICAgICAgICAgICAtLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLT4KICAgICAgICAgIFF1ZXJ5IDogQ1JDIHd3dy5leGFtcGxl LmNvbV80NDMuZXhhbXBsZS5vcmcKICAgICAgICA8LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tCiAgICAgICAgICBBbnN3ZXIgOiBObyBzdWNoIG5hbWUgKDMpCiAgICAg ICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPgogICAgICAgICAg ICAgICAgICAgICAgICAgICAgIC4uLi4uCiAgICAgICAgICAgICAgICAgICAgIDIwMCBPSwogICAg ICAgICAgICAgICA8LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KCjUuMy4gIE9w ZW5lZCBBcHBsaWNhdGlvbgoKICAgQSBjb21wYW55IGlzIHRlc3RpbmcgdGhlIENSQyBhbmQgQ1JT IGJlaGF2aW9ycyBiZWZvcmUgb3BlbmluZyBhIG5ldwogICBzZXJ2aWNlIHRvIGl0cyBjdXN0b21l cnMuICBJdHMgZmlyc3QgdGVzdCBkZXNjcmliZWQgYmVsb3cgY29uc2lzdHMgaW4KICAgY29uZmln dXJpbmcgYm90aCBzaWRlcyB0byBiZSBjb21wbGV0ZWx5IG9wZW5lZCwgbGlrZWx5IGJlZm9yZQog ICBoYXJkZW5pbmcgdGhlIENSUywgdGhlbiB0aGUgQ1JDLCBhbmQgdGVzdGluZyBhZ2Fpbi4KCiAg IFRoZSBhcHBsaWNhdGlvbi5leGFtcGxlLmNvbSBkb21haW4gaG9zdHMgYSBXZWIgYXBwbGljYXRp b24gb24gcG9ydAogICA0NDMgd2hlcmUgdXNlcnMgYXJlIGxvZ2dlZCBpbiBieSBzZW5kaW5nIGEg bnVtZXJpY2FsIGlkZW50aWZpZXIgYW5kIGEKICAgcGFzc3dvcmQuICBUaGUgYXBwbGljYXRpb24g dXNlcyBhIGRpY3Rpb25hcnkgZGF0YSB0eXBlIHRvIGlkZW50aWZ5CiAgIHRoZSB1c2VyJ3MgZG9t YWluLiAgVGhlIGNsaWVudC5leGFtcGxlLm5ldCBkb21haW4gaXMgdGVtcG9yYXJpbHkKICAgdXNp bmcgMiBDUkMgcmVjb3JkcyBpbmRpY2F0aW5nIGEgZnJlZSBhY2Nlc3MgZnJvbSBhbnl3aGVyZS4K CiAgIEFwcGxpY2F0aW9uIEZRRE4gOiBhcHBsaWNhdGlvbi5leGFtcGxlLmNvbQogICBBcHBsaWNh dGlvbiBDUlMgcmVjb3JkIDogYXBwbGljYXRpb24uZXhhbXBsZS5jb20uICBJTiBDUlMgUj1OLDQ0 MwoKICAgQ2xpZW50IEZRRE4gOiBjbGllbnQuZXhhbXBsZS5uZXQKICAgQ2xpZW50IG9yZ2FuaXph dGlvbiBDUkMgcmVjb3JkcyA6CiAgIGFwcGxpY2F0aW9uLmV4YW1wbGUuY29tXzQ0My5leGFtcGxl Lm5ldC4gIElOIENSQyAwLjAuMC4wLzI0CiAgIGFwcGxpY2F0aW9uLmV4YW1wbGUuY29tXzQ0My5l eGFtcGxlLm5ldC4gIElOIENSQyBmZTgwOjovMTAKCgoKCgpBZGVsbCAgICAgICAgICAgICAgICAg ICAgRXhwaXJlcyAxNCBPY3RvYmVyIDIwMjIgICAgICAgICAgICAgICAgW1BhZ2UgOF0KDApJbnRl cm5ldC1EcmFmdCAgICAgICAgICAgQ2xpZW50IFJvYW1pbmcgQ29udHJvbCAgICAgICAgICAgICAg IEFwcmlsIDIwMjIKCgogICBDbGllbnQgRE5TICBDbGllbnQgYnJvd3NlciAgICAgICAgICAgICAg ICBXZWIgYXBwbGljYXRpb24KCgogICAgICAgICAgICAgICAgICAgICAgICAgICAgIC4uLi4uCiAg ICAgICAgICAgICAgICAgSFRUUCBQT1NUIDEyMzQ1Ni8qKioqKioKICAgICAgICAgICAgICAgLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0+CiAgICAgICAgICAgICAgICAgICAgIDIw MCBPSwogICAgICAgICAgICAgICA8LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0K CjYuICBJQU5BIENvbnNpZGVyYXRpb25zCgogICBBY2NvcmRpbmcgdG8gR3VpZGVsaW5lcyBmb3Ig V3JpdGluZyBhbiBJQU5BIENvbnNpZGVyYXRpb25zIFNlY3Rpb24gaW4KICAgUkZDcyBbUkZDODEy Nl0gaXQgaXMgYXNrZWQgdG8gSUFOQSB0byBhZGQgaW50byB0aGUgUmVzb3VyY2UgUmVjb3JkCiAg IChSUikgVFlQRXMgcmVnaXN0cnkgbG9jYXRlZCBhdCBodHRwczovL3d3dy5pYW5hLm9yZy9hc3Np Z25tZW50cy9kbnMtCiAgIHBhcmFtZXRlcnMvZG5zLXBhcmFtZXRlcnMueGh0bWwjZG5zLXBhcmFt ZXRlcnMtNCB0aGUgdHdvIGVudHJpZXMgQ1JDCiAgIGFuZCBDUlMuCgogICAgICAgICAgICstLS0t LS0rLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0rCiAgICAgICAg ICAgfCBUWVBFIHwgVmFsdWUgfCBEZXNjcmlwdGlvbiAgICAgICAgICAgIHwgUmVmZXJlbmNlIHwK ICAgICAgICAgICArLS0tLS0tKy0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0t LS0tLS0tKwogICAgICAgICAgIHwgQ1JDICB8IFRCRDEgIHwgQ2xpZW50IFJvYW1pbmcgQ29udHJv bCB8IHRoaXMgUkZDICB8CiAgICAgICAgICAgKy0tLS0tLSstLS0tLS0tKy0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLSstLS0tLS0tLS0tLSsKICAgICAgICAgICB8IENSUyAgfCBUQkQyICB8IENsaWVu dCBSb2FtaW5nIFN1cHBvcnQgfCB0aGlzIFJGQyAgfAogICAgICAgICAgICstLS0tLS0rLS0tLS0t LSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0rCgogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgVGFibGUgMQoKNy4gIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zCgog ICBUaGlzIHNlY3Rpb24gaXMgbWVhbnQgdG8gaW5mb3JtIGRldmVsb3BlcnMgYW5kIHVzZXJzIG9m IHRoZSBzZWN1cml0eQogICBpbXBsaWNhdGlvbnMgb2YgdGhlIENSQy9DUlMgbWVjaGFuaXNtIGRl c2NyaWJlZCBieSB0aGlzIGRvY3VtZW50LgogICBXaGlsZSB0aGUgQ1JTIFJSIG1vc3RseSBwbGF5 cyBhbiBpbmZvcm1hdGl2ZSByb2xlLCB0aGUgQ1JDIFJSCiAgIGRlbGl2ZXJzIGltcG9ydGFudCBk YXRhIHdoaWNoIHJlcXVpcmVzIGF0dGVudGlvbiBmcm9tIHRoZSBkZXZlbG9wZXJzCiAgIGFuZCBh ZG1pbmlzdHJhdG9ycy4gIFNvbWUgcGFydGljdWxhciBwb2ludHMgYXJlIGRpc2N1c3NlZCBoZXJl LgoKNy4xLiAgRE5TIG1pc2NvbmZpZ3VyYXRpb24KCiAgIEFueSBETlMgQ1JTIG1pc2NvbmZpZ3Vy YXRpb24gc3VjaCBhcyBtdWx0aXBsZSByZWNvcmRzIHdpdGggZGlmZmVyZW50CiAgIHJlcXVpcmVt ZW50IHZhbHVlcyBidXQgd2l0aCB0aGUgc2FtZSBwb3J0IHZhbHVlIGNhbiBnZXQgYSBjbGllbnQK ICAgY29uZnVzZWQuICBJbiB0aGlzIGNhc2UgdGhlIGNsaWVudCBkb2VzIG5vdCBrbm93IHdpdGhv dXQgdGVzdGluZyB0aGUKICAgYWN0dWFsIGNvbmZpZ3VyYXRpb24sIGlmIGl0cyBvcmdhbml6YXRp b24gaXMgcHJvdGVjdGVkIGFnYWluc3QKICAgcm9hbWluZywgYW5kIGNvbnRhY3RpbmcgdGhlIGFw cGxpY2F0aW9uIGFkbWluaXN0cmF0b3IgdG8gZml4IHRoZQogICBzaXR1YXRpb24gaXMgYSBwb3Nz aWJpbGl0eS4KCiAgIFdoaWxlIENSQyBtaXNjb25maWd1cmF0aW9ucyBhcmUgbW9yZSBvciBsZXNz IGxlYWRpbmcgdG8gc2VyaW91cwogICBzZWN1cml0eSBwcm9ibGVtcywgYWRtaW5pc3RyYXRvcnMg bmVlZCB0byBwYXkgYXR0ZW50aW9uIHdoZW4gZGVhbGluZwogICB3aXRoIG11bHRpcGxlIG5ldHdv cmtzIG9yIHJlY29yZHMuICBQYXJ0aWN1bGFybHksIG11bHRpcGxlIHJlY29yZHMKICAgZm9yIHRo ZSBzYW1lIG5ldHdvcmsgcmFuZ2Ugb3Igb3ZlcmxhcHBpbmcgbmV0d29ya3Mgc2hvdWxkIGJlIGF2 b2lkZWQuCgoKCkFkZWxsICAgICAgICAgICAgICAgICAgICBFeHBpcmVzIDE0IE9jdG9iZXIgMjAy MiAgICAgICAgICAgICAgICBbUGFnZSA5XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICBDbGll bnQgUm9hbWluZyBDb250cm9sICAgICAgICAgICAgICAgQXByaWwgMjAyMgoKCjcuMi4gIEROUyBT ZWN1cml0eQoKICAgQ2xpZW50IGFuZCBhcHBsaWNhdGlvbiBhZG1pbmlzdHJhdG9ycyBuZWVkIHRv IHBheSBhcyBtdWNoIGF0dGVudGlvbgogICBhcyB0aGV5IHVzdWFsbHkgZG8gd2hlbiBkZWFsaW5n IHdpdGggRE5TIG1hbmFnZW1lbnQuICBBcyB0aGUgQ1JDCiAgIHJlY29yZHMgYXJlIHN1cHBvc2Vk IHRvIGJlIHJlcXVlc3RlZCBkdXJpbmcgYW4gYXBwbGljYXRpb24KICAgYXV0aGVudGljYXRpb24g cHJvY2VzcywgcmVmbGVjdGlvbiBhdHRhY2tzIGNvdWxkIGJlIGJ1aWx0IHRvIHRhcmdldCBhCiAg IGNsaWVudCBvcmdhbml6YXRpb24sIGV2ZW4gb25lIG5vdCBob3N0aW5nIGFueSBDUkMgcmVjb3Jk IGF0IGFsbC4KICAgSW4gYSBnZW5lcmFsIG1hbm5lciwgYWRtaW5pc3RyYXRvcnMgbWF5IGNvbnNp ZGVyIGFuIGFkZXF1YXRlIFRUTAogICBzZXR0aW5nIHRvIG5vdCBvdmVybG9hZCBjbGllbnQgb3Jn YW5pemF0aW9ucywgZW5hYmxlIFRDUCBhcyB0aGUKICAgcHJlZmVycmVkIHRyYW5zcG9ydCwgb3Ig cmVseSBvbiBETlNTRUMgdG8gd2FycmFudCBkYXRhIGF1dGhlbnRpY2l0eQogICBhbmQgaW50ZWdy aXR5LgoKNy4zLiAgQXBwbGljYXRpb24gU2VjdXJpdHkKCiAgIFRoZSBmb2xsb3dpbmcgcG9pbnRz IGFyZSBvZiBjb25jZXJuIHRvIGRldmVsb3BlcnM6CgogICBFbmNyeXB0aW9uOgogICBXaGVuZXZl ciBwb3NzaWJsZSwgdGhlIGFwcGxpY2F0aW9uIHByb3RvY29sIHNob3VsZCBiZSBlbmNyeXB0ZWQg dG8KICAgcHJldmVudCBlYXZlc2Ryb3BwaW5nIGFuZCBtYW4taW4tdGhlLW1pZGRsZSBhdHRhY2tz LiAgSXQgaXMgYQogICBjcml0aWNhbCBwb2ludCBmb3IgYXBwbGljYXRpb25zIG1haW50YWluaW5n IGEgdXNlciBzZXNzaW9uIHdpdGgKICAgYW55dGhpbmcgbGlrZSBhIHRva2VuIG9yIGNvb2tpZSwg YXMgaXQgY2FuIGxlYWQgdG8gc2Vzc2lvbiBoaWphY2tpbmcKICAgYXMgZGlzY3Vzc2VkIGJlbG93 LgoKICAgVGltaW5nIGF0dGFjazoKICAgQWxsIGF1dGhlbnRpY2F0aW9uIHN5c3RlbXMgbmVlZCB0 byBiZSBjYXJlZnVsIHRvIG5vdCBkZWxpdmVyIGFueQogICBpbmZvcm1hdGlvbiBkZXJpdmVkIGZy b20gdGhlIGNvbXB1dGluZyB0aW1lIHRvIGEgZGVuaWVkIHVzZXIsIGV2ZW4KICAgdGhlIG9uZXMg aW52b2x2aW5nIG11bHRpcGxlIGZhY3RvcnMgb3Igc3RlcHMgbGlrZSB0aGUgb25lIGRlc2NyaWJl ZAogICBpbiB0aGlzIGRvY3VtZW50LiAgSW4gcGFydGljdWxhciwgdGhlIG9yZGVyIGluIHdoaWNo IHRoZXNlIHN0ZXBzIGFyZQogICBleGVjdXRlZCBhbmQgdGhlaXIgcmVzcGVjdGl2ZSBpbXBsZW1l bnRhdGlvbnMsIG5lZWQgdG8gZGVmZWF0CiAgIHN0YXRpc3RpY2FsIGh5cG90aGVzZXMuCgogICBJ bnRlcm1lZGlhdGUgc3lzdGVtczoKICAgU29tZSBhcHBsaWNhdGlvbnMgYXJlIG5vdCBkaXJlY3Rs eSBJbnRlcm5ldCBmYWNpbmcgYW5kIGNhbm5vdCBhY2Nlc3MKICAgdG8gdGhlIHJlYWwgY2xpZW50 J3MgSVAgYWRkcmVzcyB3aXRob3V0IGludm9sdmluZyBhIG1lY2hhbmlzbSB0bwogICBmb3J3YXJk IHRoaXMgSVAgYXQgdGhlIGFwcGxpY2F0aW9uIGxheWVyLiAgRm9yIGV4YW1wbGUgd2l0aCBIVFRQ LCB0aGUKICAgY29tbW9uIHByYWN0aWNlIGJhc2VkIG9uIHRoZSBub24tc3RhbmRhcmQgWC1Gb3J3 YXJkZWQtRm9yIGhlYWRlciwgb3IKICAgaXRzIGFsdGVybmF0aXZlIHN0YW5kYXJkIEZvcndhcmRl ZCBbUkZDNzIzOV0sIGFyZSBwbGF5aW5nIHRoaXMgcm9sZS4KICAgU3VjaCBwcmFjdGljZSByZXF1 aXJlcyBhIGNvcnJlY3Qgc2FuaXRpemluZyBvZiB1c2VyIGRhdGEgdG8gYXZvaWQKICAgZmFsc2Ug aW5qZWN0ZWQgSVBzLgoKICAgU2Vzc2lvbiBoaWphY2tpbmc6CiAgIEEgd2VsbC1rbm93biBhdHRh Y2sgY2FsbGVkIFNlc3Npb24gSGlqYWNraW5nIGlzIG5vdCBtZWFudCB0byBiZQogICBkZWZlYXRl ZCBieSB0aGlzIGRvY3VtZW50IGFsb25lLiAgQXBwbGljYXRpb24gZGV2ZWxvcGVycyBtdXN0IGVu c3VyZQogICB0aGF0IGFueSByZWNldmVpZCBzZXNzaW9uIHRva2VuLCBzdWNoIGFzIGFuIEhUVFAg Q29va2llLCBiZWxvbmdzIHRvCiAgIHRoZSBzYW1lIElQIGFkZHJlc3MgdGhhbiB0aGUgb25lIHdo aWNoIHN0YXJ0ZWQgdGhpcyBzZXNzaW9uLgoKOC4gIFJlZmVyZW5jZXMKCgoKCkFkZWxsICAgICAg ICAgICAgICAgICAgICBFeHBpcmVzIDE0IE9jdG9iZXIgMjAyMiAgICAgICAgICAgICAgIFtQYWdl IDEwXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICBDbGllbnQgUm9hbWluZyBDb250cm9sICAg ICAgICAgICAgICAgQXByaWwgMjAyMgoKCjguMS4gIE5vcm1hdGl2ZSBSZWZlcmVuY2VzCgogICBb UkZDMTAzNV0gIE1vY2thcGV0cmlzLCBQLiwgIkRvbWFpbiBuYW1lcyAtIGltcGxlbWVudGF0aW9u IGFuZAogICAgICAgICAgICAgIHNwZWNpZmljYXRpb24iLCBTVEQgMTMsIFJGQyAxMDM1LCBET0kg MTAuMTc0ODcvUkZDMTAzNSwKICAgICAgICAgICAgICBOb3ZlbWJlciAxOTg3LCA8aHR0cHM6Ly93 d3cucmZjLWVkaXRvci5vcmcvaW5mby9yZmMxMDM1Pi4KCiAgIFtSRkMyMTE5XSAgQnJhZG5lciwg Uy4sICJLZXkgd29yZHMgZm9yIHVzZSBpbiBSRkNzIHRvIEluZGljYXRlCiAgICAgICAgICAgICAg UmVxdWlyZW1lbnQgTGV2ZWxzIiwgQkNQIDE0LCBSRkMgMjExOSwKICAgICAgICAgICAgICBET0kg MTAuMTc0ODcvUkZDMjExOSwgTWFyY2ggMTk5NywKICAgICAgICAgICAgICA8aHR0cHM6Ly93d3cu cmZjLWVkaXRvci5vcmcvaW5mby9yZmMyMTE5Pi4KCiAgIFtSRkMzOTg2XSAgQmVybmVycy1MZWUs IFQuLCBGaWVsZGluZywgUi4sIGFuZCBMLiBNYXNpbnRlciwgIlVuaWZvcm0KICAgICAgICAgICAg ICBSZXNvdXJjZSBJZGVudGlmaWVyIChVUkkpOiBHZW5lcmljIFN5bnRheCIsIFNURCA2NiwKICAg ICAgICAgICAgICBSRkMgMzk4NiwgRE9JIDEwLjE3NDg3L1JGQzM5ODYsIEphbnVhcnkgMjAwNSwK ICAgICAgICAgICAgICA8aHR0cHM6Ly93d3cucmZjLWVkaXRvci5vcmcvaW5mby9yZmMzOTg2Pi4K CiAgIFtSRkM0MjkxXSAgSGluZGVuLCBSLiBhbmQgUy4gRGVlcmluZywgIklQIFZlcnNpb24gNiBB ZGRyZXNzaW5nCiAgICAgICAgICAgICAgQXJjaGl0ZWN0dXJlIiwgUkZDIDQyOTEsIERPSSAxMC4x NzQ4Ny9SRkM0MjkxLCBGZWJydWFyeQogICAgICAgICAgICAgIDIwMDYsIDxodHRwczovL3d3dy5y ZmMtZWRpdG9yLm9yZy9pbmZvL3JmYzQyOTE+LgoKICAgW1JGQzUyMzRdICBDcm9ja2VyLCBELiwg RWQuIGFuZCBQLiBPdmVyZWxsLCAiQXVnbWVudGVkIEJORiBmb3IgU3ludGF4CiAgICAgICAgICAg ICAgU3BlY2lmaWNhdGlvbnM6IEFCTkYiLCBTVEQgNjgsIFJGQyA1MjM0LAogICAgICAgICAgICAg IERPSSAxMC4xNzQ4Ny9SRkM1MjM0LCBKYW51YXJ5IDIwMDgsCiAgICAgICAgICAgICAgPGh0dHBz Oi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZjNTIzND4uCgogICBbUkZDODE3NF0gIExlaWJh LCBCLiwgIkFtYmlndWl0eSBvZiBVcHBlcmNhc2UgdnMgTG93ZXJjYXNlIGluIFJGQwogICAgICAg ICAgICAgIDIxMTkgS2V5IFdvcmRzIiwgQkNQIDE0LCBSRkMgODE3NCwgRE9JIDEwLjE3NDg3L1JG QzgxNzQsCiAgICAgICAgICAgICAgTWF5IDIwMTcsIDxodHRwczovL3d3dy5yZmMtZWRpdG9yLm9y Zy9pbmZvL3JmYzgxNzQ+LgoKOC4yLiAgSW5mb3JtYXRpdmUgUmVmZXJlbmNlcwoKICAgW1JGQzcy MzldICBQZXRlcnNzb24sIEEuIGFuZCBNLiBOaWxzc29uLCAiRm9yd2FyZGVkIEhUVFAgRXh0ZW5z aW9uIiwKICAgICAgICAgICAgICBSRkMgNzIzOSwgRE9JIDEwLjE3NDg3L1JGQzcyMzksIEp1bmUg MjAxNCwKICAgICAgICAgICAgICA8aHR0cHM6Ly93d3cucmZjLWVkaXRvci5vcmcvaW5mby9yZmM3 MjM5Pi4KCiAgIFtSRkM4NDk5XSAgSG9mZm1hbiwgUC4sIFN1bGxpdmFuLCBBLiwgYW5kIEsuIEZ1 aml3YXJhLCAiRE5TCiAgICAgICAgICAgICAgVGVybWlub2xvZ3kiLCBCQ1AgMjE5LCBSRkMgODQ5 OSwgRE9JIDEwLjE3NDg3L1JGQzg0OTksCiAgICAgICAgICAgICAgSmFudWFyeSAyMDE5LCA8aHR0 cHM6Ly93d3cucmZjLWVkaXRvci5vcmcvaW5mby9yZmM4NDk5Pi4KCkF1dGhvcidzIEFkZHJlc3MK CiAgIEV1Z2VuZSBBZGVsbAogICBFbWFpbDogZXVnZW5lLmFkZWxsQGdtYWlsLmNvbQoKCgoKCgoK CkFkZWxsICAgICAgICAgICAgICAgICAgICBFeHBpcmVzIDE0IE9jdG9iZXIgMjAyMiAgICAgICAg ICAgICAgIFtQYWdlIDExXQo= --000000000000f6159205dc72b762-- From nobody Tue Apr 12 05:28:18 2022 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 0830A3A1D10 for ; Tue, 12 Apr 2022 05:28:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.109 X-Spam-Level: X-Spam-Status: No, score=-7.109 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=aiven.io 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 bd_m5OIzOBwp for ; Tue, 12 Apr 2022 05:28:11 -0700 (PDT) Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) (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 6689B3A1D0D for ; Tue, 12 Apr 2022 05:28:11 -0700 (PDT) Received: by mail-ed1-x52c.google.com with SMTP id g20so22124932edw.6 for ; Tue, 12 Apr 2022 05:28:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aiven.io; s=google; h=date:from:to:cc:subject:in-reply-to:message-id:references :mime-version; bh=ytyBA7JmgTaTCBmE9sqzngRZfzByDkGgLgpSZNRVU3Q=; b=C7vYX4zQrOnVgctuvUuZcPLFQvw1hnBT3CJm6bv98RYcUfLmL6mZQtYqV3SSJWVprm ulqwOONDmvz/h83QoG4oz63n9eBtXq6NIaAdD1lpmtmycArVujPJycgBO691326Y132S q7H+8/bNsCDHeiBzgPmkklgHC+/qSODkqv+Mc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:in-reply-to:message-id :references:mime-version; bh=ytyBA7JmgTaTCBmE9sqzngRZfzByDkGgLgpSZNRVU3Q=; b=hUf7mqYF+C9i7s0t0VBV0c0I2YsBhcdE2D+hgXXLHFFbpBXLkQeKMRqSc6/94Ckx0E Z1qUbM0VLl5qjwD9JjmSWjUI+BHERAJKjcdYZNGLNM7YXpmYyhrZjaVrwELgQRcpeApC uVg/J/hkVEBXl25pYy5poC2yi2IXGV5xKrje363od8CW4w/E5jFpeuAd75TymUX+5BBe k5GCQKHUzMyuswItuXCrbiZegDLm4unmAaboXasRq3NPV28083/mgt0CzOqLaGsdYqhW 6P5rDM9dHX5rMU79MJ+u7q8fGSWy2CmZUoyJUGEfq7Qnpwb1JhGm53EtIku1KkT5MAPm UccQ== X-Gm-Message-State: AOAM53312vpp4TFVtbMXWFznrQWvNnYZKvZWeOXfRqYF4cqIU2ryeyoj 5d3B0isXCEJTTihkVUQSQThmBg== X-Google-Smtp-Source: ABdhPJxjJzlrEDh0XH0qvLHOtyiBwqb0cmwK3+MVGx7CuT42vnbRAm/+SqhpPPooQJxUau5ksTJIvQ== X-Received: by 2002:aa7:cd18:0:b0:41d:8df8:86e5 with SMTP id b24-20020aa7cd18000000b0041d8df886e5mr4046113edw.248.1649766489430; Tue, 12 Apr 2022 05:28:09 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca. [193.110.157.194]) by smtp.gmail.com with ESMTPSA id c5-20020a170906d18500b006ce371f09d4sm12968452ejz.57.2022.04.12.05.28.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 Apr 2022 05:28:08 -0700 (PDT) Date: Tue, 12 Apr 2022 08:28:06 -0400 (EDT) From: Paul Wouters To: =?ISO-8859-15?Q?Eug=E8ne_Adell?= cc: dnsop In-Reply-To: Message-ID: References: <355263CA-10A6-4AED-8622-8336A94F069A@isc.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="1858192029-1831689432-1649766488=:1240664" Archived-At: Subject: Re: [DNSOP] introducing a couple of RRTypes (CRC/CRS) for B2B applications X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2022 12:28:16 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1858192029-1831689432-1649766488=:1240664 Content-Type: text/plain; format=flowed; charset=ISO-8859-15 Content-Transfer-Encoding: 8BIT On Tue, 12 Apr 2022, Eugne Adell wrote: > Beyond the technical aspects, there are several different persons to > think about in our case : the DNS administrator obviously, the > decision maker buying (or not) a secured online service, and the CISO. Why should this information exchange happen via DNS? > It looks more simple to have dedicated RR types to let them > communicate together It seems a REST API using some .well-known HTTPS link seems a better fit ? > After your comments and correcting a typo, it gives > ftp.example.com_21.example.net > Such domain name for sure doesn't exist and uses the underscore > character as separator. It has to be considered as storing data > establishing a kind of contract between the two organizations > involved. It should have a dot in between, eg ftp.example.com._21.example.net. Then, the underscore name should be uniquely identifying to split it from other DNS records. eg _crs or something. Have a look at other documents at https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#underscored-globally-scoped-dns-node-names > 5. > I give some explanation in the answer 1 but I will rephrase. The CRS > record can be used before subscribing to a service (typically any > storage/log system/SIEM) as an indicator that this service provides > the kind of authorization process described in the document. I still wonder if DNS is really the right fit for this. > This document specifies the Client Roaming Control (CRC) DNS Resource > Record allowing an organization to better control the access to > third-party applications over Internet. The applications > implementing an authorization mechanism to honor the CRC, publish on > their side the Client Roaming Support (CRS) Resource Record to inform > of this support. There is a big overlap here with MUD, see https://datatracker.ietf.org/doc/html/rfc8520 It also seems the source of authorization depends on the DNS name, but how do you ensure a device would not be lying about their name? Would this only work on zones with static DNS entries? If so, how would that scale? What would be the mechanism to authorize the publishing of CRS/CRC records, and why can that provisioning protocol not also be used to query/signal this data? Paul --1858192029-1831689432-1649766488=:1240664-- From nobody Tue Apr 12 07:29:28 2022 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 772D73A15AD for ; Tue, 12 Apr 2022 07:29:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.108 X-Spam-Level: X-Spam-Status: No, score=-2.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 wWx2tKe4KvIE for ; Tue, 12 Apr 2022 07:29:21 -0700 (PDT) Received: from mail-yb1-xb36.google.com (mail-yb1-xb36.google.com [IPv6:2607:f8b0:4864:20::b36]) (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 15CFB3A12E8 for ; Tue, 12 Apr 2022 07:29:21 -0700 (PDT) Received: by mail-yb1-xb36.google.com with SMTP id f17so2494117ybj.10 for ; Tue, 12 Apr 2022 07:29:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=DjwJiauWIn0Kw3sTqyPy45UwcaWo922dcupOMxuFCBo=; b=lUuS6kYcMTjx0QcjKLBKiT3dklcJUIY3zifWMRbSqMMjtpBADImFsEj/HZq0poARbi 2faiSQfqzGRGwO6IyKohSkz+sI41jgJP1bxq6WjxPJC/EIsOw5s7mCbMrzTmbLnOUgwH IsoJiX47KIzPoWJjm6VJhwu83tZ7ChUOezaDohGqV1o2DRWY/YC+IB0i68i3/eY2Ghj/ F1r34KKY+ahyuRLf2wzi1q9tb2GAXT6zIna1XIkLxCi+9aKanWP/EQSWJu14cTlNC4hR 4LXGC5Rcg5SN7JuNcAQuO+b5Rlbmy4d6l9GRx3a2kc89l6PUsIuF6/Zg6pVJx48LhveA 1e2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=DjwJiauWIn0Kw3sTqyPy45UwcaWo922dcupOMxuFCBo=; b=PtnIgGwW1lToLwxa/ToWH/Y6Hh+aGgpbh9SDq4WY2boR9N1mSUtKEjcv1qnkKHwg/1 229MnWxG+2EI6wEVembIWN+moKZu5cZ0gvas8Wz06kPmvGWkZNXaJFnLT25k3Jiy5XEY 1DELdaJbd/Ej79AjaymB5Td4YT6/s/8rdh4Y2eE2ZuiMcl3PM9LaeEqvAHfvNg8LmGFD VuKZGE59MQhW6Y0tFk0XI1fuwXEc53Ib/am2X9Y2ailMfBw30cFoh3QNm5CDR2MCkg7r EvJifDCocsZh5oZw5A2Iz6f5Bi+IATXhiXxx0m9JUwq1rgwVwXaqAzFp+eOzuu7Y9eID OklA== X-Gm-Message-State: AOAM531yFQze0VswDcsGEKkE11EXuq5cbUW5WqCAjQ2Bmevxbjrif8gz s7IJ14Sem49rXJ2ui2a2Ttf5U2f3vR+nj+DYatRZVQgV X-Google-Smtp-Source: ABdhPJx0y8+/LfVyKJQKA2Wb9/Qn1cIZCBBM6fUPUR76d9Xt0Qd9x1A8JxE1j+lnDh0UMdD4Gt8kC80KFC4GTDu43hs= X-Received: by 2002:a25:1443:0:b0:63d:6c01:d26f with SMTP id 64-20020a251443000000b0063d6c01d26fmr28305052ybu.296.1649773759903; Tue, 12 Apr 2022 07:29:19 -0700 (PDT) MIME-Version: 1.0 References: <355263CA-10A6-4AED-8622-8336A94F069A@isc.org> In-Reply-To: From: =?UTF-8?Q?Eug=C3=A8ne_Adell?= Date: Tue, 12 Apr 2022 16:14:34 +0200 Message-ID: To: Paul Wouters Cc: dnsop Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [DNSOP] introducing a couple of RRTypes (CRC/CRS) for B2B applications X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2022 14:29:26 -0000 Hi Paul, in the implementation I suggested, the new DNS RR types are not used for making people (administrator, decision-maker, CISO) communicating together but as an information source that is simple enough to be understood by everyone without the need of filtering and sorting data. I commented that to explain why new types are necessary, although CRC can be replaced with APL. Why use DNS at all ? Likely many server software can be modified to use the implementation suggested, while creating dependencies to another protocol not already supported by the server looks worse. For example, it's maybe not a good idea to update an FTP or LDAP server to support HTTP only to download a text file containing these networks allowed. And they would probably still need to start by a DNS request to find that file. If the Client DNS (CRC) is lying or not configured as asked by the CISO, the client organization might expose data and it's an internal threat to this organization. If the server DNS (CRS) is lying, the client organization might complain as the contract (if any) is not honored. If all is implemented/configured correctly and one client is lying on its identity (wrong information sent during the authentication for example), there is a mismatch between its real and expected IP addresses, and no authorization at the end. The use-case I'm thinking about is indeed for static entries handled manually. In my past experience, I would say each company I worked for would have benefited of some similar entries (5~10) without thinking "big". The mechanism to authorize these records is somewhat administrative for the CRC (the decision-maker asks the CISO who in turns asks the DNS admin to add a record), and limited for the CRS (a new application is brought online, with its own domain name, and an associated CRS record). As it's intended for Business-to-business, both parts still agree by another kind of contract, and I don't any necessity to have something more for the provisioning. E.A. Le mar. 12 avr. 2022 =C3=A0 14:28, Paul Wouters a = =C3=A9crit : > > On Tue, 12 Apr 2022, Eug=C3=A8ne Adell wrote: > > > Beyond the technical aspects, there are several different persons to > > think about in our case : the DNS administrator obviously, the > > decision maker buying (or not) a secured online service, and the CISO. > > Why should this information exchange happen via DNS? > > > It looks more simple to have dedicated RR types to let them > > communicate together > > It seems a REST API using some .well-known HTTPS link seems a better > fit ? > > > After your comments and correcting a typo, it gives > > ftp.example.com_21.example.net > > Such domain name for sure doesn't exist and uses the underscore > > character as separator. It has to be considered as storing data > > establishing a kind of contract between the two organizations > > involved. > > It should have a dot in between, eg ftp.example.com._21.example.net. > Then, the underscore name should be uniquely identifying to split it > from other DNS records. eg _crs or something. Have a look at other > documents at https://www.iana.org/assignments/dns-parameters/dns-paramete= rs.xhtml#underscored-globally-scoped-dns-node-names > > > 5. > > I give some explanation in the answer 1 but I will rephrase. The CRS > > record can be used before subscribing to a service (typically any > > storage/log system/SIEM) as an indicator that this service provides > > the kind of authorization process described in the document. > > I still wonder if DNS is really the right fit for this. > > > This document specifies the Client Roaming Control (CRC) DNS Resource > > Record allowing an organization to better control the access to > > third-party applications over Internet. The applications > > implementing an authorization mechanism to honor the CRC, publish on > > their side the Client Roaming Support (CRS) Resource Record to inform > > of this support. > > There is a big overlap here with MUD, see https://datatracker.ietf.org/do= c/html/rfc8520 > > It also seems the source of authorization depends on the DNS name, but > how do you ensure a device would not be lying about their name? Would > this only work on zones with static DNS entries? If so, how would that > scale? > > What would be the mechanism to authorize the publishing of CRS/CRC > records, and why can that provisioning protocol not also be used > to query/signal this data? > > Paul From nobody Tue Apr 12 12:10:07 2022 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 931313A10F2 for ; Tue, 12 Apr 2022 12:10:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.409 X-Spam-Level: X-Spam-Status: No, score=-1.409 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.248, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] 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 FeFjNqHHec5Z for ; Tue, 12 Apr 2022 12:10:00 -0700 (PDT) Received: from mail-ej1-f54.google.com (mail-ej1-f54.google.com [209.85.218.54]) (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 DBCEC3A10EA for ; Tue, 12 Apr 2022 12:09:59 -0700 (PDT) Received: by mail-ej1-f54.google.com with SMTP id k23so39199147ejd.3 for ; Tue, 12 Apr 2022 12:09:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=h4Vu0cj8+mfTTN3FV1hrzJ0PKwDDwp9ndhHorOLMQuU=; b=f4yk08GGjeCcasin6v7GDHyJyiT76kMzXmSdG8PtqHecNeVjIVOckGIubzxt/9joF2 beLNa68XKmGePjXlmNefIvauIoPgxe0BiDTRx6Kez+LH4lu02fj+XEUnbXht5cOQ2fFZ Cik0NijGexbhvK4QdfNTerhHU7P+FopETR13MAE0hmXNC6bP3Tz7DVurYAbtMHHg00pg lGr2aAYABX5t8GdAJD13B+MqPXjUWE2xFm755xQWqbfwGaX3eDPAzCxiKBTnoJSfR4VW wB7vzOUtFXzWGRBhEDxfFa8gbyzyt7W4tJwU4wGBG7BS2wEjcWLtOJ2DE8JwdKMNolFK cJ5A== X-Gm-Message-State: AOAM532ZP702AQa9kCMl6FcFk5RZqyHI8UNGfpQWoznRi4NrWPYiXCJh 7D1Mfus/EjFNjQRrdRpUgmxt7/MojByr4Lig9Yv5MhYQ X-Google-Smtp-Source: ABdhPJzb/9D8DTwuOFg/Sxca75gy/nxbigf9nB02nb6vPwfnpqsP5AXDYx3kn4XYLEDhTOWLlD93GmyOdaXas5rY+LI= X-Received: by 2002:a17:907:7d93:b0:6da:8f57:68fa with SMTP id oz19-20020a1709077d9300b006da8f5768famr36856857ejc.42.1649790598071; Tue, 12 Apr 2022 12:09:58 -0700 (PDT) MIME-Version: 1.0 References: <66256ce9-bb9f-4534-87ff-c589566db395@www.fastmail.com> <79e252e5-6aae-5dca-2d49-3ee6aa85f558@bellis.me.uk> <31074d1e-7ec3-4851-90c6-b55f0cdc802a@beta.fastmail.com> In-Reply-To: <31074d1e-7ec3-4851-90c6-b55f0cdc802a@beta.fastmail.com> From: Erik Nygren Date: Tue, 12 Apr 2022 15:09:46 -0400 Message-ID: To: Martin Thomson Cc: dnsop WG Content-Type: multipart/alternative; boundary="0000000000008d556105dc79ce91" Archived-At: Subject: Re: [DNSOP] IANA Policy for SVCB X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2022 19:10:05 -0000 --0000000000008d556105dc79ce91 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I think Expert Review makes sense (with the expert reviewing the SHOULD around the specification). On Tue, Mar 22, 2022 at 8:34 PM Martin Thomson wrote: > I agree with Tommy. > > Selecting an expert who is able to recognize when wider review might help > is a far lower bar than the one Ray suggests might be necessary. > > On Wed, Mar 23, 2022, at 05:29, Tommy Pauly wrote: > > If this space is not extensible from non-IETF RFCs, we=E2=80=99ll have = missed > > the mark. The space is designed to be large (65K) to allow new work to > > easily use this extensibility. We don=E2=80=99t need to be too conserva= tive > > with this space. > > > > I disagree that there wouldn=E2=80=99t be good experts =E2=80=94 we hav= e authors of the > > document who have seen it through, and we have more people using this > > RR and gaining expertise. > > > > Expert review is the right balance here. > > > > Tommy > > > >> On Mar 22, 2022, at 9:24 AM, Murray S. Kucherawy > wrote: > >> > >> On Tue, Mar 22, 2022 at 9:10 AM Ray Bellis wrote: > >>> I am concerned that the set of Expert Reviewers necessary to handle > SVCB > >>> needs to have both expert DNS experience *and* detailed knowledge of > the > >>> SVCB model for this to work. > >>> > >>> I am not sure there's anybody who fits that criteria. > >> > >> Specification Required also assumes a community that can produce them, > which presumably contains the right experts. > >> > >> Are we actually moving toward IETF Review here? > >> > >> -MSK > >> _______________________________________________ > >> 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 > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > --0000000000008d556105dc79ce91 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think Expert Review makes sense (with the expert reviewing the= SHOULD around the specification).

On Tue, Mar 22, 2022 at 8:34 PM= Martin Thomson <mt@lowentropy.net<= /a>> wrote:
I= agree with Tommy.

Selecting an expert who is able to recognize when wider review might help i= s a far lower bar than the one Ray suggests might be necessary.

On Wed, Mar 23, 2022, at 05:29, Tommy Pauly wrote:
> If this space is not extensible from non-IETF RFCs, we=E2=80=99ll have= missed
> the mark. The space is designed to be large (65K) to allow new work to=
> easily use this extensibility. We don=E2=80=99t need to be too conserv= ative
> with this space.
>
> I disagree that there wouldn=E2=80=99t be good experts =E2=80=94 we ha= ve authors of the
> document who have seen it through, and we have more people using this =
> RR and gaining expertise.
>
> Expert review is the right balance here.
>
> Tommy
>
>> On Mar 22, 2022, at 9:24 AM, Murray S. Kucherawy <superuser@gmail.com> wro= te:
>>
>> On Tue, Mar 22, 2022 at 9:10 AM Ray Bellis <ray@bellis.me.uk> wrote:
>>> I am concerned that the set of Expert Reviewers necessary to h= andle SVCB
>>> needs to have both expert DNS experience *and* detailed knowle= dge of the
>>> SVCB model for this to work.
>>>
>>> I am not sure there's anybody who fits that criteria.
>>
>> Specification Required also assumes a community that can produce t= hem, which presumably contains the right experts.
>>
>> Are we actually moving toward IETF Review here?
>>
>> -MSK
>> _______________________________________________
>> DNSOP mailing list
>> DNSOP@ietf.org=
>> https://www.ietf.org/mailman/listinfo/dnsop<= br> >
> _______________________________________________
> 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
--0000000000008d556105dc79ce91-- From nobody Tue Apr 12 13:05:40 2022 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 2D9133A05F0 for ; Tue, 12 Apr 2022 13:05:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -22.609 X-Spam-Level: X-Spam-Status: No, score=-22.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 jOI2QHUx93PQ for ; Tue, 12 Apr 2022 13:05:32 -0700 (PDT) Received: from mail-yw1-x112b.google.com (mail-yw1-x112b.google.com [IPv6:2607:f8b0:4864:20::112b]) (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 BC70A3A0597 for ; Tue, 12 Apr 2022 13:05:32 -0700 (PDT) Received: by mail-yw1-x112b.google.com with SMTP id 00721157ae682-2db2add4516so342947b3.1 for ; Tue, 12 Apr 2022 13:05:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=8I8fos9i12C8L1D2f62pzxQ/0tUdUYLWqN0EiXoMKP0=; b=YglbIPmwS3HTJsLOk/MyLWU4uwQl84S8bBdwzptm33am0AVtauPe0w5u9H8+cFCZWQ RUb5Mq2DtOz+/DaVe7un1Do/Gx2pl45dLv6vDtpCvChb8lJDLhR9UAsUOGucZM0NGxkv KhgsO86u+iLNPFUGQhZ6iQYlVz2SuxpoFeiolsRDyooir3dg7SgPhMLkf3q1bK6yfiMH dhVDk3JeRJ51UZEYb8+Hz3aV8lhq4Yu7JuGXkul2IqtpFPxntwgtmQVk1RALgSOX0Yui 9WUZziVhdG6/gwFCEfPlFprsiWLOD/nYZpqiaMx+9ooxK3zZ0HpAgFPUPDj4/IxxbA+Q NhMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=8I8fos9i12C8L1D2f62pzxQ/0tUdUYLWqN0EiXoMKP0=; b=v2LfcD/h5A8iedgMXVGAk1rhZF7frTzY7WEtiyP8OGwRduh4q6FPLOQvoO8eu/uDHA WU7U0wg3fpdqhxsROnTPa1wp2Q6uTz44I6dnSX7BZ5eD/bHhFC43jZ4BZpAj5QjgsvAI d3sgxnC+I8T0+WVy1uYpkgbwauMhTS6xwIanCE2WM/aevVPzpFMwcDF9w/Mu2Ro/C6Xq yZQp4NGY5pmnbWERp6/6rvet0sjzzgeaxgFnrTXu3Kmig0MQNLkmatv6GkT0MGd/hswu RqKSXWv3ZOkjD2GVDeW4dvmI2mJR6z5F2NyTO9k3SoRG1fyK804AO32kwDvzGpq4LZqm vSLg== X-Gm-Message-State: AOAM530jN7Akn3CKJKznqVOwlfpNXwJJF/QZyZBRYEZanbXjiP7ioibN I7/gOqhnJSpBkK+HdLbAv5sEZrCHN/uz+7lDIo6BqW9WDqU= X-Google-Smtp-Source: ABdhPJwrzEsdPN1/pDmj7tNJBog/18uUONK8kASpzzhQRvWswT5LoxhU+gx2vwZBkX+1bA1C/oRNADH26akz2bN+3+E= X-Received: by 2002:a0d:e5c3:0:b0:2ec:49e1:67d7 with SMTP id o186-20020a0de5c3000000b002ec49e167d7mr7183693ywe.166.1649793931189; Tue, 12 Apr 2022 13:05:31 -0700 (PDT) MIME-Version: 1.0 References: <66256ce9-bb9f-4534-87ff-c589566db395@www.fastmail.com> <79e252e5-6aae-5dca-2d49-3ee6aa85f558@bellis.me.uk> <31074d1e-7ec3-4851-90c6-b55f0cdc802a@beta.fastmail.com> In-Reply-To: From: Eric Orth Date: Tue, 12 Apr 2022 16:05:20 -0400 Message-ID: To: dnsop WG Content-Type: multipart/alternative; boundary="00000000000038ede805dc7a953a" Archived-At: Subject: Re: [DNSOP] IANA Policy for SVCB X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2022 20:05:39 -0000 --00000000000038ede805dc7a953a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'm happy as long as things are still fast and easy enough to support new/experimental/prototype usage. I think Expert Review with the proposed stuff for that expert to review is all reasonable for that goal. If we start getting into stricter bars than Expert Review, that's where we'd have to start discussing the complexity of breaking off separate private-use and experimental blocks with a lower bar. On Tue, Apr 12, 2022 at 3:10 PM Erik Nygren wrote: > I think Expert Review makes sense (with the expert reviewing the SHOULD > around the specification). > > On Tue, Mar 22, 2022 at 8:34 PM Martin Thomson wrote: > >> I agree with Tommy. >> >> Selecting an expert who is able to recognize when wider review might hel= p >> is a far lower bar than the one Ray suggests might be necessary. >> >> On Wed, Mar 23, 2022, at 05:29, Tommy Pauly wrote: >> > If this space is not extensible from non-IETF RFCs, we=E2=80=99ll have= missed >> > the mark. The space is designed to be large (65K) to allow new work to >> > easily use this extensibility. We don=E2=80=99t need to be too conserv= ative >> > with this space. >> > >> > I disagree that there wouldn=E2=80=99t be good experts =E2=80=94 we ha= ve authors of the >> > document who have seen it through, and we have more people using this >> > RR and gaining expertise. >> > >> > Expert review is the right balance here. >> > >> > Tommy >> > >> >> On Mar 22, 2022, at 9:24 AM, Murray S. Kucherawy >> wrote: >> >> >> >> On Tue, Mar 22, 2022 at 9:10 AM Ray Bellis wrote: >> >>> I am concerned that the set of Expert Reviewers necessary to handle >> SVCB >> >>> needs to have both expert DNS experience *and* detailed knowledge of >> the >> >>> SVCB model for this to work. >> >>> >> >>> I am not sure there's anybody who fits that criteria. >> >> >> >> Specification Required also assumes a community that can produce them= , >> which presumably contains the right experts. >> >> >> >> Are we actually moving toward IETF Review here? >> >> >> >> -MSK >> >> _______________________________________________ >> >> 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 >> >> _______________________________________________ >> 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 > --00000000000038ede805dc7a953a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm happy as long as things are still fast and easy en= ough to support new/experimental/prototype usage.=C2=A0 I think Expert Revi= ew with the proposed stuff for that expert to review is all reasonable for = that goal.=C2=A0 If we start getting into stricter bars than Expert Review,= that's where we'd have to start discussing the complexity of break= ing off separate private-use and experimental blocks with a lower bar.
On Tu= e, Apr 12, 2022 at 3:10 PM Erik Nygren <erik+ietf@nygren.org> wrote:
I think Expert Review makes sense = (with the expert reviewing the SHOULD around the specification).
<= /div>
O= n Tue, Mar 22, 2022 at 8:34 PM Martin Thomson <mt@lowentropy.net> wrote:
I agree with Tommy.

Selecting an expert who is able to recognize when wider review might help i= s a far lower bar than the one Ray suggests might be necessary.

On Wed, Mar 23, 2022, at 05:29, Tommy Pauly wrote:
> If this space is not extensible from non-IETF RFCs, we=E2=80=99ll have= missed
> the mark. The space is designed to be large (65K) to allow new work to=
> easily use this extensibility. We don=E2=80=99t need to be too conserv= ative
> with this space.
>
> I disagree that there wouldn=E2=80=99t be good experts =E2=80=94 we ha= ve authors of the
> document who have seen it through, and we have more people using this =
> RR and gaining expertise.
>
> Expert review is the right balance here.
>
> Tommy
>
>> On Mar 22, 2022, at 9:24 AM, Murray S. Kucherawy <superuser@gmail.com> wro= te:
>>
>> On Tue, Mar 22, 2022 at 9:10 AM Ray Bellis <ray@bellis.me.uk> wrote:
>>> I am concerned that the set of Expert Reviewers necessary to h= andle SVCB
>>> needs to have both expert DNS experience *and* detailed knowle= dge of the
>>> SVCB model for this to work.
>>>
>>> I am not sure there's anybody who fits that criteria.
>>
>> Specification Required also assumes a community that can produce t= hem, which presumably contains the right experts.
>>
>> Are we actually moving toward IETF Review here?
>>
>> -MSK
>> _______________________________________________
>> DNSOP mailing list
>> DNSOP@ietf.org=
>> https://www.ietf.org/mailman/listinfo/dnsop<= br> >
> _______________________________________________
> 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
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
--00000000000038ede805dc7a953a-- From nobody Tue Apr 12 13:11:52 2022 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 2E8EF3A0A4E for ; Tue, 12 Apr 2022 13:11:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.107 X-Spam-Level: X-Spam-Status: No, score=-2.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 zYNuggknc_tA for ; Tue, 12 Apr 2022 13:11:38 -0700 (PDT) Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::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 B51A33A0859 for ; Tue, 12 Apr 2022 13:11:37 -0700 (PDT) Received: by mail-lj1-x235.google.com with SMTP id bn33so25469704ljb.6 for ; Tue, 12 Apr 2022 13:11:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=aIuQxsoK/4n/0YlwcBe1PPw1wLIyscFCs8P3gThuJMw=; b=gFpp2EOJdQLpqQQpfgd8PmIz63eyrPZJoNdODYsmZZf+bWl0rcwf+VBA3EjjrPp/TI QZmP4exXz5baNntpwq13mC2KVE0VoIY109VRGRVJchPQJXIQ4WTNqf/JY0VY3uHC1EAU G62MbP/TBjyCFloSixFvlwiWWNzQFYOAiJJGJkROeaDoB7/dqihyqd4OEBRfLlkcHjd+ RBG46gcF6ygqZO9abT0QnZdpTlWkwBxafKfPMwTUg11g0UZbymqvm6K/s3aZsPXhgf0K QS1BBs9UOgnmNkE/G3mGXftBtcSTDZ+3/nX8PYcoqbScXk+kLAuv2M9c+coFTZsuOJxD E2Wg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=aIuQxsoK/4n/0YlwcBe1PPw1wLIyscFCs8P3gThuJMw=; b=IhMYEPU4n0MhyLw7/JIapSiTLR8+C0BA+pUKLJjOtBzp4Jrg/W1z0AZR0fJXZtIBGW 2UswxVoKKf3dhj+bvB1NCBOacbg56G8IMhljIGjBQ8/39N0CRIvfVhwWRNeiwsRGxYQ1 O4Qm9Uo5zVCfyllP8W2HvytPwUDlIIyg/Y74ah8t0MDfCqO03gCMhQpywnReSJFPR+J7 UUPbskJRfxgnSS3k64Wpwr/wSZ+gVX2YB93xwKqtyeEQv32wz7LFWoX8BRj0m6DY8J3x P/AQ0T5TukZGPmUYjAyaRniJISPTr8VbFVTaVm7mAIOdDIPzSm+XY+TY28vvci2qS9bf MbnA== X-Gm-Message-State: AOAM533zaKIQVMjY7zYLdZUIAQ2Wice7p+LAznlBq5QBRLLj6fD5rpM4 j4kaqgDfQbIGZs5/nZ+1lL7PA/hZ3/FOd6jffppfzrbZ X-Google-Smtp-Source: ABdhPJyDPtNdsKHFdxAv661ptjhEGDwjtlhhnngYrgWmKnZ+YJ3wfxWfjbKYlsmhRNyHm3loWRZCnMEdnau9pYnUlz4= X-Received: by 2002:a2e:a588:0:b0:24b:70e2:b4a5 with SMTP id m8-20020a2ea588000000b0024b70e2b4a5mr3244269ljp.449.1649794295613; Tue, 12 Apr 2022 13:11:35 -0700 (PDT) MIME-Version: 1.0 References: <66256ce9-bb9f-4534-87ff-c589566db395@www.fastmail.com> <79e252e5-6aae-5dca-2d49-3ee6aa85f558@bellis.me.uk> <31074d1e-7ec3-4851-90c6-b55f0cdc802a@beta.fastmail.com> In-Reply-To: From: Tim Wicinski Date: Tue, 12 Apr 2022 16:11:24 -0400 Message-ID: To: Eric Orth Cc: dnsop WG Content-Type: multipart/alternative; boundary="000000000000f14d6705dc7aaa17" Archived-At: Subject: Re: [DNSOP] IANA Policy for SVCB X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2022 20:11:50 -0000 --000000000000f14d6705dc7aaa17 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Also let's ensure there are several experts like we have for new RR Types. On Tue, Apr 12, 2022 at 4:06 PM Eric Orth wrote: > I'm happy as long as things are still fast and easy enough to support > new/experimental/prototype usage. I think Expert Review with the propose= d > stuff for that expert to review is all reasonable for that goal. If we > start getting into stricter bars than Expert Review, that's where we'd ha= ve > to start discussing the complexity of breaking off separate private-use a= nd > experimental blocks with a lower bar. > > On Tue, Apr 12, 2022 at 3:10 PM Erik Nygren wrote: > >> I think Expert Review makes sense (with the expert reviewing the SHOULD >> around the specification). >> >> On Tue, Mar 22, 2022 at 8:34 PM Martin Thomson wrote= : >> >>> I agree with Tommy. >>> >>> Selecting an expert who is able to recognize when wider review might >>> help is a far lower bar than the one Ray suggests might be necessary. >>> >>> On Wed, Mar 23, 2022, at 05:29, Tommy Pauly wrote: >>> > If this space is not extensible from non-IETF RFCs, we=E2=80=99ll hav= e missed >>> > the mark. The space is designed to be large (65K) to allow new work t= o >>> > easily use this extensibility. We don=E2=80=99t need to be too conser= vative >>> > with this space. >>> > >>> > I disagree that there wouldn=E2=80=99t be good experts =E2=80=94 we h= ave authors of >>> the >>> > document who have seen it through, and we have more people using this >>> > RR and gaining expertise. >>> > >>> > Expert review is the right balance here. >>> > >>> > Tommy >>> > >>> >> On Mar 22, 2022, at 9:24 AM, Murray S. Kucherawy >>> wrote: >>> >> >>> >> On Tue, Mar 22, 2022 at 9:10 AM Ray Bellis wrote: >>> >>> I am concerned that the set of Expert Reviewers necessary to handle >>> SVCB >>> >>> needs to have both expert DNS experience *and* detailed knowledge o= f >>> the >>> >>> SVCB model for this to work. >>> >>> >>> >>> I am not sure there's anybody who fits that criteria. >>> >> >>> >> Specification Required also assumes a community that can produce >>> them, which presumably contains the right experts. >>> >> >>> >> Are we actually moving toward IETF Review here? >>> >> >>> >> -MSK >>> >> _______________________________________________ >>> >> 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 >>> >>> _______________________________________________ >>> 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 >> > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > --000000000000f14d6705dc7aaa17 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

A= lso let's ensure there are several experts like we have for new RR Type= s.=C2=A0

On Tue, Apr 12, 2022 at 4:06 PM Eric Orth <ericorth=3D40google.com@dmarc.ietf.org> wrote:
I'm happy as long as things are still fast and easy enoug= h to support new/experimental/prototype usage.=C2=A0 I think Expert Review = with the proposed stuff for that expert to review is all reasonable for tha= t goal.=C2=A0 If we start getting into stricter bars than Expert Review, th= at's where we'd have to start discussing the complexity of breaking= off separate private-use and experimental blocks with a lower bar.
On Tue, = Apr 12, 2022 at 3:10 PM Erik Nygren <erik+ietf@nygren.org> wrote:
I think Expert Revi= ew makes sense (with the expert reviewing the SHOULD around the specificati= on).

On Tue, Mar 22, 2022 at 8:34 PM Martin Thomson <mt@lowentropy.net> w= rote:
I agree wi= th Tommy.

Selecting an expert who is able to recognize when wider review might help i= s a far lower bar than the one Ray suggests might be necessary.

On Wed, Mar 23, 2022, at 05:29, Tommy Pauly wrote:
> If this space is not extensible from non-IETF RFCs, we=E2=80=99ll have= missed
> the mark. The space is designed to be large (65K) to allow new work to=
> easily use this extensibility. We don=E2=80=99t need to be too conserv= ative
> with this space.
>
> I disagree that there wouldn=E2=80=99t be good experts =E2=80=94 we ha= ve authors of the
> document who have seen it through, and we have more people using this =
> RR and gaining expertise.
>
> Expert review is the right balance here.
>
> Tommy
>
>> On Mar 22, 2022, at 9:24 AM, Murray S. Kucherawy <superuser@gmail.com> wro= te:
>>
>> On Tue, Mar 22, 2022 at 9:10 AM Ray Bellis <ray@bellis.me.uk> wrote:
>>> I am concerned that the set of Expert Reviewers necessary to h= andle SVCB
>>> needs to have both expert DNS experience *and* detailed knowle= dge of the
>>> SVCB model for this to work.
>>>
>>> I am not sure there's anybody who fits that criteria.
>>
>> Specification Required also assumes a community that can produce t= hem, which presumably contains the right experts.
>>
>> Are we actually moving toward IETF Review here?
>>
>> -MSK
>> _______________________________________________
>> DNSOP mailing list
>> DNSOP@ietf.org=
>> https://www.ietf.org/mailman/listinfo/dnsop<= br> >
> _______________________________________________
> 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
_______________________________________________
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
--000000000000f14d6705dc7aaa17-- From nobody Wed Apr 13 09:37:46 2022 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 3B0473A17DC for ; Wed, 13 Apr 2022 09:37:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.106 X-Spam-Level: X-Spam-Status: No, score=-2.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari.net 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 s_Oa7GyDmlJ1 for ; Wed, 13 Apr 2022 09:37:40 -0700 (PDT) Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com [IPv6:2a00:1450:4864:20::633]) (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 876AC3A17DB for ; Wed, 13 Apr 2022 09:37:40 -0700 (PDT) Received: by mail-ej1-x633.google.com with SMTP id lc2so5057044ejb.12 for ; Wed, 13 Apr 2022 09:37:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari.net; s=google; h=mime-version:from:date:message-id:subject:to; bh=56WmDZUEh1oTqb3AYmNgnkig/jOdtr8zUBuOXILCysM=; b=cd1q8QbN7XjQcnR98QjcurDoQHqGWhb5qvLdH5vMURNHLOx8n/a+ePttQz4BISzbpz ojBGilgnZUoKBaMcLPikOX4CyorYolAypqZGYTsRWsoJ5k9QO6rw1Tfug7PNk/ym0cdX mxTKNtDTLrvs5umIMunfNNLb6nqqy4zAPLZIPVz1GxPncAKrA7NbM/tyw70teEnyHguh zbONiOnSJ13pApXbMulyzvTnq0QGzRRVzqPA4rjQ5O9ghmWz6wuWUOZoQvbHHnQVWX2k 00vmCWbnR32ORsuK/clkA2n7lhJLBDvrCkuSfWTsNDybW2rzI5ZJtZwcKkh0j3si/q5Q /f4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=56WmDZUEh1oTqb3AYmNgnkig/jOdtr8zUBuOXILCysM=; b=jMEbwUwsfuppHX6gECfJy9PSwD9lT81M+hs/Ci5Cy+GIwGt0tP3fUXVNitxY9zoBdy tlkHNEP/6PJkNB1bXnWIWuFAxHlhK+6TH00P3V7UzSgS4GcORGvrhtPzVPxZ4jdpEaiX MjpfbOXVlikdgXJcDnh8+RkVHk82lOmjR107otVLsgMdLOLaXsB9TMQ8oa8SqKvMrazM DnRkF9TQXISlYHD7nA8SIVslneOuCbFuo4ctBLjl1uKnvsJcph2v4ZZiuHftgJovNoNJ /xbZC6oYi87mr8r8dlhTedRJB4VgGJ2ehMsuak8rqAkK7KHDAQmm1fhPLbxfS15Mdczn 2Nlw== X-Gm-Message-State: AOAM531si/wnZRHyNFfL1Fbf/XcedheuawalJBaGJcpeE53oO7HERU1/ VeScey9QGSvZ9pAVOck10oBgVs5lVcvyvxRTyG4C+A== X-Google-Smtp-Source: ABdhPJzDL0hsIO+Rb/S6sYF1c++7qtmopUVxbvxnzBzhUZdOwCGAgCMk//n+hRcsxUdh8gbmgUYzv47qcq9yvMnxVys= X-Received: by 2002:a17:907:7b92:b0:6db:71f1:fc20 with SMTP id ne18-20020a1709077b9200b006db71f1fc20mr38443294ejc.343.1649867857086; Wed, 13 Apr 2022 09:37:37 -0700 (PDT) Received: from 649336022844 named unknown by gmailapi.google.com with HTTPREST; Wed, 13 Apr 2022 09:37:35 -0700 Mime-Version: 1.0 X-Superhuman-ID: l1xspkgk.fea655e2-c3d0-4485-bca9-6e4ef0b6d877 X-Superhuman-Draft-ID: draft009dd8d3b63c8c55 X-Superhuman-Thread-ID: draft00e683a07df3c2ee X-Mailer: Superhuman Desktop (2022-04-12T22:06:10Z) From: Warren Kumari Date: Wed, 13 Apr 2022 09:37:35 -0700 Message-ID: To: draft-ietf-dnsop-nsec3-guidance@ietf.org, dnsop Content-Type: multipart/alternative; boundary="0000000000008c650905dc8bcbb6" Archived-At: Subject: [DNSOP] AD Review of: draft-ietf-dnsop-nsec3-guidance X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2022 16:37:45 -0000 --0000000000008c650905dc8bcbb6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi there, authors (and WG), Thank you for this document, I found it clear, useful, and an easy read. I do have a few comments/nits; addressing these now should help the IETF LC and IESG evaluation go more smoothly. Please SHOUT loudly once you've had a chance to address these, and I'll start IETF LC. Comments / questions: ------------------------------------ Abstract: "NSEC3 is a DNSSEC mechanism providing proof of non-existence by promising there are no names that exist between two domainnames within a zone." The "promising" in this feels a little odd to me =E2=80=94 RFC4033 Sec 12 s= ays that "NSEC RRs **assert** which names do not exist..". RFC5155 talks about "showing" that names don't exist =E2=80=94 perhaps "by asserting that there= are=E2=80=A6" would be better? I'm (of course) happy to be told that "promising" was chosen for a reason and that it's the right term. Nits: ---------- Global: The document uses the term 'domainname' - RFC8499 uses 'domain name'. Looking through published RFCs, there are ~6200 instances of 'domain name', ~400 of 'domain-name' and <50 domainname (and many are in things like ABNF). I'd suggest s/domainname/domain name/g. Section 1 - Introduction Use of the opt-out feature allow large registries to only sign as many NSEC= 3 [O] allow [P] allows records as there are signed DS or other RRsets in the zone - with opt-out, unsigned delegations don't require additional NSEC3 records. [O] zone - with [P] zone; with [R] readability/grammar Section 2.4 - Salt This is true both when resigning the entire zone at once, or when incrementally signing it in the background where the new salt is only activated once every name in the chain has been completed. [O]: or [P]: and [C]: When using 'both' as a conjunction, it is 'both =E2=80=A6 and', not 'b= oth =E2=80=A6 or'; if this doesn't work, perhaps 'either =E2=80=A6 or'. ----- Thank you again; I know that making edits to address nits can be annoying, but we are expecting many people to read and review the document, and so having it polished is important and polite (also, once people start commenting on nits, they seem to continue :-) ) W --0000000000008c650905dc8bcbb6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi t= here, authors (and WG),


Thank you for this document, I found it clear, useful, an= d an easy read.


I do have = a few comments/nits; addressing these now should help the IETF LC and IESG = evaluation go more smoothly.


Please SHOUT loudly once y= ou've had a chance to address these, and I'll start IETF LC.


Comments / questions:=C2=A0

-------------------= -----------------
Abstract:
&= quot;NSEC3 is a DNSSEC mechanism providing proof of non-existence by promis= ing there are no names that exist between two domainnames within a zone.&qu= ot;

The "promising&= quot; in this feels a little odd to me =E2=80=94 RFC4033 Sec 12 says that &= quot;NSEC RRs **assert** which names do not exist..". RFC5155 talks ab= out "showing" that names don't exist =E2=80=94 perhaps "= by asserting that there are=E2=80=A6" would be better?

I'm (of course) happy to be told th= at "promising" was chosen for a reason and that it's the righ= t term.


Nits:
----------
Gl= obal:
The document uses the term 'domainname&#= 39; - RFC8499 uses 'domain name'. Looking through published RFCs, t= here are ~6200 instances of 'domain name', ~400 of 'domain-name= ' and <50=C2=A0domainname (and many are in things like ABNF). I'= d suggest s/domainname/domain name/g.


Section 1 - Introduction
<= div class=3D"">Use of the opt-out feature allow large registries to only si= gn as many NSEC3
[O] allow
[P] allows

=C2=A0recor= ds as there are signed DS or other RRsets in the zone - with=C2=A0opt-out, = unsigned delegations don't require additional NSEC3 records.
<= div class=3D"">
[O] zone - with
[P] zone; with
[R] readability/grammar
<= /div>


Se= ction 2.4 - Salt
This is true both when resigning = the entire zone at once, or when incrementally signing it in the background= where the=C2=A0 new salt is only activated once every name in the chain ha= s been=C2=A0completed.
[O]: or
[P]: and
[C]: When using 'both' as a= conjunction, it is 'both =E2=80=A6 and', not 'both =E2=80=A6 o= r'; if this doesn't work, perhaps 'either =E2=80=A6 or'.=C2= =A0

-----

Thank you again; I know that making edits = to address nits can be annoying, but we are expecting many people to read a= nd review the document, and so having it polished is important and polite (= also, once people start commenting on nits, they seem to continue :-) )
=
W


--0000000000008c650905dc8bcbb6-- From nobody Wed Apr 13 10:36:47 2022 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 77F093A1BB3 for ; Wed, 13 Apr 2022 10:36:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.107 X-Spam-Level: X-Spam-Status: No, score=-7.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 6faTsjziFh9z for ; Wed, 13 Apr 2022 10:36:40 -0700 (PDT) Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (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 A9F703A1BAE for ; Wed, 13 Apr 2022 10:36:39 -0700 (PDT) Received: by mail-lf1-x12c.google.com with SMTP id bu29so4919024lfb.0 for ; Wed, 13 Apr 2022 10:36:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=jZmhyMlz2WhSFb1/W7RQh6U4KzikqlsYqZOmNQJBgq8=; b=XkP5kwUlUbLMcvQBN7r67yNwM9wGGBMT31O9ixew1GmOMQS6SURklLThXP95Qq+who TBaq1+l6yIIeK7tL94oJ08FpzpeKrAOeArQXj7fyn7QqAWjkS3taZvoUeTD9Cm2CgqHm 3eMF1sax25zfQ0C+vGt5j7CTJKBO8xsGFKr2OBxqjVBQ5DgjMbKUpA4lKsi2Q3QarPLW eEjlxPW1DK1z2yDahkDO4ATw9zPcydBh5FLENFCLvdPeam4aMAcaOI4mn+pMBo1di0Ch Rw/TR7x9TZsNAyHK5a4a+HXyAT9PssovOXG410K64XqO6tLIVY8dr8MwTmPVJVFGnrZM UsPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=jZmhyMlz2WhSFb1/W7RQh6U4KzikqlsYqZOmNQJBgq8=; b=lt4PF/eZR4ufACKhjo8Ulnra2YaX9vTsNFO/Cdx93+pAVJpsSFsMzfFvb3jjcfCHL+ Z0wKEExnqbW8YoRSMPi6D2ipUMZ7nt/byV+peMYavN2i073V/aAj+J1O2J6t8BRjtRPK dxOfJcYGc6nnB5rd8t61vaN5Rx70prU+pfm4OHmIt8S1F1RxCybTLnDjDisXJxRUYwq+ SQXP7619tnoJ40Si3VjxcdlaqO3njGx7D2EzwLCJwIYS3G+/xxtNDp6F0k72pIFny5Di Wh38B5H8PnK2WyH74WX8z9fIPbQHEaU7GLy/KTgk5PNVj98/PYXqfVYgOEPX1Mm/0Tfb 3QWw== X-Gm-Message-State: AOAM530iNQkcn39c0TEqUpxuaL+/V4JIMCNBK24MdM5PKqC+NaX0JB+n em6mJle+pVQ6EenVm27G+D3jy81za7RQDgwpeeTVErXCysc= X-Google-Smtp-Source: ABdhPJyNI81eqiA+LSC9x3ljS6DVzinggr0eM0ETCjryRPs0G0bhJrfWr2OmaefCTpS/IN+jkcJknv57rtNA1cBd14s= X-Received: by 2002:a05:6512:1046:b0:46b:eb4f:e597 with SMTP id c6-20020a056512104600b0046beb4fe597mr3370382lfb.493.1649871397185; Wed, 13 Apr 2022 10:36:37 -0700 (PDT) MIME-Version: 1.0 From: Tim Wicinski Date: Wed, 13 Apr 2022 13:36:25 -0400 Message-ID: To: dnsop Content-Type: multipart/alternative; boundary="0000000000008dee5005dc8c9e6e" Archived-At: Subject: [DNSOP] additional documents for draft-ietf-dnsop-dnssec-bcp X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2022 17:36:45 -0000 --0000000000008dee5005dc8c9e6e Content-Type: text/plain; charset="UTF-8" All During the call for adoption, a few folks mentioned other DNSSEC documents (7129 comes to mind). While I trust Mr. Hoffman's attention to detail, I wanted to do a quick check to make sure nothing slipped by. I pulled this list from rfc-editor.org of every RFC with DNSSEC as a keyword or in the title. https://gist.github.com/moonshiner/0746776f2351ae9c8e3edb3373ee39c6 The ones marked "No" were made by me. Feel free to say otherwise. However, I left 8 RFCs undecided. If the WG has any opinions on those, please feel free to speak up. thanks tim --0000000000008dee5005dc8c9e6e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
All
During= the call for adoption, a few folks mentioned other DNSSEC documents=C2=A0(= 7129 comes to mind).=C2=A0 While I trust Mr. Hoffman's attention to det= ail, I wanted to do a quick check to make sure nothing=C2=A0slipped by.=C2= =A0

<= /div>
I pulled = this list from rfc-editor.org of ever= y RFC with DNSSEC as a keyword or in the title.=C2=A0

https://gist.github.com/moons= hiner/0746776f2351ae9c8e3edb3373ee39c6

The ones marked "No" were made = by me. Feel free to say otherwise.=C2=A0

However, I left 8 RFCs undecided.=C2=A0 If the = WG has any opinions on those, please feel free to speak up.=C2=A0


thanks
tim
--0000000000008dee5005dc8c9e6e-- From nobody Wed Apr 13 11:04:11 2022 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 D2CA53A1D9D; Wed, 13 Apr 2022 11:04:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 n9Mk1r9d-1W2; Wed, 13 Apr 2022 11:04:07 -0700 (PDT) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (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 F05D83A1D9A; Wed, 13 Apr 2022 11:04:06 -0700 (PDT) Received: by straasha.imrryr.org (Postfix, from userid 1001) id 15FA0E6713; Wed, 13 Apr 2022 14:04:05 -0400 (EDT) Date: Wed, 13 Apr 2022 14:04:05 -0400 From: Viktor Dukhovni To: Warren Kumari Cc: draft-ietf-dnsop-nsec3-guidance@ietf.org, dnsop Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Archived-At: Subject: Re: [DNSOP] AD Review of: draft-ietf-dnsop-nsec3-guidance X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2022 18:04:09 -0000 On Wed, Apr 13, 2022 at 09:37:35AM -0700, Warren Kumari wrote: > ------------------------------------ > Abstract: > "NSEC3 is a DNSSEC mechanism providing proof of non-existence by promising > there are no names that exist between two domainnames within a zone." > > The "promising" in this feels a little odd to me — RFC4033 Sec 12 says that > "NSEC RRs **assert** which names do not exist..". RFC5155 talks about > "showing" that names don't exist — perhaps "by asserting that there are…" > would be better? > > I'm (of course) happy to be told that "promising" was chosen for a reason > and that it's the right term. Thanks, I think "asserting" is better. > Nits: > ---------- > Global: > The document uses the term 'domainname' - RFC8499 uses 'domain name'. > Looking through published RFCs, there are ~6200 instances of 'domain name', > ~400 of 'domain-name' and <50 domainname (and many are in things like > ABNF). I'd suggest s/domainname/domain name/g. Thanks. No objections. > Section 1 - Introduction > Use of the opt-out feature allow large registries to only sign as many NSEC3 > [O] allow > [P] allows Yep. > records as there are signed DS or other RRsets in the zone - with opt-out, > unsigned delegations don't require additional NSEC3 records. > > [O] zone - with > [P] zone; with > [R] readability/grammar Yep. > Section 2.4 - Salt > This is true both when resigning the entire zone at once, or when > incrementally signing it in the background where the new salt is only > activated once every name in the chain has been completed. > [O]: or > [P]: and > [C]: When using 'both' as a conjunction, it is 'both … and', not 'both … > or'; if this doesn't work, perhaps 'either … or'. Yep. > Thank you again; I know that making edits to address nits can be annoying, > but we are expecting many people to read and review the document, and so > having it polished is important and polite (also, once people start > commenting on nits, they seem to continue :-) ) Much appreciated. -- Viktor. From nobody Wed Apr 13 11:04:58 2022 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 9F59E3A1DE6 for ; Wed, 13 Apr 2022 11:04:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=unavailable 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 d86KrKrfpFYs for ; Wed, 13 Apr 2022 11:04:53 -0700 (PDT) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (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 A64033A1DF6 for ; Wed, 13 Apr 2022 11:04:50 -0700 (PDT) Received: by straasha.imrryr.org (Postfix, from userid 1001) id 7401AE6785; Wed, 13 Apr 2022 14:04:49 -0400 (EDT) Resent-From: Viktor Dukhovni Resent-Date: Wed, 13 Apr 2022 14:04:49 -0400 Resent-Message-ID: Resent-To: dnsop@ietf.org Date: Wed, 13 Apr 2022 14:04:05 -0400 From: Viktor Dukhovni To: Warren Kumari Cc: draft-ietf-dnsop-nsec3-guidance@ietf.org, dnsop Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Archived-At: Subject: Re: [DNSOP] AD Review of: draft-ietf-dnsop-nsec3-guidance X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2022 18:04:57 -0000 On Wed, Apr 13, 2022 at 09:37:35AM -0700, Warren Kumari wrote: > ------------------------------------ > Abstract: > "NSEC3 is a DNSSEC mechanism providing proof of non-existence by promising > there are no names that exist between two domainnames within a zone." > > The "promising" in this feels a little odd to me — RFC4033 Sec 12 says that > "NSEC RRs **assert** which names do not exist..". RFC5155 talks about > "showing" that names don't exist — perhaps "by asserting that there are…" > would be better? > > I'm (of course) happy to be told that "promising" was chosen for a reason > and that it's the right term. Thanks, I think "asserting" is better. > Nits: > ---------- > Global: > The document uses the term 'domainname' - RFC8499 uses 'domain name'. > Looking through published RFCs, there are ~6200 instances of 'domain name', > ~400 of 'domain-name' and <50 domainname (and many are in things like > ABNF). I'd suggest s/domainname/domain name/g. Thanks. No objections. > Section 1 - Introduction > Use of the opt-out feature allow large registries to only sign as many NSEC3 > [O] allow > [P] allows Yep. > records as there are signed DS or other RRsets in the zone - with opt-out, > unsigned delegations don't require additional NSEC3 records. > > [O] zone - with > [P] zone; with > [R] readability/grammar Yep. > Section 2.4 - Salt > This is true both when resigning the entire zone at once, or when > incrementally signing it in the background where the new salt is only > activated once every name in the chain has been completed. > [O]: or > [P]: and > [C]: When using 'both' as a conjunction, it is 'both … and', not 'both … > or'; if this doesn't work, perhaps 'either … or'. Yep. > Thank you again; I know that making edits to address nits can be annoying, > but we are expecting many people to read and review the document, and so > having it polished is important and polite (also, once people start > commenting on nits, they seem to continue :-) ) Much appreciated. -- Viktor. From nobody Wed Apr 13 11:49:48 2022 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 7C61A3A178F for ; Wed, 13 Apr 2022 11:49:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.107 X-Spam-Level: X-Spam-Status: No, score=-2.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] 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 zq-ZEVSQ2mpL for ; Wed, 13 Apr 2022 11:49:40 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.85]) (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 52CA23A1785 for ; Wed, 13 Apr 2022 11:49:39 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4Kds8K4CqRz3FG; Wed, 13 Apr 2022 20:49:37 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1649875777; bh=eXyreajSagz3EwS9rbrwnX3Bj1BuSoxNiWckKqt+1uU=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=if8NkG21zMneOwj9PN/SqNuquJ+uwCJV1C4jRnS75Ax3pClqbuk5ymnJc7//fYB8O XGyd0W28dF5YmhkqicO4HsNWpzvkXVHfy+qdobSfoUTl/slodn5E7bGKpgPmbdXiE5 KypaLYHcVfxd8/ONZpyK6Be5M5gyIzeH43m9XT88= 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 70CVYBNq-RJt; Wed, 13 Apr 2022 20:49:35 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 13 Apr 2022 20:49:35 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 5E6782E1B1B; Wed, 13 Apr 2022 14:49:34 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 5B34A2E1B1A; Wed, 13 Apr 2022 14:49:34 -0400 (EDT) Date: Wed, 13 Apr 2022 14:49:34 -0400 (EDT) From: Paul Wouters To: Tim Wicinski cc: dnsop In-Reply-To: Message-ID: <93145d8b-3f90-4acd-f56f-7eec2985114e@nohats.ca> References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Subject: Re: [DNSOP] additional documents for draft-ietf-dnsop-dnssec-bcp X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2022 18:49:46 -0000 On Wed, 13 Apr 2022, Tim Wicinski wrote: [speaking as individual contributor] > Subject: [DNSOP] additional documents for draft-ietf-dnsop-dnssec-bcp > During the call for adoption, a few folks mentioned other DNSSEC documents (7129 comes to mind).  While I trust Mr. Hoffman's > attention to detail, I wanted to do a quick check to make sure nothing slipped by.  > > I pulled this list from rfc-editor.org of every RFC with DNSSEC as a keyword or in the title.  > > https://gist.github.com/moonshiner/0746776f2351ae9c8e3edb3373ee39c6 > > The ones marked "No" were made by me. Feel free to say otherwise.  > > However, I left 8 RFCs undecided.  If the WG has any opinions on those, please feel free to speak up.  If we do it as both a reference of DNSSEC and a BCP, then I think we should add: RFC 8901 Multi-Signer DNSSEC Models RFC 8027 a.k.a. BCP 207 DNSSEC Roadblock Avoidance RFC 7583 DNSSEC Key Rollover Timing Considerations RFC 7129 Authenticated Denial of Existence in the DNS RFC 4470 Minimally Covering NSEC Records and DNSSEC On-line Signing I would not include these that you included: RFC 9157 Revised IANA Considerations for DNSSEC [It's IETF administrivia] RFC 6014 Cryptographic Algorithm Identifier Allocation for DNSSEC [It's IETF administrivia] RFC 5933 Use of GOST Signature Algorithms in DNSKEY and RRSIG Resource Records for DNSSEC [Algo is dead] Otherwise, I agree with you. Paul From nobody Wed Apr 13 14:36:44 2022 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 050453A10B3 for ; Wed, 13 Apr 2022 14:36:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 duEc7RdBNB9H for ; Wed, 13 Apr 2022 14:36:35 -0700 (PDT) Received: from ppa3.lax.icann.org (ppa3.lax.icann.org [192.0.33.78]) (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 A402C3A10BA for ; Wed, 13 Apr 2022 14:36:35 -0700 (PDT) Received: from MBX112-W2-CO-1.pexch112.icann.org (out.mail.icann.org [64.78.33.5]) by ppa3.lax.icann.org (8.16.0.43/8.16.0.43) with ESMTPS id 23DLaYNZ003324 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 13 Apr 2022 21:36:34 GMT Received: from MBX112-W2-CO-1.pexch112.icann.org (10.226.41.128) by MBX112-W2-CO-1.pexch112.icann.org (10.226.41.128) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.22; Wed, 13 Apr 2022 14:36:33 -0700 Received: from MBX112-W2-CO-1.pexch112.icann.org ([10.226.41.128]) by MBX112-W2-CO-1.pexch112.icann.org ([10.226.41.128]) with mapi id 15.02.0986.022; Wed, 13 Apr 2022 14:36:33 -0700 From: Paul Hoffman To: dnsop Thread-Topic: [Ext] [DNSOP] additional documents for draft-ietf-dnsop-dnssec-bcp Thread-Index: AQHYT36LOPl4P/slxk6IlztBV4Eg1A== Date: Wed, 13 Apr 2022 21:36:33 +0000 Message-ID: <27038065-4FF1-4BDA-A443-FA00CC2DD102@icann.org> References: <93145d8b-3f90-4acd-f56f-7eec2985114e@nohats.ca> In-Reply-To: <93145d8b-3f90-4acd-f56f-7eec2985114e@nohats.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [192.0.32.234] x-source-routing-agent: Processed Content-Type: multipart/signed; boundary="Apple-Mail=_5A3099C5-1C18-45EB-8E89-16D54C0610FD"; protocol="application/pkcs7-signature"; micalg=sha-256 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.486, 18.0.858 definitions=2022-04-13_04:2022-04-13, 2022-04-13 signatures=0 Archived-At: Subject: Re: [DNSOP] [Ext] additional documents for draft-ietf-dnsop-dnssec-bcp X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2022 21:36:40 -0000 --Apple-Mail=_5A3099C5-1C18-45EB-8E89-16D54C0610FD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 13, 2022, at 11:49 AM, Paul Wouters wrote: > If we do it as both a reference of DNSSEC and a BCP, then I think we = should add: >=20 > RFC 8901 Multi-Signer DNSSEC Models > RFC 8027 a.k.a. BCP 207 DNSSEC Roadblock Avoidance > RFC 7583 DNSSEC Key Rollover Timing Considerations > RFC 7129 Authenticated Denial of Existence in the DNS > RFC 4470 Minimally Covering NSEC Records and DNSSEC On-line = Signing >=20 > I would not include these that you included: >=20 > RFC 9157 Revised IANA Considerations for DNSSEC [It's IETF = administrivia] > RFC 6014 Cryptographic Algorithm Identifier Allocation for DNSSEC = [It's IETF administrivia] > RFC 5933 Use of GOST Signature Algorithms in DNSKEY and RRSIG = Resource Records for DNSSEC [Algo is dead] >=20 > Otherwise, I agree with you. I agree with PaulW's list of inclusions. I would say that RFC 9157 and = RFC 6014 should still be in draft-ietf-dnsop-dnssec-bcp, but in a = separate section for those readers who care about the IANA registries. = RFC 5933 is not yet dead, but will be before draft-ietf-dnsop-dnssec-bcp = is published. I would add the following that are listed as blank in Tim's chart: RFC 6975 Signaling Cryptographic Algorithm Understanding in DNS = Security Extensions (DNSSEC) Relevant RFC 6725 DNS Security (DNSSEC) DNSKEY Algorithm IANA Registry = Updates For the IANA-ish section I do not understand why the following and are listed as "No", given that = they relate to the DNSSEC trust anchors, and thus are relevant to = implementors. I would say they all should be listed: RFC 8509 A Root Key Trust Anchor Sentinel for DNSSEC RFC 8145 Signaling Trust Anchor Knowledge in DNS Security = Extensions (DNSSEC) RFC 7958 DNSSEC Trust Anchor Publication for the Root Zone RFC 7646 Definition and Use of DNSSEC Negative Trust Anchors (I agree that RFC 4986 does not need to be in the draft because it is = just requirements.) Because we are talking about this in light of adding a section to = draft-ietf-dnsop-dnssec-bcp, the following can be excluded because they = are already in the draft: RFC 9077 RFC 8624 RFC 8198 RFC 8078 RFC 7344 RFC 6840 RFC 6781 RFC 5702 RFC 5155 RFC 5011 RFC 4509 RFC 4035 RFC 4034 RFC 4033 --Paul Hoffman --Apple-Mail=_5A3099C5-1C18-45EB-8E89-16D54C0610FD Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCBrYw ggayMIIFmqADAgECAhMwAAAX4ZqelQKZcEdTAAMAABfhMA0GCSqGSIb3DQEBCwUAMF8xEzARBgoJ kiaJk/IsZAEZFgNvcmcxFTATBgoJkiaJk/IsZAEZFgVpY2FubjESMBAGCgmSJomT8ixkARkWAmRz MR0wGwYDVQQDExRhZDEtbGF4LmRzLmljYW5uLm9yZzAeFw0yMTA1MjAxNTAxMzNaFw0yMzA1MjAx NTAxMzNaMIGUMRMwEQYKCZImiZPyLGQBGRYDb3JnMRUwEwYKCZImiZPyLGQBGRYFaWNhbm4xEjAQ BgoJkiaJk/IsZAEZFgJkczEUMBIGA1UECxMLSUNBTk4tVXNlcnMxFTATBgNVBAMTDFBhdWwgSG9m Zm1hbjElMCMGCSqGSIb3DQEJARYWcGF1bC5ob2ZmbWFuQGljYW5uLm9yZzCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBALtvlgd1mCsDZcUXiDdEtqqeklaJa3MfG8v1RMIKaVSaK3dsq2gA JujPfGwUdRIne4Tz6HJqPXBYEzVkgUdxdFXu/xPzfZei+fRb7zeVA9sMTrKl9gQ31Q0cw5VbmJzG P41Lxq2ruCyX/cGiru1PG4VVN72f9w1lpBt4rhRYpi5f2DDRmNm01teEoNOdvQ6PavUJVWrLVDI0 Z+uF4oe51yriMBQntRw9XenckW2yDa9ob3DlmOYKdZp1mNv2f+XB1Uc4xZSpJMFly/nxd0hIvkmi GrG0+puC0+OyDV4z1JIURBIx2RnXEJxYvaFPID5g/IT7MtFqQnLKIZTJc2DXySECAwEAAaOCAy8w ggMrMB0GA1UdDgQWBBRXoW6yUY7G6nMFSxU+2lZm7KqcvDAfBgNVHSMEGDAWgBTpKerCBbuXyks/ cnl6+luCS7lqhDCB2QYDVR0fBIHRMIHOMIHLoIHIoIHFhoHCbGRhcDovLy9DTj1hZDEtbGF4LmRz LmljYW5uLm9yZygxKSxDTj1hZDEtbGF4LENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNl cyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPWRzLERDPWljYW5uLERDPW9yZz9jZXJ0 aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9p bnQwgcoGCCsGAQUFBwEBBIG9MIG6MIG3BggrBgEFBQcwAoaBqmxkYXA6Ly8vQ049YWQxLWxheC5k cy5pY2Fubi5vcmcsQ049QUlBLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2Vz LENOPUNvbmZpZ3VyYXRpb24sREM9ZHMsREM9aWNhbm4sREM9b3JnP2NBQ2VydGlmaWNhdGU/YmFz ZT9vYmplY3RDbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MA4GA1UdDwEB/wQEAwIFoDA9Bgkr BgEEAYI3FQcEMDAuBiYrBgEEAYI3FQiBurJNhMjIaoOtkz+HlPRag/mIbk6H68s/hoOYWgIBZAIB BzApBgNVHSUEIjAgBgorBgEEAYI3CgMEBggrBgEFBQcDBAYIKwYBBQUHAwIwNQYJKwYBBAGCNxUK BCgwJjAMBgorBgEEAYI3CgMEMAoGCCsGAQUFBwMEMAoGCCsGAQUFBwMCMEkGA1UdEQRCMECgJgYK KwYBBAGCNxQCA6AYDBZwYXVsLmhvZmZtYW5AaWNhbm4ub3JngRZwYXVsLmhvZmZtYW5AaWNhbm4u b3JnMEQGCSqGSIb3DQEJDwQ3MDUwDgYIKoZIhvcNAwICAgCAMA4GCCqGSIb3DQMEAgIAgDAHBgUr DgMCBzAKBggqhkiG9w0DBzANBgkqhkiG9w0BAQsFAAOCAQEAetxZFQDQ4/o0w3yjeD1PEIf4QJU3 vLp3QHq5I0I3ogj7UTGxAUudkuz7ttpb7K9HtBWRcbhyFY9blGQ2FLScWMBQkg1GO5pIwGSAkFGj iLPcyihxOASMrI1TBGaPuHUeMfOhqYl1tYgLWnabrd2mjjSLJHvJHJQ7ZSAexjGLhoFoj8/sVPk1 JIOvOOtIWZ3lky3eYI4Q7NYI4p9sHE6CAeOX52gpdvpVphaktfKZhGbIbeQiQTmdkcvOklHr6xHE CKXbhVZqEzOQtSxbsoGUOascj3k7PwFZPmWH/aQbnINDyqo97A++tKkSyVbmKbCeOORbH5hIGpYg CshNrXTOsTGCAyAwggMcAgEBMHYwXzETMBEGCgmSJomT8ixkARkWA29yZzEVMBMGCgmSJomT8ixk ARkWBWljYW5uMRIwEAYKCZImiZPyLGQBGRYCZHMxHTAbBgNVBAMTFGFkMS1sYXguZHMuaWNhbm4u b3JnAhMwAAAX4ZqelQKZcEdTAAMAABfhMA0GCWCGSAFlAwQCAQUAoIIBezAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMjA0MTMyMTM2MzNaMC8GCSqGSIb3DQEJBDEi BCAyA0UBnxqMDdWdQ0EnLvIUuUgtQLfE8xMMQxee/xqUfjCBhQYJKwYBBAGCNxAEMXgwdjBfMRMw EQYKCZImiZPyLGQBGRYDb3JnMRUwEwYKCZImiZPyLGQBGRYFaWNhbm4xEjAQBgoJkiaJk/IsZAEZ FgJkczEdMBsGA1UEAxMUYWQxLWxheC5kcy5pY2Fubi5vcmcCEzAAABfhmp6VAplwR1MAAwAAF+Ew gYcGCyqGSIb3DQEJEAILMXigdjBfMRMwEQYKCZImiZPyLGQBGRYDb3JnMRUwEwYKCZImiZPyLGQB GRYFaWNhbm4xEjAQBgoJkiaJk/IsZAEZFgJkczEdMBsGA1UEAxMUYWQxLWxheC5kcy5pY2Fubi5v cmcCEzAAABfhmp6VAplwR1MAAwAAF+EwDQYJKoZIhvcNAQELBQAEggEAJlpBiDW1BgOC2yHRkWqr khKBD6RyMoAgOM17+8+irSbVgqSFS/hPHbRP1Kgyd+z0IDThoSOLA1w5gRRIv9XruVFi5/wpFwPg Fj1OCMQv+L9uG/brQoRaojtVMJdmiWhO1lMrw4OmApt6XbfKzgYkEQpxRqrhP2bL7r4il1GywjiC m2hfiASnB2tGCCN6Bz3IQMMHdPBSnXjmxs66EFfXIH+10HoUBtTUDoPe20V45Ow3EQal1VUrLKwu W+Aojlm0GV9H8o55dlNZttpDae8ENxeEd1Yv73nchNuf3sv+MUkDafz1wXOMfxiySvMGZQPk75xV 1Pu/vyeK1iaC8hVCMwAAAAAAAA== --Apple-Mail=_5A3099C5-1C18-45EB-8E89-16D54C0610FD-- From nobody Thu Apr 14 04:55:45 2022 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 DC1753A10A4 for ; Thu, 14 Apr 2022 04:55:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 HeH-oXCSjMZ1 for ; Thu, 14 Apr 2022 04:55:40 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietfa.amsl.com (Postfix) with SMTP id D9AF13A10A2 for ; Thu, 14 Apr 2022 04:55:37 -0700 (PDT) Received: (qmail 6753 invoked from network); 14 Apr 2022 11:51:22 -0000 Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 14 Apr 2022 11:51:22 -0000 Message-ID: <61b46811-fa52-5ec0-e16b-eb7e9d9560d4@necom830.hpcl.titech.ac.jp> Date: Thu, 14 Apr 2022 20:55:34 +0900 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.8.0 Content-Language: en-US To: Paul Wouters Cc: "dnsop@ietf.org WG" References: <57f1c37b-497c-e1a0-329c-4b9c8b7e197b@necom830.hpcl.titech.ac.jp> <9732682e-78e7-f6bf-84fc-685de22d5e12@necom830.hpcl.titech.ac.jp> <350d8ab8-0477-b656-8b08-56f7561a7fda@necom830.hpcl.titech.ac.jp> <0e2dffab-6afc-b1b6-9028-175f89f0d29e@necom830.hpcl.titech.ac.jp> From: Masataka Ohta In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] DNSSEC as a Best Current Practice X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2022 11:55:44 -0000 Paul Wouters wrote: >> I can't see any reason why you think the root zone is >> more secure than TLDs, especially because, as I wrote: > > Because I am informed about their operational procedures and I > contributed to the technical design as one of the for the DNS Root Zone > Key-Signing-Key of the Root Zone Rollover advisory group. So, you mean the root zone is secure because of "operational procedures", which is not cryptographic. Thank you very much to have confirmed my point that DNSSEC is not cryptographically secure. Your point is, surely, conclusive. > I was also responsible for the design and implementation of a large TLD > fully implementation redundant DNSSEC signer solution. So, the root and TLD zones are as secure as diginotar. > I talked to a lot of TLD operators at ICANN during my term as the > IETF Liason to the ICANN Technical Expert Group. I'm sure none of them were aware that PKI is not cryptographically secure. So? >> : Third, all the CAs, including TLDs, pursuing commercial >> : success have very good appearance using such words as >> : "HSMs" or "four eyes minimum". That is, you can't >> : compare actual operational/physical strength from >> : their formal documents. > > This is an anecdote, that a logical reasoned argument. That's your anecdote to mention "HSMs" or "four eyes minimum" proven to be useless by diginotar. Masataka Ohta From james@qualityaccelerator.com Thu Apr 14 05:02:24 2022 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 6AE573A1154 for ; Thu, 14 Apr 2022 05:02:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.907 X-Spam-Level: X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=qualityaccelerator-com.20210112.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 RUYfrHpFPz63 for ; Thu, 14 Apr 2022 05:02:20 -0700 (PDT) Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) (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 DC3043A1147 for ; Thu, 14 Apr 2022 05:02:19 -0700 (PDT) Received: by mail-wr1-x432.google.com with SMTP id g18so6565428wrb.10 for ; Thu, 14 Apr 2022 05:02:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qualityaccelerator-com.20210112.gappssmtp.com; s=20210112; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=5TY9G666gyW+tICNE39YwtCvUChr5cqv+XCrDnBduU8=; b=z+4ThqA8B4YPz6LpuBkODpKeakBrNQt3dzcQmH72RIxuxOGkXSu6v24isJv2uf3H/1 sjjyGgff1COhrJfXeigREc7eKe0IBzxN+no9tjE33VkA7/afBjvG0+8O1ya2NNwk3HJu h1r2YWIxfaU8xYZ+ij+u6V1xWX/TKmSckGdam48WJddcNFrSzNqya4hAitPc8T3TrBpC gvQOnmajfzEfPcev9PFDMWXatMhdtI9+/V9wnYJpyENrv7wDmleWb1bQLzDDFDaYk/I6 qMYEn3+imU8Zo/twYhVKXpNtnWF1C47b7zbkm1M99Wfc09tpZkQyOhqklHOhxREPn+nA BOGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=5TY9G666gyW+tICNE39YwtCvUChr5cqv+XCrDnBduU8=; b=aIa+IxSxOLxV9L/JRQ5blWuF1alV2yT152++4w4c/aE8BMpkFMiFAPY1EJrezjhO2K PzkhYTePmkebNGhVS+EyupZTY4P9QIa5AxpU/GTPL2hrbpGhPCA0WyELAb1uX/9MasK2 +8uCINkIqDNbIRASD6qGeOQabMWPfONMYBAw6iXFD/DW8J92cmwiP8QC1DUFBefUimDR tgm1t4Ioix02BqzoMKcn8+0yN8uhGuVWJipO/AcC26qv95eyC2YR/iJvHWghAG11t/A7 WF3KR5hxF9qUwKxPxsx6GO/lN9e1GmapdQKr15WBF3xTL/UAIvGjk4MnMJI7l0EUQPkS 5hLw== X-Gm-Message-State: AOAM530aFZTgM067pnOYkJJNnaIR8Aauxy8dqRkIDtAJ/l1cj+Cr05kD llP9DHPaHjNrwSuya9hUTWWTMt4XIUo6kA== X-Google-Smtp-Source: ABdhPJzlj46qlOeOXn576yW9gb6SJdKn2tYi9rCYYhwS+AWH6Ki8CS65Rfns/5eSlksvIDFlf0XppQ== X-Received: by 2002:a5d:64a3:0:b0:20a:7931:5b91 with SMTP id m3-20020a5d64a3000000b0020a79315b91mr120513wrp.388.1649937737601; Thu, 14 Apr 2022 05:02:17 -0700 (PDT) Received: from PC ([2001:bb6:dba:2700:2974:b877:87e8:23c9]) by smtp.gmail.com with ESMTPSA id l9-20020a1c7909000000b0038eb8171fa5sm1915713wme.1.2022.04.14.05.02.17 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 Apr 2022 05:02:17 -0700 (PDT) From: To: "'Masataka Ohta'" , "'Paul Wouters'" Cc: References: <57f1c37b-497c-e1a0-329c-4b9c8b7e197b@necom830.hpcl.titech.ac.jp> <9732682e-78e7-f6bf-84fc-685de22d5e12@necom830.hpcl.titech.ac.jp> <350d8ab8-0477-b656-8b08-56f7561a7fda@necom830.hpcl.titech.ac.jp> <0e2dffab-6afc-b1b6-9028-175f89f0d29e@necom830.hpcl.titech.ac.jp> <61b46811-fa52-5ec0-e16b-eb7e9d9560d4@necom830.hpcl.titech.ac.jp> In-Reply-To: <61b46811-fa52-5ec0-e16b-eb7e9d9560d4@necom830.hpcl.titech.ac.jp> Date: Thu, 14 Apr 2022 13:01:57 +0100 Message-ID: <06f401d84ff7$7228e9f0$567abdd0$@qualityaccelerator.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHdCgFkMRRyXtpt9e2gRm2O+W2aJwIbE+GtArj/KwICn+FOTwIs2XszAmG1GucC0dtUkQJfzhyrASSH2ocBeB4L5qxHVDpg Content-Language: en-us Archived-At: X-Mailman-Approved-At: Thu, 14 Apr 2022 05:58:24 -0700 Subject: Re: [DNSOP] DNSSEC as a Best Current Practice X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2022 12:03:12 -0000 Surely this is at the point of just being trolling right? -----Original Message----- From: DNSOP On Behalf Of Masataka Ohta Sent: Thursday, April 14, 2022 12:56 PM To: Paul Wouters Cc: dnsop@ietf.org WG Subject: Re: [DNSOP] DNSSEC as a Best Current Practice Paul Wouters wrote: >> I can't see any reason why you think the root zone is more secure >> than TLDs, especially because, as I wrote: > > Because I am informed about their operational procedures and I > contributed to the technical design as one of the for the DNS Root > Zone Key-Signing-Key of the Root Zone Rollover advisory group. So, you mean the root zone is secure because of "operational procedures", which is not cryptographic. Thank you very much to have confirmed my point that DNSSEC is not cryptographically secure. Your point is, surely, conclusive. > I was also responsible for the design and implementation of a large TLD > fully implementation redundant DNSSEC signer solution. So, the root and TLD zones are as secure as diginotar. > I talked to a lot of TLD operators at ICANN during my term as the > IETF Liason to the ICANN Technical Expert Group. I'm sure none of them were aware that PKI is not cryptographically secure. So? >> : Third, all the CAs, including TLDs, pursuing commercial >> : success have very good appearance using such words as >> : "HSMs" or "four eyes minimum". That is, you can't >> : compare actual operational/physical strength from >> : their formal documents. > > This is an anecdote, that a logical reasoned argument. That's your anecdote to mention "HSMs" or "four eyes minimum" proven to be useless by diginotar. Masataka Ohta _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop From nobody Thu Apr 14 07:02:43 2022 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 715EC3A1973; Thu, 14 Apr 2022 07:02:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.107 X-Spam-Level: X-Spam-Status: No, score=-2.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] 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 eu5QQn2efnjE; Thu, 14 Apr 2022 07:02:36 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.85]) (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 62FE33A1A39; Thu, 14 Apr 2022 07:02:36 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4KfLkd5Dq7zFHZ; Thu, 14 Apr 2022 16:02:33 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1649944953; bh=amGO1f5OkgzUoR9mT4ejSfdBssG9vsG9gqYSnz3OI7I=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=OPjnZezKjmNb6Dj++bkDzcH5RN+I8u+UvpMZYaqu9IT5hgRjvWDeD7VHlSb/6QQDW 5GqH1gjvhIcTZ8GivmTOnZExD81m1+dwQujVow3GEsyfWMNVWpdRZ7j3tfOxzHQXvw jWZ2lzkqgHaR6BdfTga6VnoXT31t1xHaSUK+0Wxc= 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 bUahf_4l8sOt; Thu, 14 Apr 2022 16:02:32 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Thu, 14 Apr 2022 16:02:32 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id DC71E2E21C3; Thu, 14 Apr 2022 10:02:31 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id D91822E21C2; Thu, 14 Apr 2022 10:02:31 -0400 (EDT) Date: Thu, 14 Apr 2022 10:02:31 -0400 (EDT) From: Paul Wouters To: Masataka Ohta cc: "dnsop@ietf.org WG" , dnsop-chairs@ietf.org In-Reply-To: <61b46811-fa52-5ec0-e16b-eb7e9d9560d4@necom830.hpcl.titech.ac.jp> Message-ID: <3ca89d-9aa9-7a28-e7cc-948756eb459e@nohats.ca> References: <57f1c37b-497c-e1a0-329c-4b9c8b7e197b@necom830.hpcl.titech.ac.jp> <9732682e-78e7-f6bf-84fc-685de22d5e12@necom830.hpcl.titech.ac.jp> <350d8ab8-0477-b656-8b08-56f7561a7fda@necom830.hpcl.titech.ac.jp> <0e2dffab-6afc-b1b6-9028-175f89f0d29e@necom830.hpcl.titech.ac.jp> <61b46811-fa52-5ec0-e16b-eb7e9d9560d4@necom830.hpcl.titech.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [DNSOP] DNSSEC as a Best Current Practice X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2022 14:02:42 -0000 On Thu, 14 Apr 2022, Masataka Ohta wrote: >>> I can't see any reason why you think the root zone is >>> more secure than TLDs, especially because, as I wrote: >> >> Because I am informed about their operational procedures and I >> contributed to the technical design as one of the for the DNS Root Zone >> Key-Signing-Key of the Root Zone Rollover advisory group. > > So, you mean the root zone is secure because of "operational > procedures", which is not cryptographic. No I did not say that at all. > Thank you very much to have confirmed my point that DNSSEC > is not cryptographically secure. > Your point is, surely, conclusive. This twisting of my words has now reached abusive levels, and I hope the chairs will now take action. Paul From nobody Thu Apr 14 07:17:55 2022 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 19B683A1B45; Thu, 14 Apr 2022 07:17:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.106 X-Spam-Level: X-Spam-Status: No, score=-2.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 pYjbUerzILkP; Thu, 14 Apr 2022 07:17:45 -0700 (PDT) Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (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 7B7243A1B46; Thu, 14 Apr 2022 07:17:45 -0700 (PDT) Received: by mail-lf1-x12d.google.com with SMTP id w19so9312001lfu.11; Thu, 14 Apr 2022 07:17:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dUuQ40OMmHs+NNIaiqqo8JD1eujZAJLO+ZOfp5rLYBc=; b=C1fwxOWWATCAMAwzBdqJyXzV1glDVjOFoLFQHbuIsBj7wUrarW5gFwCBpdYOFuExG6 da7oKLuaI3q8mJxI8yzqvmU+A7eS7eroJLd85evXI0rEuXBmAG3Exz6An6q9muoqwcAU hnW2pUxn5IvfVd+A3sjMI8MDjDnB2XJRWpFlHPrxPW2iyAzULomERSC2IGp3aGX57aSe tbZkKicqUiypqGIfHvbtEQQPYm0nzd/o2+9kFWx3Mj+A+pRXd8FtNKKDEf0hR77FmLkY m3rxP74ECxkfquyQxNqA4WSIQLZOGzvex466chGWjvvX8490qjDv/kcRsXC8QtAf0ChI zT2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dUuQ40OMmHs+NNIaiqqo8JD1eujZAJLO+ZOfp5rLYBc=; b=R6KKo5BF5oMbfBJxBpPNFw+MR7PJMRXEIwGXiKMFdP/evfU3c2LNqVH9HqhUNcYo6j oQvZeU6pOunge2oN0VdnO1BG8g3ofCa3O+iSeSzFi0JRT7zoP2j1nbaBqfEE6GSvFvE+ b0uz/Y524LsJTxehnw+FJXlV1hyVbYMc3P1vfmkTJaF6ff9lYZoLfNaLJubrUB5qiZfZ piae2A2M/jt8iAXRbh2qaX7+2kS4jYsFPfA49JD9Qeq+hDbdNCRZ6AyCX/fJujgSjlOk 3d8vy2hC7WvgXP90CwOOlHK3QHCL5SDuA/h9l/Bf/Saq7tVYx5U2VMzjY7VhizwqQNaU P1zA== X-Gm-Message-State: AOAM533DoWJkh0gB4VC/zKj8Gu70+4RzxkYiEXzjB27jVlB37Xx4g50R VdKx7eJAUWEAasWc9kgH81zlrKbqs5m1DUbw71E= X-Google-Smtp-Source: ABdhPJzIvJW+kA/QW65P06eHtioPF3nihcOjEOe2L8nfW14mYMZLMJtNKgBfFwJIeurHViOVvYgSbYKeh2ns7sqrfeo= X-Received: by 2002:a05:6512:22d5:b0:46b:c423:826a with SMTP id g21-20020a05651222d500b0046bc423826amr2014822lfu.162.1649945863326; Thu, 14 Apr 2022 07:17:43 -0700 (PDT) MIME-Version: 1.0 References: <57f1c37b-497c-e1a0-329c-4b9c8b7e197b@necom830.hpcl.titech.ac.jp> <9732682e-78e7-f6bf-84fc-685de22d5e12@necom830.hpcl.titech.ac.jp> <350d8ab8-0477-b656-8b08-56f7561a7fda@necom830.hpcl.titech.ac.jp> <0e2dffab-6afc-b1b6-9028-175f89f0d29e@necom830.hpcl.titech.ac.jp> <61b46811-fa52-5ec0-e16b-eb7e9d9560d4@necom830.hpcl.titech.ac.jp> <3ca89d-9aa9-7a28-e7cc-948756eb459e@nohats.ca> In-Reply-To: <3ca89d-9aa9-7a28-e7cc-948756eb459e@nohats.ca> From: Tim Wicinski Date: Thu, 14 Apr 2022 10:17:30 -0400 Message-ID: To: Paul Wouters Cc: Masataka Ohta , "dnsop@ietf.org WG" , dnsop-chairs Content-Type: multipart/alternative; boundary="0000000000001510d105dc9df514" Archived-At: Subject: Re: [DNSOP] DNSSEC as a Best Current Practice X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2022 14:17:54 -0000 --0000000000001510d105dc9df514 Content-Type: text/plain; charset="UTF-8" I sent this earlier today but I failed to do the Reply-All: --- >From the chairs, This needs to stop. Please send suggested text for the document that can be discussed, otherwise we are requesting you cease Thanks Tim ---- On Thu, Apr 14, 2022 at 10:02 AM Paul Wouters wrote: > On Thu, 14 Apr 2022, Masataka Ohta wrote: > > >>> I can't see any reason why you think the root zone is > >>> more secure than TLDs, especially because, as I wrote: > >> > >> Because I am informed about their operational procedures and I > >> contributed to the technical design as one of the for the DNS Root Zone > >> Key-Signing-Key of the Root Zone Rollover advisory group. > > > > So, you mean the root zone is secure because of "operational > > procedures", which is not cryptographic. > > No I did not say that at all. > > > Thank you very much to have confirmed my point that DNSSEC > > is not cryptographically secure. > > > Your point is, surely, conclusive. > > This twisting of my words has now reached abusive levels, and I hope > the chairs will now take action. > > Paul > --0000000000001510d105dc9df514 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I sent this earlier today but I failed to do the Reply-All:

---

From the chairs,

This needs to stop.= =C2=A0 Please send suggested text for the document that can be discussed, o= therwise we are requesting you cease

<= span style=3D"font-family:Arial,Helvetica,sans-serif">Thanks
Tim
----



On Thu, Apr 14, 20= 22 at 10:02 AM Paul Wouters <paul@noha= ts.ca> wrote:
On Thu, 14 Apr 2022, Masataka Ohta wrote:

>>>=C2=A0 I can't see any reason why you think the root zone i= s
>>>=C2=A0 more secure than TLDs, especially because, as I wrote: >>
>>=C2=A0 Because I am informed about their operational procedures and= I
>>=C2=A0 contributed to the technical design as one of the for the DN= S Root Zone
>>=C2=A0 Key-Signing-Key of the Root Zone Rollover advisory group. >
> So, you mean the root zone is secure because of "operational
> procedures", which is not cryptographic.

No I did not say that at all.

> Thank you very much to have confirmed my=C2=A0 point that DNSSEC
> is not cryptographically secure.

> Your point is, surely, conclusive.

This twisting of my words has now reached abusive levels, and I hope
the chairs will now take action.

Paul
--0000000000001510d105dc9df514-- From nobody Thu Apr 14 07:18:06 2022 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 D22C03A1B45 for ; Thu, 14 Apr 2022 07:17:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.11 X-Spam-Level: X-Spam-Status: No, score=-2.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mukund.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 7qQkdVWzdlNa for ; Thu, 14 Apr 2022 07:17:49 -0700 (PDT) Received: from mx.mukund.org (mx.mukund.org [144.76.148.120]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C5273A1A14 for ; Thu, 14 Apr 2022 07:17:48 -0700 (PDT) Date: Thu, 14 Apr 2022 19:47:43 +0530 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mukund.org; s=mail; t=1649945866; bh=G2KSzoXRperQNV7SdFrwaL+nimPt4AnHRt7R3Hehpwg=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=LvYx4Xj3jRvn1/T3UC0xv4PVx1A6kHYHFR8cz4iARaFKMB9xc+d+/tvH16La+hbhH iVesbMHAB7p2Dn7Ch81zeGbgngsyyKkf0IpOcQuvEAGdPC9SKAUtZcxqCPutSwXCY0 cgqIROGDmwX4L/IYL0buY4s9AHoLQcXfqrUy+KCE= From: Mukund Sivaraman To: Masataka Ohta Cc: Paul Wouters , "dnsop@ietf.org WG" Message-ID: References: <57f1c37b-497c-e1a0-329c-4b9c8b7e197b@necom830.hpcl.titech.ac.jp> <9732682e-78e7-f6bf-84fc-685de22d5e12@necom830.hpcl.titech.ac.jp> <350d8ab8-0477-b656-8b08-56f7561a7fda@necom830.hpcl.titech.ac.jp> <0e2dffab-6afc-b1b6-9028-175f89f0d29e@necom830.hpcl.titech.ac.jp> <61b46811-fa52-5ec0-e16b-eb7e9d9560d4@necom830.hpcl.titech.ac.jp> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="l/tiCIbo97QvM9rh" Content-Disposition: inline In-Reply-To: <61b46811-fa52-5ec0-e16b-eb7e9d9560d4@necom830.hpcl.titech.ac.jp> Archived-At: Subject: Re: [DNSOP] DNSSEC as a Best Current Practice X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2022 14:17:55 -0000 --l/tiCIbo97QvM9rh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Apr 14, 2022 at 08:55:34PM +0900, Masataka Ohta wrote: > Paul Wouters wrote: >=20 > > > I can't see any reason why you think the root zone is > > > more secure than TLDs, especially because, as I wrote: > >=20 > > Because I am informed about their operational procedures and I > > contributed to the technical design as one of the for the DNS Root Zone > > Key-Signing-Key of the Root Zone Rollover advisory group. >=20 > So, you mean the root zone is secure because of "operational > procedures", which is not cryptographic. >=20 > Thank you very much to have confirmed my point that DNSSEC > is not cryptographically secure. >=20 > Your point is, surely, conclusive. >=20 > > I was also responsible for the design and implementation of a large TLD > > fully implementation redundant DNSSEC signer solution. >=20 > So, the root and TLD zones are as secure as diginotar. >=20 > > I talked to a lot of TLD operators at ICANN during my term as the > > IETF Liason to the ICANN Technical Expert Group. >=20 > I'm sure none of them were aware that PKI is not cryptographically > secure. So? >=20 > >> : Third, all the CAs, including TLDs, pursuing commercial > >> : success have very good appearance using such words as > >> : "HSMs" or "four eyes minimum". That is, you can't > >> : compare actual operational/physical strength from > >> : their formal documents. > > > > This is an anecdote, that a logical reasoned argument. >=20 > That's your anecdote to mention "HSMs" or "four eyes minimum" > proven to be useless by diginotar. (From your posts in this thread, you appear well convinced that cryptography is broken due to operational weaknesses in securing access to signers. So I don't know if this will convince you differently.) HSMs don't have anything to do with DNSSEC's security guarantee. Use of HSMs is an implementation/operational detail. An operational decision leading to weakness doesn't mean that the cryptographic foundation of DNSSEC is broken or cannot be secured. So it's not entirely correct to say "DNSSEC is not cryptographically secure." On the topic of leak of private key or access to signers by rogue parties, there have been experiments to use threshold cryptography with DNSSEC where the actual private key is not present in any single form, but distributed as "key shares" among N parties, and "signature shares" are generated separately by M out of N parties and combined to make the final signature. The private key does not exist in one place to be used by bypassing operational security mechanisms. E.g., see this implementation by NIC Chile: https://github.com/niclabs/dtc There has also been a previous C/C++ implementation by them. These provide a PKCS11 implementation that can be used by existing DNSSEC signing tools that support the PKCS11 library interface. They use the RSA threshold signatures mechanism designed by Victor Shoup, which is compatible to be used for PKCS#1 v1.5 signature generation as used in the DNSSEC RSA algorithms, i.e., it can be used in DNSSEC currently within the RSA algorithms. https://www.shoup.net/papers/thsig.pdf There are other methods for ECDSA, and some standardization process at NIST. The army can be sent to the house of every member of "N eyes minimum" group to hit on the knuckles repeatedly until either the key cracks or their knuckles crack. Bribing with carrots also works sometimes. https://xkcd.com/538/ So this isn't an attempt to convince you that security is relative. :) Mukund --l/tiCIbo97QvM9rh Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEcpanf3Bxi94C0NsVude/iQOlsOwFAmJYLQUACgkQude/iQOl sOwAtBAAvpDWgpCmi/HcMtjuzG1nDpC/xaUKIzrWKrc5yubj4gRAIZHhydcjuZ0H Ckj7xY5rIjSXqVyWv31icaEDF83VlO1ISmA0fMMTbdaRKVV6ecWl8MSG2NvMmVhw CewO58DGgN6KRkokXSd1Cld7m6aJsV+GEBIjqOV5xZGO088EwNYD8swD8zuYwd+K xUGjc29h4KTX7sYQtQtXcwNQt7GB96MrxcSN37w0PVpE8geKdJQFw85glVu9aiSs eHR0sfpSWP2y9wNby9Ny8hG1pZSKEpXLXKMr1T7EK2xqiXxBIU83/UWXG6WRy3N4 t59f2+1jNG2aPpyT2i5v53TtqaHedrh5fkhbSc1fGaGDGWIr6vaGZplT42NnPBjY BGD5qYNe7KiWxdqqIs2Exoe6yPzDPnhiYDTDWZQ2571V1k9yfXAlx3amlwW8nEB+ 73oMZ3IFRfrTP8BKInBdKLuYutF2F7/HsSyZWscUqW4KcoTdTxMi3zmqzzkt16z9 1dbheU2px5bo98qbl5ia3rIYweLb6TYvg2YCoLui7ezlaKbuqoQs+Fy0Wlzr447f 3YIs7Ne/KJ+b6Ahm2jOjIOzhw0mdteUGYCySgZzq5/3SelOEJbBiAh7+rWKkVmMu IEmM2zQg1Un/DYSCMEbIAsPBf9jmlOIzH2ojc+PHgSDUsVQy3Es= =vZlO -----END PGP SIGNATURE----- --l/tiCIbo97QvM9rh-- From nobody Thu Apr 14 10:24:59 2022 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 E44EC3A1805 for ; Thu, 14 Apr 2022 10:24:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.106 X-Spam-Level: X-Spam-Status: No, score=-7.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pir.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 E3zt0pzXApI8 for ; Thu, 14 Apr 2022 10:24:51 -0700 (PDT) Received: from us-smtp-delivery-195.mimecast.com (us-smtp-delivery-195.mimecast.com [170.10.133.195]) (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 350033A1803 for ; Thu, 14 Apr 2022 10:24:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pir.org; s=mimecast20201020; t=1649957090; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type; bh=J/IMSNlct5ghzFqtlrD17FJL65PWylYsUn3haAk7Lcc=; b=IpULOtQMlED/ICqOhC502PYmqu2VC2KzJnjEoMTvRpEoFmIaZ/XxlZ1OTe+P4dhMXznYE6 Ng1Qt+I73bkMQLt9DXWxaMUt2IRHRCrnbH6l8Lp36jA5XSwldh5jj8OyADe9IQd0RcV+vo TOKQ6mGSpay+cAY9JdG6JRXhlhD3bO8= Received: from NAM10-BN7-obe.outbound.protection.outlook.com (mail-bn7nam10lp2101.outbound.protection.outlook.com [104.47.70.101]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-210-EBhcY27tOGGZOQJXmZHTJg-1; Thu, 14 Apr 2022 13:24:48 -0400 X-MC-Unique: EBhcY27tOGGZOQJXmZHTJg-1 Received: from SN4PR10MB5798.namprd10.prod.outlook.com (2603:10b6:806:20d::14) by DS7PR10MB5342.namprd10.prod.outlook.com (2603:10b6:5:3a6::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5164.20; Thu, 14 Apr 2022 17:24:46 +0000 Received: from SN4PR10MB5798.namprd10.prod.outlook.com ([fe80::798b:14ed:5e25:d74e]) by SN4PR10MB5798.namprd10.prod.outlook.com ([fe80::798b:14ed:5e25:d74e%4]) with mapi id 15.20.5164.020; Thu, 14 Apr 2022 17:24:45 +0000 From: Suzanne Woolf To: "dnsop@ietf.org" CC: Warren Kumari , "dnsop-chairs@ietf.org" Thread-Topic: List conduct (was: Re: [DNSOP] DNSSEC as a Best Current Practice) Thread-Index: AQHYUBN3B0hhgJ6ls0yLJjHuGq3Bww== Date: Thu, 14 Apr 2022 17:24:45 +0000 Message-ID: <6818F50A-AF06-4EA5-AD47-2F8BC3CD2A31@pir.org> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.59.22031300 x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3f2784e9-437a-41b9-36b3-08da1e3babc2 x-ms-traffictypediagnostic: DS7PR10MB5342:EE_ x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0 x-microsoft-antispam-message-info: iKq1YhpSv8Gc+jwJqwKfovKwOSIL/cNOKPBr1acTPhBoKNFcGRAQPX3w92UVAJsGoN6DJSVfR940mSWGwwSjZUi39Fdqzzvyo5NmN0geHTO3EBsb5FojZsoDUwaxjGAFg6PRT/7vseuhQiP6PjWvx2NDWIc7o1OJMWG1HZxdAGfB0OkbIjTbkIn5dO9MtwqS+MTf6jcSijpOeJVMc632kQYX2PN5yTBj85pMfLz0gZ97tUwDgD9rZAzvgxCMAd+IRxlhBMGLXhqp3F3DkdrJDRnTG1JKFmp5LJUpA2eeMjjYdu7+VfW0+8vfrXifPT/eXdw+KpkxESnMGyGNKd41NudKrpX2qbqbVqXkLHBAECZghsMP2W1/iktPkZ9PlvnZsclXuiLSJaH6YYDwy47f6Xw4pp3dEdDyLLgI9DE2QSnKLHUaDYfVxLJeKhQEyO0bPDXnnh14KOWjpn5pXIjKiTTPI8YOiQJyGrdnRLjO70FmBuZLWgBxxTLzyX+ACZzFIlS/YpDTBpIw3pgqvye7m/YYKB6jLCEWNbVC9DGVnwhdQ+sG5+QstBWNAXrZTbNhTtK9nP8Qrkvt7qDCK2n1bC8PJ6SZAuwKiqcnVCo0j+zrIpHoPW4UrxVT9J1rg6ske3SFngldxjCL4XmSHPMHDdWZu9i26aR0BB9fG2hFIgxutHGmh/fIa1WcCodUZdUEXqCHAosObatTy60L/Orp7LBqKs5+p7+ta1mYLP0a8JE= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SN4PR10MB5798.namprd10.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(346002)(366004)(396003)(376002)(136003)(39840400004)(33656002)(86362001)(122000001)(38070700005)(38100700002)(5660300002)(6486002)(508600001)(316002)(8676002)(4326008)(6916009)(8936002)(76116006)(66946007)(66556008)(66446008)(66476007)(71200400001)(83380400001)(91956017)(64756008)(186003)(6506007)(2906002)(6512007)(2616005)(36756003)(54906003)(45980500001); DIR:OUT; SFP:1102 x-ms-exchange-antispam-messagedata-chunkcount: 2 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?WnVYT1dHQmYxMEFvaE5zcEo3VTdoeVErL1drakhtM2NuOU4vQ1BQMXErcjJT?= =?utf-8?B?VUpIanpSYzVkNzRCNlk4a3hkK0piVExQdkFjWExaUXdQZFlEVENoNnJ5azdl?= =?utf-8?B?UlJVWW9NUjEvRk9pNk14TXowT2xUWkwyV3lCbE1BaklrbkJQTWJIN2xIRWVE?= =?utf-8?B?T2U4U2JYczN5U0hYaDNGRzV6ZnE0cmdiYXExS0ZxNXhnNEZOYjhOayt6Z3M0?= =?utf-8?B?Y280RTlRRkRPaVgxbWJzTXkvdWRYTTByN3UxS1N2VW5rRk11aXE0YzlOUjdD?= =?utf-8?B?UnZsYlpyVDhMZE5Yc0MzMExibFZiS3M1M3dOYlc5cGF3TjY0QnJCWUZmS0Q3?= =?utf-8?B?TTBEcmdadHNMUENOQnFoV2pQMXlUekoyejhHbU01Q1lwWEg3eWdFblkyeGdV?= =?utf-8?B?bW5WaEs3bldPcG9TZ2hHc090MFdkTXp5LzdpenF6VWZCbHJNNFBjaTBqTWxr?= =?utf-8?B?bjdtZUYrZktwK3JzNUE1RFhYR3ZoQlFZV3g5MUxWUSswbW1Wam5YcUdnaW9B?= =?utf-8?B?MG9XNUs5U25ub3lTenIzdlFiR2IvakRUcFJZdWIrVFdqQlJUWlNWa050Y3dU?= =?utf-8?B?endhY0RCQVJYVC9yNlpoUnN2azQ4TmhIMGFmajhObHhkS0huVy8zWGh3NmE5?= =?utf-8?B?YXVBNXJVNzlZMmtzYVZiV3hFTTgvalA4VFNmSjUwYTZXeHcvZFkwMzNLU013?= =?utf-8?B?WmdOYkZ6a0Q2RlZOSFNMZlowanZzdDBrQWhvQkcweCtIYXdOa1YvOENMdEgr?= =?utf-8?B?U0tVZDQ0WUZPaUhDSTlNK1Z1d3ZYYS9UMFFDWTMvN2pBcUgrdE5zMlVIWUMv?= =?utf-8?B?eWxGZG9WSUZOQW5wK3JDWVNobG42eGJ4dkdCVVo5VXM3ZVdEcjhaQUJEL0tq?= =?utf-8?B?b2N3QjhvV0IrcG9HZTRVRzc5YXBORnBRRDYrNUJ3VnBDaU1NZHhtajJZT3Jq?= =?utf-8?B?MTV3clkrN1lUZlN1MENQU3ZLQm5CNkFmKzk5UDJqZm53a0pMMzRQWDYwTUE5?= =?utf-8?B?b2pSb0tjWnhtcXEySi9zU042anFiZ1NRWCtTSXo5YVVyZkdjN0J0NjRpQU1H?= =?utf-8?B?T3M5TWpTVXJIaUVqWC82VTVGZElGMFZ0K0Z6Y2N5N1VaL0hqYzFwbmJ6NnhM?= =?utf-8?B?RGhDYTZDcjJDbVNhZG9Kcy9WRlNZeDhiWHZkbVRwS3dMVDhKQkhyci9LeVpZ?= =?utf-8?B?Qk9CQ0xsdDNKOUJGWUg0ZEV2a3ZnS3A0RjZ4cFcvL2hZek8zYVF5VEQ4a3ln?= =?utf-8?B?V0xscXprR2RqODdYa0FYa1Z5bnhycHlTM3FPYU02Qm4wOWU2ZEE0R1hOYVc1?= =?utf-8?B?RTdCdnJxQ1NKRi83SFIvRGQ1ZGdOK3ZPcDhLNWRhTmFlc2YwakVpUEhGUXdF?= =?utf-8?B?V2IxT0M3OWRjNER3ZXBVUDUvSndlcVQwZURDYXZFMkZDVjQzZE1KYzR0YTl5?= =?utf-8?B?NTJRdjQ4eVd0SXh2ZDBWa0ZBdGRrMVRONVdaRzltNlR1R3YxYXRsRE9XWTJV?= =?utf-8?B?cHoyckplc2poZFoyTEJqVWg1dFZVVmpwMC9uQUMxUS80YUZ6dU9qZURnNlpw?= =?utf-8?B?UFVhdFVVT082bDVkdUVUbDNDOXBWZ1dhUmpyanU2L0pvcjFNaEVBaDZoLzNJ?= =?utf-8?B?T1orbWVORlFsWnd0d3lUVU1FRWxMcGhvM3R6VHFZQWt5cGtQdFNjRjFWR2Nj?= =?utf-8?B?aGF4ZlRrcGZQaE5PMlEwZkNUYVQzam5qUW10L2JxL1lXeXd4dnVUVm5VdDVX?= =?utf-8?B?TnhHaWhsWlJ6dTZCbHlEa2o5SWE4MTN3eFJMbzhtY2N2elBaQU1taExGTk1J?= =?utf-8?B?ZlVCV1d0VG9aODd6clpldXVxcVpOU1BscWZrcHRlZ3MyYjFsNUhVaWkvRXJH?= =?utf-8?B?MXVJeUhRaFRzM0xFcU5zeTVqSFZhK05WTFRYSlFpRVBJZVA0MkZ1YW1IZGFv?= =?utf-8?B?WTVmVzU5RlM4RDRnNER3VFRQTW8rckdEZ1g5S0F3M3lGNWR5OGVDVEQ0TDU3?= =?utf-8?B?Uk1ubVRhMHBicFBQODFTbGZJT2RXM0RLdkFTZTBCdkJiT0Vxb014bDJnVlUz?= =?utf-8?B?T0ZrT0ZldXhVUnk0Q0NKYjRLZzFTdUsvYXRxcE83WjY5L1JiL2pmbTZ2Z3VX?= =?utf-8?B?Y0xna3ZXOFN1UW1pLzRyQXR2cWR2a1BTaGF5aGhRSThqUUZUMlNzalpaanhY?= =?utf-8?B?b3RneW5zbUtiQ2JUc05oL1UzU0xET2xMTmV4aTNLdjlhQjl4dWYvMVdOQUtZ?= =?utf-8?B?TVZVbHlEc1ZieSs3VjJNYnQveWhtcW44NXovY3psUlRLVHVMcFJYd0RkR25l?= =?utf-8?B?RTRIR1Nwd1hMU2Q2aGpVQys4SEswMmpzTk8rQzBkRFV0dDdwbnMyZmg3S3NS?= =?utf-8?Q?LmA3i/zE4v7cvMxp2KdEu7wy3Cf2Bz1jWSh9FOdow7Gwo?= x-ms-exchange-antispam-messagedata-1: qgfrtrnQ5bDjzw== MIME-Version: 1.0 X-OriginatorOrg: pir.org X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SN4PR10MB5798.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3f2784e9-437a-41b9-36b3-08da1e3babc2 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Apr 2022 17:24:45.9101 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 6c8ced78-b98f-4fa4-b6df-38beaa0d935d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: E3jGPpyGizVk/+IS9BZLoMSCP3zNsSrJnHRbqJ4qkM+QKaJkEKLM15k2CtcG3NCo X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR10MB5342 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA95A572 smtp.mailfrom=swoolf@pir.org X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: pir.org Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_6818F50AAF064EA5AD472F8BC3CD2A31pirorg_" Archived-At: Subject: [DNSOP] List conduct (was: Re: DNSSEC as a Best Current Practice) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2022 17:24:56 -0000 --_000_6818F50AAF064EA5AD472F8BC3CD2A31pirorg_ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Q29sbGVhZ3VlcywNCg0KQXMgc29tZSBvZiB5b3UgaGF2ZSBub3RlZCwgIHRoZSB0aHJlYWQgdW5k ZXIgdGhlIHN1YmplY3Qg4oCcRE5TU0VDIGFzIGEgQmVzdCBDdXJyZW50IFByYWN0aWNl4oCdIGhh cyBpbmNsdWRlZCBzb21lIGluYXBwcm9wcmlhdGUgcG9zdHMsIG5vdCBjb25zaXN0ZW50IHdpdGgg dGhlIElFVEYgQ29kZSBvZiBDb25kdWN0IG9yIGd1aWRhbmNlIG9uIGtlZXBpbmcgdGhlIFdHIG1h aWxpbmcgbGlzdCBwcm9mZXNzaW9uYWwgYW5kIHByb2R1Y3RpdmUuIEEgRE5TT1AgbWFpbGluZyBs aXN0IHBhcnRpY2lwYW50IGhhcyBiZWVuIHdhcm5lZCBhYm91dCB0aGVpciBwb3N0cyBhbmQgYXNr ZWQgdG8gc3RvcC4NCg0KQXMgYSByZW1pbmRlciB0byB0aGUgbGlzdDogcGVvcGxlIGhlcmUgY2Fu IGJlIHZpZ29yb3VzIGFuZCBpbnRlbnNlIGluIHRoZWlyIGFyZ3VtZW50cyBhbmQgdG9uZSwgYnV0 IGdlbmVyYWxseSBzdGF5IHRvIHRoZSBjaXZpbCBhbmQgY29uc3RydWN0aXZlIHNpZGUsIGFuZCB0 aGUgY2hhaXJzIGRvbuKAmXQgbGlrZSBzdGVwcGluZyBpbnRvIHN1YnN0YW50aXZlIHRlY2huaWNh bCBkaXNjdXNzaW9ucy4gSG93ZXZlciwgd2UgZG8gbW9uaXRvciB0aGUgbGlzdCwgZG8gbGlzdGVu IHRvIGNvbXBsYWludHMsIGFuZCBkbyBoYXZlIHRoZSBhYmlsaXR5IHRvIHRha2UgYWN0aW9uIHdo ZW4gbGlzdCBjb252ZXJzYXRpb24gdHVybnMgaW50byBwZXJzaXN0ZW50bHkgcmVwZWF0aW5nIGFy Z3VtZW50cyB0aGF0IGhhdmUgYWxyZWFkeSBiZWVuIGFkZHJlc3NlZCwgYWQgaG9taW5lbSBhdHRh Y2tzLCBvciBvdGhlciBiZWhhdmlvciB0aGF0IGhhcyBubyBhcHBhcmVudCBwdXJwb3NlIGJlc2lk ZXMgZGlzcnVwdGlvbi4NCg0KSXTigJlzIGltcG9ydGFudCB0byBicmluZyB5b3VyIGJlc3QgdGVj aG5pY2FsIGFyZ3VtZW50cyB0byBETlNPUCwgYnV0IGp1c3QgYXMgaW1wb3J0YW50IGluIGdldHRp bmcgb3VyIHdvcmsgZG9uZSB0byBicmluZyBjaXZpbGl0eSBhbmQgcmVzcGVjdCBmb3IgZXZlcnlv bmUgZWxzZS4gVGhlc2UgdGhpbmdzIG1hdHRlciBldmVuIG1vcmUgb3ZlciB0aGUgbGFzdCBjb3Vw bGUgb2YgeWVhcnMgb2Ygc2VlaW5nIGVhY2ggb3RoZXIgb25seSBvbmxpbmUuDQoNCkluIGdlbmVy YWwsIEROU09QIGhhcyBkb25lIHByZXR0eSB3ZWxsIGF0IGtlZXBpbmcgdGhpbmdzIHByb2Zlc3Np b25hbCBhbmQgcHJvZHVjdGl2ZS4gSXTigJlzIHBhcnQgb2YgdGhlIGNoYWlyc+KAmSBqb2IgdG8g a2VlcCBpdCB0aGF0IHdheS4gVGhhbmtzIGV2ZXJ5b25lLA0KDQoNCllvdXIgRE5TT1AgY2hhaXJz LA0KVGltLCBTdXphbm5lLCBhbmQgQmVubm8NCg0KDQoNCg0KDQoNCg== --_000_6818F50AAF064EA5AD472F8BC3CD2A31pirorg_ Content-Type: text/html; charset=UTF-8 Content-ID: <76A4C9DFB8DDDD45BF2701B8CD09B6F9@namprd10.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCWZvbnQtc2l6 ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEyLjBwdDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwv aGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiIg c3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Q29s bGVhZ3Vlcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkFzIHNv bWUgb2YgeW91IGhhdmUgbm90ZWQsJm5ic3A7IHRoZSB0aHJlYWQgdW5kZXIgdGhlIHN1YmplY3Qg 4oCcRE5TU0VDIGFzIGEgQmVzdCBDdXJyZW50IFByYWN0aWNl4oCdIGhhcyBpbmNsdWRlZCBzb21l IGluYXBwcm9wcmlhdGUgcG9zdHMsIG5vdCBjb25zaXN0ZW50IHdpdGggdGhlIElFVEYgQ29kZSBv ZiBDb25kdWN0IG9yIGd1aWRhbmNlIG9uIGtlZXBpbmcgdGhlIFdHDQogbWFpbGluZyBsaXN0IHBy b2Zlc3Npb25hbCBhbmQgcHJvZHVjdGl2ZS4gQSBETlNPUCBtYWlsaW5nIGxpc3QgcGFydGljaXBh bnQgaGFzIGJlZW4gd2FybmVkIGFib3V0IHRoZWlyIHBvc3RzIGFuZCBhc2tlZCB0byBzdG9wLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+QXMgYSByZW1pbmRlciB0 byB0aGUgbGlzdDogcGVvcGxlIGhlcmUgY2FuIGJlIHZpZ29yb3VzIGFuZCBpbnRlbnNlIGluIHRo ZWlyIGFyZ3VtZW50cyBhbmQgdG9uZSwgYnV0IGdlbmVyYWxseSBzdGF5IHRvIHRoZSBjaXZpbCBh bmQgY29uc3RydWN0aXZlIHNpZGUsIGFuZCB0aGUgY2hhaXJzIGRvbuKAmXQgbGlrZSBzdGVwcGlu ZyBpbnRvIHN1YnN0YW50aXZlIHRlY2huaWNhbA0KIGRpc2N1c3Npb25zLiBIb3dldmVyLCB3ZSBk byBtb25pdG9yIHRoZSBsaXN0LCBkbyBsaXN0ZW4gdG8gY29tcGxhaW50cywgYW5kIGRvIGhhdmUg dGhlIGFiaWxpdHkgdG8gdGFrZSBhY3Rpb24gd2hlbiBsaXN0IGNvbnZlcnNhdGlvbiB0dXJucyBp bnRvIHBlcnNpc3RlbnRseSByZXBlYXRpbmcgYXJndW1lbnRzIHRoYXQgaGF2ZSBhbHJlYWR5IGJl ZW4gYWRkcmVzc2VkLCBhZCBob21pbmVtIGF0dGFja3MsIG9yIG90aGVyIGJlaGF2aW9yIHRoYXQg aGFzDQogbm8gYXBwYXJlbnQgcHVycG9zZSBiZXNpZGVzIGRpc3J1cHRpb24uIDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+SXTigJlzIGltcG9ydGFudCB0byBicmlu ZyB5b3VyIGJlc3QgdGVjaG5pY2FsIGFyZ3VtZW50cyB0byBETlNPUCwgYnV0IGp1c3QgYXMgaW1w b3J0YW50IGluIGdldHRpbmcgb3VyIHdvcmsgZG9uZSB0byBicmluZyBjaXZpbGl0eSBhbmQgcmVz cGVjdCBmb3IgZXZlcnlvbmUgZWxzZS4gVGhlc2UgdGhpbmdzIG1hdHRlciBldmVuIG1vcmUgb3Zl ciB0aGUgbGFzdCBjb3VwbGUNCiBvZiB5ZWFycyBvZiBzZWVpbmcgZWFjaCBvdGhlciBvbmx5IG9u bGluZS4gPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5JbiBnZW5l cmFsLCBETlNPUCBoYXMgZG9uZSBwcmV0dHkgd2VsbCBhdCBrZWVwaW5nIHRoaW5ncyBwcm9mZXNz aW9uYWwgYW5kIHByb2R1Y3RpdmUuIEl04oCZcyBwYXJ0IG9mIHRoZSBjaGFpcnPigJkgam9iIHRv IGtlZXAgaXQgdGhhdCB3YXkuIFRoYW5rcyBldmVyeW9uZSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5Zb3VyIEROU09Q IGNoYWlycyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+VGltLCBTdXphbm5lLCBhbmQgQmVubm88bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_6818F50AAF064EA5AD472F8BC3CD2A31pirorg_-- From nobody Thu Apr 14 14:09:11 2022 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 CCE883A18CC; Thu, 14 Apr 2022 14:09:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 7C52ziqIdgGA; Thu, 14 Apr 2022 14:09:08 -0700 (PDT) Received: from ppa3.lax.icann.org (ppa3.lax.icann.org [192.0.33.78]) (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 6BE543A18CA; Thu, 14 Apr 2022 14:09:08 -0700 (PDT) Received: from MBX112-W2-CO-1.pexch112.icann.org (out.mail.icann.org [64.78.33.5]) by ppa3.lax.icann.org (8.16.0.43/8.16.0.43) with ESMTPS id 23EL96aE032056 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 14 Apr 2022 21:09:06 GMT Received: from MBX112-W2-CO-1.pexch112.icann.org (10.226.41.128) by MBX112-W2-CO-2.pexch112.icann.org (10.226.41.130) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.22; Thu, 14 Apr 2022 14:09:05 -0700 Received: from MBX112-W2-CO-1.pexch112.icann.org ([10.226.41.128]) by MBX112-W2-CO-1.pexch112.icann.org ([10.226.41.128]) with mapi id 15.02.0986.022; Thu, 14 Apr 2022 14:09:05 -0700 From: Paul Hoffman To: dnsop-chairs CC: dnsop Thread-Topic: [Ext] [DNSOP] Fwd: Working Group Last Call for draft-ietf-dnsop-rfc5933-bis Thread-Index: AQHYF6ti2Q2uhoukek2t25cf+8tgw6zwzcCA Date: Thu, 14 Apr 2022 21:09:05 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [192.0.32.234] x-source-routing-agent: Processed Content-Type: multipart/signed; boundary="Apple-Mail=_59065514-AB72-4D73-8586-930967F948A0"; protocol="application/pkcs7-signature"; micalg=sha-256 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.486, 18.0.858 definitions=2022-04-14_05:2022-04-14, 2022-04-14 signatures=0 Archived-At: Subject: Re: [DNSOP] [Ext] Fwd: Working Group Last Call for draft-ietf-dnsop-rfc5933-bis X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2022 21:09:10 -0000 --Apple-Mail=_59065514-AB72-4D73-8586-930967F948A0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Feb 1, 2022, at 12:35 PM, Tim Wicinski wrote: > We were reviewing the Working Group Last Call for this, and we = received no comments. We know there was interest in at least moving = this forward, but even Warren concurred we can't send this to the IESG = unless there are folks saying they feel it is ready to be published. That was a few months ago. There were only two responses, one negative, = one blandly positive ("seems reasonable").=20 Can the chairs please say what they expect to do with this draft? I ask = because it is directly relevant to draft-ietf-dnsop-dnssec-bcp, where = the draft's predecessor is mentioned. --Paul Hoffman= --Apple-Mail=_59065514-AB72-4D73-8586-930967F948A0 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCBrYw ggayMIIFmqADAgECAhMwAAAX4ZqelQKZcEdTAAMAABfhMA0GCSqGSIb3DQEBCwUAMF8xEzARBgoJ kiaJk/IsZAEZFgNvcmcxFTATBgoJkiaJk/IsZAEZFgVpY2FubjESMBAGCgmSJomT8ixkARkWAmRz MR0wGwYDVQQDExRhZDEtbGF4LmRzLmljYW5uLm9yZzAeFw0yMTA1MjAxNTAxMzNaFw0yMzA1MjAx NTAxMzNaMIGUMRMwEQYKCZImiZPyLGQBGRYDb3JnMRUwEwYKCZImiZPyLGQBGRYFaWNhbm4xEjAQ BgoJkiaJk/IsZAEZFgJkczEUMBIGA1UECxMLSUNBTk4tVXNlcnMxFTATBgNVBAMTDFBhdWwgSG9m Zm1hbjElMCMGCSqGSIb3DQEJARYWcGF1bC5ob2ZmbWFuQGljYW5uLm9yZzCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBALtvlgd1mCsDZcUXiDdEtqqeklaJa3MfG8v1RMIKaVSaK3dsq2gA JujPfGwUdRIne4Tz6HJqPXBYEzVkgUdxdFXu/xPzfZei+fRb7zeVA9sMTrKl9gQ31Q0cw5VbmJzG P41Lxq2ruCyX/cGiru1PG4VVN72f9w1lpBt4rhRYpi5f2DDRmNm01teEoNOdvQ6PavUJVWrLVDI0 Z+uF4oe51yriMBQntRw9XenckW2yDa9ob3DlmOYKdZp1mNv2f+XB1Uc4xZSpJMFly/nxd0hIvkmi GrG0+puC0+OyDV4z1JIURBIx2RnXEJxYvaFPID5g/IT7MtFqQnLKIZTJc2DXySECAwEAAaOCAy8w ggMrMB0GA1UdDgQWBBRXoW6yUY7G6nMFSxU+2lZm7KqcvDAfBgNVHSMEGDAWgBTpKerCBbuXyks/ cnl6+luCS7lqhDCB2QYDVR0fBIHRMIHOMIHLoIHIoIHFhoHCbGRhcDovLy9DTj1hZDEtbGF4LmRz LmljYW5uLm9yZygxKSxDTj1hZDEtbGF4LENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNl cyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPWRzLERDPWljYW5uLERDPW9yZz9jZXJ0 aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9p bnQwgcoGCCsGAQUFBwEBBIG9MIG6MIG3BggrBgEFBQcwAoaBqmxkYXA6Ly8vQ049YWQxLWxheC5k cy5pY2Fubi5vcmcsQ049QUlBLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2Vz LENOPUNvbmZpZ3VyYXRpb24sREM9ZHMsREM9aWNhbm4sREM9b3JnP2NBQ2VydGlmaWNhdGU/YmFz ZT9vYmplY3RDbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MA4GA1UdDwEB/wQEAwIFoDA9Bgkr BgEEAYI3FQcEMDAuBiYrBgEEAYI3FQiBurJNhMjIaoOtkz+HlPRag/mIbk6H68s/hoOYWgIBZAIB BzApBgNVHSUEIjAgBgorBgEEAYI3CgMEBggrBgEFBQcDBAYIKwYBBQUHAwIwNQYJKwYBBAGCNxUK BCgwJjAMBgorBgEEAYI3CgMEMAoGCCsGAQUFBwMEMAoGCCsGAQUFBwMCMEkGA1UdEQRCMECgJgYK KwYBBAGCNxQCA6AYDBZwYXVsLmhvZmZtYW5AaWNhbm4ub3JngRZwYXVsLmhvZmZtYW5AaWNhbm4u b3JnMEQGCSqGSIb3DQEJDwQ3MDUwDgYIKoZIhvcNAwICAgCAMA4GCCqGSIb3DQMEAgIAgDAHBgUr DgMCBzAKBggqhkiG9w0DBzANBgkqhkiG9w0BAQsFAAOCAQEAetxZFQDQ4/o0w3yjeD1PEIf4QJU3 vLp3QHq5I0I3ogj7UTGxAUudkuz7ttpb7K9HtBWRcbhyFY9blGQ2FLScWMBQkg1GO5pIwGSAkFGj iLPcyihxOASMrI1TBGaPuHUeMfOhqYl1tYgLWnabrd2mjjSLJHvJHJQ7ZSAexjGLhoFoj8/sVPk1 JIOvOOtIWZ3lky3eYI4Q7NYI4p9sHE6CAeOX52gpdvpVphaktfKZhGbIbeQiQTmdkcvOklHr6xHE CKXbhVZqEzOQtSxbsoGUOascj3k7PwFZPmWH/aQbnINDyqo97A++tKkSyVbmKbCeOORbH5hIGpYg CshNrXTOsTGCAyAwggMcAgEBMHYwXzETMBEGCgmSJomT8ixkARkWA29yZzEVMBMGCgmSJomT8ixk ARkWBWljYW5uMRIwEAYKCZImiZPyLGQBGRYCZHMxHTAbBgNVBAMTFGFkMS1sYXguZHMuaWNhbm4u b3JnAhMwAAAX4ZqelQKZcEdTAAMAABfhMA0GCWCGSAFlAwQCAQUAoIIBezAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMjA0MTQyMTA5MDVaMC8GCSqGSIb3DQEJBDEi BCBwCI+I7PgkzaTIKtvSJCbsy7Q3QbE6YKzc2qJ8sA3f0TCBhQYJKwYBBAGCNxAEMXgwdjBfMRMw EQYKCZImiZPyLGQBGRYDb3JnMRUwEwYKCZImiZPyLGQBGRYFaWNhbm4xEjAQBgoJkiaJk/IsZAEZ FgJkczEdMBsGA1UEAxMUYWQxLWxheC5kcy5pY2Fubi5vcmcCEzAAABfhmp6VAplwR1MAAwAAF+Ew gYcGCyqGSIb3DQEJEAILMXigdjBfMRMwEQYKCZImiZPyLGQBGRYDb3JnMRUwEwYKCZImiZPyLGQB GRYFaWNhbm4xEjAQBgoJkiaJk/IsZAEZFgJkczEdMBsGA1UEAxMUYWQxLWxheC5kcy5pY2Fubi5v cmcCEzAAABfhmp6VAplwR1MAAwAAF+EwDQYJKoZIhvcNAQELBQAEggEAK1Av+/351x+wbln2SZSn LmVuXS0Yd+eeF5oLdfK1q1Q+zJvVECv0d/7yM7gqV6KgamiVCnqmIl9FUvz4dIkym2krqXF04Bh/ NAxIbxES6WKTM/z8yrKJGMe2Pc1z0Slf3nf2B46g/4PSr2Tf6A1dIIm7KwniscHPZKuyRptJgwD0 vhmqiILmFCBOCFfRvMmZiSUg0ffxUBSwji1YBGl29oHUkRZU8rTLsw5btB6UziNfZA1ZrsYGAPK0 sTsKwcoDfmHsIKWbODm1nGI49KTWth/UglOmuspTPaxd8ZN2xiQhV84RHOC8GAxBoiZ/J05ugh7e C6s+vH75wgBsu1yzUwAAAAAAAA== --Apple-Mail=_59065514-AB72-4D73-8586-930967F948A0-- From nobody Thu Apr 14 14:24:04 2022 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 4BB953A1948; Thu, 14 Apr 2022 14:24:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.106 X-Spam-Level: X-Spam-Status: No, score=-2.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] 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 YNnQhmt9qK67; Thu, 14 Apr 2022 14:23:58 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.85]) (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 2C9FC3A193F; Thu, 14 Apr 2022 14:23:57 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4KfXWv3pYJzFK7; Thu, 14 Apr 2022 23:23:55 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1649971435; bh=8OVmwbuMp/YJ5gsaJijkbyBAayNs+8I6VNaP4x2Wa3U=; h=From:Subject:Date:References:Cc:In-Reply-To:To; b=PKPu09R/Z/8SWNZluRtzqj6XcFNy8HVq8HIfWbovbQoE/zb+TF32S9uitVVpUaTcb zZUvotUXT/4yxysuyJSTc80AOKTN2z1H7G2S++uCAt3/RGe7hR6oQ6xXzDwJpmMEHL PemkwJKAJ48MWQhL756aprzi/wwaLSrnIKjHFAGo= 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 0OFcgOZmtdNy; Thu, 14 Apr 2022 23:23:54 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Thu, 14 Apr 2022 23:23:54 +0200 (CEST) Received: from smtpclient.apple (24-246-53-111.cable.teksavvy.com [24.246.53.111]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by bofh.nohats.ca (Postfix) with ESMTPSA id 4A61A2E274E; Thu, 14 Apr 2022 17:23:53 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Paul Wouters Mime-Version: 1.0 (1.0) Date: Thu, 14 Apr 2022 17:23:49 -0400 Message-Id: <71364CAF-ABC4-47D8-A330-9305F53C656F@nohats.ca> References: Cc: dnsop-chairs , dnsop In-Reply-To: To: dnsop X-Mailer: iPhone Mail (19E241) Archived-At: Subject: Re: [DNSOP] [Ext] Fwd: Working Group Last Call for draft-ietf-dnsop-rfc5933-bis X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2022 21:24:03 -0000 On Apr 14, 2022, at 17:09, Paul Hoffman wrote: (Speaking with nohats on) >=20 > =EF=BB=BFOn Feb 1, 2022, at 12:35 PM, Tim Wicinski wr= ote: >> We were reviewing the Working Group Last Call for this, and we received n= o comments. We know there was interest in at least moving this forward, but= even Warren concurred we can't send this to the IESG unless there are folks= saying they feel it is ready to be published. >=20 > That was a few months ago. There were only two responses, one negative, on= e blandly positive ("seems reasonable").=20 Not sure if I replied at the time, but I think it should proceed - either as= dnsop or ISE document. There is a requirement, whether we like it or not.=20= > Can the chairs please say what they expect to do with this draft? I ask be= cause it is directly relevant to draft-ietf-dnsop-dnssec-bcp, where the draf= t's predecessor is mentioned. I predecessor should be marked dead regardless and not be in the dnssec-bcp d= ocument other than to strongly say not to use it. But that is somewhat separ= ate from this document. Paul From nobody Thu Apr 14 15:19:28 2022 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 17DB83A1B1D for ; Thu, 14 Apr 2022 15:19:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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.20210112.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 5fFT0y44FPOJ for ; Thu, 14 Apr 2022 15:19:23 -0700 (PDT) Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (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 5363C3A1B1B for ; Thu, 14 Apr 2022 15:19:23 -0700 (PDT) Received: by mail-qt1-x832.google.com with SMTP id hf18so4519183qtb.0 for ; Thu, 14 Apr 2022 15:19:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20210112.gappssmtp.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :references:from:in-reply-to:content-transfer-encoding; bh=setlD/STaGhUVJnVb+kHe/LcLHCD6vMqY2XQxRYmP7s=; b=Ge6YFII6hyRNJXsSjtXl/gXAD4nkjydndpWKZyncE47WAFj+GBOjCZxSTdUEILumlj 55gQaAbP23XFOscSJaFZYDB7MzAgJ9x0xvS8Tl/Mi4Sc+lyrpA6q6dpJgR+zfCytwEhF k+wYIR+Vx/s0wIXbKGnbYjCdurICB0EEZAl69ttvH2Jm19BQtnIA4Lk+7/k1isS1av3O 0+k1GmsBpEQ/q1arYLSH5KV1iIl1bbyo3AOzs4yA6kmtAX9EL7JE1j06zHTaYhw0zWAZ hUPkMlRH9rU9lYmcnnfilp1kLAYZnV0HcdYzlYjXy0XGVotG4EY2KifXNp24lzgO3XV/ WRgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=setlD/STaGhUVJnVb+kHe/LcLHCD6vMqY2XQxRYmP7s=; b=4+5CRZuwwOzmUnGvSAdTOtA+ZWGPvaQNyZoDW9COLSWPZB0hOur3SuX3FlwFLdk33l 4Vvz5P4meuxlTjdhfWiM03d2Fs0CQRF/uqzVpyRdoXVCVcrM6ZckVSM56V5RvUOSgL97 mw4Da+5+3DfTw3gmn3u8avu6eB0NqCzEq3foVZa0Q6vzkHOkR2P7Wt0Lx6A9XDazz4AV /1ylhuOcnskLvNB7WB78WOUOpoO7Ot0Ei3R3NJS2xGGzwWZnuhZw083IsjDfs8+ZoqV+ HiIsyivtXxDX341L7XzMM6y1aiFoxOr19XeCcruLOpZo2CL2hLefFz8NgbwVk1ESF5YH ba1A== X-Gm-Message-State: AOAM531RokZyt706FnrgFdNr+gz9303socQcHyZqSXJGBG9pwD8wM25X kwxgdnnrsCjvjOZjxj3RzF/2IGBCzJUzazVB X-Google-Smtp-Source: ABdhPJx+iTKCeRYGuF9fAxpyzMo09KQYkBeJ0nq99VrT5L6AfhwN8rWjsj5vNLSkAqNVI12+QWqmOQ== X-Received: by 2002:ac8:5dc6:0:b0:2e1:a763:d988 with SMTP id e6-20020ac85dc6000000b002e1a763d988mr3514526qtx.22.1649974761686; Thu, 14 Apr 2022 15:19:21 -0700 (PDT) Received: from [192.168.1.23] (pool-108-51-200-187.washdc.fios.verizon.net. [108.51.200.187]) by smtp.gmail.com with ESMTPSA id b194-20020ae9ebcb000000b0069c51557edasm1671706qkg.106.2022.04.14.15.19.20 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 14 Apr 2022 15:19:21 -0700 (PDT) Message-ID: <8c1db341-46c8-a622-91de-50438d97fe31@nthpermutation.com> Date: Thu, 14 Apr 2022 18:19:17 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Content-Language: en-US To: dnsop@ietf.org References: From: Michael StJohns In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [DNSOP] [Ext] Fwd: Working Group Last Call for draft-ietf-dnsop-rfc5933-bis X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2022 22:19:26 -0000 On 4/14/2022 5:09 PM, Paul Hoffman wrote: > On Feb 1, 2022, at 12:35 PM, Tim Wicinski wrote: >> We were reviewing the Working Group Last Call for this, and we received no comments. We know there was interest in at least moving this forward, but even Warren concurred we can't send this to the IESG unless there are folks saying they feel it is ready to be published. > That was a few months ago. There were only two responses, one negative, one blandly positive ("seems reasonable"). Hi Paul - Needs work is not a negative, it's a "not yet ready".  I don't have a problem with the publication of such a document, and I agree with Russ that the changes between this and RFC5933 are reasonable - but RFC5933 isn't a model of clarity itself and shouldn't be used as justification to publish this document. So "needs work" not "ready for publication" Mike > > Can the chairs please say what they expect to do with this draft? I ask because it is directly relevant to draft-ietf-dnsop-dnssec-bcp, where the draft's predecessor is mentioned. > > --Paul Hoffman > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop From nobody Thu Apr 14 17:22:21 2022 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 D046C3A0DE0; Thu, 14 Apr 2022 17:22: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: 7.46.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dnsop@ietf.org Message-ID: <164998213879.2617.6841496222817893578@ietfa.amsl.com> Date: Thu, 14 Apr 2022 17:22:18 -0700 Archived-At: Subject: [DNSOP] I-D Action: draft-ietf-dnsop-dnssec-bcp-01.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2022 00:22:19 -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 Security Extensions (DNSSEC) Author : Paul Hoffman Filename : draft-ietf-dnsop-dnssec-bcp-01.txt Pages : 10 Date : 2022-04-14 Abstract: This document describes the DNS security extensions (commonly called "DNSSEC") that are specified RFCs 4033, 4034, 4035, and a handful of others. One purpose is to introduce all of the RFCs in one place so that the reader can understand the many aspects of DNSSEC. This document does not update any of those RFCs. Another purpose is to move DNSSEC to Best Current Practice status. This document is currently maintained at https://github.com/paulehoffman/draft-hoffman-dnssec. Issues and pull requests are welcomed. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-bcp/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-dnssec-bcp-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-dnssec-bcp-01 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts From nobody Fri Apr 15 12:25:07 2022 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 C724A3A0FFF for ; Fri, 15 Apr 2022 12:24:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.109 X-Spam-Level: X-Spam-Status: No, score=-2.109 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 BFAk9qPq1LhZ for ; Fri, 15 Apr 2022 12:24:40 -0700 (PDT) Received: from mail5.verisign.com (mail5.verisign.com [69.58.187.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE11D3A1081 for ; Fri, 15 Apr 2022 12:24:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=9654; q=dns/txt; s=VRSN; t=1650050680; h=from:to:cc:date:message-id:references:in-reply-to: mime-version:subject; bh=56+6VS612RlwfosVlisY3uH2mFSahJnG3UzDRTUsalc=; b=IaQnRBluU4U0gTFHLmM3qC8RbIKLBuCZFLo3p+mHITR6y7I467NRuAxN fQjJUYFfVmnVLtTN/fUrFVeafHdF3eU9qzmn/pOnEPyNYGSlW6x8LuLPS 6Qm10psEZYek2nCzlQqoG9YfbWcpUMlzt6TlZ/8U5u8iMNxspaHfFi1Ud 0R5U48sX9UXzkJKqgNSHim1ZBjVDTsXnyTBPB9UPZ5nibaipLCt8uazSR IxrDR/C8j4wff7ysrf4v0VKXD/kvH/wdLpQRD0Vfv1uHzNrpXaLmwDN29 bOHLd1ki+u5gI4sLtQNAHx2QogW2KwK8Kgb6RC5CZABa9B8ftbxEqh4n/ w==; X-URL-LookUp-ScanningError: 1 IronPort-Data: A9a23:MeoiGqtTYzPkk0ewZoLGD7THlefnVOpeMUV32f8akzHdYApBs4E2v jNfGTXfaa7OOz2rZJktO86x6Alf7siEipMhHTLYn1l2SnNPpIzdWs/xwizYY3LIcMTNEhI84 ppGMdSecZhoHy6N9hunYrS+/HVyhPqET7akBuSeNy4uFQQ1GXd90Uo9w7Jii9Yyi4HhCAqG4 bsezyGx1HqNglaYZUpIsfrYwP8WgNzypC8A7Bt5YvtQpBnSlnYUB58FOee6KH6g6GD+99PSe wq4913Fw17x/wsxEoHi1a74cwgNSaXKewSPhXtdVrK+xBNFo3Qfkf6x3DJNaVtLk2fOlNl6x c8Lro21QBo1PuvHn+FaVgFbEmZyPKJH87LdPXPlqsya1UDKaH7txvhlBQc9J5FAz9sfPY01z hBkFQ0lbgyfn/nkh/WkVfYqisUsLcLmJp9ZsXZlihrhNq6MqDs+AP1gDHS4tAvc/fuiassyH eJEL2EHUTzAfwFXIQVQT40hg6Gkh3b+eDBCtBSeoq9wyFDolKaYe0WuaHA80TwgrG64t0CJz l4qhF8VdSz2TvTCj2Htz1qsmvPXhnG8H50NC/u09/Fri1CJ2ioYDxhRT0Oy5OSw0iaCt6lkx zspFlAG8O5pnHGDTsXhRwbq5zmboQFaV9tfEuY38h3Lwa3RpByBDy0ZR2ZrAODKz/TaMgHGr HfU2YiBOAFSjVG1dZ683uiY92+8aXFIfT8Oa38KEFBc6YS5q9w61kjDHt89QP680oSlSDr9/ WuH/XM071kxYWzn9I3gpAya3Gj8znTtZlRojukCdjv9tmuVXGMhDmCRwQCzAcxode51dXHc+ ilc8ySixLpWV8vVyHXQGL9l8IyBvJ5pDhWN2TaDILF8r1xBy1b7FWyHyGgjTKvBGp9slQ7BO Cc/iysIjHNgFCLCgZtMXm6EI59CIZ7ITo25C6+OPrKiVbAqHOOP1HkGiUe4gTixwBB0+U01E c/znc2EVR72BUn7pdYfqih0PbIDn0gDKW3vqZ/T0jr4+LezPUysV7o9GX2vP7sys4TdmVCAm zpfH5PiJxR3etfYOxbx3L5LdBYUJn8hHdb/p4pJbPWFZAFhHQnNCdeImfV4JNcjxvkO0LuYl p2+chYwJF7XiXTZKAmAQm5ucrL0XJl563k8OETAOH7xgCZ8Mdb3vM/zcbM6VKsh/q9O5MUlU sc6VMTeU/5sTA3IrmF1gZ7V6dYKmA6QrRqDIye/JiY2edhsRg7K0sfjYQb1+C8VSCGwsKMWr 7u70RvzQJcfSUJlFsm+VR6051mruyECnu9iBxKNOcdJPkDt681gLGr7lPluZd8WMhOFzTyfv +qLPSolSSD2i9dd2LH0aWqs9u9Fz8MW8pJmIlTm IronPort-HdrOrdr: A9a23:UoIzaaDL0tLQ/87lHelx55DYdb4zR+YMi2TDsHoBLCC9E/bo9f xG88566faZslgssRIb9uxoUZPoKU80nqQFgrX5U43CYCDW/EWlK4145ZbvznnKC0TFmtJ15O NFf7JlANP9SXp3na/BijWQIpIFzMOc+K6lwd3CyWxgJDsGV4h74xxnBh2gHkp6eQlDCfMCf6 ah2g== X-IronPort-AV: E=Sophos;i="5.90,263,1643691600"; d="p7s'?scan'208";a="13678808" Received: from BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) by BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2375.24; Fri, 15 Apr 2022 15:24:37 -0400 Received: from BRN1WNEX01.vcorp.ad.vrsn.com ([10.173.153.48]) by BRN1WNEX01.vcorp.ad.vrsn.com ([10.173.153.48]) with mapi id 15.01.2375.024; Fri, 15 Apr 2022 15:24:37 -0400 From: "Blacka, David" To: Peter van Dijk CC: dnsop WG Thread-Topic: [EXTERNAL] [DNSOP] More private algorithms for DNSSEC Thread-Index: AQHYUP5ycphYePj2lE+M8mHhH94/YQ== Date: Fri, 15 Apr 2022 19:24:37 +0000 Message-ID: <2DF5B8EA-80E8-4732-8863-F3797A780F6D@verisign.com> References: <5C105C71-B18C-4366-94F5-E8D60970109C@icann.org> <20B389EF-4909-43A0-9BC8-F57F5E332E8A@verisign.com> <1D59C3FB-4FCC-4A03-8E13-EA6902B14D2A@icann.org> <54622bd0dd3253187a9c9b69d0a1188a4d898bd9.camel@powerdns.com> In-Reply-To: <54622bd0dd3253187a9c9b69d0a1188a4d898bd9.camel@powerdns.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3654.120.0.1.13) x-originating-ip: [10.170.148.18] Content-Type: multipart/signed; boundary="Apple-Mail=_930197EF-870F-49EB-87CD-F19DFE244A98"; protocol="application/pkcs7-signature"; micalg=sha-256 MIME-Version: 1.0 Archived-At: Subject: Re: [DNSOP] More private algorithms for DNSSEC X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2022 19:24:50 -0000 --Apple-Mail=_930197EF-870F-49EB-87CD-F19DFE244A98 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Mar 23, 2022, at 5:45 AM, Peter van Dijk = wrote: >=20 > Caution: This email originated from outside the organization. Do not = click links or open attachments unless you recognize the sender and know = the content is safe.=20 >=20 > On Mon, 2022-03-21 at 19:32 +0000, Paul Hoffman wrote: >> On Mar 21, 2022, at 11:34 AM, Wessels, Duane = wrote: >>> Is it in response to the DNS-OARC talk we saw about implementing PQC = Falcon in PowerDNS, and they used the next unused algorithm number = rather than a private algorithm? >>=20 >> Nils could have picked 253 but probably didn't even think of looking = down to the bottom of the list. He was just following the time-honored = pattern in the IETF. :-) >=20 > (I am not speaking for Nils, to be clear.) >=20 > 253 is not for experiments - it is for private production. It requires > (as most of you might know) prefixing DNSKEY content with a private > algorithm specifier that looks like a domain name (or, for 254, with a > OID). This means if you were to use it for an experiment, your DNSKEY > content, and thus signer and validation code, would need to be changed > when you get a number assigned. Hey! There is an RFC about this! RFC 4955. If you look that one up, you might understand why I might be aware of = that one ;) That said, I didn't remember the number. Anyway, that RFC describes using the 253 and 254 private code points for = *doing experiments*. Although, to be clear, we weren't really thinking of new DNSSEC = algorithms as experiments (those would be "backwards compatible" = experiments). > So, Paul, I support the idea behind your draft, but not the current > wording. While more 253-like points might be somewhat useful, what we > really need are experimental code points with non-253 semantics. Well, we clearly don't need more code points with 253 semantics. I can = see that Paul updated it to say that (on 3/24): This document updates [RFC4034] to add seven more private use algorithms. Unlike private use algorithm 253, there is no restriction on the public key area in the DNSKEY RR and the signature area in the RRSIG RR. Thus, there are no domain names embdded in the public key or signature like there are with private use algorithm 253. This update brings the total number of private use algorithms that use the same format to eight. >=20 >=20 > Kind regards, > --=20 > Peter van Dijk > PowerDNS.COM BV - = https://secure-web.cisco.com/13BiMZSXDSomVBiVLMO81OOpFAzfdgvv6ubBC4kBzp0MF= NVxHAjB-U0ggojjjGqRr633YTsQpP9EWS2fps_2PkDMl4Npp7TAkKrLQ2C7KPz71WB0XyUMrEi= ra9LFixKJ542ReDXMA1xPBeIa1jrOCzOmcw2DovEmQ9MAC7IlFW1c37fpfSq7bAfpavOsW26_I= DGIlwEGzkC77lfGns3pefv-h8jqziBjFgyH6i56EY5jDjBvamSiQ-HHL8SWzOYmC/https%3A%= 2F%2Fwww.powerdns.com%2F >=20 > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > = https://secure-web.cisco.com/1vz4IYPF5-AIZvqtpsjPMKkgkz9QGkTMr5dT5w0nf5ZDa= qS_-qldXesfTCcYQTeol3_NPfK3d9YqfbymSWVcfqDXTQlEmOrmNcN29FH9mGE68sjotlov22q= iIl-4g_pIeY73R3IbIT0QJIVEpHXwTh2GeQ3r2InHV8vx0alG_5MogRrlrzX6b22SzZs2I5zkD= 1YgxbPt2ZPPGoo8ts3_4o2szbVNxORxLJjnkQPMkXYMyHRODX1hCyIaba4_YgTtm/https%3A%= 2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdnsop >=20 -- David Blacka =20 Verisign Fellow Verisign Product Engineering --Apple-Mail=_930197EF-870F-49EB-87CD-F19DFE244A98 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCDN0w ggYfMIIFB6ADAgECAhADuA0Dc6a64oQdstGwJ3SrMA0GCSqGSIb3DQEBCwUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBHMjAeFw0xOTA2MDQxMjM2MjBaFw0yOTA2 MDQxMjM2MjBaMG8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5EaWdpQ2VydCwgSW5jLjFHMEUGA1UE AxM+RGlnaUNlcnQgUEtJIFBsYXRmb3JtIEMyIFNoYXJlZCBTTUlNRSBJbmRpdmlkdWFsIFN1YnNj cmliZXIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCmay8IyCiMMl3lgLo6BSrd LBKvx0U1KZR/8PzvS/rsZDBQJLuVgmOTaBxUrNqo9WtejI9me5HihbHKE9BtydcyC8f+8cOQOX3h Ojs0SZr2P9eXAR8SWf0p/Q/1NkYRorjjPo4z0RovEnX/cl0of7Cny0fW65tMBt/exaxQTso6Ea1i RF9U8bf6ZsFkevsNt1WKSY9X/QvWUhfoZb4fsoa8JUZkJMzb12wS/cLnWhaO5G7cqZ+E2KqhuqlP CrlUGFNVuaPcGsuZRy2X1ByMgA4VIIwNNG0RlPa+KSqpixO6RK7kWTlt5BGhgtKw7MnuDcLtM2Bc SyaPIEqZnapn5qf7AgMBAAGjggK/MIICuzAdBgNVHQ4EFgQU3LcfIDF0S5Qadq2Dgq34xqPwRF8w HwYDVR0jBBgwFoAUzsNKuZlV8rjbYL+pfr1WtZc2p9YwDgYDVR0PAQH/BAQDAgGGMEwGA1UdJQRF MEMGCCsGAQUFBwMCBggrBgEFBQcDBAYKKwYBBAGCNwoDBAYKKwYBBAGCNxQCAgYKKwYBBAGCNwoD DAYJKoZIhvcvAQEFMBIGA1UdEwEB/wQIMAYBAf8CAQAwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUF BzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9j cmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RHMi5jcmwwOqA4oDaGNGh0dHA6 Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RHMi5jcmwwggEiBgNVHSAE ggEZMIIBFTCCAREGCWCGSAGG/WwFAjCCAQIwKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2lj ZXJ0LmNvbS9DUFMwgdUGCCsGAQUFBwICMIHIDIHFQW55IHVzZSBvZiB0aGlzIENlcnRpZmljYXRl IGNvbnN0aXR1dGVzIGFjY2VwdGFuY2Ugb2YgdGhlIERpZ2lDZXJ0IENQL0NQUyBhbmQgUmVseWlu ZyBQYXJ0eSBBZ3JlZW1lbnQgd2hpY2ggbGltaXQgbGlhYmlsaXR5IGFuZCBhcmUgaW5jb3Jwb3Jh dGVkIGhlcmVpbiBieSByZWZlcmVuY2UuIGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNvbS9ycGEtdWEw JwYDVR0RBCAwHqQcMBoxGDAWBgNVBAMTD0RpZ2lDZXJ0UEtJLTMtMjANBgkqhkiG9w0BAQsFAAOC AQEAFTczZjttMnThPMxQyeeuZ/VeQHCNNqxCze644O19xXE0Wt3qBx1VRU/QdL4kPtAWvg9sMHhQ tLvp9ySna4uF5+ffFQeHUbX12yBrfmgATdKHP2noPeyVCXnculSqsF/F/854dBW9Z1jfMtvxp/qb TPOf9d5d1mxt+mJ4sDfvd0wl3U2wVCJMUbSXjs8alHeU6ematIwXios5sn2cQcIpMtm/ySjYvhh4 G1DMUrQdpJZTBovuXh8yA3Urq8ZgmBd6mzem450LB48fa6TQyRUZJfr26Ke8EOrBEKLovi+iTCMQ bQsR+4TEsJlJBPemkwqpcfI4V3GVYQjq63ECC2ftATCCBrYwggWeoAMCAQICEEX1DV/4e4sX5EJk jP+BlM0wDQYJKoZIhvcNAQELBQAwbzELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDkRpZ2lDZXJ0LCBJ bmMuMUcwRQYDVQQDEz5EaWdpQ2VydCBQS0kgUGxhdGZvcm0gQzIgU2hhcmVkIFNNSU1FIEluZGl2 aWR1YWwgU3Vic2NyaWJlciBDQTAeFw0yMjAxMjYwMDAwMDBaFw0yMzAyMjUyMzU5NTlaMG0xIjAg BgkqhkiG9w0BCQEWE2RhdmlkYkB2ZXJpc2lnbi5jb20xFjAUBgNVBAMMDUJsYWNrYSwgRGF2aWQx FjAUBgNVBAsMDUVOVEVSUFJJU0UgSVQxFzAVBgNVBAoMDlZlcmlTaWduLCBJbmMuMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAweKFEG67MdRi4KwbBY3x9PHfrWES2Vm597KTkK7UIUjy F65UE6v1w6GN43QDESOMEzwLcQRU4QPIf1pWYfnBsxqSXSZdOSKMsnQ4XMnG0hGX48JMQYCuiYzD U3xpQHH+McHJgDBKFljcgpacyKVHR0YvfoMPSUjPW62ukq5MaUW3MDtVv1OjHmGX/9iUnVWMniBB SZxlg9Jv90jdL45YJzTzgraTcCPQgSMnHQJXR1ao2cvEPqH3EvZo4u82CMYbROtFAhwW+S2t39yr jWpE2va0FkvPCkKhnpxAUPEaQmmTdy2wyUZ1uA910iOExCHDkYW8CKmQABXAUMNssUJ+XwIDAQAB o4IDTjCCA0owDAYDVR0TAQH/BAIwADAOBgNVHQ8BAf8EBAMCBaAwFgYDVR0lAQH/BAwwCgYIKwYB BQUHAwQwHQYDVR0OBBYEFFaFSmgtcRDwfRFiqt3Vq8LJCLn5MB4GA1UdEQQXMBWBE2RhdmlkYkB2 ZXJpc2lnbi5jb20wHwYDVR0jBBgwFoAU3LcfIDF0S5Qadq2Dgq34xqPwRF8wfwYIKwYBBQUHAQEE czBxMCgGCCsGAQUFBzABhhxodHRwOi8vcGtpLW9jc3AuZGlnaWNlcnQuY29tMEUGCCsGAQUFBzAC hjlodHRwOi8vY2FjZXIuc3ltYXV0aC5jb20vbXBraS9kaWdpY2VydGMyc2hhcmVkc21pbWVjYS5j cnQwXQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL3BraS1jcmwuc3ltYXV0aC5jb20vY2FfNGI1ZDVm ZDNiMjY1MWIzNTIyOTBlMzY0NmFiY2MwMDEvTGF0ZXN0Q1JMLmNybDCCASIGA1UdIASCARkwggEV MIIBEQYJYIZIAYb9bAUCMIIBAjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29t L0NQUzCB1QYIKwYBBQUHAgIwgcgagcVBbnkgdXNlIG9mIHRoaXMgQ2VydGlmaWNhdGUgY29uc3Rp dHV0ZXMgYWNjZXB0YW5jZSBvZiB0aGUgRGlnaUNlcnQgQ1AvQ1BTIGFuZCBSZWx5aW5nIFBhcnR5 IEFncmVlbWVudCB3aGljaCBsaW1pdCBsaWFiaWxpdHkgYW5kIGFyZSBpbmNvcnBvcmF0ZWQgaGVy ZWluIGJ5IHJlZmVyZW5jZS4gaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29tL3JwYS11YTBCBgkqhkiG 9w0BCQ8ENTAzMAoGCCqGSIb3DQMHMAsGCWCGSAFlAwQBAjALBglghkgBZQMEARYwCwYJYIZIAWUD BAEqMC0GCmCGSAGG+EUBEAMEHzAdBhNghkgBhvhFARABAgIBAYO+/44sFgYyNDc2NjQwOQYKYIZI AYb4RQEQBQQrMCkCAQAWJGFIUjBjSE02THk5d2Eya3RjbUV1YzNsdFlYVjBhQzVqYjIwPTANBgkq hkiG9w0BAQsFAAOCAQEAgGYA/KUA8DSCBZqCccLTOwYWJHBN4kR1IbYJP00koaigKzB6ZlRrOrdR hL3BlIOVJKfnf0IY0QRa8ABAUtw7q4QUwg9F//l8+db/Tn7Z80ruT/5FK+MPEhEXmTA8gKPG4oNJ jprkP20xx0PSwGWZ5qt9vn40Drye+aG0RiOJ/y32+Rp7oHjjEYT47F+F+34/fsKIab8GaKsUWK4t BDb+VZra+Tj4IrmnkKeYnGDZwhmbPPCWLrY6Uli2XdCcxJQHvn/Bumcyj1M5jgSQHI5ObToH6J3L yPbLkn60NFu3a8NFEe4aVnshC+2ZXktCEBCtbSNsPbbyJBr735uh3kXO3DGCA0wwggNIAgEBMIGD MG8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5EaWdpQ2VydCwgSW5jLjFHMEUGA1UEAxM+RGlnaUNl cnQgUEtJIFBsYXRmb3JtIEMyIFNoYXJlZCBTTUlNRSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EC EEX1DV/4e4sX5EJkjP+BlM0wDQYJYIZIAWUDBAIBBQCgggGZMBgGCSqGSIb3DQEJAzELBgkqhkiG 9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTIyMDQxNTE5MjQzN1owLwYJKoZIhvcNAQkEMSIEIAHh994w N7VVmYZ/iyNwmrLFFUB1mRjnX0+FiMdu9zH8MIGUBgkrBgEEAYI3EAQxgYYwgYMwbzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDkRpZ2lDZXJ0LCBJbmMuMUcwRQYDVQQDEz5EaWdpQ2VydCBQS0kgUGxh dGZvcm0gQzIgU2hhcmVkIFNNSU1FIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQQIQRfUNX/h7ixfk QmSM/4GUzTCBlgYLKoZIhvcNAQkQAgsxgYaggYMwbzELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDkRp Z2lDZXJ0LCBJbmMuMUcwRQYDVQQDEz5EaWdpQ2VydCBQS0kgUGxhdGZvcm0gQzIgU2hhcmVkIFNN SU1FIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQQIQRfUNX/h7ixfkQmSM/4GUzTANBgkqhkiG9w0B AQsFAASCAQCFgySeElkQDuwvfmzMlNTB0DApFHETQbgnrjXvF6uO6i789x5fwxu5fo9SSuAbuqSN S/cAXDiwstB3N4txBtG/ncg5hWLL3yyZZpbHneI/mrVMCNzhgyogvqhNAUKQ0QoRB92YhL9abFOr ugeKShBNLqL9M9IdksCG1kSVnIHRLi/lrDKjmZBaU50Mk4QNcP39lOSdSCDO537qEf8PVmpWXi2o /nYU+ZSFBRSywTQf60G8txMTeojazaQnE4eVdeDWezT9hCHYClE20j1NJ122hfJxPwnrPVzFBjbN VsEIuSMkq3DbcN0RbFm8nvcm5uliXtr2t5ZRFYK0b1d4lQk1AAAAAAAA --Apple-Mail=_930197EF-870F-49EB-87CD-F19DFE244A98-- From nobody Fri Apr 15 15:44:43 2022 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 AD8C33A15E5 for ; Fri, 15 Apr 2022 15:44:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.109 X-Spam-Level: X-Spam-Status: No, score=-2.109 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 KvqpEXSQN0Jw for ; Fri, 15 Apr 2022 15:44:36 -0700 (PDT) Received: from mail3.verisign.com (mail3.verisign.com [72.13.63.32]) (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 99E933A15E2 for ; Fri, 15 Apr 2022 15:44:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=1598; q=dns/txt; s=VRSN; t=1650062677; h=from:to:cc:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version:subject; bh=9VhxxeyYWbJzYoxCChhgIssl3uO8+oJuCj/oxoXjsW0=; b=NFsklQ80MlKTL2xxEFqBJ11J6GBUsYg1tFdREBxqwudez/ltWY834dRE 2evcFodrj1YfyBO5gRrmSQURH6IHG3F3O4stWnI+7hnkZS/nJFCTTIE+F WJ6cwlBR1HRAi+ItHzqqVo/zymOkG47Q31ywMSq13ogN2N1Dzih1wI3d2 jDRo0rCY0j0SgkbjP2fu7/x1uzvaceQo+WK0sK7Usz+LGeeobKHAoLDHf OatFokCU6TphDqglwwhgGlV9c4YtGcw9ynRKXw1Zsap9UA85EgLFntNmO 2kpQppl/EAbSnNHZsOzPgBkRwMzxM96QIrOB0voyPSlHjt5zUZQyFoLfu w==; IronPort-Data: A9a23:FBlOE69twVT3N7BAeYcEDrUDPnyTJUtcMsCJ2f8bNWPcYEJGY0x3z TYaUWjQPayCY2WgftxyOdjn8UoD6pTdmINqHAVs+yAxFiIbosf7XtnIdU2Y0wF+jCHgZBk+s 5hBMImowOQcFCK0SsKFa+C5xZVEOCXhqoPUUIYoAAgoLeNfYHpn2EoLd9IR2NYy24DlWl7V4 rsenuWEULOb828sWo4rw//bwP9flKyaVOQw5wFWiVhj5TcyplFNZH4tDfjZw0jQG+G4KtWHq 9Prl9lVyEuCpktwVYn1+lrMWhZirrb6ZWBig1IIA/Ty2kAqSiYais7XP9JEAatbZqngc3mcB 7yhuLTpITrFMJEgl8wtajYCFQdUPJZl/ZDIBGXj7cmj7UDvJi6EL/VGVCnaPKUywMAuPkdjx aRCbi4GaQqbweu6hqyhUe8qjcMmRCXpFNpH/Cg/lneAUK1gHcGrr6bivLe02B88mc1VBvvaf OIHZCBudxXPZVtEPVJ/5JcWxbvz2CGuLWcwRFS9gIkZzE7V6jxI4oPuauOLduONHsh1pxPNz o7B1yGjav0AD/STzyGt/Hb1ieLV2y/2MKoeEqa/7tZrjUGdgGsJB3UruUCTq+O/01G4VsIHc QkP5DBoqKkpsUasCNPnWUT+vmSfuFgXXN84//AG1TxhA5H8u26xblXohBYYADD6nKfanQAX6 2I= IronPort-HdrOrdr: A9a23:ypTx/qFWcHvWnulXpLqENceALOsnbusQ8zAXPidKOHlom62j5q KTdZsgtSMc5Ax+ZJhCo7+90cC7KBvhHPVOkOos1NmZPTXOiS+HIIZv9oP+zzClMD2WzIJg/J YlV6RlEtX/ARxZgdaS2mOFOudl5NWc6qiniaPl0nF3QWhRBp1I9QtjFQqBKEFwSTRHAZZRLv Gh2vY= X-IronPort-AV: E=Sophos;i="5.90,264,1643673600"; d="scan'208";a="14360962" Received: from BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) by BRN1WNEX02.vcorp.ad.vrsn.com (10.173.153.49) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2375.24; Fri, 15 Apr 2022 18:44:32 -0400 Received: from BRN1WNEX01.vcorp.ad.vrsn.com ([10.173.153.48]) by BRN1WNEX01.vcorp.ad.vrsn.com ([10.173.153.48]) with mapi id 15.01.2375.024; Fri, 15 Apr 2022 18:44:32 -0400 From: "Wessels, Duane" To: Ralf Weber CC: dnsop Thread-Topic: [EXTERNAL] [DNSOP] I-D Action: draft-ietf-dnsop-glue-is-not-optional-04.txt Thread-Index: AQHYURpfgQxJljzSL0OAhOZV2gNJUA== Date: Fri, 15 Apr 2022 22:44:32 +0000 Message-ID: References: <164435963503.4033.12918772667601928806@ietfa.amsl.com> <13032699-D701-436A-8924-D0628B5DD796@verisign.com> <78C5F649-DE06-4D81-BCF0-EEDF33CBC9E3@fl1ger.de> In-Reply-To: <78C5F649-DE06-4D81-BCF0-EEDF33CBC9E3@fl1ger.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3654.120.0.1.13) x-originating-ip: [10.170.148.18] Content-Type: text/plain; charset="us-ascii" Content-ID: <3B9015E1D5F7AE4F833324ED517DD2D6@verisign.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-glue-is-not-optional-04.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2022 22:44:41 -0000 > On Mar 22, 2022, at 6:02 AM, Ralf Weber wrote: >=20 > Moin! >=20 > So to follow up on my comment in the working group on registries not havi= ng anything to do with it. I understand that this drafts is for authoritati= ve name server implementers, however I think that we should make clear that= an authoritative name server not answering correct by this draft might do = so because it does not have sufficient data. >=20 > So we currently have in the introduction: >=20 > Note that this document only clarifies requirements of name server > software implementations. It does not place any requirements on data > placed in DNS zones or registries. >=20 > how about adding: >=20 > However missing data might make it impossible for a name server to answer= with the correct (referral) glue data. >=20 > And maybe add some encouragement or referral ;-) to work that has to be d= one elsewhere. Ralf (and others), how does this look to you? In other words, this document only makes requirements on "available glue records" (i.e., those given in a zone), but does not make requirements regarding thier presence in a zone. If some glue records are absent from a given zone, an authoritative name server may be unable to return a useful referral response for the corresponding domain. The IETF may want to consider a separate update to the requirements for including glue in zone data, beyond those given in [@!RFC1034] and [@!RFC1035]. Also here: https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-glue-is-not-op= tional/pull/35 DW From nobody Sat Apr 16 11:06:43 2022 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 F38D63A0D61; Sat, 16 Apr 2022 11:06:39 -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: 7.46.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dnsop@ietf.org Message-ID: <165013239988.2692.635033794447169506@ietfa.amsl.com> Date: Sat, 16 Apr 2022 11:06:39 -0700 Archived-At: Subject: [DNSOP] I-D Action: draft-ietf-dnsop-nsec3-guidance-08.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2022 18:06:41 -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 : Guidance for NSEC3 parameter settings Authors : Wes Hardaker Viktor Dukhovni Filename : draft-ietf-dnsop-nsec3-guidance-08.txt Pages : 11 Date : 2022-04-16 Abstract: NSEC3 is a DNSSEC mechanism providing proof of non-existence by asserting that there are no names that exist between two domain names within a zone. Unlike its counterpart NSEC, NSEC3 avoids directly disclosing the bounding domain name pairs. This document provides guidance on setting NSEC3 parameters based on recent operational deployment experience. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-nsec3-guidance/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-nsec3-guidance-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-nsec3-guidance-08 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts From nobody Sat Apr 16 11:07:27 2022 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 511DD3A0DEF; Sat, 16 Apr 2022 11:07:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 xJ740pvb6std; Sat, 16 Apr 2022 11:07:02 -0700 (PDT) Received: from mail.hardakers.net (mail.hardakers.net [168.150.192.181]) (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 CC4123A0DD2; Sat, 16 Apr 2022 11:07:01 -0700 (PDT) Received: from localhost (unknown [10.0.0.9]) by mail.hardakers.net (Postfix) with ESMTPA id 0AE4029B6A; Sat, 16 Apr 2022 11:07:01 -0700 (PDT) From: Wes Hardaker To: Warren Kumari Cc: draft-ietf-dnsop-nsec3-guidance@ietf.org, dnsop References: Date: Sat, 16 Apr 2022 11:07:00 -0700 In-Reply-To: (Warren Kumari's message of "Wed, 13 Apr 2022 09:37:35 -0700") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [DNSOP] AD Review of: draft-ietf-dnsop-nsec3-guidance X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2022 18:07:16 -0000 Warren Kumari writes: > Please SHOUT loudly once you've had a chance to address these, and > I'll start IETF LC. Hi Warren, Thanks for the comments and suggestions. Looks good to us and I've made the changes and published -08. -- Wes Hardaker USC/ISI From nobody Sun Apr 17 02:00:00 2022 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 F29BF3A10FF; Sun, 17 Apr 2022 01:59:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.11 X-Spam-Level: X-Spam-Status: No, score=-7.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nlnetlabs.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 2S6kj-o-LwB5; Sun, 17 Apr 2022 01:59:54 -0700 (PDT) Received: from outbound.soverin.net (outbound.soverin.net [IPv6:2a01:4f8:fff0:65::8:228]) (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 1C8233A1109; Sun, 17 Apr 2022 01:59:53 -0700 (PDT) Received: from smtp.soverin.net (unknown [10.10.3.11]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by outbound.soverin.net (Postfix) with ESMTPS id C47D129E; Sun, 17 Apr 2022 08:59:42 +0000 (UTC) Received: from smtp.soverin.net (smtp.soverin.net [10.10.4.100]) by soverin.net DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nlnetlabs.nl; s=soverin; t=1650185982; bh=DPjOAmQj8b9fYo1dZmtZyl+/Dxq300J9OKXZ089O/dA=; h=Date:From:To:Cc:References:Subject:In-Reply-To:From; b=BtevASLDRskK4SRJc3qCXzjcIOeR2EQrjf19Fy0PG36jaCE1VdbWdN2rMEbwVuKAq kV+WFhx5v/N6tE+MeUdyphcuvntno16GJ78OlXWin263Tuu0xB1E6HMqVuJC2PIC9W nTgPb+4oPtileYzn0JIa4UunsaM5KVh5qQkj6FjDf6jCxsxCUEM2G77XdjNOSprBjf wnxGPQXBpcaATG0w2YTLJ0BEcGyG9ISMSsjxV+9zkFAJeBFadUhnVEwTT/dASgRp/h 3YXlHjbidC3V3BqAlzpKC5XTN7mkMcnMS0uS8uUEgMbCuorZtYli+OoDgZB2AV5X8t WZCxPDUGHIBCA== Message-ID: <8306ad75-038f-15df-34f3-63c85442bfda@NLnetLabs.nl> Date: Sun, 17 Apr 2022 10:59:40 +0200 MIME-Version: 1.0 Content-Language: en-GB From: Benno Overeinder To: DNSOP Working Group Cc: DNSOP WG Chairs References: <8d7e1085-33f3-6a28-3464-3f0105b54182@NLnetLabs.nl> In-Reply-To: <8d7e1085-33f3-6a28-3464-3f0105b54182@NLnetLabs.nl> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-thomassen-dnsop-dnssec-bootstrapping X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2022 08:59:59 -0000 Hi all, Thank you for your feedback and willingness to contribute text or review the document in the working group. The Call for Adoption has ended and with good support from the WG, the document is adopted as a WG Internet-Draft. The chairs will ask the authors to resubmit the document with the name draft-ietf-dnsop-dnssec-bootstrapping. Thanks, -- Benno On 25/03/2022 16:27, Benno Overeinder wrote: > As announced during the DNSOP meeting this week at the IETF 113, we are > starting a Call for Adoption for the > draft-thomassen-dnsop-dnssec-bootstrapping.  With the survey we > conducted before the last IETF 112, this draft was a clear candidate. > > With this email we start a period of two weeks for the call for adoption > of draft-thomassen-dnsop-dnssec-bootstrapping on the mailing list. > > The draft is available here: > https://datatracker.ietf.org/doc/draft-thomassen-dnsop-dnssec-bootstrapping/ > > > Please review this draft to see if you think it is suitable for adoption > by DNSOP, and comments to the list, clearly stating your view. > > Please also indicate if you are willing to contribute text, review, etc. > > This call for adoption ends: 8 April 2022 > > Thanks, > > Suzanne, Tim and Benno > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop From nobody Sun Apr 17 02:01:49 2022 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 2526B3A111B; Sun, 17 Apr 2022 02:01:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.11 X-Spam-Level: X-Spam-Status: No, score=-2.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nlnetlabs.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 v7IB3IGIfIGg; Sun, 17 Apr 2022 02:01:41 -0700 (PDT) Received: from outbound.soverin.net (outbound.soverin.net [116.202.126.228]) (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 B10273A110D; Sun, 17 Apr 2022 02:01:40 -0700 (PDT) Received: from smtp.soverin.net (unknown [10.10.3.11]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by outbound.soverin.net (Postfix) with ESMTPS id CC43729E; Sun, 17 Apr 2022 09:01:37 +0000 (UTC) Received: from smtp.soverin.net (smtp.soverin.net [10.10.4.99]) by soverin.net DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nlnetlabs.nl; s=soverin; t=1650186097; bh=rZ23AdD20D015m5ioSdRPxFAk3kRFL3fnTf/ZEvr4EU=; h=Date:Subject:From:To:Cc:References:In-Reply-To:From; b=kdL6kpiVmWt5NZH4ToeU/IW2WY9XLlUgFRzkS2n9tlv04oz5uUM7dV1+5Cn5vGlKt QoWpvKshm/R4GhAzqXwR4vivxKjlE35h1lUhdwsbMRR/d6KyWBUqunUUJde5tK/huV nVcvKOlVMgHvjG86K9cgnsDJzHXbpbEftOnuMabbt3WUHREqDgOipAJanAhyC51Xmx ZZj5ZRaADoLg5jM+6lK1KjEUJg4JobtkohJcbnpryL9bJzMk0EQ7GC8CwaiInkiF65 k/VXMM7LSiXGb5k+WWvU+4+aU41hRHoUZw9imQleV4186d5K6GtWZeNDuPO3cGSQja o3U0UUhz1qlug== Message-ID: <739ad0ca-f50f-864b-45f8-7f81e8fe8124@NLnetLabs.nl> Date: Sun, 17 Apr 2022 11:01:35 +0200 MIME-Version: 1.0 Content-Language: en-GB From: Benno Overeinder To: DNSOP Working Group Cc: DNSOP WG Chairs References: <93c34015-f441-20a3-b2b0-54159a70d021@NLnetLabs.nl> In-Reply-To: <93c34015-f441-20a3-b2b0-54159a70d021@NLnetLabs.nl> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-wisser-dnssec-automation X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2022 09:01:47 -0000 Hi all, Thank you for your feedback and willingness to contribute text or review the document in the working group. The Call for Adoption has ended and with good support from the WG, the document is adopted as a WG Internet-Draft. The chairs will ask the authors to resubmit the document with the name draft-ietf-dnsop-dnssec-automation. Thanks, Suzanne, Tim and Benno On 25/03/2022 16:35, Benno Overeinder wrote: > As with the previous Call for Adoption today, at this week's DNSOP > meeting at IETF 113, we announced that we are initiating a Call for > Adoption for the draft-wisser-dnssec-automation.  With the survey we > conducted for the last IETF 112, this draft was also a clear candidate. > > With this email we start a period of two weeks for the call for adoption > of draft-wisser-dnssec-automation on the mailing list. > > The draft is available here: > https://datatracker.ietf.org/doc/draft-wisser-dnssec-automation/. > > Please review this draft to see if you think it is suitable for adoption > by DNSOP, and comments to the list, clearly stating your view. > > Please also indicate if you are willing to contribute text, review, etc. > > This call for adoption ends: 8 April 2022 > > Thanks, > > Suzanne, Tim and Benno > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop From nobody Mon Apr 18 01:44:11 2022 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 C4D8E3A09B5 for ; Mon, 18 Apr 2022 01:44:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 24gmEdR5w41v for ; Mon, 18 Apr 2022 01:44:07 -0700 (PDT) Received: from smtp.guxx.net (nyx.guxx.net [85.10.208.173]) by ietfa.amsl.com (Postfix) with ESMTP id 626173A09A4 for ; Mon, 18 Apr 2022 01:44:06 -0700 (PDT) Received: from [192.168.42.98] (p54b8a429.dip0.t-ipconnect.de [84.184.164.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by nyx.guxx.net (Postfix) with ESMTPSA id 14B665F402FE; Mon, 18 Apr 2022 08:44:03 +0000 (UTC) From: Ralf Weber To: "Wessels, Duane" Cc: dnsop Date: Mon, 18 Apr 2022 10:43:50 +0200 X-Mailer: MailMate (1.14r5886) Message-ID: In-Reply-To: References: <164435963503.4033.12918772667601928806@ietfa.amsl.com> <13032699-D701-436A-8924-D0628B5DD796@verisign.com> <78C5F649-DE06-4D81-BCF0-EEDF33CBC9E3@fl1ger.de> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-glue-is-not-optional-04.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2022 08:44:10 -0000 Moin! On 16 Apr 2022, at 0:44, Wessels, Duane wrote: > Ralf (and others), > > how does this look to you? > > In other words, this document only makes requirements on "available > glue records" (i.e., those given in a zone), but does not make > requirements regarding thier presence in a zone. Typo here “their presence in a zone” > If some glue records are absent from a given zone, an authoritative > name server may be unable to return a useful referral response for > the corresponding domain. The IETF may want to consider a separate > update to the requirements for including glue in zone data, beyond > those given in [@!RFC1034] and [@!RFC1035]. Yeah that looks fine to me. The main point was to make sure that zone data can also be a cause of failed/false referral. This text addresses this. So long -Ralf ——- Ralf Weber