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
_______________________________________________
Tcpinc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tcpinc
