Re: [TLS] WGLC for "Deprecating TLSv1.0 and TLSv1.1"

[[e-mail] (Martin Rex)]

Hubert Kario <[e-mail]> wrote:
> Martin Rex wrote:
>> Hubert Kario <[e-mail]> wrote:
>>> MD5 was deprecated and removed by basically every library
>>> and can't be used in TLS 1.2, I specifically meant SHA1
>> 
>> MD5 deprecated ?  Nope, glaring emtpy:
>>               https://www.rfc-editor.org/errata_search.php?rfc=5246
>> 
>> MD5 removed ? Mostly, but several implementors had to be prodded with
>>               with CVE-2015-7575 (SLOTH) to remove it.
> 
> I meant in practice
> 
>> The real issue at hand is:
>> 
>>   Prohibiting TLSv1.0 and TLSv1.1 is going to result in lots of
>>   interop problems, while at the same time providing *ZERO*
>>   security benefit.
> 
> that's your opinion, not an established fact

You got this backwards.

There is a bold assertion that disabling TLSv1.0 and TLSv1.1 (alone)
would provide security benefits, but a complete lack of proof.
On digitally_signed, is proven that TLSv1.2 as defined by rfc5246
is the weakest of them all.

>> 
>>   What *WOULD* provide *HUGE* benefit, would be to remove the
>>   dangerous "protocol version downgrade dance" from careless applications,
>>   that is the actual problem known as POODLE, because this subverts the
>>   cryptographic procection of the TLS handshake protocol.
>>  
>>   We've known this downgrade dance to be a problem since the discussion
>>   of what became rfc5746.  Prohibiting automatic protoocol version
>>   downgrade dances is going to ensure that two communication peers
>>   that support TLSv1.2 will not negotiate a lower TLS protocol version.
> 
> which exact piece of popular software actually still does that?
> It ain't curl, it ain't Chrome, it ain't Firefox.

It definitely was implemented in Chrome and Firefox, which is how this
poor document got onto standards track:
   
   https://tools.ietf.org/html/rfc7507

 TLS Fallback Signaling Cipher Suite Value (SCSV)
    for Preventing Protocol Downgrade Attacks

>
> It also isn't something done automatically 
> by any TLS implementation that's even remotely popular:
> OpenSSL, NSS, GnuTLS, schannel, Secure Transport, go...

It is impossible to do this transparently, because the a connection
is ususable after a fatal TLS hanshake failure (or unexpected socket closure).

Any application-level cleartext negotiation will have to be repeated
as well, and the TLS implementation typically does not know about it.
(such as HTTP CONNECT or STARTTLS)

The POODLE paper
   https://www.openssl.org/~bodo/ssl-poodle.pdf

asserts that many clients doing downgrade dances exist, and at the
time of publication, this includes Mozilla Firefox, Google Chrome and
Microsoft Internet Explorer.


-Martin