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

[Stephen Farrell <[e-mail]>]

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 "opened...new" 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.)

> 
> (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.

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. So I wonder if the "hypercookie" concept
is even the right starting point here. And to the extent that
PLUS could enable and standardise such things, that is, for me,
a major reason to oppose PLUS. (That's a side-note for this
email, but perhaps a quite fundamental thing to consider in the
overall discussion.)

> 
> 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. Unless we're willing to
> rely on the widespread, altruistic deployment of stateful TCP
> firewalls to reject traffic (I think we can use our experience with
> BCP38 as guidance as to how well *that* will work, and in any case I
> think it would be kind of rich for me of all people to recommend
> throwing more TCP-meddling middleboxes into the mix) 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. 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, 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.

I think it'd be a fine thing to see further analysis of the attacks
and potential mitigations as your draft develops.

> 
> 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. And I think it was clear that a whole bunch of folks
in the room last week also clearly disagreed.

I believe your "only way out" conclusion isn't logically justified as
the argument seems to ignore the downsides of standardising and thus
legitimising "bad" behaviour including behaviours that your draft
properly calls an attack.

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.

Cheers,
S.

> 
> Cheers,
> 
> Brian
> 
> 
> 
> _______________________________________________ Privsec-program
> mailing list [e-mail] 
> https://www.iab.org/mailman/listinfo/privsec-program
>