Error: Failed to load processor TracNav
No macro or processor named 'TracNav' found

Emanuele Aina (em)

http://nerd.ocracy.org/em

Security

  • telekinesis needs authenticated and secure communications
  • at the XMPP level use starttls with mutual x509 certificates exchange when creating connections
  • it needs a way to protect from forged mDNS-SD packets

DNSSec

  • DNSSec SIG(0) could be the right solution, but they are not yet implemented in Avahi and relying on them will prevent the use of mDNSResponder on Windows, so this could only be the long term plan
  • mDNSResponder support is needed because Avahi is not yet ported to Windows and, even when it will run on it, we would need to write a compatibility wrapper for other programs, as running two mDNS stack on the same host is not recommended
  • with DNSSec we could even use the CERT record to publish certificates before the setup of the XMPP connection, but it can increase the packet size without a real benefit as each user will store the trusted certificates after the first XMPP connection

Ad-Hoc Solution

  • put a signature of the user data from the TXT record in the TXT record itself, appending a 'signature' field after the signed data and verifying it using the public key found in the certificate exchanged during the starttls handshake
  • use RSA/SHA1 for the signature itself and, taking inspiration from RFC 2535 and RFC 3110, add an algorithm field with value 5 (as specified in RFC 3110) and two fields for the inception and expiration time of the signature (from section 4.1 of RFC 2535). Maybe add a keytag field if one has multiple keys in its public certificate.

How it works

Mark and John connect to the same LAN:

  • Mark starts its XMPP-LL client
  • after a while John connects too and starts its own XMPP-LL client
  • Mark sees John as a untrusted user
  • John want to chat or send a file to Mark
  • Mark gets John's public certificate in the starttls exchange
  • Mark's client stores John certificate
  • Mark can put John in the trusted users or leave him untrusted

The next time Mark and John are on the same LAN:

  • Mark sees John and verifies his signed presence data with the signature in John's certificate
  • if John has not been put in the trusted list show him again as untrusted
  • if John is trusted and the signature is verified everything is ok
  • otherwise complain loudly and mark John as compromised