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

[Spencer Dawkins at IETF <[e-mail]>]

On one specific point ...

On Jul 31, 2016 09: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.

It seems to me that understanding the current levels and rate of change on
deployment of these technologies would be extremely helpful, given the
discussions we are having.

Spencer

> Given such changes, it
>   is not at all clear to me that a generic approach (like PLUS
>   attempts) is best.
> - 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
>