Re: [TLS] Industry Concerns about TLS 1.3

Brian Sniffen <bsniffen@akamai.com> Sun, 25 September 2016 03:31 UTC

Return-Path: <bsniffen@akamai.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 0DAA312B0B9 for <tls@ietfa.amsl.com>; Sat, 24 Sep 2016 20:31:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.017
X-Spam-Level:
X-Spam-Status: No, score=-5.017 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.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 pCWOHUfOBShw for <tls@ietfa.amsl.com>; Sat, 24 Sep 2016 20:31:24 -0700 (PDT)
Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 4246E128B38 for <tls@ietf.org>; Sat, 24 Sep 2016 20:31:24 -0700 (PDT)
Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 5AFED43348B; Sun, 25 Sep 2016 03:31:23 +0000 (GMT)
Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 44A1B433449; Sun, 25 Sep 2016 03:31:23 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1474774283; bh=tS5On7qFZ8Tkf9XvfAZftWgMdKdsmc295FlJaKdx3YU=; l=8637; h=From:To:Cc:In-Reply-To:References:Date:From; b=bH58/lTX4i1FnFlA1LLpZ/NOBD749Ox20cmbdWGdfxOfxDwP/tBJnF2e5BPnxORuo jBHzOT5FCUQ2Osk3LC7SxWCbs6QVa6G6wpBkYB36bLxaBQ1ozRjkRix3ed7ErqzQWT prWbT/uDz9jhHFRby1lphA9CsHGyR8HOKYWQPcrU=
Received: from Tereva.local (unknown [172.19.44.170]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 156C21FC8C; Sun, 25 Sep 2016 03:31:23 +0000 (GMT)
From: Brian Sniffen <bsniffen@akamai.com>
To: nalini.elkins@insidethestack.com, Watson Ladd <watsonbladd@gmail.com>, "Ackermann, Michael" <MAckermann@bcbsm.com>
In-Reply-To: <72011214.413503.1474650126973@mail.yahoo.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> <CACsn0c=5vjzQmr=ah6sH1JzTj3peaKad7aCPertcqD4B2DLKiA@mail.gmail.com> <72011214.413503.1474650126973@mail.yahoo.com>
User-Agent: Notmuch/0.22.1 (https://notmuchmail.org) Emacs/24.5.1 (x86_64-apple-darwin15.3.0)
Date: Sat, 24 Sep 2016 23:31:22 -0400
Message-ID: <m21t088xkl.fsf@usma1mc-0csx92.kendall.corp.akamai.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/IEeRMs3AL0FsH2J_7AsOzw9E524>
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: Sun, 25 Sep 2016 03:31:27 -0000

nalini.elkins@insidethestack.com writes:

> [ Unknown encryption status ]
> [ Unknown signature status ]
>
>
>
>>>
>>> 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?
> It would be very interesting to get the network diagnostic and
> operations people (rather than the architects) of the above companies
> involved in this conversation.

Hi, technical person most directly responsible for incident response and
urgent debugging here.  We modify endpoints to get what we need.  We did
have taps that relied on knowing the RSA Kx secret... but haven't used
them in about a decade.

I think the banks have an answer not available to the global passive
adversaries: modify the server or client to use a fixed ECDH share, then
use tech much like their current choices.  It'll take a while to
develop, but nobody in that environment plans to move to TLS 1.3 for
operational systems any time soon anyway.

-Brian


> Also, you know, companies don't really enjoy spending money on network diagnostic products which might be considered overhead.   So, if they are, we might do them the courtesy of not thinking that they are foolish to do so.   
> Why don't we listen to each other?   I know at IETF, I often hear that we don't get enough operators to comment and give feedback.  Well, here you have some.  It may be that these companies have problems that are different from Google's (just as an example).
> Isn't our goal to have the best standards possible?   Any organism (including the IETF), needs feedback to thrive.
> Nalini
>>
>> 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.
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>
>    
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>
>
>>>
>>> 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?
> It would be very interesting to get the network diagnostic and operations people (rather than the architects) of the above companies involved in this conversation.
> Also, you know, companies don't really enjoy spending money on network diagnostic products which might be considered overhead.   So, if they are, we might do them the courtesy of not thinking that they are foolish to do so.   
> Why don't we listen to each other?   I know at IETF, I often hear that we don't get enough operators to comment and give feedback.  Well, here you have some.  It may be that these companies have problems that are different from Google's (just as an example).
> Isn't our goal to have the best standards possible?   Any organism (including the IETF), needs feedback to thrive.
> Nalini
>>
>> 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

-- 
Brian Sniffen
Akamai Technologies