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

[Stephen Farrell <[e-mail]>]

Hiya,

On 29/07/16 21:18, Ted Hardie wrote:
> 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"

I guess I meant a future in which PLUS-defined PDUs are used as
meta-data in/with various transport protocols.

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

If plus were limited to only emitting those signals then I'd be far
less concerned. I think that would mean that there is no need for any
extensibility and hence no registry. I do not claim to know if those
and only those signals would be sufficiently useful to be adopted by
transport protocols and implementations thereof.

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

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

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

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

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

Cheers,
S.


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