Subject: [tcpinc] TCP-ENO: David Black's review

From: "Black, David" <[email-masked]>
Date: Wed, 29 Jun 2016 00:17:05 +0000

I'm likely to be the shepherd for this draft (but if anyone else is interested,
please email the WG chairs - [email-masked]).  

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-masked]        
----------------------------------------------------

---

From: Derek Fawcus <[email-masked]>
Date: Wed, 29 Jun 2016 07:29:14 +0100

> 		handshake (e.g., possibly for encryption renegotiation).

Actually,  that section (4.2) struck me as reasonable.

Ignoring 'a' for the moment,  and looking at 'b':  the whole point of this mechanism
is to pick / negotiate an encryption scheme.  Once picked for a given TCP connection
I can't really see the scheme being changed (i.e. between tcpcrypt and use-tls).

Having encryption params within the scheme being renegotiated seems likely,  but not
changing the scheme,  as such I can't see the need to preclude reuse of the option
values for per scheme use once the scheme is selected.  The actual use I was expecting
was that the per scheme renegotiation would/could use those values for negotiating
new keys, or other per-scheme values.

DF

---

From: "Black, David" <[email-masked]>
Date: Wed, 29 Jun 2016 12:45:50 +0000

Hi Derek,

> new keys, or other per-scheme values.

Hmm - looks like I may have misread this text last night as releasing the option for arbitrary
usage.  I suppose what is there is ok, but I'd prefer to see another option kind allocated for
encryption spec usage (if we anticipate that being needed) rather than overloading the
TCP-ENO option kind.

Thanks, --David

> -----Original Message-----
> From: Tcpinc [mailto:[email-masked]] On Behalf Of Derek Fawcus
> Sent: Wednesday, June 29, 2016 2:29 AM
> To: [email-masked]
> Subject: Re: [tcpinc] TCP-ENO: David Black's review
> 
> _______________________________________________
> Tcpinc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpinc

---

From: Joe Touch <[email-masked]>
Date: Wed, 29 Jun 2016 09:54:03 -0700

> encryption spec usage (if we anticipate that being needed) rather than overloading the

AFAICT, the encryption spec is a component of TCP-ENO. This wouldn't be
"overloading", but a sub-field or variant.

IMO, TCP option kind numbers ought to be assigned only for independently
useful options.

Joe

---

From: Kyle Rose <[email-masked]>
Date: Wed, 29 Jun 2016 13:49:29 -0400

</chair>

[M] The third paragraph on randomness sources should refer to RFC 4086 and
> MUST NOT

After briefly perusing RFC 4086, I'm not sure anyone anywhere should
reference it anymore.

I'll go into more detail on the CFRG mailing list when I get a chance, but
my immediate thoughts are that RFC 4086 reads more like an academic field
survey, not a best practices document, and that it doesn't reference the
actual BCP of 2016, which is to use HKDF. (It does include a description of
X9.82, which is probably also okay, but is buried near the end of the
document, long after an implementor would have gone to sleep.)

Kyle

---

From: "Black, David" <[email-masked]>
Date: Wed, 29 Jun 2016 19:15:46 +0000

> IMO, TCP option kind numbers ought to be assigned only for independently

Ok, I stand corrected on that one ... please ignore that comment on 4.2.

Thanks, --David

> From: Joe Touch [mailto:[email-masked]]
> Sent: Wednesday, June 29, 2016 12:54 PM
> To: Black, David; Derek Fawcus; [email-masked]

---

From: David Mazieres <[email-masked]>
Date: Wed, 29 Jun 2016 12:58:29 -0700

"Black, David" <[email-masked]> writes:

> I'm likely to be the shepherd for this draft (but if anyone else is
> interested, please email the WG chairs - [email-masked]).

Thanks for the feedback.  We're about to release a new draft of TCP-ENO.
I'll try to incorporate some of your feedback, but want to get the new
draft out as soon as possible, so might end up releasing two drafts in
rapid succession.  Anyone else considering reviewing TCP-ENO who hasn't
started reading yet might want to wait a day or two...

High-level, in addition to addressing specific feedback we got before,
we are trying to separate the "what" from the "why," so that someone who
just wants to implement TCP-ENO doesn't have to wade through a bunch of
rationale to see what to do.  This is something Jana has been pushing
for a while, and I think it will make for a better document, but the
changes are pretty extensive, which is what is delaying the next draft.
So basically I probably want to get through that restructuring before I
turn to your feedback, but should be able to get to both in the next
week.

Sorry for the bad timing.

David

---

From: "Black, David" <[email-masked]>
Date: Wed, 29 Jun 2016 21:09:17 +0000

Some of my comments are also about separating "what" and "why", so
focusing on that sounds like a good first step.

Thanks, --David

> From: David Mazieres [mailto:[email-masked]]
> Sent: Wednesday, June 29, 2016 3:58 PM
> To: Black, David; [email-masked]
> Cc: Black, David

---

From: Jana Iyengar <[email-masked]>
Date: Wed, 29 Jun 2016 21:59:57 -0700

Thanks for the heads-up David (Mazieres), I was about to start reviewing.
I'll wait until your next draft is out.