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

Nikos Mavrogiannopoulos <nmav@redhat.com> Wed, 20 May 2015 06:58 UTC

Return-Path: <nmavrogi@redhat.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 D9B641A8795 for <tls@ietfa.amsl.com>; Tue, 19 May 2015 23:58:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.312
X-Spam-Level:
X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 wFqk103eVBC3 for <tls@ietfa.amsl.com>; Tue, 19 May 2015 23:58:03 -0700 (PDT)
Received: from mx5-phx2.redhat.com (mx5-phx2.redhat.com [209.132.183.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F81B1A6F27 for <tls@ietf.org>; Tue, 19 May 2015 23:58:03 -0700 (PDT)
Received: from zmail22.collab.prod.int.phx2.redhat.com (zmail22.collab.prod.int.phx2.redhat.com [10.5.83.26]) by mx5-phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t4K6w1Ji036333; Wed, 20 May 2015 02:58:01 -0400
Date: Wed, 20 May 2015 02:58:01 -0400 (EDT)
From: Nikos Mavrogiannopoulos <nmav@redhat.com>
To: Martin Thomson <martin.thomson@gmail.com>
Message-ID: <567925460.1076064.1432105081320.JavaMail.zimbra@redhat.com>
In-Reply-To: <CABkgnnUYZFb5zAVUgQ4LHBBt0cECHoQS4dEofmmH1M5Bn8HZDQ@mail.gmail.com>
References: <FD8B7C3F-C3DD-4367-B84D-26B9907F1B9D@ieca.com> <3FCBCBD5-9295-4A8D-BD27-71377B6B8E7C@gmail.com> <CABkgnnUYZFb5zAVUgQ4LHBBt0cECHoQS4dEofmmH1M5Bn8HZDQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Originating-IP: [94.112.138.148, 10.5.101.181]
X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF31 (Linux)/8.0.6_GA_5922)
Thread-Topic: WG adoption + early code point assignment: draft-mavrogiannopoulos-chacha-tls
Thread-Index: NmMYpdoO1bRAlV+romA6wjBOXBqB2w==
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/z9UMN95NcVdq-esUmXIrc5hhzCM>
Cc: IETF TLS Working Group <tls@ietf.org>
Subject: Re: [TLS] WG adoption + early code point assignment: draft-mavrogiannopoulos-chacha-tls
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: Wed, 20 May 2015 06:58:05 -0000

----- Original Message -----
> 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:

I don't think one would have to explain each and every usage
of a ciphersuite. If applications don't need it they won't use it. 

> TLS_RSA_WITH_CHACHA20_POLY1305
> Because we're scared of ephemeral key exchange for some reason ?

I believe the main argument is that this draft is supposed to provide 
ciphersuites to used by existing protocols and applications which already 
use RSA. Yes, I agree that some of them would need to be updated to provide 
PFS, but this draft doesn't update those apps/protocols. A protocol that
I know that relies on the RSA ciphersuites is the anyconnect vpn protocol
(even though its usage doesn't affect PFS).

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

That was my intention. To provide DHE as backup to ECDHE, since they 
are not susceptible to the same attacks.  It is now
especially relevant since we will have fixed groups for DHE.

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

I don't have much data for this ciphersuite. If someone has a strong argument
on why it shouldn't be included I wouldn't object.

> 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.

I agree. However, note that this draft is not the place to argue for that,
but rather the protocols that rely on non-PFS ciphersuites.

> 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.

The idea was to provide both certificate auth for the server and PSK
auth for the client. The implementation was less than ideal.

> 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.

There is no DHE_ECDSA key exchange defined for TLS. Otherwise there would
be no reason for these ciphersuites to be there.
 
regards,
Nikos