Re: [DNSOP] Fwd: Working Group Last Call for draft-ietf-dnsop-rfc5933-bis
Michael StJohns <msj@nthpermutation.com> Tue, 01 February 2022 23:04 UTC
Return-Path: <msj@nthpermutation.com>
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 822C63A14BF for <dnsop@ietfa.amsl.com>; Tue, 1 Feb 2022 15:04:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level:
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.714, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 vBixXQrv-jk0 for <dnsop@ietfa.amsl.com>; Tue, 1 Feb 2022 15:04:07 -0800 (PST)
Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) (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 9C5DD3A14D1 for <dnsop@ietf.org>; Tue, 1 Feb 2022 15:04:07 -0800 (PST)
Received: by mail-qk1-x731.google.com with SMTP id o12so16613307qke.5 for <dnsop@ietf.org>; Tue, 01 Feb 2022 15:04:07 -0800 (PST)
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; bh=fH4y25iIwz3IVv5l+q63PaertipctSekUu8xHCdBc/A=; b=19ztMeeMI0XdgDeVVo/lDzNP6rLOKm6dd6UcUNVk4SYN80ieypI5jmWmJ/+Axmpxtq yaSojTlMTjDy0yr3qvFVfhRCKaZVDt6tjroFNUxBpmqGmfaRO1sEAUmZnHTAJcvm6Are kQmTKXAUxhxJrVmoSXKd72sS+aKtOSXDolbbo5uaOWbt8hNKvaJyiZoCw25zFwCajqhZ GjCGXw1QBQLwI8f3fGrV9FTmFhRbmunJ5QWFBdEuVKelP0VV69Hn7QyIrzplZfEMi1a7 rLsmASzhuYvIorT6vKDs1+9jDlRL/r0HpFSahXT/wdp8r57pwK0YukytQuMD7bLc2J3Q T/gA==
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; bh=fH4y25iIwz3IVv5l+q63PaertipctSekUu8xHCdBc/A=; b=l+qYWGDvKH3dAUUFgGBlwxwtZ5hYhwL5PiwH4CeHQJI1xLyuePy6+Ykr8BZh7SvZ5v J01on0irRO7pmGOMiSkr9u2+YfxyaqcMihOo2OQ8ZKHfY9a4GbgyRvrkDrPYBvIPdlDO E1DJ9/edmZJEBhP9FZPXt4sAol6GdrJVpY45CDPzmVCYnogSzKNTE3ZCpCzpYksKEQ7y jvybkNGoFNCL7kAYppq0Ssbos4aWwSPsfWKzBP5Gw89/xUJ/7gaKxi1APb58s6RnAOZM QragQ+85rMuO0YYYhBurBxgRYpLRO+V1tzL2uJJ7chStKWR50A/wL2InUcBxT8Ocgl/Q QDqg==
X-Gm-Message-State: AOAM531E39ouInomvXyC/DxUD8feY1nKFMeTDCINVFNgANbS6TjaDQi9 enyMeH+7pGaeBaWl6wDmpRS61EipMNLMlu9W5OM=
X-Google-Smtp-Source: ABdhPJyMG5fuJCg4ae/q4JyaiW0w/W9WxQfdmr9VuzNYWXF/Ti1JGLFNpFCNjUe5gfPKlCwcREF2dw==
X-Received: by 2002:a37:bf83:: with SMTP id p125mr18701159qkf.382.1643756645136; Tue, 01 Feb 2022 15:04:05 -0800 (PST)
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 c127sm10925865qkf.36.2022.02.01.15.04.04 for <dnsop@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 01 Feb 2022 15:04:04 -0800 (PST)
Content-Type: multipart/alternative; boundary="------------QO08d0bW5y9c0Hcf0HdyIAzQ"
Message-ID: <99e260b2-04fb-d0cb-1410-37b7d9f42c42@nthpermutation.com>
Date: Tue, 01 Feb 2022 18:04:03 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0
Content-Language: en-US
To: dnsop@ietf.org
References: <CADyWQ+Fch-C8LPCEHkouRxCnkMcpMeh7bmQRPTXRwodx01xWNw@mail.gmail.com> <CADyWQ+F-oop9Cvo7nNF-O86vvJhNVrNs2AdBytnith3+JzGCdQ@mail.gmail.com>
From: Michael StJohns <msj@nthpermutation.com>
In-Reply-To: <CADyWQ+F-oop9Cvo7nNF-O86vvJhNVrNs2AdBytnith3+JzGCdQ@mail.gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/YmejkVEwLynXQJB8nBd_IVsjM2M>
Subject: Re: [DNSOP] 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 <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, 01 Feb 2022 23:04:12 -0000
On 2/1/2022 3:35 PM, Tim Wicinski wrote: > All > > 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. > > Thanks > > tim > Hi Tim - Since you ask, I don't think it's ready to go forward. Section 2 is particularly opaque. Section 2.1 - Provide the ASN1 that explains what's going on by adding the prefix to a 64 byte GOST public key. Ideally identify the various OIDs that match to the key format, and to the signature format. Section 2.2 - How does the private key in the first part of the example get you to the public key in the second? The Base 64 in the DNSKEY appears to give you this value: 5E 46 7A 4F EA 90 F6 D7 8E 32 C0 3F 60 AF A4 4F 31 0B 86 E3 0F 4E C6 20 81 DC B6 6F EB 1F CC 9E AD 1F D7 A7 8B 38 8C 5F 78 23 32 75 19 23 2A E7 48 87 21 2E 3B A9 F3 1A 72 F9 45 39 97 51 32 8F Which appears to be an unparameterized GOST public key which I assume matches the private key. That may be a valid key or not, but saying that explicitly would be useful. Or at least "The following DNSKEY RR contains the encoded GOST public key paired with this private key - see xxx for the key pair generation logic" To fix all this, start from a normal (PEM or PKCS8 or PKCS12 or X509) representation of an example key pair and work from there to map to/form DNSKEY, DS and RRSIG records. The algorithm number is specified as 23 here and other places, and that's so that the examples could be calculated, but if the IANA doesn't issue them 23 as the number (and they probably won't) most of the examples will have to be redone with the final values. This is a cart/horse problem and I'd recommend that the IANA do an early assignment of the signature and digest algorithm values and that the document be redone with the final values prior to IESG submission to prevent a round trip during RFC publication. Sections 3.1 and 4.1 - show your work. Show the actual data being hashed or signed so that someone else coming along can verify that a) you did the encoding properly, and b) the hashes match or the signatures match. This is especially important with algorithms which lack broad international implementation. Section 5 - these should refer to the GOST specification (e.g. "MUST be 512 bits per [GOSTxxx]"). As stated, this could be something peculiar to this spec rather than the underlying cryptographic primitive. Section 6.1 - huh? In any case, we generally don't have single subheader sections - move the text up. I think this is supposed to be "The support of this cryptographic suite in DNSSEC-aware systems is OPTIONAL. Systems that do not support these algorithms may ignore the RRSIG, DNSKEY and DS records created with them." Section 10: " I hope this helps - Mike > > ---------- Forwarded message --------- > > All > > With draft-ietf-dnsop-dnssec-iana-cons now in AUTH48 state, it's time > to move this document along as well. > > This starts a Working Group Last Call for draft-ietf-dnsop-rfc5933-bis, > "Use of GOST 2012 Signature Algorithms in DNSKEY and RRSIG Resource > Records for DNSSEC" > > Current versions of the draft is available here: > https://www.ietf.org/archive/id/draft-ietf-dnsop-rfc5933-bis-07.html > > The Current Intended Status of this document is: Informational > > 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. > > Because of the American holiday, we're going to run the last call > process a few days long. This Working Group Last Call will end on: > 10 December 2021 > > thanks > tim > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop
- [DNSOP] Working Group Last Call for draft-ietf-dn… Tim Wicinski
- [DNSOP] Fwd: Working Group Last Call for draft-ie… Tim Wicinski
- Re: [DNSOP] Fwd: Working Group Last Call for draf… Michael StJohns
- Re: [DNSOP] Working Group Last Call for draft-iet… Russ Housley
- Re: [DNSOP] [Ext] Fwd: Working Group Last Call fo… Paul Hoffman
- Re: [DNSOP] [Ext] Fwd: Working Group Last Call fo… Paul Wouters
- Re: [DNSOP] [Ext] Fwd: Working Group Last Call fo… Michael StJohns
- Re: [DNSOP] [Ext] Fwd: Working Group Last Call fo… Ondřej Surý
- Re: [DNSOP] Fwd: Working Group Last Call for draf… Dmitry Belyavsky
- Re: [DNSOP] Fwd: Working Group Last Call for draf… Michael StJohns
- Re: [DNSOP] Fwd: Working Group Last Call for draf… Paul Wouters