IETF Logo Mail Archive

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

Russ Housley <housley@vigilsec.com> Wed, 19 July 2017 17:11 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 E7CAE131472 for <tls@ietfa.amsl.com>; Wed, 19 Jul 2017 10:11:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 s67waaKnvtZs for <tls@ietfa.amsl.com>; Wed, 19 Jul 2017 10:11:00 -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 8B47512EC3F for <tls@ietf.org>; Wed, 19 Jul 2017 10:11:00 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id B7BAE3004CB for <tls@ietf.org>; Wed, 19 Jul 2017 13:10:59 -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 CBecaePugCAI for <tls@ietf.org>; Wed, 19 Jul 2017 13:10:59 -0400 (EDT)
Received: from [5.5.33.118] (vpn.snozzages.com [204.42.252.17]) by mail.smeinc.net (Postfix) with ESMTPSA id 99843300285 for <tls@ietf.org>; Wed, 19 Jul 2017 13:10:58 -0400 (EDT)
From: Russ Housley <housley@vigilsec.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Message-Id: <E6D7DDCD-FDE6-4784-ACE8-0F5AC8E2CEDF@vigilsec.com>
Date: Wed, 19 Jul 2017 13:10:56 -0400
To: IETF TLS <tls@ietf.org>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/gti8imv9ude6oaP8oma9xOox_mQ>
Subject: [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: Wed, 19 Jul 2017 17:11:02 -0000

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

v2.23.0 | Report a Bug | By Email