Subject: [tcpinc] MPTLS : Making TLS and Multipath TCP stronger together

From: Olivier Bonaventure <[email-masked]>
Date: Thu, 06 Nov 2014 08:42:52 +0100

Hello,

I won't unfortunately be present in Hawai personally but will try to 
participate remotely. Since the Toronto meeting, several solutions have 
been explored in this group and an important part of the Hawai meeting 
will be devoted to a discussion whether whether tcpinc should protect 
the header or not.

In addition to the three drafts that are currently discussed, I have 
submitted to the MPTCP working group a draft that explores how TLS and 
MPTCP could be integrated together. This is another design point that 
might be of interest for this working group as well. Several of the 
features included in MPTCP to support multiple paths are also very 
useful to deal with packet injection attacks, which is one of the 
elements of the discussion on whether the header should be protected.

The first version of this draft is available at :

http://www.ietf.org/internet-drafts/draft-bonaventure-mptcp-tls-00.txt

Comments are more than welcome

Olivier

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 6 Nov 2014 15:12:14 +0200

On Thu, Nov 06, 2014 at 08:42:52AM +0100, Olivier Bonaventure wrote:
> submitted to the MPTCP working group a draft that explores how TLS and MPTCP
> could be integrated together. This is another design point that might be of
> interest for this working group as well. Several of the features included in
> MPTCP to support multiple paths are also very useful to deal with packet
> injection attacks, which is one of the elements of the discussion on whether
> the header should be protected.
> 

Some quick comments:

- MPTCP AFAIK mostly runs in kernelspace, so using TLS seems pretty complex
  (I hope one doesn't have to fish anything out of certificates, since
  those are ASN.1).
- Using TLS oppurtinistically is insecure without session_hash extension
  (not standardized yet!).
- Block cipher mode is a bit deprecated in TLS. And the TLS construct
  assumes that mode.

-Ilari

---

From: Olivier Bonaventure <[email-masked]>
Date: Fri, 07 Nov 2014 09:38:40 +0100

Ilari,
>> Comments are more than welcome

Thanks for your feedback.

>    (I hope one doesn't have to fish anything out of certificates, since

Current MPTCP (Linux, FreeBSD, ...) are kernelscape, but this is not 
mandatory. MPTCP does not need to be seen as a monolithic software, we 
can expose interfaces to TLS that enables the TLS user-level 
implementation to pass some records such as the initial handshake and 
use MPTCP for the data records.

> - Using TLS oppurtinistically is insecure without session_hash extension

MPTLS could be used opportunitically or not. Different modes are possible.

> - Block cipher mode is a bit deprecated in TLS. And the TLS construct

The draft assumes that the MAC can be computed separately from the 
encryption. I'll be looking at other TLS modes and see how they can fit 
in the proposed architecture. Pointers to the key deployed modes are 
more than welcome

Olivier

-- 
INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be