ecause "if it was so insecure, they wouldn't have included it
in the protocol in the first place." Unless 0-RTT can be fixed, it
looks like an attractive nuisance.
Let's leave it out.
--
Scott Schmit
smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
rly easy to translate to "the new version of TLS is going to really
improve things".
The distinction between 2 vs 2.0 seems pretty minor. SSLv2 is 2.0 and
SSLv3 is 3.0, but few write it that way.
Thus my ranked preference would be:
TLS 2017 > TLS 4 > TLS 1.3 > TLS 2 or TLS 2.0
ange at any time." Anyone doing otherwise is arguably as confused as
those who don't even know what TLS is. And there are a lot more of the
latter than the former.
But no, I would not support calling the next TLS version "SSL 4/2017" -- the
harm of invalidating the
SSL versions as to be confused with them.
And the shift in versioning strategy is so typical it would probably not
even draw serious notice.
--
Scott Schmit
smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
ecurity by one iota.
If we add an alert to be sent in this case, it would be possible for the
server to know why the clients were disconnecting and resolve the issue.
--
Scott Schmit
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
