IETF Logo Mail Archive

Re: [TLS] Deployment ... Re: This working group has failed

Andrei Popov <Andrei.Popov@microsoft.com> Mon, 18 November 2013 19:04 UTC

Return-Path: <Andrei.Popov@microsoft.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 828D01ACCDA for <tls@ietfa.amsl.com>; Mon, 18 Nov 2013 11:04:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.701
X-Spam-Level:
X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 Ouo4A8wcjv9f for <tls@ietfa.amsl.com>; Mon, 18 Nov 2013 11:04:30 -0800 (PST)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0236.outbound.protection.outlook.com [207.46.163.236]) by ietfa.amsl.com (Postfix) with ESMTP id 4300B1ADFB6 for <tls@ietf.org>; Mon, 18 Nov 2013 11:02:10 -0800 (PST)
Received: from BL2PR03MB194.namprd03.prod.outlook.com (10.255.230.142) by BL2PR03MB195.namprd03.prod.outlook.com (10.255.230.153) with Microsoft SMTP Server (TLS) id 15.0.820.5; Mon, 18 Nov 2013 19:02:03 +0000
Received: from BL2PR03MB194.namprd03.prod.outlook.com ([169.254.14.47]) by BL2PR03MB194.namprd03.prod.outlook.com ([169.254.14.47]) with mapi id 15.00.0820.005; Mon, 18 Nov 2013 19:02:03 +0000
From: Andrei Popov <Andrei.Popov@microsoft.com>
To: Yoav Nir <ynir@checkpoint.com>
Thread-Topic: [TLS] Deployment ... Re: This working group has failed
Thread-Index: AQHO4rSlvcE/bUSuv06ARL36VO/SBpooKLUAgAESAICAAAvPgIACDiBQ
Date: Mon, 18 Nov 2013 19:02:02 +0000
Message-ID: <06a3c2e5ba2b451a80cd05b18e8f4f72@BL2PR03MB194.namprd03.prod.outlook.com>
References: <CACsn0c=i2NX2CZ=Md2X+WM=RM8jAysaenz6oCxmoPt+LC5wvjA@mail.gmail.com> <52874576.9000708@gmx.net> <5287B4F6.1060102@defuse.ca> <52889ACF.3050302@gmx.net> <11586138-5410-404B-905F-CEA1DEBF6DE1@checkpoint.com>
In-Reply-To: <11586138-5410-404B-905F-CEA1DEBF6DE1@checkpoint.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [2001:4898:80e0:ee43::3]
x-forefront-prvs: 00342DD5BC
x-forefront-antispam-report: SFV:NSPM; SFS:(377454003)(199002)(189002)(24454002)(51704005)(13464003)(59766001)(77982001)(74366001)(2656002)(56816003)(87266001)(63696002)(77096001)(79102001)(76576001)(87936001)(76786001)(76796001)(31966008)(83072001)(33646001)(56776001)(54316002)(74316001)(74662001)(74502001)(47446002)(51856001)(81542001)(15975445006)(19580395003)(19580405001)(46102001)(74706001)(54356001)(69226001)(83322001)(53806001)(4396001)(47736001)(50986001)(49866001)(80976001)(47976001)(81686001)(80022001)(85306002)(81816001)(65816001)(81342001)(76482001)(74876001)(3826001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR03MB195; H:BL2PR03MB194.namprd03.prod.outlook.com; CLIP:2001:4898:80e0:ee43::3; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en;
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
Cc: "tls@ietf.org list" <tls@ietf.org>
Subject: Re: [TLS] Deployment ... Re: This working group has failed
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: Mon, 18 Nov 2013 19:04:32 -0000

Hi Yoav,

Yes, the percentage if servers that can't handle TLS1.2 or gracefully negotiate a lower protocol version is diminishing, but very slowly. From my perspective, enabling TLS1.2 by default is necessitated primarily by security and performance considerations (e.g. a chance to negotiate AES_GCM instead of RC4). However, for web browsers, enabling TLS1.2 by default means one more step in the sequence of (insecure) reconnect attempts with lower protocol versions.

Cheers,

Andrei

-----Original Message-----
From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of Yoav Nir
Sent: Sunday, November 17, 2013 3:13 AM
To: Hannes Tschofenig
Cc: tls@ietf.org list
Subject: Re: [TLS] Deployment ... Re: This working group has failed


On Nov 17, 2013, at 12:30 PM, Hannes Tschofenig <Hannes.Tschofenig@gmx.net> wrote:

> Hi Taylor,
> 
> Would be interesting to hear from someone working for Mozilla (like Ekr, our TLS WG chair) why things are progressing so slowly and what exactly their problem is.
> 

Hi Hannes

We have heard before from people at Google and at Microsoft. Google only added TLS 1.2 very recently, and Microsoft added it very early, but disabled it by default for a long time.

There were issues with failures of connections attempts using TLS 1.2.  There have been issues with 1.1, but 1.2 produced much more of them.

 1. TLS 1.2 is the first version to require support of extensions. Some servers broke when extensions existed.
 2. Some servers broke on unrecognized extensions.
 3. Some server break on missing extensions - certain servers will not accept a TLS 1.2 ClientHello without the SignatureAlgorithm extension

Combining 1 & 3, you can't win. Some servers just won't work.

I don't know what changed. Perhaps the percentage of servers that are broken like that has diminished. But not it looks like the browser vendors have deemed it as sufficiently low to allow them to make this on by default.

Yoav

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

v2.23.0 | Report a Bug | By Email