Re: [TLS] Impact of draft-ietf-mptcp-api on TLS
mrex@sap.com (Martin Rex) Thu, 29 November 2012 00:05 UTC
Return-Path: <mrex@sap.com>
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 B617C21F8952 for <tls@ietfa.amsl.com>; Wed, 28 Nov 2012 16:05:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.249
X-Spam-Level:
X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HELO_EQ_DE=0.35, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_HI=-8]
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 lBQmIltwd-Cb for <tls@ietfa.amsl.com>; Wed, 28 Nov 2012 16:05:33 -0800 (PST)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 077B921F8944 for <tls@ietf.org>; Wed, 28 Nov 2012 16:05:32 -0800 (PST)
Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id qAT05MWD016395 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 29 Nov 2012 01:05:23 +0100 (MET)
In-Reply-To: <50B69D8E.2050309@cs.tcd.ie>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Date: Thu, 29 Nov 2012 01:05:21 +0100
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20121129000521.0CF6D1A3BF@ld9781.wdf.sap.corp>
From: mrex@sap.com
X-SAP: out
Cc: Florian Weimer <fweimer@redhat.com>, Geoffrey Keating <geoffk@geoffk.org>, 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
Reply-To: mrex@sap.com
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: Thu, 29 Nov 2012 00:05:34 -0000
> 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. Thanks for the example! That is what I had in mind (but failed to properly explain). Stephen Farrell wrote: > > Right. And I think that ignoring excludedSubtrees that's all > 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 > 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 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
- [TLS] Impact of draft-ietf-mptcp-api on TLS Sean Turner
- Re: [TLS] Impact of draft-ietf-mptcp-api on TLS Sean Turner
- Re: [TLS] Impact of draft-ietf-mptcp-api on TLS Florian Weimer
- Re: [TLS] Impact of draft-ietf-mptcp-api on TLS Stephen Farrell
- Re: [TLS] Impact of draft-ietf-mptcp-api on TLS Martin Rex
- Re: [TLS] Impact of draft-ietf-mptcp-api on TLS Stephen Farrell
- Re: [TLS] Impact of draft-ietf-mptcp-api on TLS Geoffrey Keating
- Re: [TLS] Impact of draft-ietf-mptcp-api on TLS Peter Saint-Andre
- Re: [TLS] Impact of draft-ietf-mptcp-api on TLS Stephen Farrell
- Re: [TLS] Impact of draft-ietf-mptcp-api on TLS Stephen Farrell
- Re: [TLS] Impact of draft-ietf-mptcp-api on TLS Martin Rex
- Re: [TLS] Impact of draft-ietf-mptcp-api on TLS Stephen Farrell
- Re: [TLS] Impact of draft-ietf-mptcp-api on TLS Florian Weimer
- Re: [TLS] Impact of draft-ietf-mptcp-api on TLS Geoffrey Keating
- Re: [TLS] Impact of draft-ietf-mptcp-api on TLS Florian Weimer