[TLS] datacenter TLS decryption as a three-party protocol
Benjamin Kaduk <bkaduk@akamai.com> Wed, 19 July 2017 13:10 UTC
Return-Path: <bkaduk@akamai.com>
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 572A7131C71 for <tls@ietfa.amsl.com>; Wed, 19 Jul 2017 06:10:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com
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 sBY-ymDpuZuK for <tls@ietfa.amsl.com>; Wed, 19 Jul 2017 06:09:59 -0700 (PDT)
Received: from mx0b-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 1E6BD131B42 for <tls@ietf.org>; Wed, 19 Jul 2017 06:09:59 -0700 (PDT)
Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v6JD0SoH007785 for <tls@ietf.org>; Wed, 19 Jul 2017 14:09:57 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=to : from : subject : message-id : date : mime-version : content-type; s=jan2016.eng; bh=JV/2tZ3fxM8xN0rLY1PKoqmOOZap1ZbAje93LSsdJjI=; b=M5/BsfdinuPuW0XoIZxZqltH8ENnzsZEE5BFXbHNfoEZMMlLrq+3aVHstP49gLvCXSg6 AmqeoCF/g0rJNhXI16F+D7tqbcFGFdVGJ5Qi4gC9LWr3AwVcNbpMNTKiKpeHEsN2OeZh CM60/lunwJNjCRZWG0KlEyUkNX2RWPb3PED3RI9BLj/szUq9dJMkK6004GoC7gh1lEO3 ITUv/cT7L3swvaAmqk31I/vJP3hdnGhqcD4/4rcU4qO1kdjzitDt1NodbqVP1hC9wCF7 YGZVtitG975B0O1mIg/LRzHfW52iraNzY9Vd75FKDMClWfBzp//RQRUKzBRUMaamPtv1 DQ==
Received: from prod-mail-ppoint2 (a184-51-33-19.deploy.static.akamaitechnologies.com [184.51.33.19] (may be forged)) by m0050093.ppops.net-00190b01. with ESMTP id 2bs7vsf2df-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <tls@ietf.org>; Wed, 19 Jul 2017 14:09:57 +0100
Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v6JD6IqJ025467 for <tls@ietf.org>; Wed, 19 Jul 2017 09:09:55 -0400
Received: from prod-mail-relay10.akamai.com ([172.27.118.251]) by prod-mail-ppoint2.akamai.com with ESMTP id 2bqecuv698-1 for <tls@ietf.org>; Wed, 19 Jul 2017 09:09:55 -0400
Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 741131FCAD for <tls@ietf.org>; Wed, 19 Jul 2017 13:09:55 +0000 (GMT)
To: "<tls@ietf.org>" <tls@ietf.org>
From: Benjamin Kaduk <bkaduk@akamai.com>
Message-ID: <81de2a21-610e-c2b3-d3ff-2fc598170369@akamai.com>
Date: Wed, 19 Jul 2017 08:09:55 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------1667CDA4696770A730CCDF37"
Content-Language: en-US
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-19_09:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707190213
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-19_09:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707190211
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/GvwCz2Qg3G9Efqb4qb9yzNZHENc>
Subject: [TLS] datacenter TLS decryption as a three-party protocol
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: Wed, 19 Jul 2017 13:10:00 -0000
As Stephen noted in his presentation, a lot of the proposals for passive decryption can be seen as trying to turn TLS from a two-party protocol into a three-party protocol. Which is probably the right way to think about it, even when all (three) parties are within the same administrative domain. Stephen also said something about it being hard to shoehorn a three-party protocol into the API for a two party protocol. But depending on the specifics, maybe it's not so bad. For example, if the only semantics you need are a new API for "this is the list of third parties I authorize to wiretap this connection", the scope seems fairly limited. Another thought spawned from today's session is that, given concerns about preventing/noticing if schemes intended for the datacenter leak out onto the internet, it's not really clear that "minimizes changes to the wire protocol" should be considered a benefit of proposals in this space. If there are clear changes to the wire protocol, that makes it easy to detect when the scheme is in use. -Ben
- [TLS] datacenter TLS decryption as a three-party … Benjamin Kaduk
- Re: [TLS] datacenter TLS decryption as a three-pa… Ted Lemon
- Re: [TLS] datacenter TLS decryption as a three-pa… Kyle Rose
- Re: [TLS] datacenter TLS decryption as a three-pa… Ted Lemon
- Re: [TLS] datacenter TLS decryption as a three-pa… Kyle Rose
- Re: [TLS] datacenter TLS decryption as a three-pa… Roland Zink
- Re: [TLS] datacenter TLS decryption as a three-pa… Blumenthal, Uri - 0553 - MITLL
- Re: [TLS] datacenter TLS decryption as a three-pa… Yoav Nir
- Re: [TLS] datacenter TLS decryption as a three-pa… Blumenthal, Uri - 0553 - MITLL
- Re: [TLS] datacenter TLS decryption as a three-pa… Derrell Piper
- Re: [TLS] datacenter TLS decryption as a three-pa… Stephen Farrell
- Re: [TLS] datacenter TLS decryption as a three-pa… Benjamin Kaduk
- Re: [TLS] datacenter TLS decryption as a three-pa… Stephen Farrell
- Re: [TLS] datacenter TLS decryption as a three-pa… Ted Lemon
- Re: [TLS] datacenter TLS decryption as a three-pa… Colm MacCárthaigh
- Re: [TLS] datacenter TLS decryption as a three-pa… Ted Lemon
- Re: [TLS] datacenter TLS decryption as a three-pa… Colm MacCárthaigh
- Re: [TLS] datacenter TLS decryption as a three-pa… BITS Security
- Re: [TLS] datacenter TLS decryption as a three-pa… Martin Rex
- Re: [TLS] datacenter TLS decryption as a three-pa… Martin Rex
- Re: [TLS] datacenter TLS decryption as a three-pa… Salz, Rich
- Re: [TLS] datacenter TLS decryption as a three-pa… Roland Zink
- Re: [TLS] datacenter TLS decryption as a three-pa… Stephen Farrell
- Re: [TLS] datacenter TLS decryption as a three-pa… Stephen Farrell
- Re: [TLS] datacenter TLS decryption as a three-pa… Colm MacCárthaigh
- Re: [TLS] datacenter TLS decryption as a three-pa… Tony Arcieri
- Re: [TLS] datacenter TLS decryption as a three-pa… Andrei Popov
- Re: [TLS] datacenter TLS decryption as a three-pa… Colm MacCárthaigh
- Re: [TLS] datacenter TLS decryption as a three-pa… Andrei Popov
- Re: [TLS] datacenter TLS decryption as a three-pa… Salz, Rich
- Re: [TLS] datacenter TLS decryption as a three-pa… Colm MacCárthaigh
- Re: [TLS] datacenter TLS decryption as a three-pa… Stephen Farrell
- Re: [TLS] datacenter TLS decryption as a three-pa… Colm MacCárthaigh
- Re: [TLS] datacenter TLS decryption as a three-pa… Stephen Farrell
- Re: [TLS] datacenter TLS decryption as a three-pa… Colm MacCárthaigh
- Re: [TLS] datacenter TLS decryption as a three-pa… Martin Rex
- Re: [TLS] datacenter TLS decryption as a three-pa… Blumenthal, Uri - 0553 - MITLL
- Re: [TLS] datacenter TLS decryption as a three-pa… Ilari Liusvaara
- Re: [TLS] datacenter TLS decryption as a three-pa… Blumenthal, Uri - 0553 - MITLL
- Re: [TLS] datacenter TLS decryption as a three-pa… Ilari Liusvaara
- Re: [TLS] datacenter TLS decryption as a three-pa… Blumenthal, Uri - 0553 - MITLL
- Re: [TLS] datacenter TLS decryption as a three-pa… Ted Lemon
- Re: [TLS] datacenter TLS decryption as a three-pa… Blumenthal, Uri - 0553 - MITLL
- Re: [TLS] datacenter TLS decryption as a three-pa… Stephen Farrell
- Re: [TLS] datacenter TLS decryption as a three-pa… Blumenthal, Uri - 0553 - MITLL
- Re: [TLS] datacenter TLS decryption as a three-pa… Ted Lemon
- Re: [TLS] datacenter TLS decryption as a three-pa… Christian Huitema
- Re: [TLS] datacenter TLS decryption as a three-pa… Ted Lemon
- Re: [TLS] datacenter TLS decryption as a three-pa… Jeffrey Walton
- Re: [TLS] datacenter TLS decryption as a three-pa… Blumenthal, Uri - 0553 - MITLL
- Re: [TLS] datacenter TLS decryption as a three-pa… Felix Wyss
- Re: [TLS] datacenter TLS decryption as a three-pa… Ted Lemon
- Re: [TLS] datacenter TLS decryption as a three-pa… Stephen Farrell
- Re: [TLS] datacenter TLS decryption as a three-pa… Brian Sniffen
- Re: [TLS] datacenter TLS decryption as a three-pa… Kyle Rose
- Re: [TLS] datacenter TLS decryption as a three-pa… Paul Turner
- Re: [TLS] datacenter TLS decryption as a three-pa… Brian Sniffen
- Re: [TLS] datacenter TLS decryption as a three-pa… Paul Turner
- Re: [TLS] datacenter TLS decryption as a three-pa… Kyle Rose
- Re: [TLS] datacenter TLS decryption as a three-pa… Sean Turner
- Re: [TLS] datacenter TLS decryption as a three-pa… Ilari Liusvaara