On Mon, 4 Jan 2021, Stephen Farrell wrote:
WRT GOST, we're not really talking about an algorithm but
rather a national crypto standards scheme that selects sets
of algorithms. For such things, whether from Russia or the
US or anywhere, I think it's quite fair to ask "how has
version N deployment gone?"
Why is that fair?
Eh? Seems to me that asking about the facts is fair.
I have a hard time envisaging a way it could be unfair
tbh, so your question surprises me.
While asking is fair, you would also have to define what you
do based on the outcome of that ask. You left that out, so
at best I can interpret is that you would partially base any
IETF decision about algorithm N+1 on results of algorithm N.
I'd say the community was quite busy and
possibly made some mistakes in the past. I don't think that
is a valid barrier for the future. For example, would we
bar NIST or the US from ever standarizing a new RNG? :P
You seem to be assuming that the goal of asking is to
justify saying "no." That wasn't my intent - I just think
we make better decisions if we know the deployment facts,
rather than our decisions being based on whomever is
good at rhetoric or automatically giving nation-states
or mega-companies whatever they ask.
But that brings us back to the original issue, what are the requirements
for getting an allocation? If it is "with IETF approval that includes
a history of your previous work", then that is pretty close to IETF
doing a full evaluation, AKA the path of Standards Track. This again
puts the IETF in the middle of nation state crypto politics. We should
not want that. Now if you said nation states get at most one allocation
per 5 years or something equally neutral and measurable, then I might
agree. But in that case, I think Tim's solution is a better one that
accomplishes the same - give out a chunk of numbers, but hold on to a
bunch for true international / IETF usage.
WRT a new RNG - yes if one was suggested from a US or
any source, then we absolutely should be very careful with
that. Mind you, I can't think of an iana registry that
has RNG algs as entries so maybe it's not a super-good
example.
But you understand why I use it as example. It would be the
equivalent of asking the USG/NSA/NIST about their "algorithm N"
as part of considering "algorithm N+1". For example, IETF
declaring SHA3 a "nation state algorithm". (the tricky
thing here is that the US seems grandfathered in as a non
nation state entity on those occasions when it is)
If a national government wants something, we could ask for
at least one implementation to be planned.
That was not what I suggested asking. I'd just like to know
if or how much the current gost stuff gets used with dnssec.
What is the relevance of this, if not to take it into account
of the decision making process of N+1 ?
Should the failure of adoption of RSAMD5 in DNSSEC have been used
to evaluate RSASHA256 ? The early code points in DNSSEC suffered
from the general lack of DNSSEC deployment at the time. I'm sure
that is as valid for RSAMD5 as it was for GOST. The lack of
these deployments where unrelated to the algorithm.
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.
But on the other side, if would be nice if we could become
faster with obsoleting algorithms too. Why is there still
RSASHA1 deployed....
Yep. Allocating codepoints for things that don't get used (if
that is the case with gost algs and dnssec which I *still*
don't know any more about), doesn't help us move on from
things that did get used.
This is where we fundamentally disagree. If a government asks for a
codepoint, they don't do it so it does not get used. Clearly,
the intent is that it will be used. Whether that will be true
in the future might be hard to say for either the requester
of the code point or for the IETF. This is very different from
say me as an individual asking for a (likely vanity / unwise)
code point.
Paul
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
