Re: [TLS] WG adoption + early code point assignment: draft-mavrogiannopoulos-chacha-tls

Benjamin Beurdouche <> Tue, 19 May 2015 22:28 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 12AC01B3474 for <>; Tue, 19 May 2015 15:28:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.56
X-Spam-Status: No, score=-6.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HYK7V4naAtbV for <>; Tue, 19 May 2015 15:28:00 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5F8D81B346D for <>; Tue, 19 May 2015 15:28:00 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.13,460,1427752800"; d="scan'208";a="125038269"
Received: from (HELO []) ([]) by with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 May 2015 00:27:58 +0200
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
From: Benjamin Beurdouche <>
In-Reply-To: <>
Date: Wed, 20 May 2015 00:27:57 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
To: Martin Thomson <>
X-Mailer: Apple Mail (2.2098)
Archived-At: <>
Subject: Re: [TLS] WG adoption + early code point assignment: draft-mavrogiannopoulos-chacha-tls
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: Tue, 19 May 2015 22:28:03 -0000

> On 20 May 2015, at 00:14, Martin Thomson <> wrote:
> On 19 May 2015 at 14:51, Yoav Nir <> wrote:
>> 2) I question the need for TLS_DHE_ ciphersuites, and I seriously doubt anybody’s going to use those with ChaCha20 “in the wild”. Other than that, I’m all for early assignment as it would allow us to get the algorithms into code-bases and test interoperability quicker.
> I tend to agree.  Can someone reply with a brief explanation of why
> each of the following is needed?  Hopefully better than what I was
> able to devise:
> Because we’re scared of ephemeral key exchange for some reason ?

I am not, so you shouldn’t =P

> Because ECDHE is good, and RSA is widespread.


> Because this is what we actually want.


> Because we need a backup for EC.

Better safe than sorry.

> Because ECDHE is nice, but we need a backup, even for little things ?

Is this sentence hiding something ? ;)
I am really not sure about this one, why since there is EC…

> Because little things don’t like paying for asymmetric crypto.

Fair enough

> Because little things need nice things too.


> Because little things like doing bignum exponentiation without any PFS
> payoff, but RSA alone isn’t "secure enough" ?

Arf ! chop off it’s RSA ! 

> The thing that concerns me most is that we aren't saying that PFS is
> required outside of PSK.  I understand the carve-out we've made for
> the little things, but I don't understand why we are defining
> RSA-based suites without PFS.
> Of comparable concern is the RSA_PSK stuff.  I wasn't around for the
> definition of these originally, but they make basically no sense to
> me.


> I get the DHE_PSK thing if you justify it using the same basis as
> DHE_RSA, but it might be that the little things can just take a pass
> on PFS without ECDHE.
> Would it be unreasonable to cut the list to ... ?

I completely agree with Martin on this list, we probably do not need more ciphersuites than those.

> Also, I'm not against DHE in general, and I think that it's worth
> keeping around for a little longer. However.  If we consider DHE_RSA
> worth doing, then the only logic I can concoct would provide almost
> equal justification for DHE_ECDSA.

I really don’t think DHE_ECDSA will ever by massively used …
It would be like having RSA_ECDSA =s..


> _______________________________________________
> TLS mailing list