Re: [TLS] 1.0 or else (was Re: Working Group Last Call for draft-ietf-tls-sslv3-diediedie-00)
Hubert Kario <hkario@redhat.com> Fri, 30 January 2015 17:15 UTC
Return-Path: <hkario@redhat.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D5A61A8702 for <tls@ietfa.amsl.com>; Fri, 30 Jan 2015 09:15:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.912
X-Spam-Level:
X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GWL9SXrp2xjw for <tls@ietfa.amsl.com>; Fri, 30 Jan 2015 09:15:29 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C78901A6EDA for <tls@ietf.org>; Fri, 30 Jan 2015 09:15:29 -0800 (PST)
Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t0UHFPYV005710 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 30 Jan 2015 12:15:26 -0500
Received: from pintsize.usersys.redhat.com (vpn1-5-211.ams2.redhat.com [10.36.5.211]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t0UHFM4a025705 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Jan 2015 12:15:24 -0500
From: Hubert Kario <hkario@redhat.com>
To: tls@ietf.org, mrex@sap.com
Date: Fri, 30 Jan 2015 18:15:21 +0100
Message-ID: <59280567.z7RHC5U6jC@pintsize.usersys.redhat.com>
User-Agent: KMail/4.14.3 (Linux/3.17.8-200.fc20.x86_64; KDE/4.14.3; x86_64; ; )
In-Reply-To: <20150129180033.332D71B137@ld9781.wdf.sap.corp>
References: <20150129180033.332D71B137@ld9781.wdf.sap.corp>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/zcC4nqkNzyDZsCKlr0E16tYhhus>
Subject: Re: [TLS] 1.0 or else (was Re: Working Group Last Call for draft-ietf-tls-sslv3-diediedie-00)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 30 Jan 2015 17:15:32 -0000
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
- [TLS] 1.0 or else (was Re: Working Group Last Cal… Martin Thomson
- Re: [TLS] 1.0 or else (was Re: Working Group Last… Martin Rex
- Re: [TLS] 1.0 or else (was Re: Working Group Last… Hubert Kario