Re: [multipathtcp] draft minutes for montreal meeting

[Olivier Bonaventure <[e-mail]>]

Yoshi,

> Sorry for the delay. I uploaded a draft minutes for montreal meeting.
> You can take a look at the URL below.
> Please let the chairs know if you have corrections, suggestions or 
> questions.
> 
> https://datatracker.ietf.org/doc/minutes-105-mptcp/

Thanks for sharing these detailed minutes. I have some comments after 
having read them.


> 
>    Keith Moore:
>        Is there support in the room for working on a secure (encrypted) version
>        of MPTCP?
> 
>    Chairs:
>        Show of hands: How many would be willing to work on an encrypted version.

We proposed such a design in an infocom paper, see
https://inl.info.ucl.ac.be/publications/secure-multipath-tcp-design-impementation.html
There was running code on Linux but we have not maintained it since 
publication.
> 
>    Mirja (as individual):
>        If you want encryption, use QUIC.
> 
>    Chairs:
>        Would work on be a bad idea?
>        (a couple) and why?
> 
>    Nicolas P:
>        I think it's too heavy. Would require encryption of options. >
>    Yoshi:
>        TCPINC was oribinally intended to be used for MPTCP. But, it does not
>        encrypt options. Do we want to create an updated version?
> 
>    Mirja:
>        There is zero deployment of TCPINC. I would suggest to first get
>        deployment experience.

If people want to experiment with our implementation, this should be 
possible. My personal viewpoint is that adding full security to MPTCP is 
probably too difficult at this stage if the objective is to have a 
deployable solution.
> 
>    Markus:
>        Will there be another meeting at IETF 106?
> 
>    Chairs:
>        No decision has been made so far.
> 
>    Alan Ford (on Jabber):
>        MPTCP + TLS was proposed some time ago.
> 
>    Yoshi:
>        Someone wants to revive this?
> 
>    Alan Ford (on Jabber):
>        If someone is interested, I would contribute. The proposal was to use
>        TLS key extraction for the session security. It was only a 4 page draft
>        in -00. If there was interest in encryption at transport level, I would
>        suggest to use this as a starting point.
> 
>    Mirja:
>        If there is interest, bring it to the TLS working group.
> 
>    Marcelo:
>        TLS is used as it is.
> 
>    Mirja:
>        TLS may not be happy about an interface to expose the keys.

We also had an implementation of this approach. If would probably need 
to be updated now that TLS 1.3 has been published and that kTLS is 
available in the Linux kernel. In a nutshell, the idea was to derive two 
additional TLS keys (i.e. different keys than the ones used to 
authenticate and encrypt data) and give them to MPTCP to replace the 
keys that are exchanged during the handshake. This improves the security 
of the addition of new subflows but does not counter attacks where an 
attacker modifies encrypted payloads.

I can participate in the discussion on this if there is interest.


Olivier