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

[Stephen Farrell <[e-mail]>]

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.

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.

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. 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,
any IANA-based scheme would also allow for squatting on codepoints,
which we know can become a fait-accompli. I don't see any way in
which IETF/IANA processes could resist the pressure to provide such
"policy" support. I also cannot think of a non-IANA extensibility
mechanism that could work here and not have the privacy downsides.

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
>