Re: [tcpinc] Review of draft-bittau-tcpinc-tcpeno-01

[ianG <[e-mail]>]

On 26/08/2015 18:25 pm, Kyle Rose wrote:
>> ps; The argument doesn't apply generally either:
>>
>> a. We here are far better placed to choose the Internet's crypto suite for
>> the general case than any manager, committee, or sysadm.
>
> Agreed, but how are you proposing to force a change when a particular
> cipher suite starts to show its age?

v += 1

Eg:  SSL v2 -> v3 -> TLS 1.0 -> 1.1 -> 1.2 -> 1.3

The changes in the protocols needed generally exceed the lifetime of 
well-chosen ciphersuites, so any upgrades won't unduly increase the 
cycle count much.


> It seems that those decisions
> need to be made locally as software is upgraded, and certainly it is
> not realistic for a global change to be done atomically. No agility
> now => no ability to change, ever. I've been down this path too many
> times to have hope.


Well, the experience is pointing to security upgrades being pushed by 
the product supporter out to user land, and sysadms following the 
general advice "keep all software up to date."  In user land this is 
enacted by Apply updates, patch Tuesday and the like.  The sore thumb 
here is Android.  99% of sysadms don't care whether it is TLS 1.1 or TLS 
1.2, they just want it to work.


>> b. If the Russians don't trust it, they are entirely at liberty to write
>> their own crypto protocol and back-fit it into their software.  It's not
>> that hard, and if they care - which they do for natsec - they'll be
>> backfitting software anyway.
>
> I think I might agree about any one specific case, but at what point
> are the goals of the WG defeated by this attitude? Only the Russians?
> "Ok, I guess." The Russians and the Chinese? "Well, that's a lot of
> people..." The entire US government too? "Uh..." What about the
> banking system? "..."


That's a hypothetical.  But assuming that there is some merit to that, 
why not?  The goal is to stop mass surveillance, right?

And, for TCPINC - do we care that much?  Why not have the Russians, the 
Chinese, and the NSA advise that TCPINC is bad for them, so they're 
going to ... do their own.

Isn't that the endorsement we need?


> The high level goal here is to have a framework for global encryption
> of all TCP traffic. Fragmentation acts against this goal.


Right.  And being all things to all governments is probably going to be 
a bigger fragmentation than charging ahead and doing the tcpcrypt thing 
fast and furious, with one cipher suite.

Tcpcrypt could have been already out in v0.1 by now.  We could have been 
rolling it out for 6m already, and starting to think about v1.0.

Instead we're chasing a "perfect" protocol in an imperfect MITMable 
threat scenario.  Who's winning here?


>> d. Unlike the WB/IMF/UN, IETF isn't a subsidy organisation to deliver
>> solutions to governments.  It delivers to the masses, not any particular
>> squeaky wheel.
>
> Absolutely. But I think there are enough squeaky wheels on this issue
> that they are a substantial constituent of the wider internet
> community, and not simply ornery outliers.


The nature of the squeaky wheel is to say "squeak!  Listen to me or 
else."  But if you don't listen, the wheel suddenly starts rolling, 
because it doesn't want to miss out.

It's an economic thing - formation of cartels, equilibria and all - the 
incumbent argues against the new order, as much as possible, but once 
it's a done deal, the incumbent adopts.

Which is to say, in order to make this argument stick "we have to listen 
to the Russians, Chinese, NSA and other squeaky wheels" you'd also have 
to show that they won't suddenly find some oil when the machine starts 
moving without them, *and* they represent a constituency that can shift 
the internet.

Of course - you will recognise I am actually arguing against consensus 
model to an extent.  But that's a given for this topic.  Mass 
surveillance, TCPINC, we know there are going to be people who fight 
this one.

All governments are recused.



iang



ps; if you want to take this private, I'm happy - I'm pretty sure I'm 
arguing from the golf course rough, not the IETF rough.