Re: [TLS] Update spec to match current practices for certificate chain order

Dave Garrett <> Fri, 08 May 2015 15:30 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E59D21A026E for <>; Fri, 8 May 2015 08:30:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Status: No, score=-1.4 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, J_CHICKENPOX_55=0.6, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kkW0RTPoQM_7 for <>; Fri, 8 May 2015 08:29:59 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 987761A020B for <>; Fri, 8 May 2015 08:29:59 -0700 (PDT)
Received: by qkx62 with SMTP id 62so50300248qkx.0 for <>; Fri, 08 May 2015 08:29:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=VUghM739rHBGoTUtqO+9lTVKUrA3784CJVRDQN4VqL0=; b=hOD0dUm6sPCfOuGiURItPWRQuyPGtnUdKlNuqisAILTxQGYuP8fH2eOLmucdQdpt8u v3XNRy5+uG8JuRIK+UA2zClRPdT5BvB+BnIzIUc/86LPwbePhCXWE0zVgrs9NWrjhmag DIBH5U+XE9+RSnyJjhtZszGh6PNh2WoXtdWoTsL4fE0v8cjgkMWUZhaAumvPpDqea9Um mPnUz+1ywb3qvNDjhXU662Q3vTtdeUB5jmlyAL6WU8CuI1+wfMqdfw9r75SIcL4TOXyc CjaoxFf1AraOvh5bH9c/UEpwsOBpshritUdvBQMUyONN/+1zJ5sJA1RaqHN6joq3dWd2 kmBg==
X-Received: by with SMTP id i68mr5543549qgf.73.1431098998627; Fri, 08 May 2015 08:29:58 -0700 (PDT)
Received: from dave-laptop.localnet ( []) by with ESMTPSA id f131sm3783810qhc.47.2015. (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 08 May 2015 08:29:58 -0700 (PDT)
From: Dave Garrett <>
Date: Fri, 8 May 2015 11:29:56 -0400
User-Agent: KMail/1.13.5 (Linux/2.6.32-73-generic-pae; KDE/4.4.5; i686; ; )
References: <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <>
Archived-At: <>
Subject: Re: [TLS] Update spec to match current practices for certificate chain order
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 08 May 2015 15:30:01 -0000

On Friday, May 08, 2015 10:19:26 am Martin Rex wrote:
> Dave Garrett wrote:
> > On Thursday, May 07, 2015 01:51:35 pm Martin Rex wrote:
> >> Personally, I find it quite appalling how many broken TLS
> >> implementations out there fail to properly encode an ordered list
> >> of certificates into the Certificate handshake message.
> > 
> > or more concisely:
> > 
> > On Thursday, May 07, 2015 01:49:21 am Yoav Nir wrote:
> >> Bleh.
> > 
> > I think we're in fair agreement that this is sloppy, but it's sloppiness
> > that should've been fixed long ago if we still wanted to fight it.
> > 
> > I brought this issue up in response to a bug report for Firefox fully
> > validating an EV cert list with an extra cert and things out of order.
> > Mozilla and others seem to accept it just fine, so either the spec
> > needs updating to reality or everyone should be adding new security
> > errors to break it. The former makes more sense.
> No, the former is clearly detrimental.
> Browsers, which haved added fancy colors and stuff to address bars
> for EV certs, really ought to punish servers sending bogus Certificate
> handshake messages by reducing the color feedback to mere black&white
> and not attributes (_not_ produce a warning!  I believe the Google
> Chrome 42 behaviour for sha1-Signatures is totally wrong, because
> hardly anyone understands what the real issue is, and Chrome will
> not tell you which signature algorithms in which certs it is unsatisfied
> with).

Let me be clear: I don't fundamentally disagree with you. I think that protocols should be treated far more strictly than they tend to be and stuff like this should be a mandatory error if it's against the current spec. That said, if we step ~way~ far back, we're sort of hitting a standard human societal problem: given a problem, and a set of solutions, arguing for the ideal you can't get is an argument for the problem. Do you think we could compel every browser vendor to apply this (effectively) new standard uniformly, and make the changes all at the same time? I don't, especially not from the TLS spec. Vendors can't even drop critically insecure protocols in unison. I don't even have confidence that everyone could coordinate a token change of coloring in the UI for this one narrow case.

This is a wire format issue, rather than a security one, so as long as we have an accepted format that is secure, then it doesn't really matter beyond that. I would agree that browsers should probably throw a warning into their consoles for this sort of thing, but not a user-facing action. Of all the problems TLS has, this is not one I think is worth worrying about too much. ;)

> I believe that one of the causes why the problem exists at all
> is a lack of sensible PKI credential management on the server side.

Likely true, but outside of the current scope of action.