Re: [TLS] TLS Charter Revision

Watson Ladd <watsonbladd@gmail.com> Tue, 03 December 2013 03:45 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 0EA3B1ADFD3 for <tls@ietfa.amsl.com>; Mon, 2 Dec 2013 19:45:27 -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 4GeuNG2JQTeH for <tls@ietfa.amsl.com>; Mon, 2 Dec 2013 19:45:25 -0800 (PST)
Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 6571B1AD698 for <tls@ietf.org>; Mon, 2 Dec 2013 19:45:25 -0800 (PST)
Received: by mail-wg0-f45.google.com with SMTP id y10so11094361wgg.0 for <tls@ietf.org>; Mon, 02 Dec 2013 19:45:22 -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; bh=ZGUfNtTADDoVRjCTViQrr8+FCSPQLaBkH2VH1zgjorI=; b=RJAHJ6GvqJNMc+B7lj19zJmUDi8iEQ7gaAgRpzQcurPt7VkJrYCy5A6f9esMmpb5Od rSdgeHtp4jTwal/VeriTngCwXIqqITPBbhdThrzr/w6cuCqv/If3ySmzgusWK+Gc88EX 2yN/gHcjIuRUQPGhzbTCNTlwLnilTOfvixzvR/fAvLePxMIigCHmT8v/JPn3VMZAoIp4 7A8nxW3hGsjaqfePUmPmCvAD2JnyrKSJlQ5MnkXWI4ZR2VJyFVeZ8TMr1NnVKsoW4WTK 8lx1o2YXgoK6gNPMaZhIp7pphOAtp7Zmdg9HL0h7rGE+hEZ069Y3usF2Fq7Ov48K/FFV cuJA==
MIME-Version: 1.0
X-Received: by 10.180.103.233 with SMTP id fz9mr518875wib.20.1386042322521; Mon, 02 Dec 2013 19:45:22 -0800 (PST)
Received: by 10.194.242.131 with HTTP; Mon, 2 Dec 2013 19:45:22 -0800 (PST)
In-Reply-To: <2F2286E3-7717-4E8F-B1EA-B2E4155F7C17@cisco.com>
References: <2F2286E3-7717-4E8F-B1EA-B2E4155F7C17@cisco.com>
Date: Mon, 2 Dec 2013 19:45:22 -0800
Message-ID: <CACsn0ckzA9hd3+zTH5FNNBbPAQqUqaXD8_Z35a8vKEG6WjXbTg@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>
Content-Type: text/plain; charset=UTF-8
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: Tue, 03 Dec 2013 03:45:27 -0000

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. 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.
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 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."
Sincerely,
Watson Ladd