Subject: [tcpinc] Technical Review Comments: draft-bittau-tcpinc-tcpcrypt-00

From: Bob Briscoe <[email-masked]>
Date: Mon, 27 Oct 2014 22:58:13 +0000

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