Subject: [tcpinc] TCP-ENO draft 02 review

From: Kyle Rose <[email-masked]>
Date: Fri, 1 Jul 2016 19:55:35 -0400

This is a review of the latest TCP-ENO draft (02). I am acting as member,
not chair.

[3] Under the Passive Opener description, you have:

Passive opener
      A host that does not send a SYN-only segment (only a SYN-ACK
      segment).  With the BSD socket API, this occurs following a call
      to "listen".  In client-server configurations, passive openers are
      typically servers.

The language is a little garbled. (Not sending a SYN-only segment is what
occurs following a call to listen?) I might reword this as something like:
q( A host that does not send a SYN-only segment, only a SYN-ACK segment in
response to an incoming SYN-only segment. With the BSD socket API, this is
the behavior of a socket following a call to "listen". ).

[4] I feel like "spec" is being overloaded to mean algorithm, protocol, and
functional specification. I also suspect everyone knows what you mean, so
maybe clarifying it isn't worth the effort. I really only noticed it when I
hit the line q( It uses a new TCP option kind to negotiate one among
multiple possible encryption specs--separate documents describing how to do
actual traffic encryption ), because you're not negotiating documents,
you're negotiating either an algorithm or a protocol.

[4] q( A negotiation transcript that the negotiated spec must
cryptograhpically authenticate ). Spelling error, plus this seems possible
only with authentication of the session ID: without it, an active attacker
can just break a connection into two separate connections and negotiate
well-formed transcripts with each of the original endpoints. To prevent
option twiddling (e.g., to force downgrade) without a full MitM attack, I
think the required property is that the negotiation transcript be
incorporated into the key derivation so any change to the options will
result in an AEAD failure. (Maybe that's what you meant.)

[4.1] I'm mostly going to leave this issue to David Black, but IMO all
references to option 69 should just be removed from the document.

[4.2] The description of the "m" bit should maybe include a forward
reference to section 7.1, because here it seems a bit mysterious. Also not
sure where "shared libraries" comes in.

[4.4] The line q(  A suboption preceded by a length byte MUST be a spec
identifier ("cs >= 0x20") and MUST have "v = 1" ) precludes q( If the octet
following a length byte has the high bit clear ).

[4.4] It seems like a client conforming to a future revision of this spec
would forever be unable to use zzzz != 0 and negotiate encryption with
implementations based on this spec, which probably makes sense since it
might be encoding length in a way an old implementation couldn't
understand, rendering the rest of the suboptions unparseable. I'm guessing
any attempt to use a non-zero zzzz in SYN-only segments would result in a
new ENO option kind, so I wonder if it wouldn't be better just to list the
4 '0's explicitly.

Alternatively, since a TCP option itself is limited to 255 bytes by virtue
of the option format, maybe we should assume zzzz will never be part of the
length but might encode some other suboption-specific information, and so
mandate that any use of non-zero zzzz MUST result in successful
backwards-compatible encryption negotiation if there exist other valid
specs among the suboptions.

(I have an informational question for TCP gurus that I haven't been able to
find an answer to in a few minutes of searching: what is TCP's defined
behavior in the presence of unknown options? Options 0 and 1 lack a length
byte; is it the case that all other options are assumed to have a length
byte? RFC 793 seems to punt on the question by stating that "A TCP must
implement all options", which obviously cannot be true today since option
kinds >=3 have been introduced.)

[4.7] q( In particular, an encryption spec MUST fail with high probability
if its selection resulted from tampering with or forging initial SYN
segments.). See my objection to [4] above: if "forging" includes a MitM
attack, this is not possible without authentication of the resulting
session ID.

[5.1] Would it make sense to clarify that the session ID is a real value
that must be computable by both endpoints, not just an abstraction used in
a security proof? Maybe just starting the section with q( Each spec MUST
define a session ID that uniquely identifies each encrypted TCP connection
and that is computable by both endpoints of the connection. )?

[5.1] q( The session ID MUST depend in a collision-resistant way on fresh
data contributed by both sides of the connection. ). Is this clear enough
to rule out specs that, for instance, take random data from each side and
XOR it? I think it does if "collision-resistance" is interpreted as
applying to the set of raw inputs to the session ID computation; it doesn't
if a spec author interprets it as applying to the string used as the input
to the collision-resistant compression function they employ to produce the
final session ID, where that string is some function of the raw inputs.

[5.1] q( Unless and until applications disclose information about the
session ID, all but the first byte MUST be computationally
indistinguishable from random bytes to a network eavesdropper. ). For DH,
this seems to imply that the session ID must be a function of the output of
the key agreement, because all other input to the session ID is public. Is
this actually necessary, however? I've been struggling with whether it even
matters if an eavesdropper can compute the session ID from a public
transcript: the two required properties seem to be that both ends of the
connection can compute it, and that it be unique over all time with
overwhelming probability.

[7.1] q( Different middleware authentication protocols can employ unique
identifiers to multiplex the "m" bit. ). I can't figure out what this means.

[7.2] Minor quibble: I'd reword the second paragraph to start with q(
Because a network path may drop ENO options... ).

[9] The first paragraph here *really* makes me want to figure out a way to
conceal "a" from passive eavesdroppers because it means active attackers
wouldn't know until it's too late that they can't safely MitM a connection.
Not sure if there's any way to achieve this. It may be irrelevant because
the application-aware bit can be set to 0 for applications that will not
function without transport encryption. Maybe that's actually the answer:
recommend that the application-aware bit be set to 1 only for application
protocols that are willing to function without encryption, and 0 at all
other times.

[9] The third paragraph has the same issue as [4] and [4.7] above, in that
a full MitM attack will defeat any attempts to detect it without
authentication of the session ID.

[9] In the last paragraph, you might want to generalize this to all non-SYN
ENO options, which as you've stated earlier in the document are perfectly
cromulent. (You can imagine a spec that for some reason sends data in ENO
options in both directions during the key exchange. It seems both unlikely
and pointless, but if it's possible, according to the monkey-typewriter
theorem someone will eventually do it.)

Good work, BTW: this draft reads a lot better than earlier revisions.

Kyle

---

From: David Mazieres <[email-masked]>
Date: Fri, 01 Jul 2016 23:20:58 -0700

> This is a review of the latest TCP-ENO draft (02). I am acting as member,

Hi, Kyle.  Thanks for the review.  We've addressed most of your
comments, so I'll append a diff.  Since we are probably going to upload
another draft when we get Jana's review, plus we have to fix IANA
considerations, I'm not going to upload this just yet, but figured the
easiest way so see if you are happy with changes is to send you our
proposed wording.  I'll just address a few points that we didn't know
what to do with for discussion.

> you're negotiating either an algorithm or a protocol.

I agree that spec is a bit of a made up word, here, but we've failed to
come up with a better one.  For what it's worth, you are kind of
negotiating a document and a protocol.  But basically I think we would
need a more concrete suggestion to do something about this awkwardness.

> references to option 69 should just be removed from the document.

So from my limited experience, it seems like one is supposed to ask IANA
for a specific number to which they reply yes or no, rather than asking
them to choose the number.  I was hoping that since we say you MUST NOT
implement 69, this would satisfy the objections to option kind
squatting.  (Michael Scharf did at one point suggest he would be okay
with the statement, "This protocol specification MUST NOT be implemented
prior to assignment of a TCP option kind number.")

But if it's better to use a symbolic constant like ENO, we can do that,
too.  We'll defer to people who know the process better.

> following a length byte has the high bit clear ).

Right, the idea here is that if v=0, then it's not a suboption preceded
by a length byte, but rather a length word.  We've tried to clarify the
language.

> specs among the suboptions.

Obviously the issue here is what happens in the very distant future if
ever TCP SYN option space becomes huge, like more than 255 bytes.  As
you point out, there is the separate limitation that each option only
has one byte of length.

In the previous draft, we figured that in case both problems are fixed
(total option space an individual option length), we might as well have
a 12-bit length word.  Upon further reflection, we figured that isn't
super likely.  Instead, it may become necessary to split TCP-ENO over
multiple options, or reference extension options, or something else we
haven't yet thought of, for which it's better to have completely
reserved the zzzz bits right now.  It will already be a miracle if we
get >256 bytes of aggregate SYN option space, so there are just too many
unknowns about whether we'll ever get >256 bytes per individual option.

If ENO is adopted, we can always just standardize what to do with jumbo
options at the time those become available, in the hope that people will
implement both at the same time.  For that, it is better to have
completely reserved bits that cause legacy applications to abort than to
have some weird thing where we mispredicted the future.

Now, why not hard-code 0's instead of having zzzz?  Well, the initial
100 bits are how you recognize that you have a length byte/word; the
meaning of every other value of the high 3 bits is already fully
specified.  However, if we just wrote 1000000, then we haven't addressed
the question of what 100zzzz means for values of zzzz other than 0000.
We used the zzzz variable to make sure every possible byte sequence was
defined (even if the definition for zzzz != 0000 is just abort).  Does
that make sense?

> final session ID, where that string is some function of the raw inputs.

XOR is not collision-resistant.  I'm not sure I understand your second
interpretation well enough to craft language to rule it out.  Do you
have any suggested language?

> overwhelming probability.

This was discussed on the mailing list, and the feeling was that there
are cases where you might want to generate crypto keys from the session
ID (for example to authenticate that another connection belongs to the
same host as the first connection).

An alternative would be to require specs to provide an RFC5705-like
exporter facility.  That's more complicated, but still open to
discussion if people feel strongly about it.

> protocols that are willing to function without encryption, and 0 at all

Well, if an eavesdropping ISP starts downgrading only connections with
a=0, then everyone can just start setting a=1...  It could also be that
if connections are downgraded, an application falls back to some other
form of encryption...

But I see your point, I just don't know what to do about it, especially
because in the case of mandatory application-aware mode, you don't want
to go through the trouble of key exchange in the first place.

> theorem someone will eventually do it.)

Other than the third leg of the handshake, any other non-SYN ENO options
will be after the key agreement, so can just be encrypted or MACed.  But
to be honest, even that last paragraph seems a little weird to me, and
is there by request of someone else.  I think the idea is that the first
ACK is part of the TCP handshake, so people might subconsciously think
it is part of the negotiation transcript.  I'm happy to substitute
whatever wording you want to suggest.

Anyway, below are the diffs so far.

Thanks,
David

--- draft-ietf-tcpinc-tcpeno-02.md	2016-06-29 23:34:37.929943820 -0700
+++ draft-ietf-tcpinc-tcpeno-03.md	2016-07-01 22:11:48.696993934 -0700
@@ -196,15 +196,17 @@
 : A TCP segment in which the SYN and ACK flags are both set
 
 Active opener
-:  A host that sends a SYN-only segment.  With the BSD socket API,
-this occurs when an application calls `connect`.  In client-server
-configurations, active openers are typically clients.
+:  A host that initiates a connection by sending a SYN-only segment.
+   With the BSD socket API, this occurs when an application calls
+   `connect`.  In client-server configurations, active openers are
+   typically clients.
 
 Passive opener
-:  A host that does not send a SYN-only segment (only a SYN-ACK
-   segment).  With the BSD socket API, this occurs following a call to
-   `listen`.  In client-server configurations, passive openers are
-   typically servers.
+:  A host that does not send a SYN-only segment, but responds to one
+   with a SYN-ACK segment.  With the BSD socket API, passive openers
+   call `listen` and `accept`, rather than `connect`.  In
+   client-server configurations, passive openers are typically
+   servers.
 
 Simultaneous open
 :  The act of symmetrically establishing a TCP connection between two
@@ -242,8 +244,8 @@
   identifier,
 * A few extra bytes of suboption data from each host, if needed by the
   spec,
-* A negotiation transcript that the negotiated spec must
-  cryptograhpically authenticate,
+* A negotiation transcript with which to mitigate attacks on the
+  negotiation itself,
 * Role assignments designating one endpoint "host A" and the other
   endpoint "host B", and
 * A few bits indicating whether or not the application at each end
@@ -415,12 +417,17 @@
 
 `m`
 :  The middleware bit `m` functions similarly to the application-aware
-bit `a`.  It is available for middleware such as shared libraries
-needing out-of-band signaling to improve the security of legacy
-applications.  Implementations MUST set this bit to 0 by default and
+bit `a`, but is available to middleware shared by multiple
+applications, some of which might have an independent use for the `a`
+bit.  When set, the bit indicates a desire to engage in some endpoint
+authentication protocol before turning the connection over to the
+application.  Implementations MUST set this bit to 0 by default and
 SHOULD provide an API through which software can change the value.
-Unlike the application-aware `a` bit, no mandatory mode is needed for
-the middleware bit.
+Unlike the application-aware bit `a`, no mandatory mode is needed for
+the middleware bit.  Middleware using the `m` bit SHOULD employ length
+fields and unique authentication scheme identifiers so as to allow the
+`m` bit to be multiplexed by multiple schemes, but the mechanism for
+doing so is outside the scope of this document.
 
 `zz`
 :  The `zz` bits are reserved for future revisions of TCP-ENO.  They
@@ -504,11 +511,12 @@
 Figure: Suboption with length byte
 
 If the octet following a length byte has the high bit clear (meaning
-`v = 0`), then the length byte and following octet together are
-interpreted as a length word, as shown in (#fig:marker-word).  The
-length word encodes an 8-bit value corresponding to one less than the
-suboption data length.  As with length bytes, spec identifiers MUST
-have `v = 1`.
+`v = 0`), then it is not a suboption.  Instead, the length byte and
+following octet together are interpreted as a length word, as shown in
+(#fig:marker-word).  The length word encodes an 8-bit value
+corresponding to one less than the suboption data length.  As with
+length bytes, the octet following a length word MUST be a spec
+identifier suboption and MUST have `v = 1`.
 
 {#fig:marker-word}
     bit   15  14  13  12  11  10  9   8   7   6   5   4   3   2   1   0
@@ -593,9 +601,12 @@
 
 To defend against attacks on encryption negotiation itself, encryption
 specs need a way to reference a transcript of TCP-ENO's negotiation.
-In particular, an encryption spec MUST fail with high probability if
-its selection resulted from tampering with or forging initial SYN
-segments.
+In particular, an encryption spec MUST with high probability fail to
+establish a connection between two honest endpoints if the spec's
+selection resulted from tampering with or forging initial SYN
+segments.  (Of course, in the absence of endpoint authentication, two
+honest endpoints can still each end up talking to a man-in-the-middle
+attacker rather than each other.)
 
 TCP-ENO defines its negotiation transcript as a packed data structure
 consisting of two TCP-ENO options exactly as they appeared in the TCP
@@ -653,11 +664,12 @@
 ## Session IDs
 
 Each spec MUST define a session ID that uniquely identifies each
-encrypted TCP connection.  Implementations SHOULD expose the session
-ID to applications via an API extension.  Applications that are aware
-of TCP-ENO SHOULD incorporate the session ID value and TCP-ENO role (A
-or B) into any authentication mechanisms layered over TCP encryption
-so as to authenticate actual TCP endpoints.
+encrypted TCP connection and that is computable by both endpoints of
+the connection.  Implementations SHOULD expose the session ID to
+applications via an API extension.  Applications that are aware of
+TCP-ENO SHOULD incorporate the session ID value and TCP-ENO role (A or
+B) into any authentication mechanisms layered over TCP encryption so
+as to authenticate actual TCP endpoints.
 
 In order to avoid replay attacks and prevent authenticated session IDs
 from being used out of context, session IDs MUST be unique over all
@@ -814,11 +826,15 @@
 underlying TCP connection.  Such an API enables the possibility of
 authenticating servers transparently to the application, particularly
 in conjunction with technologies such as DANE [@?RFC6394].  The
-middleware bit `m` in general suboptions enables a middleware library
-to indicate to the peer that it wishes to engage in an authentication
-protocol before turning the TCP connection over to the application.
-Different middleware authentication protocols can employ unique
-identifiers to multiplex the `m` bit.
+middleware bit `m` allows such authentication to be slipped underneath
+legacy applications--if both sides set the `m` bit, then before
+turning the socket over to the application, the two endpoints engage
+in a server authentication protocol.  Over time, the consequences of
+failed or missing authentication can gradually be increased from
+issuing log messages to aborting the connection if some
+as yet unspecified DNS record indicates authentication is mandatory.
+Through shared library updates, such authentication can potentially be
+added transparently to legacy applications without recompilation.
 
 TLS can currently only be added to legacy applications whose protocols
 accommodate a STARTTLS command or equivalent.  TCP-ENO, because it
@@ -831,7 +847,7 @@
 devolving to unencrypted TCP rather than causing the entire TCP
 connection to fail.
 
-Because some network paths drop ENO options in one direction only, a
+Because a network path may drop ENO options in one direction only, a
 host must know not just that the peer supports encryption, but that
 the peer has received an ENO option.  To this end, ENO disables
 encryption unless it receives an ACK segment bearing an ENO option.
@@ -922,10 +938,11 @@
 kind of endpoint authentication.  Opportunistic encryption protects
 against undetectable large-scale eavesdropping.  However, it does not
 protect against detectable large-scale eavesdropping (for instance, if
-ISPs terminate and proxy TCP connections or simply downgrade them to
-unencrypted).  Moreover, it emphatically does not protect against
-targeted attacks that employ trivial spoofing to redirect a specific
-high-value connection to a man-in-the-middle attacker.
+ISPs terminate TCP connections and proxy them, or simply downgrade
+connections to unencrypted).  Moreover, opportunistic encryption
+emphatically does not protect against targeted attacks that employ
+trivial spoofing to redirect a specific high-value connection to a
+man-in-the-middle attacker.
 
 Achieving stronger security with TCP-ENO requires verifying session
 IDs.  Any application relying on ENO for communications security MUST

---

From: Joe Touch <[email-masked]>
Date: Fri, 1 Jul 2016 23:39:05 -0700

On 7/1/2016 11:20 PM, David Mazieres wrote:
> them to choose the number.
You can (but aren't required to), but that isn't part of the doc. It's
typically part of the out-of-band info in the request to IANA.

>   I was hoping that since we say you MUST NOT
> squatting.

So then what number might you ask for? You've effectively poisoned the
well for 69. IMO, you ought to either use that or some other number on
which others have squatted ;-) But that's not a decision to include
inside this doc (see above).

> (Michael Scharf did at one point suggest he would be okay

That's a hollow statement if you are planning on testing this code while
you're writing the spec. The correct answer (IMO) is to use an ExID with
the experimental option in this doc until a value is assigned by IANA.
ExIDs are FCFS assigned with low hurdle.

> too.  
That has always been the convention and is what many of us have been
asking you to do for YEARS, FWIW. ;-)

Joe

---

From: David Mazieres <[email-masked]>
Date: Sat, 02 Jul 2016 00:38:48 -0700

> inside this doc (see above).

I don't think your comments make sense in light of the new draft.  We
are specifically trying NOT to poison the well any further by A) using
69 in the draft (already slightly poisoned), and B) saying people MUST
NOT implement option 69 before IANA assignment.

> ExIDs are FCFS assigned with low hurdle.

So then you are happy with draft 02 I take it?  It reads:

   Implementations MUST NOT use option kind 69 unless and until it is
   assigned to TCP-ENO by IANA.  In the meantime, implementations MUST
   use experimental option 253 [RFC6994], to which IANA has assigned
   ExID 0x454E (encoded by decimal bytes 69, 78 in Figure 1).
   Conversely, after IANA assigns a dedicated option kind to TCP-ENO,
   the use of option 253 is deprecated.

We are trying to follow the precedent of RFC7413 here.

David

---

From: Kyle Rose <[email-masked]>
Date: Sat, 2 Jul 2016 12:26:25 -0400

> need a more concrete suggestion to do something about this awkwardness.

I'll think about this for a while. I don't have a suggestion at the moment.

> too.  We'll defer to people who know the process better.

Based on the rest of the thread, I'll let you, Joe, and David Black work
this out. It's really outside of my area of expertise.

> by a length byte, but rather a length word.  We've tried to clarify the

Here's what you have now:

If the octet following a length byte has the high bit clear (meaning
`v = 0`), then it is not a suboption.  Instead, the length byte and
following octet together are interpreted as a length word, as shown in
(#fig:marker-word).  The length word encodes an 8-bit value
corresponding to one less than the suboption data length.  As with
length bytes, the octet following a length word MUST be a spec
identifier suboption and MUST have `v = 1`.

It still has the problem that it implies a length word starts with a length
byte, and so the second byte must have both v=0 and v=1. I realize I'm
probably being pedantic, but I think it's worth being really precise.
Here's my attempt:

<<EOF
... The sender does so by preceding the suboption with an encoded data
length.

Suboption data lengths are encoded in either one or two octets. If the
length is between 1 and 32 bytes (inclusive), it may be encoded in a single
octet as a suboption with v=1 and cs<0x20, as shown in figure X.

Lengths up to 256 bytes (inclusive) may also be encoded in two octets, the
first of which is a suboption with v=1 and cs<0x20, and the second of which
must have the high bit unset, as shown in figure Y.

The octet following an encoded length MUST be an encryption spec suboption
followed by suboption data (v=1, cs>=0x20).  Figure Z shows an example of
such a suboption.

A receiver can distinguish between length encodings of one or two octets by
examining the high bit of the second octet: if it is 0, the length is
encoded in two octets; if it is 1, the length is encoded in a single octet.
In the two-octet case there is no ambiguity with general suboptions (v=0,
cs<0x20) or encryption specs without suboption data (v=0, cs>=0x20), as by
specification neither may have suboption data and so may not follow an
encoded length.
EOF

I've spent an hour on this and I'm still not entirely happy with it. Heh.
(This experience forces me to wonder if there's an easier-to-follow
encoding that has the same characteristics around parsimony of option
space. I doubt it, and I'm sure you've looked.)

> unknowns about whether we'll ever get >256 bytes per individual option.

It's also not clear that option space will be useful or recommended for key
agreement shares that don't fit in 256 bytes, e.g., shares for hypothetical
post-quantum key agreement schemes. We're likely to see a huge blow-up in
share size compared to what we have today even with large RSA public keys.
So I think this choice is fine: I was just throwing it in there for
discussion.

> defined (even if the definition for zzzz != 0000 is just abort).  Does

I was struggling with this exact problem in composing an alternative
suboption data length description, so I now understand what drove this. All
good.

> have any suggested language?

I'm not sure, because the potential misunderstanding is really subtle.
Let's say a spec says:

session ID = PRF('foo', (client_random XOR server_random) || other inputs)

This is collision-resistant in the sense that the underlying PRF is
collision-resistant, so (wlog) an adversarial client can't for example
choose two different client_randoms for a given server_random and get the
same session ID; but it *can* choose a client_random for any given
server_random such that the XOR of the two is the same, which may result in
the session ID being the same for multiple connections. This isn't a
collision in the PRF: it's a collision in the tuple of inputs to the PRF.
(I'm not sure I'm explaining this clearly; let me know.)

I think your language does literally prohibit this case (the overall
session ID function in my example isn't collision-resistant on its tuple of
inputs), but it's really subtle and spec designers might screw it up. Maybe
I'd be happy with q( The session ID MUST depend in a collision-resistant
way on fresh data contributed by each side of the connection. ). Or maybe
I'd separate out collision-resistance entirely:

<<EOF
 o  The session ID MUST be collision-resistant on its tuple of inputs.

 o  The session ID MUST depend on fresh data contributed by each side of
the connection.

 o  The session ID MUST depend on any public keys, public Diffie-Hellman
parameters, or other public asymmetric cryptographic parameters that are
employed by the encryption spec and have corresponding private data that is
known by only one side of the connection.

 o The session ID MUST depend on the negotiation transcript specified in
Section 4.7.
EOF

Now I've created a new problem, which is: does this combination of
constraints imply that the session ID cannot depend only on the first bit
of (for example) the negotiation transcript? I'm not sure; maybe it would
be better to explicitly state that "The negotiation transcript specified in
section 4.7 MUST be included in the tuple of inputs to the session ID
computation."

If I am being too pedantic, feel free to ignore. I am probably going way
beyond what is reasonably required in terms of precision.

> same host as the first connection).

Sigh... yeah, I remember that conversation now. The problem with allowing
the session ID to be public but not *mandating* that it be regarded as
public is that a deployment using a non-tcpcrypt spec that requires the
session ID to be private might make use of a general TCPINC-aware helper
application that assumes the session ID is public based on tcpcrypt's
requirement that it be public for purposes of bulk signing. It almost seems
inevitable that someone will write such an application, and that someone
will deploy it inappropriately without understanding the disastrous
interaction.

I would personally prefer an exporter facility for channel bindings that
explicitly requires secret input to get secret output, and for the session
ID to be explicitly regarded as public so no one will try to use it
inappropriately. I can't seem to find the thread in the archives; do you
recall who was involved in that conversation? I'd like to get their input.

I do recall Christian mentioning in Buenos Aires that the session ID
shouldn't enable passive tracking of clients, which might imply this
requirement anyway for purposes of derived SIDs used for session caching,
but that might be more appropriate as a requirement for encryption specs
and not within the ENO spec since nothing about ENO mandates the existence
of session caching or reuse of session IDs in the first place.

> to go through the trouble of key exchange in the first place.

Yeah, I'm not sure it's worth doing anything about this. I'll file it under
"It would be nice if..."

> whatever wording you want to suggest.

This is one I don't feel strongly about. What you have is probably fine.

> Anyway, below are the diffs so far.

The rest of the diff looks good.

Kyle

---

From: Kyle Rose <[email-masked]>
Date: Sat, 2 Jul 2016 22:32:19 -0400

> Okay, I think I have a fix that involves a smaller delta to the text
> than your suggestion.  First of all, I have introduce the term "length
> field" (and use it earlier in 4.1 where before we had length byte).  Now
> I have in 4.4:
>
>    ... There are two kinds of
>    length field: length bytes specifying up to 32 bytes of suboption
>    data, and length words specifying up to 256 bytes.
>
>    Figure 6 shows the format of a length byte...
>
>    A suboption preceded by a length byte MUST be a spec identifier ("cs
>    >= 0x20") and MUST have "v = 1".  Figure 7 shows an example of such a
>    suboption...
>

It's also the case that a suboption preceded by a length word must be both
of those things. Maybe I would say "length byte or word" and put it after
the following paragraph:

>    If an octet of the form shown in Figure 6 (with the high three bits
>    100) is followed by an octet in which the high bit is clear (meaning
>    "v = 0"), then the two octets together form a length word, as shown
>    in Figure 8....
>
>    A receiver MUST ignore an ENO option in a SYN segment and MUST
>    disable encryption if any of the following holds of the ENO option:
>
>    1.  A length field indicates that a suboption would extend beyond the
>        end of the ENO TCP option,
>
>    2.  The "zzzz" bits in a length word are not 0, or
>
>    3.  A length byte or word is immediately followed by an octet in the
>        range 0x80-0x9f (indicating another length field with no
>        intervening spec identifier suboption).
>

Shouldn't this be true for any octet in the range 0x00-0x9f? The only thing
valid after a length field is an encryption spec suboption with data. (In
this interpretation, the first octet of a length word is not a length byte,
which I think is where you're going with this.)

I think this looks good.

> Okay, how about putting all of the collision-resistance requirements
> together into one requirement with subrequirements:
>
>    o  The session ID MUST depend in a collision-resistant way on all of
>       the following (meaning it is computationally infeasible to produce
>       collisions of the session ID derivation function unless all of the
>       following quantities are identical):
>

I think the part in the parentheses is the critical part that was missing
before, and it avoids my awkward use of the word "tuple". I think this
reformulation looks good.

> > I can't seem to find the thread in the archives; do you
> You, me, dkg, Martin Thomson, Stephen Farrel, among others.  The root of
> the thread is message ID <[email-masked]>, which you
> can find here:
>
>         https://www.ietf.org/mail-archive/web/tcpinc/current/msg00697.html
>
> But it's easier to navigate in a mail reader.
>

It turns out I had this exact thought here:

https://www.ietf.org/mail-archive/web/tcpinc/current/msg00724.html

But after re-reading the entire thread, I understand how we got to the
language you have now. I think it's fine. Sorry for dredging this up again.
(This is one of the problems with not having thought about the issue in 11
months.)

> Well, there's another thing that if the session ID is not pseudo-random,
> then 33 bytes might not be enough.  E.g., a pathological example would
> be a session ID in which the last 12 bytes are always 0.
>

This example seems to be precluded by the requirement:

      Unless and until applications disclose information about the
      session ID, all but the first byte MUST be computationally
      indistinguishable from random bytes to a network eavesdropper.

Kyle

---

From: Joe Touch <[email-masked]>
Date: Tue, 5 Jul 2016 10:11:36 -0700

> NOT implement option 69 before IANA assignment.

I've been saying one thing all along - follow existing policy:

For this doc (yes, I know that some of this is already there - but this
is ALL that should be there):
    - Refer to a TBD value for the specific option codepoint.
    - Do not refer to any specific other values until assigned - ever.
    - Tell early adopters to use the currently assigned ExID.
    - It's fine to remind users that implementations MUST NOT use
unassigned IANA codepoints until assigned.

For the *application* to IANA:
    - that's where you would mention the relation of this request to the
previously unauthorized deployment of 69.

> So then you are happy with draft 02 I take it?  It reads:
No. See above.

>    Implementations MUST NOT use option kind 69 unless and until it is
replace 69 with TBD

>    the use of option 253 is deprecated.
The above is OK.

> We are trying to follow the precedent of RFC7413 here.

AFAICT, that RFC and its preceding IDs follow IANA policy - NO codepoint
values were ever mentioned until they were assigned by IANA.

Joe

---

From: "Black, David" <[email-masked]>
Date: Tue, 5 Jul 2016 17:33:03 +0000

Joe,

> >    the use of option 253 is deprecated.

Is it also worthwhile to have this draft record the unauthorized use of
option kind 69 for a prior protocol that is superseded by TCP-ENO?    This
would be only as a description of what's happened.

I can argue this both ways - not blessing prior bad behavior vs. recording what
happened.   The latter provides IANA with a reference for the unauthorized
use and would enable this draft to at least discourage such use.   OTOH,  
having been in an analogous situation in the past, I'm not optimistic about
ever reclaiming that option kind value.

Right now, it looks like the intent is not to ask for option kind 69 - if that were
to be requested, this draft ought to have additional text on how a receiver
distinguishes TCP-ENO from past use of that option kind (and what happens
if the use of option kind 69 that shows up doesn't match what the receiver
expects).

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: Joe Touch <[email-masked]>
Date: Tue, 5 Jul 2016 10:41:31 -0700

> would be only as a description of what's happened.
If and when 69 is assigned - yes.

But not before and not if a different codepoint is assigned.  It's
sufficient to say that "all previous variants of this protocol are
superceded by this", which applies both to content and codepoints.

> if the use of option kind 69 that shows up doesn't match what the receiver
That seems like to would be a very appropriate punishment for the behavior.

Or worse, being assigned a codepoint others are squatting on.

Sauce for the goose, as it were.

IMO, if you pee in the well, you'd better be ready to drink from it.

Joe

---

From: "Black, David" <[email-masked]>
Date: Tue, 5 Jul 2016 17:50:41 +0000

> superceded by this", which applies both to content and codepoints.

That seems like  a reasonable path forward.

Thanks,
--David

[... remainder snipped ...]