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

Geoffrey Keating <geoffk@geoffk.org> Fri, 30 November 2012 23:05 UTC

Return-Path: <geoffk@geoffk.org>
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 B00C821F8B47 for <tls@ietfa.amsl.com>; Fri, 30 Nov 2012 15:05:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NORMAL_HTTP_TO_IP=0.001]
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 BCxgYm8X0fgk for <tls@ietfa.amsl.com>; Fri, 30 Nov 2012 15:05:39 -0800 (PST)
Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [216.129.118.138]) by ietfa.amsl.com (Postfix) with ESMTP id 2FEA721F8ABB for <tls@ietf.org>; Fri, 30 Nov 2012 15:05:39 -0800 (PST)
Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id B553833D046; Fri, 30 Nov 2012 23:05:36 +0000 (UTC)
Sender: geoffk@localhost.localdomain
To: Florian Weimer <fweimer@redhat.com>
References: <20121128153650.7A2971A3BD@ld9781.wdf.sap.corp> <50B6333C.50606@cs.tcd.ie> <m2624ptshs.fsf@localhost.localdomain> <50B72900.5050400@redhat.com>
From: Geoffrey Keating <geoffk@geoffk.org>
Date: Fri, 30 Nov 2012 15:05:36 -0800
In-Reply-To: <50B72900.5050400@redhat.com>
Message-ID: <m21ufau1xb.fsf@localhost.localdomain>
Lines: 42
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
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: Fri, 30 Nov 2012 23:05:39 -0000

Florian Weimer <fweimer@redhat.com> 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?  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.