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