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

Russ Housley <housley@vigilsec.com> Thu, 20 July 2017 06:01 UTC

Return-Path: <housley@vigilsec.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 3E5FE124217 for <tls@ietfa.amsl.com>; Wed, 19 Jul 2017 23:01:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 ScB0b3WORR_M for <tls@ietfa.amsl.com>; Wed, 19 Jul 2017 23:01:06 -0700 (PDT)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94A23127866 for <tls@ietf.org>; Wed, 19 Jul 2017 23:01:06 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id E155830050A for <tls@ietf.org>; Thu, 20 Jul 2017 02:01:05 -0400 (EDT)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id DaFyPYygMv26 for <tls@ietf.org>; Thu, 20 Jul 2017 02:01:03 -0400 (EDT)
Received: from [5.5.33.129] (vpn.snozzages.com [204.42.252.17]) by mail.smeinc.net (Postfix) with ESMTPSA id 31E723004CB; Thu, 20 Jul 2017 02:01:02 -0400 (EDT)
From: Russ Housley <housley@vigilsec.com>
Message-Id: <EEBF938A-234C-43E3-B058-4AE443C66EF0@vigilsec.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_8E1BAAF5-5ADF-48DA-9767-3A21FE23D0A9"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Thu, 20 Jul 2017 02:01:03 -0400
In-Reply-To: <CAPt1N1ka=vuoZMB58LXfkJ_qafohf08WeoUs2y4kaCxBtCx29Q@mail.gmail.com>
Cc: IETF TLS <tls@ietf.org>
To: Ted Lemon <mellon@fugue.com>
References: <E6D7DDCD-FDE6-4784-ACE8-0F5AC8E2CEDF@vigilsec.com> <CAPt1N1ka=vuoZMB58LXfkJ_qafohf08WeoUs2y4kaCxBtCx29Q@mail.gmail.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/TyCH6WZP6SVovXezhS0AN67R22o>
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 06:01:08 -0000

Ted, if we use a new extension, then the server cannot include it unless the client offered it first.  I am thinking of an approach where the server would include information needed by the decryptor in the response.  So, if the client did not offer the extension, it would be a TLS protocol violation for the server to include it.

Russ


> On Jul 19, 2017, at 1:14 PM, Ted Lemon <mellon@fugue.com> wrote:
> 
> Provably involved, or involved setting an evil bit?
> 
> On Wed, Jul 19, 2017 at 7:10 PM, Russ Housley <housley@vigilsec.com <mailto:housley@vigilsec.com>> wrote:
> The hum told us that the room was roughly evenly split.  In hind sight, I wish the chairs had asked a second question.  If the split in the room was different for the second question, then I think we might have learned a bit more about what people are thinking.
> 
> 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.
> 
> Russ