Re: [TLS] TLS Charter Revision

Watson Ladd <watsonbladd@gmail.com> Wed, 04 December 2013 04:08 UTC

Return-Path: <watsonbladd@gmail.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 7205C1ADF80 for <tls@ietfa.amsl.com>; Tue, 3 Dec 2013 20:08:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 PctfZvtKiYP9 for <tls@ietfa.amsl.com>; Tue, 3 Dec 2013 20:08:14 -0800 (PST)
Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) by ietfa.amsl.com (Postfix) with ESMTP id 807831ADF0E for <tls@ietf.org>; Tue, 3 Dec 2013 20:08:14 -0800 (PST)
Received: by mail-wi0-f182.google.com with SMTP id en1so7553952wid.15 for <tls@ietf.org>; Tue, 03 Dec 2013 20:08:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=UuLrrMbKrWuLl7XQMqdaPAgjBYorkLIN7jKBfR6K+Tc=; b=bFZPKPDzFRRjgYLbEWQYtT+Po7AoNZ0IIK8x81oIeK/KuIemfooFKWyjKrTjvfFLZe oU52GBH6LXDgf6rPvCpiu62t6PrRwNySQYUKnzNHLAEpS7GrVCvRy28WzRW7FBO36UnJ DL1nEb3xMi29xIDiZPkr/R6NG0bwb1PoEvFs4N0vrzpaZruArh6dNJXHJzV2we/NlHAa mmbsViNuQA14ifUGEVY60bUvxGjM4tiocyZs15yo9yJfeoDl+DxUEyTUnBtGhcs1kWB7 Zn9K1LSgkCdivUjeW19vHvz5UP0yxPcWImfXXbqF1/So7bYZvwilrCYvDQ327t6xUzun JCpw==
MIME-Version: 1.0
X-Received: by 10.194.85.75 with SMTP id f11mr10285404wjz.14.1386130091174; Tue, 03 Dec 2013 20:08:11 -0800 (PST)
Received: by 10.194.242.131 with HTTP; Tue, 3 Dec 2013 20:08:11 -0800 (PST)
In-Reply-To: <53edda7bf2804289817f54a8c2ecce33@BY2PR03MB074.namprd03.prod.outlook.com>
References: <2F2286E3-7717-4E8F-B1EA-B2E4155F7C17@cisco.com> <CACsn0ckzA9hd3+zTH5FNNBbPAQqUqaXD8_Z35a8vKEG6WjXbTg@mail.gmail.com> <53edda7bf2804289817f54a8c2ecce33@BY2PR03MB074.namprd03.prod.outlook.com>
Date: Tue, 3 Dec 2013 20:08:11 -0800
Message-ID: <CACsn0ck1-H7ChD+2vKRUjiCiC-U3Gq0AKy2EdoPkdFBxG-xqXg@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: Marsh Ray <maray@microsoft.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
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 04:08:17 -0000

On Tue, Dec 3, 2013 at 7:13 PM, Marsh Ray <maray@microsoft.com> wrote:
> 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.
Other than letting people shoot themselves in the foot by making
insecure choices and limiting the number of compatible
implementations, as well as confounding security analysis?
>
>> 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".
>
Look at TLS 1.2 vs TLS 1.0. Active attacks exist that are only fixed
by TLS 1.2. That's also server side, not client side, so it's only
part of the full picture. And it's been 14 years since TLS 1.0 came
out. Major US financial institutions, responsible for trillions of
assets, deploy TLS in configurations that are insecure.
> 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.
A functioning upgrade path protects the upgraded. That it's been off
by default shows just how bad the upgrade picture is.
>
> 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.
If your browser is negotiating a broken protocol it is broken. Keeping
you using it is doing no one any favours.
>
>> 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"?
That "and" was not subordinating/the "its" goes with RC4 not AtE.
>
>> 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.
What part do you think is hard? We've known how to do all of this
since basically forever in cryptography terms, except the formal proof
part, but
that's automatic now. CurveCP has all of this working except the
shared low-entropy secret part.
>
> 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
>



-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin