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

[Stephen Farrell <[e-mail]>]

Hi Brian,

Sorry for the slow response...

On 03/08/16 10:07, Brian Trammell wrote:
> 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
>> <[e-mail]> 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.

That's not clear to me. I really can't see how one does what would
work for f/w folks without running into this risk. I fully accept
that many proponents of PLUS don't want to see the privacy-unfriendly
outcome I fear.

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

Determining if such a safe vocabulary is or is not possible seems
like a fine bit of work to undertake for those keen on PLUS.

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

I do think the IANA route is necessarily more risky yes. I do not
claim that there exists an acceptably risky non-IANA approach. The
reason is that if there is an IANA registry for extensibility then
that a) allows squatting and b) constrains protocol design, e.g.
to protocols that allow for a large enough codepoint-space. To try
be more concrete: without an IANA registry one could design a protocol
with one octet of space for some features and one could ensure that
all bits have defined, useful semantics. It would then be possible
to ensure that extending the protocol would generate backwards
compatibility issues. I am not saying that that would be a good
design or a good outcome, but I do think that any IANA based scheme
for extensibility is, in this case, necessarily more risky.

> 
>> 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?

Squatting is easier. And formalising the recognition of
squatted codepoints is also easier.

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

See above.

Maybe this explanation might help too: we create IANA registries for
good reasons, one primary one being that those make it easier to
extend protocols. For protocols where we do not want extensions to be
easy, we ought only very carefully create IANA registries.

Cheers,
S.

> 
>> 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,
> 
> Brian
> 
>> 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 
>> [e-mail] https://www.ietf.org/mailman/listinfo/spud
>