Re: [TLS] Ala Carte Cipher suites - was: DSA should die

Dave Garrett <davemgarrett@gmail.com> Tue, 14 April 2015 04:18 UTC

Return-Path: <davemgarrett@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 1ECA61B3315 for <tls@ietfa.amsl.com>; Mon, 13 Apr 2015 21:18:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham
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 xBNwgi70Dk0A for <tls@ietfa.amsl.com>; Mon, 13 Apr 2015 21:18:02 -0700 (PDT)
Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (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 10DF01B3313 for <tls@ietf.org>; Mon, 13 Apr 2015 21:18:02 -0700 (PDT)
Received: by qku63 with SMTP id 63so218037797qku.3 for <tls@ietf.org>; Mon, 13 Apr 2015 21:18:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=boHVuqQMKfe6r8ufzslekvSgUnc5b4OTMHMES0ftlGs=; b=o9AFxvRqwKH/gmXwhXlPGZufPc9By9tbqFdGxvYhfbc4VREe1xMXGUXK+KF38N6Xgq xIaxKKclinJs+m58ucPPMysa11zjWqHfNX6HwgTJsr+PolaWv+jebrrPJnkvwfwhYCY/ U5QrUFhD5dqbRuQtRhU3Nr6y8lLyJEjolL6Cdp/f8E1o4U9f8cKU6byydzxuD0x6yrcG QSVqsbLBDDT9CHNiKz2yWfgHjf0sG611aEDJJnDVqcnYYEct78KBemD9FJ1SkRoH6Q+G vSLOEzZ3XsRAzjzsrgpe35knROXF9elpsNLf3LxiWkDs2eZUZehdMgpGEUW8ryaanuxU oDDg==
X-Received: by 10.55.20.139 with SMTP id 11mr35707446qku.28.1428985079751; Mon, 13 Apr 2015 21:17:59 -0700 (PDT)
Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id j190sm7442005qhc.33.2015.04.13.21.17.58 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 13 Apr 2015 21:17:59 -0700 (PDT)
From: Dave Garrett <davemgarrett@gmail.com>
To: tls@ietf.org
Date: Tue, 14 Apr 2015 00:17:57 -0400
User-Agent: KMail/1.13.5 (Linux/2.6.32-73-generic-pae; KDE/4.4.5; i686; ; )
References: <CAK9dnSyKf7AY11h1i1h+SudRc-NmTZE5wC682YKhNsxnfV5ShQ@mail.gmail.com> <20150414003658.GB17637@mournblade.imrryr.org> <87oamrs98q.fsf@alice.fifthhorseman.net>
In-Reply-To: <87oamrs98q.fsf@alice.fifthhorseman.net>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201504140017.57848.davemgarrett@gmail.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/v9O4yLS4TK_zUGvW7iC5WJHjnSI>
Subject: Re: [TLS] Ala Carte Cipher suites - was: DSA should die
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Tue, 14 Apr 2015 04:18:04 -0000

On Monday, April 13, 2015 11:02:13 pm Daniel Kahn Gillmor wrote:
> On Mon 2015-04-13 20:36:58 -0400, Viktor Dukhovni wrote:
> > So a key question is whether policies that rule out various corners
> > of the product space are legitimately required???
> 
> Here's one (granted, contrived) policy:
> 
>  * i'm willing to talk to US Government peers (they all want Suite B)
>    and Russian Government peers (they all want GOST).  so my policy is
>    that I want either an all-GOST collection or an all-suite-B
>    collection.  a la carte would suggest that i'd be OK with GOST key
>    agreement combined with suite B symmetric crypto, though i would not
>    consider that OK.

This scenario would be better served by a new extension that requests enforcement of specific sets of capabilities. The new proposals would make more unusual combinations negotiable, yes, but we are already in a situation where stuff from one can get negotiated in another. (e.g. authentication)

So long as things are properly configured and prioritized, this shouldn't be an issue. (e.g. prioritize all of set A before all of set B at both endpoints, and ensure both sets are complete)


Dave