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