IETF Logo Mail Archive

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

Paul Hoffman <paul.hoffman@icann.org> Tue, 07 July 2020 14:15 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 1AE713A0CFD for <dnsop@ietfa.amsl.com>; Tue, 7 Jul 2020 07:15:20 -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 bKBF0-QnQmwm for <dnsop@ietfa.amsl.com>; Tue, 7 Jul 2020 07:15:18 -0700 (PDT)
Received: from ppa2.lax.icann.org (ppa2.lax.icann.org [192.0.33.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 CF3F23A0D4C for <dnsop@ietf.org>; Tue, 7 Jul 2020 07:14:39 -0700 (PDT)
Received: from PFE112-CA-1.pexch112.icann.org (out.west.pexch112.icann.org [64.78.40.7]) by ppa2.lax.icann.org (8.16.0.42/8.16.0.42) with ESMTPS id 067EEbwt027614 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 7 Jul 2020 14:14:38 GMT
Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 7 Jul 2020 07:14:36 -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; Tue, 7 Jul 2020 07:14:35 -0700
From: Paul Hoffman <paul.hoffman@icann.org>
To: Töma Gavrichenkov <ximaera@gmail.com>
CC: Tim Wicinski <tjw.ietf@gmail.com>, dnsop <dnsop@ietf.org>
Thread-Topic: [DNSOP] [Ext] Call for Adoption: draft-belyavskiy-rfc5933-bis
Thread-Index: AQHWRYEcUoh5DWNcfECeWUoumkosw6je9SkAgADXJICAAL1IgIAADZmAgAAMjQCAABJVgIAC7xuAgABS0ICABG52doATefQAgAATYICAAJx0gIAAK/+A
Date: Tue, 07 Jul 2020 14:14:35 +0000
Message-ID: <74F19840-7F5D-46EB-B664-79E5C55A1E96@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> <E4D1903A-47AD-4E18-BF1F-D491F6B63174@icann.org> <CALZ3u+b4W5XUv6wT6kUO39fzTJbAB39YZmm+yiu3Gmp=Vf=Adw@mail.gmail.com>
In-Reply-To: <CALZ3u+b4W5XUv6wT6kUO39fzTJbAB39YZmm+yiu3Gmp=Vf=Adw@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=_66883496-4E90-4301-A416-5DE074C25E97"; 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_08:2020-07-07, 2020-07-07 signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/UwxqzgHnzFEmDBxEs7iO_I082RQ>
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 14:15:20 -0000

On Jul 7, 2020, at 4:37 AM, Töma Gavrichenkov <ximaera@gmail.com> wrote:
> 
> Peace,
> 
> On Tue, Jul 7, 2020, 5:17 AM Paul Hoffman <paul.hoffman@icann.org> wrote:
> On Jul 6, 2020, at 6:07 PM, Tim Wicinski <tjw.ietf@gmail.com> wrote:
>> > 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.
> 
> That's only correct when said implementers have a choice.  With no allocated points going to be available in the future, a hijack would be the only viable option.
> 
> Also, we have stepped on that rake before.  You don't need a lot of implementers going nuts to destroy interoperability.  You only need *one* who would be successful in that s/he is doing.
> 
> Let's face it, there's not gonna be hundreds of DNSSEC GOST implementations anyway, I think maybe 3 or 4 would finally be born, and one of those would likely win the competition and become a standard de-facto.  See, without the code point allocation it's a pure gamble on whether we'll get interop issues in the future or not.

Fair points. Still, a crypto developer who only had to go through the ISE instead of the WG->IETF process should still be happier because they get their point faster.

And, as Ekr pointed out early, making all of these registries be just "Expert review" would be even faster.

--Paul Hoffman

v2.23.0 | Report a Bug | By Email