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

Stephen Farrell <stephen.farrell@cs.tcd.ie> Tue, 07 November 2017 09:18 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
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 78CFF13FD2D for <tls@ietfa.amsl.com>; Tue, 7 Nov 2017 01:18:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level:
X-Spam-Status: No, score=-4.3 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_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
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 TKA4Zj7G8UfW for <tls@ietfa.amsl.com>; Tue, 7 Nov 2017 01:18:52 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A19813FD6D for <tls@ietf.org>; Tue, 7 Nov 2017 01:13:23 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 8AE89BE2E; Tue, 7 Nov 2017 09:13:21 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YJwTQ52GdfND; Tue, 7 Nov 2017 09:13:20 +0000 (GMT)
Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id E8307BDF9; Tue, 7 Nov 2017 09:13:19 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1510046000; bh=vZ4K7A4Vb8F0Ub5Y9oap6lXt2cL3woMwCiMeJ3zZ1J4=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=ORqhQaBO5eeFOix8LKordFuJZVEVxpbR56JSR2Xj3+V2JcqCbyTHHMaVTygj8XvtQ tYNIF3+BGSpEasD6NlypDD4srBUiuSVnQSj3R/tEnWs6BZgp9f60kkVjlp6oHB1aNq zUJ7W/HQvOCsquDap9kLkwyR/deoYWquQBqwDXdg=
To: Flemming Andreasen <fandreas@cisco.com>, Florian Weimer <fw@deneb.enyo.de>, "Nancy Cam-Winget (ncamwing)" <ncamwing@cisco.com>
Cc: "tls@ietf.org" <tls@ietf.org>
References: <895D1206-28D1-43AB-8A45-11DEEC86A71D@cisco.com> <874lq868t3.fsf@mid.deneb.enyo.de> <a7a78674-d80d-dbd3-3c65-2d4000922423@cisco.com>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <6966da46-0f07-b518-4b6e-f2b5f599b050@cs.tcd.ie>
Date: Tue, 7 Nov 2017 09:13:19 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <a7a78674-d80d-dbd3-3c65-2d4000922423@cisco.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="XMNfiVgIWDB3nQOvVQgMxXqXV3KxBhqFR"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/3xwHTmZmLDbztiXYjGVQSWDUPSQ>
Subject: Re: [TLS] network-based security solution use cases
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, 07 Nov 2017 09:18:54 -0000

Hiya,

On 07/11/17 02:48, Flemming Andreasen wrote:
>>
> 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)

I had a quick look at the draft (will try read properly en-route to
ietf-100) and I followed the reference to [1] but that only lead to a
forest of documents in which I didn't find any reference to breaking
TLS so far at least. Can you provide an explicit pointer to the
exact document on which that claim is based?

I'd also claim that your reference to PCI-DSS is misleading, as that
same spec also explicitly calls for there to be good key management
specifically including minimising the number of copies of keys, so
at most, one might be able to claim that PCI-DSS is ok with people
who break TLS in a nod-and-a-wink manner. But if you do have a real
quote from PCI-DSS that calls for breaking TLS then please do also
send that (it's been asked for a bunch of times without any answer
being provided so far).

Thanks,
S.


[1]
https://tools.ietf.org/html/draft-camwinget-tls-use-cases-00.html#ref-NERCCIP