Some questions about SPTPS

[Guus Sliepen]

On Thu, Jul 17, 2014 at 05:13:57PM +0100, Etienne Dechamps wrote:

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

If you don't break the key of the metaconnections, then indeed the
legacy UDP connections have PFS. I could indeed just have used SPTPS for
the TCP connections and keep the UDP connections similar to how they
were done before. But then you'd still have to do SPTPS in SPTPS over the
meta-connections to establish an end-to-end-encrypted connection with
the destination node just to exchange the ephemeral keys.

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

I guess so too.

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

But if you do use StrictSubnets then SPTPS improves security, and
improving authorisation of those ADD_SUBNET messages is something for
2.0.

-- 
Met vriendelijke groet / with kind regards,
     Guus Sliepen <guus at tinc-vpn.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20140717/ae43bce0/attachment.sig>