Re: [tcpinc] Summary of arguments from call

[ianG <[e-mail]>]

On 3/08/2015 16:15 pm, Mirja Kühlewind wrote:

> - better interaction with/transition to use of application-layer TLS:
> 	- "good fit for out-of-band negotiation of application-layer TLS“
> 	- "allows applications to seek full TLS if available and upgrade to it“
> 	- "TCP INC as a transition technology/simple evolution path“


One thing that I am surprised at is the notion that we can get an 
"efficiency" by deploying the same crypto inside TCP as well as at the 
application layer.

 From an engineering pov, this makes sense, but from a security 
engineering pov, this makes no sense to me.  There appear to be three 
spaces.



*Security model space*.  If I really want security in my design, I will 
design it in.  And I will organise the whole security to be available 
and operational.  "There is only one mode, and it is secure."  I figure 
the business model, develop the threat model, analyse the risks and 
deploy the defences.  WYTM and all that.

Given that assumption, the notion that a lower layer might also be doing 
some "security" is cute at best, irrelevant for most part, a dangerous 
distraction if we pay attention to it, and at worst a security breach.

E.g., How do I integrate that lower-layer security statement into my 
security statement?  There has to be an impedance mismatch between what 
the application wants/demands and what is provided by fait from below, 
and if there isn't I need to give my fee back - I didn't do the job! 
Rationalising those statements together is just going to raise 
complications.  Real security doesn't compose that easily.

E.g.2, what happens if the statement is optional?  Why would I even 
bother to rely on it if it wasn't 100%?  What's easier - write code that 
always does what I want, or write code that switches between two paths 
according to some vague claim?

The only rational solution is to ignore the bottom layer entirely. 
Pretend it isn't there.  Do what your users demand of them - secure them.



*Best practices space*.  Now, there may be some who adopt a standard 
security model (say TLS's security statement) as the security statement 
of their application and then a sense that we just need to export that 
into TCP (not sure what to call this...).

But this is just a reflection that the application hasn't got a strong 
security model.  This would be the world of 'best practices' being that, 
you do what all the other turkeys are doing, and life is good until 
thanksgiving.  Online banking, anyone?  If it hasn't done it's own 
analysis, then, well, it gets what it's given.  Which also means there 
is no particular need to integrate TLS-outside to TLS-inside.  Sure you 
can do that if you want to, but we're in security lala land anyway so 
whatever you want to do is fine, and using a whole security working 
group for 2 years to push the lala agenda seems a bit inefficient.



*No security land*.  The third case - where the application hasn't done 
security at this level at all - is where we are actually aiming in this 
group.  If there is NO SECURITY (because security was too hard, because 
we stuffed up, or because some nasty put a barrier in place), then we 
can significantly ease things by providing some opportunisic magic under 
the covers.  Not everything, every time, but what we can do for free is 
good, will be appreciated in time, will save some people.

But in that case, again, there is no need to consider integrating 
upwards.  The goal is what we can do for free, not trying to reach out 
to someone who cares more.



In summary, from each of these general perspectives, there is no need to 
integrate and only elusive or debatable security benefit.  Yes of course 
there is a potential efficiency gain on paper, but that seems to me to 
be putting the geek's mind ahead of the user's needs.  The user wants 
simplicity plus reliability and doesn't care if the cores end up 
encrypting twice to get it.



> 	- "two stacks means twice the attack surface and twice the number of security bugs"


This also makes no sense.  Yes the attack surface is bigger, but if the 
two systems operate independently, then the attack surface is divided, 
and *both* must be attacked to get all the way through.  Only if you 
complicate things by interacting the stacks will there be twice the 
*dependent* attack surface, and then the risk of bugs will go up.

Even if it is the same code, a failure is less likely to be deployable 
efficiently against both stacks.  The risk goes down, even as the number 
of bugs goes up.  Diversity is a security win.



iang