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

[Ted Hardie <[e-mail]>]

On Fri, Jul 29, 2016 at 1:40 PM, Stephen Farrell <[e-mail]>
wrote:

>
> Hiya,
>
> >
> > The folks arguing for this have a set of concerns:
> >
> > *) Some useful path elements are impaired now, compared to
> > previously.
>
> FYI, I find the term "impaired" scarily vague in this context. It could
> mean anything from "0.1% less reliable" to "no longer allows me assert
> that the person using the machine is over 18." That lack of specificity
> and the absence iiuc of public data describing the claimed impairments
> damages the argument of the PLUS proponents here.
>
>
The specific impairments vary over the type of network, but the class is
"consume more resources than previously".  Resources here can be radio
bandwidth, power from a total radio power budget, delay intolerant queue
slots, state table size, and so on.  Note that these impairments have
implications for the end systems as well, as the hoary example of UDP
heartbeat traffic and NAT state shows.


> > How can we safely repair that impairment?
>
> That depends on what is considered impairment and without a shared idea
> of that I don't think we can get to an answer.
>
> Does the class given above help?



> > Where safely means:  not restoring
> > plaintext for inspection nor providing a worse-than-current side
> > channel for identification.  (I accept that analysing one against
> > "current" requires understanding ease of attacking the side channel)
> >
> > *) If there is a new, popular transport protocol, how do we ensure
> > that it does not end up as the new HTTP, used for a variety of things
> > not because it is suitable on design fit but because it gets through
> > the network?
>
> (Aside: if new transports are as successful as http, then we're making
> progress I think:-)
>
>
QUIC has that potential, if the race against HTTP/2 tests so far are any
guide.

> To put this another way, how do we make sure that the
> > new design pattern given above opens innovation at that transport
> > layer?
> >
> > While the proponents of PLUS believe that a substrate approach is the
> > most deployable (because you can redefine things like SRTP to run
> > over PLUS instead of bare UDP), we care much more that the approach
> > meets those concerns than the approach be a substrate.  If you want
> > to call it a "design pattern" and implement it in a couple of
> > candidates from that design pattern, fine.  You end up describing the
> > thing multiple times rather than once, but cut and paste is a fine
> > tool.
>
> I agree with your last there. I actually think cut'n'paste is likely
> a better approach here - it means that one can evaluate the essential
> signals in each case, whereas the substrate/shim approach requires
> that one has that dangerous extensibility. And for what real value?
>
> I'm not sure that the substrate/shim approach does require dangerous
extensibility; if we limit it to get what's needed, we may avoid the
danger.  And the value is the usual:  common libraries, common APIs, and
common understandings of the threat model.


> >
> > Does this description make sense to you?  Or are we still a bit at
> > cross purposes here?
>
> Aside from the vagueness in "impairment" I think I understand it yes.
> (And this may be a thing where it's possible to not be talking at
> cross purposes and yet still disagree as to whether there ought be
> any path forward at all for PLUS.)
>
>
regards,

Ted


> Cheers,
> S.
>
>
> >
> > Ted
> >
> >
> >
> > _______________________________________________ Privsec-program
> > mailing list [e-mail]
> > https://www.iab.org/mailman/listinfo/privsec-program
> >
>
>