Re: [DNSOP] [Ext] Call for Adoption: draft-hoffman-dnssec-iana-cons

Василий Долматов <> Tue, 05 January 2021 08:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E01A63A0ED1 for <>; Tue, 5 Jan 2021 00:24:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 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, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tkTCnBd96_Vr for <>; Tue, 5 Jan 2021 00:23:59 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::134]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 147F03A0EDA for <>; Tue, 5 Jan 2021 00:23:59 -0800 (PST)
Received: by with SMTP id x20so70628841lfe.12 for <>; Tue, 05 Jan 2021 00:23:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=RsoxEy3LpBaLwPs3htDVpSVjKWmPBTut2EVzK6+0Mv4=; b=skwx++FR5jGMscjF0XIi3I3E3N4wko/qWxxz7H6N3mYe6BBr2P1JM0fYXq3Y55ogrT o0bkXPmRmC6xbQbHvZn8upNOk/R2ESFL9z9qNvDb/r3zIQpSWmS7dhU0al7kKfhjobP+ +nIam50+hvYutgNJFRTLZ3yvz6EsP33GeBNzQWQFPARFBH2UZ9CHro7jCFVE1YssEL6O 492SvXBUexljTjMmSl9QN17Bk/OiHtCL/hp4FKXbNf4nRRwhK/sgAjoGbFIImisftCQ7 RKlnDg+Bbk/ICRCQQdVkm21EuQ6Dvayyhvm7PupKsWMQJYknlgeeDcOM7NDVS2v4SLIl 3bvA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=RsoxEy3LpBaLwPs3htDVpSVjKWmPBTut2EVzK6+0Mv4=; b=as9f6LvSBJ7YDCnU7i3sjL1cAl4xpZlYHjloLnNT+TrN4iPIXIaRlAGm2CP/qLxctD EoDC5oh37MZ5NyIuwn92GF5B3SzRyp/wfflYp9QvWiif2ePU51JnQXLLWh+ufDdvTHJJ YQpDVF0ypjoaYLCyfdZSQ79MsgLd/CKlENjAMJ4CENtRZazcLWhkhpCRdgNeV0jS6rCF 4uxFY8nnUNneX1j/p7CJMIV+679gYfkmkUU66JKGGZm0doHmTlpffqgcpzU+E2B6sPaY L469b7W752AB2QvL9YPTcVK0PDdG8/SuYrzbjJ5a9wEvXYBJkcVC38WIBL3HE2NvMM1o 5FtA==
X-Gm-Message-State: AOAM532N0cPUib7xJ+gg1uXUXASI4r9pq2L0Lsxbku1XDpCTe81N97dn r2lSMcXQnPTZIH10/UQGr5g=
X-Google-Smtp-Source: ABdhPJyaRJ+AV/i+thC4lJIrryNesoMbdcQs9hsTaCy/FAOMwhXPlSQAVlLEYHf3YCyUMhR5YUXotg==
X-Received: by 2002:a05:6512:6c6:: with SMTP id u6mr31765906lff.174.1609835037142; Tue, 05 Jan 2021 00:23:57 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id m16sm7577823lfb.248.2021. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Jan 2021 00:23:56 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
From: Василий Долматов <>
In-Reply-To: <>
Date: Tue, 05 Jan 2021 11:23:54 +0300
Cc: Paul Wouters <>, Paul Hoffman <>, dnsop <>, Vittorio Bertola <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <>
To: Stephen Farrell <>
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
Subject: Re: [DNSOP] [Ext] Call for Adoption: draft-hoffman-dnssec-iana-cons
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 Jan 2021 08:24:06 -0000

> 4 янв. 2021 г., в 19:20, Stephen Farrell <> написал(а):
> Hiya,
> On 04/01/2021 16:05, Paul Wouters wrote:
>> While asking is fair, you would also have to define what you
>> do based on the outcome of that ask. You left that out,
> I don't think I did omit that. My stated reason to ask was
> to help me figure out what I think about the draft named in
> the subject line. And yes, I do think that if a codepoint
> is being requested for a new version of an existing one
> then asking about how the existing one was used is a good
> thing to do. The case with gost and rsa+sha1/sha256 isn't
> the same because gost is a series of national standards.
> > As to answer your question, I believe GOST did not see
> > more than about 5 domains use it in what was clearly a
> > "Testing" deployment.
> Thanks. In that case, it sounds like it'd have been better
> to use a private or experimental code point for that kind
> of thing. OTOH, my understanding (based only on hallway
> chats over the years) was that the codepoint was allocated
> for political reasons. Either way, does that mean that a
> lot of effort to implement and test was wasted since that
> codepoint was allocated? If so, avoiding that in future
> would be good, if there's a way to do that.
The situation with GOST in DNSSEC is explainable and was explained 
in the list during the discussion of another draft (and to you personally, AFAIR,
maybe you’ve forgotten that).

To the time when RFC5933 was published and corresponding codepoint was allocated
it has been known already that new version of underlying standards for hash and signature were on the way,
so there were no reason to implement it immediately using standards which will be obsoleted soon.

That explains why there  were only several test implementations performed, which were intended to check 
smooth interoperability, if different algorithms were used in DNSSEC validation chain, with even several
algorithms switches along the chain.  The interoperability was proven and results were presented on
one of the RIPE meetings.

Then the DNSSEC deployment in Russia went into «waiting state», waiting for:
 - new standards to be published in Russia
 - reference implementations of it were created  by different software teams with interoperability checks
 - making IETF community aware of them by publishing set of Informational RFC
 - «running code» was created for new standards in open-source software (implementing it in OpenSSL for instance)
 - assigning codepoints in DNSSEC registry

Now we are at the last step in this list, and after its completion we consider that it will become possible to deploy GOST in DNSSEC.

That explains why there is no wide deployment of GOST in DNSSEC until now. We prefer slow-pace but reliable way forward.

Btw, the same way was passed for TLS now, after codepoints for GOST in TLS has been assigned already, we have
several different implementations of TLS with GOST by different software developer teams and we have a stand for TLS interoperability check which is run by the team independent from any of software vendors and performing the check that all
implementations are mutually compatible and aligned with the corresponding RFCs. 
This stand  is used for the interoperability check of IPSEC implementations also and will incorporate DNSSEC in its scope in proper time.

> Cheers,
> S.
> PS: note that I'm neither supporting, nor objecting to,
> Paul's draft in the above.
> <OpenPGP_0x5AB2FAF17B172BEA.asc>_______________________________________________
> DNSOP mailing list