First, I think that we must recognize that the *IETF* does not have the same
sectoral powers that 3GPP has. It is entirely appropriate what 3GPP
did, and they seem to have learned the lessons they needed.
John Mattsson <john.mattsson=40ericsson....@dmarc.ietf.org> wrote:
> How can IETF be more pro-active regarding deprecations in the future?
> In the best of words, nobody should be surprised when IETF deprecates a
> protocol version or algorithm. NIST and similar organizations in other
> countries have the practice to long time in advance publish deadlines
> for security levels, algorithms, and protocol versions. Can the IETF do
> something similar, not just for TLS but in general? For TLS, there are
> several things to deprecate, in addition to MD5 and SHA-1, also
> PKCS1-v1_5, RSA-2048, 224-bit ECC, ffdhe2048, and non-recommended
> cipher suites (Static RSA, CBC, DH, NULL, etc.) should be deprecated in
> the future.
I think that we can more easily deprecate these individual ciphers and cipher
suites than we can entire TLS version numbers.
The mere fact that we had to "hide" the TLS 1.3 version in the header the way
that did speaks volumes to the problems in what I'll call the "secondary"
security industry. There are significant incentives from enterprises to
have companies come to "patch up" their broken systems. If we want
enteprises to move faster, and move with us, then we will have to spend more
time addressing the issues that they have. We may not like their problems,
we may even strongly disagree, but we have to keep them in the tent.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | IoT architect [
] m...@sandelman.ca http://www.sandelman.ca/ | ruby on rails [
signature.asc
Description: PGP signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
