Re: [TLS] TLS@IETF101 Agenda Posted

nalini elkins <nalini.elkins@e-dco.com> Wed, 14 March 2018 23:46 UTC

Return-Path: <nalini.elkins@e-dco.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 AF9DF126CF6 for <tls@ietfa.amsl.com>; Wed, 14 Mar 2018 16:46:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=e-dco-com.20150623.gappssmtp.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 x8Tk5Dgo3td3 for <tls@ietfa.amsl.com>; Wed, 14 Mar 2018 16:46:41 -0700 (PDT)
Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (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 83523124D68 for <tls@ietf.org>; Wed, 14 Mar 2018 16:46:41 -0700 (PDT)
Received: by mail-it0-x22a.google.com with SMTP id e98-v6so1622646itd.4 for <tls@ietf.org>; Wed, 14 Mar 2018 16:46:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=e-dco-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=aTdiO4aWlZ8SsjgcjLYcrdUfWgn1fjNrPtPiqePW7f8=; b=OFf3ZjfdZa7hC6stlSOgMU9EYHy9xA9ruJ0skrJxms+T8+TnOoCEUI1Hf4NROGJWot 66URo8f6uvAEAJqIhLtuvO46D/4zbNTm9CbOb2ctkj08kAGT5Ug0DoYmRS5g4EHEJRyw xyJuBZN4oK+NjEsCJ29FskfkdDu2DNXOAQtBkvWNRMXmJ1OgUOhCcnSa0SM6mNxnYbL5 2pvQ1pN1zrLrofxaU4JQwv+ApA4b75up+wmzzoN6vdJBJhh54PczYHseO7KY9/8IcWmR sqXaDVGWmALMhwV7i7ZCE8db3h/3m+c9HzCVAz/ItH30uTn0Urob0eQdTui3Ejss6PQ4 9+9Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=aTdiO4aWlZ8SsjgcjLYcrdUfWgn1fjNrPtPiqePW7f8=; b=g22oxcsoH5h7RPtkIqVl4lLw5ANGslkpa5RMXphdNb8RK8Dz3PEyB6Dw6AAM3dDv8v FkvGfZnkPBwt8LCX6c55JkB6OMcGEfWviqGL7AAd6auKCxIq4T4HggaHNqqJmDQqspom hDTD8QgX9WKqVFM0+A6iSk6fTgIrAgmzEYGWbC3OcgQEG71/eH5wcy8eqeQqcr9L/l+l ISDLiKJHTga+L2K2VdVZtds83DwTcKeCMHckUkYwTe3QJQnIQhx1Uy23g2NxXajPdfFM tI5t0VjFxLQab7Ffyqd8ljM8eQOcBOG+3oXJLdDEbUYOkpe5WiLdtckLzRqwnnSbBk5A oZ6A==
X-Gm-Message-State: AElRT7GRno+0wcjGVXRCyrwQFNn34kSLGzGawPysJzD57Bbmgy4gkovZ bSnqR7dm9YDz0h7gWlhw3I0T1tyqBv0RJuh1X4LQFA==
X-Google-Smtp-Source: AG47ELuyI8Blqx5OJ3QfWj7xrkepLdBzSotMafT1AZC4bXfk3JCDwUb2tqyPK7cTDwpSl1Bv4p72sf8W9PO8ncOPmt4=
X-Received: by 10.36.43.80 with SMTP id h77mr4050070ita.103.1521071200776; Wed, 14 Mar 2018 16:46:40 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.2.29.138 with HTTP; Wed, 14 Mar 2018 16:46:40 -0700 (PDT)
In-Reply-To: <CAErg=HHnohEzi9OZViWM30p-P2dEGBtw+r5UWEtM7AFnXrVx6g@mail.gmail.com>
References: <6140B7A6-A1C7-44BC-9C65-9BE0D5E1B580@sn3rd.com> <986797a7-81b0-7874-5f39-afe83c86635b@cs.tcd.ie> <CAOgPGoBYc7O+qmjM-ptkRkE6mRsOYgc5O7Wu9pm3drFp3TVa6Q@mail.gmail.com> <d7dfdc1a-2c96-fd88-df1b-3167fe0f804b@cs.tcd.ie> <CAHbuEH7E8MhFcMt2GSngSrGxN=6bU6LD49foPC-mdoUZboH_0Q@mail.gmail.com> <1a024320-c674-6f75-ccc4-d27b75e3d017@nomountain.net> <2ed0gc.p5dcxd.31eoyz-qmf@mercury.scss.tcd.ie> <d7ec110f-2a0b-cf97-94a3-eeb5594d8c24@cs.tcd.ie> <CAAF6GDcaG7nousyQ6wotEg4dW8PFuXi=riH2702eZZn2fwfLQw@mail.gmail.com> <CAPsNn2XCNtqZaQM6Bg8uoMZRJE+qQakEwvw8Cn9fBm-5H+Xn_A@mail.gmail.com> <3F8142DE-EADB-4AB9-A204-7D87ACDCD3E3@akamai.com> <CAPsNn2VE_7+rWT0fp9rrVnZrgcY7ORLWTee+kf_Av1dqm4CiDQ@mail.gmail.com> <CB55AABB-8937-4F6B-B5AC-B6F262F08A4F@akamai.com> <CAPsNn2U_xG28Tumo3oRkQ+6=BHzgv-6YtgNSpwvhdFFRWc7EQQ@mail.gmail.com> <2DC45296-244E-4C72-8B3C-DE47EADAC2DE@fugue.com> <MWHPR21MB018978EDE7EA49B3D55B65268CD20@MWHPR21MB0189.namprd21.prod.outlook.com> <CAPsNn2UyTwe_qs_OpwFy0ikBrjcCuZqww2ZiLkk8MbcqkDvzNg@mail.gmail.com> <CAErg=HEfR27g6YqiaWXs7nY8fc=FNXq0r8v6aXsNs_hXUjd9TQ@mail.gmail.com> <CAPsNn2W-z+wQGra=LuVGM961j65OjetR91hT-JQh4sjzAuSuvw@mail.gmail.com> <CAErg=HHnohEzi9OZViWM30p-P2dEGBtw+r5UWEtM7AFnXrVx6g@mail.gmail.com>
From: nalini elkins <nalini.elkins@e-dco.com>
Date: Wed, 14 Mar 2018 16:46:40 -0700
Message-ID: <CAPsNn2VtozN6Udf3inQCE+Kixrac4pu1tT7kMJUxUmZBJ88rRA@mail.gmail.com>
To: Ryan Sleevi <ryan-ietftls@sleevi.com>
Cc: Andrei Popov <Andrei.Popov@microsoft.com>, "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="001a1147413899c566056767fcbe"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/HYeHW36JdPJHgSR-nzrjG4JzliM>
Subject: Re: [TLS] TLS@IETF101 Agenda Posted
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
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: Wed, 14 Mar 2018 23:46:44 -0000

 >>Enterprises value security and privacy.   They have a different job to
do.  What they are trying to do is to protect against leakage of data, do
fraud monitoring, protect against malware and many other things.   When
this gets into the medical arena, >>it can even be lives.  I don't even see
how you can say what you are saying.

>>Let me ask you then, what are the use cases you find to be valid?  Saying
that enterprises don't value security and privacy is really not terribly
useful to resolving any discussion.


> Isn't it the core of the discussion though?

I think the core of the discussion is that no matter how many times I say
that enterprises are trying to protect their customers, you do not consider
that a valid use case.

It is not possible to discuss something when the other person does not
think you have a valid point of view.

Nalini



On Wed, Mar 14, 2018 at 4:30 PM, Ryan Sleevi <ryan-ietftls@sleevi.com>;
wrote:

>
>
> On Wed, Mar 14, 2018 at 7:17 PM, nalini elkins <nalini.elkins@e-dco.com>;
> wrote:
>
>>
>>>    - > Nalini, why don't you (the consortium) define the standard, then?
>>>
>>>
>>>
>>> > Indeed, if a “TLS13-visibility” standard has to be defined, it would
>>> make sense for the consortium (rather than the TLS WG) to define it.
>>>
>>>
>>>
>>> I completely disagree.   Here is why I would not prefer that route:
>>>
>>>
>>>
>>> 1.  Multiple standards are likely to diverge.
>>>
>>>
>>> Take the case of India, we have over 700 dialects.  Many of them started
>>> with the same root language.  It has gotten so villages 10 miles apart
>>> cannot talk to each other.  We use English (a clearly non-native language!)
>>> to communicate.
>>>
>>>
>>> I could see the same happening with TLS and Consortium-TLS.   Not a
>>> happy thought for interoperability.
>>>
>>
>> >Why is there any need for interoperability between TLS and
>> Consortium-TLS? TLS is designed to be secure and reliable, and it's clear
>> that Consortium-TLS finds such goals problematic. Yet I fail to see why
>> that's a problem, since the claimed goal >is that Consortium-TLS would only
>> be used within a single enterprise/datacenter, and thus would never need to
>> interoperate with a world that valued security and privacy.
>>
>>
>> Enterprises value security and privacy.   They have a different job to
>> do.  What they are trying to do is to protect against leakage of data, do
>> fraud monitoring, protect against malware and many other things.   When
>> this gets into the medical arena, it can even be lives.  I don't even see
>> how you can say what you are saying.
>>
>> Let me ask you then, what are the use cases you find to be valid?  Saying
>> that enterprises don't value security and privacy is really not terribly
>> useful to resolving any discussion.
>>
>
> Isn't it the core of the discussion though? Whether the enterprise case -
> which understandably and fundamentally weakens the security assurances,
> both to servers and to clients - is justified, given the ecosystem risk it
> poses? And the specific proposals, as demonstrated, have negative impacts
> both in the design and deployment of TLS.
>
> Given that, and given the ample discussion on-list motivating PFS, and
> given the stated reasoning, it doesn't seem that "inter-protocol
> interoperability" is necessary nor desirable. It's true that enterprises
> don't value the same security and privacy properties that have been
> discussed on the list - we wouldn't be having this discussion if that was
> not the case. This isn't unproductive or not useful - this is based on the
> statements from those advocating for the weakening of security of the
> protocol.
>
> As such, the need for interoperability is not a goal that's supported by
> the discussion to date, and thus the concerns - that TLS and consortium-TLS
> would diverge - does not seem supported by the arguments. So I do hope you
> can answer - why is interoperability between TLS and Consortium-TLS
> necessary, given that the use cases to date of Consortium-TLS state they'll
> be limited to the enterprise or datacenter, for which the only
> interoperability concerns that arise are between devices supporting
> Consortium-TLS, which by speccing in a Consortium as suggested, you could
> resolve?
>
>


-- 
Thanks,
Nalini Elkins
President
Enterprise Data Center Operators
www.e-dco.com