Subject: [multipathtcp] REMINDER: Thursday 3rd October: MPTCP interim (audio) meeting on security

From: <[email-masked]>
Date: Wed, 2 Oct 2013 10:54:45 +0100

Just a reminder that tomorrow (Thursday) we have our interim call, to progress improving security of MPTCP, in order to make progress on advancing RFC 6824 on the standards track.

Audio details etc at http://trac.tools.ietf.org/wg/mptcp/trac/wiki/Interim_Oct_2013
3pm GMT (local times http://www.timeanddate.com/worldclock/fixedtime.html?msg=MPTCP+interim+Oct+2013&iso=20131003T15 )

Ps a volunteer to take notes would be excellent

Thanks!

From: Eardley,PL,Philip,TUB8 R
Sent: 27 September 2013 11:57
To: [email-masked]
Subject: RE: [multipathtcp] Thursday 3rd October: MPTCP interim (audio) meeting on security

Chatting with a couple of people and thinking about the way forward.

Marcelo has suggested a 2-pronged approach:-

Prong 1: how to improve RFC6824 to solve the ADD_ADDR attack. The aim is to get security equivalent to RFC5061 (SCTP with dynamic addresses). We can also improve RFC6824 to make some of the fallback cases clearer (I remember that came out of the implementation survey). We could hope to do this quite quickly as a relatively small improvement to 6824, since there was some discussion on the list a while back how to solve this.

Prong 2: RFC6824 sends the key in the clear on the MP_CAPABLE exchange - What could we do better?  We've had some possibilities mentioned in the past, but I don't think there's any consensus yet.

Personally I think this seems a good way forward. We could do Prong 1 quickly if it looks like Prong 2 will take some time

Comments on this approach welcome.
Also if anyone would like a timeslot in the interim meeting, please let us know

Reading
http://tools.ietf.org/html/draft-bagnulo-mptcp-attacks-00

thanks

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: 09 September 2013 17:32
To: [email-masked]<mailto:[email-masked]>
Subject: [multipathtcp] Thursday 3rd October: MPTCP interim (audio) meeting on security

Let's fix the date of the interim meeting for Thursday 3rd October at 3pm GMT (note, the clocks change at different times in different regions of the world, this time is in GMT/UTC)

Will send audio details later

Thanks!
phil

From: Eardley,PL,Philip,TUB8 R
Sent: 06 September 2013 10:59
To: [email-masked]<mailto:[email-masked]>
Subject: MPTCP interim (audio) meeting on security - please update your doodle

I extended the doodle to the first week of October.
Please could you update your entry or fill in

Sorry for the trouble

Thanks
phil

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: 04 September 2013 08:31
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [multipathtcp] MPTCP interim (audio) meeting on security, late September

Just to let you know. The Security Ads are kindly finding us a security advisor, but no luck yet. So we may have to delay this slightly.
Also, it would be good if there was some discussion on the mailing list before the call.

phil

From: Eardley,PL,Philip,TUB8 R
Sent: 21 August 2013 08:36
To: Eardley,PL,Philip,TUB8 R; [email-masked]<mailto:[email-masked]>
Subject: RE: [multipathtcp] MPTCP interim (audio) meeting on security, late September

Just a reminder, as I know a lot of people have been on holiday, please fill in the doodle

Thanks
phil

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: 06 August 2013 13:49
To: [email-masked]<mailto:[email-masked]>
Subject: [multipathtcp] MPTCP interim (audio) meeting on security, late September

We think it would a good idea to have an interim (audio) meeting, in order to make progress on advancing RFC 6824 on the standards track.

We will discuss the security of the MPTCP protocol. The aim is to reach consensus on what security improvements are needed - and what are not needed - in order to progress MPTCP on the Standards track. We hope to cover both the threat(s) that we will handle and, at a high-level, the solutions that will be defined.

Please fill in the doodle at http://doodle.com/xdf8eaiavvna9bcy#table

For previous MPTCP WG interims, ~3pm GMT has been OK. Please shout if the time is no good for you.

In the meantime, please keep discussing MPTCP's security on the list!

Thanks,
Best wishes
Phil & Yoshifumi

---

From: Sean Turner <[email-masked]>
Date: Wed, 02 Oct 2013 12:34:56 -0400

Unfortunately, this conflicts with the IESG informal telechat where 
we'll be deconflicting the upcoming IETF meeting's agenda.  How long do 
you calls usually last, I might be able to call in if we get done early.

spt

On 10/2/13 5:54 AM, [email-masked] wrote:
> Just a reminder that tomorrow (Thursday) we have our interim call, to
> progress improving security of MPTCP, in order to make progress on
> advancing RFC 6824 on the standards track.
>
> Audio details etc at
> http://trac.tools.ietf.org/wg/mptcp/trac/wiki/Interim_Oct_2013
>
> 3pm GMT (local times
> http://www.timeanddate.com/worldclock/fixedtime.html?msg=MPTCP+interim+Oct+2013&iso=20131003T15
> )
>
> *From:*Eardley,PL,Philip,TUB8 R
> *Sent:* 27 September 2013 11:57
> *To:* [email-masked]
> *Subject:* RE: [multipathtcp] Thursday 3rd October: MPTCP interim
> (audio) meeting on security
>
> Prong 1: how to improve RFC6824 to solve the ADD_ADDR attack. The aim is
> to get security equivalent to RFC5061 (SCTP with dynamic addresses). We
> can also improve RFC6824 to make some of the fallback cases clearer (I
> remember that came out of the implementation survey). We could hope to
> do this quite quickly as a relatively small improvement to 6824, since
> there was some discussion on the list a while back how to solve this.
>
> Prong 2: RFC6824 sends the key in the clear on the MP_CAPABLE exchange -
> What could we do better?  We’ve had some possibilities mentioned in the
> past, but I don’t think there’s any consensus yet.
>
> Personally I think this seems a good way forward. We could do Prong 1
> quickly if it looks like Prong 2 will take some time
>
> *From:[email-masked]
> <mailto:[email-masked]>
> [mailto:[email-masked]] *On Behalf Of
> [email-masked] <mailto:[email-masked]>
> *Sent:* 09 September 2013 17:32
> *To:* [email-masked] <mailto:[email-masked]>
> *Subject:* [multipathtcp] Thursday 3rd October: MPTCP interim (audio)
> meeting on security
>
> Let’s fix the date of the interim meeting for Thursday 3^rd October at
> 3pm GMT (note, the clocks change at different times in different regions
> of the world, this time is in GMT/UTC)
>
> *From:*Eardley,PL,Philip,TUB8 R
> *Sent:* 06 September 2013 10:59
> *To:* [email-masked] <mailto:[email-masked]>
> *Subject:* MPTCP interim (audio) meeting on security - please update
> your doodle
>
> *From:[email-masked]
> <mailto:[email-masked]>
> [mailto:[email-masked]] *On Behalf Of
> [email-masked] <mailto:[email-masked]>
> *Sent:* 04 September 2013 08:31
> *To:* [email-masked] <mailto:[email-masked]>
> *Subject:* Re: [multipathtcp] MPTCP interim (audio) meeting on security,
> late September
>
> Just to let you know. The Security Ads are kindly finding us a security
> advisor, but no luck yet. So we may have to delay this slightly.
>
> *From:*Eardley,PL,Philip,TUB8 R
> *Sent:* 21 August 2013 08:36
> *To:* Eardley,PL,Philip,TUB8 R; [email-masked]
> <mailto:[email-masked]>
> *Subject:* RE: [multipathtcp] MPTCP interim (audio) meeting on security,
> late September
>
> *From:[email-masked]
> <mailto:[email-masked]>
> [mailto:[email-masked]] *On Behalf Of
> [email-masked] <mailto:[email-masked]>
> *Sent:* 06 August 2013 13:49
> *To:* [email-masked] <mailto:[email-masked]>
> *Subject:* [multipathtcp] MPTCP interim (audio) meeting on security,
> late September
>
> We think it would a good idea to have an interim (audio) meeting, in
> order to make progress on advancing RFC 6824 on the standards track.
>
> We will discuss the security of the MPTCP protocol. The aim is to reach
> consensus on what security improvements are needed - and what are not
> needed - in order to progress MPTCP on the Standards track. We hope to
> cover both the threat(s) that we will handle and, at a high-level, the
> solutions that will be defined.
>
> In the meantime, please keep discussing MPTCP’s security on the list!
>
> Thanks,
>
> Best wishes
>
> Phil & Yoshifumi
>

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 02 Oct 2013 17:56:43 +0100

> you calls usually last, I might be able to call in if we get done early.

And I'll be less likely to make it sorry.

I'd encourage folks to think about moving the bar up to a tcpcrypt
equivalent level of security for mptcp though - that seems well worth
more than a look.

S