Re: [tcpinc] Secdir telechat review of draft-ietf-tcpinc-tcpcrypt-09

Barry Leiba <barryleiba@computer.org> Fri, 17 November 2017 17:27 UTC

Return-Path: <barryleiba@gmail.com>
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 810F0128DE5; Fri, 17 Nov 2017 09:27:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.718
X-Spam-Level:
X-Spam-Status: No, score=-1.718 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 Ob5WXW7-Cfri; Fri, 17 Nov 2017 09:27:46 -0800 (PST)
Received: from mail-it0-f47.google.com (mail-it0-f47.google.com [209.85.214.47]) (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 567121242F5; Fri, 17 Nov 2017 09:27:46 -0800 (PST)
Received: by mail-it0-f47.google.com with SMTP id y15so4900706ita.4; Fri, 17 Nov 2017 09:27:46 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=QOPIMPnffGsZyG7CvyOrBTz8+m9ph1SLsr814Y3JxaE=; b=Oyhe4FUvsPYHt6bGYvDTnTxsrgoHNoAYl5F7g8+EiAVBcbM7kFwLMhENeVFVo+Ct88 X+9Xj8TS8a6hwlee+G341UZaxwluNzGY7Q4+kJ1s98coMKh9nSnNERZT+itDsyNP3qeU 2Nnnz0vH6otX2o0q58xdiyByCB4bWYd1rtSEdq5OsGk9MOcdmx4ibIzfDzeOX6CJJJky Duy9eXFNWmMMszt3yybyh9EpDInmDIR5+zw0uoed9DerUi0MWvlmtXSLLcpk/fw9PMZb 3fxSsx4j89ffAgvjgow/BqD8VCu8QjVaK+H4ebdXYQGaFpePl5jro9d2ujo1zpGFizAN 4qrA==
X-Gm-Message-State: AJaThX4w1Mu8weDBL+bcz+YwQ3BsFbgSyy7oWy0xmdhiOkTjpSZ5Mk2U aB5oC5qB7/wnvtZim+p1bbl9xmjcnnFqjZVQ164=
X-Google-Smtp-Source: AGs4zMaWrhVWQw99R0xVP7SzZXnGNCd6INipi9qJJRYZYBw0Tn8e8357k8fMqd0xSIXNaoQeTiKE36JhqO8UxcVeBXs=
X-Received: by 10.36.164.75 with SMTP id v11mr8124121iti.33.1510939665335; Fri, 17 Nov 2017 09:27:45 -0800 (PST)
MIME-Version: 1.0
References: <151046377334.30804.5873766900092971520@ietfa.amsl.com> <20171117081354.GC57159@scs.stanford.edu>
In-Reply-To: <20171117081354.GC57159@scs.stanford.edu>
From: Barry Leiba <barryleiba@computer.org>
Date: Fri, 17 Nov 2017 17:27:33 +0000
Message-ID: <CALaySJLEzY8j3Kamavkk3dyfV=c-OvMpu+nauR5-BBBYqFoAAg@mail.gmail.com>
To: Daniel B Giffin <dbg@scs.stanford.edu>
Cc: draft-ietf-tcpinc-tcpcrypt.all@ietf.org, ietf@ietf.org, secdir@ietf.org, tcpinc@ietf.org
Content-Type: multipart/alternative; boundary="f403045fbba80788f8055e310ed0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpinc/ppRUSs9n3QDA9-IKg2MVc4eszeI>
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 17:27:50 -0000

All responses perfect; thanks.  I don’t think there’s a need for a formal
citation to TCP-ENO for the registry, as it won’t be needed once the
registry is created.  It’s only needed for review now, so people like me
don’t scratch our heads.

Carry on...

Barry


On Fri, Nov 17, 2017 at 12:16 AM Daniel B Giffin <dbg@scs.stanford.edu>
wrote:

> 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
>
> --
Barry
--
Barry Leiba  (barryleiba@computer.org)
http://internetmessagingtechnology.org/