Re: [TLS] TLS@IETF101 Agenda Posted

Ryan Sleevi <ryan-ietftls@sleevi.com> Wed, 14 March 2018 23:30 UTC

Return-Path: <ryan-ietftls@sleevi.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 EC516126CF6 for <tls@ietfa.amsl.com>; Wed, 14 Mar 2018 16:30:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.01
X-Spam-Level: *
X-Spam-Status: No, score=1.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_BL=0.01, RCVD_IN_MSPIKE_L4=2.999] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sleevi.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 OfUwzo1JTNgT for <tls@ietfa.amsl.com>; Wed, 14 Mar 2018 16:30:50 -0700 (PDT)
Received: from homiemail-a31.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EE00124D68 for <tls@ietf.org>; Wed, 14 Mar 2018 16:30:50 -0700 (PDT)
Received: from homiemail-a31.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTP id 5A2661406B3C for <tls@ietf.org>; Wed, 14 Mar 2018 16:30:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; s=sleevi.com; bh=UG4rvAqQ5sY7ADZk8stlKqYRmeo=; b= Up0kpXiz6wjVOWxiZzT2Inek8QrgrfIrf2Ptftw1uznqX7em9cIqumA0+9DgD0rn C5tczZP8DHmRCuwL+tV/IZFSENPPeKhMdxFtO1RLcfmuHfbEHoZhKgPsGBbNJZvG wU2QWy2lYn5f2XdOdyitvn0lMwoWNAXnhdpsf4OILGo=
Received: from mail-it0-f41.google.com (mail-it0-f41.google.com [209.85.214.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: ryan@sleevi.com) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTPSA id 2DEA41406B2F for <tls@ietf.org>; Wed, 14 Mar 2018 16:30:49 -0700 (PDT)
Received: by mail-it0-f41.google.com with SMTP id d13-v6so6759911itf.0 for <tls@ietf.org>; Wed, 14 Mar 2018 16:30:49 -0700 (PDT)
X-Gm-Message-State: AElRT7Ea5u3Y4ntHip4KRvK66wtBHjgJ6F6exLG60LZHoOATfsfQbnV6 zafa1VWijJhOaHFJI8jzhTWMWDKnGHxZ8lvOBFA=
X-Google-Smtp-Source: AG47ELvz5op+TJQCnj9s/+9J4dO6GwuRvk2a9SDof5wUF6qch0ik+QNeMTG06+12Or9WaOINcvl7g5J/d2JQbsCo5bw=
X-Received: by 10.36.148.204 with SMTP id j195mr4042984ite.1.1521070248395; Wed, 14 Mar 2018 16:30:48 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.2.152.80 with HTTP; Wed, 14 Mar 2018 16:30:47 -0700 (PDT)
In-Reply-To: <CAPsNn2W-z+wQGra=LuVGM961j65OjetR91hT-JQh4sjzAuSuvw@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>
From: Ryan Sleevi <ryan-ietftls@sleevi.com>
Date: Wed, 14 Mar 2018 19:30:47 -0400
X-Gmail-Original-Message-ID: <CAErg=HHnohEzi9OZViWM30p-P2dEGBtw+r5UWEtM7AFnXrVx6g@mail.gmail.com>
Message-ID: <CAErg=HHnohEzi9OZViWM30p-P2dEGBtw+r5UWEtM7AFnXrVx6g@mail.gmail.com>
To: nalini elkins <nalini.elkins@e-dco.com>
Cc: Ryan Sleevi <ryan-ietftls@sleevi.com>, Andrei Popov <Andrei.Popov@microsoft.com>, "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c0efbbad58bd2056767c35c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/3sj8YUuO5HIQN5fQJ6lCBq_59Ws>
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:30:52 -0000

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?