Re: [TLS] TLS Provfiles (Was: Call for consensus to remove anonymous DH)
Viktor Dukhovni <ietf-dane@dukhovni.org> Thu, 17 September 2015 00:37 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 3CF721A887A for <tls@ietfa.amsl.com>; Wed, 16 Sep 2015 17:37:46 -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 L3_cbQtsA_9H for <tls@ietfa.amsl.com>; Wed, 16 Sep 2015 17:37:45 -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 44A601A1A1D for <tls@ietf.org>; Wed, 16 Sep 2015 17:37:45 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 4C790284AED; Thu, 17 Sep 2015 00:37:44 +0000 (UTC)
Date: Thu, 17 Sep 2015 00:37:44 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: tls@ietf.org
Message-ID: <20150917003744.GE21942@mournblade.imrryr.org>
References: <CAH8yC8=eHzQPL6cROVK4Pm0V2FSYTL7C7csLG7p49W5LEmfo=Q@mail.gmail.com> <201509161837.21743.davemgarrett@gmail.com> <20150916230024.GS13294@localhost> <201509161914.48720.davemgarrett@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <201509161914.48720.davemgarrett@gmail.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/arDZxpLw4GZ0x2wMmXmlcC483MI>
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: Thu, 17 Sep 2015 00:37:46 -0000
On Wed, Sep 16, 2015 at 07:14:48PM -0400, Dave Garrett wrote: > Yeah, we don't need to argue semantics. My point is that I'd agree with > a more strict profile than what we have now as an addon, but not a more > permissive profile, as was the initial suggestion. I don't think that "permissive" vs. "strict" is the right axis to distinguish between profiles. Rather one axis is "Constrained" vs. "General", and another axis is "Opportunistic" vs. "Mandatory". What's different will be the MTI ciphers, and recommended preferred ciphers. Adding crap banned by the base protocol is not the point. In other words, a profile will have: * MUST support parameters (required interop) * SHOULD support parameters (additional preferred) * MAY support parameters * MUST NOT support parameters that can vary over time independently of other profiles. Then folks can go ahead and drop RC4 with prejudice from "Mandatory", while initially leaving it enabled in "Opportunistic". Which profiles are developed depends on how much interest there is in from particular "market segment" to define said profile. The main question is whether enough interested parties will be willing to work on such 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