Re: [TLS] Impact of draft-ietf-mptcp-api on TLS

[Stephen Farrell <[e-mail]>]

Hi Geoffrey,

On 11/28/2012 07:52 PM, Geoffrey Keating wrote:
> Stephen Farrell <[e-mail]> writes:
> 
>> Hi Martin,
>>
>> We're trying to figure out if the mptcp API document needs
>> to say anything about tls, and if so, what. And I'd like
>> to do that so mptcp doesn't have to fall back to just tcp
>> for all cases where you need tls, if that's ok, so that
>> mptcp has a chance to get used. (I figure its hard enough
>> being a new transport these days, but being a new transport
>> that is useless under TLS seems like a bit of a killer.)
> 
>> On 11/28/2012 03:36 PM, Martin Rex wrote:
>>> The IP-address
>>> that the socket shows after connection establishment is
>>> completely irrelevant to the security of TLS, even when
>>> Server-Certificates with IP-Addresses in the SubjectAltName
>>> are used for server endpoint identification according to
>>> rfc2818 section 3.1.
>>
>> Well, 2818 is just http/tls/tcp and the context here is
>> anything/tls/mptcp so I'm not sure that solves the problem
>> of what to say.
>>
>> I think its true that there's no security issue, but there
>> might be an interop issue, if different folks implement
>> tls/mptcp differently. If the tls code just uses the normal
>> socket api then there's nothing to say, but it won't get
>> the benefit of mptcp. If the tls code uses the basic api
>> then it can see which subflows are being used and different
>> folks might do different comparisons to the certs used.
> 
> Maybe a related example will help: suppose the user is trying to
> connect to https://198.51.100.3.  There is an HTTP proxy configured,
> so what the browser actually does is make a TCP connection to
> 192.0.2.99, send 'CONNECT https://198.51.100.3', and then start the
> SSL negotiation.  The certificate still has to mention 198.51.100.3,
> and doesn't have to mention 192.0.2.99.
> 
> So, in MPTCP, if the user asks for mphttps://198.51.100.3 (or
> whatever), then 198.51.100.3 is the address that has to appear in the
> certificate, even if the connection is redirected to some other
> endpoint, even if the redirection happens before any data is actually
> sent on the connection.

Right. And I think that ignoring excludedSubtrees that's all
fine and the right thing is to say that the TLS implementation
ought only compare the address of with which it chose to connect
for a client or the 1st subflow for a server against certs, if
it needs to bother with that.

I'm not sure what to say about excludedSubtrees though. Maybe,
given that nobody uses 'em or wants to use 'em for TLS (correct?)
we can just say its a potential problem and that you need to
use an advanced API if you care about that. (You couldn't be
sure not to have missed some IP address with the basic API I
think.)

I think that might be ok and will provide that feedback to
the mptcp folks unless someone else has more to say.

Cheers,
S.