Re: [TLS] A la carte handshake negotiation

Kyle Rose <> Wed, 22 July 2015 08:50 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A667D1ACD71 for <>; Wed, 22 Jul 2015 01:50:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WlCqVAdzmqVa for <>; Wed, 22 Jul 2015 01:50:10 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C2AD61ACD29 for <>; Wed, 22 Jul 2015 01:50:09 -0700 (PDT)
Received: by wibxm9 with SMTP id xm9so153018836wib.0 for <>; Wed, 22 Jul 2015 01:50:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=rcoMoGH1rgM+SBt32sq1WQKATK0GnM6b9y0YpAeODeA=; b=nrzS2j24sOU2hfvq+YPlwU39m7bsAq9JUIZIiZuh3PkvIYC8Ef57BXPNYwNMSss25b ufC0TRJwa4iarFheptv/KYfzGRFbLc6zXoDPbQ/Ohzjiz1LixIiETpC7R91sfIDLe5kC FJlkXW7xph7T2TaDTPG80VF2gH1bcF3r79PVE=
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:date :message-id:subject:from:to:content-type; bh=rcoMoGH1rgM+SBt32sq1WQKATK0GnM6b9y0YpAeODeA=; b=R3Bv2uvUmzcytqY3kP0VKpDjPwU9YkP+XMmhLEZeqrRrAGzP3hvAqkLpmmhdklKlCI G750RPf1kiXkD90qfmFF3Njpk9itTOrTCGmjQ8rPnxQeYY4bpdcUNNVgAKR3/X9xeXhf YvxyG9YkxRF2cMwuvAIljWKhR67ZFY8IY2HVM0YkKEijtg1SHIHsTy6zmnPpJk7rcSx1 BM9QEGUuXckZz1tUiv/6xfuUFZ+e3wf3nZoRTDeOV1IKwhMLTcGv1Hn/7NNujKibCqUg j30euR+2eoPv2HUWRaQ5S9VUWHDML/s5px/PWD786rPHTR9n3+QMLOFkmcleHFrnynqJ ftyw==
X-Gm-Message-State: ALoCoQnU851HZ7d+7F7A6A64vSVAtXIJwX0+SiW5Wz8TdAoFCd1FAqcZ7GlMFVT96ll5TeWdJpO1
MIME-Version: 1.0
X-Received: by with SMTP id o20mr4364248wiv.31.1437555008431; Wed, 22 Jul 2015 01:50:08 -0700 (PDT)
Received: by with HTTP; Wed, 22 Jul 2015 01:50:08 -0700 (PDT)
X-Originating-IP: [2001:67c:370:176:e898:8358:a694:653c]
In-Reply-To: <>
References: <> <> <> <>
Date: Wed, 22 Jul 2015 04:50:08 -0400
Message-ID: <>
From: Kyle Rose <>
To: "<>" <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Subject: Re: [TLS] A la carte handshake negotiation
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 22 Jul 2015 08:50:12 -0000

I'd like to see the bits of the cipher suite associated entirely with
ephemeral data tied together roughly by security margin, to avoid
combinations that don't make sense (e.g., straw men of RSA384 + AES256
or AES256 + CRC32). This means: the type/size of the (EC)DHE group and
the symmetric cipher (and possibly the MAC, if it's anything other
than "GCM"). So, you'd potentially have something like



The signature algorithm (ECDSA, RSA, etc.) would be entirely separate.
This isn't like the old days when the RSA key was used to exchange the
keys: in the FS world, RSA is never used for key agreement, so
RSA/ECDSA is used only to authenticate the server and is therefore
orthogonal to the cipher suite negotiated above... and it's also
implicit from the set of certificates the server has available.

This unfortunately means we can't really tie the signature security
margin to the cipher suite (going back to the RSA384 straw man), but
since it's a pre-existing credential nothing can be done by the client
other than to hang up if it's spooked by that. To fix this, we'd
really need to go down the road of specifying the key size in the
cipher suite, e.g. RSA2048 or ECDSA25519, which I'm not sure anyone

Does anyone want that? I ask because there are a ton of servers with
1024-bit RSA keys negotiating AES256-GCM, which tells an attacker
exactly what to focus on. (In theory: a tire iron is still probably
faster than factoring RSA1024.)

The nice thing about the above approach is that IMO it actually makes
things simpler for an implementer: the cipher suite list becomes a lot
smaller but still covers most of the options, avoiding the complexity
of full a la carte, while the signature algorithm is implicit for the
server. So, we're not at libsodium level of simplicity, but closer.

The one thing I'm having trouble pinning down is PSK. I fear it's not
a separate dimension, because it replaces both signature and KEX.