Re: [TLS] TLS@IETF101 Agenda Posted

nalini elkins <nalini.elkins@e-dco.com> Tue, 13 March 2018 15:58 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 4EA32127419 for <tls@ietfa.amsl.com>; Tue, 13 Mar 2018 08:58:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.338
X-Spam-Level:
X-Spam-Status: No, score=-2.338 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] 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 AlBL59qt5caZ for <tls@ietfa.amsl.com>; Tue, 13 Mar 2018 08:58:47 -0700 (PDT)
Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (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 1852F126DC2 for <tls@ietf.org>; Tue, 13 Mar 2018 08:58:47 -0700 (PDT)
Received: by mail-it0-x22e.google.com with SMTP id u66-v6so745998ith.1 for <tls@ietf.org>; Tue, 13 Mar 2018 08:58:47 -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=CKPUY5ilOXXt0/mpmft3VVO/iYhwDN4JGjr6IHKaYGw=; b=OP/UcGDx7iuLZOD1vhsB8PxsGkSvWnaTaVCuaz8TKaLi31zvCtgxXxxM3/p0HEbhPw y78nu67hqiu7zXlgZ/CZlhHkEAv0pu+g/AAbOfd09HPHLek2dmDs8j5ldUdNm35+WnkQ jcwCCQvIEtf8lL/7RBJpykFFmEvWFgoEGHVd+tPraGg/FrmK/ynyvMa8oXyEmMp+Ff3y Qr7gBhypUcX4kHIvqma6Lu2p6UJmIwIaOPdhuVPitX59GnG4tYB55B6wSfITI/RlBUfG C9RotK9D2/uIrHTc9ldlqJYgbEyk25ugXsWT2dqXZeR6ajEvdjpPJMxEmYIvpLm42pCg i/jA==
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=CKPUY5ilOXXt0/mpmft3VVO/iYhwDN4JGjr6IHKaYGw=; b=bvhMC5kJEFZ0Wf8Va84WEtpex+rCyDAS9v91PgOGLH/mbUyK9U80s2YxvaIAQR2xXE 4Y/viDGnVPKd78qa/0O96Xy+QyizxQQhSpGhkBezhF12fMCBsgot0wMF/DgOwEEoQacs YZiPNd14JvjgpAu6FlDac0+XsdNP0z35UIBbV1GpIiGszYGdovyyqHm/JaPm6lCr1+fM r0vBLMPaAeZPka/xqi0MaYHEfixjA9Nl2nDyeT8lJD0M3HT++nNl9LNNyOLto2KA+3cb haXb0foIaMZO6C/3hlY1k/WskrdhADspnYd/SgAU7lds7fg63iXl7pEHvz7MJmU7wcg1 RlxA==
X-Gm-Message-State: AElRT7GL/18UNqaPqleeRNTC1p2tlTo6Y4c/y8zLajIpwQ5EhHg0BuNY 1OFlaKa/F9PI9BleCH7paGLx1rCkeRDFWFk773Oclg==
X-Google-Smtp-Source: AG47ELvZn2HPOZnUEJOFrxQiT4rmNVFuWYEYVrMWN0QN9JHoJKxa3JNgjCh04Vi+WZegeZGnFSDzNZtyrjvnYVlOpYw=
X-Received: by 10.36.211.86 with SMTP id n83mr254449itg.23.1520956726234; Tue, 13 Mar 2018 08:58:46 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.2.29.138 with HTTP; Tue, 13 Mar 2018 08:58:45 -0700 (PDT)
In-Reply-To: <CAAF6GDcaG7nousyQ6wotEg4dW8PFuXi=riH2702eZZn2fwfLQw@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>
From: nalini elkins <nalini.elkins@e-dco.com>
Date: Tue, 13 Mar 2018 08:58:45 -0700
Message-ID: <CAPsNn2XCNtqZaQM6Bg8uoMZRJE+qQakEwvw8Cn9fBm-5H+Xn_A@mail.gmail.com>
To: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= <colm@allcosts.net>
Cc: Stephen Farrell <stephen.farrell@cs.tcd.ie>, "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="001a11479e5e62e17e05674d551e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/znmZEHWeCdmk4Phg2Ty3qUCqTk4>
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: Tue, 13 Mar 2018 15:58:51 -0000

Stephen (and TLS group)

We need to look at the bigger picture.

The TLS working group has been concentrating on making the Internet secure
for the individual user.    We feel that there is also an underlying
motivation to help the underdog and protect the political dissident.  These
are all laudable goals.

But, the Internet is much more than that.  The Internet is the
underpinnings of much of the business community which is utilized by
consumers (end users).   Making a change which makes businesses less secure
because crucial functions cannot be done will lead to enormous chaos and
disruption.   Many businesses are likely to not want to adopt TLS1.3 or
seek unique DIY type alternatives.  In fact, we have already heard of some
planning to block TLS 1.3 traffic just for this reason.  So, the main thing
to acknowledge is that the enterprise use case is different than the
Internet use case.  As such, it needs its own solution.  Please note that
the endpoint is the intended recipient of the session and the owner and
responsible party for the security of the data.

The presentation in London is to present a use case solution – along with
TLS WG recommendations/updates from Prague where half of the room hummed
that an internal solution is needed.

This rift is not good for the TLS Working Group, it is not good for the
IETF, it is not good for the business community and it is not good for the
Internet.  We need to have some type of methodology so that we can continue
to protect ourselves.  Therefore, we are asking for WG help with a solution
to the enterprise use case.

This ID helps explain the situation and subsequent need.  If you haven’t
had a chance to read it yet, please try to do it before the London meeting.
https://datatracker.ietf.org/doc/draft-fenter-tls-decryption/

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


On Tue, Mar 13, 2018 at 8:06 AM, Colm MacCárthaigh <colm@allcosts.net>;
wrote:

>
> It's my fault for the ambiguous wording, but in this context the quote
> from me reads as the opposite of my intent.  To be more clear: what I meant
> was that while the proposals aren't making much progress, I don't mind that
> it's being discussed.
>
> I'm happy to have mailing list threads on the topic and agenda time
> devoted to it (I don't go in person, but I do watch the videos). Since it's
> an area of such disagreement, I'd prefer to see /more/ discussion, not
> less. There's always hope of movement and progress on either side, and I
> think good discourse lessens the risk of dozens of fragmentary DIY
> solutions, which I think will be the worst kind of outcome of
> non-engagement.
>
> On Tue, Mar 13, 2018 at 10:21 AM, Stephen Farrell <
> stephen.farrell@cs.tcd.ie>; wrote:
>
>>
>> Hiya,
>>
>> Just to be clear: I'm still waiting for the chairs and/or
>> AD to explain how the proposed discussion of this draft
>> is consistent with IETF processes, given the results of
>> the discussion in Prague (a very clear lack of consensus
>> to even work on this topic), and the discussion of the
>> -00 version of this late last year. IOW, I don't consider
>> my objection has been answered.
>>
>> In case people haven't got all the mails from last year
>> at the front of their minds, I went through them for you
>> and have provided links and selected quotes below. Yes,
>> the quotes are selected but I think do indicate that the
>> opposition to these ideas is as before. And there were
>> also the usual voices in support of weakening TLS in this
>> manner as well - a read of the thread clearly indicates
>> to me that discussion of this draft in London will, as
>> before, be a divisive waste of time and energy.
>>
>> Chairs: Please drop the agenda item, or explain how any
>> of this fits our process, because I'm just not getting
>> it.
>>
>> Thanks,
>> Stephen.
>>
>>
>> me, "IMO the WG shouldn't touch this terrible proposal with a
>> bargepole."
>>
>>         https://www.ietf.org/mail-archive/web/tls/current/msg24493.html
>>
>> Randy Bush: "there are a lot of us lurkers out here a bit horrified
>> watching this wg go off the rails." (Different thread, but same topic)
>>
>>         https://www.ietf.org/mail-archive/web/tls/current/msg24539.html
>>
>> Uri Blumenthal: "+1 to Stephen"
>>
>>         https://www.ietf.org/mail-archive/web/tls/current/msg24542.html
>>
>> Rich Salz: "put this on hold for a year or two after TLS 1.3 is done"
>>
>>         https://www.ietf.org/mail-archive/web/tls/current/msg24544.html
>>
>> Ion Larranaga Azcue, "I really don't feel confortable with the approach
>> taken in this draft."
>>
>>         https://www.ietf.org/mail-archive/web/tls/current/msg24562.html
>>
>> Hubert Kario: "to be clear: me too" (replying about hating the idea)
>>
>>         https://www.ietf.org/mail-archive/web/tls/current/msg24578.html
>>
>> Rich Salz: "I am opposed to the basic concept of injecting a third-party
>> into the E2E TLS process."
>>
>>         https://www.ietf.org/mail-archive/web/tls/current/msg24585.html
>>
>> Florian Weimer: "I don't understand why this complicated approach is
>> needed."
>>
>>         https://www.ietf.org/mail-archive/web/tls/current/msg24607.html
>>
>> Ben Kaduk: "I do not see any potential for a workable solution."
>>
>>         https://www.ietf.org/mail-archive/web/tls/current/msg24620.html
>>
>> Uri Blumenthal: "why do we spend time discussing this draft?"
>>
>>         https://www.ietf.org/mail-archive/web/tls/current/msg24639.html
>>
>> Christian Huitema: "Maybe they have found ways to manage their
>> applications and servers without breaking TLS..."
>>
>>         https://www.ietf.org/mail-archive/web/tls/current/msg24643.html
>>
>> Ted Lemon: "I think we should stop."
>>
>>         https://www.ietf.org/mail-archive/web/tls/current/msg24649.html
>>
>> Andrei Popov: "deploying a weakened configuration of TLS 1.3 (without
>> PFS) would not meet the intent of those future mandates/requirements."
>> (On "industry need")
>>
>>         https://www.ietf.org/mail-archive/web/tls/current/msg24656.html
>>
>> Ben Kaduk: "The time I am spending on this thread is time that I am not
>> able to spend improving the TLS 1.3 document."
>>
>>         https://www.ietf.org/mail-archive/web/tls/current/msg24660.html
>>
>> Dave Garrett: "Please, let's just let this mess die. "
>>
>>         https://www.ietf.org/mail-archive/web/tls/current/msg24667.html
>>
>> Uri Blumenthal "I'm against weakening the protocol, since there are
>> other ways to accomplish the perlustrator's mission"
>>
>>         https://www.ietf.org/mail-archive/web/tls/current/msg24670.html
>>         Yeah, I had to look it up too:-)
>>         https://en.oxforddictionaries.com/definition/us/perlustrator
>>
>> Adam Caudill: "To be honest, I’m rather surprised that this group
>> continues to spend time on this."
>>
>>         https://www.ietf.org/mail-archive/web/tls/current/msg24712.html
>>
>> Tony Arcieri, "Having worked (and presently working) for more than one
>> company of this nature, in the payments business no less, I would like
>> to restate that it's incredibly disingenuous to cite the need for
>> self-MitM capability as an "industry" concern."
>>
>>         https://www.ietf.org/mail-archive/web/tls/current/msg24715.html
>>
>> Colm MacCárthaigh: "I don't have too strong an interest in this thread,
>> it's not going anywhere, and I don't mind that."
>>
>>         https://www.ietf.org/mail-archive/web/tls/current/msg24720.html
>>
>> Peter Saint-Andre: "+1 to Stephen's request." (for chairs to close down
>> the discussion)
>>
>>         https://www.ietf.org/mail-archive/web/tls/current/msg24734.html
>>
>> Cas Cremers: " I think such a mechanism should not be part of the TLS
>> 1.3 standard."
>>
>>         https://www.ietf.org/mail-archive/web/tls/current/msg24885.html
>>
>> Karthikeyan Bhargavan: "I really don’t recommend any change to the TLS
>> 1.3 design to accomplish any of this"
>>
>>         https://www.ietf.org/mail-archive/web/tls/current/msg24903.html
>>
>>
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>>
>
>
> --
> Colm
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>


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