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.