Re: [TLS] relax certificate_list requirements - opinion call (was Re: [tls13-spec] relax certificate_list ordering requirements to match current practice (#169)) I wonder if anyone is reading the full subject line or does it just get truncated at some poi

mrex@sap.com (Martin Rex) Thu, 21 May 2015 00:22 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 D77991ACD48 for <tls@ietfa.amsl.com>; Wed, 20 May 2015 17:22:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.151
X-Spam-Level:
X-Spam-Status: No, score=-5.151 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 Q90VBN1EroBg for <tls@ietfa.amsl.com>; Wed, 20 May 2015 17:22:25 -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 1C9F81ACD39 for <tls@ietf.org>; Wed, 20 May 2015 17:22:25 -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 4ACAA2BC79; Thu, 21 May 2015 02:22:23 +0200 (CEST)
X-purgate-ID: 152705::1432167743-0000413A-275A46C6/0/0
X-purgate-size: 2823
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 3507E4116B; Thu, 21 May 2015 02:22:23 +0200 (CEST)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 27E1F1B317; Thu, 21 May 2015 02:22:23 +0200 (CEST)
In-Reply-To: <BLUPR03MB1396D12DBD3232776CF85AFF8CC20@BLUPR03MB1396.namprd03.prod.outlook.com>
To: Andrei Popov <Andrei.Popov@microsoft.com>
Date: Thu, 21 May 2015 02:22:23 +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: <20150521002223.27E1F1B317@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/Hb8dgOB-MwLw6Ha44tOjiuz2oxI>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] relax certificate_list requirements - opinion call (was Re: [tls13-spec] relax certificate_list ordering requirements to match current practice (#169)) I wonder if anyone is reading the full subject line or does it just get truncated at some poi
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: Thu, 21 May 2015 00:22:28 -0000

Andrei Popov wrote:
>
> This isn't about a specific TLS implementation. As Ryan explained
> (http://www.ietf.org/mail-archive/web/tls/current/msg16238.html),
> servers today have to deviate from the certificate_list ordering
> requirements for a variety of practical reasons. Clients can't take
> advantage of these requirements, because servers violate them.
> So if neither clients nor servers can in practice implement this
> RFC language, why don't we drop it?

Not adhering to the requirements will cause *REAL* interoperability
problems in the installed base, because there are implementations
that will fail if TLS peers start sending junk.  For 13 years,
our implementation was very strict and tolerated not even duplicates
nor incorrect order of path certificates

Currently, the amount of TLS servers and TLS clients that are sending
junk seems to either negigible small, or limited to pure Web-Browser to
third-party Web-Server scenarios, i.e. pretty much none of our customers
are trying to make our software interoperate with such clients or servers.

I get to see most non-trivial SSL interop problems that our customers
report for usage scenarios, and what I've seen looks like a _very_low_
number of misconfigured Apaches with OpenSSL with these three kinds
of problems:
   - missing path CA certificates
     (e.g. yesterday, after a service provider for invoicing has switched
      from a verisign-issued server certificate, where it properly sent
      all path certificates to a GeoTrust-issued server certificate,
      where the server is sending only the server certificate)

  - duplicate certificate in the chain

  - garbled certificate chain (wrong oder of path certificates)

For the handful of customers who had that interop problem, contacting
the server admin and having them fix their server configuration was
possible every time, and I could point to the spec after analyzing
the problem to pass the blame.


So what "flexibility" there is in some implementations is much
less relevant than with how much actual abuse there currently
is in the installed base.  And to me, the visible level of abuse
is low, so the resulting amount of de-facto interop problems is low.


The only motivation that has been given for changing the requirements
is that folks consider it necessary to promote the amount of abuse
in the installed base -- which is going to create interoperability
problems and headaches as a result.


For those who have been and still are ignoring the requirements in
the specification today, why do you need these requirements changed?
You seemed to not have a problem ignoring the reasonable guidance
(that greatly simplifies implementations) all the time anyway -- you
evidently do not need this change.


-Martin