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

Stephen Farrell <stephen.farrell@cs.tcd.ie> Thu, 20 July 2017 15:26 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
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 A0571131CE2 for <tls@ietfa.amsl.com>; Thu, 20 Jul 2017 08:26:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.302
X-Spam-Level:
X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
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 zgUtk0ibSEQB for <tls@ietfa.amsl.com>; Thu, 20 Jul 2017 08:26:20 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0B32131C43 for <tls@ietf.org>; Thu, 20 Jul 2017 08:26:20 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 7C765BE38; Thu, 20 Jul 2017 16:26:18 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id odWS6STcnzCO; Thu, 20 Jul 2017 16:26:17 +0100 (IST)
Received: from [31.133.132.197] (dhcp-84c5.meeting.ietf.org [31.133.132.197]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 09E09BE2F; Thu, 20 Jul 2017 16:26:16 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1500564377; bh=L7+xNmJm4zjeykqQV5xnlKT3vejl72DNmWp4o6DlmDM=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=kpdajk4EYKAp0/OK0exdjC0qV2vVIHNy7oBFFPRa/WqMDY3QINK0L8Lbc1VUT3+V6 bZ/RXOLwOM49iM0jehuijrJ2RsltI9bIPtt6dFhgUluJkUvglX0mDfOvFTZV5BWT25 NDO6Cv7CnnsbYBQjSqQfMGkO6BzjBWa+gufSSCZ8=
To: Paul Turner <PAUL.TURNER@venafi.com>, Ted Lemon <mellon@fugue.com>
Cc: Robin Wilton <wilton@isoc.org>, "<tls@ietf.org>" <tls@ietf.org>
References: <BN6PR06MB3395E47F181D02D5772EEC81BFA70@BN6PR06MB3395.namprd06.prod.outlook.com> <bbd5d287b07d4e5aac7cbd3add41da03@venafi.com> <CAPt1N1kRf-Z_FnK8pmRH_hp7wKTYPW1zu55136Dmp2jF7vgH3w@mail.gmail.com> <691913e7a5d1464e8dda20c8848f6149@venafi.com> <dbd1a70d-c5cf-89b6-36ee-6d5b672fda99@cs.tcd.ie> <373f65c7c1e8483c9efdf06bbc5671cf@venafi.com> <e9f89ee4-9b44-fa2c-84c7-f12bc77f7202@cs.tcd.ie> <cd9e13f908224dc59472cf0e599b56ce@venafi.com> <4b3855e4-0d37-bf25-5215-1ff179c13c59@cs.tcd.ie> <6a05aa8a00b847b9aac5fd020a57c928@venafi.com>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <faee1869-08ed-cc57-e538-bb37470d4ebd@cs.tcd.ie>
Date: Thu, 20 Jul 2017 16:26:15 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <6a05aa8a00b847b9aac5fd020a57c928@venafi.com>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="0caReDpK5M2BefDtxinVubsvx9Gc6r24w"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/ZPn3J8y03Vbu-ZV57m165re0xZI>
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 15:26:23 -0000


On 20/07/17 16:23, Paul Turner wrote:
>> I'd assert there's no way TLS clients in general could know when to
>> set or unset the "please wiretap me" evil bit in a ClientHello,
>> regardless of how complex a configuration is used.
>  
> 
> It seems like the guidance would be for all TLS clients to NOT
> include the extension by default. Anyone who wanted to enable it on
> their TLS client would have to explicitly turn it on through
> configuration. Since the client wouldn’t include the extension and
> the server would know that the client would abort the connection if
> it included the extension in return (a violation of TLS 1.3), the
> server would simply proceed in killing the connection itself. It
> doesn’t seem like there would be the need for complex configuration
> decisions to be made by TLS client users who have no intention of
> enabling it. Is that correct?
No. What's correct is never even defining this at all.

If you think there's some other correct state of affairs I will
read the I-D you write describing that. (And then debunk it:-)

S.