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

[Michael Tuexen <[e-mail]>]

> On 31 Jul 2016, at 18:03, Stephen Farrell <[e-mail]> wrote:
> 
> 
> 
> On 31/07/16 16:45, Michael Tuexen wrote:
>> On 31 Jul 2016, at 16:05, Stephen Farrell <[e-mail]> wrote:
>>> 
>>> 
>>> Hiya,
>>> 
>>> On 31/07/16 13:57, Mirja Kühlewind wrote:
>>>> Hi Stephen,
>>>> 
>>>> yes, I believe that the proposed mechanisms are needed (in the first
>>>> place to address the ossification problem we see in transport - to
>>>> phrase it at a light level) and yes, I believe that the proposed
>>>> approaches have the potential to improve but at least doesn’t degrade
>>>> the situation in general but also the privacy situation that we have
>>>> today in the Internet. If I wouldn’t believe that, I wouldn’t propose
>>>> it.
>>>> 
>>>> The technical basis for this believe (regarding privacy) is that we
>>>> propose a mechanism for integrity checking that is stronger than what
>>>> we have today in transport and therefore makes mangling as least
>>>> detectable. Further, I believe that only a cooperative approach will
>>>> enable large-scale encrypting (that includes transport headers)
>>>> because otherwise operators may be incentivized to block traffic, and
>>>> in this sense standardization of a mechanism for middlebox
>>>> communication would draw a much clearer line about what we as a
>>>> community deem acceptable and what not, instead of declaring all
>>>> in-network functions other than routing as evil.
>>>> 
>>>> I intentionally used the word ‚believe‘ here several times because as
>>>> stated in my previous mail we just have probably very different
>>>> starting points. I do think some parts of our discussion involved
>>>> technical questions, and I hope I could clarify some points. However,
>>>> other parts of the discussion are naturally more vague because we
>>>> both don’t know the future. However, in this sense these ‚first
>>>> principles‘, as I believe you called them below, are purely what
>>>> people believe. But, please note that one of these ‚first principles‘
>>>> is that we in transport see a problem with the ossification today,
>>>> and PLUS is foremost a proposal to address this problem (by enabling
>>>> encryption). Given this, I don’t really understand what your comment
>>>> about the form of the discussion is below.
>>> 
>>> Let me try to clarify a couple of important places where my beliefs
>>> and yours don't seem to co-incide:
>>> 
>>> - I'm not sure the ossification issue is as-it-was 3 years ago,
>>> given QUIC, and to some extent h2 and TLS1.3, but also due to
>>> the much increased deployment of TLS. Given such changes, it
>>> is not at all clear to me that a generic approach (like PLUS
>>> attempts) is best.
>> Hi Stephen,
>> 
>> so do you mean future transport protocols (running over UDP) should
>> define their own protocol specific way of exposing information,
>> similar to the way QUIC does it?
>> That would require constant evolution of middleboxes (NAT, firewalls).
>> 
>> Or are you suggesting that future transport protocols should just
>> use the framing of QUIC (for the unencrypted part) and reuse
>> the (hopefully) upcoming QUIC support of middleboxes?
> 
> I didn't mean either.
OK.
> 
> What I meant was that perhaps the analysis that lead to the
> conclusions about ossification of the transport layer needs
> to be re-done now, give the increase in use of TLS and given
> QIUC is now highly likely to be an IETF WG. (That's a similar
> question to asking if PLUS is OBE, which I think I asked of
> Brian.)
What has changed? Building and deploying UDP based transport
protocols in combination with crypto has been done earlier.
For example in RTMFP by Adobe:
https://tools.ietf.org/html/rfc7016
https://tools.ietf.org/html/rfc7425
Other companies did develop their own protocols and did not
publish it as an RFC.

In the IETF we developed SCTP over UDP and SCTP over DTLS over UDP:
https://tools.ietf.org/html/rfc6951
https://tools.ietf.org/html/draft-ietf-tsvwg-sctp-dtls-encaps-09

All of these activities (including QUIC) focuses on the end points
and can/are deployed without specific middlebox support.
> 
> IIUC the IAB w/s that sorta lead to SPUD then PLUS happened
> before QUIC was mooted as work in the IETF and before many
> services had switched from port 80 to 443.
The crucial point is what was brought up in the QUIC BOF:

Middlebox vendors (I think it was a Firewall vendor at the
mic) explicitly stated that they want to see the QUIC work
done in the IETF such that they can build support for
QUIC in their products.

As far as I understood their argument, it was about knowing
a bit regarding QUIC flows (when is it opened, when closed)
to deal with them. This might result in QUIC specific
support by middleboxes.

SPUD/PLUS would allow this for future transports, if middlebox
vendors would add support for SPUD/PLUS (which they might
or might not do given that there is currently no protocol
using it). So do you think that there is no need for
middleboxes to support transport protocols? That would be
an important point also when looking into the requirements
of QUIC.

Best regards
Michael
> 
> S.
> 
>> 
>> Best regards
>> Michael
>>> - I am unconvinced that "giving up" some privacy in the manner
>>> envisaged will lead to an overall privacy benefit. I very much
>>> fear that opposite - that any extensible mechanism will give up
>>> so much privacy so as to render much higher layer confidentiality
>>> moot.
>>> 
>>> What I meant when referring to first principles was being explicit
>>> in how we're arguing based our these starting points (or beliefs).
>>> 
>>> My perception of the argument (in this thread and the BoF) is that
>>> it is harder because the proponents of PLUS were assuming sharted
>>> beliefs/starting points when responding to folks who have very
>>> different starting assumptions.
>>> 
>>> So for example, I don't think I've seen any of the PLUS proponents
>>> directly provide arguments as to why my concerns/beliefs above
>>> are unfounded. (I have seen assertions that they are unfounded but
>>> not arguments starting from assumptions with which I'd agree.) And
>>> my guess is that the proponents are not doing that because they
>>> think it was already done. (If a pointer to the SPUD archive is
>>> usable to answer this point, that's entirely fine.)
>>> 
>>>> 
>>>> However as you mentioned the BoF belong, I actually also have a
>>>> comment on the form of discussion: this activity is on-going for more
>>>> than one year. We mainly worked during this time on addressing
>>>> security questions that were raised at the spud BoF. Based on one
>>>> request on the mailing before the PLUS BoF we explained how we
>>>> address privacy concerns and how we think this makes the current
>>>> situation at least not worse and probably better. We did not get only
>>>> further feedback on mailing list assuming that our proposal is
>>>> acceptable. And there was no future discussion about any privacy and
>>>> security aspects on the list before the BoF. I would really
>>>> appreciate if people could constructively help us to find a solution
>>>> to address the ossification problem in transport while maintain or
>>>> improving the privacy situation we have today, instead of just
>>>> blocking new work.
>>> 
>>> Yeah, that's fair. It is of course hard to get input from folks
>>> who are worried that the work as envisaged inevitably leads to a
>>> bad outcome. (So e.g. I'm not subscribed to the SPUD list and am
>>> not sure I'd have time and the energy to be on there constantly
>>> trying to drag you back to 1st principles;-)
>>> 
>>> Cheers,
>>> S.
>>> 
>>>> 
>>>> Mirja
>>>> 
>>>> 
>>>> 
>>>>> Am 30.07.2016 um 14:14 schrieb Stephen Farrell
>>>>> <[e-mail]>:
>>>>> 
>>>>> 
>>>>> Hiya,
>>>>> 
>>>>> I agree with your conclusion that we seem to have clearly set out 
>>>>> where we disagree without so far changing one another's
>>>>> conclusions. So I only have one more thing to add for now, which is
>>>>> about the form of, and not the content of, the discussion. You
>>>>> said:
>>>>> 
>>>>> On 30/07/16 12:07, Mirja Kühlewind wrote:
>>>>>> Enabling large scale encryption that is deployable is the goal
>>>>>> of PLUS. And this enables two things: increased security and
>>>>>> privacy, as well as transport evolution. For the first goal we
>>>>>> need encryption and maintain the status quo (regarding network
>>>>>> manageability), while for the second part, we envision the
>>>>>> development and use of new transports that enable new services.
>>>>>> Not having a tool to also enable some innovation in the network
>>>>>> to support these services, archives the goal only half way.
>>>>> 
>>>>> I'm fine with and fully accept the first sentence.
>>>>> 
>>>>> The rest of that paragraph however seems to me to beg the
>>>>> question, that is, it assumes that a deployed PLUS-solution will be
>>>>> an overall good, when it is exactly that that I and others wish to
>>>>> question. I do think this is an issue in this discussion and was in
>>>>> the BoF - the proponents, being convinced that the solution is
>>>>> needed, assume that the solution is needed when answering those who
>>>>> are questioning whether we'd be better or worse off should PLUS be
>>>>> developed further.
>>>>> 
>>>>> That's probably natural given folks have been working on SPUD/PLUS 
>>>>> for some time, but it seems to me to hinder discussion with folks
>>>>> like me who are far from convinced that the envisaged solution is
>>>>> at all desirable. So my apologies for trying to drag you back to
>>>>> what you likely consider first principles you probably figured were
>>>>> done with a couple of years ago, but I think that's actually fair
>>>>> and to be expected when one has a BoF of this kind.
>>>>> 
>>>>> Cheers, S.
>>>>> 
>>>>> 
>>>>>> 
>>>>>>>> 
>>>>> 
>>>> 
>>>> _______________________________________________ Privsec-program
>>>> mailing list [e-mail] 
>>>> https://www.iab.org/mailman/listinfo/privsec-program
>>>> 
>>> 
>>> _______________________________________________
>>> Spud mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/spud
>> 
>