Re: [TLS] TLS Provfiles (Was: Call for consensus to remove anonymous DH)

Jeffrey Walton <noloader@gmail.com> Wed, 16 September 2015 10:47 UTC

Return-Path: <noloader@gmail.com>
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 B8DAE1A1BE0 for <tls@ietfa.amsl.com>; Wed, 16 Sep 2015 03:47:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.019
X-Spam-Level:
X-Spam-Status: No, score=-0.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FRT_PROFILE2=1.981, SPF_PASS=-0.001] 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 7d6mjpTYtZCG for <tls@ietfa.amsl.com>; Wed, 16 Sep 2015 03:47:02 -0700 (PDT)
Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C56A1A1B6A for <tls@ietf.org>; Wed, 16 Sep 2015 03:47:02 -0700 (PDT)
Received: by igxx6 with SMTP id x6so29620333igx.1 for <tls@ietf.org>; Wed, 16 Sep 2015 03:47:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=KJH03oUjrxcJg7EGFzW5fejkkQuNMqmshb3X1Vo3kOk=; b=dXgX/fwUO976I0uZmDWVPYFOUDyNg/NBX25qwvQowIzz70biw0vRrLkPgLhdnyO4Vd imfEJf/ZoBCT46CNMURtQQir9VSx+XuuIUMx2pHzhfozkcMqV5JP09cmu7fo/kCy7GPM gIVmplmLVEiJCO1s3Y4SGEk9ihuPmOekBa6HONZiGOeSNZkK4C8/I5Hfzhr6wMuuymc8 b9KQhf58+yEZyJk4am3qxycY+vxBlpA/OtLpOVqk0PFZodPf060pte2qkzumCB7TZsT4 5P1UCWG7dF0z6sAFExagGK9qm8q37i5chgOje1EJgn4raFJz+N9e9x4xtdUTi76b0w2+ y/XA==
MIME-Version: 1.0
X-Received: by 10.50.102.4 with SMTP id fk4mr14890186igb.46.1442400422024; Wed, 16 Sep 2015 03:47:02 -0700 (PDT)
Received: by 10.36.123.131 with HTTP; Wed, 16 Sep 2015 03:47:01 -0700 (PDT)
In-Reply-To: <55F92C1A.9060703@cs.tcd.ie>
References: <CAH8yC8=eHzQPL6cROVK4Pm0V2FSYTL7C7csLG7p49W5LEmfo=Q@mail.gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4B070E6@uxcn10-tdc05.UoA.auckland.ac.nz> <55F92C1A.9060703@cs.tcd.ie>
Date: Wed, 16 Sep 2015 06:47:01 -0400
Message-ID: <CAH8yC8ngneyDcQvTi44fCaxShhw0ExSuwhZtQcAdq1SnOOZSFQ@mail.gmail.com>
From: Jeffrey Walton <noloader@gmail.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/gHHph5pimC-htySjtHw6CwXM5sY>
Cc: "tls@ietf.org" <tls@ietf.org>
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: noloader@gmail.com
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 10:47:03 -0000

On Wed, Sep 16, 2015 at 4:45 AM, Stephen Farrell
<stephen.farrell@cs.tcd.ie> wrote:
>
>
> On 16/09/15 09:19, Peter Gutmann wrote:
>> Jeffrey Walton <noloader@gmail.com> writes:
>>
>>> Somewhat off-topic, why does TLS not produce a few profiles. One can be
>>> "Opportunistic TLS Profile" with a compatible security posture and include
>>> ADH. Another can be a "Standard TLS Profile" and include things like export
>>> grade crypto, weak and wounder ciphers SSLv3, etc. Finally, there can be a
>>> "TLS Defensive profile" where you get mostly the strong the protocols and
>>> ciphers, HTTPS Pinning Overrides are not allowed so the adversary cannot
>>> break the secure channel by tricking a user, etc.
>>
>> +1.  At the moment you're stuck with everything-all-the-time (or alternatively
>> one-size-misfits-all) where you have to support every single mechanism and
>> quirk and add-on, when all you want most of the time is to set up a basic
>> secure tunnel from A to B.  Having profiles would be a great help, so all the
>> other standards groups that build on TLS can refer to, say, the emebedded-
>> device profile or the PFS-with-PSK profile rather than having to hack around
>> the standard themselves.
>
> We have BCP195 [1] that aims for the "general" case (for
> up to TLS1.2) and a draft [2] (current in IESG evaluation)
> for the embedded case. Are those the kind of thing you're
> after?
>
> If so, and you wanted more, the UTA WG [3] (which produced
> BCP195) would maybe be the best place to see if there's
> enough interest in doing more. (The embedded one was done
> in the DICE WG [4] which was setup mostly for that as it's
> to some extent a different set of folks. And that could be
> done again if needed.)
>
This kinda begs the question, who should be responsible for high level
TLS configurations to ease management, maximize security and minimize
interoperability issues.

For that, I'd argue it falls squarely within TLS WG purview.

One of the things I've noticed (maybe incorrectly): the NSA and other
who want to exert influence do not have to influence a group like the
TLS WG.* There's enough mass and dissension that weakening is organic.
A small selection of profiles could be a strategic move to cut-off
that avenue if it is being taken advantage of.

Strategic planning is something that should to be led by leadership.

Jeff

* Maybe I should say, "not actively influence them", like the case of
RSA Data Securities and the Dual EC generator.