Subject: [tcpm] Faster application handshakes with SYN/ACK payloads

From: "Adam Langley" <[email-masked]>
Date: Thu, 31 Jul 2008 12:52:25 -0700

I posted this a while back and it gathered a little discussion:

http://www.ietf.org/internet-drafts/draft-agl-tcpm-sadata-00.txt
(implementation in [1])

I would like to have this published as Experimental and to get an
option number assigned.

The spec itself includes a somewhat rambling justification because I
wanted to decouple the spec, which is more general, from the exact
reason that I wish to start testing this over the Internet at large.
However, in order to provoke discussion I think I should explain my
motivation:

This spec allows for opportunistic encryption of TCP connections with
no additional round trips. Details of the project can be found at [2],
however a quick summary follows:

Although SYN/ACK payloads could be used to accelerate many protocols,
I'm proposing that, for HTTP, the SYN/ACK payload contains an 8-byte
random nonce and a 32-byte eliptic-curve public value. The client can
then perform key agreement and send it's own public value, nonce and
any encrypted payload in the final ACK. (Or in a following packet,
that works fine too). Data is then encrypted using Salsa20/8 where the
key is SHA256(diffie-hellman output + server nonce + client nonce) and
the IVs are 0 and 2**63 for client->server and server->client, resp.

Obviously, this open to both a downgrade and man-in-the-middle attack.
For a specific user, it offers little real security. However,
amortised over a large set of users, any ISPs performing these attacks
on a large scale will be detected. (I plan on building a network of
hosts probing for large scale attacks.) Thus, eavesdroppers are
removed from the equation and, against the rest, it can protect most
of the people, most of the time.

I also plan to sign the resulting packets with TCP-AO at some point,
if possible. However, given that that is still under development I'm
going to make that part of the negotiation, above, so that it can be
deployed without it for now.

Obviously, this system can only prove itself in time. However, it
can't prove itself with an option number assigned. And thus, I'm
looking for a consensus that this is an interesting experiment.

Thanks

Having spoken to quite a few people about this, I now have an FAQ on
the design which is included below:

* Why Elliptic-curves?

The payload must be short otherwise SYN-floods could use this as an
amplification
to backscatter DDoS another host.

Also, the reduced computation cost (as compared to Diffie-Hellman over a
multiplicative finite field) is very nice.

* Why 25519?

It's very fast (2000 ops/sec with my C code. 4000 ops/sec with asm). Also, the
server's public value must be constant, otherwise an attacker could eat CPU
time with a SYN flood and curve25519 is designed for that.

Since this is constant for all connections, there is no perfect forward
secrecy.

* Can't you fit the client's public value in the SYN?

A SYN generally has 20 bytes of free option space these days. (We can't use the
payload space in a SYN). Since this can't be the last option ever, we need to
leave 4 bytes spare. 2 bytes for the option header means 14 bytes for the
public value. The closest prime is 2**112-75.

I'm a bear of little brain and picking my own curve is already a hell of a
task, but assuming that I can:

The best, general algorithm currently known for breaking the DH problem on
elliptic curves is Pollard's Rho. The work involved in this attack is sqrt(n),
which is 2**56 in this case. Critically, once you have solved a single instance
you can precompute tables to speed up breaking more instances. With a petabyte
of storage, you could break 112-bit curves in 2**12 operations, which is very
fast.

* Can't you use a smaller field anyway?

Some speedup could be gained by using an EC with a field size around 200 bits.
However the effort of defining such a curve is pretty huge. The standard NIST
curves around that size are slower:

http://www.cacr.math.uwaterloo.ca/techreports/2003/corr2003-18.pdf (table 6)

* Why Salsa20/8?

It encrypts at two cycles per byte on modern CPUs[1]. The best attack on this,
reduced round, variant is 2**251. It's very unlikely that an attack would ever
break it to the point that it's easier than performing a downgrade attack.

http://cr.yp.to/streamciphers/phase3speed-20080331.pdf

[1] http://code.google.com/p/obstcp/source/browse/trunk/patches/synack-payload
[2] http://code.google.com/p/obstcp/

-- 
Adam Langley [email-masked] http://www.imperialviolet.org
_______________________________________________
tcpm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tcpm

---

From: "Murali Bashyam" <[email-masked]>
Date: Thu, 31 Jul 2008 14:07:29 -0700

There are firewalls that drop SYN packets carrying payload, since it's
considered anomalous behaviour (rightly so given today's end-user
behaviour). Doesn't that defeat the purpose here? I suppose TCP options have
been explored and ruled out for some reason?

On Thu, Jul 31, 2008 at 12:52 PM, Adam Langley <[email-masked]>wrote:

> [1]
> http://code.google.com/p/obstcp/source/browse/trunk/patches/synack-payload

-- 
Rgds,
Murali Bashyam
(c) (510)6736915

----------------------------- CONFIDENTIAL --------------------
*****************************************************
This telecommunication and any data attached to, or included in it
is considered confidential, and is intended only for use by the named
recipient. The contents may be legally protected as any one or more of:
copyrighted material, trade-secret protected material, attorney-client
privileged material, attorney workproduct, or as material covered by
any other legally available means. If you received this material in
error, please notify the sender and destroy the original and all copies,
whether electronic or otherwise. Thank you.
*****************************************************

---

From: "Adam Langley" <[email-masked]>
Date: Thu, 31 Jul 2008 14:19:34 -0700

> been explored and ruled out for some reason?

See the section "Can't you fit the client's public value in the SYN?"
for a discussion about using options space for this.

Middleware is a quotidian worry for these sorts of proposals. I'm not
proposing that a payload be carried in the SYN packet, but rather the
SYN/ACK packet. However, you may have meant all packets with a SYN
flag set.

The spec talks about how to back off in the face of such middleware,
and I believe that's the best that can be done. Since this is an
opportunistic protocol, detection and downgrade at the client is fine.
My current implementation doesn't do it yet, but will if there's any
call for it.

Cheers,

AGL

---

From: Joe Touch <[email-masked]>
Date: Thu, 31 Jul 2008 15:17:26 -0700

Murali Bashyam wrote:
| There are firewalls that drop SYN packets carrying payload, since it's
| considered anomalous behaviour (rightly so given today's end-user
| behaviour).

Just because a system doesn't expect a packet doesn't mean it's an attack.

Data in SYNs is defined in 793; it can be ignored (i.e., ACK the SYN but
not the data), e.g., to reduce the server state until TWHS completes (or
uses cookies, as well), but dropping those packets is the anomalous
behavior here.

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 31 Jul 2008 16:02:46 -0700

Hi, Adam,

Adam Langley wrote:
| I posted this a while back and it gathered a little discussion:
|
| http://www.ietf.org/internet-drafts/draft-agl-tcpm-sadata-00.txt
| (implementation in [1])

A few observations:

- - TCP is already permitted to send data in the SYN-ACK
	prohibiting it when the SA-PP option is missing violates
	RFC1122 sec 4.2.2.5 -- unknown options are silently ignored

	options that change TCP need to be explicitly acknowledged,
	and current (legacy) behavior should be assumed if not
	acknowledged

- - TCP is already 'backward compatible' with sources that ignore SA
payload data; that data is just retransmitted
	you note that SA-PP alters the app level protocol;
	it appears to alter its timing, but AFAICT the
	effect would be otherwise invisible to an app

- - The rule "For a given SYN, if any resulting SYNACK frame has a payload
then all resulting frames MUST have a payload" appears to disable
persists and ACKs as would be needed for proper operation when data is
not available in one or more direction

- - AFAICT, it isn't sensible to retransmit a SYN with the same ISN, port,
etc. and different options. Since you do not explicitly acknowledge the
option, how do you know which SYN is being ACKd - the presence of SA
data isn't sufficient (e.g., legacy TCPs could do this)

- - the diagrams need to include some corner cases:
	- when KX is larger than the PMTU in fig 3 (or NList is
	larger than the PMTU in fig 2)
	(i.e., it seems like there is a missing MUST NOT on the length)
	- how do you handle simultaneous opens?

- - can you explain why you use a bit-field for the TCP option flag,
rather than just using a 2-byte option? (i.e., KIND, length)

- ---

---

From: Joe Touch <[email-masked]>
Date: Thu, 31 Jul 2008 16:04:22 -0700

Joe Touch wrote:
|
|
| Murali Bashyam wrote:
| | There are firewalls that drop SYN packets carrying payload, since it's
| | considered anomalous behaviour (rightly so given today's end-user
| | behaviour).
|
| Just because a system doesn't expect a packet doesn't mean it's an attack.
|
| Data in SYNs is defined in 793;...

PS - a SYN-ACK is just a SYN with the ACK set. It can have data just
like any other SYN. The only issue is that the data is not transmitted
to the app until the end of the TWHS; for the SYN-ACK, this is immediate
(vs. putting the data in the SYN).

T/TCP allows pushing the SYN data up to the app before the end of the
TWHS, which is different, as you note.

Joe

---

From: "Adam Langley" <[email-masked]>
Date: Thu, 31 Jul 2008 16:40:08 -0700

>        and current (legacy) behavior should be assumed if not

Ah, I didn't know this. Thank you!

I don't believe changing TCP to disallow this is a good idea. However,
it's important that userland knows weather this experiment is in
effect. Thus, I believe that I should echo the SA-PP option in the
SYNACK. Also, it should probably change names: SYN/ACK Payloads
Processed or some similar.

> not available in one or more direction

That's badly worded on my part. It should read:
"For a given SYN, if any resulting SYNACK frame has a payload then all
resulting SYNACK frames MUST have a payload"

(i.e. the restriction only apply to SYNACK frames. It's just so a host
cannot decide the retransmit a different SYNACK)

> data isn't sufficient (e.g., legacy TCPs could do this)

As you note, as another consequence of my misunderstanding, the
presence of SA data isn't sufficient to tell which SYN is getting
acked. Echoing the option should also solve this issue.

>        (i.e., it seems like there is a missing MUST NOT on the length)

It's suggested that the payload be limited to 64-bytes to prevent
amplification backscatter from a SYN flood. Thus these bytestrings
have to fit within the MTU. If an implementation doesn't enforce this,
then it has to drop support when replying on a link where the MTU is
insufficient.

>        - how do you handle simultaneous opens?

I believe that simultaneous opens work just fine, although both sides
will believe that the other doesn't support this experiment since the
option won't be echoed in the SYN.

> rather than just using a 2-byte option? (i.e., KIND, length)

My hope was that by defining a flags option like this, future options
that require only to signal their presence in a SYN could save space.
If SACK permitted has been defined this way, for example, then this
draft wouldn't need to take any more space.

However, this is very subjective. If people would prefer not to do
this, or would prefer to break it out into its own draft, I'm
perfectly happy with that.

Thanks!

AGL

---

From: "Adam Langley" <[email-masked]>
Date: Thu, 31 Jul 2008 18:04:59 -0700

I've updated the draft with the following changes:
  * Fixed the wording around retransmissions which mistakenly
suggested that no packets of any type could be transmitted without
payloads
  * Renamed the flag to SYNACK Payloads Processed
  * Required that the flag be echoed in resulting SYNACK frames
  * Added discussion of simultaneous open
  * Added discussion of SYNACKs with payloads that are nothing to do
with this spec, noting that they are still permitted

I'll wait to see if there are more comments on -00 before publishing -01.

Cheers

AGL