It isn't the count of algorithms, it's the size of the algorithm field that is the issue (8 bits) though we could hack in a extension. We can invent lots of algorithms but we really need to have a good justifation to add it to the table. Why is this algorithm *significantly* better than all of the existing algorithms.
Mark In message <20150909192945.gl21...@mournblade.imrryr.org>, Viktor Dukhovni writ es: > On Wed, Sep 09, 2015 at 08:12:41PM +0200, Ondej Sur wrote: > > > Yes, we are waiting exactly for the cfrg to finish the signature > schemas. > > But the rest can get a review early. f.e. it's evident now, we have to > > add more material about motivation to add new curves into the draft(s). > > Great. My other concern is that at this point, perhaps every time > we consider adding more algorithm ids to DNSSEC we should consider > retiring some old ones, we are starting to have too many: > > Id Description Mnemonic ZSIG TSIG Reference > > ------------------------------------------------------------------------- > 1 RSA/MD5 (deprecated) RSAMD5 N Y RFC3110RFC4034 > 2 Diffie-Hellman DH N Y RFC2539 > 4 Reserved RFC6725 > 9 Reserved RFC6725 > 11 Reserved RFC6725 > -- > 3 DSA/SHA1 DSA Y Y RFC3755 > 5 RSA/SHA-1 RSASHA1 Y Y RFC3110RFC4034 > 6 DSA-NSEC3-SHA1 DSA-NSEC3-SHA1 Y Y RFC5155 > 7 RSASHA1-NSEC3-SHA1 RSASHA1-NSEC3-SHA1 Y Y RFC5155 > 8 RSA/SHA-256 RSASHA256 Y * RFC5702 > 10 RSA/SHA-512 RSASHA512 Y * RFC5702 > 12 GOST R 34.10-2001 ECC-GOST Y * RFC5933 > 13 P-256 with SHA-256 ECDSAP256SHA256 Y * RFC6605 > 14 P-384 with SHA-384 ECDSAP384SHA384 Y * RFC6605 > > I'd like to propose that with the introduction of the CFRG algorithms, > we should deprecate: > > 3 DSA/SHA1 DSA Y Y RFC3755 > 6 DSA-NSEC3-SHA1 DSA-NSEC3-SHA1 Y Y RFC5155 > 12 GOST R 34.10-2001 ECC-GOST Y * RFC5933 > > and as ideally also announce a sunset date for: > > 5 RSA/SHA-1 RSASHA1 Y Y RFC3110RFC4034 > 7 RSASHA1-NSEC3-SHA1 RSASHA1-NSEC3-SHA1 Y Y RFC5155 > > though of course these are rather widely used at present, it is > time to start encouraging folks to move on. > > Once the CFRG algorithms are done, I would also publish an updated > list of MTI algorithms for DNSSEC that would consist of: > > 8, 12 and both of the CFRG algorithms. > > The more secure of the two CFRG algorithms should be supported by > clients, but should not yet be used by servers, concerns about > post-QC crypto don't really apply to short-term signatures, we can > switch to the Goldilocks curve if/when necessary, provided the > client support is there all along. > > -- > Viktor. > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
