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

From: Florian Weimer <[email-masked]>
Date: Mon, 03 Dec 2012 10:52:50 +0100

On 12/01/2012 12:05 AM, Geoffrey Keating wrote:
> Florian Weimer <[email-masked]> writes:
>
>> On 11/28/2012 08:52 PM, Geoffrey Keating wrote:
>>
>>> 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.
>>
>> I suspect the confusion arises because if the interaction with
>> 198.51.100.3 causes another connection with a different IP address to
>> be created, it hast to be verified against the IP address 198.51.100.3
>> as well.
>
> Do you mean what MPTCP calls a "subflow", not "connection", here?

I do.

> If you do mean 'subflow', the key thing about that is that there is no
> 'verification' to do.  The certificate won't be sent again, there
> won't be a new TLS negotiation.

Ah, so MPTCP only provides a single byte stream?  Then there shouldn't 
be any TLS interpretation issues.

-- 
Florian Weimer / Red Hat Product Security Team