Re: [TLS] Deployment ... Re: This working group has failed
Watson Ladd <watsonbladd@gmail.com> Mon, 18 November 2013 20:02 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 D993B1AE1E8 for <tls@ietfa.amsl.com>; Mon, 18 Nov 2013 12:02:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=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 yG52_r8Mp5dZ for <tls@ietfa.amsl.com>; Mon, 18 Nov 2013 12:02:24 -0800 (PST)
Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 0078A1AE1C5 for <tls@ietf.org>; Mon, 18 Nov 2013 12:02:23 -0800 (PST)
Received: by mail-we0-f172.google.com with SMTP id t60so1747831wes.17 for <tls@ietf.org>; Mon, 18 Nov 2013 12:02:16 -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=ygYpB0Y1BVocJCis9zp/OLvAK8XMu1n4nTB6u2/B9dM=; b=kk+MNdGNxcOVIG2Dhd7KHpkVtl1ZSeIAf9IalQtHjkeEfwgRpOS3+uUewlsQ8mX/NM 47WwV/B64sE3ZXstfFZvS1bv7X9W2ZAKphKQpjSDzEsVN30mWxxI+R/sB5uPvhCfVlrW 5ZVZOQKdIQ+Gnm5aMdCw3T/kFY1/kojB6wb0fK/LmCyxEH1YT++OdR9Rb/7jDefOX95s lX3fP4pIBQsCrMPGo/iEDLNYJBXO52NaHjZReQw+mkfE4Lq0pvd6o2j/duQKRMg/qCJq YldP9/FAs9Y8SW2E4CMTfcfnk09A+eqHpt7oRpshn87iDKoIjvmvHzFD9RfPTIHv96n4 0aBA==
MIME-Version: 1.0
X-Received: by 10.194.109.68 with SMTP id hq4mr18451318wjb.12.1384804936597; Mon, 18 Nov 2013 12:02:16 -0800 (PST)
Received: by 10.194.242.131 with HTTP; Mon, 18 Nov 2013 12:02:16 -0800 (PST)
Received: by 10.194.242.131 with HTTP; Mon, 18 Nov 2013 12:02:16 -0800 (PST)
In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C711DAEEE432@USMBX1.msg.corp.akamai.com>
References: <CACsn0c=i2NX2CZ=Md2X+WM=RM8jAysaenz6oCxmoPt+LC5wvjA@mail.gmail.com> <52874576.9000708@gmx.net> <CAPMEXDbgp5+Gg6mkMWNrcOzmAbSpv3kjftGV0cjpqvMnRxpw=A@mail.gmail.com> <44D7624E-75D8-47D3-93BF-97427206E800@iki.fi> <CACsn0c=9GrO21ECZczB2zft3bVODcc=1ZRp3pG22c-rrDfTPXQ@mail.gmail.com> <2A0EFB9C05D0164E98F19BB0AF3708C711DAEEE373@USMBX1.msg.corp.akamai.com> <CACsn0cnRUDZp=_iOy+J4Ur1PFtkJgfFcHzhVFviSYUG9mh_t4w@mail.gmail.com> <2A0EFB9C05D0164E98F19BB0AF3708C711DAEEE432@USMBX1.msg.corp.akamai.com>
Date: Mon, 18 Nov 2013 12:02:16 -0800
Message-ID: <CACsn0c=txtnpu6CbDVfRb-DFqyh4NwBv2ehXds-HYh2NR=XTEQ@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: "Salz, Rich" <rsalz@akamai.com>
Content-Type: multipart/alternative; boundary="089e0102e6da5446ea04eb7906fa"
Cc: "TLS@ietf.org (tls@ietf.org)" <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 20:02:26 -0000
On Mon, Nov 18, 2013 at 8:41 AM, Salz, Rich <rsalz@akamai.com> wrote: > These seem contradictory to me: > >>> TLS 1.2 solves the same problem as TLS 1.0. It should therefore have the same API. >> The current APIs have caused lots of security bugs as people don't use them correctly. The solution: high level APIs that won't change ... The point is to do it right for both TLS 1.2 and TLS 1.0. If you expose details you shouldn't you are not going to be able to keep them stable or used correctly. > > The IETF has traditionally avoided API's and doesn't get involved in high-level language wars (other than ASN.1/DER vs ASCII art :) I vote ASCII art: it keeps the specs simple by imposing a cost on complexity. Now, someone try making ASCII art for all of TLS. As for the API issue, I am not suggesting that we standardize it anymore than the IPSEC people standardized F/SWAN. Rather I am suggesting that we view the lamentable state of the OpenSSL and NSS source code as problems that are keeping RC4 alive. If the WG wants to ignore the need for reference implementations and interoperability testing fine. But that is not the way successful standards have emerged from the IETF. > > /r$ > > -- > Principal Security Engineer > Akamai Technology > Cambridge, MA -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin
- [TLS] This working group has failed Watson Ladd
- [TLS] Deployment ... Re: This working group has f… Hannes Tschofenig
- Re: [TLS] Deployment ... Re: This working group h… Taylor Hornby
- Re: [TLS] This working group has failed SM
- Re: [TLS] This working group has failed Ralph Holz
- Re: [TLS] Deployment ... Re: This working group h… Hannes Tschofenig
- Re: [TLS] Deployment ... Re: This working group h… Yoav Nir
- Re: [TLS] Deployment ... Re: This working group h… Hannes Tschofenig
- Re: [TLS] This working group has failed Salz, Rich
- Re: [TLS] Deployment ... Re: This working group h… Mark Nottingham
- Re: [TLS] Deployment ... Re: This working group h… Kyle Hamilton
- Re: [TLS] Deployment ... Re: This working group h… Juho Vähä-Herttua
- Re: [TLS] Deployment ... Re: This working group h… Watson Ladd
- Re: [TLS] Deployment ... Re: This working group h… Salz, Rich
- Re: [TLS] Deployment ... Re: This working group h… Watson Ladd
- Re: [TLS] Deployment ... Re: This working group h… Salz, Rich
- Re: [TLS] Deployment ... Re: This working group h… Andrei Popov
- Re: [TLS] Deployment ... Re: This working group h… Martin Rex
- Re: [TLS] Deployment ... Re: This working group h… Martin Rex
- Re: [TLS] Deployment ... Re: This working group h… Watson Ladd
- Re: [TLS] Deployment ... Re: This working group h… Geoffrey Keating
- Re: [TLS] Deployment ... Re: This working group h… Michael Staubermann
- Re: [TLS] Deployment ... Re: This working group h… Martin Rex
- Re: [TLS] Deployment ... Re: This working group h… Joshua Davies
- Re: [TLS] Deployment ... Re: This working group h… Martin Rex
- Re: [TLS] Deployment ... Re: This working group h… Martin Rex
- Re: [TLS] Deployment ... Re: This working group h… Andy Lutomirski
- Re: [TLS] Deployment ... Re: This working group h… Kirils Solovjovs
- Re: [TLS] Deployment ... Re: This working group h… Andy Wilson
- Re: [TLS] Deployment ... Re: This working group h… Marsh Ray
- Re: [TLS] Deployment ... Re: This working group h… Ralf Skyper Kaiser
- Re: [TLS] Deployment ... Re: This working group h… Ben Laurie
- [TLS] TLS protocol version intolerance [Was: Re: … Ivan Ristić
- Re: [TLS] Deployment ... Re: This working group h… Zooko Wilcox-OHearn
- Re: [TLS] TLS protocol version intolerance [Was: … Michael Sweet
- Re: [TLS] TLS protocol version intolerance [Was: … Eric Rescorla
- Re: [TLS] Deployment ... Re: This working group h… Martin Rex
- Re: [TLS] Deployment ... Re: This working group h… Andy Lutomirski
- Re: [TLS] Deployment ... Re: This working group h… Martin Rex
- [TLS] multiple clients in one process (was: Re: D… Patrick Pelletier
- Re: [TLS] multiple clients in one process (was: R… Andy Lutomirski
- Re: [TLS] multiple clients in one process (was: R… Daniel Kahn Gillmor
- Re: [TLS] multiple clients in one process (was: R… Nico Williams
- Re: [TLS] multiple clients in one process (was: R… Nikos Mavrogiannopoulos
- Re: [TLS] multiple clients in one process (was: R… Andy Lutomirski