On 20 Mar 2016, at 12:34, Ólafur Guðmundsson wrote:
Yes, but that doesn't change what I said. Most of those domains are
signed by one entity who can change easily if the operational market
thinks that is a good idea.
Right now there are two options for on-line signers GOST-ECC and
ECDSAP256SHA256
Correct. Later this year there will be a third. Nothing in this thread
suggests otherwise.
no other alternative will be useful for many years, so our choice was
signing pain or deployment pain.
Can you say how you predict "many years"? The rollout of ECDSA in code
was pretty fast. If EDDSA is rolled into the same resolver software, and
if those resolvers do an update (as it appears many do), then it will be
as useful as ECDSA.
We picked the deployment pain due to size and signature strength
factors.
Correct. You will get exactly the same for EDDSA, and have better
operational security properties.
Your statement can be read to mean that ECC should not be used because
ECDSA has no advantages over
RSA with 1024 bit keys,
I can't see how, but you seem to see things differently.
I know that was not what you wanted to say.
Then why did you bring it up? It goes against everything that I have
said in standards-track documents for over a decade, particularly in RFC
3766.
There are at least 2 other parties that I'm aware that are working on
their
own online signing systems using the same
algorithm as we are.
This is good to hear. Do you believe that they (or you) would not be
able to change algorithms if you use software that includes it?
Right, particularly because EDDSA has notable *operational*
advantages
over ECDSA.
define operational!!!
From my point operational is all about the running systems, and how
data
gets into those systems.
I fail to see how crypto advantages help that.
Quoting from the document that we are discussing in this thread:
It does not require the use of a unique random number for each
signature, there are no padding or truncation issues as with ECDSA,
and it is more resilient to side-channel attacks.
Both of those advantages help operators keep their private keys secret.
Most operators would find that useful.
If it is faster that might
be an advantage.
EDDSA might be a bit faster, but that is not nearly as significant as
the other features.
For the record I never wanted ECDSAP384SHA384 defined, will support
having
it obsoleted.
Fewer algorithms are better for DNSSEC.
Fully agree here.
Again, what I proposed would not prevent or discourage anyone from
signing with ECDSA if they wanted to: it would simply not encourage it.
--Paul Hoffman
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
