On Sun, Mar 20, 2016 at 2:55 PM, Paul Hoffman <paul.hoff...@vpnc.org> wrote:
> On 20 Mar 2016, at 10:55, Ólafur Guðmundsson wrote: > > On Sat, Mar 19, 2016 at 4:04 PM, Paul Hoffman <paul.hoff...@vpnc.org> >> wrote: >> >> [[ Dropping CURDLE because these discussions should only be in one WG ]] >>> >>> ECDSAP256SHA256 and ECDSAP384SHA384 provide more strength for >>> signature size than RSASHA256 and RSASHA512 variants. It is expected >>> to be raised to MUST once they have been deployed more widely for >>> DNSSEC Signing. ECDSAP256SHA256 has seen raise in the deployment, so >>> it's set to MUST level for DNSSEC Validation. >>> >>> Even though I was a strong proponent of ECDSA, I think this is the wrong >>> move. ECDSA has had many years to garner interest, and it hasn't. Within >>> a >>> year, we will have EDDSA in DNSSEC, and the operational crypto properties >>> of EDDSA are noticeably better than those of ECDSA. It would be much >>> better >>> if the community just standardized on EDDSA instead of a mixture of the >>> two >>> algorithms. Proposal: drop them from this document. They will remain in >>> the >>> IANA registry, of course. >>> >>> --Paul Hoffman >>> >>> Paul for the record >>> >> There are tens of thousands of domains signed with ECDSAP256SHA256 world >> wide. >> ECDSA is currently the only viable algorithm for anyone that wants to do >> OnLine signing in low latency environments. >> > > 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 no other alternative will be useful for many years, so our choice was signing pain or deployment pain. We picked the deployment pain due to size and signature strength factors. 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 know that was not what you wanted to say. 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. > There are significant issues related to deploying a new DNSSEC algorithm >> world wide, most related to stuff actual operating environments. >> > > Sure. > > > My current >> best guess is that it takes about 5-10years after IETF standardizes new >> algorithm, before the algorithm is globally "useful". >> > > And yet you chose to deploy sooner: See above, and I did not know at the beginning how hard it is to move the ecosystem, so consider this a service to future vanity algorithms. > > We are still inside >> the 5 year window, working out the issues in deploying new algorithms with >> ECDSA can only help the algorithms that will follow. >> > > 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. If it is faster that might be an advantage. > > I see no evidence of use of ECDSAP384SHA384 except in test setups, so I >> have no problem not mentioning that algorithm in the document. >> > > The 256/384 issue is a separate one, but one worth discussing. FWIW, I > agree that mentioning it, maybe even suggesting against its use, would be > good. For the record I never wanted ECDSAP384SHA384 defined, will support having it obsoleted. Fewer algorithms are better for DNSSEC. Olafur
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
