Some questions about SPTPS

[Etienne Dechamps]

On 07/17/2014 09:35 AM, Guus Sliepen wrote:
>> - I am not sure what the thread model for SPTPS is when compared with the
>> legacy protocol. SPTPS is vastly more complex than the legacy protocol (it
>> adds a whole new handshake mechanism), and it's not clear to me why it needs
>> to be that complicated. According to the Security page, the weakness of the
>> legacy protocol are "Predictable IV" and "Truncated MAC". I'm guessing SPTPS
>> is not designed solely to address these (relatively simple) issues.
>
> SPTPS itself is actually not much more complicated than the legacy
> protocol. It indeed fixes the weaknesses in the legacy protocol, and
> it's actually based on TLS 1.2 but with cipher suite negotiation and
> public key exchange removed, instead using a fixed cipher suite with the
> PFS property, and always assuming both sides have each other's public
> key. The goal is to implement the best current practices.

I'm not sure how PFS is an improvement in that regard, considering the 
legacy protocol used ephemeral keys. There is no way to decrypt a legacy 
protocol packet without knowing the ephemeral key, and the only way to 
know the ephemeral key is to decrypt the metaconnection messages, so the 
only place where PFS is needed is on the metaconnections.

>> - The way SPTPS is currently implemented in tinc, sending packets over TCP
>> is extremely inefficient because instead of using PACKET messages like the
>> legacy protocol does, it encapsulates the packet in a REQ_KEY message (for
>> backwards compatibility reasons, I guess). The problem is, the packet
>> contents are encoded using... base64. Now, I know that TCP over TCP is not
>> supposed to be very efficient in the first place, but a 40% encoding
>> overhead seems excessive to say the least. More generally, it's not clear to
>> me why SPTPS even needs to be used to send packets over metaconnections
>> which are supposed to be trusted.
>
> It's only using those REQ_KEY messages when communicating via
> intermediate nodes. The reason is that this allows for networks with
> both 1.0.x and 1.1 nodes. Now, it's true that it still uses the REQ_KEY
> messages when the intermediate nodes are version 1.1, but that is
> something to be fixed before 1.1.0 is released.

I might end up implementing the 1.1-specific messages myself, if I have 
some time and you don't mind. I guess it's as simple as adding new 
senders/handlers and make them fall back to REQ_KEY if the other side's 
version is pre 1.1.

>> Another performance issue with SPTPS over TCP is that it requires an
>> handshake (which adds to initial communication latency), while the
>> legacy PACKET mechanism doesn't.
>
> A big difference is that in the legacy protocol, the PACKET messages are
> encrypted hop-by-hop, while with SPTPS the packets are encrypted
> end-to-end. That requires the extra handshake.

I get that, but in practice it's not clear how that improves security in 
any way. In the current state, if you gain control over a node in the 
middle, you're screwed anyway, even with SPTPS, because the compromised 
node can easily force you to send your data to it (there are multiple 
ways to do that I guess - messing with ADD_SUBNET messages sounds like 
the most obvious one). In fact, if you're not using StrictSubnets the 
compromise of *any* node results in complete compromise of the entire 
network (again by sending ADD_SUBNET). I fail to see how SPTPS prevents 
that.

-- 
Etienne Dechamps