Re: [TLS] TLS Provfiles (Was: Call for consensus to remove anonymous DH)
Viktor Dukhovni <ietf-dane@dukhovni.org> Wed, 16 September 2015 18:21 UTC
Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D98AC1A8842 for <tls@ietfa.amsl.com>; Wed, 16 Sep 2015 11:21:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.619
X-Spam-Level:
X-Spam-Status: No, score=-0.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_PROFILE2=1.981, RCVD_IN_DNSWL_LOW=-0.7] autolearn=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 cedBBrqkn3tt for <tls@ietfa.amsl.com>; Wed, 16 Sep 2015 11:21:15 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC4D21A884D for <tls@ietf.org>; Wed, 16 Sep 2015 11:21:12 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id CC226284AED; Wed, 16 Sep 2015 18:21:05 +0000 (UTC)
Date: Wed, 16 Sep 2015 18:21:05 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: tls@ietf.org
Message-ID: <20150916182105.GB21942@mournblade.imrryr.org>
References: <CAH8yC8=eHzQPL6cROVK4Pm0V2FSYTL7C7csLG7p49W5LEmfo=Q@mail.gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4B08850@uxcn10-tdc05.UoA.auckland.ac.nz> <CABkgnnWkbrvqMkkH1Yqj0Psb8=pDPqaQJ7A=6ZUT-DabWWAMHQ@mail.gmail.com> <201509161410.36507.davemgarrett@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <201509161410.36507.davemgarrett@gmail.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/2XdXBZGg-D17SF7QPJ9Sqt7fZf0>
Subject: Re: [TLS] TLS Provfiles (Was: Call for consensus to remove anonymous DH)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: tls@ietf.org
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, 16 Sep 2015 18:21:16 -0000
On Wed, Sep 16, 2015 at 02:10:36PM -0400, Dave Garrett wrote: > > Yes. I wouldn't recommend following this path to others; it's not > > easy and the return on that investment isn't all good. The mess we > > were attempting to clean up with HTTP/2 was the state of TLS > > deployment on the web, not so much the spec itself. > > The profiles idea feels like a way to justify having a crap profile in the mix. I see no basis for that dismissive throw-away. > We should be focusing on restricting TLS to always actually be competent. All profiles are restrictions by definition, they don't add new features. Competence is context dependent. The advantage of profiles is that they standardize sensible combinations of features, and encourage toolkits to provide interfaces for applications to track a particular profile. This also makes it easier for toolkits to harden some profiles selectively without breaking other profiles. Explicit profiles make some sense. They need not be defined by the TLS WG per-se, it might be enough for the TLS specification to reference an IANA profile registry, with the TLS-WG defining a "base" profile. Then other WGs (including the[ TLS WG) can define additional profiles. -- Viktor.
- [TLS] TLS Provfiles (Was: Call for consensus to r… Jeffrey Walton
- Re: [TLS] TLS Provfiles (Was: Call for consensus … Peter Gutmann
- Re: [TLS] TLS Provfiles (Was: Call for consensus … Stephen Farrell
- Re: [TLS] TLS Provfiles (Was: Call for consensus … Jeffrey Walton
- Re: [TLS] TLS Provfiles (Was: Call for consensus … Salz, Rich
- Re: [TLS] TLS Provfiles (Was: Call for consensus … Peter Gutmann
- Re: [TLS] TLS Provfiles (Was: Call for consensus … Salz, Rich
- Re: [TLS] TLS Provfiles (Was: Call for consensus … Stephen Farrell
- Re: [TLS] TLS Provfiles (Was: Call for consensus … Peter Gutmann
- Re: [TLS] TLS Provfiles (Was: Call for consensus … Peter Gutmann
- Re: [TLS] TLS Provfiles (Was: Call for consensus … Martin Thomson
- Re: [TLS] TLS Provfiles (Was: Call for consensus … Dave Garrett
- Re: [TLS] TLS Provfiles (Was: Call for consensus … Viktor Dukhovni
- Re: [TLS] TLS Provfiles (Was: Call for consensus … Dave Garrett
- Re: [TLS] TLS Provfiles (Was: Call for consensus … Viktor Dukhovni
- Re: [TLS] TLS Provfiles (Was: Call for consensus … Dave Garrett
- Re: [TLS] TLS Provfiles (Was: Call for consensus … Nico Williams
- Re: [TLS] TLS Provfiles (Was: Call for consensus … Dave Garrett
- Re: [TLS] TLS Provfiles (Was: Call for consensus … Jeffrey Walton
- Re: [TLS] TLS Provfiles (Was: Call for consensus … Viktor Dukhovni
- Re: [TLS] TLS Provfiles (Was: Call for consensus … Dave Garrett
- Re: [TLS] TLS Provfiles (Was: Call for consensus … Salz, Rich
- Re: [TLS] TLS Provfiles (Was: Call for consensus … Jacob Appelbaum
- Re: [TLS] TLS Provfiles (Was: Call for consensus … Peter Gutmann
- Re: [TLS] TLS Provfiles (Was: Call for consensus … Hubert Kario
- Re: [TLS] TLS Provfiles (Was: Call for consensus … Blumenthal, Uri - 0553 - MITLL