Subject: [multipathtcp] Fwd: Stephen Farrell's Discuss on draft-ietf-mptcp-api-06: (with DISCUSS and COMMENT)

From: Wesley Eddy <[email-masked]>
Date: Thu, 15 Nov 2012 12:29:11 -0500

-------- Original Message --------
Subject: Stephen Farrell's Discuss on draft-ietf-mptcp-api-06: (with
DISCUSS and COMMENT)
Date: Tue, 13 Nov 2012 09:19:31 -0800
From: Stephen Farrell <[email-masked]>
To: The IESG <[email-masked]>
CC: [email-masked], [email-masked]

Stephen Farrell has entered the following ballot position for
draft-ietf-mptcp-api-06: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

These ought be easy to resolve. If they're real issues, I'm
fine with making them into comments that can be resolved by the
chairs/AD or holding the discuss if that's better. If not,
then I'll be glad I checked anyway:-)

(1) Sorry if this is the wrong document for this comment, but
it only occurred to me now to check, so maybe you can say if it
applies and we can see what, if anything to do then. RFC 5246
section 7.2.1 says that once you've gotten a TLS close_notify
then you close the TLS session, and also that each side is
required to send a close_notify before closing the write side
of a TCP connection. Does that mean we missed a security
consideration in MPTCP that should have highlighted that there
may be work to be done in a TLS implementation for it to run
over MPTCP gracefully if one side wants to close some of the
subflows? Or, is that something that should/could go in here
where e.g. we say if using a basic or advanced API to implement
TLS then don't do that? If something ought go in this draft
then it'd probably be a good plan to check the text with the
TLS wg before you're done.

(2) In a similar vein, if TLS with an SNI with an IP address is
being used (rfc6066 says you can't, but who knows what's done
in the wild) and/or if a TLS certificate has IP addresses in
the SAN, then should something special be done to handle that
or could it cause an unexpected failure?  Again, if text is
needed it should probably be checked with the TLS wg. This may
also affect TLS/MPTCP via a legacy API (not sure).

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

- Would it be useful to add a security consideration to the
effect that applications may need to revisit some
assumptions about the sockets API that could impact on
security? Not sure what text precisely but I'd expect new
buffer problems might be likely here in practice if the
size of the return from getpeername() etc changes and
not all calling code is aware that MPTCP is in use.

---

From: Yoshifumi Nishida <[email-masked]>
Date: Wed, 21 Nov 2012 15:25:43 -0800

Hello Stephen,

Thanks for the comments.
I would like to clarify some points.

In basic API, application uses one socket to utilize MPTCP with
conventional APIs and doesn't know about if some of subflows are connected
or disconnected. There's no way to control subflows from the application
except closing all subflows, which indicates terminating the session.
So, in my understanding, we won't need to do anything for application when
some(but not all) of the subflows are disconnected/closed for some reasons.
When the socket is about to close, I think we'll need to do the same things
as what TLS over normal TCP does. But, this will be a generic guideline for
application, not specific to TLS.
Could you elaborate the concerns about TLS over MPTCP?

> also affect TLS/MPTCP via a legacy API (not sure).

The basic APIs utilize single IP address which is the IP address of first
subflow.
This might cause problems since there might be a situation where the IP
address is not accessible anymore while MPTCP is still running.
But, I'm not very sure if this will be a problem in this case. Could you
explain the cases where might cause failures?

As the basic APIs utilize single IP address, I think the size of the
returned parameters will be the same as conventional APIs.
So, I think there's at least no buffer problem here.
Could you let us know if there're other security implications?  (BTW, 4.4.3
describes some guidelines related to socket buffer size)

Thanks,
--
Yoshifumi Nishida

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 22 Nov 2012 09:36:58 +0000

(cc'ing iesg, since some other folks had similar
concerns to mine)

> Could you elaborate the concerns about TLS over MPTCP?

Ah, that may be partly a misreading on my part, I missed that
the TCP_MULTIPATH_SUBFLOWS was only a get and not a set option.

So, in this case, it may be fine to just say that a TLS implementation
on top of the basic API ought not close_notify just because the
set of subflows has changed, and perhaps note that this could be
more of an issue for the advanced API.

I could buy an argument that this doesn't need to be stated,
as it might open cans of worms since you're not saying how
other existing applications make use of the basic API though.
OTOH, it might still be worth including, since its a real
case where someone might do the wrong thing otherwise. What
do you think?

> explain the cases where might cause failures?

I can well imagine that different TLS/MPTCP implementations
might react differently since there are different reasonable
things one might do here, and that could break interop.

At one end of the spectrum, an implementer might conclude that
if IP addresses are in a TLS client or server cert then all
addresses for all subflows MUST be mentioned. This might be
called the 'strict' approach.

At the other end, another implementer might conclude that
if any IP address of any subflow is mentioned in the cert
then its all ok. (Possibly even ignoring if that address is
for the 1st subflow or not I guess.) This might be called
the 'lax' approach.

So, don't you need to say if 'strict' or 'lax' or something
in between is right, because if you don't then TLS sessions
between 'strict' and 'lax' implementations might fail depending
on the content of the cert, which'd seem wrong to me.

Cheers,
S.

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Sun, 25 Nov 2012 23:56:54 +0100

Stephen, Yoshifumi,

Please find some comments inline, marked by [MSC].

Thanks

Michael

________________________________
Von: [email-masked] [[email-masked]] im Auftrag von Yoshifumi Nishida [[email-masked]]
Gesendet: Donnerstag, 22. November 2012 00:25
An: multipathtcp; Stephen Farrell
Betreff: Re: [multipathtcp] Fwd: Stephen Farrell's Discuss on draft-ietf-mptcp-api-06: (with DISCUSS and COMMENT)

Hello Stephen,

Thanks for the comments.

In basic API, application uses one socket to utilize MPTCP with conventional APIs and doesn't know about if some of subflows are connected or disconnected. There's no way to control subflows from the application except closing all subflows, which indicates terminating the session.
So, in my understanding, we won't need to do anything for application when some(but not all) of the subflows are disconnected/closed for some reasons.
When the socket is about to close, I think we'll need to do the same things as what TLS over normal TCP does. But, this will be a generic guideline for application, not specific to TLS.
Could you elaborate the concerns about TLS over MPTCP?

[MSC] I am also struggling with understanding why TLS should have problems with MPTCP (but, indeed, it is a fair question - I don't recall much discussion on TLS in the working group). First, I'd assume that TLS could be understood as a legacy application, without any additional API. If TLS sends a "close()", the draft-ietf-mptcp-api-06 in section 4.3.1 states that the whole MPTCP conncetion will be closed - same as for TCP. Thus, MPTCP and TCP should behave in the same way. It is not clear to me why closing should therefore result a security issue for TLS. Apart from that, you raise an interesting question, namely whether and how TLS would use the basic API. I've not looked into TLS, but at first sight that would mainly make sense if TLS uses any of the more "advanced" socket calls already today. Any recommended pointer on that? (But, it may be offtopic, see below.)

> also affect TLS/MPTCP via a legacy API (not sure).

The basic APIs utilize single IP address which is the IP address of first subflow.
This might cause problems since there might be a situation where the IP address is not accessible anymore while MPTCP is still running.
But, I'm not very sure if this will be a problem in this case. Could you explain the cases where might cause failures?

[MSC] Use of addresses in TLS certificates is an interesting question that I have not been aware of. Thanks for raising this. But I am not sure if TLS would actually want to care about subflow addresses. This would probably require a own specification "TLS over MPTCP". If it requires changes in TLS, it is probably not in scope of this document. And this actually contracts the idea of MPTCP, which intends to keep subflow details transparent to whatever runs on top. My impression is that we should first sort out the case that TLS is using the legacy API only, i. e., unware of MPTCP at all. I think that TLS could just continue to use the addresses of the first subflows in certificates, because at the time of connection setup they are valid. I am currently thinking whether TLS would require the use of 'fate-sharing', i. e., that the MPTCP connection has to be closed if the first subflow dies. This would ensure that the certificate's data is indeed valid during the whole MPTCP connection. But 'fate-sharing' as a whole is an area that needs further experiments. In summary, I think that we need a dedicated paragraph on TLS in the security considerations, but my current understanding is that TLS is not really affected when using the legacy API.

As the basic APIs utilize single IP address, I think the size of the returned parameters will be the same as conventional APIs.
So, I think there's at least no buffer problem here.
Could you let us know if there're other security implications?  (BTW, 4.4.3 describes some guidelines related to socket buffer size)

[MSC] The data structures of the legacy API are the same, i. e., security should not be affected. The basic API is defined only in an abstract way without data structures, i.e., we can not mandate any type checks etc. We can certainly put a warning sign for implementors of the basic API. But it seems to me like a corner issue.

Thanks,
--
Yoshifumi Nishida

---

From: Wesley Eddy <[email-masked]>
Date: Sun, 25 Nov 2012 20:57:19 -0500

> for the 1st subflow or not I guess.) This might be called

Doesn't what's "right" depend on the application (or TLS) and
what policy it might want to enforce for address use?  I would
think that an MPTCP-aware TLS spec is out-of-scope for MPTCP to
try to give guidance on, and that the TLS WG would maybe do that
instead.

TLS is an important upper layer to consider as an example, but
I don't think we're going to fully specify or give guidance on
particular upper layer protocols over MPTCP, beyond just saying
what the default behavior is for legacy applications and what
the API makes available to MPTCP-aware application code.

-- 
Wes Eddy
MTI Systems

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 26 Nov 2012 02:09:06 +0000

Hi Wes 

> the API makes available to MPTCP-aware application code.

Maybe you're right but I guess we don't want there to be N equally good non interoperable ways to do TLS/MPTCP. Happy for that to not happen however is best.

S

---

From: Olivier Bonaventure <[email-masked]>
Date: Mon, 26 Nov 2012 09:01:46 +0100

Hello,

The current draft explains a basic MPTCP API whose purpose is to be as
close as possible to the cassical socket API for applications. The
current Linux implementation is already compatible with existing
applications including those that are using TLS, but also skype and
other more exotic applications.

In the discussions, we have to decouple the basic MPTCP API that aims to
be as close as possible to the socket API (and as a consequence hides
most of MPTCP to the application) and a more advanced API that would
expose additional information to the MPTCP-aware application.
> explain the cases where might cause failures?

Hiding the changes to the IP addresses is a feature that MPTCP provides
to the applications. If applications want to control this feature, this
will require an advanced API.

> [MSC] Use of addresses in TLS certificates is an interesting question
> that I have not been aware of. Thanks for raising this. But I am not
> sure if TLS would actually want to care about subflow addresses. 

I don't think that basic TLS should be concerned by this.

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

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Mon, 26 Nov 2012 10:55:59 +0100

Hi all,

One comment inline ([MSC]).

Thanks

Michael

________________________________________
Von: [email-masked] [[email-masked]] im Auftrag von Stephen Farrell [[email-masked]]
Gesendet: Montag, 26. November 2012 03:09
An: Wesley Eddy
Cc: multipathtcp; IESG
Betreff: Re: [multipathtcp] Fwd: Stephen Farrell's Discuss on   draft-ietf-mptcp-api-06: (with DISCUSS and COMMENT)

[...]

[MSC] I don't fully understand why different policies in the end system would not be interoperable. But, having said this, I think that there is an additional mechanism that helps here: If there is an IP address in a certificate, I'd assume that a server has to call bind() to this address, right? Otherwise, the TCP/IP stack is free to select any IP address and the certificate is less useful... However, if bind() with a specific address is used, the API document mandates that MPTCP must stick to this and never use other addresses for subflows unless they are explicitly provided by the app (which is not possible in legacy mode). In summary, if TLS uses a correct bind() in legacy mode, is there anything left we have to care about?

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 26 Nov 2012 11:39:18 +0000

Hiya,

> One comment inline ([MSC]).

First, the "strict" and "lax" policies I mentioned before would
not interoperate with some certificates and some subflows. If
the strict side checks the set of addresses that are used after
the first subflow, which the basic API allows, then it might
see an address that doesn't match the other side's certificate
and barf.

I suspect that you're better off here saying that the TLS
implementations using the basic API SHOULD|MUST NOT check 2nd
and subsequent subflow addresses vs. certificates, and that's
on the basis that MPTCP handles the security for relating the
1st and subsequent subflows. A consequence IMO is that MPTCP
will need to have an option that makes it able to do as good
a job as TLS for additional subflows, when we get to a
standards-track version, so this isn't a free-lunch even if
it is probably the easiest thing to do right now;-)

Secondly, its a bit of a corner case, but TLS clients can also
present certificates so everything here can happen on both
sides.

On bind() as a solution - I don't think you want that since
it'd mean that TLS implementations couldn't make use of
MPTCP (according to 4.2.1 of this draft) which'd be a bad
outcome IMO.

In any case, I do think that something needs to be stated
here and this is not just an application layer thing. It might
be properly called that from your perspective as developers
of MTPCP, but people writing applications wouldn't agree I
suspect since they tend to see TLS as a secure transport
and often access it via sockets-like APIs.

So all in all, I'd suggest the following:

"Implementations of TLS [RFC5246] making use of the basic
API that compare the addresses used by MPTCP against names
or addresses present in X.509 certificates [RFC5280,RFC6125]
MUST only consider the addresses used in the initial subflow
since MPTCP itself handles the security of subsequent
subflows. A need for finer-grained controls would imply a
need to use an advanced API."

But I also think that that needs to be checked with the
TLS WG, just in case, once you MPTCP folk are happy with
it. If you read rfc 6125 you'll see that there are a load
of subtleties here, and even though 6125 is about names and
not addresses, a lot of that is relevant to figuring out
the right thing to do.

S.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 26 Nov 2012 11:45:41 +0000

Hi,

Just on the comment part of this...

> [MSC] The data structures of the legacy API are the same, i. e., security should not be affected. The basic API is defined only in an abstract way without data structures, i.e., we can not mandate…

The data structure is the same but the cardinality can
now change with different calls as subflows change, and
that's new, right?

If so and some bit of code allocates enough space for the
getpeername() return with the initial subflow, then some
other bit of code might overrun that later with a
struct copy from a later call to getpeername().

Yes, that'd be bad code. But it happens all the time
still, and MPTCP creates a new way for it to happen, so
I think it'd be good to mention that if I'm right that
it can happen and is new. If I'm wrong and it can't
happen or is not new, then I'd agree it doesn't need
a mention.

Cheers,
S.

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Mon, 26 Nov 2012 12:59:27 +0100

Stephen,

Maybe I miss something here, but our intention was that getpeername() always returns exactly the same data. The statement in s4.2.2 is:

   This problem is addressed as follows: If used by a legacy
   application, the MPTCP stack MUST always return the addresses of the
   first subflow of an MPTCP connection, in all circumstances, even if
   that particular subflow is no longer in use.

As a result, the app should not see any difference to TCP, as far as I can tell. Specifically, the data structure sizes etc. are independent of the number of subflows, and memory allocation should continue to work as today.

Right now, we have a MUST for legacy applications, and a SHOULD for MPTCP-aware applications, because it is for further study whether in future getpeername() could return something else if the stack knows that the app is MPTCP-aware (e. g., by explicit enabling). I agree that in that case memory allocation is an issue if that should ever happen, and we could add this problem as an additional reason why even for MPTCP-aware applications the semantics of getpeername() should better not change.

Thanks

Michael

________________________________________
Von: Stephen Farrell [[email-masked]]
Gesendet: Montag, 26. November 2012 12:45
An: Scharf, Michael (Michael)
Cc: Yoshifumi Nishida; multipathtcp; [email-masked]
Betreff: Re: AW: [multipathtcp] Fwd: Stephen Farrell's Discuss on draft-ietf-mptcp-api-06: (with DISCUSS and COMMENT)

Hi,

Cheers,
S.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 26 Nov 2012 12:08:24 +0000

Hiya,

Bear in mind this is a comment, so you can decide to just
ignore this whenever you like and that's just fine.

> Right now, we have a MUST for legacy applications, and a SHOULD for MPTCP-aware applications, because it is for further study whether in future getpeername() could return something else if the stac…

I'm not trying to argue about the semantics of the API
here at all, just wondering if some warning text would
be useful.

The kind of warning we're talking about would really
be there in the (possibly forlorn) hope that someone
implementing the MPTCP API would pass that on to folks
using the API via some kind of documentation.

If an existing application gets ported to the new MPTCP
basic API, then some of its code will change, but maybe
not all and if this draft said "watch out - your memory
management assumptions might be changed by using the
basic API" then that might just help someone.

So, that's all I'm suggesting. getpeername() is just one
possible example - you might be able to find a much
better one.

Cheers,
S.

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 27 Nov 2012 09:25:34 -0800

> -----Original Message-----
> From: [email-masked] [mailto:multipathtcp-
> [email-masked]] On Behalf Of Stephen Farrell
> Sent: Monday, November 26, 2012 3:39 AM
> To: Scharf, Michael (Michael)
> Cc: multipathtcp; IESG
> Subject: Re: [multipathtcp] Fwd: Stephen Farrell's Discuss on draft-
> ietf-mptcp-api-06: (with DISCUSS and COMMENT)
> 
> 
> Hiya,
> 
> > Von: [email-masked] [[email-masked]] im
> > Auftrag von Stephen Farrell [[email-masked]]
> > Betreff: Re: [multipathtcp] Fwd: Stephen Farrell's Discuss on   draft-
> ietf-mptcp-api-06: (with DISCUSS and COMMENT)
> >
> > [...]
> >
> >>> I can well imagine that different TLS/MPTCP implementations might
> >>> react differently since there are different reasonable things one
> >>> might do here, and that could break interop.
> >>>
> >>> At one end of the spectrum, an implementer might conclude that if IP
> >>> addresses are in a TLS client or server cert then all addresses for
> >>> all subflows MUST be mentioned. This might be called the 'strict'
> >>> approach.
> >>>
> >>> At the other end, another implementer might conclude that if any IP
> >>> address of any subflow is mentioned in the cert then its all ok.
> >>> (Possibly even ignoring if that address is for the 1st subflow or
> >>> not I guess.) This might be called the 'lax' approach.
> >>
> >>
> >> Doesn't what's "right" depend on the application (or TLS) and what
> >> policy it might want to enforce for address use?  I would think that
> >> an MPTCP-aware TLS spec is out-of-scope for MPTCP to try to give
> >> guidance on, and that the TLS WG would maybe do that instead.
> >>
> >> TLS is an important upper layer to consider as an example, but I
> >> don't think we're going to fully specify or give guidance on
> >> particular upper layer protocols over MPTCP, beyond just saying what
> >> the default behavior is for legacy applications and what the API
> >> makes available to MPTCP-aware application code.
> >>
> >
> > Maybe you're right but I guess we don't want there to be N equally
> good non interoperable ways to do TLS/MPTCP. Happy for that to not
> happen however is best.
> >
> > [MSC] I don't fully understand why different policies in the end
> system would not be interoperable. But, having said this, I think that
> there is an additional mechanism that helps here: If there is an IP
> address in a certificate, I'd assume that a server has to call bind() to
> this address, right? Otherwise, the TCP/IP stack is free to select any
> IP address and the certificate is less useful... However, if bind() with
> a specific address is used, the API document mandates that MPTCP must
> stick to this and never use other addresses for subflows unless they are
> explicitly provided by the app (which is not possible in legacy mode).
> In summary, if TLS uses a correct bind() in legacy mode, is there
> anything left we have to care about?
> 
> First, the "strict" and "lax" policies I mentioned before would not
> interoperate with some certificates and some subflows. If the strict
> side checks the set of addresses that are used after the first subflow,
> which the basic API allows, then it might see an address that doesn't
> match the other side's certificate and barf.
> 
> implementations using the basic API SHOULD|MUST NOT check 2nd and
> subsequent subflow addresses vs. certificates,

Agreed.

> and that's on the basis
> that MPTCP handles the security for relating the 1st and subsequent
> subflows.

But security is not solely reliant on MPTCP; TLS also handles the 
security for the subsequent flows.

> A consequence IMO is that MPTCP will need to have an option
> that makes it able to do as good a job as TLS for additional subflows,
> when we get to a standards-track version, so this isn't a free-lunch
> even if it is probably the easiest thing to do right now;-)

Let's generalize this problem a little but putting TLS aside for a moment, 
and consider how MPTCP would work with HTTP, specifically with a URL 
containing an IPv4 address literal, let's say http://192.0.2.1.  When
accessing that URL, the TCP stack will initially connect to 192.0.2.1
and the HTTP header will contain "Host: 192.0.2.1".

MPTCP might bring up a separate flow, to a different IP address,
let's say 192.0.2.2.  

MPTCP does not expect HTTP to send a new request, nor expect HTTP to 
react to the flow going over 192.0.2.2.  This is because HTTP is
an application and is generally unaware that MPTCP brought up a 
separate flow to 192.0.2.2.

If you are saying TLS needs special handling for this case, would 
not HTTP also need special handling for that same case, and so
would any other application protocol running over TCP that exchanges
IP address literals or exchanges FQDN where the FQDN might not
resolve to the IP addresses used by MPTCP?

> Secondly, its a bit of a corner case, but TLS clients can also present
> certificates so everything here can happen on both sides.
> 
> On bind() as a solution - I don't think you want that since it'd mean
> that TLS implementations couldn't make use of MPTCP (according to 4.2.1
> of this draft) which'd be a bad outcome IMO.
> 
> In any case, I do think that something needs to be stated here and this
> is not just an application layer thing. It might be properly called that
> from your perspective as developers of MTPCP, but people writing
> applications wouldn't agree I suspect since they tend to see TLS as a
> secure transport and often access it via sockets-like APIs.
> 
> "Implementations of TLS [RFC5246] making use of the basic API that
> compare the addresses used by MPTCP against names or addresses present
> in X.509 certificates [RFC5280,RFC6125] MUST only consider the addresses
> used in the initial subflow since MPTCP itself handles the security of
> subsequent subflows. A need for finer-grained controls would imply a

Seems reasonable to me.

> But I also think that that needs to be checked with the TLS WG, just in
> case, once you MPTCP folk are happy with it. If you read rfc 6125 you'll
> see that there are a load of subtleties here, and even though 6125 is
> about names and not addresses, a lot of that is relevant to figuring out
> the right thing to do.

-d

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 27 Nov 2012 19:15:50 +0000

Hi Dan,

> security for the subsequent flows.

Sure.

>> even if it is probably the easiest thing to do right now;-)

Lemme correct my text above a bit. With my suggested handling of
addresses in public key certs, a standards-track MPTCP will need
to do a good enough job in associating subflows so that it does
not create any new security issues for TLS.

> resolve to the IP addresses used by MPTCP?

My concern is e.g. that if MPTCP security were not ok, then that
might create new MITM problems for TLS.

I don't think this is a hard thing to avoid though, but it is a
hard thing to check that you've avoided.

>> need to use an advanced API."

Ok. I already updated my discuss to say that. Sean's gonna send that
to the TLS WG to give 'em a chance to check it.

S

---

From: Sean Turner <[email-masked]>
Date: Tue, 27 Nov 2012 15:32:37 -0500

> to the TLS WG to give 'em a chance to check it.

FYI - already sent

spt

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 28 Nov 2012 15:33:12 +0000

Hi Dan,

I'm really sorry about this, but in the process of asking
the TLS wg about the suggested, I belated recalled that
RFC 5280 has name constraints which can be expressed as
IP addresses and can specify excluded subtrees, so its
possible for a cert to say:

   "this is not for <<these>> IP address(es)".

I really doubt anyone cares about or uses this, since
I don't think its actually used, but it might mean
that we need to re-think the lax vs strict thing.
Or at least explain that being lax means you might
do what the CA considers the wrong thing.

Sorry again for not coming up with this earlier,
Cheers,
S.

PS: Yes, I'm an author of 5280 so I really have no
good excuse for not remembering it;-)

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 28 Nov 2012 07:56:32 -0800

> >> A consequence IMO is that MPTCP will need to have an option that
> >> makes it able to do as good a job as TLS for additional subflows,
> addresses in public key certs, a standards-track MPTCP will need to do a
> good enough job in associating subflows so that it does not create any
> new security issues for TLS.

Thanks for that clarification.

> > Let's generalize this problem a little but putting TLS aside for a
> > moment, and consider how MPTCP would work with HTTP, specifically with
> > a URL containing an IPv4 address literal, let's say http://192.0.2.1.
> > When accessing that URL, the TCP stack will initially connect to
> > 192.0.2.1 and the HTTP header will contain "Host: 192.0.2.1".
> >
> > MPTCP might bring up a separate flow, to a different IP address, let's
> > say 192.0.2.2.
> >
> > react to the flow going over 192.0.2.2.  This is because HTTP is an
> > application and is generally unaware that MPTCP brought up a separate
> > flow to 192.0.2.2.
> >
> > If you are saying TLS needs special handling for this case, would not
> > HTTP also need special handling for that same case, and so would any
> > other application protocol running over TCP that exchanges IP address
> > literals or exchanges FQDN where the FQDN might not resolve to the IP
> > addresses used by MPTCP?
> 
> My concern is e.g. that if MPTCP security were not ok, then that might
> create new MITM problems for TLS.

I expect everyone agrees we do not want new attacks against TLS.

> I don't think this is a hard thing to avoid though, but it is a hard
> thing to check that you've avoided.

-d

> >> present certificates so everything here can happen on both sides.
> >>
> >> that TLS implementations couldn't make use of MPTCP (according to
> >> 4.2.1 of this draft) which'd be a bad outcome IMO.
> >>
> >> In any case, I do think that something needs to be stated here and
> >> this is not just an application layer thing. It might be properly
> >> called that from your perspective as developers of MTPCP, but people
> >> writing applications wouldn't agree I suspect since they tend to see
> >> TLS as a secure transport and often access it via sockets-like APIs.
> >>
> >> compare the addresses used by MPTCP against names or addresses
> >> present in X.509 certificates [RFC5280,RFC6125] MUST only consider
> >> the addresses used in the initial subflow since MPTCP itself handles
> >> the security of subsequent subflows. A need for finer-grained
> >> controls would imply a need to use an advanced API."
> >
> > Seems reasonable to me.
> 
> Ok. I already updated my discuss to say that. Sean's gonna send that to
> the TLS WG to give 'em a chance to check it.
> 
> S
> 
> >
> >> But I also think that that needs to be checked with the TLS WG, just
> >> in case, once you MPTCP folk are happy with it. If you read rfc 6125
> >> you'll see that there are a load of subtleties here, and even though
> >> 6125 is about names and not addresses, a lot of that is relevant to
> >> figuring out the right thing to do.
> >
> > -d
> >
> >

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 28 Nov 2012 23:36:59 +0000

Update on that.

I think we can get away with saying that if you care
about excludedSubtrees then you need to use the
advanced API. I can't figure how to make it work with
the basic API at all but that's ok since nobody does
excludedSubtrees that I know.

I'll give the TLS WG another day or so and then
propose some text if nobody else comes up with any
new points.

Cheers,
S.