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

[Stephen Farrell <[e-mail]>]

On 11/28/2012 09:41 PM, Peter Saint-Andre wrote:
> On 11/28/12 12: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.
> 
> This is basically the "CertID" problem (RFC 6125). When Jeff Hodges
> and I worked on that spec, we deliberately left IP addresses out of
> scope, but if someone wants to work on a similar (though much simpler)
> document about IP addresses instead of domain names, I'm sure they
> could find quite a bit of text to borrow.

Yep, I pointed the mptcp folks at that already. I suspect they
may have found it frightening;-) X.509 PKI just has too many
twistable knobs unfortunately.

S.


> 
> Peter
> 
> 
>