Re: [TLS] ETSI releases standards for enterprise security and data centre management

Sean Turner <sean@sn3rd.com> Fri, 07 December 2018 22:49 UTC

Return-Path: <sean@sn3rd.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 033F5131029 for <tls@ietfa.amsl.com>; Fri, 7 Dec 2018 14:49:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 rJKhbI9lrqp5 for <tls@ietfa.amsl.com>; Fri, 7 Dec 2018 14:49:00 -0800 (PST)
Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com [IPv6:2607:f8b0:4864:20::72c]) (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 42765130F19 for <tls@ietf.org>; Fri, 7 Dec 2018 14:49:00 -0800 (PST)
Received: by mail-qk1-x72c.google.com with SMTP id 189so3383858qkj.8 for <tls@ietf.org>; Fri, 07 Dec 2018 14:49:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=alQHTJONohRr/GTuu2ZoFYVLU7PjnJ40N9EGoRJfv6g=; b=aSogsxF13x7EAwh3U/fG+mhuXYGu8VQuvHW71phm5WmV3xvZJOsmL+tubDANhQHBcD Wt0Q7Gm7WrUQtOcnj4tZb1Ru8fo93E4UB3arENgts2HkHyE1Y5GqPUuozNgI6ZtBHXpm eNwyRPqbeFxdZU7ip7cWEc4J4dly9y0gX0FWc=
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=alQHTJONohRr/GTuu2ZoFYVLU7PjnJ40N9EGoRJfv6g=; b=ddAfaoqAp8qUyn+DDD5MZe/1hE3cnKZ6/DZpfKQn01t9P3qLPmLAWcZByFr2u/F8GX sJzNTSpC9+e46KchxHjZlHxn9sjkdMLGt7pEI2BKa74T+greU879X1Zp+DYOoAezwOJ9 2sZjpp9fAsgYe1um8OAVfbknXDXp7jYCBO1zECwn9w+FHof07+kazeEQ3xrhpo/yMblp ySvCODEqtb/jCjnT1LdHbTg1oDkCknDYDnvA0qlwXeVPXc9CrCh5L6IxZxQ6YD2BNCyo NwL/qcsj6ncjkyVloGfJqNGyY8Z9AZgbGYsOaVIq7ahBTu6UNmv0newMI55BHeEYpPXK WmKg==
X-Gm-Message-State: AA+aEWZ2uGErHWcQezqMuh9hIZm5EF2uqmNhr+9RzMol41ihFKFEn6Pe 4zz5wvTV0SyhMzovytRzG1PeFbSUz28=
X-Google-Smtp-Source: AFSGD/X4di9Na+EcioCTDT5STpT+H50VB1eo0BTYJT+FDZqal7MrLVzQTvNuUocH/5vwV+pTCnzf7A==
X-Received: by 2002:a37:a44e:: with SMTP id n75mr3631248qke.244.1544222939098; Fri, 07 Dec 2018 14:48:59 -0800 (PST)
Received: from [172.16.0.18] ([96.231.218.194]) by smtp.gmail.com with ESMTPSA id y12sm4518084qta.13.2018.12.07.14.48.58 for <tls@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Dec 2018 14:48:58 -0800 (PST)
From: Sean Turner <sean@sn3rd.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Date: Fri, 07 Dec 2018 17:48:57 -0500
References: <CADqLbzKd-AgDRv2suZ-0Nz4jNUqKg0RNT8sgQd-n793t+gEN3g@mail.gmail.com> <CAHOTMVKZT1ScvHeP3=Kv2zodVimHkaAtG-2DTq6ojnF+q-OMSQ@mail.gmail.com> <20181202233553.GD15561@localhost> <CAHOTMV+vPkM-=Qsto-8-ipFuGsNKkH_U=BEY_mB=7CM7tto3Mw@mail.gmail.com> <38D10A65-B4EE-4E81-8EA4-D69514F7F47B@gmail.com> <51754d91-c00c-0cad-ecd6-8db74544d26a@cs.tcd.ie> <A7423BAF-398B-4BBE-81AC-364CE748D6B1@gmail.com> <9344c0e1-f484-2b4b-8594-1d29731f6b7a@cs.tcd.ie> <01429BF7-BF1D-4F1C-9E18-D796A5585E62@gmail.com> <87o9a0dubn.fsf@fifthhorseman.net> <fvfVqv2EkdRrbfymEtYZoShBrSZNu9raK-hYp8b72xwFXkXl-AxaI8Lvz-LVcysyWMr2-DgnK9e0QA107qb934xzt1_cBWigd2qbiYvQWpk=@protonmail.com>
To: "tls@ietf.org" <tls@ietf.org>
In-Reply-To: <fvfVqv2EkdRrbfymEtYZoShBrSZNu9raK-hYp8b72xwFXkXl-AxaI8Lvz-LVcysyWMr2-DgnK9e0QA107qb934xzt1_cBWigd2qbiYvQWpk=@protonmail.com>
Message-Id: <61BFBD99-8178-4B06-8E23-5F2D18702D37@sn3rd.com>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/ZAxdLmf_CZNKtHdWyzr-fsWGSh4>
Subject: Re: [TLS] ETSI releases standards for enterprise security and data centre management
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
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: Fri, 07 Dec 2018 22:49:11 -0000

There is no WG consensus to adopt this draft as no WG adoption call has been made.  draft-dkg-tls-reject-static-dh is an individual draft that is currently being discussed on this list; in much the same way draft-green-tls-static-dh-in-tls13 and draft-rhrd-tls-tls13-visibility were individual drafts that were discussed on this list; there was no WG consensus to adopt draft-rhrd-tls-tls13-visibility and there was never a call to adopt draft-green-tls-static-dh-in-tls13.  

The chairs have been debating whether draft-dkg-tls-reject-static-dh is in scope or whether the discussion should be moved elsewhere.  Parts of this draft we believe are in scope, e.g., providing guidance on handling key share re-use and pitfalls for not following this guidance.  (Note that how to handle key share re-use is not the same thing as explicitly prohibiting re-use of keys.)  Other parts of the draft contain material for which we did not reach consensus to address, such as Section 3.3 on prohibiting key-share reuse.  We are not the protocol police and have recently gotten out of that business, e.g., by removing barriers for cipher suite code points. We do not want to get back in that business.

In order to ensure a focused discussion and avoid rehashing the previous debate regarding draft-rhrd-tls-tls13-visibility, parts of this draft should be rescoped or removed.  Authors are free to take this material to an AD and seek sponsorship, or to the ISE/IAB for further guidance.

Cheers,
Joe, Chris, and Sean

> On Dec 6, 2018, at 21:19, Arnaud.Taddei.IETF <Arnaud.Taddei.IETF=40protonmail.com@dmarc.ietf.org> wrote:
> 
> I am really surprised how the answers you don't like are systematically put on denial. Can you explain me what leads you to think that some people here are not concerned by the list of people you list? this is an assumption and the wrong assumption.
> 
> Perhaps on the contrary we are concerned BOTH by what these people endure but too by what other consistencies are basically removed rights to defend themselves.
> 
> As to the marketing aspect frankly this is an invention here and again I don't see what allows you to paint the answers you don't like because you don't like.
> 
> So I could on the contrary hightight the dogmatism that reins here, with a smell of intimidation, and to some degree the sectarianism back to the latin roots of the word
> 
> Regarding Human Rights, we DO care about Human Rights too and fact is that I had the chance to make more progress in 2 hours than I did in 2 years at IET and I had the chance to contribute to a magic moment with a Chinese Organization to comply a technical solution to Human Rights requirements. You know why? Because we took the time to TALK properly to each other, understand each other, learn from each other with no intimidation and no wrong assumptions that 'because we LOOK to be on the wrong side' we are foolish people, and respect to the fact that not everyone speaks and writes a proper English and sometimes words are dangerous when we don't know exactly the semantics in the right context
> 
> The assumption that you are the only one who cares is tiresome.
> 
> This group was offered a chance to control the development of a 360 degree solution for all parties and it was rejected. Fine. The ETSI took it and is taking its responsibly.
> 
> I don't know what leads you to think that a model where security resides only on the 2 ends of the communication IS the answer to all the problems.
> 
> The recent continuous scandals that are affecting a number of platforms and destroying trust, privacy and security is leading me to think about why should I trust this model. By analogy when I see how my body defends itself against bad stuff, it is using a battery of models, not one model.
> 
> In any negotiation you can look for what is the right battle, and those who understand that point will know that the right battle (and the one which is harder for the opposition) is on providing guarantees. This would have been a better battle to pick and would have given a chance to work more collaboratively and not by confrontation.
> 
> Now I don't understand what leads this group to try now to block the ETSI, can someone tell me and in particular the chairs if we have a consensus here?
> 
> Finally I am calling on the chairs of this group. It was very interesting to observe the many comments at the last IETF103 about the vile and toxic atmosphere that prevails here. I have all my time to work in these conditions but perhaps the chair could try to think about a more positive atmosphere of work.
> 
> A bon entendeur salut
> 
> 
> 
> Sent with ProtonMail Secure Email.
> 
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Wednesday 5 December 2018 21:36, Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote:
> 
>> On Wed 2018-12-05 20:15:08 +0900, Bret Jordan wrote:
>> 
>>>> On Dec 5, 2018, at 7:33 PM, Stephen Farrell stephen.farrell@cs.tcd.ie wrote:
>>>> 
>>>>> On 05/12/2018 10:22, Bret Jordan wrote:
>>>>> I think we should be more open minded and look at the needs from a
>>>>> 360 degree deployment perspective.
>>>> 
>>>> I think we should avoid marketing speak.
>>> 
>>> This is not marketing speak. This is understanding how these solutions
>>> need to be deployed end to end in all of their scenarios from
>>> consumer, to small business, to enterprise, to service provider, to
>>> content provider, to telco, etc.
>> 
>> Perhaps one of the reasons that this might across as marketing speak to
>> some people is that your list of "all their scenarios" appears to be
>> only business use cases (where the individual people involved are at
>> most consumers of business products). You haven't mentioned
>> journalists, disk jockeys, activists, flat earthers, dissidents,
>> students, medical professionals, juggalos, community organizers, gun
>> nuts, cryptozoologists, whistleblowers, LGBTQ folx, refugees, free
>> software developers, elected officials, religious minorities, senior
>> citizens, or any of the other non-business use cases that may depend on
>> TLS for confidentiality, integrity, authenticity, or any of the other
>> information security guarantees that are put at risk by proposals like
>> this.
>> 
>> One of the concerns the last time we danced this dance was that the
>> proposal claimed to be interested in one use case only: "the enterprise
>> data center", and yet offered no meaningful way to effectively limit its
>> (ab)use outside the data center. This objection was raised clearly, and
>> the proponents of the protocol change failed to address it. And now it
>> appears that instead of addressing the concern, they forum-shopped until
>> they found a place to publish the same approach without even
>> acknowledging the concern that this could have an impact beyond the data
>> center.
>> 
>> A full 360 degree view might acknowledge that doing harm to the core
>> priniciples of a security protocol that everyone relies on for the sake
>> of one particular use case out of many might not be an appropriate step
>> to take. (and that one use case might have other solutions, albeit
>> perhaps more expensive or inconveient ones for people who have already
>> made certain investments)
>> 
>> I'm pretty sure we don't want TLS to be all things to all people, right?
>> What are the core goals or guarantees of TLS that you would like to see
>> preserved?
>> 
>> --dkg
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls