To follow up on specific ways to evolve the TCP-ENO spec to make it compatible with symmetrically-designed protocols like TCP could be (and IMO should be for consistency with TCP and to avoid breaking simultaneous-open):
- Section 2, Introduction: insert “, if needed by the negotiated protocol,”
somewhere appropriate in bullet 6 at the very end of this section.
- Section 3.1: Simply document this role-defining function as an optional
capability of TCP-ENO negotiation, and move this section somewhere later -
e.g., just after (or into a subsection of) the current section 3.3, where the
spec defines the suboption containing the tie-breaker bit. Then the
currently-specified general sub option (the one with high-nibble of 0) would in
turn become optional in general; required only when at least one of the listed
encryption-scheme specs requires the tie-breaking functionality and/or the
application-aware (aa) bits.
- Section 3.2: the basic ENO-presence rules during handshake rules already
don't seem to depend on the passive/active role distinction. In particular,
the ENO option presence rules in the section paragraph of section 3.2 seem to
be perfectly symmetrical already; the only asymmetry assumption that suggests
itself is the way in which the text starting “Depending on whether a host…”
elaborates on those rules. And that can be fixed trivially simply by
clarifying how the rules work in the (perhaps rare) simultaneous-open case,
i.e., by adding a third bullet-point that looks something like:
* If both endpoints play the active role, e.g., in the case of TCP
simultaneous-open, then each endpoint will first send a SYN packet (without the
ACK flag set) containing ENO options; then upon receiving the other endpoint’s
SYN packet, each endpoint will send an ACK packet containing an empty ENO
option in order to confirm receipt of the other endpoint’s ENO options.
- The “negotiated spec” paragraph needs to be adjusted as I proposed in my
earlier E-mail: e.g., from each list of supported specs, take the last spec
from each list that is present in both lists, and if they are different, just
choose (say) the numerically higher one, instead of choosing the one proposed
by host B.
- Just delete the paragraph that start “When possible, host B SHOULD send only
one spec identifier…”
- Change wording slightly here and there in 3.2.1 “Handshake examples” to avoid
unnecessarily implying an assumption of active/passive asymmetry. (The
examples can still use asymmetry and refer to active/passive sides in the cases
where, like the first, the roles are clearly defined in the example scenario -
but just make it clear that those roles are associated with those specific
examples.)
- Section 3.4: simply redefine the transcript as being a directional pair of
transcripts, one containing the (two) ENO-options one endpoint sent (#s 1-2 in
the current spec), the other containing the (two) ENO-options the other
endpoint sent (#s 3-4 in the current spec). These may then be used
directionally as I already proposed in the tcpcrypt protocol, or
undirectionally by sorting them either lexicographically or via the tie-breaker
mechanism (needed only for negotiated protocols that need the tie-breaker).
That is, when the symmetric version tcpcrypt is negotiated via ENO, endpoint A
takes the two ENO-transcripts (AtoB, BtoA) and uses them in that order to
derive the AtoB master key, and uses the two ENO transcripts in the opposite
order (BtoA, AtoB) to derive the BtoA master key. When TLS is negotiated via
ENO, each endpoint takes the two ENO-transcripts and sorts them into A/B roles
via the tie-breaker rules, resulting in the same effective behavior as what the
ENO spec currently defines in the #1-4 list.
- Section 4.1 should similarly be generalized to allow for both directional and
undirected session IDs to be passed to applications. The cleanest way to do
this is probably simply to specify that any spec MUST provide three session IDs
to the application: (a) an undirected session-ID, (b) a “me-to-you” session ID,
and (c) a “you-to-me” session ID. The spec must arrange that both application
endpoints receive the same undirected session-ID (a); that each endpoint’s
“me-to-you” session ID (b) is identical to the other endpoint’s “you-to-me”
session ID (c); and that all of these session-IDs are unique with overwhelming
probability. The application can then use whichever of these session IDs are
most convenient for the application protocol: asymmetric application protocols
might be more likely to use (a) while symmetric protocols might be more likely
to use (b) and (c), but that’s the application’s concern.
Those are the only significant changes I see that would be needed to enhance
TCP-ENO to support both symmetric and asymmetric use. Did I miss anything
important?
Now for two issues that my closer read-through brought up, which are at least
partially orthogonal to the symmetric-mode support:
1. The current section 3.1 doesn’t really state clearly where the “p” bit comes
from in Figure 4. It’s not included in the general sub option specified in
section 3.3, so I assume each endpoint is supposed to “infer” both its own
p-bit and the other endpoint’s p-bit. Presumably it’s easy for each endpoint
to decide the value of its own p-bit, but how does each endpoint determine the
intended value of the other endpoint’s p-bit? For example, if I consider
myself an active opener (p=0), then do I decide that the other endpoint’s p-bit
is a 1 if the first TCP packet I get from them is a SYN-ACK, and decide the
other endpoint’s p-bit is a 0 if the first packet I get from them is a SYN
without an ACK (presumably indicating a simultaneous open)? If so, I see a
problem with race conditions. For example, my SYN (without ACK) reaches my
partner but his SYN (without ACK) gets dropped on its way to me. The next
packet he sends me (e.g., a retransmission) will be a SYN-ACK, because he is by
then aware of my SYN. But he’ll correctly perceive my p-bit to be 0, and thus
go into tie-breaker mode, whereas I’ll think his p-bit is a 1 because I saw a
SYN-ACK first, and horrible confusion ensues. Perhaps it would be better to
avoid risk of such confusion simply by deleting the ‘z’ bit from the sub option
packet and instead just including an explicit ‘p’ bit right next to the ‘b’ bit?
2. Section 3 currently specifies that only one variable-length sub option per
ENO option is allowed, but that multiple ENO options can be used if needed to
contain multiple variable-length ENO sub options. I understand the tradeoffs
discussed in section 6.4 but frankly the current solution makes my skin crawl.
:) I think the ENO spec should be defined such that it should never, ever be
necessary to have more than one ENO option in a single packet. This doesn’t
necessarily mean adding a whole extra byte to every variable-length sub option.
Two possible ways to avoid that are: (a) when v=1, use the next 3 bits to
choose from a few possible sub-option lengths: e.g., 0,1,2,4,8,16,32,64. A sub
option that needs 5 bytes gets encoded with 3 padding bytes (oh well). (b)
when v=1, use the next bit (u?) to encode whether this is the “last” suboption
(u=0) or not-the-last suboption (u=1). When u=1 (a non-last suboption), the
bottom 6 bits encode the length of this (non-last) sub option, and the sub
option itself is coded starting in the next byte with v=1,u=0. This approach
would be just as space-efficient as the current proposal in the presumably
common case of only one variable-length sub option, and would add one extra
byte of overhead (for the v=1,u=1 length byte) for each *additional*
variable-length option encoded before that last option.
Cheers
Bryan
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
