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

Stephen Farrell <> Fri, 29 July 2016 20:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 47AE212D144 for <>; Fri, 29 Jul 2016 13:17:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.588
X-Spam-Status: No, score=-5.588 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5axH6tphzOiA for <>; Fri, 29 Jul 2016 13:17:13 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9246A12D1CB for <>; Fri, 29 Jul 2016 13:17:13 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 639F7BE3F; Fri, 29 Jul 2016 21:17:12 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PkAvHCg4SAk4; Fri, 29 Jul 2016 21:17:07 +0100 (IST)
Received: from [] ( []) by (Postfix) with ESMTPSA id 53306BE3E; Fri, 29 Jul 2016 21:17:06 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=mail; t=1469823426; bh=iBUKao61ODrjs2cLAkuNpPO5jz8t6MhjrBiaYIE85Lw=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=ipdzZ1Nrz/SIoNQydzq4ArNt1DP7Sn/g4KUVxxN3h5tGwVtC0RRKXqdcU7s73Gu8D irEAP3KksSYohtwPhbNHT6JGqarAj+CBOiuuwhMo5Ol/2sxiunbDRlZAipmQIksvia clM+VM4tfrWSkqKp3ZN5yJl6QK5sJd27ZHGoXv6k=
To: Brian Trammell <>
References: <> <> <>
From: Stephen Farrell <>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <>
Date: Fri, 29 Jul 2016 21:17:05 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="I6q3dw2xI35wxntvkmCw48JUqmnmq2m2R"
Archived-At: <>
Cc:, spud <>
Subject: Re: [Spud] [Privsec-program] Detecting and Defeating TCP/IP Hypercookie Attacks
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Session Protocol Underneath Datagrams <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 29 Jul 2016 20:17:16 -0000


On 29/07/16 17:22, Brian Trammell wrote:
> hi Stephen,
>> Hi Brian,
>> On 29/07/16 13:33, Brian Trammell wrote:
>>> Greetings, all,
>>> During the PLUS BoF last week, concern was expressed that a
>>> generic signaling mechanism such as proposed opened two new
>>> attack surfaces:
>> No necessarily "" perhaps more "risked making much more
>> ubiquitous." At the meeting I didn't hear anyone claim these were
>> new attacks. (I did hear you say they were not new.)
> Point; shall we say "may widen two existing"? (Of course, I disagree
> that PLUS does widen this surface, otherwise I could not in good
> conscience work on it. I am afraid we simply have to agree to
> disagree here, though.)

Well, PLUS would have to minimally extend the attack surface at
least in an xkcd-one-more-standard manner. One could still in good
conscience argue for that though if one thought that the existence
of the new, standard method for injecting meta-data meant that the
overall amount of privacy unfriendly behaviour would be reduced.
While that's an argument that could be made, I'd not be convinced
by it unless we had evidence that standardising something like PLUS
would result in just that changed behaviour, and I can't see that
that's possible.

>>> (1) A method for endpoints to allow path elements to add 
>>> non-integrity protected signals presents a surface for metadata 
>>> injection attacks, where an entity who can place devices on a
>>> user's access network and has information about the user's
>>> identity could exfiltrate that information to third parties. For
>>> purposes of giving it a name, let's call this a hypercookie
>>> injection attack ("hyper" since it exists in a space completely
>>> inaccessible to the application).
>>> (2) Even if path elements are not allowed to say anything, a 
>>> mechanism to allow endpoints to add integrity-protected signals
>>> to their traffic presents a surface for coercion attacks. An
>>> access provider can force a user to tag traffic with their user
>>> ID or some other token (a signed assertion that an advertisement
>>> has been viewed to the end, or maybe even just straight-up
>>> bitcoins) in order to get "better" connectivity, or even any
>>> connectivity at all. A more classically Orwellian dystopian
>>> variant of this attack has a government requiring citizens to tag
>>> all their outgoing traffic with some government-issued
>>> identifier. Let's call this a hypercookie coercion attack.
>>> I am less concerned about the surface PLUS presents to these
>>> attacks than those who have raised the concerns in the BoF and on
>>> the mailing list, because the current Internet architecture is
>>> already quite vulnerable to them. 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.
>> Wrt injection I can buy that totally. Having read your draft I
>> don't find enough there to accept your assertion wrt coercion -
>> ISTM that coercion attacks have not been analysed yet in your
>> draft.
> Agreed that the analysis isn't where I'd like it to be yet. There are
> two major reasons for this. One, this draft is focused on in-band
> abuse of TCP and IP features (which seemed a good place to start) and
> it's not clear to me that the real threat of coercion lies at this
> layer at all: coercion attacks seem a lot easier to implement with
> out of band techniques at the application layer. 

Hmm, not sure myself. Worth pondering and (hey, your fav... :-)
doing some measurement.

> Second, with respect
> to the threat at this layer, it seems that coercion attackers would
> want to be less detectable, which expands the space of abuse to
> include low-frequency temporal domain side channels and other
> quasi-in-band sorts of things.

There's a lot packed into the above sentence that I think may be
usefully unpicked in future revisions of your draft. I'm not sure
I agree about wanting to be less detectable - the common usage of
outrageous terms and conditions is both detectable and fits here.

> Coercion is at its heart a layer 9 attack, though, and a good
> analysis of it that takes this into account would make the draft much
> better. Happy to accept text on this. Need to get the source into a
> public GitHub repo to send PRs against, first.
>> As a side-note, meta-data doesn't have to be person-specific to be
>> controversial - "over 18" and anything with similar semantics, e.g.
>> "member of <this> minority" can very clearly be equally or more
>> damaging, yet totally non-identifying if the relevant set of folks
>> is large enough.
> Of course; this is an orthogonal question, though. 

Yes and no. The question is a side-note in my mail but IMO crucial to
the questions about PLUS overall.

> Here we're
> considering how many bits you can inject or leak. How many bits you
> need is a question of how large the space of signals is. If what
> you're concerned about is linkage on a very small number of bits,
> though, then everything is even more ruined than we think.

Well, I didn't agree that ruined is a good descriptor though:-)

My point is that the entropy of the signal ought not be the only
consideration - there have historically been some societies where
just one bit (in-group/out-group) would have been sufficient to
cause an awful lot of damage. I think we really do need to think
hard about changes to the transport layer that might enable such
discrimination at that layer and at such scale.

> <snip>
>>> ... the only way I can see out is to add integrity protection to
>>> all transport and network-layer headers, as well as
>>> confidentiality protection to those headers the path does not
>>> need to see.
>> I don't agree. Observatories seem to me like a mitigation that your
>> draft does not consider.
> Good point. We should add large-scale Internet observatories to the
> list of general mitigation approaches (Yay! more measurement to do!).
> This scales a bit better than firewalls everywhere, but still
> requires you to throw a lot of power and cooling at the problem if
> you're going to get enough scale to make the attacks too dangerous to
> execute.

That's not clear to me at all. Some observatory functions may only
require putting up a server that says what it sees, or even better
building such features into loads of other servers that have a day
job. Things like [1] and [2] aren't necessarily that expensive and
can play their part here I think and even though observatory might
not be the right term for those, such things can be part of the
overall set of mitigations here.

   [1] (no working https, sorry:-)

But yes, other observatories may be more expensive.

>> If the attacker here does not want to be seen to be attacking, then
>> those can be effective. Should we standardise a method for such
>> abuse,
> ... noting that one of the points of this draft is to make it clear
> that we *have already standardized* at least eleven methods for such
> abuse with the publication of RFCs 791, 3315, 4291, 6437, 6864, and
> 6994, among others. 

I would not use the above phrasing. I don't believe that the IETF
intended to standardise the abuse-cases in all of those. I'm not
even sure if the folks concerned thought of those abuses before it
was too late. If there are cases where we did, documenting that would
also be a fine thing for your draft to do, to help us understand
how to not make those mistakes again.

> These standards don't condone the abuse they
> enable, but by having MUST NOT send / MUST ignore language, which
> remains good engineering practice for interoperability, they *do*
> enable it, 

Right. Making that point in your draft (or wherever), may be quite
valuable. (Maybe there's a statement or two to add to 3552bis on
this topic as well?)

> and in terms of how much evil the abuse can result in, I
> don't see that there's really any practical difference between the
> condoning and enabling.

I do, as previously noted.

> Methods for encrypting transport headers, whether specific to a
> single transport protocol (QUIC) or generic (PLUS), would, however,
> make injection impossible, not just somewhat-mitigatable.

So a different question: what other protocol that is not QUIC is one
where PLUS would be beneficial? And wouldn't the existence of PLUS
and it's use with any protocol that didn't encrypt as much as QUIC
represent a clear standardisation and extension of the bad features
here? (I guess I may be partly asking if the SPUD/PLUS idea has been
OBE here.)

>> then I think it's quite possible the attacker may argue that their
>> behaviour is not an attack as it's just a part of "the standard."
>> Such a mitigation could be attempted against the attack in 4.1.3 of
>> your draft for example so I disagree with the draft's assertion 
>> that "no user-initiated mitigation is possible" in that case at 
>> least and maybe others.
> Whether an observatory counts as "user-initiated mitigation" or not
> is a semantic quibble. Fine.

Some observatories are, some are not. One for 4.1.3 could well be
user-initiated and cheap. That may well not be the case for others
that could be useful against other of the attacks in your draft.

>> I think it'd be a fine thing to see further analysis of the
>> attacks and potential mitigations as your draft develops.
> An open invitation to all: text appreciated. :) One thing I do want
> to do is some measurement to see on how many paths these work as
> advertised.
>>> This is, of course, the whole point of PLUS. We can and should
>>> have a discussion of what the endpoints should be able to say,
>>> and what the endpoints should be able to let the path say. But if
>>> we're concerned about this attack, the general approach is AFAICT
>>> the only way out.
>> I disagree.
> Again, agreeing to disagree.
> But I think we also have a specific misunderstanding here: the point
> I wanted make *here* was not "you need PLUS". (I think you do, but
> that's a separate question.) The "general approach" I referred to
> (sorry for not being more precise) is: "you *at the very least* need
> cryptographic integrity protection of transport headers, with
> confidentiality protection for things the path doesn't need to see".
> We can have honest disagreements about what the path needs to see and
> doesn't, and we should do engineering analysis of the
> cost-risk-benefit tradeoffs in order to resolve those disagreements.

Yes, discussions on the above can be had (and I'm sure you've been
having 'em happily without me for quite a while:-).

I don't however see how those discussions lead to a conclusion that
there is value in an an attempt to provide an extensible and transport-
independent solution. That last seems like maybe the least desirable
approach one could take here as I think it leads to solutions that
are most open to additional abuse.

>> Frankly, I was and remain puzzled by SPUD/PLUS. ISTM that we have 
>> different sets of sensible folks reaching diametrically opposed 
>> conclusions based on the same facts and arguments. Perhaps the
>> tl;dr in your abstract may be a hint there - I do not think
>> everything is ruined myself, so maybe one's level of opt/pess-imism
>> affects one's view of the valid conclusions to reach in this
>> space.
> I suspect I've spent a bit too much time staring at how TCP breaks
> over my career, which is the source of my pessimism, on this
> particular topic, at least.

Sure. The question is whether or not that's part of the reason we
see folks coming to such different conclusions. I don't claim to
know the answer btw;-)

> One purpose of the draft in its present state is that I realized
> during the PLUS BoF that others may be making overly optimistic
> assumptions about what the transport layer does and does not do as
> defined, and to make sure that everyone who cares to read the draft
> has a shared understanding of how TCP breaks, so they can make their
> own conclusions about their own pessimism. I do hope that it can
> evolve into a generalized guide to breaking brokenness for this
> particular set of attacks, though.

Yeah, I think the evolution of your draft may be of value independent
of PLUS.


> Thanks, cheers,
> Brian
> _______________________________________________ Privsec-program
> mailing list