Re: [TLS] TLS@IETF101 Agenda Posted

Ted Lemon <mellon@fugue.com> Thu, 15 March 2018 10:21 UTC

Return-Path: <mellon@fugue.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 48566126CB6 for <tls@ietfa.amsl.com>; Thu, 15 Mar 2018 03:21:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-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 SZP8Kx7M--xi for <tls@ietfa.amsl.com>; Thu, 15 Mar 2018 03:21:11 -0700 (PDT)
Received: from mail-ot0-x22d.google.com (mail-ot0-x22d.google.com [IPv6:2607:f8b0:4003:c0f::22d]) (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 3E676126BF7 for <tls@ietf.org>; Thu, 15 Mar 2018 03:21:11 -0700 (PDT)
Received: by mail-ot0-x22d.google.com with SMTP id 79-v6so6283607oth.11 for <tls@ietf.org>; Thu, 15 Mar 2018 03:21:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=ujUKcliTEYtuHfZLRr0DCKeh1ls2zcCg5h29cpUHo6k=; b=1kJIqcIQ1VmXTtKgJxbcjrJUAQf29c/sNrVf20qDY/lnh8rSHAWKfOUYqpCPltoyJZ /HiglM6Q0sQM4a3WF3MPMSDwCaBWhhCBt5ZNWYpvABSHVieydK/El0xugUFpOgbRybuP 8TpacfEtk8Qm0Gi/pkZ4vw5nRM9EkqRiKNvGGmPkGFCANigGYXBBtYPtS1D8s9LHQwtm BMbN9CmemCxhXLmppxmY8A5g1M6Q40SGAEafGfdiNiVpx/xyvN4eHGCeWWehseKFjl1U Pf2BHEh63LtnbrBzOb2+Rr9MZHoo2+dC/xov7RZwLEQroIyuU/8HKrPFyg1eROeAKJua ZpfA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=ujUKcliTEYtuHfZLRr0DCKeh1ls2zcCg5h29cpUHo6k=; b=LCuhD3jLoanB9bTmNp+H2qLjpNJA0eM8eVNd4V01UDWfM87mwkAWQsuM9i2UBQGpME SakF4WCf1AXHuZNRJoHq5amkwNfOuRxnhlm/Qh7eP/5vLOIqN3BekDmMgltFfsHUXw/T VR1HArE0UPMgIqrjJpv+qTNR10BzPVQgVUyCZHS6OLwC4iIzy/UIlO9Lm2PF69fkkLj6 AVfjQteh36ZQy2aBTyAXGNbYaVDL4ljIFRDdirjFgul0HBMCWeV70G3D0m5O3eW9Gh5m Teev3ToEKHYNpJYlSBNeVWJbOppyhXCIMPmjnSmbRdGqCeW37IE05FRvdsDG0b+L9Q7h Bt1g==
X-Gm-Message-State: AElRT7GPXyjvLi2DxfN34aCoSv5fCkg+04xtziG9yfjiluJS8Dcdqfme PVM5nWyUq3iddBM/NsksRXHbOzgT3uombA==
X-Google-Smtp-Source: AG47ELuM4fht1wNRHx+gvkbwuMylRc3+en6Z4CgCH7ZpaKnJxEYvpRuqdgFH8AS8rJo+Ml1bNUvDVQ==
X-Received: by 10.157.4.104 with SMTP id 95mr5407042otc.267.1521109270318; Thu, 15 Mar 2018 03:21:10 -0700 (PDT)
Received: from [172.20.0.124] ([12.252.83.114]) by smtp.gmail.com with ESMTPSA id h96sm2686856otb.80.2018.03.15.03.21.06 for <tls@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 15 Mar 2018 03:21:07 -0700 (PDT)
From: Ted Lemon <mellon@fugue.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
Date: Thu, 15 Mar 2018 06:21:03 -0400
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>
To: "<tls@ietf.org>" <tls@ietf.org>
In-Reply-To: <CAPsNn2UyTwe_qs_OpwFy0ikBrjcCuZqww2ZiLkk8MbcqkDvzNg@mail.gmail.com>
Message-Id: <6408B1C1-C80D-4D79-A0E7-6F9F6D1E1CD8@fugue.com>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/BpI92CgIeyERMfvd3rIuVHiDMpo>
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: Thu, 15 Mar 2018 10:21:13 -0000

My responses for today are all in this message, including a response to Ralph.  I'm going to try not to engage on this again until tomorrow.

On Mar 14, 2018, at 6:52 PM, nalini elkins <nalini.elkins@e-dco.com>; wrote:
> 1.  Multiple standards are likely to diverge.

We don't need multiple standards, so this isn't an issue.   What you need is to define the behavior that you need from your TLS implementation to give you the visibility that you want.

> 2.  The TLS WG of the IETF has many of the world's experts in defining such protocols.  The years of collective expertise is remarkable.   We want to work with the TLS group not try to recreate it.

Of course, it would be ideal for you if you could get the TLS working group to do this work for you.

> 3.   The reason I support the enterprises and their voice in TLS is because I am naive enough to actually believe in the IETF.  I believe that technical truth matters.  That it is not actually the Vendor Engineering Task Force.  That is a group of the vendors, by the vendors and for the vendors.   I could see when this whole thing with taking away RSA was happening that correct though it may be, it was going to cause enormous disruption for many, many people in the commercial world.  You may not believe it, but I am actually doing this because I really believe that we need one set of standards that everyone can use.  I want it to be in the TLS WG.  I want the TLS WG to be credible and succeed and I want the IETF to succeed.  I believe that the Internet needs it.

The problem isn't that we don't believe that it will involve significant work for you to secure your customer's data.

> 4.  Again, believe it or not, the TLS WG needs the enterprises.  Of course, this is all my opinion only.   These enterprises are a huge group of users of the IETF protocols and TLS in particular.   The feedback of users is irreplaceable.  Who are we building the protocols for if not the users?  Sure, there are multiple sets, but these are a very large group.  

This is the crux of the question: who are the users whose needs the TLS working group is serving?   Any discussion that doesn't begin by answering this question is going to be non-terminal.   I believe it's your position that the "user" is the large corporation; an alternate view, which appears to be shared by quite a few participants here, is that the user is the end user: the person who, if their data security is compromised, will wind up bearing the cost of that compromise.

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

None of these applications require changes to TLS 1.3.   If you think they do, you need to walk us through your reasoning.  The reason we can say what we are saying is that we understand that none of what you have mentioned here requires that TLS 1.3 be weakened.

> But, it is a very difficult issue.   If I can use a different analogy, if the City of Monterey built a new sewer system and told me that to connect to it, I had to build a new house, I would scream!

That's a great analogy, but we are talking about software, not houses.   There is no technical reason why switching to TLS 1.3 requires you to build a new house.   It does require you to update your software, and there is no doubt a real cost to that.  There may even be software that you will have to stop using.  But any software that you would have to stop using is software you already should not be using, because it's not supported.

> I would not agree with that.  People understand that sometimes they have to pay when there are protocol and other changes.  It is a question of if you could do everything that you needed to do to protect your customers even if you re-built your network from the ground up.

I don't think there's any question that if you rebuilt your network from the ground up, you could use TLS 1.3.   If you think this is not the case, it would help if you could say what precisely stands in the way.

On Mar 14, 2018, at 10:32 PM, Ralph Droms <rdroms.ietf@gmail.com>; wrote:
> And there is a name for this sort of labeling - it's called an "ad hominem attack".  I don't believe anyone is employing "consensus by exhaustion".  Please don't attach unwarranted labels to honest attempts to explain requirements and develop solutions.

Ralph, the problem is not that these attempts to explain requirements are not honest.  It is that until we agree on who we are protecting, talking about requirements doesn't really help: the requirements of people who are not our priority are interesting, but not important.

And because we are discussing requirements before we have agreed as to whether or not it is okay to weaken the security of the protocol, the discussion is non-terminal.   I've just quoted from three of the five long messages Ms. Elkins sent to the mailing list today, for example.

This is a serious problem: the working group cannot afford to debate this point indefinitely when the discussion is non-terminal.   It is not "ad hominem" (an argument about a person) to say that it would be better if the working group chairs were to declare this issue closed.   There is a clear benefit to doing so.