Re: [DNSOP] [Ext] Call for Adoption: draft-belyavskiy-rfc5933-bis

Paul Hoffman <paul.hoffman@icann.org> Tue, 07 July 2020 02:17 UTC

Return-Path: <paul.hoffman@icann.org>
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 24ADC3A08ED for <dnsop@ietfa.amsl.com>; Mon, 6 Jul 2020 19:17:18 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DGjq9YRCj9vf for <dnsop@ietfa.amsl.com>; Mon, 6 Jul 2020 19:17:16 -0700 (PDT)
Received: from ppa4.dc.icann.org (ppa4.dc.icann.org [192.0.46.77]) (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 3CB563A08EB for <dnsop@ietf.org>; Mon, 6 Jul 2020 19:17:16 -0700 (PDT)
Received: from PFE112-CA-2.pexch112.icann.org (out.west.pexch112.icann.org [64.78.40.10]) by ppa4.dc.icann.org (8.16.0.42/8.16.0.42) with ESMTPS id 0672HBCI011377 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 7 Jul 2020 02:17:12 GMT
Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 6 Jul 2020 19:17:09 -0700
Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1497.006; Mon, 6 Jul 2020 19:17:09 -0700
From: Paul Hoffman <paul.hoffman@icann.org>
To: Tim Wicinski <tjw.ietf@gmail.com>
CC: "dnsop@ietf.org" <dnsop@ietf.org>
Thread-Topic: [DNSOP] [Ext] Call for Adoption: draft-belyavskiy-rfc5933-bis
Thread-Index: AQHWRYEcUoh5DWNcfECeWUoumkosw6je9SkAgADXJICAAL1IgIAADZmAgAAMjQCAABJVgIAC7xuAgABS0ICABG52doATefQAgAATYIA=
Date: Tue, 7 Jul 2020 02:17:09 +0000
Message-ID: <E4D1903A-47AD-4E18-BF1F-D491F6B63174@icann.org>
References: <CADyWQ+H4713BnZDntTuVW0FrO59zZ9NFJ=J=n9JFFq2zmfy2pQ@mail.gmail.com> <A930F8C6-9C33-4933-AC37-579ACEF5B325@ogud.com> <7FF83D52-F20B-4FF2-82AA-416835FCA5F4@isc.org> <CADqLbzJsJ6etv-eZuabLsMO4g+XYgktgpuP-fTNSi1cFTwdOGg@mail.gmail.com> <68eb8413-8704-40a3-9765-7eb19ebd0e78@www.fastmail.com> <CABcZeBORz-ustvXvrYaMm15rAHUfA3zR8Sr3ZscLWB6YJ6-s8w@mail.gmail.com> <CADyWQ+EOcTWX6PrbQUmqM6=Z442bE7itFAG6No0b9MZdcARbOg@mail.gmail.com> <CABcZeBOwxO6=Qpoyk=_cDsP5G__3CfjKV8p+boGY4-9OX=Gh8w@mail.gmail.com> <CADyWQ+Ge7AmGKT3PZ9SQDkHWi9315T=xbLcx4vQ23e=4T=zmNg@mail.gmail.com> <C2C9BDB4-AA7B-47B8-8735-2A529B37B4BA@icann.org> <CADqLbzLdu-ceWDKk5aUYTe3WzAntJKh5QTncHyy137W=nyDSfQ@mail.gmail.com> <7269525A-5376-48AA-B9DC-84BE9D84BA36@icann.org> <40d8663d-5f39-4900-b1c6-e78d73ebffcd@www.fastmail.com> <431980F9-988B-4212-8FF5-8A64436C8392@icann.org> <CABcZeBMuHMrLyPrMgfAP_4miDi5WHvvgUnsgmeCkRO=d=UDifA@mail.gmail.com> <1CEA89AD-CE7F-42BF-B2DF-1CF99846E47D@icann.org> <CAKW6Ri5cyhkP_3AwR=Tf6q9-P0Spx9N79OFc-1fafmoxz2BPaA@mail.gmail.com> <8AA61029-3E0A-491C-ACC4-F8DC43887109@gmail.com> <A7CA0EAF-0B42-4884-A4B9-C4A4BC8A3D8B@icann.org> <ybla70sgk73.fsf@w7.hardakers.net> <CADyWQ+GcD4ED8_z0ZcVZWpNQ+xcV=Q7W+9mvFGaw5QFO=Po1UA@mail.gmail.com>
In-Reply-To: <CADyWQ+GcD4ED8_z0ZcVZWpNQ+xcV=Q7W+9mvFGaw5QFO=Po1UA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [192.0.32.234]
x-source-routing-agent: Processed
Content-Type: multipart/signed; boundary="Apple-Mail=_09BCF0D5-4518-4D9B-B9FD-13935249A88A"; protocol="application/pkcs7-signature"; micalg=sha-256
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-07-07_01:2020-07-06, 2020-07-06 signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/9gKiV0RJ8IS8__FOwCyoimDgZuI>
Subject: Re: [DNSOP] [Ext] Call for Adoption: draft-belyavskiy-rfc5933-bis
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Jul 2020 02:17:18 -0000

On Jul 6, 2020, at 6:07 PM, Tim Wicinski <tjw.ietf@gmail.com> wrote:
> 
> 
> All
> 
> I've been going over the CfA comments, and discussing this with my chairs and Warren, and 
> perhaps the best way to walk through the logic in our decision is to work backwards.
> 
> 
> The authors are requesting a code point for their algorithm in this IANA registry:
> 
> https://www.iana.org/assignments/ds-rr-types/ds-rr-types.xhtml#ds-rr-types-1
> 
> To receive such a code point a "Standards Action", which is defined as:
> 
>     For the Standards Action policy, values are assigned only through
>     Standards Track or Best Current Practice RFCs in the IETF Stream.
> 
> Which means that 1) Informational will not work; and 2) Independent Stream will not work.
> 
> In the excellent discussion on this, what seems to be the underlying consensus is 
> the need to publish the document to establish the code point, and document it as such.

So far, so good.

> 
> To not adopt this means, the implementers could easily pick their own 

This seems unlikely. If they step on unallocated code points, few implementers will go along with that because implementers generally respect the IETF and IANA more than they respect a country's crypto regime.

If we fix the registries in question to not require standards-track RFCs, then we don't need to adopt this document: the authors could publish them through the ISE.

> There was also discussion on updating the table in https://tools.ietf.org/html/rfc8624#page-5 [tools.ietf.org]
> (implementation recommendations for DNSKEY algorithms), and here seemed to be some consensus around MAY

Yes, great.

> There was also an orthogonal discussion around changing the registry from "Standards Action"
> to "RFC Required".  

That was not orthogonal at all. It was directly intended to allow the WG to not adopt this document and yet allow the authors to get what they want, which are IANA code point allocations that implementers can then find the relevant documents for.

It feels weird for the DNSOP WG to recommend to the IETF that it publish a standards-track document that virtually no one in the WG understands. The DNSOP WG could use the same pattern as other IETF WGs (TLS, SMIME, IPsec, ...) for the past 25+ years.

And, before anyone says "but we'll run out of code points!", please take a look at how small the registries are for those other crypto protocols. There are a handful of countries with their own crypto, but the number is surprisingly low.

> While this seems to be a simple procedural move, I fear that doing
> so haphazardly without understanding the operational considerations is completely 
> wrong (Remember, We are DNS OPerations)

I'm not seeing how following what the other WGs have been doing for decades as "haphazard".

> Mr. Wouters made the very correct comment that "no one outside the IETF really knows the difference for RFCs anyway."
> This was something I was reminded of all too well during the DNS RPZ discussions. 

This document is not for people outside the IETF: it's for implementers. They do indeed consider standards-track RFCs different than informational RFCs. That is why we had to create RFC 8624.

> Summary:  Adopt as Standards Track because we have to add text to the state as such.  We will not spend a lot
> of WG time on this document, and Warren and I will end up doing the heavy lifting on all the process portions.

That feels exactly wrong. "We didn't really read this draft, but we want you to make it an IETF standard". My counter-proposal was "we made it easier for folks with national algorithms to get their code points without having to deal with the WG process".

--Paul Hoffman