Re: [TLS] TLS Charter Revision

Marsh Ray <maray@microsoft.com> Wed, 04 December 2013 03:14 UTC

Return-Path: <maray@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 4EC1B1ADFFD for <tls@ietfa.amsl.com>; Tue, 3 Dec 2013 19:14:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 ve2gt_yd2E3y for <tls@ietfa.amsl.com>; Tue, 3 Dec 2013 19:14:03 -0800 (PST)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0186.outbound.protection.outlook.com [207.46.163.186]) by ietfa.amsl.com (Postfix) with ESMTP id C30A01ADFF5 for <tls@ietf.org>; Tue, 3 Dec 2013 19:14:02 -0800 (PST)
Received: from BY2PR03MB074.namprd03.prod.outlook.com (10.255.241.154) by BY2PR03MB075.namprd03.prod.outlook.com (10.255.241.155) with Microsoft SMTP Server (TLS) id 15.0.820.5; Wed, 4 Dec 2013 03:13:57 +0000
Received: from BY2PR03MB074.namprd03.prod.outlook.com ([169.254.12.17]) by BY2PR03MB074.namprd03.prod.outlook.com ([169.254.12.159]) with mapi id 15.00.0820.005; Wed, 4 Dec 2013 03:13:57 +0000
From: Marsh Ray <maray@microsoft.com>
To: Watson Ladd <watsonbladd@gmail.com>, "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>
Thread-Topic: [TLS] TLS Charter Revision
Thread-Index: AQHO75QH12xj16hlv0SmAgrMfgWOIZpB1QcAgAF+I3A=
Date: Wed, 4 Dec 2013 03:13:57 +0000
Message-ID: <53edda7bf2804289817f54a8c2ecce33@BY2PR03MB074.namprd03.prod.outlook.com>
References: <2F2286E3-7717-4E8F-B1EA-B2E4155F7C17@cisco.com> <CACsn0ckzA9hd3+zTH5FNNBbPAQqUqaXD8_Z35a8vKEG6WjXbTg@mail.gmail.com>
In-Reply-To: <CACsn0ckzA9hd3+zTH5FNNBbPAQqUqaXD8_Z35a8vKEG6WjXbTg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [2001:4898:80e0:ed43::3]
x-forefront-prvs: 0050CEFE70
x-forefront-antispam-report: SFV:NSPM; SFS:(199002)(189002)(65816001)(15975445006)(80976001)(49866001)(77982001)(87266001)(33646001)(19580405001)(15202345003)(85306002)(83072001)(83322001)(53806001)(80022001)(81542001)(56816005)(90146001)(85852002)(63696002)(54356001)(19580395003)(47446002)(81342001)(81816001)(74366001)(56776001)(31966008)(47976001)(46102001)(59766001)(76482001)(81686001)(74316001)(77096001)(76786001)(74706001)(74662001)(76796001)(87936001)(51856001)(69226001)(74502001)(54316002)(2656002)(47736001)(74876001)(79102001)(4396001)(76576001)(50986001)(3826001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB075; H:BY2PR03MB074.namprd03.prod.outlook.com; CLIP:2001:4898:80e0:ed43::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>" <tls@ietf.org>
Subject: Re: [TLS] TLS Charter Revision
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: Wed, 04 Dec 2013 03:14:06 -0000

From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Watson Ladd

> I strenuously object to the proposed rechartering as it now stands.
> First, I do not have confidence in this WG and its chair to deliver a secure protocol to the
> IESG. They did not the previous 3 times, and I do not want to give them a 4th shot
> without some guarantee of the quality.

> Secondly, the proposed recharting has made certain technical decisions related to
> the protocol without due discussion, in particular the list of goals implies that we
> keep the stupidity of multiple ciphersuites and extensions galore around.

SSL/TLS has had some issues over the last 20 years, but I can't think of any serious ones *caused* by the multiplicity of ciphersuites and extensions. To the contrary, the version negotiation, cipher suite, and extension mechanisms have been invaluable in rapidly deploying fixes when cracks have appeared in the other parts.

> Thirdly, the experience of TLS 1.2 teaches us that no matter how compatible a
> protocol upgrade is, it will not happen, and so one need not keep compatibility.

That must be why SSLv2 has 99% server market share and TLS has only 20%. Oh wait, I got that backwards. https://www.trustworthyinternet.org/ssl-pulse/
So uhh..."baloney".

Looks like the latest version of Centos and its upstream "major North American Linux vendor"
Made this change "OpenSSL and NSS now support TLS 1.1 and 1.2."
http://wiki.centos.org/Manuals/ReleaseNotes/CentOS6.5

Microsoft clients and servers have supported it for years now but it has been off by default.

Oh looky... 83.9% of sites have even added support for the RFC 5746 Renegotiation Indication security patch in just the last 3-4 years, whereas only 74.3% of servers have disabled SSLv2. I dunno, could have something to do with the fact that the extension mechanism allows adoption without breaking existing clients and servers.

> Fourthly, item 3 is not strong enough: AtE needs to die a fiery death and nothing short of killing RC4 will address its shortcomings.

I agree that AtE was a mistake and needs to go, but what would killing RC4 do to "address its shortcomings"?

> I propose the following charter instead.
> "To create a protocol establishing a secure encrypted and authenticated channel in the
> standard model between parties A and B, supporting the following authentication methods:
> -One-way authentication with the PKI
> -Two-way authentication with the PKI
> -Two-way authentication with a shared low-entropy secret -One side authenticated with the PKI, and the other with a shared low-entropy secret.
> Said protocol will function over UDP and TCP with a minimum of handshakes, complexity, and options, and will have a formal security proof."

Gee you make it sound so easy.

I think we should also consider forward secrecy to be a required and essential security property these days.

Also, how about some security for anonymous connections too? And resistance to traffic analysis and fingerprinting. And privacy of the endpoints' identities. And not becoming a browser evercookie. And not enabling any new forms of server DoS attacks. And so on.

- Marsh