tcpcrypt authors (Andrea, Dan, Mike, Mark, David, Quinn),
Thank you for all the work behind draft-bittau-tcpinc-tcpcrypt-00 and
its predecessors.
I recently carefully read through
draft-bittau-tcpinc-01
and just did a diff to check none of my comments were affected by the
revision to:
draft-bittau-tcpinc-tcpcrypt-00.
I have a wide range of comments. I have confined the rest of this
email to technical concerns. A subsequent posting will cover purely
editorial points.
I haven't been following the list closely, so apologies if I'm
covering old ground in some cases. I know item G (Authentication and
Resegmentation) touches a hot topic on the list at the mo, so feel
free to respond to that one separately.
1) My main technical concern is the expectation that users will
accept a round of latency on short connections just to get
opportunistic encryption. I fear that instead this will cause
deployment to be near-non-existent, rather than ubiquitous. I will
suggest a solution to that in a separate posting.
2) My second highest concern is the considerable complexity of the
protocol, given it's already asking the security community to divide
its attention over more security protocols. The proposal in my other
email removes some complexity, but it's still worryingly high.
However, I'm not sufficiently knowledgeable (yet) in this area to say
whether re-purposing an existing protocol e.g. TLS, would be preferable.
The rest of this email enumerates my other technical concerns, in the
order they arise in the doc (not in order of importance).
A./ Danger of Downgrade as a Norm.
(Sec.2. Intro; Last bullet)
If middleboxes make fall-back common, attackers can use this as
air-cover for occasional downgrade attacks when they want to snoop on
something.
B./ Stateful Server Resume
(Sec.3.8 Session caching)
The session caching model requires the server to hold session state
between TCP connections. But operationally it's difficulty for a
server to cache session state in load balanced environments. There is
no guarantee that a resumed connection will arrive at the same
physical server as the previous session.
Wouldn't it be preferable to use an approach like RFC5077 Session
Keys, so the server can send a 'cookie' to the client at the end of
one session, and the client can return it when resuming a subsequent session?
C./ Reliable delivery of control options.
(Sec.4. Extensions to TCP)
Where it says tcpcrypt uses the Data Portion for INIT1 and INIT2, it
needs to explain whether the TCP sequence number and RWND covers this
option data or not.
There also seems to be a problem with how control data in a packet
that doesn't increment the seq no will be delivered reliably when
subject to packet loss. For instance, the INIT1, INIT2 and PKCONF
options can be on pure ACK packets. So, if they are lost, the TCP
state machine will not retransmit them.
Won't this stall tcpcrypt, unless you make the state machine even
more complex by adding some tcpcrypt-specific reliable ordered
delivery logic for these options (cf. the REKEY option)?
D./ Ambiguity in state machine?
(Figure 1)
S := SYN=1, ACK=0, FIN=0, RST=0
S? := SYN=1, ACK=any, FIN=0, RST=0
Therefore, in the NEXTK-SENT state, if it receives SYN=1, ACK=0,
FIN=0, RST=0 / HELLO, the state machine seems to head off in two
directions at once:
- drop and transition to HELLO-SENT
- snd ?A/PKCONF and transition to S-MODE
E./ Ossifies the traditional TCP state machine.
(Figure 1)
Altho the chartered focus of the IETF tcpinc WG is TCP, it would
still be preferable not to lock opportunistic encryption so tightly
to the current state machine of TCP, which will make the TCP state
machine harder to evolve in future. Consider that four proposals in
progress right now in the TCPM WG alter the TCP state machine - so it
seems likely there will be more in future.
F./ Separate out Cookie functions
(Table 4 or Sec.4.3.6)
It seems that the SYNCOOKIE and ACKCOOKIE options have more genral
applicability than tcpcrypt. It would be worth considering making
these new TCP options and shifting them into a short separate draft.
Then make this draft mandatory to implement for all tcpcrypt implementations.
In fact, I have posted draft-briscoe-tcpm-echo-cookie-00 today.
This could be defined to be more general (e.g. on a FIN for caching
session state in the client for a later resume), not just to defend
against SYN flooding attacks during the 3WHS. (See Stateful Server
Resume above.)
G./ Authentication and Resegmentation
(Sec.4.4 The TCP MAC option)
TCP connection splitters such as Performance Enhancing Proxies, Web
filters, etc. are fairly common. Certain TCP senders often send
sub-full-sized segments (e.g. if each message is app-limited). If
these queue up at the ingress to a connection splitter, it will
probably transmit full-sized segments onward to the receiver (it
would be very hard for its egress interface to preserve the segment
boundaries arriving at the ingress).
The result is that some segments coalesce, and then at every
full-sized boundary it introduces a split and starts a new segment.
Therefore, as well as firewalls that re-randomise the ISN,
resegmentation is fairly common.
The MAC covers a specified range of bytes in the payload, but then
adds coverage of 'the header'. After resegmentation 'the header' (at
least the fields covered by the MAC in it) might accidentally be the
same as the original, but they might not. It is actually a newly
created header over a different TCP connection, so it might have
different TCP options, different TCP flags (e.g. ECN), etc.
tcpcrypt has developed Authenticated Sequence Mode and it goes to
some lengths to be robust against rewriting of TCP seq nos by
consistently using seq no offsets. It seems a shame to have gone to
all that trouble, but then not to be robust against resegmentation.
The more brittle that the tcpcrypt MAC is to middlebox interference,
the more often it will be disabled, providing no protection at all.
It strikes me that it would be more robust to MAC the byte-stream and
the headers separately.
H./ Authentication Coverage
(Sec.4.4 TCP MAC option)
The coverage choices are problematic in the following respects.
i) The reserved flags (bits 4-6 counting from zero of byte 12 of the
TCP header) might not be immutable if they are defined in future. It
would constrain future evolvability of the header to assume they are
immutable, even tho one would /currently/ expect the TCP header to be
immutable e2e. For instance, in future, one of these flags might be
standardised for a co-operating middlebox to signal that it has
altered the TCP header.
ii) Middleboxes alter some TCP options. In particular, firewalls that
'correct' the ISN usually also 'correct' the SACK block.
iii) I'm not sure what the justification for the following behaviour
is, or why this particular set of options has been singled out:
" where the
TSOPT (8), Skeeter (16), Bubba (17), MD5 (19), TCP-AO (29), and
MAC (OPT2) options appear, their contents (all but the kind and
length bytes) are replaced with all zeroes.
"
Whatever the justification, a list like this will not remain static.
The spec needs to require future TCP option RFCs to state whether
they are in this list or not. That's messy because every time a new
TCP option is implemented, the tcpcrypt code (at least a .h file)
also has to be altered.
iv) Surely MAC coverage of TCP options needs to take account of where
the MAC option sits in the order of option processing. A tcpcrypt MAC
cannot cover headers that come after the MAC option in processing
order. This also means that the MAC cannot cover the Data Offset (DO)
- while processing subsequent TCP options after having computed the
MAC, the sender might need to increase DO.
Both the above 'cannot's could be relaxed with a suitable
dispensation clause, e.g. the MAC is always calculated after other
TCP options, even if it is not placed last. But that would be messy.
Alternatively, it has to be specified that MAC MUST be the last TCP option.
However, if I were on the IESG, I would be suspicious of an option
that 'MUST be last'. What if someone else's option also 'MUST be
last'? (BTW, I'm not sure why a MAC option would be used as well as
TCP-AO (or MD5)).
I./ Unnecessary latency in decline of state re-use?
Sec. 5.5. Example 5: Decline of state reuse
Surely, in this example, B doesn't need to send a PKCONF, because it
already knows A's pub key preferences. It can surely send an INIT1 immediately?
Bob
________________________________________________________________
Bob Briscoe, BT
_______________________________________________
Tcpinc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tcpinc
