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 (CEST)
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 (Martin Rex)
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