Re: [TLS] Update spec to match current practices for certificate chain order
mrex@sap.com (Martin Rex) Mon, 11 May 2015 14:00 UTC
Return-Path: <mrex@sap.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77DE71A88C9 for <tls@ietfa.amsl.com>; Mon, 11 May 2015 07:00:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.851
X-Spam-Level:
X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OK-3RfmJxu-E for <tls@ietfa.amsl.com>; Mon, 11 May 2015 07:00:00 -0700 (PDT)
Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FC011A0025 for <tls@ietf.org>; Mon, 11 May 2015 07:00:00 -0700 (PDT)
Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 412052AA1A; Mon, 11 May 2015 15:59:58 +0200 (CEST)
X-purgate-ID: 152705::1431352798-00005316-8EF319DE/0/0
X-purgate-size: 2316
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate-type: clean
X-SAP-SPAM-Status: clean
Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 309CB4290C; Mon, 11 May 2015 15:59:58 +0200 (CEST)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 1F96C1B2E4; Mon, 11 May 2015 15:59:58 +0200 (CEST)
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AB019AE1@uxcn10-tdc05.UoA.auckland.ac.nz>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>
Date: Mon, 11 May 2015 15:59:58 +0200
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: <20150511135958.1F96C1B2E4@ld9781.wdf.sap.corp>
From: mrex@sap.com
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/fGF1Hp8NiTB00kD6pK-zTO-5OZs>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] Update spec to match current practices for certificate chain order
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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: Mon, 11 May 2015 14:00:02 -0000
Peter Gutmann wrote: > Martin Rex <mrex@sap.com> writes: >> >>A TLS client should not know or care about the hostname of the server it is >>talking to, and there is no requirement what kind of stuff is contained in >>the server's certificate. > > Which is far too true, unfortunately, particularly among Android and iOS apps, > as recent research (e.g. "Why Eve and Mallory Love Android: An Analysis of > Android SSL (In)Security" and "The most dangerous code in the world: > validating SSL certificates in non-browser software") has pointed out. Still, > not caring whether the supposed www.bankofamerica.com presents a cert for > www.qwertyuiop.com doesn't strike me as a sound security strategy. > >>Our TLS client does _not_ know the server's hostname (it gets a connected >>socket). > > So it's like all the insecure Android and iOS apps? You're obviously confusing application bugs with TLS bugs. As previously mentioned, all TLS specifications up to and including TLSv1.2 have been extremely clear that the name contained in the certifcates is a matter of the protocols & software layers on top of TLS, and none of TLS business: https://tools.ietf.org/html/rfc5246#page-5 the decisions on how to initiate TLS handshaking and how to interpret the authentication certificates exchanged are left to the judgment of the designers and implementors of protocols that run on top of TLS. For (a part) of our code I am providing an abstraction that loads the (external) TLS implemenation, provides configurability for certain default behaviour, performs the client-side caching magic, and it does provide an rfc2818 section 3 server endpoint identity check for convenience, which the API caller can use or override. The TLS(!) implementation itself, however, does not get to see the server hostname. Now the fashion this has been wrapped by higher application layers, it is currently not possible for the _end_user_ to configure our (programmatic) HTTPS client to skip server certificate path validation or server endpoint identity checking, and some of the top-level apps programmers are unhappy, because they have to properly document how to configure their scenarios so that both checks succeed. -Martin
- [TLS] Update spec to match current practices for … Dave Garrett
- Re: [TLS] Update spec to match current practices … Yoav Nir
- Re: [TLS] Update spec to match current practices … Peter Gutmann
- Re: [TLS] Update spec to match current practices … Viktor Dukhovni
- Re: [TLS] Update spec to match current practices … Dave Garrett
- Re: [TLS] Update spec to match current practices … Martin Rex
- Re: [TLS] Update spec to match current practices … Martin Rex
- Re: [TLS] Update spec to match current practices … Peter Gutmann
- Re: [TLS] Update spec to match current practices … Martin Rex
- Re: [TLS] Update spec to match current practices … Peter Gutmann
- Re: [TLS] Update spec to match current practices … Viktor Dukhovni
- Re: [TLS] Update spec to match current practices … Ryan Sleevi
- Re: [TLS] Update spec to match current practices … Martin Rex
- Re: [TLS] Update spec to match current practices … Dave Garrett
- Re: [TLS] Update spec to match current practices … Fabrice Gautier
- Re: [TLS] Update spec to match current practices … Viktor Dukhovni
- Re: [TLS] Update spec to match current practices … Ryan Sleevi
- Re: [TLS] Update spec to match current practices … Viktor Dukhovni
- Re: [TLS] Update spec to match current practices … Geoffrey Keating
- Re: [TLS] Update spec to match current practices … Dave Garrett
- Re: [TLS] Update spec to match current practices … Ryan Sleevi
- Re: [TLS] Update spec to match current practices … Ben Laurie
- Re: [TLS] Update spec to match current practices … Martin Rex
- Re: [TLS] Update spec to match current practices … Kemp, David P.
- Re: [TLS] Update spec to match current practices … Martin Rex
- Re: [TLS] Update spec to match current practices … Kemp, David P.
- Re: [TLS] Update spec to match current practices … Dave Garrett
- Re: [TLS] Update spec to match current practices … Martin Rex
- Re: [TLS] Update spec to match current practices … Martin Rex
- Re: [TLS] Update spec to match current practices … Martin Rex
- Re: [TLS] Update spec to match current practices … Geoff Keating
- Re: [TLS] Update spec to match current practices … Ryan Sleevi
- Re: [TLS] Update spec to match current practices … Dave Garrett
- Re: [TLS] Update spec to match current practices … Ryan Sleevi
- Re: [TLS] Update spec to match current practices … Dave Garrett
- Re: [TLS] Update spec to match current practices … Dave Garrett
- Re: [TLS] Update spec to match current practices … Martin Rex
- Re: [TLS] Update spec to match current practices … Salz, Rich
- Re: [TLS] Update spec to match current practices … Ryan Sleevi
- Re: [TLS] Update spec to match current practices … Dave Garrett
- Re: [TLS] Update spec to match current practices … Viktor Dukhovni
- Re: [TLS] Update spec to match current practices … Peter Gutmann
- Re: [TLS] Update spec to match current practices … Peter Gutmann
- Re: [TLS] Update spec to match current practices … Ben Laurie
- Re: [TLS] Update spec to match current practices … Martin Rex
- Re: [TLS] Update spec to match current practices … Peter Gutmann
- Re: [TLS] Update spec to match current practices … Viktor Dukhovni
- Re: [TLS] Update spec to match current practices … Ilari Liusvaara
- Re: [TLS] Update spec to match current practices … Martin Rex
- Re: [TLS] Update spec to match current practices … Viktor Dukhovni
- Re: [TLS] Update spec to match current practices … Watson Ladd
- Re: [TLS] Update spec to match current practices … Viktor Dukhovni
- Re: [TLS] Update spec to match current practices … Ryan Sleevi
- Re: [TLS] Update spec to match current practices … Martin Rex
- Re: [TLS] Update spec to match current practices … Martin Rex
- Re: [TLS] Update spec to match current practices … Ryan Sleevi
- Re: [TLS] Update spec to match current practices … Martin Rex
- Re: [TLS] Update spec to match current practices … Ryan Sleevi
- Re: [TLS] Update spec to match current practices … Martin Rex
- Re: [TLS] Update spec to match current practices … Ryan Sleevi