Re: [TLS] Industry Concerns about TLS 1.3

Michał Staruch <m.staruch@cinkciarz.pl> Tue, 27 September 2016 08:37 UTC

Return-Path: <m.staruch@cinkciarz.pl>
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 DD74612B09F for <tls@ietfa.amsl.com>; Tue, 27 Sep 2016 01:37:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cinkciarz.pl
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 4_DZd-pPnpRz for <tls@ietfa.amsl.com>; Tue, 27 Sep 2016 01:37:10 -0700 (PDT)
Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (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 BEC6112B036 for <tls@ietf.org>; Tue, 27 Sep 2016 01:37:09 -0700 (PDT)
Received: by mail-lf0-x234.google.com with SMTP id b71so15135634lfg.0 for <tls@ietf.org>; Tue, 27 Sep 2016 01:37:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cinkciarz.pl; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=gcs2If/2gjMYmRoHQGHNBSJShOmzRzrBhZ/zggucwOM=; b=BcWOTVaC0Q3OBb6lrnjEHQ0KQ8Ipj4fXgFmCOnmWxdQlr89xk/XfWIGR2JgA002c7X 3Xr+838+uCTyukKD37oQ+1hY0NqhGrfXyIAh8ctdEn3qSFup4nroUMJjlPNx5kvCT1wn d6RUayMSTL1F3T6AISS1L1o9CHD7IDwMC3BSQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=gcs2If/2gjMYmRoHQGHNBSJShOmzRzrBhZ/zggucwOM=; b=mKsrJA1IGSiILCVIYp+cAmHZwcYb6spjO1DH/uZmZZfFlHXA4wpB8Q0fB4DnhMo0sr uZHs7QZBxCupWQbWD5/Z/xK1ZT9WxwWxkHwfYeD289wcTyw8FzzbLP7lLPJpYRWI7MTn 630g/3BMF9koa88CjsUYy+dOxB7/j4LKxrC2HbVLNM8gGPtl4IIEK6feNtQiSoXmTdzI AdlJIFOmJH0vHBABIqK3SeXHuAor6ODh/em8GSp/q89E/DRLf5dVXdhHWRD47iCojsWu nwzoGFqI1u8c8Vr62BmBy0z3phkZWrST3ataPM1wZPJ0t+lLWjWF39b/v6zxihNQR591 ArHw==
X-Gm-Message-State: AE9vXwMHkLvUz0/6y8Q7y4LVpsAC0HcEAxDfTXJ2FXiRLV6tsITHWWTl9kNJ2brDjaTmNy7vWMogv7Vqn+XmyA==
X-Received: by 10.25.41.142 with SMTP id p136mr8008343lfp.32.1474965427948; Tue, 27 Sep 2016 01:37:07 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.25.70 with HTTP; Tue, 27 Sep 2016 01:36:27 -0700 (PDT)
In-Reply-To: <20160926145534.0EFD41A55B@ld9781.wdf.sap.corp>
References: <fd4ad423-3614-5330-b687-1b5848e839f0@wheelsystems.com> <20160926145534.0EFD41A55B@ld9781.wdf.sap.corp>
From: =?UTF-8?Q?Micha=C5=82_Staruch?= <m.staruch@cinkciarz.pl>
Date: Tue, 27 Sep 2016 10:36:27 +0200
Message-ID: <CAN1difvo4tOMZSERV3JH-Xx1EOY_XP+aEeEt8ZrdVPeEVHzR_g@mail.gmail.com>
To: mrex@sap.com
Content-Type: text/plain; charset=UTF-8
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/LVQmvcpRetRsoIiIPJZQn416aM8>
X-Mailman-Approved-At: Tue, 27 Sep 2016 12:07:57 -0700
Cc: tls@ietf.org
Subject: Re: [TLS] Industry Concerns about TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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, 27 Sep 2016 08:46:29 -0000

On Mon, Sep 26, 2016 at 4:55 PM, Martin Rex <mrex@sap.com>; wrote:
> And no, there can not be any valid regulations to require such
> monitoring, because _every_ to the secrecy provisions and criminalization
> requires an explicit law from the parlamentarian legislator.

GDPR Article 88 leaves rules of processing employees' personal data
in the employment context up to the Member States - so regulations
in Germany may be different than ones in let's say Poland.


About the main topic: TLS main task is to protect privacy and data
integrity - essentially to prevent the MitM. Requests that are in
direct conflict with that can't be treated seriously.

TLS needs to provide secure connections, and PFS cipher suites are
better choice than non-PFS ones. If anyone wants (or needs) to monitor
the data, he should set proper trust boundaries, and do the monitoring
between TLS terminators.