Re: [TLS] Industry Concerns about TLS 1.3

Watson Ladd <watsonbladd@gmail.com> Fri, 23 September 2016 15:43 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 0162C12B841 for <tls@ietfa.amsl.com>; Fri, 23 Sep 2016 08:43:50 -0700 (PDT)
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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 BJpl-cjK7_-3 for <tls@ietfa.amsl.com>; Fri, 23 Sep 2016 08:43:48 -0700 (PDT)
Received: from mail-ua0-x22c.google.com (mail-ua0-x22c.google.com [IPv6:2607:f8b0:400c:c08::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D87A612B7ED for <tls@ietf.org>; Fri, 23 Sep 2016 08:43:47 -0700 (PDT)
Received: by mail-ua0-x22c.google.com with SMTP id u68so46070581uau.0 for <tls@ietf.org>; Fri, 23 Sep 2016 08:43:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Uj8/rsgkRoQmjzbG6L/zFiOj5dqs4ua4Hy8mCOjYJ6A=; b=ppmq3Y80Ict10jdOH8C1XPmPlz4xOD1YskDV4ALNlOASm9hAjhap5l8IUO43au2xN+ xEGppgSqti/SHfBdeDIktK9UXGbV+J5xLJvCd19ZnjFOCs8SiYdiqEqYopb9alhKZUaa 6bhY09btJLvPa19o3VhbqKYcIB9SqRzC0j/XD4LgsDG4Uj0rRLQy+HCJIW1Q40nylJWc aIipXdvCS+ejOrLlbkVS+Qb+fWWlX16iHFdXoI2fi4cTAxBH+sBrj1/EO2v3hK4a8vuJ KQNccPlPElyKt/4A3JTf1IMCNcR6v7gQ5ujSLkd9nWRN9NpGkRVnUp69Sctq9mJj+aD/ XroQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Uj8/rsgkRoQmjzbG6L/zFiOj5dqs4ua4Hy8mCOjYJ6A=; b=LZ3mNOXjrHPRxRxb576NesukZ9IESYfRUXMg5D73xTT5nyXFxWTb6KTyjsvHNja1fx 29zSGuBAhRAQzXE0+ptDB7hgTCkXzObjySFU24ENYzrMrlOGKeO/kg2Qtprqku9MdHJz Hy3Du1vn+xfjeBIQb3TTBGvpmM7Ul1GCaOFeenw/GgW/AjxVSPWusYpPtdAM2lAjm2yL xBKsjQO0lP7K06CqW2yQ1iwfwrDOMKXHogVSZ9md6d0Z1+Os2l67xD0U/TirzlJLomnZ zuP3XjxGG1MU5w7OQHhdj/CMaZRVOAOCdvkbLIRUiJl4zD4GfB1Ms6cYgctY0JYMf76w aOJA==
X-Gm-Message-State: AE9vXwMbf4Q2A0Vgo8cAITnk8IvmCAMWCaT3susC5LQSnIWuwK9aGV11ZjkbPjTAws+z4ZJ39gIZeBXIiYpwGQ==
X-Received: by 10.176.0.143 with SMTP id 15mr4192569uaj.33.1474645426983; Fri, 23 Sep 2016 08:43:46 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.176.4.102 with HTTP; Fri, 23 Sep 2016 08:43:46 -0700 (PDT)
In-Reply-To: <4FC37E442D05A748896589E468752CAA0DBC699B@PWN401EA120.ent.corp.bcbsm.com>
References: <DM5PR11MB1419B782D2BEF0E0A35E420DF4C90@DM5PR11MB1419.namprd11.prod.outlook.com> <CO1PR07MB283F2C414B6478E993675DEC3C90@CO1PR07MB283.namprd07.prod.outlook.com> <394611bf-208f-03d3-620c-79aaf169645b@cs.tcd.ie> <4FC37E442D05A748896589E468752CAA0DBC66AE@PWN401EA120.ent.corp.bcbsm.com> <CAH8yC8kgYzYXwJ01NkK7WYxD-diponWEQOd+MNHssm+bLHE54w@mail.gmail.com> <4FC37E442D05A748896589E468752CAA0DBC699B@PWN401EA120.ent.corp.bcbsm.com>
From: Watson Ladd <watsonbladd@gmail.com>
Date: Fri, 23 Sep 2016 08:43:46 -0700
Message-ID: <CACsn0c=5vjzQmr=ah6sH1JzTj3peaKad7aCPertcqD4B2DLKiA@mail.gmail.com>
To: "Ackermann, Michael" <MAckermann@bcbsm.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/0pObn7F7xB8ErtzFD62XFFCIzTk>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Industry Concerns about TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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: Fri, 23 Sep 2016 15:43:50 -0000

On Fri, Sep 23, 2016 at 8:31 AM, Ackermann, Michael
<MAckermann@bcbsm.com>; wrote:
>  I am not sure I understand what your reply means?
>
> Is it that we should create or even allow an environment to develop,  where all providers of service cannot  provide effective diagnostics and support?   And then see the constituents of these industries collapse together.     And only then realize we have an issue?
> I hope I am  not understanding correctly.     IETF is supposed to be looking ahead to provide better answers and circumvent predictable problems.    Not ignoring,  waiting and then reacting to negative situations that can and should be avoided.

What exactly is the problem you are concerned with? As I've pointed
out previously one can still log the contents of TLS protected
connections: you do this at the client, or with an intercepting proxy.
What information does this not get you that you need on the network?

>
> What I am saying,  in relation to your "Delivering a stable product"  comment is that over time various industries have learned what it takes to "Deliver a stable product".    We did not want to invest millions in these debugging networks.   But  we learned the hard way,  that it was necessary.
> I am not a member of the banking coalition that started this subject,  nor of the banking industry at all,  but I certainly understand their perspective and am concerned about  the same unmanageable future they described.

Do  Akami, Cloudlflare and Google magically not have these problems?
>
> Thanks
>
> Mike
>
>
>
> -----Original Message-----
> From: Jeffrey Walton [mailto:noloader@gmail.com]
> Sent: Friday, September 23, 2016 10:55 AM
> To: Ackermann, Michael <MAckermann@bcbsm.com>;
> Cc: BITS Security <BITSSecurity@fsroundtable.org>;; tls@ietf.org
> Subject: Re: [TLS] Industry Concerns about TLS 1.3
>
> On Fri, Sep 23, 2016 at 10:46 AM, Ackermann, Michael <MAckermann@bcbsm.com>; wrote:
>> From the perspective an Enterprise that runs these applications and has invested HEAVILY in the debugging networks.........
>>
>> The reason we are debugging these networks is so that "The 5-6 order of magnitude of folks using them"  will have good service.   If they do not,  they will consider competitors and/or generate a litany service calls or complaints.        I.E.     When these "Folks"  are slow or not working they are just as unhappy as we are.
>>
>
> Isn't that the market operating as expected? Those who deliver a stable product at a competitive price are rewarded, while those who fail to deliver or deliver at an unreasonable cost are not? (Some hand waiving).
>
> If all providers failed to deliver or delivered an inferior product, then it might indicate a major course correction is needed. But I don't think that's the case here.
>
> Jeff
>
>
> The information contained in this communication is highly confidential and is intended solely for the use of the individual(s) to whom this communication is directed. If you are not the intended recipient, you are hereby notified that any viewing, copying, disclosure or distribution of this information is prohibited. Please notify the sender, by electronic mail or telephone, of any unintended receipt and delete the original message without making any copies.
>
>  Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are nonprofit corporations and independent licensees of the Blue Cross and Blue Shield Association.
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls



-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.