RE: Gen-ART LC review of draft-ietf-tls-chacha20-poly1305-04 - resend

"Roni Even" <ron.even.tlv@gmail.com> Fri, 08 April 2016 14:36 UTC

Return-Path: <ron.even.tlv@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDA6B12D518; Fri, 8 Apr 2016 07:36:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 IHJDWnbZDWsU; Fri, 8 Apr 2016 07:36:57 -0700 (PDT)
Received: from mail-qg0-x22c.google.com (mail-qg0-x22c.google.com [IPv6:2607:f8b0:400d:c04::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACD2A12D18A; Fri, 8 Apr 2016 07:36:57 -0700 (PDT)
Received: by mail-qg0-x22c.google.com with SMTP id j35so91780644qge.0; Fri, 08 Apr 2016 07:36:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=3N2eKeN3wxbTTL9cHkZLRIT8cgK6eUGYUiirttNC9Cs=; b=bxcfeOMBZ8PHNSaY1WTAaKEiWFuqPOHFKe1Rz4bMftd9GNXZ4ZQiQgARnWBJzCIr/W X15jRSHSMHX5lPZK9bPQI/nfTi9cBow2CefW6vFDbUQHQkJ4ENqJXBdToQIiJ1+leeZH qbW6MzMKFal+8/2VXZiDK04HFPQQaBHznAGZR2uPIhVlhfJnCxXffdpw65BdOWtui2Xf kyhD6CHUUVS8yRRk3w+KlEctS677YhHUhKjJzdT/srLkHx4vSPfdMf/UTF1qApaJppZe WQIs7yvDzxdTACJpy/v7dMKRe2ul4OBj8xqzaeJ0ioSi6wheitcY2lULt0TSk+uJTB3U j6rQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=3N2eKeN3wxbTTL9cHkZLRIT8cgK6eUGYUiirttNC9Cs=; b=TO1BG0Tf+caAhjPSx4v8UvcLikaHEFH3Ag6VvF3Y2L0gamgtlYaI2FHhzJxSNGCnUl dzJxotnafT6M56bu6BaCI2AQ0h6gRJDzAlWSm0CpIo7G+I0oZcgPiIo4VfZvBC4mXGnA i6PKXGL7hsdllCb/An1/cB3+mBBDtAyOANDyA90SDTf1EQtFfDyuJnfJl1pvp9/aVu1o 63NBbxkW+kHnn/v6+j4aXKi6H+cFEP02kPcdDeFyc7LoaAY89A6AhJ/PdMyvTYp8oXlq lyjQmKwj7bXdbwnyTZS+dDH8p01T+pbV1E3u6Fx2U181vTLbYm+Tz6zOGkscG4wR+gE1 ZlKw==
X-Gm-Message-State: AD7BkJIynFnkMTQLPq9pUdTl3PTEQcRyxOhNYCHit4e4vfu75Iz7rdBZoyq/DgYt2CtO/Q==
X-Received: by 10.140.153.135 with SMTP id 129mr12342244qhz.38.1460126216845; Fri, 08 Apr 2016 07:36:56 -0700 (PDT)
Received: from RoniPC ([2001:67c:370:176:1193:10da:961:ce1]) by smtp.gmail.com with ESMTPSA id b67sm5587871qhd.11.2016.04.08.07.36.54 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 08 Apr 2016 07:36:55 -0700 (PDT)
From: "Roni Even" <ron.even.tlv@gmail.com>
To: "'Sean Turner'" <sean@sn3rd.com>
References: <017a01d190ca$ace223b0$06a66b10$@gmail.com> <A8A038B3-E10F-4A94-99D3-2C4D23A6E065@sn3rd.com>
In-Reply-To: <A8A038B3-E10F-4A94-99D3-2C4D23A6E065@sn3rd.com>
Subject: RE: Gen-ART LC review of draft-ietf-tls-chacha20-poly1305-04 - resend
Date: Fri, 8 Apr 2016 17:36:51 +0300
Message-ID: <00d901d191a4$185fa340$491ee9c0$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQIM3GM2urfPwNWEbUqsemq3RkNvLQCQN/CbnwUH76A=
Content-Language: he
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/7cv9u5iYrHrdSBRfjZG_BlscSwk>
Cc: gen-art@ietf.org, draft-ietf-tls-chacha20-poly1305.all@ietf.org, ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Apr 2016 14:37:00 -0000

Hi Sean,
Inline
Roni

> -----Original Message-----
> From: Sean Turner [mailto:sean@sn3rd.com]
> Sent: Friday, April 08, 2016 3:27 PM
> To: Roni Even
> Cc: ietf@ietf.org list; gen-art@ietf.org; draft-ietf-tls-chacha20-
> poly1305.all@ietf.org
> Subject: Re: Gen-ART LC review of draft-ietf-tls-chacha20-poly1305-04 -
> resend
> 
> 
> > On Apr 07, 2016, at 09:40, Roni Even <ron.even.tlv@gmail.com>; wrote:
> >
> > I am the assigned Gen-ART reviewer for this draft. For background on Gen-
> ART, please see the FAQ at
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>;.
> >
> > Please resolve these comments along with any other Last Call comments
> you may receive.
> >
> > Document:  draft-ietf-tls-chacha20-poly1305-04
> >
> > Reviewer: Roni Even
> >
> > Review Date:2016–3-28
> >
> > IETF LC End Date: 2016–4-9
> >
> > IESG Telechat date:
> >
> >
> > Summary: This draft is almost ready for publication as a standard track
> RFC.
> >
> >
> >
> > Major issues:
> > I am wondering why this is a standard track document and not
> > informational since the registration requirements are specification
> > required.  (RFC5246)
> 
> I’m not sure I agree that Specification Required implies informational track.
> Specification Required permits registrations from
> informational/experimental drafts, but it certainly doesn’t require
> informational/experimental.
> 
> Also note, the registry rules are:
> 
> 0-191	Standards Action			Refers to value of first byte
> 192-254	Specification Required		Refers to value of first byte
> 255		Reserved for Private Use  	Refers to value of first byte
[Roni Even] So  I would like to assume that there was a reason to have two different policies so why not follow it.
> 
> > I am also wondering why this document updates RFC5246 and RFC6347.
> > Reading the document it looked to me that the registration document is
> used also to endorse this cypher suite by the IETF and if this is the case my
> view is that there should be two documents, one Informational for
> registration and the will be standard track and update RFC5246 and RFC6347
> For Example the following text from section 1 “Therefore, a new stream
> cipher to replace RC4 and address all the  previous issues is needed. “
> provides what may look as a normative recommendation.
> 
> As far as the updates header:
> 
> The RC4 stream cipher which was in TLS1.0-1.2 is now prohibited [RFC7465]
> (note not deprecated it’s prohibited) and ChaCha20-Poly1305-based ciphers
> are the replacement.  So, we do in fact want folks who were using RC4 to
> switch to ChaCha20-Poly1305, hence the updates header.
> 
> As far as splitting the registrations/updates:
> 
> What you’re suggesting is certainly one way to do it, but the way we’ve been
> doing it for years in the security area (e.g., TLS, IPSec, S/MIME, PKIX) is as
> follows (there have, of course, been exceptions):
> 
> - (if needed) Informational RFC for algorithm
> 
> - Standards track RFC for how to use algorithm with security protocol. This is
> how AES, Camellia, etc. were documented for TLS.

 [Roni Even] So this is the standard track RFC, I still do not get it
>From  RFC4346 a.5 "Cipher suite values with first byte decimal 192 (0xC0) through
         decimal 254 (0xFE) inclusive are reserved for assignment for
         non-Standards Track methods."

So this is the reason to have the registration as non standard document.   I looked at Camellia and it follows your explanation except for updating the TLS specification yet it uses the first byte from the range 0-191.  So my question will be why did you use the first byte from 192 - range?




> 
> Also in play here is the need to avoid a bunch of DOWNREFs because two of
> the ChaCha20-Poly1305 suites are SHOULDs in the draft TLS1.3.  DOWNREFs
> aren’t anything to be scared of, but where we can avoid them I think we
> should.
> 
> I guess I’d rather not devise new process and just keep on doing what we’ve
> been doing.
> 
> spt
> 
> PS we are currently in the process of discussing a change to make the entire
> range (minus the reserved) specification required, but that won’t complete
> for a while and the implementers want this now (technically yesterday).