[TLS] Delegated Credentials and Lawful Intercept

Florian Weimer <fw@deneb.enyo.de> Fri, 01 November 2019 20:14 UTC

Return-Path: <fw@deneb.enyo.de>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 23758120828 for <tls@ietfa.amsl.com>; Fri, 1 Nov 2019 13:14:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 41vjXoST_Icd for <tls@ietfa.amsl.com>; Fri, 1 Nov 2019 13:14:01 -0700 (PDT)
Received: from albireo.enyo.de (albireo.enyo.de []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8882D120013 for <tls@ietf.org>; Fri, 1 Nov 2019 13:14:01 -0700 (PDT)
Received: from [] (helo=deneb.enyo.de) by albireo.enyo.de with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1iQdJ0-0002JZ-3g for tls@ietf.org; Fri, 01 Nov 2019 20:13:58 +0000
Received: from fw by deneb.enyo.de with local (Exim 4.92) (envelope-from <fw@deneb.enyo.de>) id 1iQdIz-0005MF-VY for tls@ietf.org; Fri, 01 Nov 2019 21:13:57 +0100
From: Florian Weimer <fw@deneb.enyo.de>
To: tls@ietf.org
Date: Fri, 01 Nov 2019 21:13:57 +0100
Message-ID: <87zhhfcq2i.fsf@mid.deneb.enyo.de>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/DDDHg-hnFDEtRWnePYxgk6VOHO0>
Subject: [TLS] Delegated Credentials and Lawful Intercept
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, 01 Nov 2019 20:14:03 -0000

Would it be possible to use delegated credentials to address lawful
intercept concerns, similar to eTLS?

Basically, the server operator would issue a delegated credential to
someone who has to decrypt or modify the traffic after intercepting
it, without having to disclose that backdoor in certificate
transparency logs.

And in a data center scenario, perhaps people feel more comfortable
loading those short-term credentials into their monitoring equipment.