IETF Logo Mail Archive

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

Paul Wouters <paul@nohats.ca> Tue, 21 July 2020 01:09 UTC

Return-Path: <paul@nohats.ca>
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 8E8453A12DB for <dnsop@ietfa.amsl.com>; Mon, 20 Jul 2020 18:09:41 -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, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 XGp91VBJzfMx for <dnsop@ietfa.amsl.com>; Mon, 20 Jul 2020 18:09:39 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C90983A12E0 for <dnsop@ietf.org>; Mon, 20 Jul 2020 18:09:30 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4B9gVJ4pvnzFMV; Tue, 21 Jul 2020 03:09:28 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1595293768; bh=6yXj5F3W21mzhUyEecvHCk24lfnRTsYfwE6zmsu3bNw=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=KGCp+lv8dDaPmtVm3gJ9AGifFAOca0WviRt7k/tOwxmzTULXguUzXl25a7gXB/9zt xl5A+KhAG/nnKe1dLvVnLf1qqU92+J5dRRQrJtcjlzWUc+3o5t6RV5HPOAUnFw9Rg7 aEgaxbc80Bcv6suV2IDg7pLUOUtDyG9AMEH+l7JY=
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 KrZbAlNOOhW5; Tue, 21 Jul 2020 03:09:27 +0200 (CEST)
Received: from bofh.nohats.ca (unknown [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; Tue, 21 Jul 2020 03:09:27 +0200 (CEST)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id A305F6029BA4; Mon, 20 Jul 2020 21:09:26 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id A1DE8669F1; Mon, 20 Jul 2020 21:09:26 -0400 (EDT)
Date: Mon, 20 Jul 2020 21:09:26 -0400
From: Paul Wouters <paul@nohats.ca>
To: Paul Vixie <paul@redbarn.org>
cc: dnsop@ietf.org
In-Reply-To: <2753503.1rNK4gVDxN@linux-9daj>
Message-ID: <alpine.LRH.2.23.451.2007202106390.155773@bofh.nohats.ca>
References: <C2C9BDB4-AA7B-47B8-8735-2A529B37B4BA@icann.org> <DA0E1657-D590-4FF1-8E2E-7944F33E7395@rfc1035.com> <32CEC795-45F3-48C7-BD42-DCCFE0454B7A@isc.org> <2753503.1rNK4gVDxN@linux-9daj>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/gY7HwdXAnHsvQdVK1rPhjikcNmk>
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, 21 Jul 2020 01:09:48 -0000

On Sun, 19 Jul 2020, Paul Vixie wrote:

> On Sunday, 19 July 2020 07:52:39 UTC Ondřej Surý wrote:
>> I just want to point out, that I am certainly not overthinking this with my
>> implementors hat. The RFC and code-point puts pressure on the DNS vendors
>> to actually implement this „because there’s RFC“. ...

If we are talking about Nation State ciphers, the pressure is on them to
submit code to get it supported. Whether it is in openssl or bind or
what not.

> i'm going to want to be able to validate signatures generated in russia by 
> russians of russian dns zones. so my pressure on my implementors will not be 
> because there's an RFC, but rather, because there are keys and signatures.

> the thing we live on is round.

Indeed. As much as I also want to limit the number of algorithms because
most Nation States ones will never see real deployment, we cannot really
prevent them from trying to get a real deployment.

If someone from Europe or North America would come up with another
algorithm, I'd be more tempted to say no than if Russia or China
would come to ask for one.

Paul

v2.23.0 | Report a Bug | By Email