Re: [TLS] Is there a way forward after today's hum?

mrex@sap.com (Martin Rex) Thu, 20 July 2017 13:29 UTC

Return-Path: <mrex@sap.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 BED1E131B37 for <tls@ietfa.amsl.com>; Thu, 20 Jul 2017 06:29:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.921
X-Spam-Level:
X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-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 Hi1MlpNkT_Zd for <tls@ietfa.amsl.com>; Thu, 20 Jul 2017 06:29:23 -0700 (PDT)
Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7609131C1C for <tls@ietf.org>; Thu, 20 Jul 2017 06:29:22 -0700 (PDT)
Received: from mail07.wdf.sap.corp (mail04.sap.corp [194.39.131.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 3xCvrJ69FNz1HQL; Thu, 20 Jul 2017 15:29:20 +0200 (CEST)
X-purgate-ID: 152705::1500557360-00000810-FC7742B5/0/0
X-purgate-size: 1265
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate-type: clean
X-SAP-SPAM-Status: clean
Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail07.wdf.sap.corp (Postfix) with ESMTP id 3xCvrJ2wdVzGnvS; Thu, 20 Jul 2017 15:29:20 +0200 (CEST)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 58B131A6CB; Thu, 20 Jul 2017 15:29:20 +0200 (CEST)
In-Reply-To: <E6D7DDCD-FDE6-4784-ACE8-0F5AC8E2CEDF@vigilsec.com>
To: Russ Housley <housley@vigilsec.com>
Date: Thu, 20 Jul 2017 15:29:20 +0200
CC: IETF TLS <tls@ietf.org>
Reply-To: mrex@sap.com
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20170720132920.58B131A6CB@ld9781.wdf.sap.corp>
From: mrex@sap.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/xyGTEQP6quZCBOAZvewNm3zNjqQ>
Subject: Re: [TLS] Is there a way forward after today's hum?
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: Thu, 20 Jul 2017 13:29:25 -0000

I'm sorry, Russ, but I think this would be seriously deceiving.


Russ Housley wrote:
> 
> If a specification were available that used an extension that involved
> both the client and the server, would the working group adopt it, work
> on it, and publish it as an RFC?
> 
> I was listening very carefully to the comments made by people in line.
> Clearly some people would hum for "no" to the above question, but it
> sounded like many felt that this would be a significant difference.
> It would ensure that both server and client explicitly opt-in, and any
> party observing the handshake could see the extension was included or not.

Any party observing the handshake (read: a monitoring middlebox) would
see whether client proposed the extension and server confirmed the extension
in the clear part of the TLS handshake, and that very same monitoring
middlebox very very very probably would kill/prevent all TLS handshakes
without that extension being confirmed by the server from completing...

... at which point this is no longer a "rare and occasional voluntary
opt-in for debugging broken apps" but rather a policy enforcment known
as "coercion".

I am violently opposed to standardizing enfored wire-tapping for TLS.

-Martin