Hi,
My 2 cents, I think a kind of overview page with status about
protocols, ciphers an others would helps a lot. Something near of what
is done in https://en.wikipedia.org/wiki/Transport_Layer_Security#Cipher
This would be the page to know to be updated about security
deprecation and planned obsolescence.
If API was available to query this data, it could maybe be used by
tools like : https://www.ssllabs.com/index.html
Regards,
Simon
Le 26/09/2019 à 15:50, Daniel Migault a écrit :
Thanks for raising this discussion John, we have been struggling with
this in curdle as well and ipsecme. This is also a topic that I
believe would be useful to improve the security.
One aspect is that some implementers go to the IANA pages and believe
that everything on the pages is acceptable. I believe that it would be
worth adding some status associated to the code points. Currently, in
most cases a reference is associated to the code point. In some cases,
the reference is the RFC or document creating that created the code
point in other cases, the reference could be the RFC that deprecates
the code point. There is no specific rules, and that is probably
something that would worth being clarified. That being clarified, I
still believe that it could be useful to have a some sort of
indication like a column that indicates whether the code point is
deprecated or not. This may involve additional terminology depending
on the level of information needed.
Another aspect would be to have software automatically checking which
are the code points status. This would of course only solve one side
of the problem as a device may end up on becoming silent, but that is
probably what should occur to non maintained devices.
Yours,
Daniel
On Thu, Sep 26, 2019 at 8:18 AM John Mattsson
<[email protected]
<mailto:[email protected]>> wrote:
Hi,
Hopefully, we have learned some lessons from the TLS 1.0 and TLS
1.1 deprecation. TLS 1.0 and TLS 1.1 are (to cite Martin Thomson)
broken in a myriad subtle ways and should according to me
optimally have been deprecated years ago.
3GPP mandated support of TLS 1.2 in Rel-13 (2015) but could at
that time not forbid use of TLS 1.1 as that would potentially
break interoperability with some Rel-12 nodes (that had TLS 1.2 as
should support). The lesson 3GPP learned from this was the need to
as early as possible mandate support of new protocol versions.
With TLS 1.3, 3GPP took action early and TLS 1.3 support was
mandated for network nodes in Rel-15 (2018) and for mobile phones
in Rel-16 (2019).
At some point in time we will want to deprecate TLS 1.2. To enable
that, TLS 1.3 support should be mandated or encouraged as much as
possible. I would like to avoid a situation where we want to
deprecate TLS 1.2 but realize that it cannot be done because some
implementations only support TLS 1.2. How can IETF enable smoother
and faster deprecations in the future? The browser industry has a
decent track record of algorithm deprecation and I hope to soon
see the following warning in my browser:
“TLS 1.2 is obsolete. Enable TLS 1.3 or later.”
Other industries have less stellar track records of algorithm
deprecation.
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.
Cheers,
John
_______________________________________________
TLS mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tls
