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

[Ted Hardie <[e-mail]>]

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

>
> Hiya,
>
> On 29/07/16 16:54, Mirja Kühlewind wrote:
> > Hi Stephen,
> >
> > I see registries as a needed and valuable part of our standardization
> > process. People ignoring registries as well as things that are
> > explicitly specified in a standards document is a different problem.
>
> Registries can be a useful way to support extensibility. They can
> also be a nuisance that allow for the promulgation of crazy ideas.
> And probably lots in between and all at once;-)
>
> None of the generalities above help in this specific case where I
> remain convinced that any extensible-generic-PLUS is liable to be
> highly dangerous. (And I'm unsure if a non-extensible-PLUS can be
> usefully transport independent.)
>
>
So, it's not clear to me exactly what you mean by "transport independent"
here, so let me drill down a bit.  I think PLUS is proposed for a set of
transports that use the UDP demux (and thanks to Stuart Cheshire for a
useful shorthand for that function).  It expects that those transports will
integrity protect their transport headers and treat as confidential some
aspects of their state exchange (a multiplexing transport, for example,
might decide that the state of the flows being multiplexed should be
confidential).  A PLUS with very limited semantics (start, stop, delay
tolerant, drop tolerant) would likely be broadly applicable to that class
of transports and yet be transport independent (for that specific meaning
of transport).

The folks arguing for this have a set of concerns:

*) Some useful path elements are impaired now, compared to previously.  How
can we safely repair that impairment?  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?  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.

Does this description make sense to you?  Or are we still a bit at cross
purposes here?

Ted