Subject: Secdir telechat review of draft-ietf-tcpinc-tcpcrypt-09

From: Barry Leiba <[email-masked]>
Date: Sat, 11 Nov 2017 21:16:13 -0800

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

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?

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.

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.)

---

From: Kathleen Moriarty <[email-masked]>
Date: Sun, 12 Nov 2017 00:18:48 -0500

Barry,

Thank you for your review.

Kathleen

On Sun, Nov 12, 2017 at 12:16 AM, Barry Leiba <[email-masked]> wrote:
> _______________________________________________
> Tcpinc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpinc

-- 

Best regards,
Kathleen

---

From: Daniel B Giffin <[email-masked]>
Date: Fri, 17 Nov 2017 00:13:54 -0800

Thanks for the review!

>    The wire format of all messages is specified in Section 4.

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.

> 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
	 [...]

> 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.

> is specified between -07 and -09, so this clearly has not even been clear to

Thanks, I've added that as you can see above.

daniel

---

From: Barry Leiba <[email-masked]>
Date: Fri, 17 Nov 2017 17:27:33 +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

> Thanks, I've added that as you can see above.
Barry
--
Barry Leiba  ([email-masked])
http://internetmessagingtechnology.org/