Re: [TLS] datacenter TLS decryption as a three-party protocol
"Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu> Mon, 24 July 2017 01:01 UTC
Return-Path: <prvs=8378146a2a=uri@ll.mit.edu>
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 F02F512F268 for <tls@ietfa.amsl.com>; Sun, 23 Jul 2017 18:01:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
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 R-xQRiy9M59C for <tls@ietfa.amsl.com>; Sun, 23 Jul 2017 18:01:40 -0700 (PDT)
Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id B28DA129B30 for <tls@ietf.org>; Sun, 23 Jul 2017 18:01:40 -0700 (PDT)
Received: from LLE2K10-HUB02.mitll.ad.local (LLE2K10-HUB02.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id v6O11c36013930; Sun, 23 Jul 2017 21:01:38 -0400
From: "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>
Message-ID: <C76720C5-7BB6-4AB4-8A2D-7569EC57D15D@ll.mit.edu>
Content-Type: multipart/alternative; boundary="Apple-Mail=_3FC9EA3E-E8C1-441A-BD8B-0C6783BACF11"
MIME-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Sun, 23 Jul 2017 21:01:37 -0400
In-Reply-To: <44105D6B-4CE0-4C3C-ACFA-30EF1D8AA8F7@fugue.com>
CC: "<tls@ietf.org>" <tls@ietf.org>
To: Ted Lemon <mellon@fugue.com>
References: <CAAF6GDeFuRy0DN6w3FwmR_nh1G=YBi4+qiEcw0MfSRj4SUCbZQ@mail.gmail.com> <20170720200114.AA2F91A6CB@ld9781.wdf.sap.corp> <06AE85BC-87AD-4CA5-8408-44F670358701@ll.mit.edu> <20170720203238.e66zurx5yn2jja3a@LK-Perkele-VII> <17109486-336E-44C0-B9FC-D65EE14310B5@ll.mit.edu> <20170723070240.x7kmynzmu4jqco5t@LK-Perkele-VII> <C0772D29-CB26-418F-981B-BC2E2435E655@ll.mit.edu> <35FD3356-8300-405A-B8D8-FC2574DB9A56@fugue.com> <CE89217F-972F-4F37-B8BA-925AE1FE8D68@ll.mit.edu> <44105D6B-4CE0-4C3C-ACFA-30EF1D8AA8F7@fugue.com>
X-Mailer: Apple Mail (2.3273)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-23_17:, , 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-1707240012
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/2Mnqk26VSmRsgSdbM0HwEycDuBo>
Subject: Re: [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: Mon, 24 Jul 2017 01:01:43 -0000
On Jul 23, 2017, at 15:37, Ted Lemon <mellon@fugue.com> wrote: > On Jul 23, 2017, at 12:05 PM, Blumenthal, Uri - 0553 - MITLL <uri@ll.mit.edu <mailto:uri@ll.mit.edu>> wrote: >> I think there's no way the connection can be established if the third party in control of the network does not allow that. > > This is why it’s hard to reason well about this stuff—we tend to get the threat models wrong. The attack that negotiating enables is not that a third party can block all connections. They can always block all connections. What the attack enables is blocking only those connections that don’t negotiate a downgrade. So if you negotiate a downgrade, you get to look at your content, but if you don’t negotiate the downgrade, you don’t. This allows a MiTM to coerce end users into negotiating downgrades. That is clear and AFAIK unavoidable. And not my (main) concern. What I am trying to avoid is the ability to *surreptitiously* subvert a protocol that’s assumed to be secure. IMHO it is fine if one end-point is faced with a choice of either agreeing to an “eavesdropping” connection or aborting because of no (remaining) common cipher-suites. What I don’t want to see is one end negotiating a connection that “should” be secure based on the exchange parameters, but in fact leaking keys… What I want in such a case is a negotiation that clearly states what has been done. Then the end-point would make a conscious decision to either connect and access data despite being surveilled, or avoid both surveillance and service. > Of course the far end can just not downgrade, but it may have downgrading enabled either for debugging purposes, never intending that all connections be downgraded, or because the operator didn’t configure the server correctly. My main concern is the “invisible” downgrade (that the operator has no say about), not an operator error. > If it’s not in the standard, it can still be enabled by operators who are violating the end user’s trust, but won’t happen by accident and won’t be possible to coerce with a MiTM attack. I see your point. I don’t share your concern, but don’t object to it either.
- [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