[openssl-users] s_server -www -tls1_3: Firefox/Chrome not working

[Dennis Clarke]

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