Re: [tcpinc] Secdir telechat review of draft-ietf-tcpinc-tcpcrypt-09
Daniel B Giffin <dbg@scs.stanford.edu> Fri, 17 November 2017 08:13 UTC
Return-Path: <dbg@scs.stanford.edu>
X-Original-To: tcpinc@ietfa.amsl.com
Delivered-To: tcpinc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F5E8128C84; Fri, 17 Nov 2017 00:13:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 fr7pyPV49Q12; Fri, 17 Nov 2017 00:13:56 -0800 (PST)
Received: from market.scs.stanford.edu (www.scs.stanford.edu [IPv6:2001:470:806d:1::9]) (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 EFF96124319; Fri, 17 Nov 2017 00:13:55 -0800 (PST)
Received: from market.scs.stanford.edu (localhost [127.0.0.1]) by market.scs.stanford.edu (8.15.2/8.15.2) with ESMTP id vAH8DtWH089661; Fri, 17 Nov 2017 00:13:55 -0800 (PST)
Received: (from dbg@localhost) by market.scs.stanford.edu (8.15.2/8.15.2/Submit) id vAH8DslG052450; Fri, 17 Nov 2017 00:13:54 -0800 (PST)
Date: Fri, 17 Nov 2017 00:13:54 -0800
From: Daniel B Giffin <dbg@scs.stanford.edu>
To: Barry Leiba <barryleiba@computer.org>
Cc: secdir@ietf.org, draft-ietf-tcpinc-tcpcrypt.all@ietf.org, tcpinc@ietf.org, ietf@ietf.org
Message-ID: <20171117081354.GC57159@scs.stanford.edu>
References: <151046377334.30804.5873766900092971520@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <151046377334.30804.5873766900092971520@ietfa.amsl.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpinc/s4_C0CvskMx-4kcp3tXGSjp2kN0>
Subject: Re: [tcpinc] Secdir telechat review of draft-ietf-tcpinc-tcpcrypt-09
X-BeenThere: tcpinc@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Working group mailing list for TCP Increased Security \(tcpinc\)" <tcpinc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpinc>, <mailto:tcpinc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpinc/>
List-Post: <mailto:tcpinc@ietf.org>
List-Help: <mailto:tcpinc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpinc>, <mailto:tcpinc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 17 Nov 2017 08:13:57 -0000
Thanks for the review! Barry Leiba wrote: > Reviewer: Barry Leiba > Review result: Has Issues > > I’ve looked at Stephen Kent’s review and the discussion thereof, and have > little to add to that. A couple of small things: > > 1. Section 3 says that the subsections “describes the tcpcrypt protocol at an > abstract level.” There is no sense in which this description is abstract, and > I’d prefer that we not try to say it is, because that gives a reader an > expectation that it will be high-level, and perhaps even non-normative. Maybe > this?: > > NEW > This section provides details of the operation of the tcpcrypt protocol. > The wire format of all messages is specified in Section 4. > END Good point, thanks -- for the next draft I've gone with something very similar: This section describes the operation of the tcpcrypt protocol. The wire format of all messages is specified in Section 4. > 2. In Section 7 (IANA), you say: > > Tcpcrypt's TEP identifiers will need to be incorporated in IANA's > "TCP encryption protocol identifiers" registry under the > "Transmission Control Protocol (TCP) Parameters" registry > > I can find no such registry. Can you help me here, maybe give me a URL? Right, that registry is defined in TCP-ENO, which I understand would be published in tandem with this draft. Does that solve the problem, or ought we provide a reference to TCP-ENO here? For now, I've provided at least a hint by mentioning TCP-ENO at the beginning of that sentence: For use with TCP-ENO's negotiation mechanism, tcpcrypt's TEP identifiers will need to be incorporated in IANA's "TCP encryption protocol identifiers" registry under the "Transmission Control Protocol (TCP) Parameters" registry, as in Table 4 below. The [...] > Also, with respect to the new “tcpcrypt AEAD Algorithm" registry: > > Future assignments are to be made under the "RFC Required" policy > > Note that that policy allows for assignments to be made in any RFC stream, > which includes the IRTF, the IAB, and the Independent Stream. Do you really > want people to be able to send documents to the Independent Stream Editor, and > to have them published and make assignments with minimal review? > > You might consider whether “IETF Review” is more appropriate. That allows RFCs > of any type (Standards Track, Informational, Experimental, BCP), but requires > that they be in the IETF stream and have a formal IETF last call. Following the discussion about assignment policy in another thread, I've updated this to use the same policy as TCP-ENO. The paragraph on the "tcpcrypt AEAD Algorithm" registry now reads: In Section 4.1, this document defines "sym_cipher" specifiers in the range 0x0001 to 0xFFFF inclusive, for which IANA is to maintain a new "tcpcrypt AEAD Algorithm" registry under the "Transmission Control Protocol (TCP) Parameters" registry. The initial values for this registry are given in Table 5 below. The AEAD algorithms named there are defined in Section 6. Future assignments are to be made upon satisfying either of two policies defined in [RFC8126]: "IETF Review" or (for non-IETF stream specifications) "Expert Review with RFC Required." IANA will furthermore provide early allocation [RFC7120] to facilitate testing before RFCs are finalized. > It will also help IANA if you make it clear what the valid range of values is > for the “Value” column. Is 0x0000 valid? Is 0xFFFF the maximum? Explicitly > saying that values must be in the range 0x0001 to 0xFFFF inclusive will be > helpful. (I say this with particular note that you changed how the Value field > is specified between -07 and -09, so this clearly has not even been clear to > the spec developers.) Thanks, I've added that as you can see above. daniel
- [tcpinc] Secdir telechat review of draft-ietf-tcp… Barry Leiba
- Re: [tcpinc] Secdir telechat review of draft-ietf… Kathleen Moriarty
- Re: [tcpinc] Secdir telechat review of draft-ietf… Daniel B Giffin
- Re: [tcpinc] Secdir telechat review of draft-ietf… Barry Leiba