IETF Logo Mail Archive

[TLS] This working group has failed

Watson Ladd <watsonbladd@gmail.com> Sat, 16 November 2013 04:53 UTC

Return-Path: <watsonbladd@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF7FE11E81CA for <tls@ietfa.amsl.com>; Fri, 15 Nov 2013 20:53:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.741
X-Spam-Level:
X-Spam-Status: No, score=-0.741 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i3hcM3eBOnfO for <tls@ietfa.amsl.com>; Fri, 15 Nov 2013 20:53:38 -0800 (PST)
Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) by ietfa.amsl.com (Postfix) with ESMTP id F3BB111E81C4 for <tls@ietf.org>; Fri, 15 Nov 2013 20:53:33 -0800 (PST)
Received: by mail-wi0-f180.google.com with SMTP id ey16so1849135wid.7 for <tls@ietf.org>; Fri, 15 Nov 2013 20:53:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=OD4BDgEoUkU029ZDvrL0pxQFb5QWUqqaZAyCsPgXKlg=; b=cHiC1w/35pjtVePGv2iiK2jNhe/iY55B5bdli2jZFVaEkXKAgGXdAjU9TDAt6E0Okh eRKeQI4o3aOPyqfeQNGsVdOOFuSnfvkHSe3cdFHHVrxCOnSu3B71bVb9ywkzHB4eF/a4 sKum+po3P1E+bjkCrlnPTrr99Sav3riGoaidzmWEA50EGbP5tVorgXvO2gn/MIqtxPV8 F7rRqlE+wxkRp1hArlObrH919grwk3qiwX8UN3LCe5ILmU0qFsF0kOtRWNyiOV3ytZhD 9Gp102+jTACYOP+uDAAaSo3zuY/nfg5EUnnxS+jb1CwPb0pP8iHpyjSiLWGZPXHI0XQ0 W8ZQ==
MIME-Version: 1.0
X-Received: by 10.194.178.6 with SMTP id cu6mr3005580wjc.61.1384577612970; Fri, 15 Nov 2013 20:53:32 -0800 (PST)
Received: by 10.194.242.131 with HTTP; Fri, 15 Nov 2013 20:53:32 -0800 (PST)
Date: Fri, 15 Nov 2013 20:53:32 -0800
Message-ID: <CACsn0c=i2NX2CZ=Md2X+WM=RM8jAysaenz6oCxmoPt+LC5wvjA@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Subject: [TLS] This working group has failed
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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: Sat, 16 Nov 2013 04:53:39 -0000

In the past decade there have been many attacks against TLS.
With the exception of CRIME, not one of them relied on any results
that were not known
at the time the TLS 1.0 standard was being written. (See the citations
for the RC4 paper to see this, or the infamous Rogaway email about AtE
vs EtA). Every time this standards group has had a choice to make
regarding cryptography, they have made the wrong one. Even AES-GCM got
screwed up: nonces should be counters, but all implementations make
them random, introducing an artificial birthday bound issue due to
truncation in the standard.

TLS is solving the deadest of dead problems in cryptography: using the
PKI to establish a secure channel between two endpoints. Diffie and
Hellman solved this in their paper. Were TLS to be submitted by an
undergraduate as a solution to this problem it would earn an F.
Implementers such as AGL are bypassing the WG, choosing to emit I-Ds
and implementing and deploying because there is little to be gained
from WG discussions. This is not necessarily a bad thing, but it does
raise a question of whether what is good for Google is good for the
Web as a whole.

What problems would a hypothetical competition solve that TLS 1.2
hasn't already? Let's deal with real problems: TLS 1.2 is not getting
deployed, RC4 is still out there, the handshake protocol takes too
many round trips and is very hard to implement in an interoperable way
due to options, all the implementations with modern cryptographic
support have sucky APIs that make it impossible for ordinary
developers to use correctly, etc. All of this I have said before as
main priorities, but they are the biggest issues affecting us today. I
propose that a chair (do we have one?) convene a meeting via IRC or in
person at some convenient event to determine what problems should be
priorities, and then we will address them.

There are a few good points: I am glad to see that major vendors are
represented on this list, and are generally willing to work together
to insure interoperability and remove obstacles to improving internet
security. I am also glad to see that we are acutely aware of the
issues currently threatening the lives and property of internet users.

Sincerely,
Watson

v2.23.0 | Report a Bug | By Email