> On 18 Dec 2018, at 17:19, Paul Wouters <p...@nohats.ca> wrote: > > On Tue, 18 Dec 2018, paul.kon...@dell.com wrote: > >>> Well, I think it's a bit too complex for random implementer. >>> I'd prefer to classify all algorithms as follows: >>> >>> 1. Secure, required for interoperability >>> 2. Secure, not required for interoperability >>> 3. Insecure (obsoleted) > >> Possibly some algorithms are candidates for "obsolete" status not because >> they are known to be insecure but because they never got traction or >> security analysis. I'm not sure if CAST is an example. >> >> On terminology: "secure" is too strong a statement for the non-expert >> audience. "Believed to be secure" would be more prudent, but I don't really >> like those words either. Can we come up with some words that don't suggest >> a guarantee we can't make? > > When I described the various SHOULD, MAY, MUST and their variants, I was > not suggesting of putting that into the IANA registry. The IANA registry > should only get "deprecated" or "obsolete". In my view (and I think the > RFCs view) deprecrated means "issues found, stop using it" and > "obsolete" means "meh, not harmful but no one else is using it anymore”.
I think it’s best to copy what TLS is doing and just add a “Recommended” column with a y/n value to all the algorithm lists. A prudent administrator enables the algorithms marked “Recommended” and none of the others. An administrator that enables other algorithms will have to explain why he or she did that when things go wrong. TLS did write a document to change the IANA registries like that. Yoav _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
