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

Watson Ladd <watsonbladd@gmail.com> Thu, 21 May 2015 22:42 UTC

Return-Path: <watsonbladd@gmail.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 81B2F1A90F3 for <tls@ietfa.amsl.com>; Thu, 21 May 2015 15:42:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 rQzDMbJrOyHb for <tls@ietfa.amsl.com>; Thu, 21 May 2015 15:42:56 -0700 (PDT)
Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 061491A8784 for <tls@ietf.org>; Thu, 21 May 2015 15:42:56 -0700 (PDT)
Received: by wicmx19 with SMTP id mx19so30011324wic.0 for <tls@ietf.org>; Thu, 21 May 2015 15:42:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ERePXHcfGJEJNpYNECIcI5U3aqv5QhPX/30ARIBdJDY=; b=DCYpxlXGR2d7pmKbFjVDdcHxIEy0vUE6mfhjIeDwkuj17AsxXPjZlENtJimOXnPVz6 QeyP12qvypZZ4oi05uu7XGuiDWgGH3sz6kIeT+qoZGl5yO1WfgTETLn5hNYi01OkwH4d 0VXIt4uhIhtgDrHsIX9V2aSalNqtGXIm+F2nWqJ+RfrUfchDUfvwZNaE8FeoeC3iHRC4 mLueahwBqttn/b1DPymXjnnz08ZcBqTcjd5btNy2i6V+/hmNLu8oCa7eEjatI0jm12Ji Pi9TgEuz6/xCGivVREKf9wfR5T2nhIXhxhv3LRL1zqQPEd7lm7WEO/sKkfmGPofGcn2S 1irw==
MIME-Version: 1.0
X-Received: by 10.180.8.41 with SMTP id o9mr1645206wia.83.1432248174823; Thu, 21 May 2015 15:42:54 -0700 (PDT)
Received: by 10.194.20.97 with HTTP; Thu, 21 May 2015 15:42:54 -0700 (PDT)
In-Reply-To: <20150521002223.27E1F1B317@ld9781.wdf.sap.corp>
References: <BLUPR03MB1396D12DBD3232776CF85AFF8CC20@BLUPR03MB1396.namprd03.prod.outlook.com> <20150521002223.27E1F1B317@ld9781.wdf.sap.corp>
Date: Thu, 21 May 2015 18:42:54 -0400
Message-ID: <CACsn0cnfLJ=_iV7qYjkdh6r3aMatRMu5dzvq_03KwUeWge6acA@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: "mrex@sap.com" <mrex@sap.com>
Content-Type: text/plain; charset=UTF-8
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/137m6Dj1roTW6lhigtH-UDdEOUc>
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
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 22:42:58 -0000

On Wed, May 20, 2015 at 8:22 PM, Martin Rex <mrex@sap.com>; wrote:
> 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

What about junk following the chain, as needed in the case of updates
to signature algorithms?

>
> 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.

So none of your clients are dealing with bridge CAs, CAs that are
handling migrations in the way that Ryan Sleevi indicated some are, or
are dealing across organizational boundaries?

>
> 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.

As you admitted above, you don't see any of the problems in the wild
the web browser people do.

>
>
> 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.

Or is it going to warn the implementor that all sorts of junk will be
expected to work, and of some of the dragons that may exist?
Documenting the *actual* problems in the world is far more useful than
ignoring them entirely.

>
>
> 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
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls



-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.