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

Stephen Farrell <stephen.farrell@cs.tcd.ie> Wed, 28 November 2012 15:25 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB4A521F8867 for <tls@ietfa.amsl.com>; Wed, 28 Nov 2012 07:25:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ez5iAwAHBSG3 for <tls@ietfa.amsl.com>; Wed, 28 Nov 2012 07:25:16 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 0903021F8891 for <tls@ietf.org>; Wed, 28 Nov 2012 07:25:15 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 3C5C7BE62; Wed, 28 Nov 2012 15:24:53 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TQeADm09ccQA; Wed, 28 Nov 2012 15:24:52 +0000 (GMT)
Received: from [IPv6:2001:770:10:203:9999:53ef:87e7:8281] (unknown [IPv6:2001:770:10:203:9999:53ef:87e7:8281]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 4AEAFBE20; Wed, 28 Nov 2012 15:24:52 +0000 (GMT)
Message-ID: <50B62CC4.6090109@cs.tcd.ie>
Date: Wed, 28 Nov 2012 15:24:52 +0000
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Florian Weimer <fweimer@redhat.com>
References: <50A53890.4090502@ieca.com> <50B5105B.1050806@ieca.com> <50B5C5D0.8060904@redhat.com>
In-Reply-To: <50B5C5D0.8060904@redhat.com>
X-Enigmail-Version: 1.4.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: tls@ietf.org
Subject: Re: [TLS] Impact of draft-ietf-mptcp-api on TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Nov 2012 15:25:17 -0000

On 11/28/2012 08:05 AM, Florian Weimer wrote:
> On 11/27/2012 08:11 PM, Sean Turner wrote:
>> On 11/15/12 1:46 PM, Sean Turner wrote:
>>> 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?
>>
>> 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."
> 
> I think the "since" part is wrong.  The security of the subsequent
> 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.

>