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

From: Sean Turner <[email-masked]>
Date: Thu, 15 Nov 2012 13:46:40 -0500

The Multipath TCP (MPTCP) work is starting to bubble up to the IESG:
http://datatracker.ietf.org/doc/draft-ietf-mptcp-api/
Both Stephen and I have concerns about its interactions with TLS:
https://datatracker.ietf.org/doc/draft-ietf-mptcp-api/ballot/

Has anybody here had a look at mptcp (or want to have a look) and have 
any thoughts about its interactions with TLS?

spt

---

From: Sean Turner <[email-masked]>
Date: Tue, 27 Nov 2012 14:11:23 -0500

> any thoughts about its interactions with TLS?

What's on offer to for the mptcp api draft is as follows:

"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."

Thoughts?

spt

---

From: Florian Weimer <[email-masked]>
Date: Wed, 28 Nov 2012 09:05:36 +0100

> need to use an advanced API."

I think the "since" part is wrong.  The security of the subsequent 
subflows must depend on TLS itself, not MPTCP.

-- 
Florian Weimer / Red Hat Product Security Team

---

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

> subflows must depend on TLS itself, not MPTCP.

Fair point. I can try re-word it, but first to the real
question I'd like to check...

Does anyone care that e.g. a server cert that contains IP
address 'a' might be used for the first subflow, but
subsequent packets for that TLS session can end up going
vis MPTCP to IP address 'b' where 'b' is not mentioned
in the cert?

Ah crap - I just remembered excludedSubtrees can apply to
IP address name constraints. Anyone here care about that?

Cheers,
S.

---

From: [email-masked] (Martin Rex)
Date: Wed, 28 Nov 2012 16:36:50 +0100 (CET)

> IP address name constraints. Anyone here care about that?

I somehow fail to understand the discussion.  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.

What is actually matched is the "information SOURCE" that the application
uses to establish the network connection and the Certificate presented
by the server in the TLS handshake.  Whether there are HTTP CONNECT
proxies or even network-address-transparent MITMs on the path does
not matter for the security provided by TLS, because that information
is not (must not be) part of the information that is matched
during server endpoint identification.

-Martin

---

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

Hi Martin,

On 11/28/2012 03:36 PM, Martin Rex wrote:
> I somehow fail to understand the discussion.  

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.)

> The IP-address

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.

Cheers,
S.

---

From: Geoffrey Keating <[email-masked]>
Date: 28 Nov 2012 11:52:31 -0800

> 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.

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 28 Nov 2012 14:41:10 -0700

On 11/28/12 12:52 PM, Geoffrey Keating wrote:
>> 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.)
> 
>>> 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.
>> 
>> 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.
> 
> 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.
> 
> 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/

---

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

Hi Geoffrey,

> endpoint, even if the redirection happens before any data is actually

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.

---

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

> 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.

---

From: [email-masked] (Martin Rex)
Date: Thu, 29 Nov 2012 01:05:21 +0100 (CET)

> Geoffrey Keating wrote:

Thanks for the example!
That is what I had in mind (but failed to properly explain).

Stephen Farrell wrote:
> fine

HUH?

With "excludedSubtrees", are you thinking of X.509 Name Constraints
(on IP addresses as subject alt names)?

There is no such thing as an "excludedSubtrees" return parameter
defined for the PKIX "Basic Path Validation":

  http://tools.ietf.org/html/rfc5280#section-6.1.6

   6.1.6. Outputs

   If path processing succeeds, the procedure terminates, returning a
   success indication together with final value of the
   valid_policy_tree, the working_public_key, the
   working_public_key_algorithm, and the working_public_key_parameters.

Name Constraints must appear only in CA certificates, Name Constraints
are meaningful and visible exclusively to the internals of the Certificate
Path Validation function, and apply exclusively to Names that are
actually _present_ in subordinate certificates on the path and to the
value of Names _exactly_ as they appear _in_the_certificate_.

>
>        and the right thing is to say that the TLS implementation

I agree, a note should probably added to very very strongly discourage using
any of the characteristics from the resulting connection for performing
server endpoint identification or a real server authentication.  Only
original/trustworthy information ought to be used that existed before
trying to establish the actual network connection with the peer.

An indirection through a "trusted directory" (secure is not sufficient)
would be OK, such as a trusted local configuration, a lookup in a secure
directory (something that existed in DCE), or e.g. transformation through
a DNSSEC-protected TLSA lookup according to DANE.

> 
> I'm not sure what to say about excludedSubtrees though.

If this is about X.509 Name Constraints, then IMO nothing should be said
within mptcp.  It is a matter completely internal to PKIX certificate
path validation.

-Martin

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 29 Nov 2012 00:17:13 +0000

Hiya,

> value of Names _exactly_ as they appear _in_the_certificate_.

Ah, you're right there, thanks. Silly me.

I think we agree about all the rest.

Thanks,
S.

---

From: Florian Weimer <[email-masked]>
Date: Thu, 29 Nov 2012 10:21:04 +0100

> endpoint, even if the redirection happens before any data is actually

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.

This is different from HTML over HTTPS, where additional connections use 
the embedded addresses and names for endpoint verification.  This is 
possible because in the HTML/HTTPS case, these names and addresses are 
protected by the TLS channel, while in MPTCP, they are not.

---

From: Geoffrey Keating <[email-masked]>
Date: 30 Nov 2012 15:05:36 -0800

Florian Weimer <[email-masked]> writes:

> 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?  For
example, if a web page at 198.51.100.3 contains an image tag which
causes a new MPTCP connection to be created, that isn't verified
against 198.51.100.3, it's verified against where the image's URL says
the image should be.

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.

> This is different from HTML over HTTPS, where additional connections
> use the embedded addresses and names for endpoint verification.  This
> is possible because in the HTML/HTTPS case, these names and addresses
> are protected by the TLS channel, while in MPTCP, they are not.

One way to look at this is that it's an OSI layering issue.  TCP and
MPTCP are layers 4 and 5.  TLS certificate validation occurs at layer
7, the application layer, the same layer as the fetching of HTML
images or the execution of JavaScript; TLS, HTTP, and the syntax of
HTML are layer 6.