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 02:35 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 2D6EC1ACE7C for <tls@ietfa.amsl.com>; Wed, 20 May 2015 19:35:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.551
X-Spam-Level:
X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Ujj0Y4_Xm5iv for <tls@ietfa.amsl.com>; Wed, 20 May 2015 19:35:07 -0700 (PDT)
Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 471C71ACE78 for <tls@ietf.org>; Wed, 20 May 2015 19:35:07 -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 smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id 5A1EF458A1; Thu, 21 May 2015 04:35:05 +0200 (CEST)
X-purgate-ID: 152705::1432175705-0000413A-4EA279CA/0/0
X-purgate-size: 2465
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 4003B411BE; Thu, 21 May 2015 04:35:05 +0200 (CEST)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 34E031B317; Thu, 21 May 2015 04:35:05 +0200 (CEST)
In-Reply-To: <201505202215.52302.davemgarrett@gmail.com>
To: Dave Garrett <davemgarrett@gmail.com>
Date: Thu, 21 May 2015 04:35:05 +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: <20150521023505.34E031B317@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/V0JAaqeWctb7YZ152k_-EZnDTlA>
Cc: 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 02:35:09 -0000

Dave Garrett wrote:
> On Wednesday, May 20, 2015 08:22:23 pm Martin Rex wrote:
>> 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.
>[...]
>> 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.
> 
> That said, your argument is basically just that it doesn't affect you so it's
> not worth dealing with. TLS is a general security protocol used on the Web,
> not just by your customers. In the same way that IoT people will have to
> deal with stuff that isn't ideal for tiny embedded systems, people not
> accustomed to the mess that is the Web will have to deal with stuff that
> isn't ideal for people who can actually contact server admins every time.
> 
> The ability to reliably contact server admins to deal with interop reports
> from users sounds wonderful, but it's a fantasy to us trying to triage the
> mess on the Web side of the spectrum. Seriously; we're not debating
> this issue from the same world, but TLS has to operate in both.

You are totally missing the point.
I *DO* care quite a lot about interoperability, and about
the amount of work that others will have to interop with us.


The issue here is about improving implementations that they become
easier to use.  It is not possible to "misconfigure" our SSL implementation
so that it sends junk in the TLS handshake.  The admin will face an
error and a refusal to install&use an incomplete certificate chain
on the server side, so that no peer will ever have to deal with
the problem with our software sending junk in a Certificate
handshake messages.  I added this check into our PKI credentials
maintenance on purpose about a decade ago.

The proposed change does not encourage other implementers to improve
their implementations to catch and complain problems as soon as they
are created to the person that is in the best position to fix it,
but rather the opposite.
Because I *DO* care, I do not want to see others promoting a mess
that currently seems to be limited (and still fixable).


-Martin