Re: [TLS] Refactoring the negotiation syntax

Kyle Rose <> Mon, 18 July 2016 15:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7100512D0E8 for <>; Mon, 18 Jul 2016 08:51:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id df5wiiD35rOU for <>; Mon, 18 Jul 2016 08:51:19 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E7D1112D08E for <>; Mon, 18 Jul 2016 08:51:17 -0700 (PDT)
Received: by with SMTP id p74so160848061qka.0 for <>; Mon, 18 Jul 2016 08:51:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wXTHet+wJXVdeOkbpk0tOB/8w4TPlPWyEFbtSc4JrTs=; b=rRg2HQIIM7ia/cU8iWRJK9fG6yJ9znhg5TjUb+MyfRFUGpxzQNM6et9MqewjrXL7fl hFws9vcS9QsSOjHLvPbQbqLzSK+5DnRr1yx5zeju76I6zWushqMyZFnUhYbc5D7H7Oyz FA8XprHQzG6TI4QZ0y/bOzghh2Fns+u7zz0CE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wXTHet+wJXVdeOkbpk0tOB/8w4TPlPWyEFbtSc4JrTs=; b=hkdpZqC2ICJi2LtqCdZUOT4ggwJpKnJn89sMGq5mSqT+yCJrhx0nIpRzNh3h3ubSEJ SPIuXsncLkomPO+6KcV3Nk7EWhBmu2xzsZmnXN4emf/UtcuAH8NauEDBjQACqWgtHfSC EZgJW3dJXGjRZgFm+j3YT9eGYb5954Xtsy6Yk8KjV8TxqeOp+QxyvQfdxAAUVyxlmKYM PtaorcNpMNqYMMhOzCHC6h+AOlr/efOSZdeX2YtWSownI4ImYUajfnCT0etRHkVkEoqR BUR1fMyB//h7Dbb6eJJcIM89JkeaQ/33k3xDeDJbBSV6uffHYhDaTGTjFjIoBFI9OrW0 hzcQ==
X-Gm-Message-State: ALyK8tIYCCypAu/2/JhtQicopOvDMfO6KwbgVBa5s6LiRiOBIS1aOqSZwOp7YjaW5l6mGVLqjJN2uT6V5XX2bQ==
X-Received: by with SMTP id l67mr45489163qkd.17.1468857076708; Mon, 18 Jul 2016 08:51:16 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Mon, 18 Jul 2016 08:51:15 -0700 (PDT)
X-Originating-IP: []
In-Reply-To: <>
References: <> <> <>
From: Kyle Rose <>
Date: Mon, 18 Jul 2016 17:51:15 +0200
Message-ID: <>
To: Ilari Liusvaara <>
Content-Type: multipart/alternative; boundary="94eb2c0731e6490afb0537eaf0a3"
Archived-At: <>
Cc: "<>" <>
Subject: Re: [TLS] Refactoring the negotiation syntax
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 18 Jul 2016 15:51:21 -0000

On Mon, Jul 18, 2016 at 5:07 PM, Ilari Liusvaara <>

> > Tl;dr: I think this is a good approach because it eliminates much of the
> > existing negotiation redundancy/complexity and combinatorial explosion in
> > the 1.3+ ciphersuite menu.
> I recently tried to write code to handle this ciphersuite negotiation, so
> that it always negotiates a valid choice if any valid choice exists.
> I think the end result was insane. The problem that makes it so difficult
> is that legacy signature types, group types and protection/PRFs interact,
> so not all supported offers that server has enabled are actually possible
> to chose.

It may also be that combinatorial explosion in ciphersuites just isn't a
problem in reality: that there should be so few choices offered in the
standard, with those believed to be secure, and new ones introduced only
when they are actually needed, not simply when there is something shiny and

> If you are talking about "strength-matching", there is no sane notion of
> security equivalence with protection, key exchange and signatures (due to
> different sub-threshold, multi-key and period properties).
> ....
> IMO, no it is not necressary to tie the security margins. In case of
> authentication and encryption, there is also the issue that authentication
> is good if it is unbroken at that moment, whereas key exchange and
> encryption
> must remain unbroken for long time since.
> So that someone thinks ECDSA P-256 is OK for authentication does not mean
> that the same entity thinks ECDHE P-256 is OK for key exchange. Or to think
> that 128-bit symmetric encryption is OK.

Yeah, this is a really good point. This argues for a complete separation of
authentication (over which the client has no control) from the rest of the
security parameters. In some sense, the KX and symmetric cipher are still
tied together as a break in either in the future will reveal confidential
data, but I'll concede the point that there is no sane way to tie security
margins between KX and cipher suite.

> And coupling those in a way that doesn't lead to great difficulty (even
> greater than currently) REALLY causes the ciphersuite space to
> combinatorially explode.

The combinatorial explosion I was referring to was that of consuming code
points for multiple combinations of things that have a separate negotiation
mechanism (e.g., SignatureAlgorithms). But maybe it's not a problem in

> Or maybe prospective security margin is too complex and/or too ill-defined
> > to bother with, and a server should just choose the least CPU-intensive
> > combination of everything.
> Well, yeah, it is ill-defined. Of course, there can be bad algorithms
> that one wants to disable.
> However, interactions between bad algorithms are much less likely than
> actual bad algorithms causing problems by themselves.

I'm more concerned about the a la carte approach admitting bad ciphers or
PRFs that then get implemented naïvely by completists, but I suppose that
problem still exists when they are tied together. And maybe this won't be a
problem in practice in the presence of a "recommended" column in the