[TLS] debugging tools [was: Industry Concerns about TLS 1.3]

Nikos Mavrogiannopoulos <nmav@redhat.com> Fri, 23 September 2016 10:46 UTC

Return-Path: <nmav@redhat.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 40D0A12D777 for <tls@ietfa.amsl.com>; Fri, 23 Sep 2016 03:46:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.238
X-Spam-Level:
X-Spam-Status: No, score=-9.238 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, RP_MATCHES_RCVD=-2.316, SPF_HELO_PASS=-0.001, 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 nvrNzz_5hi7j for <tls@ietfa.amsl.com>; Fri, 23 Sep 2016 03:46:41 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5F5F12D76D for <tls@ietf.org>; Fri, 23 Sep 2016 03:46:41 -0700 (PDT)
Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 13A2A9D0F1; Fri, 23 Sep 2016 10:46:41 +0000 (UTC)
Received: from dhcp-10-40-1-102.brq.redhat.com ([10.40.3.0]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u8NAkcf6010444 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 23 Sep 2016 06:46:40 -0400
Message-ID: <1474627597.2773.14.camel@redhat.com>
From: Nikos Mavrogiannopoulos <nmav@redhat.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, "tls@ietf.org" <tls@ietf.org>
Date: Fri, 23 Sep 2016 12:46:37 +0200
In-Reply-To: <394611bf-208f-03d3-620c-79aaf169645b@cs.tcd.ie>
References: <DM5PR11MB1419B782D2BEF0E0A35E420DF4C90@DM5PR11MB1419.namprd11.prod.outlook.com> <CO1PR07MB283F2C414B6478E993675DEC3C90@CO1PR07MB283.namprd07.prod.outlook.com> <394611bf-208f-03d3-620c-79aaf169645b@cs.tcd.ie>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Fri, 23 Sep 2016 10:46:41 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/qxo-ulw984H-8gb9Ha-MFhRZliI>
Subject: [TLS] debugging tools [was: Industry Concerns about TLS 1.3]
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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, 23 Sep 2016 10:46:43 -0000

On Fri, 2016-09-23 at 09:05 +0100, Stephen Farrell wrote:
> 
> On 22/09/16 19:36, Yuhong Bao wrote:
> > 
> > This also reminds me of https://bugzilla.mozilla.org/show_bug.cgi?i
> > d=1188657
> 
> Yuk. Prioritising the needs of those debugging networks
> over the maybe 5-6 orders of magnitude more folks using
> them is ass-backwards IMO. That result looks to me like
> a very bad decision if I'm following it correctly.

That's a very different concern than the one asked by BITS security,
and is IMO a very valid one. Running any protocol under TLS wouldn't
mean that debugging is very hard or impossible for the one running the
protocol. Administrators debug and trace protocols every day to figure
out failures (that's why we have advanced tools like wireshark). Making
it hard for them to use these tools isn't increasing security; it is
only making their life harder.

regards,
Nikos