Re: [TLS] network-based security solution use cases

Flemming Andreasen <> Tue, 07 November 2017 02:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AD9F713FB5D for <>; Mon, 6 Nov 2017 18:47:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.52
X-Spam-Status: No, score=-14.52 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 426tGvPiqhW9 for <>; Mon, 6 Nov 2017 18:47:48 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0F5B213FB0D for <>; Mon, 6 Nov 2017 18:47:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=2482; q=dns/txt; s=iport; t=1510022868; x=1511232468; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=JpwbW0L+q5Qb179qjnMZDfuoPHYDYXktBieUnvRpc1E=; b=eaJvnEkKnYpWDm50ERAtmXNl7vxYmlgRg18fTimyc18drALogLamWBVx 6qDX2qPLB7JPks+HoAiG0XVJb6iNqc1ZeCsYdqjc9OqWhQPHNBDOvK90f twolwKVP4QKd3kTdoR7gVnnsA3yCl3nW1FxtHqwVNCGKzT0q+GH+Nb1z0 8=;
X-IronPort-AV: E=Sophos;i="5.44,355,1505779200"; d="scan'208";a="315452544"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Nov 2017 02:47:47 +0000
Received: from [] ( []) by (8.14.5/8.14.5) with ESMTP id vA72lktd013999; Tue, 7 Nov 2017 02:47:47 GMT
To: Florian Weimer <>, "Nancy Cam-Winget (ncamwing)" <>
Cc: "" <>
References: <> <>
From: Flemming Andreasen <>
Message-ID: <>
Date: Mon, 6 Nov 2017 21:48:38 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <>
Subject: Re: [TLS] network-based security solution use cases
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 07 Nov 2017 02:47:50 -0000

On 11/5/17 10:31 AM, Florian Weimer wrote:
> * Nancy Cam-Winget:
>> @IETF99, awareness was raised to some of the security WGs (thanks
>> Kathleen ☺) that TLS 1.3 will obscure visibility currently afforded in
>> TLS 1.2 and asked what the implications would be for the security
>> solutions today.
>> is an
>> initial draft to describe some of the impacts relating to current
>> network security solutions.  The goal of the draft is NOT to propose
>> any solution as a few have been proposed, but rather to raise
>> awareness to how current network-based security solutions work today
>> and their impact on them based on the current TLS 1.3 specification.
> I'm not sure if this approach is useful, I'm afraid.  The draft is
> basically a collection of man-in-the-middle attacks many people would
> consider benign.  It's unclear where the line is drawn: traffic
> optimization/compression and ad suppression/replacement aren't
> mentioned, for example, and I would expect both to be rather low on
> the scale of offensiveness.
We didn't draw any particular line, but the use case scenarios that we 
tried to highlight are those related to overall security and regulatory 
requirements (including public sector) where a network-based solution 
currently exists, and (we believe) is not easily replaced. A number of 
these are routinely encountered in present-day enterprise, cloud and 
public sector, and we believe they will continue to be relevant. On top 
of that, we have a rapidly expanding base of IoT endpoints with limited 
capabilities, which presents a whole new and highly vulnerable attack 

> What the draft is essentially arguing is that many user cannot afford
> end-to-end encryption for various reasons, some legal, some technical,
> some political.  But it seems to me that this is currently not a
> viewpoint shared by the IETF.
That is our read of the current situation as well, however the concern 
is that by focusing solely on privacy and e2e security, there are 
additional important considerations that are being ignored. Our intent 
with the draft is to illustrate some of those and see if we can get to 
some consensus around the need to address those (and/or possibly others).


-- Flemming

> _______________________________________________
> TLS mailing list