Message-ID: <48744351.20609@isi.edu>
Date: Tue, 08 Jul 2008 21:49:21 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.14 (Windows/20080421)
MIME-Version: 1.0
To: Adam Langley <agl@imperialviolet.org>
References: <396556a20807011045n20656450w7da5955bab19fbd9@mail.gmail.com>
In-Reply-To: <396556a20807011045n20656450w7da5955bab19fbd9@mail.gmail.com>
Cc: tcpm@ietf.org
Subject: Re: [tcpm] draft-ietf-tcpm-tcp-auth-opt-00
Precedence: list
Content-Type: multipart/mixed; boundary="===============0174443146=="
Sender: tcpm-bounces@ietf.org
Errors-To: tcpm-bounces@ietf.org

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============0174443146==
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enig7C8BA6B2E7E7F9BDF76B97A5"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig7C8BA6B2E7E7F9BDF76B97A5
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable



Adam Langley wrote:
>> 2.2. TCP-AO Option
>=20
> [snip]
>=20
>> The MAC is computed over the following fields in the following order:
>=20
> Currently AO is suggesting the same serialisation as TCPMD5:
>   sig =3D MAC(key, pseudoheader + header + data)
>=20
> I suggest, instead, that the default serialisation be:
>   sig =3D MAC(key, H(data) + pseudoheader + header)
>=20
> 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.

The current algorithm is optimized for the most common case, where=20
TCP-AO is implemented inside the stack, and the hash is computed just=20
before the packet is emitted. The same is true on the receiving end -=20
i.e., in both cases, the data is processed as a single stream, whichis=20
why the order is [pseudoheader, header, data]. This works well for both=20
software implementations inside the stack and hardware as well.

The above is optimized assuming that the hash is computed during a copy=20
operation that may or may not occur (e.g., it would not in a zero-copy=20
stack), and further assumes that the copy is performed one MSS at a time =

(vs. copying the entire write() call argument, i.e., copy-on-write).=20
It's not clear that optimizing the algorithm for this corner case is=20
desirable, especially given the impact on more traditional=20
implementations (i.e., the extra header copies/moves).

=2E..
> 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.

I'd like to hear what others think of this. My view is that NATs do=20
other things to TCP packets (e.g., rewrite sequence numbers, modify TCP=20
options) that TCP-AO should probably detect as attacks. An earlier=20
version of this work did consider replacing these values (addr/port=20
pairs), not zeroing them out - i.e., replacing them with values=20
determined during key exchange. I would prefer that to zeroing them out, =

though.

> 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.
>=20
> 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.

TCP already includes a 16-bit counter - the sequence number. The use of=20
longer counters that retain the high-order bits of that number were=20
discussed in Philadelphia. The key problems involve retransmission at=20
the edge of counter wrap; a goal of TCP-AO is to avoid modifying the TCP =

protocol itself. As you note, there didn't seem to be a good solution her=
e.

=2E..
> Also, is encryption of the payload considered out-of-scope for this spe=
c?

Yes. Payload encryption is provided by SSL.

oe


--------------enig7C8BA6B2E7E7F9BDF76B97A5
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIdENRE5f5cImnZrsRAhoOAKDR9JM3vL2Hw8aqufV12g3mSpAWCQCfYyiD
66b67kqzEtVDYxx5e6arkL8=
=XvL/
-----END PGP SIGNATURE-----

--------------enig7C8BA6B2E7E7F9BDF76B97A5--

--===============0174443146==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm

--===============0174443146==--