I'm likely to be the shepherd for this draft (but if anyone else is interested,
please email the WG chairs - [email protected]).
Back before Mirja became our AD, she commented that this draft read more like
a research paper than a standard that is intended to be used for implementation.
Towards that end, I have a number of suggestions for improvements (based on
draft-ietf-tcpinc-tcpeno-01). This review is not written in my WG chair role,
e.g.,
it is a review, not instructions or demands - discussion and pushback are
definitely
welcome.
I should first comment that the draft is reasonably clear and comprehensible,
and
reflects the significant effort that has gone into writing it.
Ok, on to the suggestions ...
[A] The Introduction (Section 2) is too long. I would send the bullet list of
possible
forthcoming changes (e.g., increased option space) off to a later section or
even
an Appendix, leaving the paragraphs before and after it in place.
[B] The list of design goals at the end of the Introduction is good - it would
help to
put them into their own section (3) or subsection (2.1).
[C} After the design goals, a paragraph or two are needed to explain all the
pieces
that make up TCP-ENO - options, suboptions, marker bytes and transcripts - in
essence this is asking for a summary that explains the organization of Section
3.
[D] Section 3 on the option itself mixes data structure specification with
usage
specification. It would be much clearer to specify the contents of the option
here
and move all the usage info down to Section 3.2 on the handshake. The usage
info to be moved is a minor part of this section:
- First paragraph, except for its first sentence.
- Parenthetical comment about graceful fallback in second paragraph
- Paragraph on TCP SYNC segment contents.
[E] I would reverse the order of Sections 3.1 and 3.2 to describe the handshake
(3.2, of general applicability) before the simultaneous open tiebreaker (3.1,
mostly
about a special case). Both sections will need some text edits. As part
of this
consider presenting all the handshake examples except for the simultaneous open
example after the handshake specification - this would then be followed by
current
section 3.1 on simultaneous open tiebreaking and the final example.
[F] Sections 3.3 and 3.4 ought to better connect the suboption length material
in
3.4 with the suboptions themselves in 3.3. The primary concern is that the
marker
byte in 3.4 comes as a bit of a surprise after reading 3.3 on suboptions. The
first
paragraph in this section ought to explain the relationship of suboptions and
marker
bytes (including the situations where marker bytes are used vs. omitted). The
rest
of the text can probably remain in about its current order - specify general
suboptions,
then marker bytes.
[G] Section 4.2 - NO, don't do this! The option kind will be assigned to
TCP-ENO by
IANA, and allowing this class of reuse:
a) almost certainly violates the rules for the registry from which that
kind
value is assigned.
b) prematurely closes off opportunities to use the option after the
initial
handshake (e.g., possibly for encryption renegotiation).
[H] Section 5 should just be deleted - deal with this in the separate API draft.
[I] Section 6 should be entirely about experiments - the "Open Issues" title of
Section 6 should be changed, but the contents of Sections 6 and 6.1 look
reasonable.
[J] OTOH, I'm not sure about 6.2 - can that experiment be effectively run with
TCP-ENO as currently specified.
[K] First paragraph of section 7 needs to be expanded and strengthened.
- Define opportunistic encryption.
- Make it clear that it's unauthenticated at the TCP level.
- Make the warnings about MiTM and downgrade attacks
blunter and nastier.
- Explain in more detail what "fold the session ID into authentication"
means, and provide an example that gets this right. There
are lots of ways for people who aren't crypto experts to get
that wrong.
Explain how/why this protects against MiTM attacks.
[L] The second paragraph doesn't say enough about the security role/purpose
of the negotiation transcript. One possibility is to move the content after
the
second sentence up to section 3.5 and add text describing the purpose of the
negotiation transcript (downgrade and related negotiation attack countermeasure)
along with a pointer back to 3.5 for the complete discussion.
[M] The third paragraph on randomness sources should refer to RFC 4086 and MUST
NOT
use the term "pseudo-randomness" as this will be understood by implementers to
refer
to horribly insecure PRNGs. Just refer to RFC 4086, and make sure that
whatever is
said here is consistent with that (both content and terminology usage).
[N] The IANA considerations are seriously inadequate. The first sentence is
ok,
but it needs to identify the registry - it's the TCP Option Kind Numbers
subregistry of
the Transmission Control Protocol (TCP) Parameters at :
http://www.iana.org/assignments/tcp-parameters/tcp-parameters.xhtml
The second sentence is effectively a placeholder. Much more text needs to be
written
to tell IANA how to establish and manage the suboption values registry. See
RFC 5226
for a long discussion of what has to be specified, and RFC 6580 may be a useful
source
of examples. As part of this, one or more cs values should be set aside
permanently
for experimental use. As one of the authors of RFC 6580, I can help with the
IANA
Considerations text.
Thanks, --David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC, 176 South St., Hopkinton, MA 01748
+1 (508) 293-7953 Cell: +1 (978) 394-7754
[email protected]
----------------------------------------------------
_______________________________________________
Tcpinc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tcpinc
