Subject: [multipathtcp] Comments on draft-bagnulo-mptcp-privacy-00

From: Olivier Bonaventure <[email-masked]>
Date: Tue, 16 Jul 2019 14:40:03 +0000

Marcelo, Amelia, Christoph,

Thanks for having initiated the above draft. As I will not be able to 
participate to the discussion in Montreal, here are some suggestions and 
comments.

Generic comments

First, I think that it would be useful to compare the privacy features 
of QUIC (or a forthcoming Multipath QUIC) with those of MPTCP. 
Obvisouly, given that MPTCP does not encrypt anything, it suffers from 
more types of privacy attacks than QUIC.

Second, beyond looking at the issues with the current version of MPTCP, 
we could consider whether an hypothetical MPTCP version x could solve 
some of these issues. In the draft, you mention the possibility of 
encrypting some of the MPTCP options. If this is done with the keys 
exchanged in clear during the handshake, it would probably not help. 
However, since a privacy sensitive application would anyway use TLS, why 
not consider a solution like

https://datatracker.ietf.org/doc/html/draft-paasch-mptcp-ssl

that basically extracts the MPTCP keys from the TLS exchange. The above 
draft has experied, but could probably be updated to support TLS 1.3 and 
the latest version of MPTCP.

If we had this extension inside MPTCP, which options would need to be 
encrypted/authenticated :

- MP_CAPABLE(no)	
- MP_JOIN (maybe)
- DSS (but TCP sequence number would not be encyrpted)
- ADD_ADDR
- REMOVE_ADDR	
- MP_PRIO	
- MP_FAIL	
- MP_FASTCLOSE

Another possible design point is MPTCPSec, see 
https://inl.info.ucl.ac.be/publications/secure-multipath-tcp-design-impementation.html

A third design point would be to explore the integration of TCPINC and 
MPTCP, if this is possible.

Detailed comments

I think that it would be useful to provide a discussion on privacy 
considerations in the configuration of MPTCP and when add_addr and 
mp_join should be sent. A client that always sends add_addr and creates 
a full mesh of subflows is more vulnerable from this viewpoint than a 
client that does not send add_addr and only sends mp_join when the 
primary path fails. Of course, this increases the reaction time in case 
of failures.

Changing the token in mp_join is something that looks interesting. We 
could imagine a server that provides to its client the next token to be 
used (possibly encrypted). This allows the server to control the 
numberof subflows that a client can establish, and also improves 
privacy. I would encourage you to explore this direction and also 
consider the implementation cost on servers.

Considering the benefits of spreading data over multiple paths, there 
are benefits from the viewpoint of countering an attacker willing to 
capture the entire bytestream. On the other hand, an attacker who wishes 
to simply collect metadata about who talks with who would get more data 
from mptcp than from regular tcp...

Overal, I think that there are many tradeoffs between privacy, reaction 
to failures, protocol/implementation complexity that would be worth to 
discuss in the draft.

Best regards,

Olivier

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 18 Jul 2019 11:44:50 +0200

Hi Olivier,
Thanks for your comments, replies below...

> more types of privacy attacks than QUIC.

I am uncertain about this.

I mean, so far, the security analysis we have done for MPTCP we used TCP 
as a baseline. I think this was a useful approach as it has allowed us 
to progress with realistic expectations and using the rule of not making 
things worse than currently are (i.e. TCP). I think the same approach is 
useful and reasonable for privacy.

Also, what we currently have standardized is MPTCP (not MPQUIC). So, it 
is possible to perform a comparative analysis of two protocols we have 
(MPTCP and TCP). It is much harder to make the analysis of a protocol 
that has not been standardized yet (MPQUIC) as it is a moving target.

That being said, I do agree that there is a value in defining what would 
be the goals and requirements in terms of privacy for MPQUIC or for a 
more secure version of MPTCP that encrypts the payload, but this would a 
different analysis.

In summary, i think there is room for two analysis:

- a analysis the privacy of MPTCP as currently defined and using TCP as 
a baseline. This document would identify the privacy threats that MPTCP 
as currently defined introduces with respect to TCP.

- the definition of goals in terms of privacy (and probably in terms of 
security) for a more secure version of MPTCP and also MPQUIC.

This draft aims to do the first bullet. I am happy to also work on 
another document for the second bullet but i believe are different 
documents as one is an analysis of the residual threats of an existent 
protocol (and proposes minor changes to fix them) and the other one is 
an ex-ante protocol defining the privacy requirements of a new protocol 
(by new i mean major changes than current MPTCP)

> exchanged in clear during the handshake, it would probably not help.

Well, this depends on the goal we set.

So far, the goal has been to be no more vulnerable to TCP and we are 
essentially vulnerable to an attacker on the path when the key is 
exchanged. The proposed approach would make provide a similar level of 
protection for privacy threats, which i would guess is aligned with the 
current security features of MPTCP.

Agree we could define more ambitious goals, but this would be both for 
privacy and security. See the two analysis that i suggest above.

> MPTCP, if this is possible.

I agree with all these possible approaches for a security/privacy 
enhanced version of MPTCP. I also think there is value in having a minor 
modification that remediates the privacy threats compared to plain TCP.

> primary path fails. Of course, this increases the reaction time in case

Agree, this is something we wanted to include in the document, but it 
was not clear to me what guidelines to include in there. any suggestions?

> consider the implementation cost on servers.

Great, we can do that.

Also, I guess we need some mechanism for endpoints to detect if the 
other endpoint supports this mechanism. Fortunately, i dont think this 
is needed to be done in the SYN.

> from mptcp than from regular tcp...

Not sure what more metadata the attacker would obtain.

I mean, with the current version, it can extract metadata from the ADD 
ADDR and from the MPJOINs, as the draft identifies. You mean that or 
something else beyond what is identified in the draft?

(I am not sure the other options provide any form of useful information 
to the attacker)

> to failures, protocol/implementation complexity that would be worth to

Agree, the idea would be to identify those missing and include them in 
future versions of the document.

Thanks again,

Regards, marcelo

>
> Best regards,
>
>
>
> Olivier
> _______________________________________________
> multipathtcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multipathtcp
>