Tcpcrypt in Debian
Mailing list to discuss Tcpcrypt packaging in debian -- please join if you're interested!
Notes from Tcpcrypt ad-hoc discussion in DebConf14
concerns:
- does libtcpcrypt hang when tcpcryptd is not available?
- proper minimization
- why mkdir with launch_tcpcryptd.sh instead of in tcpcryptd itself?
- systemd service file
- package tcs?
- built-in check.tcpcrypt.org network test service? what happens if we don't use that?
- interaction with VPNs, etc?
- persistent client identities?
- can this be run at the gateway?
- choice of ports to divert? choice of ports for listening?
- can tcpcryptd use unix-domain socket for control instead of loopback tcp socket?
system integration concerns
- integration with shorewall, ferm, other puppets, etc.
- talk with debian kernel team
- talk with dsa about network check server
- inverting default ports
- can check be done with popcon?
- encourage installation on tor exit nodes?
do we want a pkg-tcpcrypt packaging team?
things to work on:
- wireshark decoder
- put tcs in tcpcryptd
- how does state serialization work -- can you stuff it in the kernel? what happens to existing connections when you restart tcpcryptd?
- review forward secrecy
- review linkage to libssl instead of libcrypto
- licensing: libnfnetlink vs openssl?
- hcrypto is 3-clause BSD license for krb5
- some sort of tcpcrypt observatory system?
- do we want a mechanism to announce tcpcrypt other than the options? (rough consensus seemed to be "no" -- if an announcement mechanism is available out of band, it should be used for stronger crypto
- talk to ooni people to add tcpcrypt to ooni probe.
- consider linkability of sessions
- backport to wheezy (someone got it working during the session)
- IPv6?
- improve iptables filtering to bypass diversion when not enabled (use mark during syn and avoid sending unmarked out to userspace?)