Re: [Spud] Extensibility considered harmful? was Re: [Privsec-program] Detecting and Defeating TCP/IP Hypercookie Attacks

Brian Trammell <> Wed, 03 August 2016 09:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4381312D1AA for <>; Wed, 3 Aug 2016 02:08:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.189
X-Spam-Status: No, score=-3.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hBCO9kIMRmka for <>; Wed, 3 Aug 2016 02:08:05 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 0B321127078 for <>; Wed, 3 Aug 2016 02:08:04 -0700 (PDT)
Received: from [] ( []) by (Postfix) with ESMTPSA id BA47E1A1166; Wed, 3 Aug 2016 11:07:33 +0200 (CEST)
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: multipart/signed; boundary="Apple-Mail=_4DC0E581-8B4C-467E-8A06-B9AA8899CAEC"; protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail
From: Brian Trammell <>
In-Reply-To: <>
Date: Wed, 3 Aug 2016 11:07:32 +0200
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <5113d019-2405-fba0-0868-04a05ccce3f1@c>
To: Stephen Farrell <>
X-Mailer: Apple Mail (2.3124)
Archived-At: <>
Cc: Michael Tuexen <>, Ted Hardie <>, =?utf-8?Q?Mirja_K=C3=BChlewind?= <>, spud <>
Subject: Re: [Spud] Extensibility considered harmful? was Re: [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: Wed, 03 Aug 2016 09:08:07 -0000

hi Stephen,

Thanks for this; I understand the concerns you have better, now. I have a couple of questions, and one major point of remaining confusion, inline, below:

> On 01 Aug 2016, at 22:55, Stephen Farrell <> wrote:
> Hiya,
> On 01/08/16 19:56, Ted Hardie wrote:
>> On Sun, Jul 31, 2016 at 6:01 PM, Stephen Farrell <
>>> IMO that case has not been made to the point where I would
>>> consider it justifies privacy downsides. IOW, while I am of
>>> course in favour of endpoints being able to signal to one
>>> another without middlebox interference, I am not at all on
>>> side with transport header integrity being counted as a major
>>> win in the analysis of PLUS, if that "win" inherently requires
>>> a significant privacy cost. (And I am clearly happy to endlessly
>>> repeat myself that in this particular case:
>>>        extensibility == privacy unfriendly
>> Stephen, someone naively coming across this statement in the record will
>> think you mean that any extensibility is privacy unfriendly.  Obviously,
>> you have championed the ability to shift cryptographic algorithms as needs
>> change, which requires extensibility of specific forms.   Lots of other
>> work requires extensibility to be useful at all (imagine if the tag space
>> of the web had been frozen in 1993).
>> I should greatly appreciate you reformulating this into something that
>> actually matches your meaning.  That would likely be useful; this is not.
> Sorry if there was context lacking and happy to try elucidate
> further (and please do feel free to help improve my description of
> the issue)...
> In the specific case of exposing higher layer information about well
> protected (e.g. encrypted) traffic to lower layers, (whether via an
> interface from the higher layer, or via addition by the lower layers)
> I believe any extensible mechanism for that kind of interface severely
> risks being extremely privacy unfriendly. And the transport layer may
> be the worst possible case of such an extensible higher/lower layer
> interaction as it by definition spans the full "width" of the network.

(Aside: I'll note again that this isn't the proposal. Transports expose transport layer information that used to be available from inspection of now-encrypted transport headers. Applications can help with this, and of course the APIs should allow applications control over what gets said.  Preventing linkage between that information and higher-level data (e.g. making sure that certain kinds of content aren't commonly tagged so as to be fingerprintable) is a matter for careful design of the vocabulary. It's clear we disagree as to whether it's possible to carefully design a vocabulary that is large enough to be useful. I can't (yet) prove that it is, but I strongly suspect so.)

> I think the main reason is that there would be significant pressure
> and temptation to try support non-technical policies being enforced
> at one place in the network based on information provided at another.
> In this case, by "non-technical," I mean any information not
> absolutely necessary for the correct operation of the lower layer.
> That's a term and definition I'm sure could be improved, and I'm also
> sure there could be borderline cases.

Of course, there's a fair range of opinion hiding behind that "absolutely"; which point along that continuum do you mean? *All* of the extended information we envision applications exposing to the path via PLUS are intended to improve the performance and/or economy of the network. Some of them we're pretty sure will work, while others will require more experimentation to know. Let's say we're wildly successful and PLUS signaling allows a network to operate at a given capacity with M% less spectrum (due e.g. to unwanted traffic rejection before the RAN), or reduce user-perceived latency by N% (loss/latency signaling and other smarter queue management), or use P% less battery in aggregate (due to better state management), or reduce operational diagnostic costs by Q% (in-band measurement), with respect to an approach where we have fully encrypted transport headers. What are the M, N, P, and Q values that divide "absolutely necessary for correct operation" from "non-technical information exposure"?

> But there would immediately also be cases that are nowhere near any
> border... such policies would almost certainly demand methods to expose
> personally identifying information or identifiers that can be easily
> (re)identified as such. That would directly enable the kind of
> meta-data collection and tracking that the IETF has agreed is an
> attack in BCP188. (I assume here that no relevant lower layers "need"
> PII to operate correctly - if they do, they are probably broken:-)
> But another and possibly even worse (ab)use case might signal that the
> person associated with a flow is a member of some set of people, for
> example, over-18, a member of the ruling party, or of some minority.
> The consequences of standardising that kind of extensibility in a way
> that could allow such "policy enforcement" at essentially any place
> on the Internet is for me supremely scary.
> While there do doubtlessly exist use-cases for such extensibility in
> this context that initially appear reasonable, the potential impact of
> the abuse cases, and my own opinion of their probability of occurrence
> being approx 1.0 at some place(s) and times on the big-I Internet for
> me very much outweighs any potential utility from non-abuse cases of
> this particular kind of extensibility.

In your estimation, is the probability of occurrence of this kind of abuse of the present protocol stack, at some places and times on the big-I Internet, currently less than 1.0? (I know you think this question is irrelevant. I'd just like to how bad you think things are today.)

> As an aside, I fully accept
> that folks arguing for non abuse-cases of extensibility are doing so
> with good intentions. I think this is just an unusual case where our
> normal ways of engineering extensibility are way more dangerous than
> usual. (*)
> In the case of the proposed charter at the BoF, the use of an IANA
> registry seems particularly unwise to me as in addition to being
> open to pressure to formally register privacy-unfriendly codepoints,

Now I'm really confused.

Of course this pressure exists. Are you arguing that a vocabulary registry for a signaling protocol which requires a standards action to modify is necessarily less resistant to this pressure than the standards process itself? If so, can you explain the mechanism by which that is the case? Because they seem like exactly the same thing to me.

> any IANA-based scheme would also allow for squatting on codepoints,
> which we know can become a fait-accompli.

How is squatting on codepoints not equivalent to the abuse of widely deployed protocols and implicit behaviors thereof?

> I don't see any way in
> which IETF/IANA processes could resist the pressure to provide such
> "policy" support.

When a registry is requires a standards action to add to, how is this statement not equivalent to "The IETF standards process is incapable of resisting the pressure to provide such policy support"? This seems quite pessimistic, even to me.

> I also cannot think of a non-IANA extensibility
> mechanism that could work here and not have the privacy downsides.

I at least fully agree with you that the IANA-managed extensibility is as dangerous as or less dangerous than non-IANA managed extensibility. So at least we have that. :)

Thanks, cheers,


> And lastly, there is a significant difference here between existing
> non-standard methods for injecting the above kinds of information
> and a world in which we have standardised such extensibility. The
> status quo may allow for such injection but the full horror of the
> worst abuse-cases here would require that the abuse-case information
> flow from end-to-end unimpeded (or almost end-to-end) so reliably
> abusing that kind of information does I think require a standard.
> Hopefully that's clearer, (it's definitely longer;-) and again, I'd
> really welcome crisper and better text to describe these issues as
> I'm sure it's a discussion that will recur at other times and places.
> Cheers,
> S.
> (*) The "usual" dangers of extensibility are I guess complexity and
> loss of interoperability, exemplified in the current debate about TLS
> ciphersuite structure and TLS version intolerance.
>> thanks,
>> Ted
> _______________________________________________
> Spud mailing list