[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ietf-tls
Subject:    Re: [TLS] 1.0 or else (was Re: Working Group Last Call for draft-ietf-tls-sslv3-diediedie-00)
From:       Hubert Kario <hkario () redhat ! com>
Date:       2015-01-30 17:15:21
Message-ID: 59280567.z7RHC5U6jC () pintsize ! usersys ! redhat ! com
[Download RAW message or body]

On Thursday 29 January 2015 19:00:33 Martin Rex wrote:
> Martin Thomson wrote:
> > Martin Rex <mrex@sap.com> wrote:
> >> That's not quite true.  There es little, if any stuff outside of the
> >> browser world that could go to > extension-less TLSv1.0, because there
> >> are still too many servers out there that will abort the handshake
> >> when extensions are present or when the version is > TLSv1.0.
> > 
> > Our limited survey thus far has identified only a small number (0.27%)
> > of sites [1][2] that can't handle our TLS 1.2 handshake [3], even
> > though they will tolerate our TLS 1.0 handshake.  In contrast,
> > disabling SSL3 affected more than twice this amount.
> 
> For our TLS client and our customers, the amount of public Websites
> with TLS extension or TLS version intolerance is not very meaningful.

the point of those studies is not to test the whole TLS ecosystem - that's 
simply impossible

the point is to have at least /some/ reference point

also, HTTPS is the biggest user of TLS so it's likely that if there is a TLS 
implementation it is used by somebody to encrypt web traffic. HTTPS is also 
basically the only one that gets any kind of scrutiny wrt. used 
configurations.

if you have different statistics, please share them

> adding a small number of TLS cipher suites IDs to ClientHello creates
> only a manageable risk (rfc5746 did not cause any interop problems).

It probably did not, but tests done by Yngve say something different wrt to 
cipher id selected for fallback scsv

-- 
Regards,
Hubert Kario


[prev in list] [next in list] [prev in thread] [next in thread]