[tcpm] draft-ietf-tcpm-tcp-auth-opt-00

> 2.2. TCP-AO Option

[snip]

> The MAC is computed over the following fields in the following order:

Currently AO is suggesting the same serialisation as TCPMD5:
  sig = MAC(key, pseudoheader + header + data)

I suggest, instead, that the default serialisation be:
  sig = MAC(key, H(data) + pseudoheader + header)

When the TCP stack is getting data from userspace, it generally knows
the MSS and splits the data into packets right away. With the
suggested serialisation, the data can be hashed as it's copied and the
hash stored with the data. This saves traversing the data again at
transmit time to calculate the MD5 signature. The latter is no less
secure, I believe, and opens up possibilities for optimisation so
should be a clear gain.

Note that MAC(key, H(data) + pseudoheader + header) is better than
MAC(key, data + pseudoheader + header) because, with the latter, a
partial block needs to be stored as well. With common hash functions
(MD5, SHA-1) this is 64-bytes of extra data.

Additionally, the draft already mentions an Option Kind Exclusion List
and I'd suggest another option: that the pseudoheader be omitted and
the source/destination ports in the TCP header be zeroed. This would
allowed the signature to be robust to most (all?) NATs. The NAT
workaround suggested in section 7 is impractical for many uses and a
significant fraction of hosts are now imprisoned behind NATs.

Currently unspecified is a nonce for the packets. Modern MAC
functions, based on polynomials (such as [1]), can have the very
pleasing property of being provably within a factor as secure as
another function (like a block cipher). However, they often require
nonces as inputs.

A trivial solution would be to keep a 64-bit counter, increment it for
each transmission and transmit it along with the signature. However,
we'll struggle to fit that all in the options space; esp for SYN
packets. Next we could consider taking the seq number as the lower
32-bits of a 64-bit counter. However, that doesn't guarantee that two
different messages wouldn't be transmitted with the same nonce. We
could just transmit the bottom (say) 16-bits of the nonce, but a
prolonged outage could knock the endpoints out of sync. I don't have a
good solution here.

Also, is encryption of the payload considered out-of-scope for this spec?

[1] http://cr.yp.to/mac.html

-- 
Adam Langley agl@imperialviolet.org http://www.imperialviolet.org
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm