On 09/13/2018 02:13 PM, Jakob Bohm wrote:
On 13/09/2018 09:57, Klaus Keppler wrote:
Hi,
thank you for all your responses.
I've just tested with Firefox Nightly 64.0a1, and both s_server and our
own app (using OpenSSL 1.1.1-release) are working fine.
The Firefox website is quite confusing:
Firefox 61 is already shipping draft-28, which is essentially the
same as the final published version (just with a different version
number).
(https://blog.mozilla.org/security/2018/08/13/tls-1-3-published-in-firefox-today/)
This is quite confusing, as it sounds better than it actually is.
(so I've just learned that draft-28 is obviously incompatible with
RFC8446)
So thank you for your input, will now continue with OpenSSL 1.1.1.
The rest will be only a matter of time. :D
Best regards
-Klaus
Would it be reasonable for 1.1.1a to add a transitional "bugs" bit (to be
removed again in a few years) to accept the draft version number of final
TLS 1.3, if the protocols are otherwise identical?
What would the benefit be? Allow support for older browsers? I think
that TLSv1.3 support exists fine in Firefox now and ver 61 is not an ESR
release at all. I am not sure what the benefit would be. Draft 28 is
much like Draft X for any X less than 28.
This would be similar to the (now historic) bits for known bugs in other
popular clients. It also seems to be what Facebook has done for their
own servers (according to other posts in this discussion).
Or would it be unproblematic from a real world perspective to just keep
TLS 1.3 non-functional for draft-28 browsers?
Given that the protocol is published and the browser support exists for
the real protocol then there can not be a raeason to support Draft X.
Dennis
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
