IETF Logo Mail Archive

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

"Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu> Sun, 02 December 2018 16:39 UTC

Return-Path: <prvs=587480f1f3=uri@ll.mit.edu>
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 CE377130DF5 for <tls@ietfa.amsl.com>; Sun, 2 Dec 2018 08:39:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level:
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 Cv4ct84u9Llg for <tls@ietfa.amsl.com>; Sun, 2 Dec 2018 08:38:59 -0800 (PST)
Received: from llmx3.ll.mit.edu (LLMX3.LL.MIT.EDU [129.55.12.49]) by ietfa.amsl.com (Postfix) with ESMTP id B17E412426A for <tls@ietf.org>; Sun, 2 Dec 2018 08:38:59 -0800 (PST)
Received: from LLE2K16-MBX01.mitll.ad.local (LLE2K16-MBX01.mitll.ad.local) by llmx3.ll.mit.edu (unknown) with ESMTP id wB2GcsHY031376; Sun, 2 Dec 2018 11:38:54 -0500
From: "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>
To: Christian Huitema <huitema@huitema.net>
CC: "trutkowski@netmagic.com" <trutkowski@netmagic.com>, "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] ETSI releases standards for enterprise security and data centre management
Thread-Index: AQHUiVXKOcVsIDkH4E2hlVUSAK/jpaVqXueAgAADZQCAABQ7AIAACr0AgAAtG2CAAU3KgA==
Date: Sun, 02 Dec 2018 16:38:53 +0000
Message-ID: <503B95CD-1ABF-4433-BDB1-F9BE931F8D05@ll.mit.edu>
References: <CADqLbzKd-AgDRv2suZ-0Nz4jNUqKg0RNT8sgQd-n793t+gEN3g@mail.gmail.com> <CAHOTMVKZT1ScvHeP3=Kv2zodVimHkaAtG-2DTq6ojnF+q-OMSQ@mail.gmail.com> <CADqLbzL16cnm-WQXj4bh9awOp6Qqnu21cQd3T9XxpVhHse8yoQ@mail.gmail.com> <CAHOTMV+ppxTmNaBdTOEkXzX_LWWcE=RMu4sxN3CsHTEga_8M2Q@mail.gmail.com> <7de09a4c-4ba9-d4ac-3371-89af3294f424@huitema.net> <da41ea97-a24a-1148-046a-f81b6c6ce229@netmagic.com> <d9e7a5d7-ed82-f9af-5aa5-7397d0438f7d@huitema.net>
In-Reply-To: <d9e7a5d7-ed82-f9af-5aa5-7397d0438f7d@huitema.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
Content-Type: multipart/signed; boundary="Apple-Mail-C2289A6E-F270-4FC6-BE12-FD905BA18C92"; protocol="application/pkcs7-signature"; micalg="sha1"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-12-02_11:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1812020159
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/-3676Sy58UZaTdUQjGU0psbTEoc>
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: Sun, 02 Dec 2018 16:39:02 -0000

Exactly. I for one am against such "enhancements" and agree that treating them as errors is the right way.

Regards,
Uri

Sent from my iPhone

> On Dec 1, 2018, at 20:44, Christian Huitema <huitema@huitema.net> wrote:
> 
> 
>> On 12/1/2018 11:14 AM, Tony Rutkowski wrote:
>> 
>> The eTLS use case is an enterprise network or data center that is
>> owned or dedicated and under the control of a company (e.g., a
>> financial institution) or government agency that is subject to
>> compliance obligations that require auditing and traffic monitoring
>> capabilities for their systems and users.  This relatively bounded use
>> case should be kept in mind here.  The associated tutorial is
>> helpful. 
>> https://www.etsi.org/news-events/events/1338-2018-10-webinar-middlebox-security-protocol-explained
>> 
> 
> Which reinforces the idea that these "enhancements" have no legitimate
> reason to be found "in the wild", and hence should be treated as errors
> when detected.
> 
> -- Christian Huitema
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

v2.23.0 | Report a Bug | By Email