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
_______________________________________________
Tcpinc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tcpinc
