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

[Peter Saint-Andre <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlC2hPYACgkQNL8k5A2w/vxh+QCgozvyk8K6K1z6lHEz8hafzTGL
CEYAoL6fF0tgUeP3oohDbXmLRafdTEqj
=iJ0P
-----END PGP SIGNATURE-----