Hi Paul, > > 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) > > > > Regards, > > Valery. > > 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?
I agree that more accurate wording is definitely required here. My point was that we need three states for the algorithms - one indicating that the algorithm is recommended (we believe it is secure and it is recommended choice for interoperability), second indicating that algorithm is known to be broken or having insufficient security, and the third, for all other algorithms without known security issues, but that are not (yet?) recommended for interoperability. Regards, Valery. > paul _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
