Re: [Spud] Detecting and Defeating TCP/IP Hypercookie Attacks

[Christian Huitema <[e-mail]>]

On Friday, July 29, 2016 5:34 AM, Brian Trammell wrote:

>...
>... As I said
> during my presentation last Thursday, Ted Hardie and I sat down to think
> about this at lunch a couple of months ago, and found six ways one could
> execute hypercookie injection or coercion today before our pizza showed up.
> 
> I sat down a little longer to write these up. I found five more, without even
> considering trivial out-of-band metadata leaks or steganographic side
> channels. https://tools.ietf.org/html/draft-trammell-privsec-defeating-tcpip-
> meta-00 is the result. The conclusion: these attacks are trivially easy to
> execute today by exploiting the gap between valid TCP traffic and what will be
> ignored by TCP-indifferent devices and endpoints, as well as all those juicy bits
> IPv6 gives you...

The original message generated a long thread of comments, but I would like to look back at Brian's draft. First of all, this is an interesting piece of information, and I would like to thank Brian for writing it down. Whether we believe that additional shim headers are wise or not, we should certainly look at current privacy threats against TCP and IP, and as much as possible deploy mitigations.

Here is a set of detailed comments:

- Section 4.1.2, regarding DHCPv6, ought to quote RFC 7844, Anonymity Profiles for DHCP Clients, which specifies mitigations for that threat.

- Section 4.1.3, Identification using IPv6 network address translation, probably needs a bit more context. The NAT can only identify the user context if it links that context to a User-ID, which is somewhat hard for shared connections. But we should take this seriously and develop mitigations, e.g. end-to-end encrypted options that report the address seen by the peer. It would not prevent translation, but it would expose the practice.

- Section 4.2.1.  Fragment Identification Rewriting. Maybe it is time to specify in IP that if the "don't fragment" bit is set, the fragment identifier MUST be set to all zeroes, and SHOULD be reset to zero on reception. If enough end systems and intermediaries do that, this side channel becomes unreliable.

- Section 4.3.  Abusing Transmission Control Protocol Features. All that is true, but it is also part of the rationales for deploying encrypted transports like QUIC. As far as I can tell, none of these attacks apply to QUIC. Which is indeed the point made in section 5.

The draft mentions the IPv6 flow-ID, but creative intermediaries might also manipulate the TOS fields, so maybe there should be a subsection describing that too. And we could also have recommendations for API designs that expose the received values, so cooperating endpoints could detect alterations.

I think the draft should be extended to also cover UDP, and in particular the side channel created by the potential gap between IP packet length and UDP packet length. My personal preference would be to instruct middleboxes and end-systems to simply drop packets in which UDP length and IP length do not match.

-- Christian Huitema