Re: [TLS] TLS@IETF101 Agenda Posted

nalini elkins <nalini.elkins@e-dco.com> Wed, 14 March 2018 23:17 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 BC6E7126DD9 for <tls@ietfa.amsl.com>; Wed, 14 Mar 2018 16:17:07 -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 u5u5V91XNeJP for <tls@ietfa.amsl.com>; Wed, 14 Mar 2018 16:17:05 -0700 (PDT)
Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (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 81C9D128896 for <tls@ietf.org>; Wed, 14 Mar 2018 16:17:05 -0700 (PDT)
Received: by mail-it0-x236.google.com with SMTP id e98-v6so1559974itd.4 for <tls@ietf.org>; Wed, 14 Mar 2018 16:17:05 -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=R+V9v/tDPEo0qtQ7kZQHZzT3stsQtV4M+Z2Y5RcSb4w=; b=lroFN0EhBqAYUTmURq1SclVZer8DJ1XrjUDcLO4HeKygk0ZrIa3oGATcPxjAupjmcx s1QW1VkRiVFuzfxlsWbRgPRsyOko2TzyfhQhRJ4com+/K2NnydVXhc6k7q3pmBHu8c3O S58i+VLA6MPVXfIeli3W5iuVAECW32vqBXzU9WoAMBFyj1luVNn0TD1ZAjeOi42aK7AB JuZ9vpGBe9HNbJE1msaXapfoki1LsgkWjJCJejhJbOM+GNNsxQQZKhd8F3gMR4sjgjaq 8ZIdqPeHM2Z52rC21UlaDrlGqrUTMXM9iyLjlA95j4TsYBEPHr871nCxK5cyaTk7iJP5 ytVA==
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=R+V9v/tDPEo0qtQ7kZQHZzT3stsQtV4M+Z2Y5RcSb4w=; b=CBZUTx76oBZc4SiWxx2d2gykmYRYgqtxBdGOO2gZUZfqYrwBfS8e9xi0mqPECLfL/+ OY7G8wY85Yf0EFrV6SgjZ9yJIb2gxqdex0DciOQKfvn2rqAK/V7xZ14Yz8ldOsapMTPI 0UwpkXEHrLdoIQeJ2O400SkY7yXEC7OUPS6JodSjBO+65ieV2Fwq/2smCHLfZMPJqKRu l24UTRCaRNmdBdtNZV4R+OxMfmWSqk4nD5KLVecDTtsCvjgw5JRZhiOqc3x1V3wf5PWi d6HFwczdhFjw4Z9DzmTqQHqqHc/eLhPEgAOYl7Pk3/+w4HTzE+SDpm7xABM8d27CyCyg jWOg==
X-Gm-Message-State: AElRT7GH+ukgzNBXQ5Ywt2Q4TwtKA8mD00WcovlDnFLc5rsC4WJ8Mps2 Tuc9zOCTmTTUBNBz8bFx6BTUcHjaxltscb4Q4Tv8ZA==
X-Google-Smtp-Source: AG47ELs/bEVtRVK8xq8kOj0LnmJVyZkBUBVqbRqXv8Ub9KeTPlXu5fwiuYP8VVV9g/3hvrNyzceyS6ITSo1yHanH+UU=
X-Received: by 10.36.2.200 with SMTP id 191mr4072353itu.108.1521069424746; Wed, 14 Mar 2018 16:17:04 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.2.29.138 with HTTP; Wed, 14 Mar 2018 16:17:04 -0700 (PDT)
In-Reply-To: <CAErg=HEfR27g6YqiaWXs7nY8fc=FNXq0r8v6aXsNs_hXUjd9TQ@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>
From: nalini elkins <nalini.elkins@e-dco.com>
Date: Wed, 14 Mar 2018 16:17:04 -0700
Message-ID: <CAPsNn2W-z+wQGra=LuVGM961j65OjetR91hT-JQh4sjzAuSuvw@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="001a11446d98bdbde00567679282"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/CWVl8sBsjqu58xfgOXKoCza0HC4>
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:17:08 -0000

>
>
>    - > 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.

Nalini







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

>
>
> On Wed, Mar 14, 2018 at 6:52 PM, nalini elkins <nalini.elkins@e-dco.com>;
> wrote:
>
>>
>> All,
>>
>> In London now & back on email:
>>
>>
>>    - >> 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.
>



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