Subject: [tcpinc] Summary of arguments from call

From: Mirja Kühlewind <[email-masked]>
Date: Mon, 3 Aug 2015 17:15:29 +0200

Hi all,

as promised my summary of arguments for and against a certain approach (see below). Text in quotes is more or less copied from someone's mail as an indication what exactly the argument was and how often this point was raised. Not guarantee I’ve captured everything but I’ve tried my best.

I personally would summarize this as simplicity and maturity are the main arguments for tcpcrypt, while people at the same time are afraid that the dependencies on TLS could hold up the work. For TCP-use-TLS the main argument is that re-use might help to avoid bugs and make it simpler, as well as good interactions with the higher layer TLS which may allow transition in future.

Probably no surprising results; hope it’s still helpful for you to have the summary below!

Mirja

-------------------------------------------------

a) TCP-use-TLS
Pro: 
- re-use of existing code/mechanisms will help to avoid bugs: 
	- "security bugs in developing a new security protocol; less problems than something new“
	- "TLS will ensure better and deeper security analysis“
	- "light weight filter can be smaller, and thus easier to verify, debug, or even prove“
	- "New code is undesirable in security systems"
- re-use makes it simpler: 
	- "simple and direct application of TLS“
	- "better than an entirely distinct protocol"
- 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“
- easier to deploy: 
	-„more likely to achieve ubiquitous encryption because easier to deploy“
	- "TLS-the-brand is established and trusted by vendors -> acceptance more quickly"
- can also be implemented in kernel: 
	- "profile of tls can be produced that will be acceptable to kernel developers“
	- "embedded systems already do TLS in the kernel“
	- "TCP-use-TLS is not restricted to implementation in applications *or* in user-space"
- appropriate candidate to pick one: 
	- "serves the purpose of opportunistic encryption“
	- "two stacks means twice the attack surface and twice the number of security bugs"

Contra:
- dependency on TLS and update cycles of other working group
	- "opposed to putting TLS into TCP"
	- "TLS is very slow to update at the institutional level“
	- "TLS depends on other WG“
	- "do not want see TCPINC and TLS1.3 tightly coupled -> can lead to delay and friction“
	- "TLS proposal also limits the ability to make modifications because need to interoperate w/ the TLS spec/WG“
- can’t not be implemented in the kernel:
	- "TLS not be suited for running in supervisor mode“
- no code available/no proof of feasibility 
	- "TLS has only working code/substantial experience outside TCP“
	- ""passthrough" mode of TLS proposal looks unlikely to work"
- effectively there is no re-use:
	- "TLS1.3 which is brand new - experience argument does not apply here"
	- "codebase is going to be new anyway“
	- "likely flawed argument applies equally to both proposals“
- should not require a userland implementation/modification
	- "TLS proposal still allows for implementations to do a minimal implementation where TLS is pushed down to userland“

b) tcpcrypt
Pro:
- simplicity: 
	- "Tcpcrypt looks much simpler“
	- "clean, tight, simple“
	- "is simpler“
	- "_simple_ protocol“
	- "simplicity“
	- "simpler"
	- "a simple, easily-understood security primitive with provable security properties“
	- "simple approach to authentication"
- running code and higher level of maturity
	- "working code and experience"
	- "one complete document"
	- "some current runing code“
	- "started working earlier since there is more content to review“
	- "basically ready-to-go“
	- "experience of a working implementation“
	- "research on the impact on middleware boxes“
	- "the Internet-Draft is more detailed“
	- "running code“
- ‚cleaner‘, more self-contained approach (more suitable to TCP, separation of authentication, …)
	- "more specifically suited to TCP"
	- "more self-contained“
	- "a clean break with legacy systems"
	- "a natural separation between application-specific authentication and general-purpose encryption“
- easier to implement in the kernel:
	- "use in a kernel (FreeBSD) environment“
	- "more likely to make it into a kernel"
- higher chance of (quick) deployment:
	- "quick adoption by major Linux distributions"
	- "more likely to see actual deployment, especially in a kernel“
- no dependencies on TLS/other working group
	- "less dependence on other WGs or legacy standards/formats“
	- "isn't anchored to another working group's specification -> easier to modify“
- Diversity:
	- "broader base of applicability"
	- "experience with working on tcpcrypt will be informative (if not followed on)"
	- "adds to the diversity of protocols"
	- "additional genetic diversity" 

c) both
Pro:
- "Kernel vs user space arguments aren't really important"
- "both good starting points"
- "more implementation and experimentation experience needed“

Contra
- "risk of nothing much happening until November"

---

From: Martin Thomson <[email-masked]>
Date: Mon, 3 Aug 2015 09:51:27 -0700

In the interest of factual accuracy, and because I didn't have a
chance to refute these arguments previously...

> - dependency on TLS and update cycles of other working group

Also a Pro.  We know that TLS is going to get continued maintenance.

> - can’t not be implemented in the kernel:

Not entirely true.  I believe that Microsoft does this.  Netflix have
done a partial kernel port.  Of course, I appreciate that it might be
considered more difficult as a result of living in the kernel, and
that the existing TLS code for operating systems like Linux is likely
a poor fit.

---

From: Martin Stiemerling <[email-masked]>
Date: Mon, 3 Aug 2015 21:54:23 +0200

Hi,

> that the existing TLS code for operating systems like Linux is likely

Believe is not a proof. Any evidence for this?

   Martin

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 3 Aug 2015 13:03:56 -0700

> Believe is not a proof. Any evidence for this?

For the claim that MSFT has kernel-mode TLS?

Here's what Christian said yesterday:

"That argument rings a bit hollow for a Windows kernel developer, since we
have in fact access to S-Channel in the Windows kernel. Windows web servers
rely on the HTTP.SYS kernel driver, which implements TLS using the kernel
API for S-Channel. HTTP.SYS has been doing that for a long time, so there
is indeed some experience with that solution. "

-Ekr

>   Martin
>
>
> _______________________________________________
> Tcpinc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpinc
>

---

From: Joe Touch <[email-masked]>
Date: Tue, 4 Aug 2015 10:29:16 -0700

FWIW, there were a number of issues raised when tcpcrypt was presented
to the transport area. I haven't seen those raised here, and it would be
useful to know how they affect both current proposals.

You might want to contact the TSV for that.

Joe

---

From: ianG <[email-masked]>
Date: Tue, 04 Aug 2015 20:43:28 +0100

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

---

From: John-Mark Gurney <[email-masked]>
Date: Tue, 4 Aug 2015 13:15:51 -0700

Martin Thomson wrote this message on Mon, Aug 03, 2015 at 09:51 -0700:
> > - can???t not be implemented in the kernel:
> 

This is good evidence:
https://msdn.microsoft.com/en-us/library/windows/desktop/aa364671(v=vs.85).aspx

> that the existing TLS code for operating systems like Linux is likely

I'm helping out w/ the Netflix in kernel TLS code, and right now the
code only does encryption (no decryption), and for normal write
traffic frames are constructed in userland, only for sendfile is the
frame constructed in the kernel...

It requires all key negotiation to be done in userland, so isn't even
close to a TLS-use-TCP implementation...

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."