IETF Logo Mail Archive

Re: [TLS] Alexey Melnikov's Yes on draft-ietf-tls-chacha20-poly1305-04: (with COMMENT)

Nikos Mavrogiannopoulos <nmav@redhat.com> Fri, 06 May 2016 07:08 UTC

Return-Path: <nmav@redhat.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CD9612D59D; Fri, 6 May 2016 00:08:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.918
X-Spam-Level:
X-Spam-Status: No, score=-7.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 Cc8QMKWcGZUD; Fri, 6 May 2016 00:08:35 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6C6312D12B; Fri, 6 May 2016 00:08:35 -0700 (PDT)
Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 00F0E80096; Fri, 6 May 2016 07:08:34 +0000 (UTC)
Received: from dhcp-10-40-1-102.brq.redhat.com ([10.40.3.127]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u4678VVo009455 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 6 May 2016 03:08:32 -0400
Message-ID: <1462518511.2994.8.camel@redhat.com>
From: Nikos Mavrogiannopoulos <nmav@redhat.com>
To: noloader@gmail.com, Stephen Farrell <stephen.farrell@cs.tcd.ie>
Date: Fri, 06 May 2016 09:08:31 +0200
In-Reply-To: <CAH8yC8kv_0DrsNG7iucfCVtg2aweEb3ibFSHzHn-8Jh87iCxQg@mail.gmail.com>
References: <572B553B.8050805@cs.tcd.ie> <BN1PR09MB12485CDEFB38C52C21FD223F37C0@BN1PR09MB124.namprd09.prod.outlook.com> <1462459509.3180577.599095937.04C39339@webmail.messagingengine.com> <572B5D61.3020600@cs.tcd.ie> <CAH8yC8kv_0DrsNG7iucfCVtg2aweEb3ibFSHzHn-8Jh87iCxQg@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/B2CIAD1F91-7VwWvFsooCxiMeaM>
Cc: "tls@ietf.org" <tls@ietf.org>, Alexey Melnikov <aamelnikov@fastmail.fm>, draft-ietf-tls-chacha20-poly1305@ietf.org, tls-chairs@ietf.org, The IESG <iesg@ietf.org>
Subject: Re: [TLS] Alexey Melnikov's Yes on draft-ietf-tls-chacha20-poly1305-04: (with COMMENT)
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/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: Fri, 06 May 2016 07:08:37 -0000

On Thu, 2016-05-05 at 12:39 -0400, Jeffrey Walton wrote:
> On Thu, May 5, 2016 at 10:49 AM, Stephen Farrell
> <stephen.farrell@cs.tcd.ie> wrote:
> > 
> > 
> > Thanks all. I updated the RFC editor note to add the FIPS
> > reference.
> > 
> You might also consider mentioning the interop problems that are
> going
> to occur when diverging from Bernstein's reference implementation.
> Its
> already creating open questions on other mailing lists. For example,
> linux-crypto and
> https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1137554.
> html:
> 
>     > +     chacha20_block(&crng->state[0], out);
>     > +     if (crng->state[12] == 0)
>     > +             crng->state[13]++;
> 
>     state[12]++? Or why do you increment the nonce?

I wondered the same when I saw the comment. However, I'm not sure that
is an issue. Chacha20 as a stream cipher is not defined anywhere by
IETF (as far as I know). RFC7539 defines Chacha20-poly1305 AEAD
(authenticated encryption) mechanism which uses a modified chacha20
than the reference algorithm. However, that doesn't really affect any
other uses for the stream cipher. That's maybe the reason for the
confusion.

Bottom line, the comment relates more to RFC7539 rather than this
draft.

regards,
Nikos

v2.23.0 | Report a Bug | By Email